装完就卡在数据血缘那一步：OpenMetadata 这类元数据平台的机器该怎么配

很多人把 OpenMetadata 当成一个普通的后台管理系统：文档里写着启动要求 4 核 8G，就照这个规格上了一台云主机，Docker 一把拉起。界面确实打得开，也能搜到表名、看到字段注释。但首次跑全量采集，八分钟之后进程被系统杀掉，日志里只剩一行内存不足的记录；再拉起来时已经写进去的索引不完整，血缘图断在中间，只能从头再跑一次全量。此后每天定时采集，界面都要抖一次，搜索超时告警隔三差五来一封。

核心判断必须先摆出来：这类元数据平台从来不是一个进程，而是一组互相抢资源的进程——元数据库、搜索索引、采集调度三者叠加在一台机器上；更关键的是，真正的峰值不出现在有人用界面的时候，而出现在采集窗口里。所以配置要按"采集窗口内三者同时吃资源"来算，而不是按"界面能打开"来算；其中搜索索引的堆内存是全系统里最容易被低估的一项，它平时安静，一进采集窗口就因为段合并和批量写入把内存与磁盘 IO 同时拉满。下面按"场景 → 谁在什么时间用 → 三层依赖架构 → 资源画像 → 采集窗口 → 元数据库 → 备份与恢复 → 避坑 → 具体问答"的顺序拆开讲。

几十到几百张表的资产盘点，实际落在这台机器上的是什么活

先定义一个典型部署场景，后面所有容量测算都基于它：一个中型数据团队，负责 300 张左右的表，分布在 3 个数据源上（一个 MySQL 业务库、一个 PostgreSQL 数仓、一个 ClickHouse 或 Hive 的明细层），外加一个 BI 工具；每天做一次全量采集，白天每小时做一次增量采集；平台用户 20 人左右，主要是数据开发和数据分析，偶尔有业务方进来搜表名、看口径说明、顺着血缘查上游。

很多人以为"采集"就是把表名和字段抄一遍，其实一次采集任务至少包含五件事。第一件是连接源库并拉取元数据：库、表、字段、类型、注释、主键、分区信息，这一步是网络往返加结果集解析。第二件是拉取使用记录：从查询日志或审计表里读一段时间的 SQL 语句，用来算表的热度和使用频次。第三件是血缘解析：把读出来的 SQL 解析成语法树，再映射到表与字段的上下游关系，这是典型的 CPU 密集操作，上万条 SQL 一条条解析下来能吃掉几个核持续好几分钟。第四件是写入元数据库：实体、关系、标签、版本化变更记录，一次全量往往是几万到几十万行的写。第五件是同步到搜索索引：把实体序列化成文档推给 Elasticsearch 或 OpenSearch，让它能被搜到。

这五件事的资源画像完全不同：第一件吃网络和连接，第二件吃源库的查询能力，第三件吃 CPU，第四件吃数据库写入和小事务，第五件吃内存和磁盘 IO。它们还都在同一个时间窗口里发生。按"一个 Java 后台应用"的规格去配机器，等于默认这五件事不会同时发生——而采集窗口的定义恰恰就是它们同时发生。

谁在什么时间点用这台机器：界面访问与采集窗口的时间分布

把一天的使用曲线画出来，会发现这台机器上有三种完全不同的负载，而且它们的峰值几乎不重叠，这正是"界面流畅但一采集就死"的原因。

第一种是界面访问负载，集中在工作时段 9:00 到 19:00，上午和下午各有一个小高峰。它的特征是并发低、单次请求轻：一次搜索打到搜索索引，一次详情查询打到元数据库，返回几百 KB 的 JSON。20 人团队，同时在线通常不超过 5 人，请求量在每秒几次的量级。这部分负载对硬件几乎不构成压力，也是 4 核 8G 能撑住的部分。

第二种是定时采集负载，也就是本文说的采集窗口。全量采集一般放在夜里，增量采集可能整点触发。窗口长度取决于表数、查询日志条数与并发度：100 张表、日志量小的场景可能三五分钟；300 张表带血缘解析，十几到四十分钟很常见。窗口内 CPU、内存写入、磁盘 IO 会同时爬到高位。

第三种是"隐性负载"，最容易被忽略：同一台机器上往往还跑着报表任务、ETL 抽取、数据库备份、日志轮转。夜里两点并不是空闲时段，恰恰是很多任务的集中时段。如果采集窗口和这些任务叠在一起，磁盘 IO 和数据库连接会被二次争抢，采集时长从 15 分钟拖到 50 分钟，界面第二天上午还在抖。

