PERCENTILE 函數(shu)(shu)用(yong)于統計表中某(mou)列的(de)值(zhi)(zhi)(zhi)百(bai)分位數(shu)(shu)，某(mou)一百(bai)分位所對應(ying)數(shu)(shu)據的(de)值(zhi)(zhi)(zhi)就(jiu)稱為(wei)這一百(bai)分位的(de)百(bai)分位數(shu)(shu)， 比如 90% 的(de)分位數(shu)(shu)的(de)值(zhi)(zhi)(zhi)，代表有 90% 的(de)數(shu)(shu)小于該(gai)分位數(shu)(shu)的(de)值(zhi)(zhi)(zhi)，10% 的(de)數(shu)(shu)大(da)(da)于該(gai)分位數(shu)(shu)的(de)值(zhi)(zhi)(zhi)。0 和 100 也就(jiu)相(xiang)當于集合的(de)最(zui)小值(zhi)(zhi)(zhi)跟(gen)最(zui)大(da)(da)值(zhi)(zhi)(zhi)。在具體業(ye)務中，我們經常用(yong)這一函數(shu)(shu)來衡量(liang)服務響應(ying)延遲(chi)，以最(zui)常用(yong)的(de) p99 為(wei)例(li)，它衡量(liang)了(le) 99% 的(de)情況(kuang)下(xia)(xia)能達到(dao)的(de)最(zui)大(da)(da)延遲(chi)，99% 的(de)請求都(dou)低于這個數(shu)(shu)值(zhi)(zhi)(zhi)，即絕(jue)大(da)(da)多數(shu)(shu)情況(kuang)下(xia)(xia)的(de)最(zui)差情況(kuang)。

今天我們為大家分享一個(ge)關于(yu) TDengine 在 PERCENTILE 函數性(xing)能優化上的真實(shi)案例。

麥當勞中國

這一案例主角是麥當勞中國，其在運維領域用 TDengine 來存儲服務器監控相關數據，目前麥當勞中國的服務器數量約 800 個，單個服務器最高時每天產生 1000 萬條數據，每天服務器產生的總數據量高達 35 億條。每個服務器(qi)的(de)(de)數(shu)據各存(cun)于一個子表(biao)中，每天都需進行數(shu)據統(tong)計匯總。由于麥(mai)當勞中國業務上的(de)(de)查詢主(zhu)要以(yi) percentile 函數(shu)為主(zhu)，因此(ci)這一函數(shu)的(de)(de)性(xing)能也是其最關注的(de)(de)問題。

其查詢流程如下：

• Parser 將 SQL 語句轉化為抽象語法樹 AST，并且通過 catalog 模塊獲取元數據信息進行校驗。
• Planner 通過 AST 轉化為邏輯執行計劃(LogicPlan)， 然后經過 Optimizer 對邏輯計劃進行簡化、重寫， filter/limit 下推等優化，將邏輯計劃通過分布式計劃拆分，轉換為可執行的物理計劃(Physical Plan)。
• Scheduler 通過 PRC 模塊將物理執行計劃放到消息中，調度到各個 vnode。
• vnode 查詢線程是通過物理計劃創建算子樹(Operator Tree)，通過執行器(Executer)從 root 節點上游算子向下執行。數據流方向則相反，從 datasink 逐級向上返回，例如，需要先從 table scan 算子在 TSDB 讀取數據，然后再從 Aggregate 算子調用 Function 模塊進行聚合計算。
• 對于查詢超級表時要進行分布式執行，并且需要 second stage 聚合的操作，根據物理計劃(由客戶端 queryPolicy 決定)在 vnode/qnode/client 再次進行聚合計算，然后再返回查詢結果給客戶端。

查詢描述如下：

SELECT COUNT(*), AVG(duration), PERCENTILE(duration,90) as line_90, PERCENTILE(duration,95) as line_95, PERCENTILE (duration,99) as line_99, PERCENTILE (duration,99.99) as line_9999 FROM tb_0 WHERE ts >='2020-01-01 00: 00:00.00.0000' and ts <= '2020-01-02 00:00:00.000';

