Apache Iceberg 与 Delta Lake

• 理解 Iceberg 的三层元数据结构
• 掌握 schema/partition 演进不需重写数据的原理
• 认识快照与 ACID 语义

Iceberg 用三层元数据组织数据：table metadata（表元数据，含 schema、partition spec、snapshot 列表）、manifest list（快照内文件清单，指向 manifest file）、manifest file（记录每个 data file 及其列级统计、分区、删除信息）、data file（实际数据文件）。每次写入生成新快照，只需新增 manifest，无需重写已有数据文件。因此 schema 演进（加列、改列）与 partition 演进（改分区 spec）只需更新元数据，历史数据文件按新 spec 读取时按需处理，实现"演进不重写数据"。

三层结构把"数据文件"与"元数据"解耦，快照不可变（immutable），演进通过元数据变更完成。这使得 Iceberg 支持时间旅行、schema/partition 演进与 ACID 提交，是湖仓的核心能力。

• 理解 Iceberg v2 的 row-level delete 机制
• 掌握 positional delete 与 equality delete 的差异
• 认识 upsert 与删除语义

Iceberg v2 引入行级删除能力，用于支持 UPDATE/DELETE/MERGE。positional delete 记录被删除行的文件路径与行号（position），删除粒度精确、读取时需额外合并；equality delete 记录被删除行的主键/等值列值，删除时可对任意满足条件的行，适合按主键删除，但读取时需对文件做等值匹配。两者都通过 manifest 标记删除，不直接修改原 data file，配合 compaction 可清理被删数据。

行级删除让 Iceberg 在不修改不可变数据文件的前提下表达删除。positional 精确但需行号，equality 灵活但读取需匹配，二者是 v2 支持 update/delete 的关键。

• 理解 Delta 事务日志（_delta_log）结构
• 掌握 checkpoint 的加速作用
• 认识 ACID 控制在湖上的实现

Delta Lake 在表目录的 _delta_log 下记录每个事务的 JSON 文件（如 00000000000000000000.json），每个文件是一个原子提交，记录新增/删除文件、schema、commit 元数据等。读取时按版本号顺序回放 JSON 得到当前表状态。为提高效率，Delta 定期生成 checkpoint（parquet 快照），把到某版本为止的事务合并成一份状态，读取时先加载 checkpoint 再回放增量，加速表扫描。这套日志让 Delta 在数据湖上实现 ACID 与版本控制。

_delta_log 是 Delta 的"红宝书"，用 JSON 事务 + checkpoint 实现多写入者原子提交与版本控制。checkpoint 是性能优化，避免每次全量回放日志。

• 理解 OPTIMIZE 的小文件合并
• 掌握 Z-ORDER 的多维排序布局
• 认识数据文件剪枝与谓词下推

OPTIMIZE 是 Delta 的合并命令，把多个小文件合并为较大文件，减少文件数量与元数据开销，提升读取效率。Z-ORDER 是在 OPTIMIZE 时按多个列做空间填充曲线（Z-ordering）排序，使相关列值在文件间聚集，从而让查询过滤时能更精准地跳过无关文件（数据跳跃/文件剪枝），尤其适合多列组合过滤的查询。OPTIMIZE 提升总体性能，Z-ORDER 提升特定过滤模式下的剪枝效果。

OPTIMIZE 解决文件规模问题，Z-ORDER 解决文件局部性问题。Z-ORDER 通过多维排序让相似数据聚集，配合统计信息做文件剪枝，是 Delta 优化查询的关键手段。

• 理解 Change Data Feed 的用途
• 掌握 enableChangeDataFeed 配置
• 认识变更流向下游

Delta Lake 的 Change Data Feed（CDF）提供表级 row-level 变更流，可捕获 INSERT/UPDATE/DELETE 事件。在表属性中设置 enableChangeDataFeed=true（或用 ALTER TABLE 开启）后，Delta 会在每次提交时记录变更数据，通过读 _change_data 目录或 table_changes 函数查询指定版本区间的变更。下游可据此做增量同步、变更捕获、实时数仓，无需全量扫描。