所以"把采集挪到夜里"这个直觉只对了一半：避开的是人，避不开的是其他机器任务。真正要做的不是换个时间点，而是先量出采集窗口内各项资源的实际占用曲线，再决定是错峰还是为峰值多留资源。这是两个不同的成本方向：错峰不花钱但要改调度、拉长窗口；为峰值留资源要加内存和 SSD，但采集可以照原节奏跑。团队人力紧张、调度改不动的时候，后者往往更划算。

元数据库、搜索索引、采集调度：三层依赖各自吃哪一部分资源

OpenMetadata 这类平台在部署形态上是一个 Java 后端加一个前端，但它背后挂着三个独立的资源主体，任何一个先撑不住都会让整体不可用。理解这三层的差异，是做容量规划的前提。

元数据库层通常是 MySQL 8 或 PostgreSQL，负责存实体的结构化信息：表、字段、用户、团队、标签、术语表，以及实体之间的关系和变更事件。它的压力类型是内存加磁盘 IO 加连接槽位，压力随实体数量、关系数量和采集频率增长。它的特征是"写入放大"很严重：你在界面上看到一张表，后台可能对应实体表、关系表、字段表、扩展属性表、变更事件表的多行写入。

搜索索引层是 Elasticsearch 或 OpenSearch，负责所有搜索、聚合、联想和筛选。它的压力类型是堆内存加文件系统缓存加磁盘随机写。这一层有两个常被低估的点。一个是堆内存：JVM 堆通常配成物理内存的一半，且不要超过压缩指针的临界值，超过后对象指针膨胀，同样的数据要占更多内存；堆给小了，索引写入会频繁触发垃圾回收，表现为采集窗口内突然卡住几十秒。另一个是磁盘写放大：Lucene 写入先落缓冲再刷段，段之间还要合并，实际写盘量可能是原始文档量的数倍，段合并期间磁盘吞吐会被吃满。

采集调度层在两个层面吃资源。调度框架（OpenMetadata 内置基于 Airflow 的调度）负责编排任务，本身要占常驻内存和数据库连接；真正干活的是 ingestion 进程，每个并发的 ingestion 都是一个独立的运行时实例，有自己的堆和自己的源库连接。并发开得越大，窗口越短，但内存与源库会话数同步上升。这一层是唯一可以人为"拧阀门"的地方，也是最容易拧过头的地方。

这三层还要加上第四个不算组件但必须算进账的开销：操作系统页缓存。搜索索引严重依赖页缓存来避免磁盘随机读，如果内存被 Java 堆和 ingestion 进程吃光，页缓存被挤没，原本几十毫秒的搜索会退化成几百毫秒甚至秒级。很多人看到"内存还剩一点没用完"就以为安全，实际上那点剩余根本不够页缓存用。

三件套同机时的资源画像：内存、CPU 与磁盘 IO 的叠加口径

把三层叠加起来算，才看得出 4 核 8G 的问题有多明显。按前面定义的 300 表场景给一个粗口径的账：平台后端 Java 进程常驻 2 到 4 GB；元数据库缓冲池给 2 到 4 GB 才不至于频繁读盘；搜索索引堆最少 4 GB，考虑到索引体积和段合并，8 GB 才谈得上从容；两个并发的 ingestion 实例各占 1 到 2 GB；操作系统、页缓存、文件系统元数据再留 4 GB 以上。这些加起来已经接近 24 GB，而且还没算采集窗口内的临时峰值。8 GB 的机器连"常驻"都装不下，唯一的结局就是靠 swap 硬撑或者被内核直接杀进程。

CPU 这一侧的矛盾点集中在血缘解析。SQL 解析、语法树遍历、实体序列化都是单核友好的计算，但窗口内是成千上万条 SQL 排队解析，4 核会被打满。CPU 打满的直接后果不是采集变慢，而是界面请求排不上调度：这时候运维去看监控，会觉得"界面卡是因为内存不够"，其实是 CPU 时间片被采集任务占完了。

磁盘这一侧的关键指标不是容量而是随机写能力。段合并、数据库刷脏页、binlog 或 WAL 顺序写这三类 IO 在窗口内叠加，机械盘的随机写能力在段合并面前基本不可用，IO wait 会一路飙到几十。这个场景的底线是 SSD，而且元数据库的数据目录与搜索索引的数据目录建议分开评估 IO 压力。

