1、前言

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

2、搜索業(yè)務形態(tài)

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

3、實時技術(shù)的挑戰(zhàn)

目前搜索上層應用業(yè)務對實時數(shù)據(jù)的需求，主要包含三部分內(nèi)容：

1、?搜索整體數(shù)據(jù)的實時分析。

2、 AB實驗效果的實時監(jiān)控。

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

這三部分數(shù)據(jù)需求，都需要進行深度的下鉆，維度細化需要到SKU粒度。同時我們也承擔著搜索實時數(shù)據(jù)平臺的建設任務，為下游用戶輸出不同層次的實時流數(shù)據(jù)。

我們的用戶包括搜索的運營、產(chǎn)品、算法以及采銷人員。雖然不同用戶關(guān)心的數(shù)據(jù)粒度不同、時間頻率不同、維度也不同，但是我們希望能夠建立統(tǒng)一的實時OLAP數(shù)據(jù)倉庫，并提供一套安全、可靠的、靈活的實時數(shù)據(jù)服務。

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

4、實時技術(shù)架構(gòu)演進

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

為解決之前架構(gòu)出現(xiàn)的問題，我們首先進行了架構(gòu)升級，將storm引擎替換為Apache Flink，用以實現(xiàn)高吞吐、exactly once的處理語義。同時根據(jù)搜索數(shù)據(jù)的特點，將實時數(shù)據(jù)進行分層處理，構(gòu)建出PV流明細層、SKU流明細層和AB實驗流明細層，期望基于不同明細層的實時流，構(gòu)建上層的實時OLAP層。

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

1：數(shù)據(jù)延遲在分鐘級，查詢響應時間在秒級

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

3：支持join操作，方便維度增加屬性信息

4：流量數(shù)據(jù)可以近似去重，但訂單行要精準去重

5：高吞吐，每分鐘數(shù)據(jù)量在千萬級記錄，每天數(shù)百億條新增記錄

6：前端業(yè)務較多，查詢并發(fā)度不能太低

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

通過對比開源的幾款實時OLAP引擎，我們發(fā)現(xiàn)doris和clickhouse能夠滿足我們的需求，但是clickhouse的并發(fā)度太低是個潛在的風險，而且clickhouse的數(shù)據(jù)導入沒有事務支持，無法實現(xiàn)exactly once語義，對標準sql的支持也是有限的。

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

目前的技術(shù)架構(gòu)中，flink的任務是非常輕的，state狀態(tài)非常小，并沒有使用KeyedState自定義狀態(tài)，而OperatorState中只包含kafka的offset信息，這樣保證任務的運行開銷很小，穩(wěn)定性大大提升。同時基于生產(chǎn)的數(shù)據(jù)明細層，我們直接使用了doris來充當聚合層的功能，將原本可以在flink中實現(xiàn)的窗口計算，下沉到doris中完成。利用doris的routine load消費實時數(shù)據(jù)，雖然數(shù)據(jù)在導入前是明細粒度，但是基于聚合模型，導入后自動進行異步聚合。而聚合度的高低，完全根據(jù)維度的個數(shù)與維度的基數(shù)決定。通過在base表上建立rollup，在導入時雙寫或多寫并進行預聚合操作，這有點類似于物化視圖的功能，可以將數(shù)據(jù)進行高度的匯總，以提升查詢性能。

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

5、技術(shù)取舍

實時數(shù)據(jù)處理的技術(shù)實現(xiàn)，需要在低延遲、準確性和成本之間進行取舍。我們采用doris作為實時倉庫的聚合層，其實也是在多方面進行了取舍。例如：

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

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

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

以上幾點取舍，是結(jié)合業(yè)務場景與需求的要求而決定的，并非絕對的情況。所以，面對實時數(shù)據(jù)大規(guī)模、無界、亂序等特點，實時流計算的選型，最終考慮的就是如何取舍。

6、Doris在大促期間的優(yōu)化

上文提到我們在doris中建立了不同粒度的聚合模型，包括PV粒度、SKU粒度以及AB實驗粒度。我們這里以每日生產(chǎn)數(shù)據(jù)量最大的曝光AB實驗模型為例，闡述在doris中如何支持大促期間每日新增百億條記錄的查詢的。

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

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

目前doris的集群共30+臺BE，存儲采用的是支持NVMe協(xié)議的SSD硬盤。AB實驗曝光topic的分區(qū)數(shù)為40+，每日新增百億條數(shù)據(jù)。在數(shù)據(jù)導入階段，我們主要針對導入任務的三個參數(shù)進行優(yōu)化：最大時間間隔、最大數(shù)據(jù)量以及最大記錄數(shù)。當這3個指標中任何一個達到設置的閾值時，任務都會觸發(fā)導入操作。為了更好的了解任務每次觸發(fā)的條件，達到10分鐘消費6億條記錄的壓測目標，我們通過間隔采樣的方法，每隔3分鐘采樣一次任務的情況，獲取Statistic信息中的receivedBytes、cimmittedTaskNum、loadedRows以及taskExecuteTimeMs數(shù)值。通過對上述數(shù)值在前后2個時間段的差值計算，確定每個任務觸發(fā)的條件，并調(diào)整參數(shù)，以在吞吐和延遲之間進行平衡，最終達到壓測的要求。

為了實現(xiàn)快速的多維數(shù)據(jù)查詢，基于base表建立了不同的rollup，同時每個rollup的字段順序，也要遵循過濾的字段盡可能放到前面的原則，充分利用前綴索引的特性。這里并不是rollup越多越好，因為每個rollup都會有相應的物理存儲，每增加一個rollup，在寫入時就會增加一份IO。最終我們在此表上建立了2個rollup，在要求的響應時間內(nèi)盡可能多的滿足查詢需求。

7、總結(jié)與展望

京東搜索是在今年5月份引入doris的，第一個應用的上線到現(xiàn)在已經(jīng)運行半年時間。目前集群版本是0.11.33，規(guī)模是30+臺BE，線上同時運行著10+個routine load任務，每日新增數(shù)據(jù)條數(shù)在200億+，已經(jīng)成為京東體量最大的doris用戶。從結(jié)果看，用doris替換flink的窗口計算，既可以提高開發(fā)效率，適應維度的變化，同時也可以降低計算資源，用doris充當實時數(shù)據(jù)倉庫的聚合層，并提供統(tǒng)一的接口服務，保證了數(shù)據(jù)的一致性和安全性。

我們在使用中也遇到了查詢相關(guān)的、任務調(diào)度相關(guān)的bug，也在推動京東OLAP平臺升級到0.12版本。接下來待版本升級后，我們計劃使用bitmap功能來支持UV等指標的精準去重操作，并將推薦實時業(yè)務應用doris實現(xiàn)。除此之外，為了完善實時數(shù)倉的分層結(jié)構(gòu)，為更多業(yè)務提供數(shù)據(jù)輸入，我們也計劃使用適當?shù)膄link窗口開發(fā)聚合層的實時流，增加數(shù)據(jù)的豐富度和完整度。

作者：李哲，京東搜推數(shù)據(jù)開發(fā)工程師，曾就職于美團點評，主要從事離線數(shù)據(jù)開發(fā)、流計算開發(fā)以及OLAP多維查詢引擎的應用開發(fā)。

-=END=-

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

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

【熱門文章】

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

2.?Apache Doris 在 WeLab實時大數(shù)據(jù)平臺的應用實踐

3.?作業(yè)幫基于Apache Doris的數(shù)倉實踐

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

5.?美團外賣實時數(shù)倉建設實踐

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。