PERCENTILE 函數(shù)用于統(tǒng)計(jì)表中某列的值百分位數(shù)，某一百分位所對(duì)應(yīng)數(shù)據(jù)的值就稱為這一百分位的百分位數(shù)， 比如 90% 的分位數(shù)的值，代表有 90% 的數(shù)小于該分位數(shù)的值，10% 的數(shù)大于該分位數(shù)的值。0 和 100 也就相當(dāng)于集合的最小值跟最大值。在具體業(yè)務(wù)中，我們經(jīng)常用這一函數(shù)來衡量服務(wù)響應(yīng)延遲，以最常用的 p99 為例，它衡量了 99% 的情況下能達(dá)到的最大延遲，99% 的請(qǐng)求都低于這個(gè)數(shù)值，即絕大多數(shù)情況下的最差情況。

今天我們?yōu)榇蠹曳窒硪粋€(gè)關(guān)于 TDengine 在 PERCENTILE 函數(shù)性能優(yōu)化上的真實(shí)案例。

麥當(dāng)勞中國

這一案例主角是麥當(dāng)勞中國，其在運(yùn)維領(lǐng)域用 TDengine 來存儲(chǔ)服務(wù)器監(jiān)控相關(guān)數(shù)據(jù)，目前麥當(dāng)勞中國的服務(wù)器數(shù)量約 800 個(gè)，單個(gè)服務(wù)器最高時(shí)每天產(chǎn)生 1000 萬條數(shù)據(jù)，每天服務(wù)器產(chǎn)生的總數(shù)據(jù)量高達(dá) 35 億條。每個(gè)服務(wù)器的數(shù)據(jù)各存于一個(gè)子表中，每天都需進(jìn)行數(shù)據(jù)統(tǒng)計(jì)匯總。由于麥當(dāng)勞中國業(yè)務(wù)上的查詢主要以 percentile 函數(shù)為主，因此這一函數(shù)的性能也是其最關(guān)注的問題。

其查詢流程如下：

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

查詢描述如下：

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';

• 查詢內(nèi)容：響應(yīng)時(shí)間的百分位占比
• 查詢值 count、avg、P90、P95、P99、P99.99 固定同時(shí)查詢
• 查詢對(duì)象：每個(gè)服務(wù)的子表，不對(duì)超級(jí)表進(jìn)行查詢
• 查詢條件：1 天的時(shí)間段左右（可變，任意時(shí)間段）
• 并發(fā)量：個(gè)位數(shù)并發(fā)查詢

麥當(dāng)勞中國希望在此業(yè)務(wù)背景下，單表 1000 萬條數(shù)據(jù)查詢響應(yīng)時(shí)間能夠在秒內(nèi)實(shí)現(xiàn)，這也是本次PERCENTILE 函數(shù)性能優(yōu)化的重點(diǎn)。

優(yōu)化過程簡述

在針對(duì)整個(gè)查詢以及函數(shù)的執(zhí)行流程以及邏輯進(jìn)行詳細(xì)分析后，我們發(fā)現(xiàn)單獨(dú)查詢 1 個(gè) PERCENTILE 耗時(shí)在 1.1s，2 個(gè) PERCENTILE 耗時(shí)在 1.8s，3 個(gè) PERCENTILE 在 2.5s 左右，而無論幾個(gè) PERCENTILE 執(zhí)行，table scan 部分都是公共的，因此通過相減可以推斷出單獨(dú)一個(gè) PERCENTILE 消耗在 AGGREGATE 以及 PROJECTION 部分的耗時(shí)，即 1 個(gè) PERCENTILE 耗時(shí) 0.7s，2 個(gè) 1 耗時(shí) 1.4s，這個(gè)幾乎是線性增長的，而 table scan 部分在 0.4s， 總體上多個(gè) PERCENTILE 耗時(shí)就是：

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