CDF 把 Delta 的内部变更以可读形式暴露，是 CDC 能力的湖上实现。开启后每次提交记录变更，供下游按版本增量消费。

• 理解 COW 与 MOR 的写入/读取机制
• 掌握两种表类型的适用场景
• 认识读写权衡

COW（Copy On Write）在写入时直接重写包含受影响行的数据文件，更新立即生效，读取无需合并，读性能好，但写入放大高、更新延迟大，适合读多写少、更新不频繁的场景。MOR（Merge On Read）把更新先写入增量 log 文件，读取时合并 base 文件与 log，写入快、延迟低，但读需合并 log 导致读性能下降，适合写多读少、更新频繁的场景。Hudi 通过 min_commits/compaction 定期把 log 合并进 base 文件来平衡。

COW 与 MOR 是"写时重写"vs"读时合并"的经典取舍。COW 读优写慢，MOR 写优读慢，选择取决于报表的读写比与更新频率。

• 理解 Hudi 索引在 upsert 中的作用
• 掌握 bloom_filter、simple、global_bloom 的差异
• 认识索引开销与效率

Hudi 的索引用于 upsert 时定位某条记录是否已存在。bloom_filter 索引在文件级维护 bloom filter，快速判断主键可能落在哪个文件，本地（按文件）高效；simple 索引记录主键到文件的映射，简单直接但内存/存储开销随量增大；global_bloom 把 bloom filter 扩展到全局，跨分区定位更准确，但维护成本高。选择时需权衡查询效率、内存占用与更新频率。

索引类型决定 upsert 定位既有记录的速度。bloom_filter 用近似判断换取文件剪枝，simple 用精确映射换简单，global_bloom 用全局准确性换更高维护成本。

• 理解三者的核心优势
• 掌握各自的适用场景
• 认识生态与特性差异

三者定位各有侧重：Iceberg 以强 schema/partition 演进、不可变快照、ACID 与多引擎支持著称，适合作为通用、中立的开放湖表格式；Delta Lake 依托 Databricks 的 Unity Catalog 生态，强调表格式、数据治理与流批一体，深度集成 Spark；Hudi 则强调增量计算与流式能力，支持 CDC、增量查询、MOR/COW 与 upsert，适合数据入湖与增量管道。选型取决于团队生态（Spark/Databricks）、对演进与增量计算的需求。

三者都是湖表格式，但定位不同：Iceberg 中立开放、Delta 绑定 Databricks 生态、Hudi 强增量。理解差异利于按需选型。

• 理解 Trino 的 connector/SPI 架构
• 掌握多数据源联邦查询
• 认识 connector 的职责

Trino（前身 PrestoSQL，由 Presto 项目分叉而来）采用 connector 插件架构，每种数据源对应一个 connector，通过统一的 SPI 接口实现元数据、数据读取与下推。用户可同时配置 Hive、Iceberg、Delta Lake、Kafka、MySQL/PostgreSQL 等多个 connector，用 SQL 跨源联邦查询。connector 负责把 Trino 的算子映射到对应源的读取方式，并支持谓词下推等优化，使单一 SQL 引擎能统一访问多种异构数据源。

connector 是 Trino 的扩展点，把"查询引擎"与"数据源"解耦。30+ connector 让 Trino 成为联邦查询/跨源分析的统一入口。

• 理解 CBO（基于成本优化）的原理
• 掌握 join 顺序与代价估算
• 认识统计信息的作用

Trino 的 CBO（Cost-Based Optimizer）利用表的统计信息（行数、列基数、分布、null 比例等）估算各 join 顺序与执行策略的代价，选择代价最小的执行计划。例如对小表做大表关联的 join 时，CBO 可选择 build 侧为小表的 hash join，或调整 join 顺序（如 reorder、repeated join）以减少中间结果大小。统计信息越准确，CBO 选择越优，从而显著提升复杂 join 查询性能。

