湖仓一体总体架构

湖仓一体是什么

湖仓一体（Lakehouse）是在低成本对象存储之上，通过开放表格式（Iceberg / Hudi / Delta）实现 ACID 事务、Schema 治理与多引擎并发访问的新型数据平台架构。它保留了数据湖「海量、廉价、存原始数据」的底色，又把数据仓库数十年沉淀的事务与治理能力下沉到表格式层，用一份存储同时服务离线、实时、AI 与检索等全部负载。

开放表格式 对象存储 ACID 多引擎共享

从三代演进看湖仓的必然

数仓以「先建模、后装载」为核心：结构在写入时即被约束，质量与一致性极佳，报表生态成熟。但商业数据库按容量计费，扩容成本陡峭；封闭格式让数据「进得去、出不来」，ML 与探索类负载既贵又慢。

HDFS 与对象存储把每 GB 成本压到分级别，原始数据先落地、结构后解析，完美适配机器学习。但湖本质是文件目录：没有 ACID、没有并发控制、没有 Schema 约束，「数据沼泽」开始出现，企业不得不再建一套仓来救湖。

Iceberg 等开放表格式把元数据（schema、分区、快照）从引擎私有目录中解放出来，变成存储之上的「公共合同」：任何引擎按协议读写即可获得事务与演进能力。治理不再是仓的专属，湖第一次拥有了数据库级别的可靠性。

三大核心价值

下面这段配置展示了「多引擎共享」的落地面貌：三个引擎各写一份配置，却指向同一套元数据与数据文件：

# Trino catalog：etc/catalog/lakehouse.properties（挂载 Iceberg + Hive Metastore）
connector.name=iceberg
iceberg.catalog.type=hive_metastore
hive.metastore.uri=thrift://metastore.lake.local:9083
s3.endpoint=http://minio.lake.local:9000
s3.path-style-access=true

# Spark：同样指向这套元数据，无需任何数据导出或同步任务
spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions
spark.sql.catalog.lakehouse=org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.lakehouse.type=hive
spark.sql.catalog.lakehouse.uri=thrift://metastore.lake.local:9083
spark.sql.catalog.lakehouse.warehouse=s3://lakehouse/wh

# Flink：批与流共享同一份元数据与数据文件，分钟级写入对批读可见
sql.catalog.lakehouse.type=iceberg
catalog.lakehouse.type=hive
catalog.lakehouse.uri=thrift://metastore.lake.local:9083
catalog.lakehouse.warehouse=s3://lakehouse/wh

六层参考架构

本站全站结构都映射到这套六层参考架构。自上而下依次是：场景消费层 → 可观测性层 → 调度与资源层 → 计算与查询层 → 数据集成层 → 存储与表格式层。数据则自下而上流动：先落底座，再被加工、查询，最终在场景层产生业务价值。

业务价值的出口层，回答「平台最终为谁创造什么」。情报研判需要多源关联与图谱展开；AI 向量检索需要非结构化数据入湖与特征回填；时序与 GIS 需要专用索引。该层对下的核心诉求是统一的语义入口（视图/语义层）与细粒度权限——业务方只应面向「对象与指标」编程，而非面向底层表。对应章节：场景实战。

平台的「体检系统」。Prometheus 周期抓取 Spark、Flink、Trino、Iceberg 与 YARN 的指标暴露端口；EFK 汇聚各组件与业务日志；Grafana 出大盘；告警规则联动值班与调度层的失败重试。它向上承接调度层的任务级异常，向下覆盖所有组件的节点级异常，是「故障在业务感知之前被发现」的保障。对应章节：可观测。

平台的「神经系统」。DolphinScheduler 负责任务 DAG：依赖编排、定时触发、补数重跑、失败告警；YARN 负责资源：队列划分、CPU/内存配额、弹性调度。它把计算层成百上千的作业组织成可信的生产流水线，并把集群资源公平地分配给多租户。对应章节：调度资源。

湖仓的「双引擎矩阵」。Spark 承接大规模离线加工与 ML 训练；Flink 承接实时计算与 CDC 流式入湖；Trino 提供交互式联邦查询；Doris 服务实时多维 OLAP；ClickHouse 专攻日志与时序扫描。它们对上满足场景层的算力需求，对下通过统一 Catalog 读写同一份 Iceberg 数据——引擎之间是「分工」而非「搬运」。对应章节：计算层、查询层。

数据的「入湖口」。Kafka 缓冲高吞吐消息流并支持重放；Flink CDC 直连业务库订阅 binlog 实现增量入湖；DataX/SeaTunnel 承接异构批量同步。该层对上把数据交给计算层加工或直接落地表格式，对下把 Parquet 文件写入对象存储并在 Metastore 注册元数据——集成层的稳定与时效决定了整个平台的「数据鲜度」。对应章节：数据集成。

全平台唯一可信底座。对象存储（HDFS 或 MinIO 兼容 S3）提供廉价、高可用的文件底座；Parquet 提供高压缩比列存布局；Iceberg 在文件之上维护元数据树并提供快照、ACID、Schema 演进与隐藏分区；Hive Metastore 作为统一元数据中心被所有引擎共享。所有上层组件都经由开放协议访问它——这是「换引擎不搬数据」的根本保证。对应章节：存储层。

六层全景与层间数据流如下（箭头方向表示数据自下而上流动）：

批流一体设计

「批还是流」是流式计算十几年的路线之争。Lambda 与 Kappa 给出了两代经典答案，而湖仓时代在存储层给出了第三种：

