Doris 在京東客服 OLAP 中的應用實踐

前言

Doris 是一款開源的 MPP 分析型數據庫產品，不僅能夠在亞秒級響應時間即可獲得查詢結果，有效的支持實時數據分析，而且支持 10PB 以上的超大的數據集。相較於其他業界比較火的 OLAP 數據庫系統，Doris 的分佈式架構非常簡潔，支持彈性伸縮，易於運維，節省大量人力和時間成本。目前國內社區火熱，也有美團、小米等大廠在使用。

引言

本文主要討論京東客服在人工諮詢、客戶事件單、售後服務單等專題的實時大屏，在實時和離線數據多維分析方面，如何利用 Doris 進行業務探索與實踐。近些年來，隨着數據量爆炸式的增長，以及海量數據聯機分析需求的出現，MySQL、Oracle 等傳統的關係型數據庫在大數據量下遇到瓶頸，而 Hive、Kylin 等數據庫缺乏時效性。於是 Doris、Apache Druid、ClickHouse 等實時分析型數據庫開始出現，不僅可以應對海量數據的秒級查詢，更滿足實時、準實時的分析需求。離線、實時計算引擎百花齊放。但是針對不同的場景，面臨不同的問題，沒有哪一種引擎是萬能的。我們希望通過本文，對京東客服業務在離線與實時分析的應用與實踐，能夠給到大家一些啓發，也希望大家多多交流，給我們提出寶貴的建議。

京東客服業務形態

京東客服作爲集團服務的入口，爲用戶和商家提供了高效、可靠的保障。京東客服肩負着及時解決用戶問題的重任，給用戶提供詳細易懂的說明與解釋；爲更好的瞭解用戶的反饋以及產品的狀況，需要實時的監控諮詢量、接起率、投訴量等一系列指標，通過環比和同比，及時發現存在的問題，以更好的適應用戶的購物方式，提高服務質量與效率，進而提高京東品牌的影響力。

Easy OLAP 設計

0****1

EasyOLAP Doris 數據導入鏈路

EasyOLAP Doris 數據源主要是實時 KAFKA 和離線 HDFS 文件。實時數據的導入依賴於 Routine Load 的方式；離線數據主要使用 Broker Load 和 Stream Load 的方式導入。

EasyOLAP Doris 數據導入鏈路

0****2

EasyOLAP Doris 全鏈路監控

目前 EasyOLAP Doris 項目的監控，使用的是 Prometheus+Grafana 框架。其中 node_exporter 負責採集機器層面的指標，Doris 也會自動以 Prometheus 格式吐出 FE、BE 的服務層面的指標。另外，部署了 OLAP Exporter 服務用於採集 Routine Load 相關的指標，旨在第一時間發現實時數據流導入的情況，確保實時數據的時效性。

EasyOLAP Doris 監控鏈路

EasyOLAP Doris 監控面板展示

0****3

EasyOLAP Doris 主備雙流設計

EasyOLAP Doris 爲了保障 0 級業務在大促期間服務的穩定性，採取了主備集羣雙寫的方式。當其中一個集羣出現抖動或者數據存在延遲的情況，用戶可以自主地快速切換到另一個集羣，儘可能的減少集羣抖動給業務帶來的影響。 

Easy OLAP Doris 主備雙流設計

0****4

EasyOLAP Doris 動態分區管理

京東 OLAP 團隊分析需求之後，對 Doris 做了一定的定製化開發，其中就涉及到動態分區管理功能。儘管社區版本已經擁有動態分區的功能，但是該功能無法保留指定時間的分區。針對京東集團的特點，我們對指定時間的歷史數據進行了留存，比如 618 和 11.11 期間的數據，不會因爲動態分區而被刪除。

動態分區管理功能能夠控制集羣中存儲的數據量，而且方便了業務方的使用，無需手動或使用額外代碼來管理分區信息。

Doris 緩存機制

01

需求場景

致力於不斷提升用戶體驗，京東客服的數據分析追求極致的時效性。離線數據分析場景是寫少讀多，數據寫入一次，多次頻繁讀取；實時數據分析場景，一部分數據是不更新的歷史分區，一部分數據是處於更新的分區。在大部分的分析應用中，存在下述幾種場景：

  1. 高併發場景：Doris 較好的支持高併發，但是過高的 QPS 會引起集羣抖動，且單個節點無法承載太高的 QPS；

  2. 複雜查詢：京東客服實時運營平臺監控根據業務場景需展示多維複雜指標，豐富指標展示對應多種不同的查詢，且數據源來自於多張表，雖然單個查詢的響應時間在毫秒級別，但是整體的響應時間可能會到秒級別；

  3. 重複查詢：如果沒有防重刷機制，由於延遲或手誤，重複刷新頁面會導致提交大量重複的查詢；

