专题说明
先理解这个专题解决什么问题，再按顺序读正文。
这组文章聚焦 lakehouse 在真实团队里的落地问题，而不是只停留在概念宣传。
如果你在做数仓升级、数据平台重构，或者在评估 Iceberg、Delta Lake、Hudi 等技术路线，这个专题适合按顺序阅读。
Lakehouse 系列总览
用一组面向工程团队的文章，系统讲清 lakehouse 的边界、表格式、数据摄入、成本控制与治理落地。
打开总览这一组文章会讨论什么
- 云数据库到底改变了哪些职责边界。
- 数据库选型、高可用、性能、成本与迁移如何拆开看。
- 哪些问题属于平台能力，哪些问题仍然要由工程团队负责。
推荐阅读顺序
先总览，再按问题域逐步深入。
Lakehouse 系列总览
用一组面向工程团队的文章，系统讲清 lakehouse 的边界、表格式、数据摄入、成本控制与治理落地。
第 1 篇：Lakehouse 到底在解决什么问题
lakehouse 的核心价值不只是统一存储，而是把数据平台的存储、计算和交付边界重新拆开。
第 2 篇：Iceberg、Delta Lake、Hudi 该怎么看
选表格式的关键不在于谁最流行，而在于你的写入模型、查询路径和引擎生态更适合哪一套事务与元数据机制。
第 3 篇：Lakehouse 的数据摄入和建模别只盯着批流一体
lakehouse 的摄入链路重点不只是批流一体，而是怎样让原始层、明细层和消费层之间的责任边界稳定下来。
第 4 篇：Lakehouse 成本问题往往不在存储
lakehouse 平台真正容易失控的，通常不是对象存储费用，而是扫描量、重复计算和治理缺失带来的计算成本。
第 5 篇：Lakehouse 真正上线，卡在治理而不是查询引擎
一个 lakehouse 平台要真正跑到生产环境里，最难的通常不是把查询跑起来，而是把权限、质量、血缘和责任边界真正落地。