• 查詢內容：響應時間的百分位占比
• 查詢值 count、avg、P90、P95、P99、P99.99 固定同時查詢
• 查詢對象：每個服務的子表，不對超級表進行查詢
• 查詢條件：1 天的時間段左右（可變，任意時間段）
• 并發量：個位數并發查詢

麥當勞中國希望在此業務背景下，單表 1000 萬條數據查詢響應時間能夠在秒內實現，這也是本次PERCENTILE 函數性能優化的重點。

優化過程簡述

在(zai)針對整個(ge)查詢以及(ji)函數的(de)執行(xing)流程以及(ji)邏輯進(jin)行(xing)詳細分析后，我們發(fa)現單獨查詢 1 個(ge) PERCENTILE 耗(hao)時在(zai) 1.1s，2 個(ge) PERCENTILE 耗(hao)時在(zai) 1.8s，3 個(ge) PERCENTILE 在(zai) 2.5s 左(zuo)右，而無論幾個(ge) PERCENTILE 執行(xing)，table scan 部(bu)分都是(shi)公共的(de)，因此通過(guo)相(xiang)減可以推斷(duan)出單獨一(yi)個(ge) PERCENTILE 消耗(hao)在(zai) AGGREGATE 以及(ji) PROJECTION 部(bu)分的(de)耗(hao)時，即(ji) 1 個(ge) PERCENTILE 耗(hao)時 0.7s，2 個(ge) 1 耗(hao)時 1.4s，這個(ge)幾乎是(shi)線(xian)性(xing)增長的(de)，而 table scan 部(bu)分在(zai) 0.4s， 總體上多(duo)個(ge) PERCENTILE 耗(hao)時就是(shi)：

table_scan_cost(0.4s) + process_cost(0.7s) * N

因為 table scan 這部分涉及(ji)到 tsdbread 的(de)存儲，因此可以(yi)優化(hua)(hua)的(de)點在于是否可以(yi)將單個耗時減(jian)少 0.7s， 或者減(jian)少執(zhi)行(xing)(xing)(xing)(xing)次(ci)數 N。由于函(han)數實際執(zhi)行(xing)(xing)(xing)(xing)時間優化(hua)(hua)起來相(xiang)對困難，函(han)數算法基本(ben)上也是業界比較(jiao)成(cheng)熟(shu)的(de)算法，在不(bu)對算法優化(hua)(hua)的(de)情況下，可能只能通過(guo)一(yi)些代碼技巧來做優化(hua)(hua)。減(jian)少執(zhi)行(xing)(xing)(xing)(xing)次(ci)數 N 的(de)關鍵(jian)在于看多次(ci)函(han)數執(zhi)行(xing)(xing)(xing)(xing)時是否有共用的(de)地方可以(yi)進行(xing)(xing)(xing)(xing)合并。

通過觀(guan)察麥當勞(lao)中(zhong)國的幾個 PERCENTILE 查詢，我(wo)們(men)總結出了一(yi)個特點(dian)，它們(men)所(suo)涉(she)及的數據列都是(shi)同一(yi)列，數據范(fan)圍(wei)都是(shi)固定的，這種情況下我(wo)們(men)可以合并數據進行分(fen)桶的部分(fen)。通過這種優(you)化方式執行時間變為：

table_scan_cost + process_cost * N -> table_scan_cost + process_cost * 1

這樣一來，即(ji)使執(zhi)行多個 PERCENTILE 時間也不會隨個數線性(xing)增(zeng)長(chang)，測試結(jie)果也驗證了這一優(you)化(hua)(hua)的成功性(xing)。但當前結(jie)果穩定在 1.1s 左右，加上 count 和 avg，總(zong)時間在 1.2s，仍然還未能達到(dao)麥當勞(lao)中國要(yao)求(qiu)的執(zhi)行時間優(you)化(hua)(hua)到(dao) 1s 內。

最終結果

這(zhe)時(shi)我們將(jiang)重(zhong)點放(fang)在“單個耗時(shi)減(jian)少 0.7s”上，經過分析明(ming)確了多出的 300ms 耗時(shi)主要在第(di)一遍 table sacn 以及計算上。