CBO 的核心是"用统计信息估代价"。join 顺序决定中间结果规模，是性能关键。CBO 通过行数/基数估算选择最优顺序，是查询优化器成熟度的标志。

• 理解 Doris 的 Unique Key 表模型
• 掌握主键覆盖写机制
• 认识 upsert 在实时更新场景

Doris 的 Unique Key（唯一键）模型中，同一主键（唯一键）仅保留最新一条数据，批量导入时按主键去重，新数据覆盖旧数据，从而实现 upsert（更新或插入）语义。该模型适合订单、用户等需要按主键更新的实时写入场景。Doris 通过存储层的合并（compaction）与查询时按主键取最新版本来保证"只保留最新"。

Unique Key 模型用"主键覆盖"实现 upsert，是 Doris 面向实时更新场景的设计。相比 Duplicate/聚合模型，它保证主键唯一且取最新。

• 理解向量化执行引擎
• 掌握 CBO 在 Doris 中的作用
• 认识 OLAP 性能优化

Doris 2.x 全面支持向量化执行引擎，按列批量处理数据，利用 CPU 缓存与 SIMD 指令大量减少虚函数调用与逐行开销，显著提升分析查询吞吐。同时强化 CBO（基于成本优化），基于统计信息优化 join 顺序、选择物化视图与执行策略，提升复杂查询性能。两者结合让 Doris 在 OLAP 场景的处理能力大幅增强。

向量化执行（列式批量处理）与 CBO 是现代 OLAP 引擎的两大支柱。Doris 2.x 补齐这两项，是性能提升的关键。

• 理解 StarRocks 与 Doris 的渊源
• 掌握 CBO 与向量化执行
• 认识 StarRocks 的定位

StarRocks 曾是 Apache Doris 的一个分支，后独立演进，专注于高性能 OLAP。它采用代价优化器（CBO）与向量化执行引擎，并采用列式存储，支持明细模型、聚合模型、更新模型等多种建模方式。在 join、聚合、窗口函数等场景通过向量化执行与 CBO 优化实现高吞吐低延迟查询，同时支持物化视图自动改写加速。

StarRocks 与 Doris 同源但独立演进，都属于 MPP 列式 OLAP。CBO + 向量化执行是其高性能的核心手段。

• 理解 CBO 的代价估算
• 掌握 join 顺序优化
• 认识执行计划生成

StarRocks 的 CBO 基于统计信息（行数、NDV、分布等）为查询生成多个候选执行计划，估算各计划的代价（IO、CPU、网络），选择代价最小的执行计划。它优化 join 顺序（把小表放 build 侧、重排 join 树）、选择 join 算法（hash/broadcast/shuffle）、决定聚合与排序策略，从而显著减少中间结果与数据重分布，提升复杂查询性能。

CBO 通过"枚举候选计划 + 代价比较"选优。join 顺序与执行策略是高维度组合，CBO 利用统计信息找出近似最优，是 StarRocks 优化复杂查询的基石。

• 理解物化视图的概念
• 掌握自动改写（rewrite）机制
• 认识查询加速

StarRocks 支持物化视图，把预计算的聚合/join 结果物化为实体表。查询时优化器若识别到查询模式与某物化视图匹配，会自动改写为从物化视图查询，从而避免实时重算，加速查询。自动改写基于查询谓词、聚合函数与物化视图定义的对齐匹配，支持透明加速，无需用户改 SQL。物化视图数据由后台定时或基于事件刷新。

物化视图自动改写是"用预计算换查询性能"。优化器透明地把查询改写为物化视图访问，用户无感，是 StarRocks 缩短查询的关键能力。

• 理解 Iceberg 快照与版本
• 掌握 snapshot-id / timestamp 回溯
• 认识历史数据查询

