表越多不代表平台越重：DataHub 的元数据采集频率与血缘粒度怎么定

几百张表的环境，采集任务比上万张表的环境还慢

几百张表的环境，采集任务比上万张表的环境还慢——差别不在表有多少，而在一个开了列级血缘、每天全量扫，另一个只做表级、按变更触发。这个反差在数据团队里经常出现，但第一次遇到的人多半会往错误的方向排查：先看机器是不是不够，再看是不是采集源配错了，最后才想到去看血缘粒度的开关。

把两个环境拆开看。环境 A 大概四五百张业务表，二十来个 BI 报表，几十个调度任务；采集配置是每天一次全量扫描，血缘开到字段级。环境 B 一万多张表，几十个数据源，血缘只到数据集级，采集按变更触发。按直觉 B 应该更重，实际跑起来却常常是 A 的采集任务先超时。原因不在表数：A 每跑一次采集，要把落到这些表上的 SQL 语句全部取出来做解析，一张表有几十个字段，一条 SQL 又可能产出几十到上百条字段级的边；这些边要逐条进图索引。B 的表虽然多，但数据集级血缘大多能从作业元数据或者调度依赖里直接读到，不需 要解析 SQL，一次采集的耗时主要花在"比对有没有变"上，而不是"算边"。

这个对比说明一件很关键的事：元数据平台的资源压力跟业务数据量几乎没关系。一张存了几十亿行的表和一张空表，在元数据平台里的对象大小差别很小，元数据记录的是结构、归属、上下游，不是行。真正决定这个平台有多重的是另外三个变量。把这三个变量认清楚，比多堆两台机器有用得多。

下面的讨论都以 DataHub 这类"元数据服务 + 前端 + 多个存储后端"的架构为背景。DataHub 由 LinkedIn 开源、目前由社区维护，典型部署里包含元数据存储（关系型数据库）、检索索引（Elasticsearch 或同类）、图索引（图数据库或基于索引实现的图服务），以及用于传递元数据变更与审计事件的消息队列。具体的默认值、参数名与行为在不同版本之间有差异，需要以实际版本文档为准。

真正决定负载的三个变量，各自乘在哪一项上

第一个变量是元数据对象数。它决定存储基线与单次全量采集的基线耗时。这里要注意"对象"不等于"表"：一个数据源里的 schema、表、字段、仪表盘、图表、任务、管道、数据平台用户与组，全都是独立实体。一个五百张表的库，如果每张表平均四十个字段，实体数一下子就从几百变成两万多，再加 BI 侧的仪表盘与图表，规模很容易翻上去。所以估算对象数时不能拿信息库里统计表数量的查询结果当答案，要把字段、任务、图表都算进去，通常比团队自己以为的规模大一到两个量级。

第二个变量是采集频率。它乘在单位时间写入量与对源库的扫描压力上。频率提高一档，扫描次数成倍增加，每次扫描都要去源的元数据库里拉一遍结构，这部分压力是线性增长的。但写入量并不跟着线性涨：多数对象没变，采集源会把没变的部分去掉，真正进入消息队列的变更事件数量取决于真实的元数据变更率，而不是扫描次数。这一点经常被搞反，以为采集频率翻倍写入量就翻倍，其实写入量更接近"这段时间内真的改了多少东西"。

第三个变量是血缘粒度，也就是表级还是列级。它乘在图存储的边数与单次采集的解析耗时上，是三者里最危险的一个。表级血缘的边数量级跟表数量级相当；列级血缘的边数量级跟"被覆盖到的列"的数量级相当，而列数通常是表数的几十倍。一次演示里把列级血缘打开，看到字段级的上下游链很漂亮，之后就没人敢关——因为一旦关掉，依赖它的查询与告警会直接失效。而它恰恰是把采集耗时与图存储放大一到两个数量级的那一项。

采集侧的两种触发方式：定时扫描与变更上报

采集方式分两类。拉取式是采集源定时去数据源扫元数据，比如定时连到数据库读系统表、读 Hive Metastore、读调度系统的任务定义；推送式是生产方主动调用接口或发送事件上报变更，比如 DDL 执行完之后由变更流程发一条事件，或者数据开发平台在作业发布时把上下游关系推过来。