麥(mai)當(dang)勞中國在查詢上(shang)除了使(shi)用 PERCENTILE，還使(shi)用了其他的(de)(de)多個(ge)函(han)數，比如 COUNT，AVG 等其他函(han)數。通(tong)過日志查看具(ju)體(ti)物理計劃以(yi)(yi)及執行器的(de)(de)邏輯，發(fa)現 PERCENTILE 對(dui)于兩(liang)遍掃描以(yi)(yi)及計算是這樣(yang)的(de)(de)：

在(zai)第一遍(bian) main scan 時，物理計(ji)(ji)(ji)(ji)劃指定 dataLoad 為 1，也就是(shi)(shi)需要實(shi)(shi)際(ji)(ji)(ji)(ji)加(jia)載數(shu)據(ju)，而(er)不去(qu)讀 sma 的(de)(de)值，這是(shi)(shi)因為其(qi)他函(han)(han)數(shu)的(de)(de)實(shi)(shi)際(ji)(ji)(ji)(ji)計(ji)(ji)(ji)(ji)算(suan)(suan)(suan)，以及(ji) PERCENTILE 的(de)(de)第一階(jie)段計(ji)(ji)(ji)(ji)算(suan)(suan)(suan)，都(dou)會(hui)在(zai) main scan 執(zhi)行(xing)，而(er)很多函(han)(han)數(shu)的(de)(de)計(ji)(ji)(ji)(ji)算(suan)(suan)(suan)實(shi)(shi)際(ji)(ji)(ji)(ji)上是(shi)(shi)不能(neng)依賴 sma 的(de)(de)，所以為了保證大部(bu)分(fen)函(han)(han)數(shu)能(neng)夠計(ji)(ji)(ji)(ji)算(suan)(suan)(suan)，就需要加(jia)載實(shi)(shi)際(ji)(ji)(ji)(ji)數(shu)據(ju)進行(xing)計(ji)(ji)(ji)(ji)算(suan)(suan)(suan)。對于第二遍(bian)掃描 second stage scan，PERCENTILE 函(han)(han)數(shu)第二個(ge)階(jie)段的(de)(de)執(zhi)行(xing)，需要加(jia)載實(shi)(shi)際(ji)(ji)(ji)(ji)數(shu)據(ju)去(qu)做(zuo)分(fen)桶并計(ji)(ji)(ji)(ji)算(suan)(suan)(suan)最(zui)終的(de)(de)結果，不能(neng)使用(yong) sma，因此 dataload 仍然是(shi)(shi) 1。

針對(dui)這(zhe)種情(qing)況，因為 PERCENTILE 第一階(jie)段可以(yi)使用 sma 加速，因此我們將執(zhi)行(xing)邏輯改(gai)為下(xia)面這(zhe)種方式(shi)：

也就(jiu)是說，在(zai)(zai)創建計劃(hua)時(shi)，檢測到有(you) PERCENTILE 函數參與運算時(shi)，將(jiang)第(di)一遍掃表設(she)置(zhi)為 Pre Scan，并(bing)且(qie)設(she)置(zhi) dataLoad 為 0，因此 PERCENTILE 第(di)一階(jie)段計算可以(yi)使(shi)用 sma， 而不是實際拉取數據(ju)。第(di)二遍掃表則當作 Main Scan，將(jiang)其(qi)他函數的計算跟 PERCENTILE 第(di)二階(jie)段放在(zai)(zai)一起，不影響之前的邏輯(ji)。

經過這兩次優化操作，最終我們消除了多出的 300ms，加上 count、avg 函數后，查詢時間在 0.8s 左右，成功幫助麥當勞中國將單表 1000 萬條數據查詢響應時間控制在了秒內。

寫在最后

PERCENTILE 秒級查詢優化對于麥當勞中國來說是一項重要的技術升級，可以幫助他們更靈活、更實時地管理和優化業務運營，也為麥當勞中國與 TDengine 的更長遠合作打下了基礎。希望這一優化工作的經驗分享能給到你幫助，如果大家還有更多的技術問題想要交流，可以添加小Tvx：tdengine，和 TDengine 資深研(yan)發進行溝(gou)通。