Iceberg 每次写入生成一个不可变快照（snapshot），表元数据维护快照列表。Time Travel 允许通过指定 snapshot-id 或 timestamp（AS OF）查询历史版本的数据，实现版本回溯、数据审计与"回滚到某时间点"。由于数据文件不可变 + 快照链，历史版本可被任意读取，只要快照未被清理。这为数据恢复与审计提供了强大能力。

不可变快照是 Time Travel 的基础。查询指定 snapshot-id/timestamp 即可读到对应历史数据，无需复制，是湖表格式的独特价值。

• 理解 partition spec 演进
• 掌握旧数据按旧 spec 读取
• 认识分区演进的优势

Iceberg 支持分区规范演进（partition spec evolution），即在不重写已有数据文件的情况下改变分区策略。新写入的数据按新 spec 分区，旧数据沿用旧 spec；表元数据记录多个分区 spec，读取时对每个文件按对应 spec 的列对齐。这样加分区、改分区粒度等演进无需重写历史数据，避免昂贵的全表重写，实现分区策略的动态调整。

分区演进是 Iceberg 的独特能力。它通过"多 spec 并存 + 按文件匹配 spec"让新旧分区共存，避免重写数据，显著降低演进成本。

• 理解 REST Catalog 的架构
• 掌握跨引擎共享元数据
• 认识统一目录接口

Iceberg REST Catalog 以 REST API 形式暴露目录服务，统一管理表的元数据、schema、快照与提交。Spark、Flink、Trino 等引擎通过 REST 客户端访问同一目录服务，实现元数据共享与协同提交，避免各引擎各自维护一份元数据导致不一致。REST Catalog 成为 Iceberg 跨引擎的标准接口，支持多引擎在同一张表上读写与演进。

REST Catalog 把元数据服务化，是跨引擎协作的关键。它让多引擎共享同一快照与提交流程，保证一致性，是 Iceberg 生态标准化的产物。

• 理解 Delta UniForm 的概念
• 掌握 Iceberg/Parquet 兼容
• 认识多格式互操作

Delta Lake 3.x 引入 Delta UniForm，让同一份 Delta 表同时暴露为 Iceberg 与 Hudi 表格式（通过 Parquet 作为统一存储格式），使 Iceberg/Hudi 生态的引擎也能读取 Delta 表。UniForm 在写入时同步维护 Iceberg 元数据，无需复制数据，实现"一份数据、多格式可读"，解决湖表格式互操作与生态割裂问题。

UniForm 通过"共享 Parquet 数据 + 按需生成各格式元数据"实现多格式兼容。它让 Delta 表能被 Iceberg/Hudi 引擎读取，降低数据复制与锁定成本。

• 理解 Delta 版本控制
• 掌握 VERSION AS OF / TIMESTAMP AS OF
• 认识历史数据查询

Delta Lake 基于事务日志维护版本，Time Travel 允许通过 VERSION AS OF（指定版本号）或 TIMESTAMP AS OF（指定时间戳）读取历史版本的数据。Delta 通过日志确定该版本对应的文件列表，重建历史快照。这用于数据审计、误操作恢复、历史趋势分析等场景。前提是历史文件未被清理（如未执行 VACUUM）。

事务日志让 Delta 能按版本重建任意历史状态。VERSION/TIMESTAMP AS OF 是查询入口，VACUUM 会清理历史文件从而限制可回溯范围。

• 理解 Hudi timeline 结构
• 掌握 commit/clean/replace 事件
• 认识元数据与时间线

Hudi 在表目录的 .hoodie 下维护 timeline（时间线），按时间顺序记录表的所有操作事件，包括 commit（提交写入）、clean（清理旧文件）、replace（替换/压缩）、rollback（回滚）、indexing 等。每个事件对应一个时间戳文件，记录受影响文件与元数据。timeline 是 Hudi 的"事务日志"，用于版本控制、增量查询与故障恢复，驱动 Hudi 的增量计算能力。

