1. 一个关于五千张表没人说得清的真实开局先说一个我印象很深的现场某公司的数据平台Hive、Spark、Flink跑了一堆任务HDFS上目录一层套一层表数量到了五千多张字段加起来超过两万。IT运维、数据开发、业务分析师开会时最常见的对话是这张表是谁建的这个字段是从哪个上游来的这个指标的口径在哪定义。答案基本靠问人问不到就瞎猜。数据越堆越多元数据却停在Excel和口头传播的层面。当时我们引进了Apache Atlas做元数据治理后来又在一个新项目里换成了DataHub。有人问我Atlas和DataHub到底选哪个这个问题其实很难一句话回答因为两个工具的出发点、架构思路、使用体验完全不是一个路子。标题里的数据治理四个字看起来是个技术问题实际上是个管理问题你先把元数据当成固定资产管起来才谈得上血缘、资产目录、数据质量。这篇文章我尽量把两个平台的思路、能力边界、实操里的坑和我的选型建议讲透给正在做元数据管理选型的人一个参考。2. Atlas和DataHub长在哪两个开源元数据平台的出身与定位2.1 Apache Atlas从Hadoop生态长出来的治理中心Atlas最初是给Hadoop体系做治理的。注意这个词治理。它天生绑定了Hive元数据、HDFS路径、Kafka Topic、Spark作业这类传统大数据组件并且和Apache Ranger深度联动把元数据标签变成权限策略的一部分。它的内核是一套叫Type System的东西。你可以定义实体类型比如hive_table、hive_column、process定义分类比如PII、敏感、财务每个实体还可以挂属性和关系。血缘在Atlas里被建模成Process实体一个SQL脚本处理若干输入表和输出表就是一个Process。查血缘就是沿着input/output的边去遍历。实际部署Atlas时依赖链比想象中长。HBase做存储Solr做索引新版也支持ElasticsearchKafka负责接收Hook发来的元数据变更事件。安装包倒是不大但这几个外部组件要先伺候好。早年我们在某生产环境踩过Solr索引堆内存溢出的问题元数据一多重建索引就特别吃力。因为Atlas本质上是Java后端重量级存储组合适合搭一个大系统统一管但搭起来不是五分钟能解决的事情。2.2 DataHub用事件流重做元数据的现代化方案DataHub是LinkedIn开源2020年前后进入大众视野。它的设计思路更像数据基础设施而不是治理控制台。整个系统是事件驱动的GMSGeneralized Metadata Service负责元数据存储和服务Kafka负责元数据变更事件的传递Elasticsearch负责搜索前端是一个现代化的React应用。第一次接触DataHub你会发现血缘可以按字段column-level看UI点开一张表就能看到字段级别的上下游。这背后其实是元数据模型设计得好——Dataset、DataJob、DataFlow这些标准实体靠UpstreamLineage关系连接字段血缘和表级血缘是分开建模的。再加上DataHub里有Glossary业务术语表、Data Product数据产品、Tags、Domains这些概念它更强调让人能理解数据而不仅是让人能找到数据。启动DataHub非常直接一条命令就能把整个环境拉起来。日常操作上用Ingestion框架配置一个recipe文件跑一条命令就能把Hive、ClickHouse、Kafka、Airflow、dbt之类源里的元数据采集进来。我后来的很多实践迁移到DataHub最大的感受就是它把元数据管理从平台运维的事变成了开发也能自己接入的事。3. 元数据能力逐项对比血缘、分类、搜索、协作谁更能打3.1 血缘追踪Atlas的类型级血缘和DataHub的字段级血缘血缘是元数据管理最核心的功能。Atlas拿到血缘的主要方式是Hive Hook。安装atlas-hive-hook后Hive执行SQL时Hook会拦截执行计划解析出输入表、输出表、SQL操作类型把血缘信息通过Kafka事件发到AtlasAtlas再建Process实体。这种方式对Hive生态支持最好但血缘粒度基本是表级。列级血缘也有主要是依赖Hive执行计划里的列依赖关系但展示很弱想通过Atlas界面快速找到这个字段被哪张下游表引用其实很麻烦。DataHub的字段级血缘做得扎实。你在UI里点开某张表的某个字段右侧栏直接列出字段级的上下游这些信息来自VLValue lineage数据或SQL解析。DataHub有内置的SQL parserdbt的sources、Looker的视图定义、Airflow里的数据任务依赖都能被Ingestion框架拆出来。表级血缘用Dataset-to-Dataset的Edge表示字段级用SchemaField级别的Edge表示两者分得很清楚。我自己实测的感受查某张被下游十张表依赖的核心表Atlas能给出有血缘的结果但要做影响分析比如我要删这个字段哪些任务会挂DataHub的字段级血缘配合DataJob的血缘才真正好用。如果你每天面对一堆SQL分析任务字段级血缘几乎是刚需。3.2 分类打标与安全联动Atlas和Ranger的组合拳Atlas的分类Classification可以挂到实体上比如给某张hive_table打上PII标签。真正让Atlas在企业里站住脚的是Ranger插件。Ranger能读取Atlas的实体标签在Hive的授权策略里动态生效某个用户能访问表前提是这张表没有PII标签或者有标签但用户属于脱敏组。这个能力在强合规环境下特别值钱。DataHub也有Tags和Glossary Terms可以给实体打敏感受限之类的标签但DataHub本身不直接做数据库层的权限拦截。它更多是告诉你这里有什么敏感数据不做不允许你访问。如果你的核心诉求是从元数据打到权限策略AtlasRanger是组合拳如果只是需要记录并展示哪些数据是敏感的DataHub足够。3.3 搜索与浏览两种截然不同的找到数据体验搜索体验差异非常大。Atlas的搜索本质是TypeClassification属性的结构化检索界面偏传统。你要先选实体类型比如hive_table再填属性甚至还要懂一点查询语法。对开发人员还好对业务分析师来说门槛偏高。而且Atlas的搜索结果和血缘展示比较朴素想按业务域浏览数据资产基本上做不到。DataHub的搜索是Elasticsearch驱动的全文本搜索支持模糊匹配、布尔逻辑、按标签/域/平台筛选。首页能按Data PlatformHive、Kafka、Snowflake等、Domain业务域、Tag多维度浏览。我印象很深的一点DataHub的UI里字段、Dataset、仪表盘、Pipeline都是可搜索实体输入一个字段名能搜到所有包含它的表。这种按字段找表的检索模式在生产环境里比按表找字段高效得多。3.4 协作能力元数据管理的群众路线我把协作单独拎出来说是因为元数据管理能不能持久靠的不是后端多强而是业务和开发愿不愿意在上面维护信息。Atlas在这块的思路很薄弱有文档和注释功能但做得简陋使用体验像企业后台表单。DataHub提供了文档、上下文、知识库、任务提醒、评论等功能分析师看到某个字段口径不对可以直接在UI里写说明数据质量问题的告警还能自动创建任务分配到责任人。在实际项目里DataHub这种协作能力带来的好处是元数据不再是一两个平台运维人员维护而是分析师、数据开发、数据产品经理都能参与补全。对一个元数据管理平台来说这比多一个搜索功能重要得多因为它决定了系统是否会被持续使用。4. 部署体验与二次开发从零到能用的门槛差距4.1 Atlas的部署是一场耐心的考验Atlas和Hadoop生态绑定很深安装手册看着不复杂但真正跑起来需要合理规划JVM内存和外部组件。我梳理一下典型步骤准备HBase、Solr或Elasticsearch、KafkaAtlas用Kafka接收Hook事件。解压Atlas安装包配置atlas-application.properties存储后端指向HBase索引后端指向Solr/ESKafka地址。启动HBase、Solr、Kafka之后初始化Atlasatlas_start.py。接入Hive把atlas-hive-hook打包路径配置到Hive的HIVE_AUX_JARS_PATH然后在atlas-env.sh里配好Kafka生产者与Hook参数重启HiveServer2。启动后等Hook把Hive元数据事件推过来Atlas会创建对应实体。这里我踩过几个坑一是HBase的RegionServer如果不做预分区元数据量大时容易单Region热点二是Solr索引目录如果不独立到高速磁盘重建索引时会有明显卡顿三是Hook日志默认会打印到Hive日志里任务一多日志量暴涨。Atlas能干活但它需要你有专门的运维精力去养它。4.2 DataHub的部署容器化让人省心DataHub官方提供Docker Compose和Helm两套部署方式。个人开发环境直接跑datahub docker quickstart它会拉取GMS、前端、Kafka、Elasticsearch、MySQL等容器几分钟后打开http://localhost:9002就能用。生产环境用Kubernetes部署内存大约按每个节点8-16G规划比Atlas省心很多。数据接入方面DataHub的Ingestion框架丰富很多。它把采集器叫Source目前有大几十种Hive、Mysql、ClickHouse、Snowflake、dbt、Tableau、PowerBI、Airflow、Spark、Flink等统一用YAML recipe配置后跑datahub ingest -c recipe.yml。比如接Hive# recipe.yml 示例 source: type: hive config: host_port: hive-server:10000 database: default schema_pattern: allow: [ods, dwd] include_tables: true sink: type: datahub-rest config: server: http://localhost:8080跑完之后在DataHub里用Data Platform维度看能看到Hive里的database、table、column都以统一模型展示。这个流程比配Hook简单太多而且单个采集器失败不影响整体因为每次Ingest都是独立的批次任务。4.3 接口能力对比REST和GraphQL的差距Atlas对外主要提供REST API比如通过/api/atlas/v2/entity/bulk批量创建实体通过/api/atlas/v2/search/attribute做属性查询。但它的接口风格偏重笨重返回结构复杂做联动开发时文档也不够友好。DataHub对外有REST API和GraphQL API。GraphQL可以做联合查询一次请求拿到实体的血缘、标签、字段、下游引用。比如查一张表的血缘和字段query { dataset(urn: urn:li:dataset:(urn:li:dataPlatform:hive,ods_order,PROD)) { urn name properties { description } lineage { downstreamRelationships { entity { ... on Dataset { urn name } } } } } }这种查询能力在自研内部平台、快速做数据地图时非常方便DataHub还提供Python SDK可以直接脚本批量读取元数据。5. 元数据从哪来两类平台的采集接入实操链路5.1 Atlas的Hook机制与手动导入Atlas接入数据源有两条路一条是Hook一条是API导入。Hook适合处理数据引擎自己执行任务时顺手把元数据发出去。Hive Hook是我用得最多的HBase、Kafka、Sqoop、Storm或Flink也都有对应Hook。核心逻辑是监听执行计划将表、列、血缘转换为Atlas实体通过Kafka发送到Atlas。Hook配置好之后是纯自动的不需要人工干预。缺点是每个组件都要装一遍Hook没有Hook的老组件要自己写采集脚本。API导入适合自己开发采集器。Atlas提供REST API你按Type System定义实体JSON通过POST方式创建实体和关系。我早期在某平台就是每天晚上跑一个Python脚本把自研元数据服务里的表和字段信息转成Atlas实体结构批量导入。要注意统一Type Definition尤其是qualifiedName必须全局唯一否则Atlas会当成更新而不会新建分类。5.2 DataHub的Ingestion配置细节DataHub的采集器做成Source插件多数Source都支持配置项platform_instance区分同类型多环境dev/prod避免元数据混淆table_pattern和schema_pattern正则摘掉不需要的表profiling采集字段统计信息非空率、去重率等用于数据画像transformers在采集过程中改写实体属性比如自动给某些表加标签跑一次采集datahub ingest -c recipe.yml。采集结果会先发到一个Stage本地文件或Kafka再由Sink写入GMS。这样做的好处是采集和写入解耦比如先把全量元数据导出成文件再离线导入。我在生产里常用file这个sink做全量备份再配合差异增量比直接连GMS稳妥。5.3 数据质量校验和失败排查不管是Atlas还是DataHub采集时最容易遇到三类问题权限不够。Hive的Hook、Ingestion连接器都需要能读取元数据的账号很多环境里没有开只读账号导致采集Job报警。qualifiedName或urn格式不一致。两套平台都要求实体的唯一标识稳定如果采集代码里拼接规则变了同一个表会被识别成多个实体血缘就断掉了。列级血缘丢失。Atlas里常见于SQL语句特别复杂、有多个子查询嵌套的情况Hook解析出的字段依赖可能只覆盖了部分。DataHub里如果上游SQL来自非标准方言SQL parser也可能解析不出准确字段。处理方式一般是先跑通表级血缘再逐步补字段级不要一上来就强求全链路血缘闭环。6. 选型结论别再问哪个更好先问你的元数据问题是什么做选型决策时我建议把问题拆成三个元数据的主要消费对象是谁血缘粒度要做到什么程度是否需要和权限策略联动我把两个平台按常用维度做了一张对比表对比维度Apache AtlasDataHub定位治理中心、审计、安全联动数据目录、协作、资产发现血缘能力表级血缘为主列级有限列级血缘清晰UI展示强元数据模型Type System自定义实体和分类PDL模型Dataset、Chart、Dashboard等搜索体验结构化搜索为主ES全文搜索 多维筛选协作能力偏弱文档、注释、任务、讨论齐全部署复杂度高HBase/Solr/Kafka手动搭建低Docker Compose或K8s开箱权限联动和Ranger深度集成自带平台角色权限不联动计算引擎生态覆盖Hadoop体系原生其他源需自研数据湖、数仓、BI、调度、dbt等覆盖广适合场景强合规、强审计、需标签驱动脱敏数据运营、业务自助找数、多平台统一目录我的个人经验是如果公司大量使用Hadoop生态有明确的权限审计和脱敏联动需求选AtlasRanger是顺路的事。你不需要太多UI漂亮度更多是能被审计系统扫描到能按标签控制Hive访问。这个场景Atlas至今仍是可靠选择。如果公司的挑战是数据多而散业务找不到数流程难统一那DataHub更合适。它的协作和搜索能力能很快让分析师愿意用起来列级血缘对数据开发做影响分析也有直接帮助。如果你不想二选一也可以共存DataHub做全域资产目录Atlas做安全标签和Ranger联动两者在血缘、标签这类元数据上通过定时任务同步。我实际做过一次复杂度可控关键是先统一好两边的实体命名规则和一个双向同步的桥接脚本。这个领域有个很朴素的道理元数据管理工具选型根本不是功能多比功能少的问题而是谁愿意持续维护它的问题。Atlas和DataHub都不是装了就能自动把数据资产管好的工具它们像是一个需要长期喂养的机制采集器要维护标签规范要制定责任人要明确口径要更新。工具的价值是在这个机制运转起来后把成果放大给所有人看。最后分享一个我现在更倾向的做法新项目优先看DataHub因为引入成本低团队接受度高但如果是必须对着审计要求打标签脱敏的Hive数仓Atlas和Ranger的组合我依然会坚持用。两个都跑过一遍之后你会发现元数据管理里真正难得不是部署某套系统而是想清楚每个元数据字段以后由谁负责更新、谁负责消费。先把这个问题答好再选工具才不会一年后发现自己又维护了一个没人看的元数据库。