运维诊断图谱产品系统

团队使用Grafana Loki组件采集调度平台的任务日志，读取日志中的内容并作为监控数据（包含tagKey、tagValue和数据值）写入Prometheus，Prometheus再通过网关将监控数据写入TDengine。虽然已经通过这套架构实现了日志数据的采集和存储，但目前调度任务数量庞大，当任务出现问题时，如何快速从海量日志信息中寻找关键信息并以关系图谱串联起来，成为了一项挑战。比如，当前任务在哪台hiveserver2机器上运行，它的查询id是多少，生成了多少application，每个application又在哪些机器运行。
高峰期当任务出现异常，若不能快速定位，则会影响问题排查效率。

基于TDengine、Loki、Prometheus、Nebula Graph体系建立日志、指标等数据间的关系图谱，打造多数据观测融合能力，旨在当任务出现问题，能一键展示关键信息，提升问题定位效率。

项目初期，我引入了NebulaGraph图数据库来重构日志关系，我们需要从TDengine中提取元数据，然后写入NebulaGraph来构建图谱。当时我们面临的最大挑战是海量数据的处理效率极低，生成图谱需要8分钟，完全无法满足实时性。 为了解决这个问题，我主要做了三点核心优化：
第一，在TDengine的数据获取逻辑上，我废弃了低效的‘全量导出+awk’模式，改为基于时间范围的 SQL分片查询，利用多线程并发拉取数据。
第二，在NebulaGraph的数据处理逻辑上，我放弃了存在阻塞风险的`parallelStream`，改用Java8的CompletableFuture 自定义线程池。
在此基础上，对于数据写入，一个批次对应一个写入线程，每个批次再按小批次构建批量sql语句，提升单次请求写入数据量。
对于数据查询，一个批次对应一个查询线程，并将查询语句从`MATCH`改为性能更优的LOOKUP。
第三，利用微服务的多实例架构，让各实例分摊不同时间片的逻辑，实现多实例分而治之，降低总体处理时长。
这一系列动作将任务处理时长从8分钟缩短至5秒，极大提升了数据处理的实时性。
项目运行一段时间后，底层的TDengine组件出现不稳定性现象，导致元数据缺失。为了彻底解决这个问题，我主导了对TDengine网关组件 TaosAdapter 的源码改造（Golang），并替换TDengine组件。
首先，为了在移除TDengine后依然保证高性能元数据去重，我基于Redis设计了一套新算法：利用Bitmap结构计算计算每个元数据唯一的偏移量，并使用 Bitfield 命令，在一个网络请求内完成批量数据的‘存在即跳过，不存在则写入’，解决了内存占用和吞吐量问题。
然后，将去重后的日志元数据写入NebulaGraph以替代TDengine。