[doc](lakehouse) Add external metadata cache memory management for 4.1.4

[CalvinKirs]

What

• Add Chinese and English usage guides for external metadata-cache memory management, supported from Doris 4.1.4.
• Document FE-wide, Catalog-level, and cache-entry-level limits, configuration precedence, examples, and observability.
• Document the supported weighted entries: Hive partition_values; Iceberg table, snapshot, and manifest; Paimon table and snapshot.
• Align the Hive, Iceberg, Paimon, Hudi, and MaxCompute Catalog pages with the merged 4.1 behavior.
• Update catalog_meta_cache_statistics in both languages to match the 33-column FE schema, including weight usage, eviction, and rejection fields.
• Add the guide to the 4.x sidebar and link it from the metadata-cache page.

Runtime behavior covered

• Weight admission occurs after metadata has been loaded and prepared. An oversized or incompletely estimated object is returned to the current query but is not cached; this is retained-memory governance, not pre-load OOM protection.
• Estimation uses type-specific rounded structural constants plus loader-time payload counters. It does not perform generic reflective object-graph traversal or container sampling; Iceberg has one fail-closed probe that only checks whether snapshot metadata is already loaded to avoid estimation-time I/O.
• Local cold-entry eviction is synchronous. Peer reclamation across sibling entries, and across Catalogs for an FE-wide deficit, is asynchronous and best effort.
• A rejected refresh retains the previous known-good generation.
• Weighted entries use soft values, while reservation records do not retain a strong reference to the cached value.
• Successful Catalog property changes reset the Catalog execution context and clear all routed metadata-cache engines; in-flight queries continue with their existing objects.
• Explain the Iceberg manifest-cache and Paimon CachingCatalog defaults when Doris memory governance is active, including explicit-property precedence.

This documents the user-facing behavior introduced by apache/doris#66717.

Checks

• Rebased the PR onto the latest apache/doris-website:master.
• git diff --check.
• Parsed frontmatter and checked balanced code fences in all 16 changed content files.
• Verified both system-table documents contain the same ordered 33 columns as SchemaTable.java.
• Verified the affected documents contain no stale Doris 4.1.5 availability references.

A full Docusaurus build was not run because dependencies are not installed in the clean worktree.

[924060929]

The guide already covers the quota hierarchy, admission/eviction behavior, configuration, and entry-level observability well. Could we also add a Catalog-level summary query? This is likely the first query operators will use:

SELECT
    fe_host,
    catalog_name,
    MAX(catalog_max_weight) AS catalog_max_weight,
    MAX(catalog_estimated_weight) AS catalog_estimated_weight,
    MAX(global_max_weight) AS global_max_weight,
    MAX(global_estimated_weight) AS global_estimated_weight
FROM information_schema.catalog_meta_cache_statistics
WHERE catalog_estimated_weight >= 0
GROUP BY fe_host, catalog_name
ORDER BY fe_host, catalog_name;

CATALOG_MAX_WEIGHT and CATALOG_ESTIMATED_WEIGHT are repeated on every weighted-entry row of the same Catalog, so the example should explicitly use MAX; using SUM would double-count them.

It would also help to clarify the time semantics: ESTIMATED_WEIGHT, CATALOG_ESTIMATED_WEIGHT, and GLOBAL_ESTIMATED_WEIGHT are current reservation gauges at query time, while eviction/rejection fields are cumulative counters for the current cache instance. The system table itself does not retain historical samples.

[924060929]

One additional suggestion: the main operator question is not only what each field means, but what to do when FE memory is under pressure. Could we add a dedicated section such as Troubleshoot and control memory pressure with a short operational runbook?

Suggested flow:

1. Check whether managed metadata caches are materially contributing to the pressure. Query the current per-FE global reservation and configured limit. Explicitly remind users that this is estimated retained-cache weight, not total FE heap, and that load-time temporary memory and count-bounded entries are outside it.
2. Locate the responsible Catalogs. Provide the Catalog-level summary query grouped by FE_HOST, CATALOG_NAME, and explain how to identify a Catalog close to its limit or disproportionately large on one FE.
3. Drill down to entries. Query ENGINE_NAME, ENTRY_NAME, ESTIMATED_WEIGHT, MAX_WEIGHT, EVICTION_WEIGHT, WEIGHT_REJECT_COUNT, LAST_WEIGHT_REJECT_REASON for the target Catalog. Explain that increasing rejection/eviction can indicate quota pressure or an oversized candidate.
4. Choose the appropriate control:
   • set external_meta_cache_max_weight for an FE-wide bound (requires FE restart);
   • set meta.cache.max-weight to isolate one Catalog;
   • set meta.cache.<engine>.<entry>.max-weight when one supported entry dominates;
   • reduce TTL or disable an entry when fresher metadata is preferred over caching.
5. Explain what happens after a change. Catalog-property changes clear the initialized Catalog cache group and rebuild it lazily; in-flight queries keep their existing objects. A lower quota can increase misses and external metadata load latency.
6. State what this mechanism cannot solve. If FE heap remains high while accounted weight is low, investigate unaccounted/count-bounded caches, metadata objects still referenced by running queries, connector SDK caches, and load/materialization peaks instead of simply lowering max-weight.

A compact “symptom → query → interpretation → action” table would make this much more useful during an incident than distributing the information across configuration, observability, and caveat sections.