我们生产环境的 Atlas 血缘采集链路跑通后，功能没问题，但延迟一直不理想。监控数据显示：从 Hive SQL 执行完成到血缘关系在 Atlas 页面可查，P99 延迟约 28~35 秒。
这个延迟对资产盘点和事前影响分析来说够用，但对故障定位场景完全不够——凌晨生产故障，值班同事打开血缘页面发现"还看不到刚才那条 SQL 的影响范围"，只能等。
我们花了大约两周做专项优化，最终把 P99 延迟从 30 秒压到了 3 秒以内。本文按优化链路逐层展开。
一、先搞清楚延迟花在哪
优化之前，先画清楚全链路，标注每个环节的耗时。
HiveServer2 SQL 执行 → Hook 序列化事件 (1~2ms) → 写入 Kafka Topic (2~5ms) → Kafka 端到端传递 (50~200ms) → Atlas Notification Consumer 拉取 (???) → JanusGraph 图写入 (???) → Solr 索引更新 (???) → 前端查询可见
我们在每个环节埋了日志，统计了 1000 条血缘事件的耗时分布：
环节平均耗时P99 耗时占比Hook 序列化 + Kafka 生产5ms12ms< 1%Kafka 端到端120ms380ms~1%Notification Consumer 拉取8s18s~55%JanusGraph 写入4s12s~35%Solr 索引更新2s5s~10%
瓶颈一目了然：Consumer 拉取延迟和 JanusGraph 写入延迟占了 90% 以上。
下面逐个拆解优化手段。
二、第一刀：Kafka 消费端参数调优
Atlas 的 Notification Consumer 默认配置非常保守，完全是"能跑就行"的级别。
2.1 增加 Consumer 线程数
Atlas 默认只启动 1 个 Notification Consumer 线程。在 DDL 操作频繁的生产环境，单个线程根本消费不过来。
# atlas-application.properties # 默认值：1 atlas.notification.hook.numthreads=1
改为：
atlas.notification.hook.numthreads=4
注意这个值不是越大越好。线程数超过 Kafka 分区数，多余的线程会空转。我们线上 Topic 是 8 个分区，Consumer 线程设为 4（每个 Consumer 消费 2 个分区），实测 CPU 利用率合理。
效果：Consumer 拉取延迟从 8s 降到 2s 左右。
2.2 Producer 端关闭等待
Atlas Hook 默认在 Kafka 写入后等待 Broker 的 ACK 确认，这个确认在跨机房部署时尤其慢。
# 默认值：all（最严格，等待所有副本确认） atlas.notification.hook.kafka.producer.acks=all
改为：
atlas.notification.hook.kafka.producer.acks=1
从 all 改成 1（Leader 确认即可），Kafka 端到端延迟从 120ms 降到 50ms 左右。代价是极端情况下可能丢失事件，但 Hook 事件本身是高频上报的（每次 SQL 执行都会触发），丢一条对最终血缘图影响极小，DAG 关系不会断。
2.3 关闭 Kafka 消息压缩
默认使用 snappy 压缩，在小消息场景下压缩收益不大，反而增加 CPU 开销：
atlas.notification.hook.kafka.compression.type=none
单条 Hook 消息通常只有几 KB，压缩性价比很低。关闭后 Producer 延迟降低约 30%。
三、第二刀：JanusGraph 批量写入
JanusGraph 是 Atlas 的图存储引擎，底层用 HBase 存数据。这是整个链路中性能最敏感的环节。
3.1 问题诊断：逐条提交
默认情况下，Atlas 每收到一条 Notification 事件，就开启一个 JanusGraph 事务、写入一条数据、提交一个事务。在 HBase 集群上，这意味着每条血缘更新触发一次 HBase 写入，每次写入涉及 WAL 刷盘和 Region 锁。
1000 条血缘事件 = 1000 次 JanusGraph 事务 = 1000 次 HBase Put。这就是 4 秒写入延迟的根源。
3.2 方案：批量消费 + 批量提交
我们修改了 Atlas 的 Notification Hook Consumer 逻辑，改为批量拉取 + 批量写入：
// 原来：逐条处理 while (true) { List<HookNotificationMessage> messages = consumer.receive(); for (HookNotificationMessage msg : messages) { processMessage(msg); // 每条消息一个事务 } } // 优化后：批量处理 while (true) { List<HookNotificationMessage> messages = consumer.receiveBatch(200, 5000); // 最多200条或5秒 processBatch(messages); // 200条消息共用一个事务 }
关键参数配置：
// 批量大小：根据单条消息平均大小和 JVM 内存确定 int BATCH_SIZE = 200; // 最大等待时间：即使不够 200 条，超过 5 秒也提交 long MAX_WAIT_MS = 5000;
效果：JanusGraph 写入延迟从 4s 降到 0.8s。
3.3 HBase 侧优化
JanusGraph 底层是 HBase，HBase 的写入性能直接影响图数据库吞吐。
# JanusGraph HBase 配置 storage.hbase.region-count=8 storage.hbase.regions-per-server=4 # HBase 侧：预分区 # 在 HBase Shell 中执行 create 'atlas_janus', 'f', {NUMREGIONS => 16, SPLITALGO => 'HexStringSplit'}
预分区避免了写入热点——所有血缘数据写入同一个 Region 会导致单 RegionServer 成为瓶颈。我们按 JanusGraph 的 Vertex ID 做 Hex 预分区，16 个 Region 均匀分布到 4 个 RegionServer。
四、第三刀：Solr 索引更新异步化
Solr 做全文索引，用于支撑 Atlas 前端的搜索功能。默认行为是每次 JanusGraph 事务提交后同步更新 Solr 索引，这会导致写入链路被搜索索引拖慢。
4.1 改为异步索引
# atlas-application.properties # 默认：同步提交 atlas.graph.index.search.solr.mode=cloud # 改为异步 atlas.notification.index.search.solr.commit-option=soft
soft 模式下，Solr 索引更新从同步阻塞改为异步提交，写入链路不再等待索引落盘。
效果：Solr 索引环节从 5s 降到几乎可忽略（< 100ms 触发异步任务）。
代价是极端情况下（索引更新延迟），前端搜索可能查不到最新一条血缘关系。但搜索场景本身就不需要实时性（你搜表名，T+1 都能接受），这个代价可以接受。
4.2 精简索引字段
Atlas 默认对几乎所有 Entity 属性建索引，包括很多低频查询字段。我们裁剪了索引范围：
// Atlas Entity 定义中，只对高频搜索字段建索引 // 去掉 description、owner、createTime 等低频索引字段 @AtlasEntity( attributes = { @AtlasAttribute(name = "qualifiedName", isIndexable = true), @AtlasAttribute(name = "name", isIndexable = true), @AtlasAttribute(name = "type", isIndexable = true), // 以下字段不再建索引 @AtlasAttribute(name = "description", isIndexable = false), @AtlasAttribute(name = "owner", isIndexable = false) } )
减少索引字段直接降低了 Solr 的写入压力，同时减少了索引存储体积约 30%。
五、最终效果
优化后重新跑压测，2000 条血缘事件，各环节耗时：
环节优化前 P99优化后 P99优化幅度Hook → Kafka12ms8ms-33%Kafka 端到端380ms60ms-84%Consumer 拉取18s0.7s-96%JanusGraph 写入12s0.9s-92%Solr 索引5s0.2s-96%端到端总计~35s~2.0s-94%
P99 从 35 秒降到 2 秒，P50 稳定在 1 秒以内。故障定位场景下，值班同事打开血缘页面，最多 2 秒就能看到最新的影响范围。
六、优化清单速查
优化项配置预期收益Consumer 线程数numthreads=4消费延迟降低 70%Kafka ACKacks=1端到端延迟降低 50%关闭压缩compression=noneProducer 延迟降低 30%批量消费BATCH_SIZE=200写入延迟降低 80%HBase 预分区NUMREGIONS=16热点问题消除Solr 异步commit-option=soft索引延迟降低 95%精简索引字段只保留高频字段写入量和存储降低 30%
七、还没解决的问题
- 跨机房部署：我们的 Kafka 和 Atlas 在同一个机房，端到端延迟才 60ms。如果跨机房（比如前端在华东、Kafka 在华北），延迟会增加到 200~500ms，目前的优化方案需要重新评估。
- JanusGraph 自身瓶颈：HBase 预分区解决了写入热点，但 JanusGraph 本身在大规模图遍历（比如上游有 50 层血缘）时性能仍然不理想。我们正在评估用 NebulaGraph 替代 JanusGraph 的可行性，这块后续单独写。
- Spark Listener 的血缘粒度：Hive Hook 只能捕获 Hive 引擎的 SQL，Spark SQL 的血缘需要 Spark Listener 来补。Spark Listener 的延迟问题比 Hive Hook 更复杂——Spark 的 DAG 是懒执行的，Listener 在 Job 提交时触发，但实际血缘关系在 Stage 执行完才能确定。这块我们还在探索。
本文优化方案基于 Atlas 2.3.0 + HBase 2.2 + Kafka 2.8 + Solr 8.11，不同版本配置项可能有差异，请以官方文档为准。
