3-3 高英舉-海量可觀測性時序數據庫的分布式查詢演進之路.pdf

《3-3 高英舉-海量可觀測性時序數據庫的分布式查詢演進之路.pdf》由會員分享，可在線閱讀，更多相關《3-3 高英舉-海量可觀測性時序數據庫的分布式查詢演進之路.pdf（34頁珍藏版）》請在三個皮匠報告上搜索。

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）查詢忽快忽慢不穩定，查詢超時失?。?）無法根據查詢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!