拉取式的好处是对生产方零改造，接一个新数据源只要配好连接与账号就能跑，绝大多数团队一开始都是这么做的。代价是重复扫描：不管有没有变化，每次都要把结构拉回来逐项比对。对象数越大，这个比对过程越长，而它的产出经常是零。另一个代价是对源库的压力，扫描要读系统表，频率高了会跟业务查询抢资源，尤其源库本身负载就高的时候。

推送式省掉了扫描，也更及时，但对生产方有改造要求：得有地方埋点，得保证事件不丢，还得处理生产方改造不到位导致的元数据缺失。缺失比滞后更难发现——扫描式缺了会在下次扫描补上，推送式丢了就是真的没了，直到有人手工触发一次重建。

比较现实的做法是混合：核心数据源（数仓主库、核心调度系统）做推送，长尾数据源保留低频拉取兜底。核心源变更频繁、影响面大，值得为它做改造；长尾源一个月改不了两次，一周扫一次足够，扫描成本可以忽略。这样既把压力集中在可控的少数源上，又不会因为某个源没接入推送就出现空白。

频率每抬一档，代价落在哪里

频率从每天一次提到每小时一次，扫描次数乘二十四。这一档提升带来的东西要分三处看：源库压力、采集任务占用、写入量。前两处是接近线性的，第三处不是。

写入量的规律是：进入系统的变更事件数量约等于这段时间内真实发生变更的对象数。如果一天里只有十张表改了结构，那么不管扫一次还是扫二十四次，最终产生的变更事件都是那个量级，多出来的二十三次扫描只产出了比对开销。所以频率的价值上限由元数据的真实变更率决定——一个 DDL 一天只改几次的环境，把采集提到分钟级几乎没有增量信息，只会有增量压力。

反过来说，频率也不是越低越好。频率决定了元数据的新鲜度，而新鲜度决定使用者信不信这个平台。一张表今天早上被改了字段，到明天才在平台里体现，使用者遇到过两次就会回到口口相传的老办法。判断频率的合理口径是先看一周内 schema 变更与作业变更的次数分布，按分布的高位区间选一档，再留一点余量，而不是拍一个整点。

还有一个容易被忽略的点：采集频率跟采集范围是耦合的。全量扫与增量扫的差别不在频率档位上，而在每次扫描覆盖多少对象。把"每次扫全部"改成"按上次扫描时间戳取变更"，频率就可以提得高一些而代价可控。这个改动依赖数据源是否暴露变更时间戳，不是所有源都支持，支持的源里应该优先用。

一次采集不是写一条记录：写入放大发生在哪几步

很多容量估算错在这一步：以为改一张表就是写一条记录。实际的写入路径是：采集源产生变更提案（MCP），转为元数据变更事件（MCE）进入消息队列，元数据服务消费后写入元数据存储并更新检索索引与图索引，同时产生审计事件（MAE）回灌消息队列。一次对象变更触发的写入至少包括这几个部分。

第一处是元数据存储里的一行或多行。DataHub 的元数据模型采用实体—切面的组织方式，一个实体的不同切面分别记录结构、所有权、使用统计与操作信息。改一个字段类型，写的是结构切面；加一个负责人，写的是所有权切面。切面是分开存的，一次变更可能涉及多个切面。

第二处是检索索引里的一条文档更新。文档体积随索引字段多少变化，与业务表的数据行数无关——这一点在估算时很重要，一个存了 PB 级数据的表和一个空表，在检索索引里的体积差别很小。

第三处是图索引里的边。表级血缘下，一张表上下游各若干张，边数是十以内量级；列级血缘下，这些边要按字段展开，边数跳到几百甚至更高。这是写放大倍数里弹性最大的一项。

第四处是审计事件。每次变更都会留下一条，用于追溯谁在什么时候改了什么。审计事件本身不大，但它是只增不减的，长期累积下来的量不能忽略。

把这几处加起来，一个对象的写放大倍数大致是"一加索引文档数加边数加审计事件数"这个量级。也就是说，真正决定写入成本的是边数，而边数由血缘粒度决定。这就是为什么血缘粒度这一项调错，会比采集频率调错贵得多。

表级血缘与列级血缘，获得方式的差别决定了成本差

血缘分数据集级（表级）与字段级（列级）两类，差别不在"粗细"，而在获得方式完全不同。

