Lakehouse 系列总览
这几年数据平台的讨论里，lakehouse 几乎已经成了绕不过去的词。很多团队提到它时，会把它理解成“把数仓搬到对象存储上”，或者“用一个新表格式替换 Hive 表”。这些理解都不算完全错，但都太窄。
lakehouse 真正带来的变化，不只是底层存储介质或者查询引擎变了，而是数据平台的组织方式变了。存储、计算、元数据、治理、数据交付不再被强绑定在一套系统里，团队开始用更模块化的方式搭平台。
这组文章会围绕五个高频问题展开：
- lakehouse 到底适合解决什么问题，不适合解决什么问题。
- Iceberg、Delta Lake、Hudi 这类表格式到底在解决哪一层问题。
- 批流一体和多引擎接入时，数据摄入链路应该怎么设计。
- 存储便宜以后，为什么计算和治理成本反而更容易失控。
- 一个 lakehouse 平台要真正跑到生产环境里，治理与权限边界应该怎么定。
适合谁看
- 在做数据平台升级的数据工程团队
- 从传统数仓往对象存储迁移的架构师
- 需要选表格式、编排链路和查询引擎的技术负责人
- 想把数据治理从“工具堆叠”拉回架构层讨论的人
建议阅读顺序
先看总览，然后建议按下面顺序读：
- 概念边界
- 表格式选择
- 数据摄入与建模
- 计算与成本
- 治理与生产化