Open Tables，共享真相：构建多引擎 Lakehouse
发布: (2026年3月31日 GMT+8 15:35)
5 分钟阅读
原文: Dev.to
Source: Dev.to
（请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式。）
问题
- 同一数据集被复制多次。
- 同一指标产生不同的结果。
- 治理逻辑在各系统中被重新实现。
尽管如此，组织仍自信地声称：
“我们拥有唯一的真相来源。”
实际上，存在的是各自独立的副本：
- 数据仓库副本
- 数据湖副本
- 服务副本
每个副本略有不同，并且仅在其自身的上下文中是“正确”的。
我们为何走到这一步
历史原因：
- 计算引擎无法就格式达成一致。
- 存储系统缺乏事务保证。
- 治理绑定于特定平台。
工程师通过将管道作为粘合剂来连接碎片化的真相——然而，管道会复制真相而不是扩展它。
转向开放表格格式
数据湖最初承诺“把所有东西存放在一个地方”，并提供了：
- 更快的访问
- 更少的 ETL 作业
- 灵活的分析
但所有权并未改变；数据湖变得可访问，却仍不是权威的。
新的所有权单元
表格，而非引擎，是所有权的单元。
过去，数据归引擎所有，管道在它们之间移动数据。现在，表格成为共享、受治理且具权威性的资产。
开放表格格式如 Apache Iceberg、Delta Lake 和 Apache Hudi 为对象存储带来类似数据库的保证：
- ACID 事务
- 模式演进
- 时间旅行
- 快照隔离
- 并发读写
多引擎兼容性
多个引擎可以可靠地读取和写入同一张表，例如：
- Apache Spark
- Trino
- Amazon Athena
- Snowflake
无需复制，也无需转换层。
现代湖仓架构
传统 vs. 现代 方法
| 方面 | 传统 | 现代 |
|---|---|---|
| 数据处理 | 复制，管道遍布各处，真相的多个版本 | 共享，最小化管道，唯一一致的真相 |
| 存储角色 | 被动存储 | 记录系统（权威） |
| 治理 | 引擎特定的策略 | 表级，集中式策略 |
分层架构
- 存储层 – 对象存储（例如 Amazon S3）
- 表层 – 开放表格格式（Iceberg / Delta / Hudi）
- 计算层 – 多引擎（Spark、Trino、Athena 等）
- 治理层 – 集中式策略执行（例如 AWS Lake Formation）
- 消费层 – BI、机器学习、API
设计规范
即使使用开放表格，团队仍可能陷入陷阱：
- 将表格视为 CSV 文件
- 缺乏所有权模型
- 允许每个引擎无限制写入
- 忽视成本和压缩策略
关键考虑因素
- 并发写入者 – 冲突解决策略
- 压缩所有权 – 谁负责维护表格性能？
- 性能调优 – 分区、索引
- 故障域 – 什么会出错，出错位置在哪里？
这些是平台层面的决策，而不仅仅是工程层面的决定。
组织变革
转变比技术更大；它是一场组织转型。
| 从 | 至 |
|---|---|
| 管道所有权 | 数据产品所有权 |
| 系统孤岛 | 共享合同 |
| 以工具为中心的思考 | 以协议为中心的思考 |
- 停止复制数据。
- 开始共享真相。
- 将表格设计为产品。
- 让引擎可以互换。
“最具可扩展性的分析平台是围绕协议而非工具构建的。”
结论
我们花了多年时间来优化数据处理的速度。现在关键的问题是：
真理在哪里，它归谁所有？
在这个问题解决之前，任何计算资源都无法修复你的数据平台。