表级血缘通常能从作业元数据或依赖关系直接获得：调度任务声明了输入表与输出表，ETL 作业配置里写了来源与目标，数据开发框架生成的依赖关系本身就是表级的。这类信息的采集成本很低，读配置、读 API 就能拿到，不需要理解 SQL 在做什么，也不依赖执行引擎。

列级血缘不一样，它往往需要解析 SQL——把语句解析成语法树，追踪 select 列表里每个输出列来自哪些输入列，处理别名、子查询、join 条件、case 表达式、窗口函数；或者依赖执行引擎输出的血缘事件，由引擎在执行时把列映射记录下来上报。两条路都贵：解析要 CPU 与时间，且解析覆盖率不可能到百分之百；引擎事件要改造执行链路，且只在真正执行过的作业上才有。

解析覆盖率是列级血缘最实际的麻烦。存储过程、动态拼接的 SQL、临时表、自定义函数、跨引擎的读写，都会让解析结果不完整或者干脆失败。结果是一张表的一部分边有、一部分边没有，使用者看到一条断掉的链，很难判断是"这个字段确实没有上游"还是"解析器没认出来"。这种不完整的血缘比没有血缘更消耗信任。

还有一个隐性成本：列级血缘的产出要逐条写进图索引，写入是批量但非原子的，解析出来几百条边意味着几百次图操作。采集任务的耗时曲线会随 SQL 复杂度剧烈抖动，一条几千行的存储过程可能占掉整个采集任务一半的时间。这也是列级血缘环境下采集超时最常见的原因。

列级血缘为什么"打开容易，关掉难"

列级血缘在采集配置里通常就是一个开关，勾上、重启采集、等一轮，前端就能看到字段级的上下游链。演示效果很好，这一步通常发生在项目早期，在场的人都觉得应该一直开着。

难的是关。一旦对外提供，下游能力会立刻长在上面：字段级影响分析、改动告警、敏感字段的合规追踪、口径溯源，这些功能都直接读列级边。关掉开关等于这些能力同时失效，而此时使用者已经把它当成事实来源在用，突然少掉一层粒度的破坏力，比当初没有它要大得多。这就是典型的单向门——进去容易，退出的代价由别人的工作流承担。

更麻烦的是，大家不敢关的理由往往不是"用得多"，而是"不知道谁在用"。元数据平台的使用统计如果不细，就没法判断关掉会影响几个报表、几条告警。于是这个开关就一直开着，采集耗时与图存储也一直按开着的方式增长。

比较稳的做法是把粒度做成可回退的范围配置，而不是全局开关：按数据源、按库、按表前缀限定列级血缘的覆盖范围，先在核心链路的少数表上开，观察一到两个采集周期的耗时变化与图存储增长，确认可控再扩大。同时把"谁在查列级血缘"这件事记录下来，真要收缩范围时至少有依据。这样即使要退，退的是范围而不是整体能力，代价可控。

三处存储各自怎么长：关系库、检索索引、图索引

元数据存储（关系库）随实体数、切面数与版本历史增长。单行体积很小，主要是结构与归属这类文本，但行数是实体数乘切面数，如果有历史版本保留，还要再乘版本数。这一处通常是三者里最好预估的，因为它是线性的，且随对象数而不是随查询量变化。

检索索引的体积主要随元数据对象数与索引字段多少增长，与业务表的数据行数无关。这意味着一张超大的业务表在检索索引里并不比一张小表占更多空间；反过来，把一个对象的更多字段纳入检索范围，索引体积会明显上升，但检索体验的改善未必成比例。索引字段是很多人随手加的，加之前值得算一下这一项带来的体积增量。

图索引是三者里最容易失控的一处，因为它随边数增长，而边数由血缘粒度决定。表级血缘下边数是表数量级，列级血缘下是列数量级，中间的差距就是一到两个数量级。图索引对内存的敏感度也高于关系库，边数上去之后内存占用跟着上，扩容时通常先在这一处遇到瓶颈。

消息队列是第四处，但性质不同：它堆的是传递中的变更事件与审计事件 MCE、MAE，属于可清理的临时区，按保留期堆积。它的存在让写入具备缓冲与重放能力，这是好事——采集侧突发一大批变更时平台不会被冲垮，索引重建时也能靠重放补齐。但它也意味着索引更新可能滞后于元数据存储，排查"我改了但搜不到"这类问题时，要先区分是"已写入"还是"已可检索"，这两件事在这个架构里不是同一时刻发生的。

