3-3 高英举-海量可观测性时序数据库的分布式查询演进之路.pdf

1、海量可观测性时序数据库的分布式查询演进之路演讲人：字节跳动 高英举目录1.可观测性TSDB演进路线2.可观测性TSDB整体架构3.可观测性TSDB查询性能稳定性优化经历4.可观测性TSDB的过去、现在、未来可观测性TSDB演进路线-业务场景、数据规模050000100000150000查询QPS查询QPS20212022202302000400060008000打点量百万每秒打点(datapoint)量2021202220231亿亿+metrics数量数量可观测性TSDB演进路线(20192023)线 上 服 务 种 类、规 模 越 来 越 大；性 能、稳 定 性 要 求 越 来 越 高观 测

2、 服 务 用 途 的 时 序 数 据 写 入、查 询 量 数 倍 增 长完 全 依 赖 开 源 技 术 到 大 部 分 能力 自 研单 节 点 到 分 布 式 的 存 储、查 询多 架 构(O p e n T S D B,I n f l u x D B,P r o m e t h e u s)走 向 统 一可观测性TSDB整体架构-数据模型&使用姿势cpu_loadmem_usagedisk_iops写入SDK：Golang/Java/C+/Python数据类型：Timer/Counter/Gauge/Histogram查询：实现了绝大部分 OpenTSDB 查询语法，可通过 Grafana、

3、Bosun 等接入，亦可用OpenAPI 查询数据可观测性TSDB整体架构-整体架构可观测性TSDB整体架构-查询支持跨机房、跨节点的两级Scatter-Gather架构跨机房跨机房单机房跨节点单机房跨节点单节点内单节点内可观测性TSDB整体架构-查询分布式查询计划(DAG Plan)1.一次查询的逻辑执行计划最终会转换成一个DAG表示的物理执行计划。2.数据分片的IO，聚合计算，RPC请求都是DAG上的一个节点。3.整个DAG被拆分成多个部分（如查询拆分机房、时间分片），调度到多个节点上。调度器根据节点间依赖的拓扑顺序来调度节点保证计算的正确性。可观测性TSDB整体架构-查询性能、稳定性核心

4、3指标QPS峰值峰值ATBLatency P99Latency P50报警规则执行110K99.9%1360ms29ms可观测数据开放API27K99.9%1660ms45ms监控看板、大盘0.6K98.2%10000ms230ms图注：（1）ATB=2xx/(2xx+5xx)*100%（2）Latency的统计排除了瞬时毛刺（3）执行时间超过10000ms的查询主动time out返回504可观测性TSDB查询性能稳定性优化-查询瓶颈用户视角：（1）查询慢（2）查询忽快忽慢不稳定，查询超时失败（3）无法根据查询pattern做封禁/熔断重查询，只能封禁整个metric（4）单个请求查询7/1

5、4/30天及以上的数据，容易超时不返回数据可观测性TSDB视角：（1）使用姿势问题：部分用户打点的tagset维度数动辄高达3000w+、2亿+维度（2）使用姿势问题：部分用户单个请求中查询过去半年、一年的数据（3）服务自身问题：在Planner层、调度层、执行层上存在不合理的设计实现（4）服务自身问题：服务节点不稳定、内存资源瓶颈显著、GC开销较大，IO读放大可观测性TSDB查询性能稳定性优化-查询瓶颈举例内存瓶颈：某cpu usage 60%的节点，其中超过25%的cpu用来做GC可观测性TSDB查询性能稳定性优化-查询服务优化总结（回顾）QL ParserPlannerScheduler

6、Execution（1）轻重查询隔离（2）亲和力调度（3）Splits划分（4）推测执行Storage（1）自适应动态分片（2）物化视图构建（3）数据模型优化（4）基于数据特征做优化（5）索引（6）更精准的CBO数据（1）分布式执行模型（2）自动物化视图选择（1）查询限速熔断（2）Cache（3）filter算子下推（4）JDK升级（5）Java编码优化（6）RPC codec优化（包括存储、计算）（1）SubQuery个数削减（2）多SubQuery合并数据上报源头可观测性TSDB查询性能稳定性优化-轻重查询隔离热存冷存查询客户端query proxyqueryqueryquery以前：热存