1. 数据迁移的现状与挑战
聊数据迁移，得先看看我们到底从哪出发、要往哪去。这几年我参与过不少企业级数据平台的迁移项目，从传统数仓到数据湖，再到现在的 Lakehouse，每个阶段都有各自的坑。说白了，没有一种架构是万能的，关键看你业务到底要什么。
1.1 传统数据仓库的痛点
传统数仓，像 Teradata、Oracle、Greenplum 这些，十年前确实是王者。但现在业务数据量暴涨，它的短板越来越明显。
核心痛点：扩展成本高、数据形态单一、实时性差。
- 扩展成本高：传统数仓是 Share-Nothing 架构，加节点要重新分布数据。我见过一个客户，Teradata 集群从 20 节点扩到 40 节点，光数据重分布就跑了三天，业务直接停摆。而且硬件贵，一个节点几十万，小公司根本扛不住。
- 数据形态单一：数仓只擅长处理结构化数据。日志、图片、音视频这些半结构化、非结构化数据，要么存不进去，要么存进去也查不动。你想想看，现在哪个业务不涉及用户行为日志？传统数仓在这块基本是废的。
- 实时性差：传统 ETL 是 T+1 的，今天跑昨天的数据。业务要实时看大屏、做风控？对不起，得等明天。我有个做金融的朋友，他们用 Oracle 做数仓，实时交易数据要延迟 6 小时才能入库，风控模型根本跑不起来。
避坑提醒：我曾经遇到一个项目，客户坚持用传统数仓做实时流处理，结果花了半年改造，性能还不如开源方案。选型时别硬扛，该换就换。
1.2 数据湖的局限性
数据湖的出现，解决了传统数仓的扩展性和数据多样性问题。Hadoop、Spark 这些技术让企业能存海量数据，成本也低。但数据湖也有自己的麻烦。
| 维度 | 传统数仓 | 数据湖 |
|---|---|---|
| 数据质量 | 强约束，Schema-on-Write | 弱约束，Schema-on-Read |
| 事务支持 | ACID 事务 | 无事务或弱事务 |
| 查询性能 | 优化好，秒级响应 | 依赖计算引擎，常分钟级 |
| 数据治理 | 成熟 | 混乱，容易变数据沼泽 |
数据湖最大的问题，就是容易变成「数据沼泽」。数据往里一丢，没人管，没人用。我见过一个团队，HDFS 上存了 200TB 数据，80% 是重复的、过期的、格式混乱的。分析师想用，得先花两周清洗。
另外，数据湖不支持 ACID 事务。多个任务同时写同一个表，数据可能就乱了。我记得有一次，一个 Spark 任务跑了一半挂了，结果目标表里既有旧数据又有新数据，查出来的结果根本不对。这种问题在数据湖里太常见了。
1.3 Lakehouse 架构的兴起
Lakehouse 的出现，说白了就是把数据湖的灵活性和数仓的可靠性结合起来。它基于开放格式（如 Parquet、ORC），加上事务层（如 Delta Lake、Apache Iceberg、Apache Hudi），实现了 ACID 事务、Schema 演进、时间旅行这些能力。
我的理解：Lakehouse 不是推翻重来，而是在数据湖上盖一层「管理壳」。数据还是存在廉价对象存储上，但读写有了事务保证，查询有了优化器支持。
为什么 Lakehouse 能解决前面那些问题？
- 扩展性：存储计算分离，存到 S3、OSS 上，算力按需伸缩。我做过一个项目，数据量从 10TB 涨到 500TB，存储成本只增加了 30%，计算资源动态扩缩，完全不用停机。
- 数据多样性：支持结构化、半结构化、非结构化数据。同一份数据，既能跑 SQL 分析，也能跑机器学习模型。
- 实时性：通过流批一体，实现分钟级甚至秒级的数据入湖。Delta Lake 的 Change Data Feed 功能，能直接捕获增量变更，不用再写复杂的 ETL。
- 数据治理：Catalog、Schema Registry、血缘追踪，这些在 Lakehouse 里都是原生支持的。数据不再是一堆乱文件，而是有元数据管理的资产。
下面这张图，是我自己总结的 Lakehouse 核心架构，你可以看看它和传统数仓、数据湖的区别。
从这张图能看出来，Lakehouse 不是简单地把数仓和数据湖拼在一起。它是在数据湖的存储层上，加了一层事务和索引能力，让数据既能像湖一样灵活，又能像仓一样可靠。
总结一下：传统数仓适合高价值、结构化、低延迟的场景；数据湖适合海量、多样、低成本存储的场景；Lakehouse 则试图把两者的优点合并，成为企业数据平台的新底座。
我个人习惯，在评估迁移方案时，先看业务对数据一致性、实时性、扩展性的真实需求。别盲目追新，也别死守旧架构。Lakehouse 是个好方向，但落地需要扎实的规划和执行。后面几章，我会详细讲怎么一步步把传统数仓和数据湖迁移到 Lakehouse 上。