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多維查詢引擎的應用開發。

-=END=-

北京鼎石縱橫科技有限公司，我們正在基于Apache Doris建設企業級新一代極速MPP數據庫。如果你對數據庫技術興趣濃厚，并且有勇氣和我們一起去打造一款世界級的混合云數據倉庫產品，請立即發簡歷給我們 hr@dorisdb.com。核心研發工程師，測試工程師，產品經理……我們都需要。

如果你對Doris數據庫感興趣，歡迎添加微信“DorisDB-1”咨詢以及進群和其他小伙伴交流。

【熱門文章】

1.?基于Apache Doris的小米增長分析平臺實踐

2.?Apache Doris 在 WeLab實時大數據平臺的應用實踐

3.?作業幫基于Apache Doris的數倉實踐

4.?Apache Doris在云真信智能決策分析平臺的應用實踐

5.?美團外賣實時數倉建設實踐

6.Apache Doris在京東廣告的應用實踐

公眾號回復：“資料全集”，海量PPT等你來拿。

總結

以上是生活随笔為你收集整理的Apache Doris在京东搜索实时OLAP中的应用实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。