数据资产发现：Atlas / DataHub / Amundsen

可视化演示

展示Apache Atlas、DataHub、Amundsen三大数据资产发现平台的架构定位对比、数据血缘追踪流程、以及自动化元数据采集管道。切换模式探索不同维度。

资产发现概念

图书馆刚开业时只有一百本书，管理员可以凭记忆回答“营销报表在哪”。但当书籍涨到一万册、分散在十个书库，记忆就会失效——读者找不到书，管理员互相不知道对方书库有什么，甚至同一张表被不同部门重复做了三份。大型企业的数据资产也面临同样的“失序”。

数据资产发现平台要做的事，就是为这栋“数据图书馆”建立总目录。它把散落在各系统的数据表、指标、任务、报表统称为“数据资产”，为每一份资产登记一条“元数据”。元数据就是“关于数据的数据”，相当于图书封面上的书名、作者、分类号。目录建好后，读者能查、管理员能管、审计能追溯。

一个成熟的数据资产发现平台通常包含三个层次：采集层通过插件连接 Hive、HBase、Snowflake 等数据源，抓取表结构、字段注释、调度信息；模型层把异构信息统一成可查询的元数据实体；服务层向上提供血缘图、搜索、标签、权限等能力。衡量目录建设进度最朴素的指标是覆盖率：

有了这层总目录，数据才从“躺在仓库里的书”变成“可以被检索、被借阅、被引用的资产”。接下来，我们要看看三位候选管理员各有什么绝活。

Atlas血缘分类

图书管理员最头疼的问题是“这本书是从哪本书改编来的？改动之后哪些报表会被影响？”Atlas 就像图书馆里的族谱管理员，给每本书绘制一张“家族树”——这就是血缘。

Apache Atlas 是 Hadoop 生态里成长起来的元数据治理平台，把“血缘追踪”和“分类管理”作为两大核心职责。血缘回答“这个指标依赖哪些原始表、又被哪些下游表消费”；分类回答“这本书属于哪个书库、贴了什么标签”——比如“个人敏感数据”标签决定了借阅权限。

Atlas 用“类型系统 + 实体实例”组织元数据。类型定义数据的形态，如 hive_table、hive_column；实体是具体的表或字段。平台从 Hive、HBase、Sqoop 等组件的钩子（hook）中捕捉变更事件，自动建立输入表到输出表的血缘边。对合规而言，最常用的查询是“找出一张表的所有上游来源”：

有了族谱管理员，合规审计不再需要翻几十份手工文档——一张血缘图就能说清楚数据从哪里来、流过哪些环节、最终去了哪里。这就是 Atlas 在强治理场景中不可替代的原因。

DataHub自动采集

如果图书馆每天涌入两百本新书，靠人工登记显然来不及。DataHub 就像一台自动化编目机器人：书刚放上传送带，它立刻扫描封面、目录、作者，自动生成图书卡并归档。

DataHub 起源于 LinkedIn，定位是“元数据领域的自动化采集平台”。它的核心哲学是把元数据当成持续流动的事件流，而不是一次性的静态快照。每当数据源里新增一张表、修改一个字段，都会触发一条元数据事件，被实时捕捉、标准化、写入目录。

技术实现上，DataHub 定义了统一元数据模型（Unified Metadata Model），用数据集、指标、用户、任务等实体覆盖业务要素；采集器通过 Kafka 事件管道接入各种数据源，再落到文档存储并建立 Elasticsearch 索引供查询。评价目录是否“跟得上变化”，可以用新鲜度指标：

对数据平台团队来说，DataHub 的意义在于“把人工编目的工作量压到最低”。只要管道搭好，新资产就能自动上架——这正是大规模数据中台最需要的省心机器人。

Amundsen探索

目录建好了，但读者怎么找到书？Amundsen 就是图书馆门口的搜索引擎：你输入“客户 流失”，它像 Google 一样返回最相关的表、指标和报表，还能告诉你哪本书最近最热门、大家的评分如何。

Amundsen 起源于 Lyft，设计出发点非常朴素——数据探索体验。业务分析师通常不记得表名，只记得“我要找客户留存相关的数据”。Amundsen 把搜索、浏览、收藏、评论、质量徽章整合在一起，让找数像逛书店一样自然。

排序是搜索引擎的灵魂。Amundsen 的搜索结果会综合文本匹配度、使用热度（被查询、被收藏次数）、数据新鲜度等因素加权排序，确保常被使用的优质表排在前面：

有了 Amundsen，找数从“到处问人”变成“自助搜索”。分析师把精力花在分析本身，而不是在几十个库里大海捞针——这是数据驱动文化的润滑剂。

架构差异对比

三位管理员各用一套工作笔记：族谱管理员用家族树状图，编目机器人用流水线卡片盒，搜索引擎用倒排索引账本。三个平台在架构上正好对应三类不同的存储与检索哲学。

Atlas 采用图模型，把表和加工任务作为节点、血缘作为边，天然适合查询“谁依赖谁”；DataHub 采用文档模型加流式管道，强调元数据的实时流动与统一抽象；Amundsen 用图数据库（Neo4j）存储关系、用 Elasticsearch 提供搜索排序，本质是一个以体验为中心的目录应用。

