1、数据越来越多，管理成本也在涨？
每张 Iceberg 表在持续写入的过程中，小文件会悄悄堆积，历史快照越来越多，查询性能慢慢下滑，存储成本也越来越高。手动写 Spark 脚本合并小文件、定期清理快照、琢磨冷数据怎么处理，这些事情做过的人都知道有多琐碎。阿里云瑶池旗下的云原生数据仓库 AnalyticDB MySQL版（以下简称ADB）推出的 Iceberg 表优化服务（Table Service），就可以把这些工作自动化完成：在控制台配好策略，剩下的交给系统。
2、Table Service 能做什么？
表优化服务从查询提速和存储降本两个方向优化 Iceberg 表的使用体验。
查询提速
🔔 小贴士：Bitmap 索引适合高基数列（用户 ID、订单号等），主要加速等值和 IN 查询，需要在控制台指定列。如果查询以范围扫描或聚合为主，小文件合并和排序优化更合适。
存储降本
一张订单表的日常
以一张日增数百万条的电商订单明细表为例，配置表优化服务后，系统会自动执行以下策略：
3、典型使用场景
场景一：存储降本
▶︎ 日志数据全生命周期管理
某业务每天持续写入约 500 GB 的日志类数据（应用日志、访问日志、行为埋点等），数据保留 1 年，统一存储在 ADB Iceberg 湖仓中。
在 ADB 控制台配置冷热分层 + 自动回收策略：
0-30 天 → 标准存储（高频读写，支撑实时看板和告警） 30-90 天 → 低频访问存储（偶尔查询，按需取回） 90-365 天 → 归档存储（几乎不访问，仅合规留存） > 365 天 → 自动删除（过期分区自动回收）
运行满一年后，各存储层数据量达到稳态：
不做分层时，全部标准存储月费为 22,426 元。冷热分层后年度存储费从 26.9 万降至 10.7 万，节省 16.2 万元（降幅 60%）。
数据量更大或保留更久，节省更显著：
保留周期越长、冷数据占比越高，降本效果越明显。
注：以上数据量为按日写入量直接累加的理论值，未计入 Parquet 列存压缩（实际存储占用通常更小，节省的绝对金额会相应缩小，但降本比例基本一致）。存储单价基于阿里云 OSS 中国大陆地区按量付费公开定价（标准存储 0.12 元/GB/月、低频 0.08 元/GB/月、归档 0.033 元/GB/月），实际费用请以OSS定价页为准。
归档数据并非“存了就不能用”。需要回查时一条 SQL 即可按需解冻：
-- 解冻去年双十一当天的日志，3 天内可查 CALL catalog.system.restore_files( table => 'log_db.app_logs', where => "dt = '2025-11-11'", days => 3 );
以解冻一天的数据（~500 GB）为例，归档取回费约 15 元，相比全量存标准存储每月多花的上万元，几乎可以忽略。
▶︎ 在降本的基础上进一步提速
冷热分层解决的是存储成本问题。如果对最近几天的热数据查询速度也有要求，可以再开启湖存储加速（LakeCache）缓存预热，把数据提前加载到本地缓存，查询走缓存而不是远程读 OSS。经测试，Spark 查询性能可提升约 3 倍。
LakeCache 按缓存数据量计费（0.002 元/GB/小时，约 1.44 元/GB/月）。以缓存最近 7 天的数据（约 3.5 TB）为例，月增加费用约 5,040 元，叠加分层存储的 8,947 元，总月费约 13,987 元，仍比不做分层的 22,426 元省了约 38%。
两者可以独立配置：只关心成本就开分层；对热数据延迟敏感，再叠加 LakeCache。
场景二：查询提速——元数据整理让查询快 10 倍
某业务每天持续写入约 200 GB 的数据，分析师通过 XIHE 引擎对近一周的数据做即席查询。
高频写入导致 Iceberg 表积累了大量 manifest 文件。实测发现，单次查询需要读取约 120 个 manifest 文件（每个 3~5 MB），仅查询规划阶段就要拉取近 600 MB 的元数据，这成了性能瓶颈。原因是每次导入生成的 manifest 里混杂着所有分区的条目，查任何一个分区都要扫描几乎全部 manifest。
Table Service 的元数据整理会将 manifest 条目按分区重新归类，不移动数据文件，只重新编排索引。整理后查询单个分区只需读取少量相关的 manifest，不再全量扫描。
配置好策略后自动执行，不需要人工介入。
4、技术延伸：自研 Bitmap 索引
以上都是在控制台配好就能用的能力。这一节聊点技术细节，说说我们为什么要在 Iceberg 上自研文件级 Bitmap 索引。
开源 Iceberg 内置的文件过滤靠的是列级别的 min-max 统计信息，只能跳过值域完全不匹配的文件。对于 user_id、device_id 这类高基数列，min-max 几乎没用，因为每个文件的值域都覆盖了查询目标值，最终还是全量扫描。开源社区目前也没有文件级的索引过滤方案。
ADB 自研的做法是：对指定列构建文件级 Bitmap 索引，记录每个值存在于哪些数据文件中。查询时引擎先查索引、跳过无关文件，再扫描命中的少量文件。
在典型场景测试中，一张包含 1349 个数据文件的业务表，针对 user_id 的等值查询，索引直接将扫描范围从全部文件收窄到 1 个，查询耗时从 4.2 分钟降到 1.8 分钟。在标准测试集（1 亿行、20 个日分区）上也能看到效果：
数据文件越多、值分布越分散，索引的过滤效果越好。上面那张 1349 个文件的表过滤到 1 个，是比较典型的高基数列场景。
设计上有几个值得一提的决策。索引按数据文件粒度构建，一个数据文件对应一个索引文件，查询时通过 Spark executor 并行加载，天然适配分布式场景。索引元数据纳入 Iceberg 的事务管理，并发写入不会出一致性问题。构建过程是增量的，只对新增数据文件补建索引，不需要每次全量重建。另外我们做了 fail-open 设计：索引出了问题就自动回退到非索引查询，查询本身不会报错。
-- 对 user_id 列创建索引 CALL catalog.system.create_index('db.table', 'user_id'); -- 查看已有索引 CALL catalog.system.show_index('db.table');
5、怎么用？
Table Service 已集成到 ADB MySQL 控制台，全程可视化操作，不需要写脚本。（灰度开放中，点击文末「阅读原文」即可提工单申请灰度测试）
1. 选择启用范围
支持多级配置继承，从实例到库到表，灵活控制粒度：
勾选"启用湖存储优化"，下级对象自动继承配置，也可以逐级自定义覆盖。
2. 配置优化策略
3. 查看效果在控制台可以看到每张表的优化执行历史：合并了多少文件、释放了多少空间、任务是否成功。配完策略之后就不用管了，系统按策略自动调度。
6、和手动维护的对比
7、谁适合用
当您的业务符合下面任意一种情况，ADB MySQL Iceberg表优化服务能直接帮你解决问题：
存储费用在涨，但不敢轻易降级。
冷数据继续放标准存储太浪费，转低频又怕查询变慢——冷热分层配合查询加速，正好能解这个「省钱还是保性能」的两难。
运维精力有限，不想持续维护优化脚本。
小文件合并、快照清理、排序优化这些琐事，做过的人都知道有多琐碎。配好策略后系统自动调度执行，基本不需要人工盯盘。
数据天然有明显的冷热特征。
日志分析、历史订单、审计记录、行为埋点……这类数据近期高频访问、历史偶尔查、过期后基本不用，分层存储和自动回收正好匹配这个生命周期。
若您已有 ADB MySQL 湖仓版/企业版/基础版集群的话，创建好 Spark 资源组，在控制台开启表自动优化服务即可使用。无需额外部署组件，无需编写运维脚本，也无需了解 Iceberg 的内部细节——配好策略，剩下的交给系统。
了解更多
Table Service 目前已在 ADB MySQL 湖仓版、企业版灰度上线。欢迎点击链接了解详情，如果您正在用 ADB + Iceberg，可以提交工单申请在控制台试用。
欢迎钉钉搜索群号：136815048471 或扫码加入“ADB湖存储表优化”交流群
