📚 课程目录第1章 Catalog概念与痛点

一、Catalog概念与痛点：什么是数据Catalog、企业面临的多Catalog碎片化问题、统一纳管的业务价值

先聊聊最基础的问题——数据Catalog是什么。

我见过不少团队，一上来就跟我讲「我们要上数据治理平台」、「我们要做元数据管理」。但问他们到底要管什么，往往说不清楚。

其实说白了，数据Catalog就是一个「数据资产的黄页」。你想想看，你家附近有个图书馆，你找书的时候是不是先查目录？目录告诉你这本书在哪个书架、哪个楼层、作者是谁、大概讲什么。数据Catalog干的就是这件事——它告诉你公司里有哪些数据、数据在哪、谁在用、怎么用。

数据Catalog的核心能力：

我在一家金融公司做过一个项目，他们数据团队有30多人，但每次新同事入职，光找数据就要花两周。为什么？因为没有Catalog。大家靠口口相传：「那个表在Hive里，叫ods_order_v2，不对，是v3...」——你想想看，这效率能高吗？

好，现在问题来了。很多公司不是没有Catalog，而是Catalog太多了。

我这些年接触过的企业，少的有两三个Catalog，多的能有十几个。为什么会这样？

原因其实很现实：

技术栈割裂——Hadoop生态用Apache Atlas，云上用AWS Glue或阿里云DataWorks，实时数据用Confluent Schema Registry，BI报表又用Tableau的Catalog。每个平台都有自己的元数据存储，互不相通。
部门墙——数据团队用一套，业务部门用另一套，甚至同一个部门的不同项目组各自为政。我见过一个客户，他们数据中台团队用Atlas，算法团队用MLflow的Model Registry，两个Catalog里的表名对不上，同一个字段叫「user_id」和「uid」——你说这是不是灾难？
历史遗留——公司并购、系统迁移、技术升级，老的Catalog没下线，新的Catalog又建起来了。数据散落在各个孤岛里，没人说得清全貌。

我曾经踩过的坑：

有一家电商公司，他们同时维护着4个Catalog。数据工程师往Hive里加了一张表，忘了在Atlas里注册。结果业务部门在Tableau里查不到这张表，又自己手动建了一个同名表。两周后，两张表的数据对不上了，业务报表出了大问题。最后排查了三天，才发现是Catalog不同步导致的。

嗯，从那以后我养成了一个习惯——不管项目多急，先把Catalog统一纳管方案定下来。

多Catalog碎片化带来的具体痛点：

你想想看，一个数据分析师想找「最近30天的用户活跃数据」，他得先搞清楚：这个数据在Hive里还是ClickHouse里？表名叫什么？字段是叫active_user还是dau？有没有权限？——光这些前置问题就能耗掉半天。

那统一纳管能带来什么？我直接说结论：它解决的不是技术问题，而是效率问题和信任问题。

价值一：数据可见，效率翻倍

统一Catalog之后，用户只需要在一个地方搜索，就能找到所有数据资产。我在一个项目中做过统计：统一纳管前，数据查找平均耗时4.2小时；统一后，缩短到15分钟。这不是夸张，是真实数据。

价值二：口径统一，信任重建

当所有Catalog都指向同一个元数据标准，同一个字段名、同一个指标定义，业务部门就不会再问「为什么你的报表和我的报表数据不一样」。信任，是数据驱动决策的基石。

价值三：权限收敛，安全可控

统一纳管后，权限策略只需要在中心化平台配置一次，所有下游Catalog自动同步。审计的时候，也能一键导出全链路权限清单。我有个客户，之前每年数据安全审计都要花两个月，统一纳管后缩短到一周。

价值四：血缘贯通，问题可溯

跨Catalog的数据血缘打通后，一张报表出问题，可以秒级追溯到源头——是源数据错了，还是ETL脚本写错了，还是BI层配置有问题。不用再靠猜，也不用挨个系统查日志。

我个人习惯：

在启动统一纳管项目之前，先做一次「Catalog普查」。把公司里所有的元数据存储列出来，包括那些「没人维护但还在跑」的老系统。这一步虽然枯燥，但能避免后面踩大坑。

说了这么多，我画一张图帮你理清思路。这张图展示了多Catalog碎片化问题的本质，以及统一纳管的核心逻辑。

这张图左边是典型的碎片化现状——不同技术栈、不同部门、不同历史阶段留下的Catalog各自为政。右边是统一纳管后的理想状态——所有元数据在同一个平台上管理，用户只需要一个入口就能完成搜索、权限申请、血缘追踪等操作。

箭头中间的「统一纳管」就是我们要做的事情。它不是简单地把所有Catalog的数据复制一份，而是通过元数据采集、映射、同步、治理，让多个Catalog在逻辑上成为一个整体。