三类架构带来不同的查询复杂度特征。图上的血缘遍历需要沿着边扩展，复杂度与节点数、边数相关；而索引检索通过倒排列表直接定位，复杂度接近对数级别：

所以“谁好谁坏”没有标准答案：想盘清家谱选图模型，想快速响应大规模变更选流式模型，想要用户体验选搜索模型。理解了架构差异，选型就成功了一半。

选型决策建议

给图书馆配人手，不能只看哪位管理员名气大。小书店一个多面手就够了，国家级图书馆则需要族谱员、编目机器人、搜索引擎分工协作。企业的数据规模与技术栈，决定了该优先配备哪种能力。

经验法则可以概括为三点：数据源以 Hadoop 生态为主、合规审计诉求强烈时，Atlas 的血缘与分类能力最契合；数据规模增长快、每天产生大量新表、希望目录自动跟上变化时，DataHub 的流式采集效率最高；业务分析师多、强调自助找数与知识传播时，Amundsen 的搜索体验最受欢迎。

更严谨的做法是把选型拆成可打分的维度，再按企业权重加权：

权重数值可以按企业特点动态调整：强合规行业提高治理相关维度，分析师众多的企业提高体验维度。选管理员不是选“最贵的”，而是选“最合适的”。

实施落地路径

决定雇哪位管理员只是开始。真正的挑战在于：给管理层立规矩、把散落各处的书搬进登记流程、让读者习惯用新目录。实施一套数据资产发现平台，本质是一场持续的数据治理运动。

落地通常分三步走。第一步是元数据规划：圈定范围（先管核心数仓还是全公司所有系统）、统一命名规范、确定表/字段/指标的登记标准；第二步是接入集成：逐个对接数据引擎，配置采集器与调度频率；第三步是持续治理：建立血缘更新的巡检机制、定期清理僵尸资产、运营目录的使用率。

治理是否到位，可以用一个朴素的成熟度指标衡量——规划内的关键系统是否都已接入并保持更新：

目录建起来只是起点，真正让数据资产“活”起来的是日常运营：谁负责维护标签、多久巡检一次血缘、目录使用率如何纳入团队 KPI。就像图书馆的好口碑来自日复一日的上架、整理与导览，数据资产的秩序也来自持续治理。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Mini data asset catalog: register assets, trace lineage, search."""from collections import defaultdict  class Asset:    def __init__(self, name, owner, tags):        self.name = name        self.owner = owner        self.tags = tags  class MiniCatalog:    def __init__(self):        self.assets = []        self.lineage_map = defaultdict(list)  # source -> downstream     def register(self, name, owner, tags, sources=None):        asset = Asset(name, owner, tags)        self.assets.append(asset)        for src in (sources or []):            self.lineage_map[src].append(name)        return asset     def search(self, keyword):        kw = keyword.lower()        scored = []        for a in self.assets:            score = 0            if kw in a.name.lower():                score += 3            if kw in a.owner.lower():                score += 2            if any(kw in tag.lower() for tag in a.tags):                score += 1            scored.append((score, a.name, a.owner))        scored.sort(key=lambda x: x[0], reverse=True)        return scored     def upstream(self, name):        """Return all direct upstream sources of an asset."""        result = []        for src, dsts in self.lineage_map.items():            if name in dsts:                result.append(src)        return result     def coverage(self, discovered, total):        return discovered / total * 100 if total else 0.0  def main():    catalog = MiniCatalog()    catalog.register("user_profile", "zhangwei", ["user", "profile"])    catalog.register("order_pay", "lishu", ["order", "pay"])    catalog.register("user_orders", "daxue", ["order", "user"],                     sources=["user_profile", "order_pay"])    catalog.register("fraud_score", "chenhan", ["fraud", "risk"],                     sources=["user_orders", "user_profile"])     print("=== search 'order' ===")    for score, name, owner in catalog.search("order"):        print("  %-14s score=%d owner=%s" % (name, score, owner))     print("=== upstream of fraud_score ===")    print("  ", catalog.upstream("fraud_score"))     print("=== coverage ===")    print("  %.1f%%" % catalog.coverage(len(catalog.assets), 6))  if __name__ == "__main__":    main()

1. self.lineage_map = defaultdict(list)用字典记录“源表 → 下游表”的映射，这就是一张迷你血缘图。
2. def register(self, name, owner, tags, sources=None)登记一本“书”，并顺手把它的上游来源写入血缘图谱。
3. for src in (sources or []):把血缘边写入图谱，对应 Atlas 追踪“这本书由哪些书改编而来”。
4. if kw in a.name.lower(): score += 3表名命中给予最高权重，模拟 Amundsen 排序中的 Match 项。
5. scored.sort(key=lambda x: x[0], reverse=True)按得分降序排列，模拟搜索引擎的结果排序。
6. def coverage(self, discovered, total)计算目录覆盖率，即正文中衡量建设进度的 \(C\) 指标。

常见误区

面试题