針對上述場景，在應用層有解決方案——將查詢結果放入到 Redis 中，緩存會週期性的刷新或者由用戶手動刷新，但是也會存在一些問題：

  1. 數據不一致：無法立即對數據的更新作出響應，用戶接收到的結果可能是舊數據；

  2. 命中率低：如果數據實時性強，緩存頻繁失效，則緩存的命中率低且系統的負載無法得緩解；

  3. 額外成本：引入外部組件，增加系統複雜度，增加額外成本。

02

緩存機制簡介

在 EasyOLAP Doris 中，一共有三種不同類型 Cache。根據適用場景的不同，分別爲 Result Cache、Sql Cache 和 Partition Cache。三種緩存都可以通過 MySql 客戶端指令控制開關。

這三種緩存機制是可以共存的，即可以同時開啓。查詢時，查詢分析器首先會判斷是否開啓了 Result Cache，在 Result Cache 開啓的情況下先從 Result Cache 中查找該查詢是否存在緩存，如果存在緩存，直接取緩存的值返回給客戶端；如果緩存失效或者不存在，則直接進行查詢並將結果寫入到緩存。緩存放在各個 FE 節點的內存中，以便快速讀取。

Sql Cache 按照 SQL 的簽名、查詢的表的分區的 ID 和分區最新版本號來存儲和獲取緩存。這三者一起作爲緩存的條件，其中一者發生變化，如 SQL 語句變化、數據更新之後分區版本號變化，都會無法命中緩存。在多表 Join 的情況下，其中一張表的分區更新，也會導致無法命中緩存。Sql Cache 更適合 T+1 更新的場景。

Partition Cache 是更細粒度的緩存機制。Partition Cache 主要是將一個查詢根據分區並行拆分，拆分爲只讀分區和可更新分區，只讀分區緩存，更新分區不緩存，相應的結果集也會生成 n 個，然後再將各個拆分後的子查詢的結果合併。因此，如果查詢 N 天的數據，數據更新最近的 D 天，每天只是日期範圍不一樣但相似的查詢，就可以利用 Partition Cache，只需要查詢 D 個分區即可，其他部分都來自緩存，可以有效降低集羣負載，縮短查詢響應時間。

一個查詢進入到 Doris，系統先會處理查詢語句，並將該查詢語句作爲 Key，在執行查詢語句之前，查詢分析器能夠自動選擇最適合的緩存機制，以確保在最優的情況下，利用緩存機制來縮短查詢相應時間。然後檢查 Cache 中是否存在該查詢結果，如果存在就獲取緩存中的數據返回給客戶端；如果沒有緩存，則正常查詢，並將該查詢結果以 Value 的形式和該查詢語句 Key 存儲到緩存中。Result Cache 可以在高併發場景下發揮其作用，也可以保護集羣資源不受重複的大查詢的侵佔。Sql Cache 更加適合 T+1 的場景，在分區更新不頻繁以及 Sql 語句重複的情況下，效果很好。Partition Cache 是粒度最小的緩存。在查詢語句查詢一個時間段的數據時，查詢語句會被拆分成多個子查詢。在數據只寫一個分區或者部分分區的情況下，能夠縮短查詢時間，節省集羣資源。

爲了更好的觀察緩存的效果，相關指標已經加入到 Doris 的服務指標中，通過 Prometheus 和 Grafana 監控系統獲取直觀的監控數據。指標有不同種類的 cache 的命中數量、不同種類的 cache 命中率、cache 的內存大小等指標。

03

緩存機制效果

京東客服 Doris 主集羣，11.11 期間，在沒有開啓緩存時，部分業務就導致 CPU 的使用率達到 100%；在開啓 Result Cache 的情況下，CPU 使用率在 30%-40% 之間。緩存機制確保業務在高併發場景下，能夠快速的得到查詢結果，並很好的保護了集羣資源。

Doris 在 2020 年 11.11 大促期間的優化

01

導入任務優化