湖仓时代批流一体的核心思路：不再在引擎层强行统一批与流，而是在存储层用 Iceberg 作为批与流的共同落地形态——Flink 以小文件 + 快照提交的方式流式写入，数据在分钟级对批侧可见；Spark / Trino 基于快照批量读取与回刷；compaction 周期任务收敛小文件。两条链路并行运行、互相独立，却在同一张表上自然汇合：

-- 链路：MySQL --Flink CDC--> Kafka --Flink SQL--> Iceberg
CREATE TABLE orders_binlog (
  order_id   STRING,
  user_id    STRING,
  pay_amount DECIMAL(12, 2),
  order_time TIMESTAMP(3),
  PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
  'connector'        = 'mysql-cdc',
  'hostname'         = 'mysql-biz.local',
  'database-name'    = 'trade',
  'table-name'       = 'orders',
  'scan.startup.mode'= 'initial'  -- 首次全量 + 持续增量
);

INSERT INTO lakehouse.dwd_trade_orders
SELECT order_id, user_id, pay_amount, order_time,
       DATE_FORMAT(order_time, 'yyyy-MM-dd') AS dt
FROM orders_binlog;

# Spark：每日 T+1 重跑，与流式写入共享同一张表
spark-sql --master yarn --deploy-mode cluster \
  --conf spark.sql.shuffle.partitions=800 \
  -e "INSERT OVERWRITE lakehouse.dws_trade_city
      PARTITION (dt = '2026-11-04')
      SELECT city, SUM(pay_amount) FROM lakehouse.dwd_trade_orders
      WHERE dt = '2026-11-04' GROUP BY city"

-- Trino：BI/分析师直接查询，无需等待导出
SELECT * FROM lakehouse.dws_trade_city
WHERE dt = '2026-11-04';

-- 小文件治理是批流一体的运维生命线：流写高频提交，必须定期合并
CALL lakehouse.system.rewrite_data_files(
  table   => 'lakehouse.dwd_trade_orders',
  strategy => 'binpack',
  options  => map('target-file-size-bytes', '134217728')
);

支撑 Palantir 式数据体系

Palantir Foundry 证明了数据平台的终极形态不是「一堆表」，而是本体（Ontology）+ 流水线（Pipeline）+ 应用：把业务对象、关系与动作映射为数据之上的语义层，让决策直接在模型上发生。湖仓底座恰好为这套体系提供了全部四类基础能力：

• 本体建模（Ontology）：以对象—关系—动作三层语义抽象业务世界。底座需要提供统一元数据、主外键约束与血缘，让「对象」能稳定地映射到 Iceberg 实体表。详见数据治理。
• 数据流水线（Pipeline）：本体背后是批流一体的加工链路。底座需要任务编排、断点重跑与数据鲜度保障——这正是 DolphinScheduler + Flink/Spark 的组合价值。详见调度资源。
• AI 检索：RAG 与推荐需要向量库与非结构化数据入湖。底座需要对象存储承载原始文档、计算层完成 embedding、向量库承载 ANN 检索，并把结果表回写湖仓统一服务。详见场景实战。
• 时空分析：GIS 空间研判与时序监控要求底座支持空间索引、时间窗口与高压缩扫描，通常由 ClickHouse/时序引擎 + Parquet 列存协同完成。

一个简化的本体定义（YAML 节选），可以直接架在湖仓的实体表之上：

# 语义层本体定义示例（节选）：对象映射到 Iceberg 实体表
ontology:
  object_types:
    - name: SalesOrder                  # 业务对象：销售订单
      primary_key: order_id
      source_table: lakehouse.dwd_sales_order
      attributes:
        - { name: order_amount, type: decimal(12,2) }
        - { name: customer_id,   type: string }
        - { name: order_time,    type: timestamp }
  link_types:
    - name: PlacedBy                    # 关系：订单 ← 下单客户
      source: SalesOrder
      target: Customer
      cardinality: many-to-one
  actions:
    - name: RefundOrder                 # 动作：可回写业务系统
      input: [ order_id, reason ]
      target_service: erp-refund-api

四类上层场景对底座的能力要求汇总如下：

技术选型方法论

湖仓组件多、迭代快，选型最容易犯两类错误：要么追新求全引入「全家桶」，要么保守扎堆堆叠历史包袱。以下五原则是评审任何湖仓选型方案的锚点：

1. 开放标准优先：表格式与文件格式必须选开放标准（Iceberg / Parquet），确保数据与元数据不被任何单一引擎或厂商私有化——这是湖仓架构的「宪法条款」。
2. 一专多能：优先选择能同时覆盖多个场景的组件（如 Trino 既是联邦查询器又是即席分析引擎），把组件总数压到最小；每多一个组件就多一份运维成本。
3. 社区活跃度：看 commit 频率、issue 响应速度、版本发布节奏与中文资料密度；一个两年不发版的「明星项目」比一个默默迭代的工具更危险。
4. 运维成本：评估团队熟悉度、部署复杂度、监控暴露成熟度与故障处理手册；选「团队能驾驭的最优解」，而不是「纸面上的最强解」。
5. 国产化适配：DolphinScheduler、Doris、MinIO、SeaTunnel 等国产开源组件已在湖仓栈中占据主流，中文社区与信创环境适配是实打实的减分加分项。

落到具体场景，本站的推荐组合如下（后续各章会给出完整的选型对比与理由）：

相关章节

建立全局地图后，建议按「存储 → 计算 → 查询 → 集成」的顺序进入六层技术栈的细节学习：