1. Catalog 选型概述：什么是数据 Catalog、为什么需要 Catalog、主流产品对比
各位同学，咱们今天聊一个很实在的话题——数据 Catalog 选型。
我做了这么多年数据平台，见过太多团队一上来就撸代码建表、写 ETL，结果半年后连自己有哪些表都说不清楚。嗯，这时候 Catalog 的价值就体现出来了。
1.1 什么是数据 Catalog？
说白了，数据 Catalog 就是一本「数据字典」。但它比字典能干多了。
你想想看，一个企业里可能有几千张表、几万个字段。谁建的？什么类型？怎么来的？哪些是敏感字段？没有 Catalog，这些信息全在人的脑子里。人一走，信息就断了。
我个人习惯把 Catalog 理解成三层：
- 元数据存储层——存表结构、分区、格式这些基础信息
- 权限管理层——谁能看、谁能改、谁能删
- 发现与治理层——数据血缘、标签、搜索、质量监控
大部分开源产品只做到第一层，商业产品会覆盖后两层。选型的时候，你得想清楚自己要哪几层。
核心观点：Catalog 不是「要不要」的问题，而是「什么时候上、上多深」的问题。项目初期可能一个 Hive Metastore 就够了，但到了跨团队、跨云、跨引擎的阶段，没有统一 Catalog 就是灾难。
1.2 为什么需要 Catalog？
我在项目中遇到过最典型的场景：
一个数据分析师跑过来问：「咱们那个用户画像表在哪？」我查了半天，发现三个团队各建了一张同名表，字段定义还不一样。你说这数据谁敢信？
Catalog 解决的就是这类问题。具体来说：
- 统一元数据视图——不管数据在 HDFS、S3 还是本地，一个入口查所有
- 权限集中管控——别再到处贴权限申请单了，Catalog 里一次配好
- 数据血缘追踪——这张表从哪来的、下游被谁用了，一目了然
- 降低沟通成本——新人上手不用挨个问「这个字段啥意思」
我的经验：如果团队超过 10 个人做数据开发，或者数据表超过 200 张，就应该上 Catalog。别等到数据沼泽形成了再治理，那成本高得多。
1.3 主流 Catalog 产品对比
市面上常见的 Catalog 产品，我挑四个有代表性的聊聊：Hive Metastore、AWS Glue、Unity Catalog、Polaris。它们代表了不同的设计思路。
| 特性 | Hive Metastore | AWS Glue | Unity Catalog | Polaris |
|---|---|---|---|---|
| 开源/商业 | 开源 | 商业（AWS） | 商业（Databricks） | 开源（Apache） |
| 存储后端 | RDS/MySQL | AWS 托管 | Databricks 托管 | PostgreSQL |
| 权限模型 | 简单（基于 HDFS） | IAM + Lake Formation | 细粒度 RBAC | 细粒度 RBAC |
| 多引擎支持 | Hive/Spark | Athena/EMR/Redshift | Spark/Databricks SQL | Spark/Trino/Flink |
| 数据血缘 | 无 | 有限 | 内置 | 无 |
| 适用场景 | 传统 Hadoop 数仓 | AWS 原生生态 | Databricks 湖仓 | 开源湖仓（Iceberg） |
我来逐个拆解一下：
Hive Metastore
老牌产品了。我最早做数仓的时候用的就是它。优点是稳定、简单，缺点也很明显——没有权限控制、没有血缘、跨引擎支持差。说白了，它就是个「元数据数据库」，不是真正的 Catalog。
如果你还在用 Hive + Spark 的传统架构，HMS 够用。但一旦引入 Trino、Flink 这些引擎，你就得自己折腾兼容性了。
AWS Glue
AWS 全家桶用户的首选。Glue Catalog 跟 Athena、EMR、Redshift 集成得很好，爬虫功能也挺方便。但有个坑——它跟开源生态的兼容性一般。你如果想把 Glue Catalog 的数据拉到自建 Spark 集群上用，得额外写不少代码。
我曾经帮一个客户从 Glue 迁移到开源方案，光是元数据导出就折腾了两周。嗯，这里要注意。
Unity Catalog
Databricks 的旗舰产品。权限模型做得非常细，能精确到行级、列级。血缘追踪也是内置的，不用额外配置。但它是商业产品，价格不便宜。而且一旦用了 Unity Catalog，基本就被绑定在 Databricks 生态里了。
我个人建议：如果你的数据平台已经重度依赖 Databricks，Unity Catalog 是首选。否则，慎重。
Polaris
Apache 基金会的新项目，专门为 Iceberg 设计的 Catalog。开源、支持多引擎、权限模型也够用。目前还在快速迭代中，生产环境案例不算多，但潜力很大。
我最近在做一个新项目，就在评估 Polaris。它的设计理念很干净——只做 Catalog 该做的事，不绑定计算引擎。这一点我很欣赏。
避坑指南：我曾经见过一个团队，因为贪图 Glue 的爬虫方便，把所有元数据都扔进去了。后来想迁移到开源 Trino 集群，发现 Glue 的 API 跟 Trino 的 Hive Metastore 接口不兼容，数据查不出来。最后只能写脚本全量同步，每天跑一次，延迟大不说，还经常出问题。
所以选型的时候，一定要想清楚：你未来可能用到哪些引擎？这些引擎跟 Catalog 的兼容性如何？
1.4 知识体系总览
下面这张图，我把 Catalog 的核心概念和选型逻辑串起来了。你一看就明白。
从这张图你能看到，Catalog 的核心能力是三层，四个产品各有侧重。选型的时候，先看你的引擎生态，再看你的治理需求，最后算成本。
我的建议：别一上来就追求大而全。先跑通一个最小闭环——元数据能查、权限能控、血缘能追。后面再慢慢加功能。很多项目死在「想一步到位」上。
好了，这一章的内容就到这。Catalog 选型是个系统工程，后面几章我会带你深入每个产品的细节和实战配置。咱们下章见。