怎么写才不像AI我直接给你来点实在的。起名字这种事看起来简单真做起来才知道里面的坑有多深。atlas这名字乍一看冷冰冰的就是个古希腊扛天巨神的名字搁编程世界里又跟地图库、配置文件、数据库集群什么都沾点边。可正是这种模糊感让它成了我手头这个项目最贴切的名字。当时项目立项的时候需求其实特别朴素机构里有大量分散在不同系统里的数据资产团队想找一个统一入口把数据目录、血缘关系、负责人信息全部管理起来最好还能让业务同学自己上去查而不是每次都要找数仓同事要表结构。说白了就是要给数据中台做一张总地图。我翻了不少命名方案主数据管理、数据资产地图、元数据中心……都太干巴了直到一个同事随口说了句这不就是一张ATLAS吗项目名当场就定了。这个名字后来带来的好处远超预期。对内团队每天开发都在说atlas上加了什么表、atlas的血缘没跑出来指名道姓很清晰对外业务方一听就明白这系统是干嘛的不用解释。再后面我深入调研时才发现Apache Atlas本来就是业界做元数据管理的标准方案我们这名字算是踩在了同一个思路上。这期我就把整个项目从零到一的过程、架构设计、核心功能拆解以及我踩过的那些坑全部摊开来写一遍给想在数据治理方向上做点东西的朋友一个完整参考。1. 项目整体设计与思路拆解先说说这份设计思路是怎么来的。团队当时已经有一套相对完整的数据仓库Hive表几百张ClickHouse、MySQL、Kafka里也散落着大量数据。可一旦问到这张表的负责人是谁这个字段上游从哪来这个报表的数据链路几跳没人能立刻答得上来。要解决这类问题光靠建文档是没用的——文档永远是滞后的必须要有自动化采集、统一存储、可视化的元数据管理平台。1.1 核心需求解析我把需求拆成了三个层次这也是atlas项目的关键骨架元数据采集层要能从Hive、MySQL、ClickHouse、Kafka这些数据源里自动采集库表、字段、分区、字符集、负责人等基础信息并且能感知结构变化。血缘解析层能解析SQL任务把表A的字段b经过什么任务变成表C的字段d这种链路关系自动构建出来而且是字段级别的血缘。服务/展示层给数据开发、数据产品、业务分析师分别提供检索、浏览、详情查看、变更通知等功能最好还有权限控制。这三个层次缺一不可。如果只做采集那最多算个数据字典没有血缘根本回答不了这数据能不能信这种源头问题没有展示层研发同学压根没有使用的动力。仔细看这个需求是不是觉得特别像一本地图册每张表是一个城市字段是街道血缘是道路连接数据源是不同国家。人想在一张大地图上找到从A到B的路靠的就是清晰标注。所以atlas这个名字在逻辑上也完全成立——它远远超过了命名的范畴本身就是一个合适的产品隐喻。1.2 自研还是用开源一次艰难的选型技术选型上团队内部争论了很久。市面上一开始就有Apache Atlas、DataHub、Amundsen这几个成熟的元数据平台按理说拿来改改就能用。但我们的情况有点特殊数据源类型杂、团队人力少、对字段级血缘要求高。Apache Atlas跟Hive生态集成得最紧密血缘也支持但部署重要依赖HBaseSolr界面体验偏旧定制开发门槛高。我们团队没有专门的Java后端人力去改UI。DataHub现代化的数据目录产品界面漂亮有数据血缘可视化支持平台也多。但当时它的版本迭代太快API不稳定插件机制学习成本高快速接入有风险。Amundsen它更像数据发现工具血缘支持弱表级别还行字段级基本要靠自己扩展。自研快速版本一开始就排除了团队没这对时间。最后我们还是选了自研为主 开源为辅的路子。采集层和展示层自研血缘解析层用了部分开源工具做SQL解析但存储和API完全自己设计。原因很现实我们最核心的需求是字段级血缘和灵活的数据源适配而开源系统的血缘引擎一般是按他们自己的数据模型实现的想深度改造成本并不低。自研后整体框架简单可控出了问题能快速定位也方便后续扩展。1.3 技术架构总览整个系统我画了一个很清晰的分层架构这里文字描述一下采集端部署在各数据源所在网络的Agent支持定时拉取元数据通过HTTP上报。消息队列用Kafka接收采集上报的原始元数据做异步解耦。处理服务核心的服务模块负责元数据解析、血缘解析、数据标准化、变更检测。存储层元数据主存储用MySQL血缘关系用图数据库JanusGraph检索用ElasticSearch。展示端统一Web入口微服务架构前端用Vue实现。这套架构的核心思维是采集、处理、存储、展示四层分离每一层都可以独立扩展。比如以后要接入新的数据源只要新增一个采集插件不用改核心逻辑。这个灵活度是我们在初始设计时就定死的原则。2. 核心细节解析与实操要点架构敲定后马上进入每个模块的细节设计。这一部分我挑几个最核心也最容易翻车的环节来讲尤其是字段级血缘解析以及元数据采集的增量同步策略。2.1 元数据采集全量加增量的双轨策略刚开始做采集器的时候我想得特别简单每天定时把每个库的所有表元数据全量拉一遍然后覆盖写到MySQL里。后来数据量上了一定规模后这种做法的弊端立刻暴露出来Hive有几万张表时每天全量拉取要花好几个小时如果刚好在业务高峰期触发会让Hive Metastore压力变大影响正常查询。很多表几周都不变全量采集纯属浪费资源。元数据如果反复被覆盖历史变更记录就丢失了没法追溯这个字段上周的类型是什么。所以我把采集策略设计成了全量 增量双轨模式。首次接入某个数据源时做一次全量采集建立基线之后每隔10分钟做一次增量采集通过比对上次采集的最大修改时间Hive里对应LAST_ACCESS_TIME和PARAMETERS里的transient_lastDdlTime只拉取有变更的表。增量采集的关键点在于采集水位线的管理。我用一张collect_watermark表记录每个数据源、每个库上次成功采集的时间戳Agent每次上报都会带最新的水位处理服务端校验成功后更新。如果某次采集任务中途挂了下次可以从上次水位继续不用重来大幅降低了重复成本。还有一个细节是采集幂等性。上报的原始元数据必须带唯一键我这边设计的是数据源类型 数据源ID 库名 表名 字段名处理服务按这个唯一键做upsert。加了幂等控制后即使消息重复投递最终存储也不会错乱。这点在Kafka consumer端尤为重要我用的是enable.auto.commitfalse手动提交offset处理成功后才会commit。2.2 字段级血缘解析最硬的一块骨头血缘解析是整个atlas项目里最复杂也最让我头疼的部分。表级血缘还好做SQL里看到insert into table_b select * from table_a基本就能判定字段级血缘则需要做到table_a的col1对应table_b的col2中间还有各种表达式、子查询、CASE WHEN、UDF函数。这块我用了开源的SQL解析引擎比如JSQLParser、Antlr生成的Hive SQL解析器然后自己写血缘解析规则。核心思路可以拆成三步SQL标准化把SQL统一成AST语法树去掉注释、格式化大小写、统一引号处理。目标列映射解析INSERT语句的目标字段列表拿到要写入的每一列。源列追踪对SELECT列表中的每个表达式递归向下找遇到列引用就记录到源字段遇到函数就继续解析函数参数里的列引用遇到子查询就往里层钻。举个例子考虑这样一条SQLINSERT OVERWRITE TABLE dws_order_full PARTITION(dt 2024-01-01) SELECT user_id, SUM(amount) AS order_amount, CASE WHEN pay_status 1 THEN paid ELSE unpaid END AS pay_state FROM dwd_order_detail WHERE dt 2024-01-01 GROUP BY user_id;血缘解析的结果应该是dws_order_full.user_id←dwd_order_detail.user_iddws_order_full.order_amount←dwd_order_detail.amount经过SUM聚合dws_order_full.pay_state←dwd_order_detail.pay_status经过CASE WHEN转换这里的关键难点在于函数和表达式会改变血缘的语义。SUM、CASE WHEN这类操作严格说叫转换血缘字段源头并没有变但经过ETL后数据内容被加工了。为了不丢失信息我给每条血缘打上了transform_type标签标记它是直通、聚合转换还是条件转换。这样数据人员看血缘时一眼就能看出这跳关系是简单复制还是做了加工。前端可视化血缘的时候我把字段级血缘设计成了可展开的树状图。默认展示表级血缘点击表之间的连线可以下钻到字段级别的关联这样既避免了图面过载又能满足深度追踪的需求。2.3 元数据存储为什么选MySQL加图数据库混合存储血缘关系如果全塞MySQL路径查询会极其痛苦。比如要查表A的上游两跳有哪些表MySQL里要用递归查询表多了性能惨不忍睹。而图数据库天生就是为这种多跳关系设计的。存储层的分工存储数据内容选型理由MySQL基础元数据库表字段、负责人、标签、业务描述事务性好、易于管理、检索简单JanusGraph HBase血缘关系表级、字段级的边图遍历性能强支持多跳深度查询ElasticSearch元数据全文检索模糊搜索、分词、补全体验好字段级血缘在JanusGraph里怎么建模其实不复杂每个字段是一个Vertex字段与字段之间的血缘是一条EdgeEdge可以带transform_type、任务ID、时间戳、SQL摘要等属性。查询的时候以某个字段Vertex为起点沿指定方向遍历几步就能拿到完整上下游链路。这个模型对图数据库来说几乎是最佳实践查询速度在毫秒级。但是要提醒的是图数据库并不是万能的。一开始我们尝试把所有元数据都丢进图里后来发现简单属性的查询比如按负责人搜所有表反而没有MySQL方便而且图库运维成本明显更高。权衡之后才收敛为混合存储方案。数据少的时候意识不到这个问题数据量一到万级存储选型的价值就体现出来了。2.4 数据标准化与变更检测从不同数据源采集上来的元数据格式五花八门比如数据类型叫法就各不一样Hive里有string、varcharMySQL里有varchar(255)ClickHouse里有String。如果不对这些做标准化用户搜索的时候会非常痛苦。我建了两层标准化规则词法层统一大小写、去掉长度参数varchar(255)统一成varchar、枚举类型归纳。语义层把不同数据源的同义类型映射到一套通用类型体系上比如string、String、text都映射成标准字符串类型。变更检测是基于标准化后的元数据做的。每次采集完服务端会把新元数据和上一版本做字段级diff发现字段新增、删除、类型变更、注释变化就产生一条变更事件。事件会进Kafka下游可以做通知、生成审计日志。这块实践下来对数据治理特别有帮助能发现某张表悄悄删了一个已经被下游依赖的字段这类隐患。3. 完整实操从搭建到发布的全流程这部分我梳理一条从零把atlas系统跑起来的完整操作链路每一步都按我实际做过的来写。这里我用一个小型测试环境举例——3台4核16G的云服务器适合前期开发验证生产环境可适当提高规格。3.1 环境准备与基础组件安装第一步先把基础环境准备好。我的测试环境是基于CentOS 7.9的大概装的东西如下MySQL 8.0存元数据Kafka 2.13-3.4.0消息队列HBase 2.4.17 JanusGraph 1.0.0图存储ElasticSearch 7.17.9全文检索JDK 1.8后端运行环境每个组件单独部署不要图省事全装在一台机器上。实际踩过坑所有东西混装在一台机器ElasticSearch的堆内存和JanusGraph的内存会互相挤占JVM频繁GC查询会疯狂超时。部署的时候有几个小建议Kafka的log.retention.hours建议调到168小时以上血缘解析是异步的消息消费延迟时会丢消息。ElasticSearch的indices.fielddata.cache.size设成堆内存的20%即可不要贪大否则GC压力很大。HBase的RegionServer堆内存至少8G否则写入一多就会触发频繁的flush。3.2 后端服务模块搭建后端我分了几个微服务每个服务独立打包部署atlas-collector采集器服务部署在数据源侧的Agent。atlas-ingest接收采集数据的入口服务负责解析Kafka消息并写入存储。atlas-lineage血缘解析服务消费SQL变更事件异步构建血缘关系。atlas-api统一查询接口供前端调用。atlas-notify变更通知服务。启动顺序有讲究先启动atlas-ingest和atlas-lineage等它们成功注册到注册中心后再启动atlas-collector开始采集。如果先把采集器拉起来大量元数据直接涌入Kafka消费端还没就绪可能造成消息积压。我第一次部署时没注意这个顺序结果Kafka topic里积压了几十万条消息消费追了好久才追平。后端服务的配置文件我用的是YAML格式核心的Kafka消费配置长这样spring: kafka: bootstrap-servers: kafka01:9092,kafka02:9092,kafka03:9092 consumer: group-id: atlas-lineage-group enable-auto-commit: false auto-offset-reset: earliest max-poll-records: 500 listener: concurrency: 6注意enable-auto-commit: false配合手动提交offset。这样消息处理失败了还能重新消费否则一旦消费端程序处理过程中宕机没有提交offset的那些消息会丢失。3.3 数据源接入配置以Hive数据源为例接入过程是这样在采集端的配置文件里加一段atlas.datasource.hive.enabletrue atlas.datasource.hive.metastore.uristhrift://hive-metastore:9083 atlas.datasource.hive.namespacedefault atlas.datasource.hive.exclude.databasestemp,test atlas.datasource.hive.fetch.size1000配置里的exclude.databases特别关键。有些数仓的临时库和测试库数据变化频繁、量又大不排除掉的话采集压力会大很多。我第一次忽略了这块测试库里的几十张临时表天天变增量采集水位一直往前跑真正核心库的元数据反倒延迟了好几分钟才入库。配置完成后采集器会把自身注册到atlas-ingest然后开始按调度周期拉取元数据。同时采集器还会监听Hive的DDL事件。Hive Metastore有个HiveMetaStoreEventListener机制可以在表结构变化时触发回调采集器实现了这个接口把DDL变更实时上报这样增量采集的时效性就能从分钟级提升到秒级。3.4 血缘任务接入从SQL日志到血缘血缘要接入最重要的是能拿到所有跑在数据平台上的SQL任务。我在数据平台的任务调度器里加了一个SQL采集钩子任务执行前把SQL语句异步上报到Kafka的atlas-sql-topic执行成功后把任务ID、执行时间、目标表信息一起上报。这样血缘解析服务就能拿到完整上下文。如果你们没有统一调度平台退而求其次的方案是解析HiveServer2或者其他引擎的审计日志。HiveServer2的审计日志里会记录每次提交的SQL把审计日志同步到Kafka同样可以做血缘解析。这个方案的问题在于只有SQL没有任务维度信息血缘只能做到表字段级别但已经覆盖了80%的需求。3.5 前端页面功能落地前端我用了Vue 3加Element Plus核心页面有四个检索页全站搜索框支持模糊搜表名、字段名、别名、负责人结果按数据源类型打标分组。表详情页展示表的基础属性、字段列表、分区信息、负责团队按钮、描述编辑、标签管理、变更历史Tab。血缘图页用AntV G6绘制血缘图支持点击节点展开上下游支持切换表级和字段级视图。数据源管理页展示所有已接入的数据源及其采集状态、最近采集时间、采集耗时、异常数量。最麻烦的是血缘图的渲染性能。一开始直接用G6渲染全链路一个核心表的上游三跳有上千个节点时页面直接卡死。后来做了两个优化才解决第一默认只展示第一跳点击展开才加载下一跳第二服务端做节点裁剪只返回表级节点字段级节点延迟加载。做完之后渲染速度从十几秒优化到了一秒内。4. 常见问题与排查技巧实录系统上线到现在各种问题出了不少有些是设计时就能预见到的有些则是完全没想到的。挑几个典型的记录一下给后来人当参考。4.1 Kafka消息积压导致血缘更新延迟现象某天发现atlas血缘图上出现了昨天的任务但今天的还没有更新去Kafka看消费延迟发现有上百万条积压。排查过程先看血缘解析服务的日志发现一直报ES批量插入超时。进一步看原来是ES集群有个节点磁盘使用率超过了85%官方默认的cluster.routing.allocation.disk.watermark.low为85%达到这个水位后ES会停止向该节点分配新分片写入性能骤降。解决方案清理了ES节点上历史索引再把水位线临时调高PUT _cluster/settings { transient: { cluster.routing.allocation.disk.watermark.low: 90%, cluster.routing.allocation.disk.watermark.high: 95% } }调整之后写入恢复积压的消息逐步消费完。这里注意水位线调高只适合临时应急长期还是得扩容或者删旧数据。4.2 增量采集丢数据Hive的lastDdlTime不准现象接入采集后下游反馈某张关键表元数据一直不更新但表结构明明昨天改过。排查过程开始怀疑是采集任务没跑查了采集日志发现正常。后来手动查了下那张表的lastDdlTime发现时间戳还是上周的。这才想起来Hive的lastDdlTime在不少场景下并不会自动更新比如直接修改HDFS文件、用alter table touch之外的命令修改表属性等。其实touch命令可以刷新但很多人根本不知道这条命令。解决方案调整了采集策略不再完全依赖lastDdlTime而是每天凌晨对全量表做一次轻量扫描比对表名清单和分区数发现差异再触发深度采集。说白了就是保留每天一次全量清单对比作为兜底方案增量采集只负责缩短时效性。4.3 血缘解析漏报子查询和CTE覆盖不全现象数据团队反映某张报表的上游血缘始终缺几个中间表。排查过程手动拿那条SQL测试发现SQL里有大量CTE表达式WITH tmp1 AS ( SELECT user_id, SUM(amount) FROM table_x GROUP BY user_id ), tmp2 AS ( SELECT user_id, COUNT(*) FROM tmp1 GROUP BY user_id ) INSERT OVERWRITE TABLE tmp3 SELECT user_id, _c1 FROM tmp2;SQL解析引擎解析CTE的时候没有把CTE内部的表引用关联到最终目标表。这个问题处理起来比较繁琐需要单独维护CTE的映射链每个CTE别名对应一个内部临时表临时表的血缘继续向里层解析。解决方案在两处做了修复。第一SQL解析前先做CTE展开提前把CTE的原始表结构记录下来后续血缘关系从最内层原始表开始追踪第二加上一层血缘校验逻辑如果发现目标表字段的源是空就触发一次深度SQL重解析并打印警告日志方便人工排查。修复之后CTE血缘的准确率从80%左右提升到了95%以上。4.4 检索分词导致搜不到内容现象用户搜Hive订单宽表搜不出来任何东西但表名里明明包含这个字。排查过程ES默认的分词器是standard对中文只是按字切分不会按词切分。订单两个字被拆成了订和单两个独立token搜索订单时匹配结果反而不理想。解决方案为表名和字段名加了IK分词器{ settings: { analysis: { analyzer: { default: { type: ik_max_word } } } } }把默认analyzer换成ik_max_word后中文检索效果立竿见影。还有一个细节很多表名会是dwd_order_detail这种下划线风格我又加了一个字段专门存去掉下划线的表名比如dwd order detail这样用户输入订单明细也能匹配上实际使用友好很多。4.5 权限管理如何做先粗后细很多开源元数据系统在权限上做得都很轻大家通常觉得数据目录嘛只读的不需要什么权限。实际用下来发现这是一个很大的误区。数据目录会暴露敏感信息比如某些表中身份证号、手机号字段如果权限控制不当内部员工就能看到所有数据资产的字段名甚至通过血缘反推业务模型在企业里这是非常大的数据安全风险。我做了一套先粗后细的权限控制粗粒度按角色区分。管理员、数据开发、分析师、访客四种角色每种角色默认能看不同范围的数据源和库。细粒度字段级权限。某些核心库的某些敏感字段只对指定角色可见其他角色即使能搜到这张表也看不到字段明细。权限控制还和变更通知关联当一张表被标记为敏感表后任何采集到的DDL变更都会立刻触发告警通知表负责人。这样做下来数据目录从单纯的技术工具变成了一部分合规工具。4.6 血缘展示性能图太大怎么办前面提到血缘图渲染卡顿的优化这里再补充一个思路服务端做血缘裁剪。有些表是维表被几百个下游引用全链路展开完全没有意义所以我在展示链路时加了只显示核心链路开关。核心链路的定义设计成只显示那些有字段级血缘且最近30天有活跃任务的表。这样做并不会影响血缘关系的准确性只是展示层做了聚合整个图会精简很多。5. 一些经验心得和扩展建议atlas上线到现在差不多半年了从最初只有基础元数据采集到字段级血缘、敏感数据识别、变更通知每个功能都是被真实用户需求逼出来的。如果让我重新做一遍有件事情我会放在架构设计阶段而不是上线后审计日志的留存设计。现在数据湖里的元数据变更越来越频繁用户要通过什么时间谁改了这张表结构来做质量追溯如果一开始就在数据模型里设计好审计日志的保留周期、归档策略、查询接口后面会省很多事。另外想强调下血缘解析别指望一次做到完美。SQL的写法千奇百怪总有解析引擎覆盖不到的语法。我们在血缘解析服务里加了一个置信度字段每条血缘都标记自动解析或人工确认状态业务方看到人工确认的血缘会认为更可信。这个设计完全是实践中长出来的很接地气也提高了业务方的信任感。启动一个这样的数据资产管理项目千万别想着一步到位。我的建议是先跑通元数据采集和检索再上血缘最后才谈权限和合规一步一步来。每做完一个环节拿去给目标用户试用听他们的反馈再迭代。数据治理工具最容易犯的毛病就是闭门造车做出来一堆功能用户根本不用。我们踩过这个坑希望后来人能少走点弯路。最后再分享一个提高使用率的小细节把atlas的检索入口加到团队浏览器的默认首页里同时做了浏览器插件选中SQL里的表名右键就能直接跳转atlas查看表详情。就这个简单的入口一下子让团队的使用频率翻了好几倍。工具做得再好用户能找到入口才是第一位的。
数据治理实战：从零构建元数据管理平台Atlas的架构设计与踩坑记录
怎么写才不像AI我直接给你来点实在的。起名字这种事看起来简单真做起来才知道里面的坑有多深。atlas这名字乍一看冷冰冰的就是个古希腊扛天巨神的名字搁编程世界里又跟地图库、配置文件、数据库集群什么都沾点边。可正是这种模糊感让它成了我手头这个项目最贴切的名字。当时项目立项的时候需求其实特别朴素机构里有大量分散在不同系统里的数据资产团队想找一个统一入口把数据目录、血缘关系、负责人信息全部管理起来最好还能让业务同学自己上去查而不是每次都要找数仓同事要表结构。说白了就是要给数据中台做一张总地图。我翻了不少命名方案主数据管理、数据资产地图、元数据中心……都太干巴了直到一个同事随口说了句这不就是一张ATLAS吗项目名当场就定了。这个名字后来带来的好处远超预期。对内团队每天开发都在说atlas上加了什么表、atlas的血缘没跑出来指名道姓很清晰对外业务方一听就明白这系统是干嘛的不用解释。再后面我深入调研时才发现Apache Atlas本来就是业界做元数据管理的标准方案我们这名字算是踩在了同一个思路上。这期我就把整个项目从零到一的过程、架构设计、核心功能拆解以及我踩过的那些坑全部摊开来写一遍给想在数据治理方向上做点东西的朋友一个完整参考。1. 项目整体设计与思路拆解先说说这份设计思路是怎么来的。团队当时已经有一套相对完整的数据仓库Hive表几百张ClickHouse、MySQL、Kafka里也散落着大量数据。可一旦问到这张表的负责人是谁这个字段上游从哪来这个报表的数据链路几跳没人能立刻答得上来。要解决这类问题光靠建文档是没用的——文档永远是滞后的必须要有自动化采集、统一存储、可视化的元数据管理平台。1.1 核心需求解析我把需求拆成了三个层次这也是atlas项目的关键骨架元数据采集层要能从Hive、MySQL、ClickHouse、Kafka这些数据源里自动采集库表、字段、分区、字符集、负责人等基础信息并且能感知结构变化。血缘解析层能解析SQL任务把表A的字段b经过什么任务变成表C的字段d这种链路关系自动构建出来而且是字段级别的血缘。服务/展示层给数据开发、数据产品、业务分析师分别提供检索、浏览、详情查看、变更通知等功能最好还有权限控制。这三个层次缺一不可。如果只做采集那最多算个数据字典没有血缘根本回答不了这数据能不能信这种源头问题没有展示层研发同学压根没有使用的动力。仔细看这个需求是不是觉得特别像一本地图册每张表是一个城市字段是街道血缘是道路连接数据源是不同国家。人想在一张大地图上找到从A到B的路靠的就是清晰标注。所以atlas这个名字在逻辑上也完全成立——它远远超过了命名的范畴本身就是一个合适的产品隐喻。1.2 自研还是用开源一次艰难的选型技术选型上团队内部争论了很久。市面上一开始就有Apache Atlas、DataHub、Amundsen这几个成熟的元数据平台按理说拿来改改就能用。但我们的情况有点特殊数据源类型杂、团队人力少、对字段级血缘要求高。Apache Atlas跟Hive生态集成得最紧密血缘也支持但部署重要依赖HBaseSolr界面体验偏旧定制开发门槛高。我们团队没有专门的Java后端人力去改UI。DataHub现代化的数据目录产品界面漂亮有数据血缘可视化支持平台也多。但当时它的版本迭代太快API不稳定插件机制学习成本高快速接入有风险。Amundsen它更像数据发现工具血缘支持弱表级别还行字段级基本要靠自己扩展。自研快速版本一开始就排除了团队没这对时间。最后我们还是选了自研为主 开源为辅的路子。采集层和展示层自研血缘解析层用了部分开源工具做SQL解析但存储和API完全自己设计。原因很现实我们最核心的需求是字段级血缘和灵活的数据源适配而开源系统的血缘引擎一般是按他们自己的数据模型实现的想深度改造成本并不低。自研后整体框架简单可控出了问题能快速定位也方便后续扩展。1.3 技术架构总览整个系统我画了一个很清晰的分层架构这里文字描述一下采集端部署在各数据源所在网络的Agent支持定时拉取元数据通过HTTP上报。消息队列用Kafka接收采集上报的原始元数据做异步解耦。处理服务核心的服务模块负责元数据解析、血缘解析、数据标准化、变更检测。存储层元数据主存储用MySQL血缘关系用图数据库JanusGraph检索用ElasticSearch。展示端统一Web入口微服务架构前端用Vue实现。这套架构的核心思维是采集、处理、存储、展示四层分离每一层都可以独立扩展。比如以后要接入新的数据源只要新增一个采集插件不用改核心逻辑。这个灵活度是我们在初始设计时就定死的原则。2. 核心细节解析与实操要点架构敲定后马上进入每个模块的细节设计。这一部分我挑几个最核心也最容易翻车的环节来讲尤其是字段级血缘解析以及元数据采集的增量同步策略。2.1 元数据采集全量加增量的双轨策略刚开始做采集器的时候我想得特别简单每天定时把每个库的所有表元数据全量拉一遍然后覆盖写到MySQL里。后来数据量上了一定规模后这种做法的弊端立刻暴露出来Hive有几万张表时每天全量拉取要花好几个小时如果刚好在业务高峰期触发会让Hive Metastore压力变大影响正常查询。很多表几周都不变全量采集纯属浪费资源。元数据如果反复被覆盖历史变更记录就丢失了没法追溯这个字段上周的类型是什么。所以我把采集策略设计成了全量 增量双轨模式。首次接入某个数据源时做一次全量采集建立基线之后每隔10分钟做一次增量采集通过比对上次采集的最大修改时间Hive里对应LAST_ACCESS_TIME和PARAMETERS里的transient_lastDdlTime只拉取有变更的表。增量采集的关键点在于采集水位线的管理。我用一张collect_watermark表记录每个数据源、每个库上次成功采集的时间戳Agent每次上报都会带最新的水位处理服务端校验成功后更新。如果某次采集任务中途挂了下次可以从上次水位继续不用重来大幅降低了重复成本。还有一个细节是采集幂等性。上报的原始元数据必须带唯一键我这边设计的是数据源类型 数据源ID 库名 表名 字段名处理服务按这个唯一键做upsert。加了幂等控制后即使消息重复投递最终存储也不会错乱。这点在Kafka consumer端尤为重要我用的是enable.auto.commitfalse手动提交offset处理成功后才会commit。2.2 字段级血缘解析最硬的一块骨头血缘解析是整个atlas项目里最复杂也最让我头疼的部分。表级血缘还好做SQL里看到insert into table_b select * from table_a基本就能判定字段级血缘则需要做到table_a的col1对应table_b的col2中间还有各种表达式、子查询、CASE WHEN、UDF函数。这块我用了开源的SQL解析引擎比如JSQLParser、Antlr生成的Hive SQL解析器然后自己写血缘解析规则。核心思路可以拆成三步SQL标准化把SQL统一成AST语法树去掉注释、格式化大小写、统一引号处理。目标列映射解析INSERT语句的目标字段列表拿到要写入的每一列。源列追踪对SELECT列表中的每个表达式递归向下找遇到列引用就记录到源字段遇到函数就继续解析函数参数里的列引用遇到子查询就往里层钻。举个例子考虑这样一条SQLINSERT OVERWRITE TABLE dws_order_full PARTITION(dt 2024-01-01) SELECT user_id, SUM(amount) AS order_amount, CASE WHEN pay_status 1 THEN paid ELSE unpaid END AS pay_state FROM dwd_order_detail WHERE dt 2024-01-01 GROUP BY user_id;血缘解析的结果应该是dws_order_full.user_id←dwd_order_detail.user_iddws_order_full.order_amount←dwd_order_detail.amount经过SUM聚合dws_order_full.pay_state←dwd_order_detail.pay_status经过CASE WHEN转换这里的关键难点在于函数和表达式会改变血缘的语义。SUM、CASE WHEN这类操作严格说叫转换血缘字段源头并没有变但经过ETL后数据内容被加工了。为了不丢失信息我给每条血缘打上了transform_type标签标记它是直通、聚合转换还是条件转换。这样数据人员看血缘时一眼就能看出这跳关系是简单复制还是做了加工。前端可视化血缘的时候我把字段级血缘设计成了可展开的树状图。默认展示表级血缘点击表之间的连线可以下钻到字段级别的关联这样既避免了图面过载又能满足深度追踪的需求。2.3 元数据存储为什么选MySQL加图数据库混合存储血缘关系如果全塞MySQL路径查询会极其痛苦。比如要查表A的上游两跳有哪些表MySQL里要用递归查询表多了性能惨不忍睹。而图数据库天生就是为这种多跳关系设计的。存储层的分工存储数据内容选型理由MySQL基础元数据库表字段、负责人、标签、业务描述事务性好、易于管理、检索简单JanusGraph HBase血缘关系表级、字段级的边图遍历性能强支持多跳深度查询ElasticSearch元数据全文检索模糊搜索、分词、补全体验好字段级血缘在JanusGraph里怎么建模其实不复杂每个字段是一个Vertex字段与字段之间的血缘是一条EdgeEdge可以带transform_type、任务ID、时间戳、SQL摘要等属性。查询的时候以某个字段Vertex为起点沿指定方向遍历几步就能拿到完整上下游链路。这个模型对图数据库来说几乎是最佳实践查询速度在毫秒级。但是要提醒的是图数据库并不是万能的。一开始我们尝试把所有元数据都丢进图里后来发现简单属性的查询比如按负责人搜所有表反而没有MySQL方便而且图库运维成本明显更高。权衡之后才收敛为混合存储方案。数据少的时候意识不到这个问题数据量一到万级存储选型的价值就体现出来了。2.4 数据标准化与变更检测从不同数据源采集上来的元数据格式五花八门比如数据类型叫法就各不一样Hive里有string、varcharMySQL里有varchar(255)ClickHouse里有String。如果不对这些做标准化用户搜索的时候会非常痛苦。我建了两层标准化规则词法层统一大小写、去掉长度参数varchar(255)统一成varchar、枚举类型归纳。语义层把不同数据源的同义类型映射到一套通用类型体系上比如string、String、text都映射成标准字符串类型。变更检测是基于标准化后的元数据做的。每次采集完服务端会把新元数据和上一版本做字段级diff发现字段新增、删除、类型变更、注释变化就产生一条变更事件。事件会进Kafka下游可以做通知、生成审计日志。这块实践下来对数据治理特别有帮助能发现某张表悄悄删了一个已经被下游依赖的字段这类隐患。3. 完整实操从搭建到发布的全流程这部分我梳理一条从零把atlas系统跑起来的完整操作链路每一步都按我实际做过的来写。这里我用一个小型测试环境举例——3台4核16G的云服务器适合前期开发验证生产环境可适当提高规格。3.1 环境准备与基础组件安装第一步先把基础环境准备好。我的测试环境是基于CentOS 7.9的大概装的东西如下MySQL 8.0存元数据Kafka 2.13-3.4.0消息队列HBase 2.4.17 JanusGraph 1.0.0图存储ElasticSearch 7.17.9全文检索JDK 1.8后端运行环境每个组件单独部署不要图省事全装在一台机器上。实际踩过坑所有东西混装在一台机器ElasticSearch的堆内存和JanusGraph的内存会互相挤占JVM频繁GC查询会疯狂超时。部署的时候有几个小建议Kafka的log.retention.hours建议调到168小时以上血缘解析是异步的消息消费延迟时会丢消息。ElasticSearch的indices.fielddata.cache.size设成堆内存的20%即可不要贪大否则GC压力很大。HBase的RegionServer堆内存至少8G否则写入一多就会触发频繁的flush。3.2 后端服务模块搭建后端我分了几个微服务每个服务独立打包部署atlas-collector采集器服务部署在数据源侧的Agent。atlas-ingest接收采集数据的入口服务负责解析Kafka消息并写入存储。atlas-lineage血缘解析服务消费SQL变更事件异步构建血缘关系。atlas-api统一查询接口供前端调用。atlas-notify变更通知服务。启动顺序有讲究先启动atlas-ingest和atlas-lineage等它们成功注册到注册中心后再启动atlas-collector开始采集。如果先把采集器拉起来大量元数据直接涌入Kafka消费端还没就绪可能造成消息积压。我第一次部署时没注意这个顺序结果Kafka topic里积压了几十万条消息消费追了好久才追平。后端服务的配置文件我用的是YAML格式核心的Kafka消费配置长这样spring: kafka: bootstrap-servers: kafka01:9092,kafka02:9092,kafka03:9092 consumer: group-id: atlas-lineage-group enable-auto-commit: false auto-offset-reset: earliest max-poll-records: 500 listener: concurrency: 6注意enable-auto-commit: false配合手动提交offset。这样消息处理失败了还能重新消费否则一旦消费端程序处理过程中宕机没有提交offset的那些消息会丢失。3.3 数据源接入配置以Hive数据源为例接入过程是这样在采集端的配置文件里加一段atlas.datasource.hive.enabletrue atlas.datasource.hive.metastore.uristhrift://hive-metastore:9083 atlas.datasource.hive.namespacedefault atlas.datasource.hive.exclude.databasestemp,test atlas.datasource.hive.fetch.size1000配置里的exclude.databases特别关键。有些数仓的临时库和测试库数据变化频繁、量又大不排除掉的话采集压力会大很多。我第一次忽略了这块测试库里的几十张临时表天天变增量采集水位一直往前跑真正核心库的元数据反倒延迟了好几分钟才入库。配置完成后采集器会把自身注册到atlas-ingest然后开始按调度周期拉取元数据。同时采集器还会监听Hive的DDL事件。Hive Metastore有个HiveMetaStoreEventListener机制可以在表结构变化时触发回调采集器实现了这个接口把DDL变更实时上报这样增量采集的时效性就能从分钟级提升到秒级。3.4 血缘任务接入从SQL日志到血缘血缘要接入最重要的是能拿到所有跑在数据平台上的SQL任务。我在数据平台的任务调度器里加了一个SQL采集钩子任务执行前把SQL语句异步上报到Kafka的atlas-sql-topic执行成功后把任务ID、执行时间、目标表信息一起上报。这样血缘解析服务就能拿到完整上下文。如果你们没有统一调度平台退而求其次的方案是解析HiveServer2或者其他引擎的审计日志。HiveServer2的审计日志里会记录每次提交的SQL把审计日志同步到Kafka同样可以做血缘解析。这个方案的问题在于只有SQL没有任务维度信息血缘只能做到表字段级别但已经覆盖了80%的需求。3.5 前端页面功能落地前端我用了Vue 3加Element Plus核心页面有四个检索页全站搜索框支持模糊搜表名、字段名、别名、负责人结果按数据源类型打标分组。表详情页展示表的基础属性、字段列表、分区信息、负责团队按钮、描述编辑、标签管理、变更历史Tab。血缘图页用AntV G6绘制血缘图支持点击节点展开上下游支持切换表级和字段级视图。数据源管理页展示所有已接入的数据源及其采集状态、最近采集时间、采集耗时、异常数量。最麻烦的是血缘图的渲染性能。一开始直接用G6渲染全链路一个核心表的上游三跳有上千个节点时页面直接卡死。后来做了两个优化才解决第一默认只展示第一跳点击展开才加载下一跳第二服务端做节点裁剪只返回表级节点字段级节点延迟加载。做完之后渲染速度从十几秒优化到了一秒内。4. 常见问题与排查技巧实录系统上线到现在各种问题出了不少有些是设计时就能预见到的有些则是完全没想到的。挑几个典型的记录一下给后来人当参考。4.1 Kafka消息积压导致血缘更新延迟现象某天发现atlas血缘图上出现了昨天的任务但今天的还没有更新去Kafka看消费延迟发现有上百万条积压。排查过程先看血缘解析服务的日志发现一直报ES批量插入超时。进一步看原来是ES集群有个节点磁盘使用率超过了85%官方默认的cluster.routing.allocation.disk.watermark.low为85%达到这个水位后ES会停止向该节点分配新分片写入性能骤降。解决方案清理了ES节点上历史索引再把水位线临时调高PUT _cluster/settings { transient: { cluster.routing.allocation.disk.watermark.low: 90%, cluster.routing.allocation.disk.watermark.high: 95% } }调整之后写入恢复积压的消息逐步消费完。这里注意水位线调高只适合临时应急长期还是得扩容或者删旧数据。4.2 增量采集丢数据Hive的lastDdlTime不准现象接入采集后下游反馈某张关键表元数据一直不更新但表结构明明昨天改过。排查过程开始怀疑是采集任务没跑查了采集日志发现正常。后来手动查了下那张表的lastDdlTime发现时间戳还是上周的。这才想起来Hive的lastDdlTime在不少场景下并不会自动更新比如直接修改HDFS文件、用alter table touch之外的命令修改表属性等。其实touch命令可以刷新但很多人根本不知道这条命令。解决方案调整了采集策略不再完全依赖lastDdlTime而是每天凌晨对全量表做一次轻量扫描比对表名清单和分区数发现差异再触发深度采集。说白了就是保留每天一次全量清单对比作为兜底方案增量采集只负责缩短时效性。4.3 血缘解析漏报子查询和CTE覆盖不全现象数据团队反映某张报表的上游血缘始终缺几个中间表。排查过程手动拿那条SQL测试发现SQL里有大量CTE表达式WITH tmp1 AS ( SELECT user_id, SUM(amount) FROM table_x GROUP BY user_id ), tmp2 AS ( SELECT user_id, COUNT(*) FROM tmp1 GROUP BY user_id ) INSERT OVERWRITE TABLE tmp3 SELECT user_id, _c1 FROM tmp2;SQL解析引擎解析CTE的时候没有把CTE内部的表引用关联到最终目标表。这个问题处理起来比较繁琐需要单独维护CTE的映射链每个CTE别名对应一个内部临时表临时表的血缘继续向里层解析。解决方案在两处做了修复。第一SQL解析前先做CTE展开提前把CTE的原始表结构记录下来后续血缘关系从最内层原始表开始追踪第二加上一层血缘校验逻辑如果发现目标表字段的源是空就触发一次深度SQL重解析并打印警告日志方便人工排查。修复之后CTE血缘的准确率从80%左右提升到了95%以上。4.4 检索分词导致搜不到内容现象用户搜Hive订单宽表搜不出来任何东西但表名里明明包含这个字。排查过程ES默认的分词器是standard对中文只是按字切分不会按词切分。订单两个字被拆成了订和单两个独立token搜索订单时匹配结果反而不理想。解决方案为表名和字段名加了IK分词器{ settings: { analysis: { analyzer: { default: { type: ik_max_word } } } } }把默认analyzer换成ik_max_word后中文检索效果立竿见影。还有一个细节很多表名会是dwd_order_detail这种下划线风格我又加了一个字段专门存去掉下划线的表名比如dwd order detail这样用户输入订单明细也能匹配上实际使用友好很多。4.5 权限管理如何做先粗后细很多开源元数据系统在权限上做得都很轻大家通常觉得数据目录嘛只读的不需要什么权限。实际用下来发现这是一个很大的误区。数据目录会暴露敏感信息比如某些表中身份证号、手机号字段如果权限控制不当内部员工就能看到所有数据资产的字段名甚至通过血缘反推业务模型在企业里这是非常大的数据安全风险。我做了一套先粗后细的权限控制粗粒度按角色区分。管理员、数据开发、分析师、访客四种角色每种角色默认能看不同范围的数据源和库。细粒度字段级权限。某些核心库的某些敏感字段只对指定角色可见其他角色即使能搜到这张表也看不到字段明细。权限控制还和变更通知关联当一张表被标记为敏感表后任何采集到的DDL变更都会立刻触发告警通知表负责人。这样做下来数据目录从单纯的技术工具变成了一部分合规工具。4.6 血缘展示性能图太大怎么办前面提到血缘图渲染卡顿的优化这里再补充一个思路服务端做血缘裁剪。有些表是维表被几百个下游引用全链路展开完全没有意义所以我在展示链路时加了只显示核心链路开关。核心链路的定义设计成只显示那些有字段级血缘且最近30天有活跃任务的表。这样做并不会影响血缘关系的准确性只是展示层做了聚合整个图会精简很多。5. 一些经验心得和扩展建议atlas上线到现在差不多半年了从最初只有基础元数据采集到字段级血缘、敏感数据识别、变更通知每个功能都是被真实用户需求逼出来的。如果让我重新做一遍有件事情我会放在架构设计阶段而不是上线后审计日志的留存设计。现在数据湖里的元数据变更越来越频繁用户要通过什么时间谁改了这张表结构来做质量追溯如果一开始就在数据模型里设计好审计日志的保留周期、归档策略、查询接口后面会省很多事。另外想强调下血缘解析别指望一次做到完美。SQL的写法千奇百怪总有解析引擎覆盖不到的语法。我们在血缘解析服务里加了一个置信度字段每条血缘都标记自动解析或人工确认状态业务方看到人工确认的血缘会认为更可信。这个设计完全是实践中长出来的很接地气也提高了业务方的信任感。启动一个这样的数据资产管理项目千万别想着一步到位。我的建议是先跑通元数据采集和检索再上血缘最后才谈权限和合规一步一步来。每做完一个环节拿去给目标用户试用听他们的反馈再迭代。数据治理工具最容易犯的毛病就是闭门造车做出来一堆功能用户根本不用。我们踩过这个坑希望后来人能少走点弯路。最后再分享一个提高使用率的小细节把atlas的检索入口加到团队浏览器的默认首页里同时做了浏览器插件选中SQL里的表名右键就能直接跳转atlas查看表详情。就这个简单的入口一下子让团队的使用频率翻了好几倍。工具做得再好用户能找到入口才是第一位的。
