1. 课程导入

在金融行业的数据平台建设中，湖仓一体架构已经成为承接实时风控、反洗钱、客户画像、监管报送与经营分析的核心底座。与互联网场景相比，金融湖仓的数据链路更长、合规约束更强、批流混合更普遍，任何一次写入抖动都可能被下游的报表、模型和监管口径放大。小文件问题正是其中最容易被低估、却最频繁引发连锁反应的一类工程隐患。

一、为什么金融湖仓会“长”出大量小文件

小文件并不是某一次错误操作造成的，而是多种写入模式叠加后的必然结果。理解其成因，是后续治理方案设计的前提。

• 流式写入的微批提交：Flink、Spark Structured Streaming 等引擎通常以秒级或分钟级 checkpoint 触发提交，每个微批都会在表目录下生成新的数据文件与元数据文件。
• 分区粒度与数据分布不匹配：按业务日期、机构、渠道、产品等多级分区后，单个分区内实际数据量可能只有几十 KB，却仍会生成独立文件。
• 频繁的增量覆盖与回补：金融场景中 T+1 补数、差错重跑、监管口径调整非常常见，每次 overwrite 或 merge 都会留下新的文件版本。
• 多引擎并发写入：离线 Spark、实时 Flink、交互式查询引擎同时写入同一张表，各自按自身策略提交，进一步碎片化。
• 元数据膨胀：Hive Metastore、Iceberg Catalog 或 Delta Log 中记录的文件条目快速增长，规划与列举开销显著上升。

二、小文件对金融业务的真实影响

在金融场景中，小文件带来的代价往往以“业务可感知”的方式出现，而不仅是技术指标恶化。

因此，小文件治理不是单纯的存储优化，而是金融湖仓稳定性、时效性与合规性的共同要求。

三、核心概念：Compaction 与相关机制

本课程围绕“治理”与“Compaction”展开，需要先建立统一的概念坐标系。

• 小文件：通常指显著小于目标文件大小（如 128MB 或 256MB）的数据文件，具体阈值需结合引擎与存储特性确定。
• Compaction（合并）：将多个小文件重写为较少、较大的文件，同时保持数据逻辑不变的过程。
• Major / Minor Compaction：Minor 合并部分增量文件，Major 合并全量或大范围文件，代价与收益不同。
• Bin-packing：按目标大小将小文件打包成大文件，常用于 Iceberg、Delta 等表格式。
• Sort / Z-Order Compaction：在合并同时进行排序或聚簇，提升后续查询的裁剪效率。
• 快照与保留策略：Compaction 会产生新快照，需要配合 expire snapshots 控制元数据与存储增长。

四、整体课程框架与学习目标

本课程共 30 章，按照“问题认知—原理机制—方案设计—实战落地—复盘优化”的路径展开，帮助你把零散经验转化为可复用的治理体系。

1. 认知与诊断：理解小文件成因、影响与度量方法，能够定位问题表与问题分区。
2. 原理与机制：掌握 Iceberg、Hudi、Delta 等表格式的 Compaction 原理与差异。
3. 方案与参数：学习目标文件大小、触发阈值、并发度、调度窗口等关键参数设计。
4. 实战与工具：通过 Spark、Flink、SQL 与调度平台完成 Compaction 作业开发与上线。
5. 复盘与优化：建立监控指标、成本评估与持续治理机制，避免问题反弹。

完成本课程后，你应当能够独立设计一套适配金融湖仓的小文件治理方案，并在真实生产环境中落地、验证与迭代。

五、一个典型金融场景的直观认识

假设某银行实时风控表按“业务日期 + 机构 + 渠道”分区，Flink 每 1 分钟提交一次微批。一天内单分区可能产生上千个小文件，下游 Spark 报表需要扫描数万个文件。此时查询计划阶段的文件列举就可能耗时数十秒，任务启动后 Task 数量远超实际数据量所需。

-- 典型的小文件分布查询（以 Iceberg 为例）
SELECT
  partition,
  count(*) AS file_count,
  avg(file_size_in_bytes) / 1024 / 1024 AS avg_mb
FROM db.table.files
GROUP BY partition
ORDER BY file_count DESC
LIMIT 20;

通过这类查询可以快速识别“文件数量多、平均体积小”的分区，作为 Compaction 的优先目标。后续章节会在此基础上展开完整的诊断与治理流程。