timeline 是 Hudi 实现 ACID 与增量计算的基础。它把所有变更按时间线记录，支持时间旅行、增量读取与 recover。

• 理解 record-level index
• 掌握 Flink 集成
• 认识 upsert 加速

Hudi 0.14+ 引入 record-level index（0.13 及以前只有文件级索引），在文件内维护记录级主键映射，相比文件级索引能更精确地定位记录所在文件，避免扫描整个文件，提升 upsert 定位既有记录的速度。这与 Flink 集成配合，Flink 的 Hudi 写入器可利用 record-level index 高效处理 upsert 与去重，支持流式写入与状态化更新，提升性价比。

record-level index 细化索引粒度，让 upsert 定位更快。与 Flink 的流式写入结合，支撑高频率更新与去重场景。

• 理解 Hudi 与 Flink 的集成
• 掌握流式读取/写入
• 认识增量处理

Hudi 与 Flink 深度集成，支持流式写入（Streaming Write）与流式读取（Streaming Read）。Flink 可把 Hudi 作为 sink 持续写入，也可作为 source 持续读取 Hudi 的新增/变更数据（基于 timeline 的增量查询），实现端到端流式管道。Hudi 的增量查询能力让 Flink 能按提交时间消费变更，支持实时入湖、流式 ETL 与近实时分析。

Hudi 的增量语义 + Flink 的流式引擎，让"湖上实时计算"成为可能。Streaming Query 依赖 timeline 的增量读取能力。

• 理解三者的 catalog 架构
• 掌握 REST Catalog 的标准化
• 认识跨引擎互操作趋势

Iceberg、Delta、Hudi 各有自己的 catalog/元数据管理方式，早期互不互通，导致同一数据被多个格式锁定。Iceberg 提出 REST Catalog 作为标准元数据接口，通过 REST API 统一管理元数据，使 Spark/Flink/Trino 等引擎经同一接口访问；Delta 的 UniForm、Hudi 也在向兼容靠拢。REST Catalog 因其跨语言、跨引擎、可部署为服务而成为标准接口，推动三者在 catalog 层互通。

catalog 互通是湖表格式走向统一的关键。REST Catalog 以标准 HTTP 接口解耦引擎与元数据，成为跨格式/跨引擎协作的事实标准。

• 理解三者的 time travel 机制
• 掌握 schema enforcement 的差异
• 认识语义差异的实际影响

三者都支持 time travel 与 schema 约束，但实现有差异：Iceberg 通过不可变快照 + snapshot-id/timestamp 实现 time travel，schema 演进可加列/删列；Delta 通过事务日志版本 + VERSION/TIMESTAMP AS OF 实现 time travel，schema 默认严格（新增列需显式）；Hudi 通过 timeline 时间线实现增量/时间旅行，schema 演进与 upsert 结合。三者对 schema 演化（如类型变更、列删除）的严格程度与 time travel 的回溯粒度不同，需按引擎实际行为处理。

语义差异源于各自元数据模型。Iceberg 快照不可变最灵活，Delta schema 严格，Hudi 时间线导向增量。理解差异避免迁移陷阱。

• 理解 Coordinator/Worker 分工
• 掌握 Worker 弹性扩容
• 认识 SPI 注册 connector

Trino 采用 Coordinator/Worker 架构，Coordinator 负责解析、规划与调度，Worker 负责执行任务。Worker 无状态，可随时加入/退出集群，通过心跳向 Coordinator 注册并接收任务，从而实现弹性扩容。Worker 通过 SPI（插件接口）加载 connector 插件，动态注册可访问的数据源，启动时扫描 connector 插件并初始化，使集群可灵活接入多种数据源。

Coordinator/Worker 分离 + Worker 无状态是弹性扩容的基础。SPI 让 connector 以插件形式注册，扩展数据源而不改内核。

• 理解 Presto 与 Trino 的分叉历史
• 掌握 Trino 的社区与演进
• 认识版本演进

