1.1 从找数难说起：DataHub的定位

1.1 从找数难说起：DataHub的定位

本节摘要：DataHub 是 LinkedIn 开源的元数据管理平台，核心能力是把分散在各数据系统中的元数据汇聚成一张可搜索、可追溯的实体关系图。本节从三个高频痛点切入，界定 DataHub 的能力边界——它是数据地图，不是数据仓库，更不是 ETL 工具——并厘清数据字典、数据目录、元数据平台三个常被混用的概念。本节是全册的起点，为第 2 章的架构剖析提供"它是什么"的坐标原点。

问题现场

周一上午十点，风控团队在群里问："营销活动的客户名单表在哪个库？"数据组的回答分三步：先问"你说的是哪次活动"，再翻聊天记录找出上次的同步文档，最后发现那张表上个月刚迁移到新数仓，文档没更新。四十分钟后表找到了，又冒出新问题："这张表能直接用吗？上游变了会不会通知我们？"

这一幕在很多组织里日复一日上演。把它拆开，其实是三类反复出现的成本：

• 找数难：数据存在哪里，只有经手人知道。人一离职、组织一调整，知识就断档。
• 信数难：同名表有好几份，口径各不相同。用的人不知道哪份是权威版本，只能凭印象挑一个。
• 改数怕：想改一个字段，不知道下游有谁在用。要么不敢改，要么改了炸了下游报表才发现。

这三类成本有个共同根源：数据在快速生产，而"关于数据的知识"没有被同样认真地管理。表结构在变更，字段含义在漂移，上下游关系在重组——这些变化散落在聊天记录、离线文档和老员工的记忆里。元数据平台要做的，就是把这些知识变成有专人维护、可查询、可追溯的正式资产。

DataHub 是什么：一张实体关系图

DataHub 对自己的定义很克制：一个元数据管理平台。落到数据形态上，它维护的是一张大图，节点是元数据实体，边是实体之间的关系。常见节点包括数据表、字段、仪表盘、ETL 任务、数据Topic、业务术语、负责人；常见边包括"表 A 血缘来源于表 B""仪表盘 C 依赖表 A""字段 D 的负责人是某团队"。下图示意了这张图的局部形状：

理解 DataHub 最省力的方式，是把它类比成测绘机构绘制的地图：数仓、数据库是山川河流本身，DataHub 不生产山川，它绘制的是标注了地名、边界、道路连接关系的图纸。图纸的准确性取决于测绘频率（元数据摄入的实时性），图纸的可用性取决于标注体系（元数据模型）的设计。

DataHub 不是什么：三个常见误解

第一，它不是数据仓库。DataHub 不存业务数据，一条订单的明细不会进入它。它在意的只是"存在一张订单表、字段有哪些、上游是谁"。也正因如此，它的存储量级远小于业务数据，元数据总量通常是数据本身的千分之一以下，这让它有可能把全组织的元数据集中在一处。

第二，它不是 ETL 工具。它不会帮你搬运或清洗数据。血缘关系是把元数据"描"出来的——通过解析调度系统任务、解析 SQL 语句获得，而不是靠它执行任何数据加工。把它当调度平台用是方向性错误。

第三，它不是字段注释登记表。很多团队第一个动作是"把所有表的注释批量导入"，导入完成后平台便再无访问。注释只是元数据的一小部分，孤立注释不构成网络；DataHub 的价值在于注释与血缘、负责人、质量结果、术语的关联产生的涌现能力——例如顺着血缘找到某字段的负责人，再看到该字段最近的质量校验通过率。

三个概念的能力边界

数据字典、数据目录、元数据平台经常被混为一谈，但它们的能力范围差异很大。用一张表划清边界：

判断自己需要哪一层：如果痛点只是"新人找不到表"，数据字典可能已经够用；如果开始被"这个数能不能信"追问，需要数据目录；一旦"改数怕"成为常态、合规审计要求追溯数据来源，就到了元数据平台的阶段。DataHub 属于第三层，但向下兼容前两层的全部能力。

一个最小案例：三步让一张表可被发现

为了给后续章节一个具象锚点，这里展示一次最小规模的接入流程，细节在 4.2 节展开。第一步，在配置文件里声明数据源，告诉 DataHub 去哪里采集：

source:
  type: mysql
  config:
    host_uri: "10.0.2.15:3306"
    database: sales
sink:
  type: datahub-rest
  config:
    server: "http://datahub-gms:8080"
​

第二步，执行摄入命令，DataHub 连接 MySQL 读取库表结构，转换成统一模型后推送给元数据服务。第三步，打开 Web 界面搜索表名，进入详情页即可看到表结构、负责人，如果同时接入了调度系统，还能看到上下游血缘图。三步之后，"这张表在哪"的提问就终结了——答案从聊天记录变成了一个链接。

这个例子刻意保持了极简。真实项目里，数据源有几十种、字段口径要打标、负责人要认领，每一步都有取舍。这正是后续章节要逐一展开的内容。

两个高频追问

追问一：它与数据质量工具是什么关系？ 质量工具负责"算"，DataHub 负责"让人看见"。校验规则在质量平台里定义与执行，结果通过接口回写到表实体上（第 5.4 节展开），于是取数的人在详情页直接看到健康状态。两者是共生而非竞争：没有元数据平台，质量结果是又一份没人看的报告；没有质量回写，数据地图缺了"能不能信"这层最关键的颜色。

追问二：它管数据权限吗？ 管一层，但不是全部。DataHub 能基于标签与领域做访问策略——比如"高敏标签的表只对合规组可见"（6.3 节展开），也能成为权限评审时的资产底册。但行级、列级的数据权限执行仍在数据系统本身：地图告诉你"这张表是高敏、负责人是谁、该找谁申请"，真正拦住查询的是数仓与数据库的权限体系。把它当成权限系统的替代品，会在第一次安全评审时被退回来。

本节要点回顾

• 痛点根源：找数难、信数难、改数怕，都源于"关于数据的知识"未被系统管理。
• 本质定位：DataHub 维护一张元数据实体关系图，节点是表、任务、仪表盘、术语等，边是血缘、依赖、所有权。
• 能力边界：不存业务数据、不做数据加工、不是孤立注释表，价值在关联产生的涌现能力。
• 概念分层：数据字典、数据目录、元数据平台是三层递进的能力，DataHub 处于第三层并向下兼容。
• 最小闭环：声明数据源、执行摄入、界面搜索，三步即可终结"表在哪"的提问。

下一节我们回看这套平台从何而来——理解了三代工具的演化逻辑，才能真正看懂 DataHub 设计中的那些关键取舍。