📚 课程目录第1章课程导入

1. 课程导入

欢迎进入《Apache Iceberg金融湖仓建模实战》。在开始写第一张Iceberg表之前，我们需要先建立一张“全局地图”：金融行业的数据平台为什么正在从传统数仓走向湖仓一体？Iceberg在这条演进路径中究竟解决了什么问题？本课程后续30章会围绕哪些能力展开？这一章不涉及复杂代码，但它是后续所有建模决策的起点。

一、金融湖仓的现实背景：从“报表仓库”到“实时资产”

金融行业的数据平台长期以集中式数仓为核心，支撑监管报送、财务报表、风险计量和客户分析。但随着业务变化，传统模式面临三个结构性压力：

数据时效性要求提升：风控、反欺诈、实时营销要求分钟级甚至秒级可见，T+1批处理难以满足。
数据形态多样化：除了结构化交易数据，还有日志、埋点、影像元数据、图关系数据，传统数仓扩展成本高。
存算分离与成本压力：对象存储（如S3、OSS、HDFS）成本低、扩展性好，但缺乏事务、Schema演进和快照能力。

湖仓一体的核心思路是：在低成本对象存储之上，叠加表格式（Table Format）能力，让数据湖具备数仓级的事务、Schema管理和查询性能。Apache Iceberg正是这一层表格式的事实标准之一。

  金融湖仓不是“把数仓搬到湖上”，而是重新定义数据的分层、更新、审计与消费方式。Iceberg负责“表”的语义，计算引擎负责“算”的能力，存储负责“放”的成本。

二、Iceberg核心价值：为什么金融场景尤其需要它

Iceberg的价值可以归纳为四个关键词：快照、演进、隐藏分区、开放。对金融行业而言，这些能力直接对应监管审计、模型迭代和多引擎协作需求。

能力	技术含义	金融场景价值
快照与时间旅行	每次提交生成不可变快照，可查询历史版本	监管回溯、对账差异定位、数据版本审计
Schema演进	支持加列、改类型、重命名，不重写全量数据	业务字段频繁调整，模型迭代不停机
隐藏分区与分区演进	分区对用户透明，可变更分区策略	避免分区字段暴露，支持按日期/机构灵活重组
开放格式与多引擎	Spark、Flink、Trino、Hive均可读写同一张表	批流一体、避免数据孤岛和重复搬迁

下面这张图展示了金融湖仓中Iceberg所处的位置：它位于计算引擎与对象存储之间，向上提供表语义，向下管理文件与元数据。

三、方法流程：金融湖仓建模的典型工作流

在后续章节中，我们会反复使用一条标准工作流。这里先给出整体轮廓，帮助你建立“从需求到表”的路径感：

需求分层：区分ODS、DWD、DWS、ADS层，明确每层的数据粒度和更新频率。
表设计：确定分区策略、排序键、文件大小目标、Schema演进预留字段。
写入模式：选择追加、覆盖、合并（MERGE）或CDC入湖，配置提交间隔与并发控制。
维护治理：执行小文件合并、快照过期、孤儿文件清理、元数据重写。
消费与审计：通过时间旅行对账，通过标签（Tag）固定监管版本，通过分支（Branch）隔离实验。

金融场景中，“可追溯”比“快”更重要。Iceberg的快照和标签机制，让每一次数据变更都有据可查，这是传统Hive表难以做到的。

四、案例场景：一个典型的金融湖仓需求

假设某银行需要构建“客户资产视图”，数据来自核心交易系统、理财系统和信贷系统。传统做法是每天凌晨跑批，将三份数据抽取到数仓后做全量关联。问题在于：

交易数据延迟导致资产视图滞后，客户经理上午看到的可能是昨天的余额。
理财系统字段频繁新增，每次加字段都要重跑全量历史数据。
监管要求保留每月末的资产快照，用于回溯审计。

使用Iceberg后，可以这样设计：

-- 创建客户资产明细表（示意）
CREATE TABLE lakehouse.dwd_customer_asset (
  customer_id   BIGINT,
  asset_type    STRING,
  balance       DECIMAL(18,2),
  update_time   TIMESTAMP,
  dt            DATE
)
USING iceberg
PARTITIONED BY (dt, bucket(16, customer_id))
TBLPROPERTIES (
  'write.target-file-size-bytes' = '134217728',
  'write.merge.mode' = 'copy-on-write'
);

-- 每月末打标签，固定监管快照
ALTER TABLE lakehouse.dwd_customer_asset
CREATE TAG audit_20250131
AS OF TIMESTAMP '2025-01-31 23:59:59';

这样，日常查询走最新快照，监管审计走标签快照，字段演进通过ALTER TABLE ADD COLUMN完成，无需重写历史数据。

五、常见误区与复盘

误区一：把Iceberg当成数据库。Iceberg是表格式，不提供计算和存储服务。它需要搭配Spark、Flink等引擎使用，不能单独“启动”一个Iceberg。

误区二：分区越多越好。金融数据中按机构、产品、日期多重分区会导致小文件爆炸。应优先使用隐藏分区和分桶，控制文件数量。

误区三：忽略元数据维护。快照和清单文件会持续增长，必须定期执行expire_snapshots和rewrite_manifests，否则查询性能会下降。

复盘来看，Iceberg在金融湖仓中的成功落地，依赖三个条件：合理的分层建模、稳定的写入模式、持续的元数据治理。这也是本课程后续章节的主线。

六、学习目标与整体框架

完成本课程后，你将能够：

理解Iceberg的元数据结构和快照机制，能解释一次写入背后发生了什么。
根据金融业务需求设计ODS到ADS的分层表，选择合适的分区、排序和文件策略。
使用Spark和Flink完成批流一体的Iceberg写入，处理MERGE、CDC和小文件问题。
执行快照过期、标签管理、分支实验和元数据重写等治理操作。
排查常见的写入冲突、查询变慢和元数据膨胀问题。

课程整体分为六个模块：基础原理、表设计、写入与更新、查询与优化、治理与运维、综合实战。每一章都会围绕一个可落地的金融场景展开，最终带你完成一个完整的金融湖仓建模项目。