Trino 与 PrestoDB 原为同一项目（Presto），因社区治理与方向分歧在 2018 年底分叉：原核心团队创建社区版并继续主导开发，即后来更名的 Trino（曾用名 PrestoSQL）；PrestoDB 则由 Facebook 等继续维护并纳入 Presto Foundation。Trino 因其活跃的核心团队、持续迭代（新 connector、性能优化、SQL 特性）与更开放的社区治理，成为社区主流，被广泛用于联邦查询与湖仓分析。

分叉后 Trino 保持活力源于核心团队持续开发与社区治理。版本与生态的活跃度决定主流地位。

• 理解 Manifest 与快照的关系
• 掌握 ACID 的文件级实现
• 认识原子提交与时间旅行

Iceberg 的 ACID 与时间旅行通过"不可变数据文件 + 元数据快照"实现。每次提交在 manifest 中记录新增/删除的数据文件，生成新的快照指针（snapshot），表元数据指向最新快照。提交时通过"比较并交换"（CAS）原子更新表元数据指针，多写入者只有一方成功，实现并发控制。时间旅行即读取任意历史快照对应的 manifest 与文件集合，无需复制数据。数据文件不可变，删除通过 manifest 标记，保证 ACID。

文件层 ACID 的核心是"不可变文件 + 元数据指针原子更新"。快照即 manifest 集合，提交即改指针，天然支持并发控制与时间旅行。

• 理解不可变文件的挑战
• 掌握更新在不可变文件上的实现
• 认识湖表格式的更新机制

数据湖底层文件不可变，但湖仓一体（Lakehouse）通过湖表格式（Iceberg/Delta/Hudi）在不可变文件之上实现更新语义：更新不修改原文件，而是写新文件，并在元数据中标记旧文件被删除/替换，通过快照指针切换实现"逻辑更新"。行级更新用 positional/equality delete 或 MOR log 表达。配合 compaction 定期合并清理旧文件，实现物理回收。这样既保留不可变文件的优势（可并发、可回溯），又支持更新。

更新与不可变文件的协调靠"写新弃旧 + 元数据切换"。湖表格式把逻辑更新映射为文件新增与删除标记，实现 ACID 更新的同时保持不可变优势。

• 理解 spill-to-disk 原理
• 掌握落盘目标（S3/HDFS）
• 认识大查询的内存管理

Trino 的 spill-to-disk 允许在内存不足时，将中间结果（如 join build 侧、聚合状态、排序数据）临时溢出落盘，避免查询因内存不足而失败。通过配置 spill 路径（本地磁盘或分布式文件系统如 S3/HDFS），Trino 把溢出数据写入该路径，查询结束后清理。这允许大查询以更少内存运行，代价是落盘与读回的 IO 开销，牺牲部分性能换取稳定性。

spill-to-disk 是用 IO 换内存。它让超内存查询通过落盘继续执行而非失败，是 Trino 处理大查询/内存受限环境的关键容错机制。

• 理解 COW/MOR 的更新机制
• 掌握 Iceberg v2 的更新语义
• 认识删除/合并实现差异

Hudi 的 COW 在更新时重写受影响文件，更新立即对读可见；MOR 把更新先写入 log，通过 compaction 合并，读时需合并。Iceberg v2 的更新通过写新文件 + positional/equality delete 标记旧行，读取时合并 delete 文件，也支持 MERGE 操作。差异在于：Hudi 主动提供 COW/MOR 两种读改写策略，Iceberg 用 delete 文件 + 快照实现统一更新；Hudi 更强调 upsert 与 COMPACTION 自动化，Iceberg 更强调快照与元数据演进。两者语义上都能实现最终一致的更新，但工程机制不同。

两者都实现"逻辑更新"，但 Hudi 用 COW/MOR 显式选择读写权衡，Iceberg 用 delete 文件 + 快照统一表达。理解差异便于选型。