Apache Doris在京東搜尋實時OLAP中的應用實踐

1、前言

本文討論了京東搜尋在實時流量資料分析方面，利用Apache Flink和Apache Doris進行的探索和實踐。流式計算在近些年的熱度與日俱增，從Google Dataflow論文的發表，到Apache Flink計算引擎逐漸站到舞臺中央，再到Apache Druid等實時分析型資料庫的廣泛應用，流式計算引擎百花齊放。但不同的業務場景，面臨著不同的問題，沒有哪一種引擎是萬能的。我們希望京東搜尋業務在流計算的應用實踐，能夠給到大家一些啟發，也歡迎大家多多交流，給我們提出寶貴的建議。

2、搜尋業務形態

京東集團的新使命是“技術為本，致力於更高效和可持續的世界”。京東搜尋作為電商平臺的一個入口，為眾多商家與使用者提供連線的紐帶。京東搜尋發揮著導流的作用，給使用者提供表達需求的入口；為了正確理解使用者意圖，將使用者的需求進行高效的轉化，線上同時執行著多個AB實驗演算法，遍及POP形態與自營形態的多個商品，而這些商品所屬的品類、所在的組織架構以及品牌店鋪等屬性，都需要線上進行監控，以衡量轉化的效果和承接的能力。

3、實時技術的挑戰

目前搜尋上層應用業務對實時資料的需求，主要包含三部分內容：

1、 搜尋整體資料的實時分析。

2、 AB實驗效果的實時監控。

3、 熱搜詞的Top榜單以反映輿情的變化。

這三部分資料需求，都需要進行深度的下鑽，維度細化需要到SKU粒度。同時我們也承擔著搜尋實時資料平臺的建設任務，為下游使用者輸出不同層次的實時流資料。

我們的使用者包括搜尋的運營、產品、演算法以及採銷人員。雖然不同使用者關心的資料粒度不同、時間頻率不同、維度也不同，但是我們希望能夠建立統一的實時OLAP資料倉儲，並提供一套安全、可靠的、靈活的實時資料服務。

目前每日新增的曝光日誌達到幾億條記錄，而拆分到SKU粒度的日誌則要翻10倍，再細拆到AB實驗的SKU粒度時，資料量則多達上百億記錄，多維資料組合下的聚合查詢要求秒級響應時間，這樣的資料量也給團隊帶來了不小的挑戰。

 

4、實時技術架構演進

我們之前的方案是以Apache Storm引擎進行點對點的資料處理，這種方式在業務需求快速增長的階段，可以快速的滿足實時報表的需求。但是隨著業務的不斷髮展、資料量逐漸增加以及需求逐漸多樣化，弊端隨之產生。例如靈活性差、資料一致性無法滿足、開發效率較低、資源成本增加等。

為解決之前架構出現的問題，我們首先進行了架構升級，將storm引擎替換為Apache Flink，用以實現高吞吐、exactly once的處理語義。同時根據搜尋資料的特點，將實時資料進行分層處理，構建出PV流明細層、SKU流明細層和AB實驗流明細層，期望基於不同明細層的實時流，構建上層的實時OLAP層。

OLAP層的技術選型，需要滿足以下幾點：

1：資料延遲在分鐘級，查詢響應時間在秒級

2：標準SQL互動引擎，降低使用成本

3：支援join操作，方便維度增加屬性資訊

4：流量資料可以近似去重，但訂單行要精準去重

5：高吞吐，每分鐘資料量在千萬級記錄，每天數百億條新增記錄

6：前端業務較多，查詢併發度不能太低

通過對比目前業界廣泛使用的支援實時匯入的OLAP引擎，我們在druid、ES、clickhouse和doris之間做了橫向比較：

通過對比開源的幾款實時OLAP引擎，我們發現doris和clickhouse能夠滿足我們的需求，但是clickhouse的併發度太低是個潛在的風險，而且clickhouse的資料匯入沒有事務支援，無法實現exactly once語義，對標準sql的支援也是有限的。

最終，我們選定doris作為聚合層，用於實時OLAP分析。對於流量資料，使用聚合模型建表；對於訂單行，我們將聚合模型換成Uniq模型，保證同一個訂單最終只會儲存一條記錄，從而達到訂單行精準去重的目的。在flink處理時，我們也將之前的任務拆解，將反覆加工的邏輯封裝，每一次處理都生成新的topic流，明細層細分了不同粒度的實時流。新方案如下：

 

目前的技術架構中，flink的任務是非常輕的，state狀態非常小，並沒有使用KeyedState自定義狀態，而OperatorState中只包含kafka的offset資訊，這樣保證任務的執行開銷很小，穩定性大大提升。同時基於生產的資料明細層，我們直接使用了doris來充當聚合層的功能，將原本可以在flink中實現的視窗計算，下沉到doris中完成。利用doris的routine load消費實時資料，雖然資料在匯入前是明細粒度，但是基於聚合模型，匯入後自動進行非同步聚合。而聚合度的高低，完全根據維度的個數與維度的基數決定。通過在base表上建立rollup，在匯入時雙寫或多寫並進行預聚合操作，這有點類似於物化檢視的功能，可以將資料進行高度的彙總，以提升查詢效能。

