一、数据湖仓概述：从数据孤岛到统一治理
大家好，我是这次课程的主讲。在数据这个行当摸爬滚打了十几年，我见过太多团队在数据架构上「翻车」——要么是数仓太死板，要么是数据湖太混乱。今天咱们聊的「多 Catalog 整合」，说白了就是解决一个核心矛盾：数据越来越多，但找到数据越来越难。
嗯，在正式进入多 Catalog 之前，得先把地基打牢。这一章我们聊聊数据湖、数据仓库的区别，湖仓一体是怎么演进的，以及——为什么突然冒出个「多 Catalog」的概念。
1.1 数据湖 vs 数据仓库：两个时代的产物
先问个问题：你公司现在用的是什么？是传统数仓，还是数据湖？或者两者都有？
我个人的经验是，很多团队其实「两头不靠」——用数仓的嫌它贵，用数据湖的嫌它乱。咱们先看看它们到底差在哪。
| 维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据形态 | 结构化，Schema-on-Write | 结构化/半结构化/非结构化，Schema-on-Read |
| 存储格式 | 行列式存储（如 Oracle、Teradata） | 对象存储 + 开放格式（Parquet、ORC） |
| 处理引擎 | 专用 SQL 引擎 | Spark、Flink、Presto 等 |
| 数据质量 | 强约束，ETL 清洗 | 弱约束，原始数据保留 |
| 典型场景 | BI 报表、固定指标 | 机器学习、探索性分析 |
| 成本 | 高（硬件 + 许可） | 低（廉价对象存储） |
一句话总结：数据仓库是「先想好再用」，数据湖是「先存了再说」。我在项目中见过太多人把数据湖当成「垃圾堆」——存了一堆没用的原始日志，最后谁也找不到。
1.2 湖仓一体架构演进：从「两套系统」到「一套架构」
你想想看，如果公司同时跑着数仓和数据湖，会是什么场景？
数据工程师每天在两个系统之间搬数据，ETL 脚本写到手软。业务方问「这个指标为什么对不上？」——嗯，因为数仓里的数据是清洗过的，湖里的是原始的，口径不一样。
这就是湖仓一体要解决的问题。它的演进大致经历了三个阶段：
- 两套独立系统：数仓做报表，数据湖做探索，中间靠 ETL 打通。数据冗余严重，口径经常打架。
- 湖上建仓：在数据湖上直接跑 SQL 引擎（如 Hive、Spark SQL），试图用湖的存储 + 仓的查询能力。但事务、ACID、更新删除这些能力很弱。
- 真正的湖仓一体：以开放格式（如 Apache Iceberg、Delta Lake、Hudi）为基础，在对象存储上实现事务、索引、时间旅行等数仓级能力。
我记得 2019 年第一次接触 Iceberg 时，心里还犯嘀咕：「这不就是 Hive 换了个皮？」后来深入用了才发现——它把数仓的 ACID 和湖的弹性存储真正结合在了一起。
我的建议：如果你的团队还在纠结「用湖还是用仓」，不如直接考虑湖仓一体。别走回头路，我见过太多从数仓迁到数据湖，两年后又想迁回去的案例——折腾。
1.3 多 Catalog 出现的背景：数据碎片化催生的新问题
好，前面铺垫了这么多，终于到正题了。
湖仓一体解决了「存储与计算」的统一，但它没解决「元数据」的统一。什么意思呢？
你想想看，一个中型公司可能有：
- Hive Metastore 管理着几百张 Hive 表
- Iceberg 有自己的 Catalog（如 HiveCatalog、HadoopCatalog）
- Kafka 的 Schema Registry 管理着流数据的元数据
- 甚至还有 MySQL、PostgreSQL 的业务元数据
这些 Catalog 各自为政，互不相通。数据工程师想找一张表，得先问「这表在哪个 Catalog 里？」——是不是很熟悉？
我曾经踩过的坑：有一次做数据迁移，团队以为所有表都在 Hive 里，结果漏掉了 Iceberg 的 HadoopCatalog 下的几十张表。上线后才发现数据对不上，回滚花了整整两天。从那以后，我坚持所有 Catalog 必须统一纳管。
多 Catalog 出现的背景，说白了就是三个字：碎片化。
具体来说，有这几个驱动力：
- 引擎多样化：Spark、Flink、Presto、Trino 各有各的元数据管理方式。
- 格式多样化：Iceberg、Delta Lake、Hudi 各自定义了自己的 Catalog 接口。
- 环境隔离：开发、测试、生产环境需要不同的 Catalog 实例。
- 多云/混合云：数据分布在 AWS、阿里云、自建机房，Catalog 也得跟着分布。
下面这张图，是我自己总结的「多 Catalog 问题全景」：
你看，左边是传统数仓体系的 Catalog，右边是新兴的流式/云上 Catalog。它们之间没有统一的「元数据总线」。数据工程师每天花大量时间在「找表」和「对口径」上——这其实是一种巨大的隐性成本。
1.4 多 Catalog 整合要解决什么？
说白了，多 Catalog 整合的目标就三个：
- 统一发现：不管表在哪个 Catalog，都能在一个地方搜到。
- 统一权限：不需要每个 Catalog 单独配权限。
- 统一治理：血缘、质量、生命周期一把抓。
我在上一家公司主导过一个项目，把 Hive、Iceberg、Kafka Schema Registry 三个 Catalog 整合到一起。刚开始觉得「不就是个元数据同步吗？」——结果一做就是三个月。为什么？因为每个 Catalog 的接口、语义、事务模型都不一样。
嗯，这就是我们这门课要深入探讨的内容。后面的章节，我会带着大家一步步拆解每个 Catalog 的整合方案，包括代码实现和避坑指南。
本章核心要点：
- 数据湖和数仓不是替代关系，而是互补关系——湖仓一体把它们融合了。
- 多 Catalog 是湖仓一体落地后的「次生问题」，本质是元数据碎片化。
- 整合 Catalog 不是技术炫技，而是为了降低数据工程师的「找表成本」。