3. 湖仓一体核心概念

在金融历史行情场景中，数据量以 TB 级起步，且同时存在逐笔成交、快照行情、K 线聚合、因子指标、回测结果等多类数据。要理解湖仓一体，先要厘清三个基础概念：数据湖、数据仓库和 Lakehouse。它们不是简单的替代关系，而是围绕“存储成本、数据质量、计算灵活性”三者的不同取舍。

一、核心定义与本质差异

数据湖以低成本对象存储（如 S3、OSS、HDFS）为底座，采用“先存后治理”模式，原始数据以文件形式落地，Schema 在读时定义（Schema-on-Read）。它擅长承载海量原始行情、日志和半结构化数据，但缺乏事务、约束和高效元数据管理，容易退化为“数据沼泽”。

数据仓库采用“先建模后写入”模式，Schema 在写时定义（Schema-on-Write），强调强一致、ACID 事务和结构化 SQL 分析。它数据质量高、查询性能稳定，但存储与计算耦合、扩展成本高，对非结构化数据和半结构化行情适配较弱。

Lakehouse是在数据湖之上引入表格式（Table Format）与元数据层，使对象存储具备事务、Schema 演进、时间旅行等数仓能力。它既保留数据湖的低成本与开放性，又提供数仓级的数据管理与查询性能，是金融行情湖仓建设的主流形态。

二、表格式的核心机制

Lakehouse 的关键在于表格式层。它位于计算引擎与对象存储之间，用元数据文件记录“哪些数据文件构成一张表”，从而在文件之上实现事务、快照和 Schema 管理。目前主流的三类表格式机制如下：

• Delta Lake：以 _delta_log 事务日志为核心，每次提交生成一个 JSON 日志，记录新增/删除文件与元数据变更。支持 ACID、时间旅行、Schema 演进和 MERGE 更新，与 Spark 生态结合最紧密。
• Apache Iceberg：采用分层元数据（metadata file → manifest list → manifest file → data file），支持隐藏分区、分区演进和快照隔离。多引擎兼容性好，适合 Flink、Spark、Trino 混合查询。
• Apache Hudi：以时间线（Timeline）管理提交，区分 Copy-on-Write 与 Merge-on-Read 两种表类型。擅长增量写入和近实时更新，适合高频行情落湖与增量拉链。

三、选型对比与金融行情场景

在金融历史行情湖仓中，常见组合是：Hudi 承接逐笔与快照的增量入湖，Iceberg 承载多引擎因子与指标查询，Delta Lake 用于回测快照与实验版本管理。选型不应追求单一表格式统一，而应按数据写入频率、查询引擎和更新模式分层选择。

四、常见误区与复盘

-- Iceberg 小文件合并示例
CALL catalog.system.rewrite_data_files(
  table => 'market.tick',
  options => map('target-file-size-bytes','134217728')
);

-- Delta Lake 优化与清理
OPTIMIZE market.kline ZORDER BY (symbol, trade_date);
VACUUM market.kline RETAIN 168 HOURS;