《3-3 高英举-海量可观测性时序数据库的分布式查询演进之路.pdf》由会员分享,可在线阅读,更多相关《3-3 高英举-海量可观测性时序数据库的分布式查询演进之路.pdf(34页珍藏版)》请在三个皮匠报告上搜索。
1、海量可观测性时序数据库的分布式查询演进之路演讲人:字节跳动 高英举目录1.可观测性TSDB演进路线2.可观测性TSDB整体架构3.可观测性TSDB查询性能稳定性优化经历4.可观测性TSDB的过去、现在、未来可观测性TSDB演进路线-业务场景、数据规模0500000查询QPS查询QPS202000400060008000打点量百万每秒打点(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以前:热存
7、查询、冷存查询分开调度热存查询:查询涉及的数据在热存冷存查询:查询涉及的数据在冷存跨冷热存查询:涉及的数据在跨越了热存、冷存问题:(1)轻查询、重查询混在一起执行,相互影响(2)少量重查询导致大量轻查询Latency不稳定(3)查询性能不仅受到存储介质的IO效率影响,与查询涉及的数据量也有关系热存是基于纯内存构建的一套存储服务,存储最近28小时的数据冷存是基于HDFS构建的一套存储服务,存储28小时以前的数据单机房内的查询架构round robin的方式将请求调度到query节点node group 0node group 1可观测性TSDB查询性能稳定性优化-轻重查询隔离热存冷存查询客户端q
8、uery proxyqueryqueryquery现在:轻查询、重查询分开调度轻查询:查询涉及的数据量较少重查询:查询涉及的数据量较多获取查询涉及数据量的手段(1)通过存储服务对外暴露的API,访问延迟在2ms10ms(2)存储服务内置统计数据(series数、dps数、bytes数)(3)考虑了filter pushdown的情况,存储服务可查询内存中的索引快速统计收益:(1)重查询不影响轻查询(2)轻查询Latency低且稳定(3)不合理的重查询的执行受到限制问题:(1)重查询可用资源更少,性能可能劣化思考:(1)重查询是否是伪需求?(2)能否既要保障轻查询,还要保障重查询?单机房内的查询
9、架构将请求先发到query轻查询执行节点,如果query认定其为重查询,则返回307 Redirect,将请求重定向到query重查询执行节点node group 0node group 1307 Redirect Location轻查询重查询可观测性TSDB查询性能稳定性优化-轻重查询隔离跨机房的查询架构dc1dc2dc3query proxy(1)(2)(3)(4)跨机房调度:对于跨机房的查询,如果查询涉及的数据不在本机房,则通过307 Redirect到对应数据所在的机房收益:(1)避免了query node作为多一跳的中转节点带来的数据序列化反序列化、network io开销(2)避免
10、了作为中间跳板的节点内存的GC压力具体查询案例:sum:service.node_statscpu_usagedc=dc2|dc3如果要查询所有dc的数据,并且按dc分组,查询pattern如下:sum:service.node_statscpu_usagedc=*307 Redirect Location查询客户端可观测性TSDB查询性能稳定性优化-自适应动态分片背景知识:一个metric在存储的数据分布假设(1)存储有4个shard(2)某个metric在存储中有2个bucketbucket0bucket0bucket0timeslot0timeslot1timeslot2shard 1s
11、hard 0shard 2bucket1bucket1bucket1shard 3writerrouting by hash可观测性TSDB查询性能稳定性优化-自适应动态分片bucket0bucket1bucket47bucket0bucket1bucket47big metric数据分布情况small metric数据分布情况queryquery以前:数据分布bucket数固定,与数据量无关big metric:数据量较大的metricsmall metric:数据量较小的metric问题:(1)small metric容易出现数据分布过度分散导致存储效率低,查询时RPC过多并行度过大,产生
12、惊群效应,进一步导致集群整体并发量上不去。(1)big metric容易出现数据分布不够分散导致数据写入存储时处理堆积,查询时不好提高数据读取并行度思考:(1)能不能仅通过查询的分片(Splits)划分策略来解决问题?可观测性TSDB查询性能稳定性优化-自适应动态分片bucket0bucket1bucket96bucket0bucket1big metric数据分布情况small metric数据分布情况queryquery现在:根据数据量做数据分布,决定bucket数(1)自适应自适应:根据metric数据量自动决策bucket数(2)动态动态:可随时对bucket数扩容、缩容,不需要重启服
13、务。(3)生效延迟:delta_valuerate(counter_value)=rate_value可观测性TSDB查询性能稳定性优化-构建与自动选择物化视图Tag Rewrite适用场景:将所有服务的数据都上报到同一个metric的大型框架类metric,例如rpc、mq、tracing类指标。原始指标特点:指标中的某些tagkey能够区分不同的服务(例如psm),数据量非常大查询特点:每个用户只查询自己关系的少数服务的数据解决方案:数据写入存储时,按照指定tagkey将原始指标重写为多个指标。收益:(1)减少因指标数据量过大导致的写入封禁(2)查询时在存储中扫描的数据量、索引都更小,更快
14、返回数据。psm=a.b.cpsm=k.m.npsm=x.y.zpsm=a.b.c。psm=k.m.npsm=x.y.z可观测性TSDB查询性能稳定性优化-构建与自动选择物化视图Pre-Aggregation适用场景:数据量较大的指标,查询中主要对某些特定tagkey分组聚合,并且对其他tagkey的预聚合能够显著减少数据量。原始指标特点:指标数据量非常大,某些非常用聚合的tagkey维度较高。解决方案:数据写入存储时,按照指定tagkey将原始指标重写为多个指标。如果不需要原始指标可以丢弃。收益:(1)减少因指标数据量过大导致的写入封禁(2)查询时在存储中扫描的数据量、索引都更小,更快返回数
15、据。查询真正涉及的数据量显著减少。dcclusterpathstatusnode_id(高维度)(高维度)dcclustersum(req_cnt)clusterstatussum(req_cnt)sum:service.statsdc=*,cluster=*【命中1个Pre-Aggregation】sum:service.statscluster=c1|c2|c3【命中多个Pre-Aggregation】sum:service.statsdc=*,path=*【未命中Pre-Aggregation】可观测性TSDB查询性能稳定性优化-构建与自动选择物化视图Pre-Downsample适用场景
16、:查询时对数据结果的时间精度要求不高(如单个查询的时间跨度7/14/30天,绘制监控折线图),并且希望查询速度快。原始指标特点:数据量大(序列多且点密集)解决方案:(1)数据写入存储时,同时做降低时间精度处理。(2)根据查询时间跨度长短自动选择不同精度pre-downsample物化视图。例如时间跨度越长,选择时间精度越低的物化视图。收益:(1)查询时在存储中扫描的数据量、索引都更小,更快返回数据。查询真正涉及的数据量显著减少。t0t1t2t3t4t5t6t7.t0t4.t0.原始指标1/4 Pre-Downsample1/8 Pre-Downsample可观测性TSDB查询性能稳定性优化-冷
17、存Cache+亲和力调度HDFS特性剖析:-HDFS是优先吞吐设计的,并不是很适合要求低延迟、高并发读的场景。顺序读取整个文件会比较快,大量随机读取文件的部分数据没有顺序读取的吞吐高(read bytes per second)。-HDFS读取同样大小数据量延迟波动很大,实验中发现读取同样1MB数据,有时只需要100ms,有时需要2s。-对于同一个数据块(例如几十MB),想要通过增加并发来降低读取该数据块的总延迟并不可行,甚至可能会增加读取总延迟。-HDFS List File、Open File的延迟时快时慢不稳定,因此在查询时,我们要去打开的File越少越好。-基于HDFS存储时,主要的优
18、化方向是减少读取的数据量。因为在多次大量Query执行时的数据读取延迟中,可以得到的普遍规律是:虽然数据读取延迟的不稳定性存在,但是读取小数据量的延迟普遍低于读取大数据量的延迟。Query热存(Mem)冷存(HDFS)可观测性TSDB查询性能稳定性优化-冷存Cache+亲和力调度Query冷存(HDFS)Data CacheMetadata CacheBytedance可观测性TSDBMeta(Facebook)PrestoMeta(Facebook)的实践经验类似,参见:https:/prestodb.io/blog/2021/02/04/raptorx可观测性TSDB查询性能稳定性优化-冷
19、存Cache+亲和力调度CacheQueryQueryCacheQuery冷存(HDFS)查询客户端query proxySplit0=(shard0,timeslot0)CacheQuerySplit0=(shard1,timeslot0)Split0=(shard2,timeslot0)Data Splits划分Split0Split1Split2亲和力调度的重要性、风险Split调度到哪些节点的逻辑:调度到哪些节点的逻辑:hash()+hash()可观测性TSDB查询性能稳定性优化-查询服务优化总结(回顾)QL ParserPlannerSchedulerExecution(1)轻重查询
20、隔离(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查询性能稳定性优化-查询性能稳定性优化的辅助手段(1)核心指标长期变化趋势的看板熟悉核心指标定位瓶颈POC试错工程化实现全链路回归压测上线发布(
21、1)Metrics与监控看板(2)QueryLog(3)Tracing(4)CPU火焰图(5)Jmap、Visualvm(6)Arthas常态化全链路回归压测体系(1)流量复制(2)请求修改(3)数据导入(4)测试集群(尽量接近线上规模)可观测性TSDB的过去、现在、未来-专用时序数据库代际 第一代专用时序数据库的代表:OpenTSDB OpenTSDB其特点是能做简单聚合查询,简单到大部分基本的数据计算能力都是缺失的。第二代专用时序数据库的代表:Prometheus,VictorMetrics,InfluxDB 从Prometheus的QL可以看出其支持的功能性至少在APM领域较OpenTS
22、DB相对完整,例如支持多种数据计算functions,支持多个指标按照相同tag联结(JOIN)后的算术运算(+,-,*,/)。InfluxDB以SQL作为QL,支持了分析型数据库中的单表查询的大部分语义,并针对时序数据处理的特征,对SQL的语义有所补充扩展。第三代专用时序数据库的代表:AWS Timestream,TimescaleDB,Influx IOX等。广泛吸收了OLAP数据库领域常用的优化,技术架构上越来越向真正的分析型数据库靠拢,比如多值计算、列式格式、向量化执行、MPP执行等等。时序数据库计算层也有了明确的计算模型,类似分析型数据库那样明确了QL、Logical Plan、Ph
23、ysical Plan、Distributed Plan等。也有很多时序数据库计算层直接基于分析型数据库计算层的整套架构或代码库来构建。例如:AWS Timestream基于Presto、TimescaleDB基于PostgresSQL。可观测性TSDB的过去、现在、未来通用分析型数据库 vs 专用时序数据库(第一代、第二代)可观测性TSDB的过去、现在、未来通用分析型数据库 vs 专用时序数据库(第三代)可观测性TSDB的过去、现在、未来主要收获:(1)自研vs 开源的技术路线选择:亲身实践、走弯路、大彻大悟(2)少埋技术债,选对师傅、打好地基:以优秀的开源项目为根基来做自研(3)从源头解决
24、问题:教育、规范好用户对TSDB的使用姿势(4)找到主要场景、主要瓶颈、主要问题:5%的用户打点引发了95%的TSDB写入、查询链路问题。例如:高维度数据,重查询。时序数据库能从数据库领域40年+的发展学习到什么?(1)抽象语法树、逻辑执行计划、物理执行计划、优化器(2)Volcano(Iterator Model)执行模型(3)分布式计算模型:Scatter Gather,多Stage。(4)列式格式(5)基于CBO的查询优化(6)灵活高效的调度策略:基于轻重查询的调度,基于负载的调度,基于逻辑隔离的调度等。Bytedance 可观测TSDB的存储、查询能力未来规划:(1)TSDB冷存、热存架构融合(2)Metrics、Log、Trace数据all in one存储、查询(3)时序计算QL的对比选择:类SQL vs 类SPL vs 特定QL(PromQL,InfluxQL)(4)存储与查询更紧密的配合,例如:CBO、索引、物化视图、RPC codecTHANK YOU!