时间序列型切面的保留期必须单独定

元数据模型里，使用统计与操作类切面属于随时间累积的时间序列型数据。这类数据的增长速度跟查询次数、作业运行次数绑定，而不是跟表数绑定。也就是说，即使元数据对象数一个都不增加，只要业务在跑、报表在被查，这部分数据就会一直涨。

它的量级往往被低估。使用统计通常是按时间窗口聚合的，一个热门表一天可能产生大量查询记录；操作类切面记录作业的运行实例，一个每小时跑一次的作业一年就是近万条。把它们跟结构切面放在一起做容量规划，结果就是磁盘先在这部分出问题。

没有保留策略的话，时间序列型切面会成为元数据平台中最先撑爆磁盘的部分。这不是理论上的担心：结构切面的增长有上限（受对象数限制），时间序列没有上限，它是一个只增的流。所以保留期不能跟其他切面共用一套策略，必须单独设。

具体的做法是定一个保留窗口，窗口内的明细保留，窗口外按周或按月聚合成统计值后清理原始粒度。清理要写成定时任务自动跑，不能指望有人手工执行。同时要注意一致性：清理元数据存 储里的切面对应行时，要确认检索索引与图索引里没有残留的关联引用，否则会出现"明细已清理但索引还能搜到"的不一致状态，这类问题排查起来很费时间。

采集任务与平台本体要不要分开部署

建议分开，理由是两类任务的资源画像完全不同。采集任务是尖峰型的：跑的时候 CPU 与内存冲上去，跑完就掉下来，尤其是带列级血缘解析的采集，解析复杂 SQL 时的内存峰值可以远超稳态。平台本体是稳态型的：元数据服务长时间在线，吃的是稳定的内存与 IO，对抖动敏感。

放在一起的后果是采集跑起来的时候把元数据服务的资源挤掉，表现出来就是平台卡、检索慢，而这时候采集任务本身可能还一切正常。这种故障很难定位，因为两个进程的日志都没有报错。分开之后，采集任务可以单独限流、单独扩容、单独重试，出问题的时候也不会连累平台可用性。

分开部署还有一个好处：采集任务可以被设计成幂等的，重复跑不会写出重复数据。这一点在接入新数据源时特别有用，可以先跑一遍验证配置，确认产出没问题再正式纳入。幂等性也是推送式接入的安全网——生产方重复发事件时不会把元数据搞乱。

采集失败的处理也要想清楚。失败不应该让平台不可用，最多是元数据滞后；但失败必须有可见的告警，否则会出现"平台显示一切正常但血缘是三个月前的"这种情况。采集任务的成功率与耗时应该被单独监控，而不是只看平台是否在 线。

索引层要不要独立，什么时候该考虑托管

检索索引与图索引的资源特性不一样：检索索引对内存与磁盘都敏感，体积随对象数与索引字段增长；图索引对边数带来的内存占用更敏感，且写入模式是大量小边操作。分开部署之后可以分别扩容、分别备份、分别重建，互不牵扯。合在一起的话，通常是图索引的边数增长先撑爆内存，然后连累检索一起不可用。

重建索引是这个架构里的常规运维动作，不是应急动作。映射变更、分词调整、字段增删、大版本升级，都可能触发重建。重建期间写入不能停，所以消息队列的缓冲与重放能力在这里是必需的：变更事件先堆在队列里，重建完成后消费补齐。设计的时候要把"重建一次需要多久、这段时间队列会堆多少"算进去，队列的保留期要能覆盖重建窗口。

考虑托管的信号主要是团队规模。这套架构有三套存储后端加一个消息队列要维护，加上采集任务自身的部署与监控，对小团队来说是持续的人力开销。如果团队没有专职做平台运维的人，托管是合理的选择。但选托管之前要确认一件事：采集频率与血缘粒度这两个变量是否可配。这两个变量决定成本与负载，如果托管方案把它们固定了，就等于失去了最重要的两个调控手段，后面遇到增长只能整体加钱。

自建的话，成本主要落在运维人力上，而不是机器上。三套存储后端的版本升级、备份恢复、容量监控、索引重建，这些事不会自动消失。做决定时应该按"需要投入多少人维护"来算，而不是按"需要几台机器"来算——后者通常比前者便宜。

只为了找表的场景，其实不必自建