在明細層採用kafka直接對接到doris，還有一個好處就是這種方式天然的支援資料回溯。資料回溯簡單說就是當遇到實時資料的亂序問題時，可以將“遲到”的資料進行重新計算，更新之前的結果。這是因為我們匯入的是明細資料，延遲的資料無論何時到達都可以被寫入到表中，而查詢介面只需要再次進行查詢即可獲得最新的計算結果。最終方案的資料流圖如下：

 

5、技術取捨

實時資料處理的技術實現，需要在低延遲、準確性和成本之間進行取捨。我們採用doris作為實時倉庫的聚合層，其實也是在多方面進行了取捨。例如：

1、routine load的匯入任務，為了達到更高的寫入吞吐量，我們將實時匯入任務的最大時間間隔設定了30s，即增加了匯入延遲，換來了更大的吞吐

2、為了降低開發成本，節省計算資源，我們通過建立rollup來支援快速的查詢需求，但是卻增加了儲存壓力以及寫入時的IO壓力

3、PV、UV等流量指標在聚合時採用的是HLL計算，降低了精度，換來了更短的查詢響應時間

以上幾點取捨，是結合業務場景與需求的要求而決定的，並非絕對的情況。所以，面對實時資料大規模、無界、亂序等特點，實時流計算的選型，最終考慮的就是如何取捨。

 

6、Doris在大促期間的優化

上文提到我們在doris中建立了不同粒度的聚合模型，包括PV粒度、SKU粒度以及AB實驗粒度。我們這裡以每日生產資料量最大的曝光AB實驗模型為例，闡述在doris中如何支援大促期間每日新增百億條記錄的查詢的。

AB實驗的效果監控，業務上需要10分鐘、30分鐘、60分鐘以及全天累計等四個時間段，同時需要根據渠道、平臺和一二三級品類等維度進行下鑽分析，觀測的指標則包含曝光PV、UV、曝光SKU件次、點選PV、點選UV等基礎指標，以及CTR等衍生指標。

在資料建模階段，我們將曝光實時資料建立聚合模型，其中K空間包含日期欄位、分鐘粒度的時間欄位、渠道、平臺、一二三級品類等，V空間則包含上述的指標列，其中UV和PV進行HLL近似計算，而SKU件次則採用SUM函式，每到來一條記錄則加1。由於AB實驗資料都是以AB實驗位作為過濾條件，因此將實驗位欄位設定為分桶欄位，查詢時能夠快速定位tablet分片。值得注意的是，HLL的近似度在目前PV和UV的基數下，實際情況誤差在0.8%左右，符合預期。

目前doris的叢集共30+臺BE，儲存採用的是支援NVMe協議的SSD硬碟。AB實驗曝光topic的分割槽數為40+，每日新增百億條資料。在資料匯入階段，我們主要針對匯入任務的三個引數進行優化：最大時間間隔、最大資料量以及最大記錄數。當這3個指標中任何一個達到設定的閾值時，任務都會觸發匯入操作。為了更好地瞭解任務每次觸發的條件，達到10分鐘消費6億條記錄的壓測目標，我們通過間隔取樣的方法，每隔3分鐘取樣一次任務的情況，獲取Statistic資訊中的receivedBytes、cimmittedTaskNum、loadedRows以及taskExecuteTimeMs數值。通過對上述數值在前後2個時間段的差值計算，確定每個任務觸發的條件，並調整引數，以在吞吐和延遲之間進行平衡，最終達到壓測的要求。

為了實現快速的多維資料查詢，基於base表建立了不同的rollup，同時每個rollup的欄位順序，也要遵循過濾的欄位儘可能放到前面的原則，充分利用字首索引的特性。這裡並不是rollup越多越好，因為每個rollup都會有相應的物理儲存，每增加一個rollup，在寫入時就會增加一份IO。最終我們在此表上建立了2個rollup，在要求的響應時間內儘可能多的滿足查詢需求。

7、總結與展望

京東搜尋是在今年5月份引入doris的，第一個應用的上線到現在已經執行半年時間。目前叢集版本是0.11.33，規模是30+臺BE，線上同時執行著10+個routine load任務，每日新增資料條數在200億+，已經成為京東體量最大的doris使用者。從結果看，用doris替換flink的視窗計算，既可以提高開發效率，適應維度的變化，同時也可以降低計算資源，用doris充當實時資料倉儲的聚合層，並提供統一的介面服務，保證了資料的一致性和安全性。

我們在使用中也遇到了查詢相關的、任務排程相關的bug，也在推動京東OLAP平臺升級到0.12版本。接下來待版本升級後，我們計劃使用bitmap功能來支援UV等指標的精準去重操作，並將推薦實時業務應用doris實現。除此之外，為了完善實時數倉的分層結構，為更多業務提供資料輸入，我們也計劃使用適當的flink視窗開發聚合層的實時流，增加資料的豐富度和完整度。

 

作者：李哲，京東搜推資料開發工程師，曾就職於美團點評，主要從事離線資料開發、流計算開發以及OLAP多維查詢引擎的應用開發。