導讀：性能分析等場景對實時分位數有強烈訴求。在計算累計時長時，能夠將不一樣時間段的時長簡單相加，而分位數卻沒法先計算不一樣維度下的分位值，而後對其直接聚合，該特性對實時計算帶來了較大挑戰。咱們基於TDigest數據結構，利用Redis和Doris等高性能存儲，預先計算全部可能查詢的分位值指標，既能夠快速計算指標，同時能夠保障查詢效率。該系統已經對百度內內核性能、網絡性能等業務場景進行輸出，並能有效知足業務高時效的分析需求。前端
全文3663字，預計閱讀時間10分鐘。算法
1、問題描述與技術挑戰
在實際工做中，咱們發現許多業務場景中都有對某一數值型指標實時統計分位數的需求，通常要求計算結果有很高準確率同時具有極低的計算延遲，實現這類需求給數據RD的開發工做帶來必定的挑戰，其中主要的技術挑戰包括如下三個方面：後端
沒法對全量數據進行排序：因爲在實時計算場景中是逐條處理數據的，沒法對全量數據排序，進而沒法得到全量數據的分位數數組
計算邏輯複雜，計算延遲高：即時在可以排序的場景中，高複雜度的排序操做也會帶來很高的計算延遲，沒法知足實時計算的低延遲要求性能優化
分位數結果沒法聚合：兩個計算得出的分位數結果沒法像求和結果那樣直接累加合併獲得新的結果，這爲分位數計算結果的存儲方式帶來挑戰網絡
針對上述問題，咱們基於TDigest數據結構，實現了實時計算環境下的分位數計算方法，封裝爲基礎組件並向上提供API接口，能夠在不一樣的業務場景（內核性能、搜索性能、PUSH等）下提供實時、準確的分位數計算。數據結構
2、基礎架構與解決方案
本節咱們將從計算分位數的經常使用數據結構、咱們實現分位數計算的基礎架構、解決方案三部分介紹流式計算場景下的分位數計算方法：架構
2.1 分位數的經常使用數據結構
TDigest計算分位數app
TDigest是一個簡單，快速，精確度高，可並行化的近似百分位算法，被Spark, ES, Kylin等系統使用。TDigest的核心思想是經過聚類的方法將離散的數據點彙集爲多個不一樣的質心，在經過線性插值法計算分位數，線性插值法是最簡單的插值算法。性能
通俗的講：傳統方法是對離散的數據進行排序，在排序結果中直接得到分位數。而TDigest是將離散的數據聚類爲多個質心，而後對質心進行近似的「排序」，最後經過插值法求取分位數。
如上圖所示，將離散的數據點(圖中無色的數據點)聚類爲多個不一樣的質心(圖中彩色的數據點)，其中每一個質心周圍的數據點數決定了該質心所佔的權重(圖中質心的大小)，最後經過對全部的質心進行排序，就可使用線性插值法求取對應的分位數，其中數據點與質心的距離和權重關係以下圖所示。
特別地，在每一個TDigest建立時有一個重要的compression參數，主要用於在計算的精確度與空間複雜度之間作權衡：
當compression參數設置越大時，聚類獲得的質心越多，則差分法求取的分位數精確度越高
當compression參數設置越大時，TDigest數據結構佔用的存儲空間越大，則分位數計算的空間複雜度越高
設置合適的compression參數，可以在提升計算準確率的同時，儘量下降存儲空間，從而知足業務的實際需求
爲了幫助你們在作分位數計算時可以選取合適的參數，咱們選擇百萬級的數據量(即統計100w個隨機變量的分位數)，在不一樣參數下的計算精確度和空間複雜的以下表所示：
針對上表所示的數據，咱們將作出如下三點說明：
本次測試使用MergingDigest數據結構，該結構佔用的空間與compression參數的取值有關，與統計的數據量無關；
隨着數據量的增大，compression的取值應適當增大，可以有效提升計算的準確率
2.2 分位數組建的基礎架構
因爲實時分位數計算是一個常見統計方法，在許多業務場景都會提出相似的需求，對需求方關注的統計指標計算不一樣的分位數。
爲節約人力成本，縮短迭代開發的時間週期，咱們基於TDigest數據結構，封裝了通用的基礎組件，從而在不一樣的業務場景下快速實現實時分位數統計的開發。
如上圖所示，在實時分位數計算的通用組件中，其基礎架構和執行過程主要分爲如下幾個關鍵步驟：
1) 從上游業務方讀取須要統計分位數的原始數據
-
根據業務方需求的分組規則，按分組聚合爲TDigest數據結構，將聚合結果存入Redis中，或與Redis中已存在對應的數據進行合併，以獲取準確的計算結果
-
從TDigest結構中獲取分位數的計算結果，並向上返回
綜上所述，咱們經過封裝基礎組件並向上提供API的方式，實現了通用、靈活且對應用方透明的分位數計算方法，可以保證明時性的同時，實現高準確率、低空間複雜度的分位數計算，目前已經在性能平臺、搜索、PUSH等廠內多個業務需求中落地應用
2.3 總體實現方案
基於上述介紹的實時分位數基礎組件，在廠內的大多數業務場景中，一般從消息隊列中獲取應用方上報的原始數據，通過一系列解析和計算後，將計算結果存儲Doris等OLAP引擎或DB中，共需求方查詢和生成對應報表，這是一個通用的解決方案。
根據上述分析，咱們就能夠獲得一個分位數實時計算做業的基本架構，其架構模型以下圖所示：
如上圖所示，在廠內的環境中，實時分位數計算任務的經常使用基本架構主要包括如下幾個關鍵步驟：
1）從消息隊列中讀取業務方上報的基礎數據，並按業務邏輯進行數據解析；
2）經過FlatMap方法，按不一樣字段將一條數據展開爲多條（具體內容將在第3節詳細介紹）；
3）根據業務設計的查詢維度，按不一樣的key對數據進行分組操做
4）分別將每一個key的數據合併爲一個TDigest數據結構
5）將聚合後的數據與Redis中存儲的數據進行合併，同時將合併結果寫回Redis中
6）最後根據數據聚合結構，從每一個分組對應的TDigest結構中獲取對應的分位數
綜過以上步驟，能夠實現高實時性、高精確度和低空間複雜度的實時分位數計算方法，可以知足大多數實時分位數業務的需求，在更多的業務場景中可能須要根據實際需求進行適當的調整。
3、解決分位數沒法聚合的問題
3.1 問題描述
在實際的業務需求中，咱們可能須要按照不一樣的時間、查詢維度等信息檢索統計的分位數。可是，已經計算好的兩個分位數結果是沒法進行聚合操做的。
例如：針對手百APP的用戶訪問時長，咱們能夠將某一天中每一個小時訪問時長的和(SUM)進行累加，從而得到這一天的訪問時長總和。但咱們若是記錄了每一個小時中訪問時長的80分位數，則沒法對這些分位數進行聚合，即沒法求得這一天中訪問時長的80分位數。這種現象被稱爲分位數的「不可聚合性」
所以，在實際應用中，若是業務需求要對不一樣時間、不一樣維度下的指標分位數進行任意聚合、查詢等操做，就爲分位數的計算和存儲提出新的技術挑戰。
3.2 分位數聚合方案
針對上述問題，咱們提出按全部查詢維度進行提早聚合計算的解決方案，即針對每一種可能出現的查詢維度組合，咱們都提早計算分位數並存儲，這樣在查詢過程當中直接檢索對應查詢維度的聚合計算結果，在解決了分位數的「不可聚合性」問題的同時，也避免了重複的聚合計算帶來的時間開銷，縮短了查詢耗時，提高了用戶體驗。
接下來，咱們經過一個簡單實例講解具體的聚合計算方法：假設在某業務場景中，用戶關注的查詢維度共有三個字段，分別爲：APP版本(app_version)、廠商(manufacturer)和客戶端操做系統版本(os_version)。則對於任意維度組合的查詢操做，用戶有可能採用 2^3=8 種聚合查詢方式。所以，咱們經過排列組合的方式，枚舉中全部可能的聚合查詢方式，分別統計分位數。假設從上游讀取到的部分數據以下表所示：
而且，若是對某一字段進行聚合查詢，咱們將該字段的取值記爲關鍵詞 「ALL」，則這條數據共對應2^3=8 種可能的聚合查詢方式。爲了模擬出8種不一樣的維度排列組合方式，咱們利用二進制排列組合的方式，讓每一個字段嚴格對應二進制數據中的一位：若是該位的取值爲0，則字段內容爲上報的原始值（即上表中的實際取值）；若該位的取值爲1，則對應字段的取值記爲關鍵詞「ALL」。此外，二進制數據中從右至左每一位與字段的對應關係爲：
第1位對應os_version
第2位對應manufacturer
第3位對應app_version
由此可得，任意字段聚合查詢的排列如何方式以下表所示：
這樣，咱們就經過二進制排列組合的方式，枚舉出全部可能的維度組合查詢方式。在實際的計算過程當中，能夠利用流式計算的FlatMap算子，按照上述的排列組合方式，將一條數據擴展爲多條數據，並進行分組聚合、計算分位數，將最終的計算結果存入Doris等存儲引擎中供用戶查詢。此時，計算結果中實際已經包含了全部可能的聚合查詢方式，業務方能夠按須要直接查詢到最終的分位數結果，而無需另外進行聚合計算操做，在有效提升查詢效率的同時保證了用戶體驗。
4、結語
以上內容是咱們從宏觀的角度，對實時分位數計算方法的核心技術、基礎架構和技術難點進行了簡要介紹。若有任何問題或建議，歡迎你們隨時溝通交流。
本期做者 | 子陽，負責百度性能平臺的實時數據開發工做，主要研究方向爲流式計算、智能預測等
招聘信息
百度APP技術平臺研發部負責百度APP和百家號技術平臺建設，也承載着PUSH、消息、互動、交易、日誌、性能、審覈、B端等一系列標杆中臺的建設，歡迎你們加盟，期待着你的到來！
不管你是後端，前端，仍是大數據，這裏有若干職位在等你，歡迎投遞簡歷，【聯繫方式同名公衆號百度Geek說，輸入內推便可】，百度APP技術平臺研發部期待你的加入！
閱讀原文
推薦閱讀
---------- END ----------
百度Geek說
百度官方技術公衆號上線啦！
技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘信息 · 內推信息 · 技術書籍 · 百度周邊
歡迎各位同窗關注