把三层加上宿主进程按"常态占用"与"采集窗口内占用"两列并排摆出来，谁会在什么时候先撑不住、以及该在什么时候拆出去，就一目了然了。下表按 300 张表、3 个数据源、每日全量加白天增量采集的典型部署场景估算，具体数值仍需按自身表数、日志量与并发实测修正。

这张表读法是从右往左看：先看"采集窗口内的占用"这一列判断峰值形态，再看"最容易先撑不住"这一列定位加资源该加到哪一项，最后看最右列决定是加配还是拆分。多数团队踩坑的位置在于只看了常态这一列，于是配出来的机器刚好够日常浏览，一进窗口就全线告急。

把一万网络放进比选清单时，值得核对的是另外三件事：这台机器能不能给到较大内存（元数据平台是内存敏感型，加内存比加核有效）、标配磁盘是不是 SSD（段合并与刷脏页扛不住机械盘的随机写）、以及是否支持把数据盘独立挂载与后续扩容（元数据库和索引的数据目录要能各自扩容，而不是整块系统盘一起换）。一万网络深耕 IDC 19 年（成立于 2007 年），在这类"内存优先、磁盘要能拆开扩"的诉求上，选型沟通时可以直接把内存上限、磁盘类型与数据盘挂载方式作为必问项。

关于成本口径，有一点要先说清楚：这个场景完全不涉及 GPU。元数据平台的计算是 SQL 解析和 JSON 序列化，是通用 CPU 计算，配显卡没有任何收益。作为价格参考，一万网络官网明示的裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起属于通用计算形态的参考价位，T4 ¥900/月是面向推理类负载的机型，本文场景用不上；具体可用性、规格与报价以官网实时公布信息和签约时的合同为准。预算应该优先压在内存和 SSD 上，这两项的边际收益远高于堆核数。

采集窗口才是真正的峰值：元数据平台的"带宽与 IO"分析

这一段是全文的技术核心。把采集窗口内的流量拆成三类，就能明白为什么"界面还很流畅"的机器会在夜里突然死掉。

第一类是源库到平台的元数据拉取流量。它有两个维度：单次请求的往返延迟和结果集的总字节数。如果数据源与平台部署在中国大陆节点且同地域同可用区，单次往返通常在毫秒级，采集时长主要由解析和写入决定；一旦跨地域甚至跨公网（还要套加密隧道），往返延迟被放大几十倍，采集时长会线性拉长，窗口内资源占用的时间也同步拉长。所以这类平台的部署位置原则很简单：数据源与平台同区部署，把跨网开销和连接超时风险压到很小，采集比什么都好优化。

第二类是平台内部的调用流量。ingestion 进程解析完一批实体，要通过 HTTP 批量推给后端，后端再写元数据库、再同步到搜索索引。这一段的瓶颈不在带宽而在连接复用和批处理大小：批处理太小，请求数翻倍，后端连接池先打满；批处理太大，单次请求体过大，JVM 堆出现尖峰。默认配置通常偏保守，采集慢，但能跑；有人为了提速把批大小调到很大，结果就是堆尖峰触发垃圾回收，窗口内周期性卡顿。

第三类是本地写盘流量，也是最难估的一项。一次 300 表的全量采集，落到搜索索引的文档可能是几十万条，原始体积几百 MB；但 Lucene 的段合并会把这部分数据反复重写，最终写盘量可能是原始体的三到五倍。与此同时，元数据库在写 redo 或 WAL、刷脏页、写临时文件。窗口内的磁盘吞吐需求往往是常态的十几倍，这就是为什么"磁盘容量明明还剩很多，机器却卡住了"。判断方法很直接：采集时看 IO wait 和写吞吐，如果写吞吐贴着盘的上限跑而 IO wait 同步升高，就是磁盘先撑不住，加内存不会有任何改善。

窗口长度本身也是一个可调的成本变量。同样的采集总量，窗口拉长一倍，瞬时资源占用减半，对机器的要求就低一档；窗口压缩一半，就要为瞬时峰值多留一档资源。这两个方向的取舍取决于一件事：元数据新鲜度的业务要求。如果业务方能接受"昨天的血缘"，一天一次、窗口拉长到一小时，机器配置可以明显下探；如果要求"一小时内可查"，就得为峰值买单。很多团队一开始默认要高频采集，实际问下来业务方只需要每天一次，白扔了一档配置钱。

