1、数据湖仓Catalog概述：什么是数据湖仓、Catalog的核心作用、为什么需要统一Catalog
1.1 数据湖仓到底是什么
先聊聊数据湖仓。这个词这几年特别火，但很多人把它想复杂了。
说白了，数据湖仓就是「数据湖」和「数据仓库」的融合体。数据湖能存各种格式的原始数据，成本低，但管理混乱；数据仓库结构化好、查询快，但扩展性差、成本高。数据湖仓想两头占——既要湖的灵活和低成本，又要仓的事务支持和SQL查询能力。
我2019年在一个金融客户那里做数据平台改造，他们湖上存了200TB的日志和交易数据，但分析师根本不敢直接用，因为没人知道哪些文件是干净的、哪些是脏数据。最后他们还是把数据ETL到Oracle仓库里用，湖变成了「数据沼泽」。这就是典型的数据湖仓没做好的样子。
数据湖仓的核心能力，我总结为三点：
- 统一存储：一份数据，多种引擎都能读（Spark、Flink、Presto、Hive）
- 事务支持：ACID特性，读写不冲突，数据不会读到一半
- 开放格式：用Parquet/ORC/Avro这些开放格式，不被厂商锁定
嗯，这里要注意，数据湖仓不是某个产品，而是一种架构理念。Apache Iceberg、Delta Lake、Apache Hudi都是这个理念的具体实现。
1.2 Catalog的核心作用
Catalog是什么？你可以把它理解成「数据的地图」。
没有Catalog的时候，你要查一张表，得先知道它在哪个路径下、是什么格式、有哪些分区。然后写一堆HDFS路径去读。我见过一个团队，他们的数据读取代码里硬编码了上百个HDFS路径，换一个集群就得改代码——这哪是数据平台，简直是手工作坊。
Catalog把这一切抽象掉了。你只需要说「我要查表orders」，Catalog自动告诉你：
- 这张表存在哪个存储位置
- 它的Schema是什么（有哪些列、什么类型）
- 它有哪些分区
- 它的数据格式是什么
- 它的统计信息（行数、大小）
我习惯把Catalog比作「图书馆的索引卡」。没有索引卡，你得在书架上挨个翻；有了索引卡，直接定位到书架第几排第几本。数据湖仓的Catalog就是这张索引卡，只不过它管理的是PB级的数据。
Catalog的核心职责：
- 元数据管理：表、列、分区、格式、位置
- 权限控制：谁可以读、谁可以写
- 版本管理：表结构变更历史、数据快照
- 统计信息：辅助查询优化器做执行计划
1.3 为什么需要统一Catalog
这个问题，我在很多客户现场都被问到过。他们的现状往往是：Hive有Hive Metastore，Spark有Spark的临时表，Kafka有Schema Registry，ClickHouse有自己的元数据……每个系统各管各的。
结果是什么？
- 同一个业务表，在Hive里叫
ods_orders，在ClickHouse里叫orders_flat，字段名还不一样 - 数据工程师在Spark里写好的ETL，分析师在Presto里查不到，因为Presto连的是不同的Catalog
- 权限要配好几遍，Hive配一次、Impala配一次、Kafka再配一次
我曾经帮一个电商客户做数据治理，他们光元数据同步脚本就写了7个，每天跑一遍，还经常对不上。有一次大促期间，分析师查到的订单数和运营后台差了30万单，查了两天才发现是Catalog没同步——Hive里已经更新了分区，但Presto的Catalog还是旧的。
统一Catalog要解决的就是这些「各自为政」的问题。它的目标很明确：
| 问题 | 统一Catalog的解法 |
|---|---|
| 元数据分散 | 所有引擎共享同一个元数据视图 |
| 权限重复配置 | 一次授权，全局生效 |
| 数据口径不一致 | 统一Schema定义，避免同名不同义 |
| 查询效率低 | 统一统计信息，优化器能做出更好的执行计划 |
你想想看，如果你的数据平台有5个计算引擎、3个存储系统，每个都有自己的Catalog，那维护成本是指数级增长的。统一Catalog之后，你只需要维护一套元数据、一套权限、一套血缘关系。
我的建议：不要等到Catalog混乱到不可收拾了才去统一。我见过太多团队，前期图省事用Hive Metastore凑合，等数据量到百TB级别再想迁移，代价巨大。统一Catalog这件事，越早做越划算。
1.4 数据湖仓Catalog的架构全景
下面这张图展示了数据湖仓Catalog在整个架构中的位置。你可以看到，Catalog是连接存储层和计算层的「中枢神经」。
从这张图你能看到，Catalog处于中间层，向上对接各种计算引擎，向下管理存储层的数据文件。没有这个中间层，每个引擎都得自己实现一套元数据管理逻辑，重复造轮子不说，还容易出问题。
1.5 主流Catalog方案对比
目前市面上主流的Catalog方案，我列个表格给你参考：
| 方案 | 底层存储 | 事务支持 | 多引擎兼容性 | 适用场景 |
|---|---|---|---|---|
| Hive Metastore | 关系型数据库（MySQL/PostgreSQL） | 弱（无ACID） | 好（Hive/Spark/Presto都支持） | 传统Hadoop生态，存量系统 |
| Apache Iceberg REST Catalog | REST服务 + 元数据后端 | 强（快照隔离） | 好（Spark/Flink/Presto原生支持） | 云原生、多引擎混合场景 |
| Delta Lake Unity Catalog | Databricks托管服务 | 强（ACID） | 一般（Databricks生态为主） | Databricks用户，全托管需求 |
| Apache Polaris | REST服务 + 可插拔后端 | 强（基于Iceberg） | 好（开源、厂商中立） | 需要开放、可自建的场景 |
| AWS Glue Catalog | AWS托管服务 | 弱（无ACID） | 好（AWS生态内） | AWS用户，与S3深度集成 |
避坑提醒：我曾经帮一个客户从Hive Metastore迁移到Iceberg REST Catalog，踩了个大坑——他们的Hive表有上千个分区，但Iceberg的元数据服务默认配置下，单次提交的分区数有限制。结果迁移脚本跑了三天，中间还因为超时回滚了好几次。后来调大了commit.max-threads和commit.max-retries才搞定。所以迁移前一定要做压力测试，别直接上生产。
1.6 什么时候该考虑统一Catalog
不是所有场景都需要统一Catalog。我总结了几条判断标准：
- 引擎超过2个：如果你只用Spark，Hive Metastore够用。但如果你同时用Spark、Flink、Presto，统一Catalog能省很多事
- 数据团队超过10人：人多了，元数据混乱的概率指数级上升
- 跨部门数据共享：不同部门用不同引擎，但需要看到同一份数据
- 有数据治理需求：血缘、权限、审计，这些都需要统一的元数据底座
嗯，如果你现在的团队只有三五个人，一个Hive Metastore加一个Excel文档也能撑一阵子。但一旦数据量上来了、团队扩张了，统一Catalog就是绕不开的坎。与其到时候手忙脚乱，不如提前规划。