實時數據的導入一直是一個挑戰。其中，保證數據實時性和導入穩定性是最重要的。爲了能夠更加直觀的觀察實時數據導入的情況，京東 OLAP 團隊自主開發了 OLAP Exporter，用於採集實時數據導入相關的指標，如導入速度、導入積壓和暫停的任務等。通過導入速度和導入積壓，可以判斷一個實時導入任務的狀態，如發現任務有積壓的趨勢，可以使用自主開發的採樣工具，對實時任務進行採樣分析。實時任務主要有三個閾值來控制任務的提交，分別是每批次最大處理時間間隔、每批次最大處理條數和每批次最大處理數據量，一個任務只要達到其中一個閾值，該任務就會被提交。通過增加日誌，發現 FE 中的任務隊列比較繁忙，所以，參數的調整主要都是將每批次最大處理條數和每批次最大處理數據量調大，然後根據業務的需求，調整每批次最大處理時間間隔，以保證數據的延遲在每批次最大處理時間間隔的兩倍之內。通過採樣工具，分析任務，不僅保證了數據的實時性，也保證了導入的穩定性。另外，我們也設置了告警，可以及時發現實時導入任務的積壓以及導入任務的暫停等異常情況。

02

監控指標優化

監控指標主要分爲兩個部分，一個是機器層面指標部分，一個是業務層面指標部分。在整個監控面板裏，詳細的指標帶來了全面的數據的同時，也增加了獲取重要指標的難度。所以，爲了更好的觀察所有集羣的重要指標，單獨設立一個板塊——11.11 重要指標彙總板塊。板塊中有 BE CPU 使用率、實時任務消費積壓行數、TP99、QPS 等指標。指標數量不多，但是可以觀測到所有集羣的情況，這樣可以免去在監控中頻繁切換的麻煩。

03

周邊工具支持

除了上述說到的採樣工具和 OLAP Exporter，京東 OLAP 團隊還開發了一系列的 Doris 維護工具。

  1. 導入採樣工具：導入採樣工具不僅可以採集實時導入的數據，而且還支持調整實時導入任務的參數，或者在實時導入任務暫停狀態下，生成創建語句（包括最新的位點等信息）用於任務的遷移等操作。

  2. 大查詢工具：大查詢不僅會造成集羣 BE CPU 使用率的抖動，還會導致其他查詢響應時間變長。在有大查詢工具之前，發現集羣 CPU 出現抖動，需要去檢查所有 FE 上的審計日誌，然後再做統計，不僅浪費時間，而且不夠直觀。大查詢工具就是爲了解決上述的問題。當監控側發現集羣有抖動，就可以使用大查詢工具，輸入集羣名和時間點，就可以得到該時間點下，不同業務的查詢總數，時間超過 5 秒、10 秒、20 秒的查詢個數，掃描量巨大的查詢個數等，方便我們從不同的維度分析大查詢。大查詢的詳細情況也將被保存在中間文件中，可以直接獲取不同業務的大查詢。整個過程只需要幾十秒到一分鐘就可以定位到正在發生的大查詢並獲取相應的查詢語句，大大節約了時間和運維成本。

  3. 降級與恢復工具：爲了確保 11.11 大促期間，0 級業務的穩定性，在集羣壓力超過安全位的時候，需要對其他非 0 級業務做降級處理，待度過高峯期後，再一鍵恢復到降級前的設置。降級主要是降低業務的最大連接數、暫停非 0 級的實時導入任務等。這大大增加了操作的便捷性，提高了效率。

  4. 集羣巡檢工具：在 11.11 期間，集羣的健康巡檢是極其重要的。常規巡檢包括雙流業務的主備集羣一致性檢查，爲了確保業務在一個集羣出現問題的時候可以快速切換到另一個集羣，就需要保證兩個集羣上的庫表一致、數據量差異不大等；檢查庫表的副本數是否爲 3 且檢查集羣是否存在不健康的 tablet；檢查機器磁盤使用率、內存等機器層面的指標等。

總結與展望

京東客服是在 2020 年年初開始引入 Doris 的，目前擁有一個獨立集羣，一個共享集羣，是京東 OLAP 的資深用戶。

在業務使用中也遇到了例如任務調度相關的、導入任務配置相關的和查詢相關等問題，這也在推動京東 OLAP 團隊更深入的瞭解 Doris。我們計劃推廣使用物化視圖來進一步提升查詢的效率；使用 bitmap 來支持 UV 等指標的精確去重操作；使用審計日誌，更方便的統計大查詢、慢查詢；解決實時導入任務的調度問題，使導入任務更加高效穩定。除此之外，我們也計劃優化建表、創建優質 rollup 或物化視圖以提升應用的流暢性，加速更多業務向 OLAP 平臺靠攏，以提升應用的影響力。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XzYPxQ32Mo6Qoy_CxWx4hg

猜你喜歡