如果唯一的诉求是找表，也就是回答"我们有哪些数据""这个字段是什么意思""这张表归谁管"这类问题，那么自建一整套带三个存储后端的平台，投入产出比很差。这类诉求用一份维护得当的数据字典、数仓自带的注释体系、或者直接在元数据库上写几个查询视图就能解决，而且维护成本低一个量级。文档类方案的缺点是会过期，但过期的文档至少不会让人误以为它是准确的；一个采集失败的元数据平台反而会给出错误的确定感。

真正需要自建的信号是这几个：需要自动血缘，尤其是跨系统的血缘；需要在改动之前回答"会影响什么"；需要把元数据采集接到数据开发流程或者 CI/CD 里，让变更自动可见；需要按字段粒度做合规与敏感数据追踪。这些能力的共同点是依赖自动采集与图结构，文档做不到，才有必要上平台。

本文只讨论元数据平台部署时的采集与存储变量估算口径；不构成选型结论，不提供报价，不与其他元数据平台做功能对比评测。所有容量与耗时的说法都是量级估算，需要按实际环境验证后才能用于决策，文中不引用任何跑分结果、性能对比数字或具体项目实例。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

元数据平台这几个变量，哪些必须按自家环境实测

需要按自家环境拿到数字的变量有五个，任何一个拿不到，容量规划就只是估算。

一是真实的实体总数，不是表数。要按实体类型分别统计：数据集、字段、仪表盘、图表、任务、管道、用户与组。字段数通常是表数的几十倍，这一项最容易算错，而它直接决定了后续的边数量级。

二是元数据真实变更率。统计一周内 DDL 变更次数、作业变更次数、归属与描述变更次数，按天看分布。这个数字决定采集频率的合理档位，也决定频率再提高还有没有收益。没有这个数字就去定频率，基本是拍脑袋。

三是 SQL 可解析比例。把落到核心表上的 SQL 拿出来，看存储过程、动态拼接、临时表、自定义函数各占多少。这个比例决定列级血缘的实际覆盖率，也就是决定开了列级血缘之后能得到多少可信的边。覆盖率低的话，开列级血缘的收益会明显低于预期，而成本照付。

四是列级血缘覆盖范围内的列数。不用全库算，先算核心链路里那部分表的列数总和，边数量级大致就是这个数的倍数。这个数字是图存储容量的主要输入。

五是单次采集耗时与内存峰值，按采集源分开记。开了列级血缘之后这一项会变化，要对比开前后的差值，这个差值就是血缘粒度的真实代价。只有拿到这个差值，才能判断粒度是否值得继续开着。

这五个数字的顺序也有讲究：先量对象数与变更率，因为它们决定采集侧的配置；再量可解析比例与列数，因为它们决定血缘粒度能不能开、开多大；最后量采集耗时与内存峰值，用来校验前面的判断。反过来做的话，会先定粒度再量代价，那时候已经不好退了。

关于 21291 这篇文章的技术口径与来源

本文的技术描述基于公开文档中可查的通用事实：DataHub 由 LinkedIn 开源、目前由社区维护，采用元数据服务加前端加多个存储后端的架构；典型部署包含元数据存储（关系型数据库）、检索索引（Elasticsearch 或同类）、图索引，以及用于传递元数据变更与审计事件的消息队列；写入路径为采集源产生变更提案（MCP），转为元数据变更事件（MCE）进入消息队列，元数据服务消费后写入存储并更新检索与图索引，同时产生审计事件（MAE）；采集方式分拉取式与推送式两类；血缘分数据集级与字段级两类，字段级通常需要解析 SQL 或依赖执行引擎输出的血缘事件；元数据模型采用实体—切面的组织方式，其中使用统计与操作类切面属于时间序列型数据。

涉及具体默认值、参数名称、版本行为的部分，文中一律按"常见情况""以实际版本文档为准"处理，没有给出确定数值。文中出现的容量与耗时描述均为量级估算，用于建立判断框架，不能替代在自家环境中验证得到的数字。

文中不包含任何来自真实运行环境的性能数字、跑分结果、交付实例或用户反馈，也不涉及具体报价与机型推荐。示例架构仅用于说明变量之间的关系，以下为典型部署思路，并非特指某一真实环境。文中提到的地域仅涉及基础设施部署层面的通用描述，不作其他评价。