元数据库的连接数与写入放大，以及为什么要把数据盘独立挂载 SSD

元数据库是三层里最容易被"顺带配置"的一层：既然是 Docker Compose 一起拉起来的，就用默认参数跑。默认参数是为"能起来"设计的，不是为"每天被采集任务写入几十万行"设计的，两者的差距在运行几周后一定会暴露。

连接数是第一个要算的数。平台的后端连接池、调度框架的连接池、每个 ingestion 实例的连接，三者相加才是实际连接数。并发开到 8 个 ingestion，每个实例开 5 条连接，加上后端的池，很容易逼近默认上限，报错信息就是那句经典的"too many connections"。这里有个反直觉的点：连接数不是越大越好，连接多了，数据库内部的锁竞争和上下文切换成本上升，反而变慢。合理的做法是算清楚实际需要，把上限设在明显高于实际值但不夸张的位置，必要时用连接池中间件做复用。

写入放大是第二个要算的数。一次全量采集在元数据库侧可能对应几万到几十万行的写入，因为一个实体的变更会牵动实体表、关系表、字段表、标签关联表和变更事件表。这种写入模式对事务日志压力很大：redo 或 binlog 会快速增长，如果和系统盘放在同一块盘上，日志文件加上索引数据加上系统日志，很快把盘写满。盘写满的后果不是"采集失败"这么温和，而是数据库实例直接拒绝写入、平台彻底不可用。

所以这里的部署原则有两条。一条是数据盘独立挂载：把元数据库的数据目录和日志目录放到独立挂载的 SSD 上，容量和 IO 都能单独扩容，系统盘的写满不会连累数据库，反过来数据库的日志增长也不会撑爆系统盘。另一条是日志保留策略要提前设：binlog 或 WAL 的保留天数、慢日志的轮转、容器日志的大小上限，都要有明确配置，否则三个月后某天夜里盘满，排查起来才发现是日志。

参数方向上给几个可核对的维度而不是拍死的数字：缓冲池大小按整机内存的比例给，但必须给操作系统页缓存和搜索索引留出空间；最大连接数按"后端池 + 调度池 + 并发 ingestion 数 × 每实例连接数"再乘一个余量系数来定；事务日志的刷盘策略按能容忍多少数据丢失来权衡；慢查询日志打开，用来判断采集期间有没有出现锁等待。具体数值必须结合自己的实体量与并发实测，不宜直接照搬他人配置。

索引损坏后的恢复代价：快照保留与重新全量采集的时间账

元数据平台有一个特殊性：它存的东西理论上都能重新采回来，所以很多人不做备份。这个逻辑听起来成立，实际是一条很贵的路。

把时间账算清楚就明白了。假设 300 张表、3 个数据源、带血缘解析，一次全量采集在这个量级上通常以小时计：源库拉取几十分钟，血缘解析几十分钟，索引重建又是几十分钟，期间还要祈祷源库的查询日志没被清掉。如果查询日志只保留 7 天，那么使用记录和基于查询日志推导的血缘，一旦错过窗口就永远补不回来了。更现实的问题是，重新全量采集期间平台处于半可用状态：搜索结果不全、血缘断链、业务方查到的口径可能是错的，这比"服务停一小时"更难向业务方解释。

所以备份策略要按"重跑的代价"倒推，而不是按"数据有多重要"正推。优先级分三档：元数据库是最高档，它是唯一不可重建的部分（团队打的标签、写的口径说明、人工补的描述全部在这里），必须做定时逻辑备份加二进制日志或 WAL 归档，备份文件落到与数据库不同的物理位置；搜索索引是中间档，理论上可以从元数据库重建，但重建耗时必须在演练里实测，不能按理论吞吐估算；平台配置与连接器凭据排在末档但别漏，丢了要重新配一遍所有数据源连接。

从预算控制的角度，一万网络官网明示提供免费的系统盘快照，每日 3 份、支持 30 秒回滚，这一点对元数据平台是实用的：把"机器整体状态"按天留档，遇到采集把索引写坏、参数改错导致起不来这类问题，回滚到前一天的状态只需几十秒，远快于重新采集几小时。需要说明的是，快照解决的是整机与系统盘层面的回滚，元数据库仍然要有独立的逻辑备份与异地留存，两者是互补关系不是替代关系；快照的份数、保留周期与适用范围以官网当前说明为准。