因?yàn)?table scan 這部分涉及到 tsdbread 的存儲(chǔ)，因此可以優(yōu)化的點(diǎn)在于是否可以將單個(gè)耗時(shí)減少 0.7s， 或者減少執(zhí)行次數(shù) N。由于函數(shù)實(shí)際執(zhí)行時(shí)間優(yōu)化起來相對(duì)困難，函數(shù)算法基本上也是業(yè)界比較成熟的算法，在不對(duì)算法優(yōu)化的情況下，可能只能通過一些代碼技巧來做優(yōu)化。減少執(zhí)行次數(shù) N 的關(guān)鍵在于看多次函數(shù)執(zhí)行時(shí)是否有共用的地方可以進(jìn)行合并。

通過觀察麥當(dāng)勞中國的幾個(gè) PERCENTILE 查詢，我們總結(jié)出了一個(gè)特點(diǎn)，它們所涉及的數(shù)據(jù)列都是同一列，數(shù)據(jù)范圍都是固定的，這種情況下我們可以合并數(shù)據(jù)進(jìn)行分桶的部分。通過這種優(yōu)化方式執(zhí)行時(shí)間變?yōu)椋?/p>

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

這樣一來，即使執(zhí)行多個(gè) PERCENTILE 時(shí)間也不會(huì)隨個(gè)數(shù)線性增長，測(cè)試結(jié)果也驗(yàn)證了這一優(yōu)化的成功性。但當(dāng)前結(jié)果穩(wěn)定在 1.1s 左右，加上 count 和 avg，總時(shí)間在 1.2s，仍然還未能達(dá)到麥當(dāng)勞中國要求的執(zhí)行時(shí)間優(yōu)化到 1s 內(nèi)。

最終結(jié)果

這時(shí)我們將重點(diǎn)放在“單個(gè)耗時(shí)減少 0.7s”上，經(jīng)過分析明確了多出的 300ms 耗時(shí)主要在第一遍 table sacn 以及計(jì)算上。

麥當(dāng)勞中國在查詢上除了使用 PERCENTILE，還使用了其他的多個(gè)函數(shù)，比如 COUNT，AVG 等其他函數(shù)。通過日志查看具體物理計(jì)劃以及執(zhí)行器的邏輯，發(fā)現(xiàn) PERCENTILE 對(duì)于兩遍掃描以及計(jì)算是這樣的：

在第一遍 main scan 時(shí)，物理計(jì)劃指定 dataLoad 為 1，也就是需要實(shí)際加載數(shù)據(jù)，而不去讀 sma 的值，這是因?yàn)槠渌瘮?shù)的實(shí)際計(jì)算，以及 PERCENTILE 的第一階段計(jì)算，都會(huì)在 main scan 執(zhí)行，而很多函數(shù)的計(jì)算實(shí)際上是不能依賴 sma 的，所以為了保證大部分函數(shù)能夠計(jì)算，就需要加載實(shí)際數(shù)據(jù)進(jìn)行計(jì)算。對(duì)于第二遍掃描 second stage scan，PERCENTILE 函數(shù)第二個(gè)階段的執(zhí)行，需要加載實(shí)際數(shù)據(jù)去做分桶并計(jì)算最終的結(jié)果，不能使用 sma，因此 dataload 仍然是 1。

針對(duì)這種情況，因?yàn)?PERCENTILE 第一階段可以使用 sma 加速，因此我們將執(zhí)行邏輯改為下面這種方式：

也就是說，在創(chuàng)建計(jì)劃時(shí)，檢測(cè)到有 PERCENTILE 函數(shù)參與運(yùn)算時(shí)，將第一遍掃表設(shè)置為 Pre Scan，并且設(shè)置 dataLoad 為 0，因此 PERCENTILE 第一階段計(jì)算可以使用 sma， 而不是實(shí)際拉取數(shù)據(jù)。第二遍掃表則當(dāng)作 Main Scan，將其他函數(shù)的計(jì)算跟 PERCENTILE 第二階段放在一起，不影響之前的邏輯。

經(jīng)過這兩次優(yōu)化操作，最終我們消除了多出的 300ms，加上 count、avg 函數(shù)后，查詢時(shí)間在 0.8s 左右，成功幫助麥當(dāng)勞中國將單表 1000 萬條數(shù)據(jù)查詢響應(yīng)時(shí)間控制在了秒內(nèi)。

寫在最后

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