[Doc] Update iceberg_catalog.md (#52548)

(cherry picked from commit c15d401)

# Conflicts:
#	docs/zh/data_source/catalog/iceberg_catalog.md

docs/en/data_source/catalog/iceberg_catalog.md

@@ -1,6 +1,7 @@
 ---
 displayed_sidebar: docs
 toc_max_heading_level: 5
+keywords: ['iceberg']
 ---
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';

docs/en/quick_start/iceberg.md

@@ -3,6 +3,7 @@ displayed_sidebar: docs
 sidebar_position: 3
 description: Data Lakehouse with Apache Iceberg
 toc_max_heading_level: 2
+keywords: ['iceberg']
 ---
 import DataLakeIntro from '../_assets/commonMarkdown/datalakeIntro.md'
 import Clients from '../_assets/quick-start/_clientsCompose.mdx'

docs/zh/data_source/catalog/iceberg_catalog.md

@@ -1,6 +1,7 @@
 ---
 displayed_sidebar: docs
 toc_max_heading_level: 5
+keywords: ['iceberg']
 ---
 
 # Iceberg catalog
@@ -1152,3 +1153,36 @@ StarRocks 采用 Least Recently Used (LRU) 策略来缓存和淘汰数据，基
 | iceberg_metadata_memory_cache_expiration_seconds | 秒       | `86500`                                              | 内存中的缓存自最后一次访问后的过期时间。                     |
 | iceberg_metadata_disk_cache_expiration_seconds   | 秒       | `604800`，即一周                                     | 磁盘中的缓存自最后一次访问后的过期时间。                     |
 | iceberg_metadata_cache_max_entry_size            | 字节     | `8388608`，即 8 MB                                   | 缓存的单个文件最大大小，以防止单个文件过大挤占其他文件空间。超过此大小的文件不会缓存，如果查询命中则会直接访问远端元数据文件。 |
+<<<<<<< HEAD
+=======
+
+自 v3.3.3 起，Iceberg Catalog 支持 [元数据周期性后台刷新方案](#附录元数据周期性后台刷新方案)。您可以通过系统变量 [`plan_mode`](../../sql-reference/System_variable.md#plan_mode) 调整 Iceberg Catalog 元数据检索方案。
+
+您可以通过以下 FE 配置项来设置 Iceberg 元数据缓存刷新行为：
+
+| **配置项**                                                    | **单位** | **默认值**                  | **含义**                                                    |
+| :----------------------------------------------------------- | :--- | :-------------------------- | :----------------------------------------------------------- |
+| enable_background_refresh_connector_metadata                 | 无   | true | 是否开启 Iceberg 元数据缓存周期性刷新。开启后，StarRocks 会轮询 Iceberg 集群的元数据服务（HMS 或 AWS Glue），并刷新经常访问的 Iceberg 外部数据目录的元数据缓存，以感知数据更新。`true` 代表开启，`false` 代表关闭。 |
+| background_refresh_metadata_interval_millis                  | 毫秒 | 600000（10 分钟）           | 接连两次 Iceberg 元数据缓存刷新之间的间隔。                     |
+| background_refresh_metadata_time_secs_since_last_access_sec  | 秒   | 86400（24 小时）            | Iceberg 元数据缓存刷新任务过期时间。对于已被访问过的 Iceberg Catalog，如果超过该时间没有被访问，则停止刷新其元数据缓存。对于未被访问过的 Iceberg Catalog，StarRocks 不会刷新其元数据缓存。 |
+
+## 附录：元数据周期性后台刷新方案
+
+元数据周期性后台刷新方案是 StarRocks 用于加速检索 Iceberg Catalog 中元数据的策略。
+
+自 v3.3.3 起，StarRocks 优化了 Iceberg 元数据的缓存机制，针对不同元数据使用场景，分别设定了不同检索方案。
+
+- **针对大体量元数据的分布式方案**
+
+  为了有效处理大体量元数据，StarRocks 通过多 BE/CN 节点实现分布式元数据检索方案。该方案利用现代查询引擎的并行计算能力，可以将读取、解压和过滤 Manifest 文件等任务分布在多个节点上。通过并行处理这些 Manifest 文件，可以显著减少元数据检索所需的时间，从而加快作业计划的速度。该方案对涉及大量 Manifest 文件的大型查询特别有利，因为可以消除单点瓶颈，提高整体查询执行效率。
+
+- **针对小体量元数据的本地方案**
+
+  对于小型查询，由于反复解压和解析 Manifest 文件会引入不必要的延迟，StarRocks 采用了一种不同的策略。StarRocks 会将反序列化后的内存对象（尤其是 Avro 文件）缓存下来，以应对延迟问题。通过将这些反序列化的文件缓存在内存中，系统可以在后续查询中跳过解压和解析阶段，直接访问所需的元数据。这种缓存机制显著减少了检索时间，使系统响应更快，更能满足高查询需求和物化视图改写的要求。
+
+- **自适应的元数据检索方案（默认）**
+
+  默认设置下，StarRocks 可以根据各种因素自动选择合适的元数据检索方法，包括 FE/BE/CN 节点的数量、核心数以及当前查询所需读取的 Manifest 文件数量。这种自适应的方法确保系统可以动态优化元数据的检索，无需手动调整元数据相关的参数。通过该方案，StarRocks 能在不同条件下平衡分布式和本地方案，实现最佳的查询性能，为用户提供无缝体验。
+
+您可以通过系统变量 [`plan_mode`](../../sql-reference/System_variable.md#plan_mode) 调整 Iceberg Catalog 元数据检索方案。
+>>>>>>> c15d401a72 ([Doc] Update iceberg_catalog.md (#52548))

docs/zh/quick_start/iceberg.md

@@ -3,6 +3,7 @@ displayed_sidebar: docs
 sidebar_position: 3
 description: "湖仓分析"
 toc_max_heading_level: 2
+keywords: ['iceberg']
 ---
 import DataLakeIntro from '../_assets/commonMarkdown/datalakeIntro.md'
 import Clients from '../_assets/quick-start/_clientsCompose.mdx'