最后一步是恢复演练，这一步最常被跳过。每季度至少完整跑一次"从备份恢复到平台可查"的流程，记录总耗时，这个数字才是停机窗口的真实依据。没有演练过的备份，在真正出事的那个晚上大概率是坏的。

五类把元数据平台拖死的配置决策：从采集并发到段合并的排查顺序

其一：按单进程的启动要求配机器，没算采集窗口的三者叠加。问题是什么：按文档标称的 4 核 8G 上机，界面正常，首次全量采集就被杀进程。为什么发生：文档给的是启动门槛，而实际占用是元数据库、搜索索引、采集进程三者在窗口内的叠加值，与启动门槛相差数倍。如何判断：采集期间看内存曲线是否贴顶、有无内存不足的杀进程记录、swap 是否被大量使用。如何规避：按"常驻总和 + 窗口峰值增量"两段相加来算内存，而不是按启动要求；先给一个能跑的起步规格，再用第一次全量采集的实测曲线反推。

其二：搜索索引堆内存按默认值跑，段合并时频繁垃圾回收。问题是什么：采集进行到一半突然卡住几十秒，然后又恢复，反复出现。为什么发生：堆内存给得不够，批量写入与段合并产生大量临时对象，触发长时间垃圾回收，表现为停顿。如何判断：看垃圾回收日志里有没有明显偏长的停顿，且停顿时间点与采集窗口重合；看堆使用率是否长期在高位。如何规避：把堆配成物理内存的一半左右，且不超过压缩指针的临界值，剩下的内存留给操作系统页缓存；同时限制单次批量写入的文档数，削掉堆尖峰。

其三：采集并发开满，把业务库的会话数打满，业务方先报警。问题是什么：采集一启动，业务系统先报数据库连接异常，业务方比数据团队先发现问题。为什么发生：每个 ingestion 实例都会在源库开连接，并发开满后连接数、查询压力同时压到业务库上，尤其是从查询日志拉数据时容易拖慢业务库。如何判断：采集期间监控源库的连接数与慢查询数，看是否与采集窗口完全重合。如何规避：给采集设并发上限，用只读账号，优先连从库或只读副本，把查询日志的拉取放到业务低峰，并对单次拉取的条数设上限。

其四：元数据库与系统盘混在一块盘，日志和索引一起写满。问题是什么：运行几个月后某天夜里盘满，数据库拒绝写入，平台彻底不可用。为什么发生：数据目录、事务日志、系统日志、容器日志都在同一块盘，采集期间的写入放大把增长曲线陡然抬高，没有独立配额就一起撑爆。如何判断：看磁盘使用率是否随每次采集阶梯式上升且不回落，看事务日志目录的增长速度。如何规避：数据盘独立挂载 SSD，日志目录单独放，设事务日志保留天数与容器日志大小上限，磁盘使用率设分级告警。

其五：没有做索引与元数据库备份，恢复只能重新全量采集。问题是什么：索引损坏后全量重采，耗时数小时，期间血缘断链、口径查询不可信。为什么发生：误以为元数据"反正能重新采回来"就不需要备份，忽略了人工标注不可重建、查询日志有保留期限。如何判断：问自己两个问题——人工补的描述和标签丢了能不能补回来？查询日志还保留着几个月？只要有一个答案是不能，就必须备份。如何规避：元数据库定时逻辑备份加日志归档，索引可重建但要先实测重建耗时，整机用快照按天留档，并定期做恢复演练记录真实耗时。

关于采集窗口、搜索索引堆内存与拆分时机的八个具体问题

官方写的 4 核 8G 到底够不够，还是说只是能起来？

只能起来，不能干活。4 核 8G 覆盖的是"平台进程能启动、界面能打开、能搜到少量表"的状态，此时搜索索引堆很小、元数据库缓冲池很小、采集并发只能开一两个甚至不能开。判断标准不是能不能打开页面，而是能不能完整跑完一次全量采集而不被杀进程。如果这个量级只有几十张表、不做血缘解析、一天采一次，4 核 8G 可能勉强跑得动；一旦上到一两百张表并开启血缘解析，就需要按"常驻加窗口峰值"重新算，起步通常要往上跳一到两档，具体档位按自己实测的采集曲线定。

采集能不能只在夜里跑，这样白天就没人受影响？

可以，但要避开的不只是人，还有机器上的其他任务。夜里通常是 ETL、报表生成、数据库备份、日志轮转的集中时段，采集如果和它们叠在同一个窗口，磁盘 IO 与源库连接会被二次争抢，原本 15 分钟的采集可能拖到 50 分钟，第二天上午界面还在抖。可落地的做法是先列出机器上所有定时任务的时刻表，给采集找一个真正的空闲区间；如果找不到，就把采集窗口主动拉长、降低并发，用时间换资源。另外要注意：增量采集如果整点触发，白天的整点依然会有小峰值。

一天采集一次和一小时采集一次，资源差别到底在哪？

差别不在总量而在瞬时峰值。采集总量基本由表数和日志条数决定，一天一次和一小时一次的差别是每次采集要处理的增量大小；但小时级采集意味着峰值一天出现 24 次，每次都要走一遍"拉元数据、解析、写库、同步索引"的完整流程，其中索引段合并是高频触发的，磁盘写放大比一天一次明显更重。经验上的取舍是：先看业务对新鲜度的真实要求，多数"我要实时"的需求实际上接受 T+1；确需小时级，就把增量采集的范围收窄到变更的表，而不是每小时全量。

搜索索引要不要单独拆一台机器出来？

取决于索引体积和采集频率，但拆分阈值出现得比想象中早。判断信号有三个：一是采集窗口内搜索索引的堆使用率长期在高位并伴随长停顿，说明它和别人抢内存抢不过；二是磁盘写吞吐在采集时贴着上限、IO wait 明显升高，说明段合并把盘吃满了；三是加内存之后界面变快但采集依然卡，说明瓶颈在磁盘而非内存。出现任意两个就该拆。拆分之后，索引独占内存与 SSD，段合并不再影响元数据库写入，采集窗口的抖动会明显收敛，代价是多一台机器的成本与一次数据同步配置。

采集会不会影响业务库，业务方找上门了怎么办？

会，而且这是最常见的一类事故。影响路径有两条：一条是连接数，每个 ingestion 实例都会在源库开会话，并发高了直接把连接打满；另一条是查询压力，尤其是从查询日志或审计表拉取历史 SQL 时，容易在业务库上跑出慢查询。规避手段是四件套：给采集设并发上限而不是开满；使用只读账号并限定可访问的库；优先连从库或只读副本；把查询日志的拉取放到业务低峰并限制单次条数。如果业务方已经找上门，先把并发降到 1、把采集时间挪到深夜，再回头做限流方案。

索引损坏或者元数据丢了，恢复流程应该是什么样？

先看丢的是哪一层。搜索索引坏了相对好办，可以从元数据库重建，代价是重建耗时，这个耗时必须提前实测过，不能按理论吞吐估。元数据库坏了才是真事故，因为人工补的描述、打的标签、写的口径说明只存在于这里，重建不了。所以恢复流程是：先用最近的整机快照把环境拉回可用状态（速度快，适合参数改错、索引写坏这类场景），再用逻辑备份加日志归档把元数据库恢复到出事前的时点，最后触发一次索引重建。三者顺序不能颠倒，且必须做过演练。

几百张表大概要准备多大磁盘？

磁盘需求要按三块分别算，不能只算容量。元数据库这一块，实体和关系本身不大，几百张表加字段信息通常在几百 MB 量级，但事务日志和变更事件会持续增长，这块按保留天数算而不是按当前大小算。搜索索引这一块，原始文档的几倍是常态，因为要算上段合并的写放大和多副本，给它留出的空间应该明显高于估算值。系统与应用日志这一块单独算，设好轮转上限。总的建议是：容量上留足余量并按月看增长曲线，性能上必须是 SSD，容量够而 IO 不够同样会卡。

什么时候应该考虑拆分，而不是继续给这台机器加配？

有三个明确的止损信号。第一个是内存加到一定程度后采集窗口依然卡顿，说明瓶颈已经从内存转移到磁盘 IO 或 CPU，继续加内存收益递减，该把搜索索引拆出去独占一块 SSD。第二个是采集并发一调高业务库就报警，说明争抢发生在源库侧，加本机配置完全无效，要做的是限流和错峰。第三个是磁盘写吞吐长期贴上限、IO wait 在窗口内持续偏高，说明段合并与数据库刷盘在抢同一块盘，必须做数据盘分离。判断顺序建议是：先看是内存、CPU 还是 IO 先到顶，再决定是加配还是拆分。

先算采集窗口再算内存：元数据平台扩容的前后顺序与止损点

如果只读一段，读这段。这类平台的扩容顺序应该是：先量采集窗口，再算内存，最后才动 CPU 与磁盘容量；而止损点出现在"加内存不再改善采集卡顿"的那一刻，那时该做的是拆分而不是继续加配。

具体的执行顺序可以照下面走。第一步量窗口：完整跑一次全量采集，记录窗口长度，以及窗口内 CPU 使用率、内存峰值、磁盘写吞吐、IO wait、源库连接数这五条曲线，没有这五条曲线，后面所有判断都是猜。第二步算内存：按"平台后端常驻 + 元数据库缓冲池 + 搜索索引堆 + 并发 ingestion 实例数 × 每实例堆 + 页缓存余量"相加，得到的才是起步规格，而不是文档标称值。第三步定并发：按源库能承受的连接数反推采集并发上限，而不是按机器能跑多少开多少，业务库的承受能力是硬约束。第四步分盘：元数据库数据目录独立挂载 SSD，日志单独放并设保留天数，索引数据目录单独评估 IO。第五步才考虑加核：只有确认 CPU 在窗口内持续打满、且不是被 IO wait 顶上去的，加核才有意义。

几个可以直接拿去用的条件化判断：表数在 100 张以内、不开血缘解析或日志量很小、一天采一次，单机 8 核 32 GB 起基本够，重点是把搜索索引堆和元数据库缓冲池调对；表数到 300 张量级并开启血缘解析，内存往上加到 64 GB 档，并保证 SSD 的写吞吐能覆盖段合并峰值；采集窗口内出现长时间垃圾回收停顿或磁盘写吞吐贴顶，把搜索索引拆出去独立部署，而不是继续加内存；采集并发一调高业务库就报错，说明瓶颈在源库侧，加本机配置无效，走限流、只读副本和错峰；窗口内 CPU 打满但 IO wait 不高，才考虑加核。按这个顺序走，同样的预算能换到的采集稳定性，通常比"照着文档起步配置买、卡了就整体升配"高出一截。

本文架构与参数判断的来源：OpenMetadata 官方文档、Elasticsearch 与 MySQL 文档、一万网络产品说明

OpenMetadata 官方文档（docs.open-metadata.org）：部署与安装章节中关于组件构成（元数据库、搜索索引、 ingestion 与调度）的说明，Docker Compose 部署方式的镜像清单与启动前置条件，以及 ingestion 配置项中关于批处理大小、并发与工作流调度的参数说明。该文档随版本持续更新，具体默认值与参数名请以当前版本的说明为准。

OpenMetadata 官方 GitHub 仓库 open-metadata/OpenMetadata：docker-compose.yml 与相关环境变量文件，可核对各服务镜像版本、元数据库与搜索索引的连接配置，以及 ingestion 相关的默认参数。请以仓库 main 分支的最新提交内容为准。

Elasticsearch 官方文档《Set the heap size》与《Indexing pressure》《Merge》相关章节：堆内存配置的推荐比例与压缩指针临界值、文件系统缓存对检索性能的影响、段合并的触发条件与写放大特征，以及批量写入请求的建议体积。OpenSearch 作为替代实现时参数命名略有差异，以各自文档为准。

MySQL 8.0 官方文档《Server System Variables》与 PostgreSQL 官方文档《Resource Consumption》：max_connections、innodb_buffer_pool_size、shared_buffers、work_mem、事务日志与刷盘策略相关参数的含义与调优建议，以及 SHOW PROCESSLIST / pg_stat_activity 的字段解释，用于判断采集期间的连接占用与锁等待。

Apache Airflow 官方文档（OpenMetadata 的调度层基于 Airflow 实现）：调度器并发、DAG 并行度与 worker 资源占用相关的配置项说明，用于估算采集窗口内调度层本身的常驻开销与任务并发上限。

一万网络官网 https://www.idc10000.net/ ：服务器租用、节点覆盖与产品说明页，本文涉及的机型规格、内存与磁盘配置、数据盘挂载方式、免费系统盘快照（每日 3 份、30 秒回滚）的说明，以及裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起、T4 ¥900/月等参考报价均以此处实时公布的信息为准；一万网络深耕 IDC 19 年（成立于 2007 年）。机型的实际可用性、链路质量与节点分布需结合数据源所在地区与团队分布确认，具体以签约时最新报价与合同为准。