1、業務場景

北京雲真信科技有限公司（簡稱“雲真信”）是國內領先的金融科技服務提供商。公司擁有強大的資料探勘與整合、提供優勢的泛金融領域整體化解決方案的能力；自設立以來，已與多家大型國有銀行、商業銀行以及大型持牌消金機構等建立了深度的合作關係，打造了客戶信賴的產品服務體系；同時擁有一支在資料科學、人工智慧、金融風控等領域具備豐富的理論和實踐經驗的核心管理團隊；近期，雲真信連續獲評國家高新技術企業、2020中國金融創新獎十佳智慧風控創新獎，標誌著權威認證機構對雲真信技術能力和創新能力的高度認可。

雲真信智慧決策分析平臺是解決大規模資料下進行多維度的快速分析決策系統，藉助Apache Doris底層技術能力，最終能夠實現秒級多維度的快速統計分析與高效建模。

2、技術選型

為了有效地支援智慧決策分析平臺的資料計算，我們對市面上流行的OLAP引擎進行了全面的調研。在目前開源的OLAP引擎中，根據處理型別分類，主要有三大類：MPP架構、搜尋引擎架構以及預處理架構這三種類型。針對這三大型別的主要產品，我們分析了其對於我們場景的適用情況。

相較於以上的產品，Apache Doris更加適合我們的場景，主要原因如下：

1. Doris支援的資料規模比較大，而且實現了MySQL協議，對標準SQL支援比較友好。

2. Doris架構比較簡潔，只有FE和BE兩個元件，不依賴任何外部的元件。不依賴Hadoop，卻可以通過HDFS匯入資料，還可以通過Spark、Kafka等方式匯入資料。

3. 在Join方面，支援Shuffle Join、Broadcast Join以及Colocation Join，特別是Colocation Join，非常適合我們。Doris 的Colocation Join功能，原理是將需要Join的表，根據Join時用到的key進行分桶，而且要保證分桶數一樣，副本數一樣，colocate_with屬性也要保持一致。在這樣的前提條件下，Doris就會將相同key資料排程到相同的節點，在兩表關聯時，只需拿本地的資料即可，沒有資料的網路傳輸開銷，能大大提升效能。

4. Doris還有一個有用的特性：Doris On ES。在我們的智慧決策分析平臺中有用到ES，而ES無法對多個index進行join查詢。Doris On ES的特性非常完美地解決了我們這樣的需求。Doris On ES的一個重要功能是支援過濾條件下推，將過濾條件下推到ES。這樣就只有滿足條件的資料才會被返回，能大大提升效能以及降低Doris和ES之間資料傳輸的效能消耗。在查詢時，Doris的BE節點會根據就近原則，優先請求本地部署的ES節點，通過HTTP Scroll方式流式地從ES中獲取資料。目前我們的ES叢集和Doris叢集就是混合部署在相同的伺服器上，使用Doris On ES這一特性很有優勢。

綜合我們自己的業務場景，以及目前市面上開源的OLAP引擎的現狀，我們最終選擇了Doris+ES解決方案來開發我們的智慧決策分析平臺。平臺整體採用hadoop 、Doris On ES的架構，充分發揮三款開源元件各自的功能優勢，最終實現秒級人群多維度組合分析。

各自功能介紹：

Hadoop：它是一個分散式系統基礎架構，適合大資料體量下的資料預處理，進行高吞吐的離線清洗、加工。在智慧決策分析平臺中它主要用於使用者特徵寬表的預處理，主要為使用者特徵，以及行轉列處理。最終在hadoop將資料按照ES以及Doris的資料組織結構進行加工處理。

Doris：它是一款開源的OLAP分析引擎，可以實現靈活的多維分析 、支援豐富的資料模型、基於主鍵的實時自動更新。且Doris 的優點是易運維，易擴充套件和高可用，無外部系統依賴，部署和配置都很簡單，可以一鍵加減節點，並自動均衡資料， Doris 的 FE 和 BE 都可以容忍少數節點掛掉。

而在智慧決策分析平臺中，Doirs主要實現秒級的大資料體量下的快速Join，以及多維度下的秒級聚合分析。另外它支援在Doris中建立ES的外部表，Doris On ES將Doris的分散式查詢規劃能力和ES(Elasticsearch)的全文檢索能力相結合，提供更完善的OLAP分析，實現ES中的多index分散式Join查詢，Doris和ES中的表聯合查詢，更復雜的全文檢索過濾。而Doris目前不支援表的二級索引，所以當我們想要實現多維度組合的的人群過濾，它並不能支援。

ES：ES是一個分散式、高擴充套件、高實時的搜尋與資料分析引擎。它能很方便的使大量資料具有搜尋、分析和探索的能力。充分利用Elasticsearch的水平伸縮性，ES在智慧決策分析平臺中主要實現千億級別資料量下對人群進行多維度的秒級過濾篩選。ES的弱項是不支援快速地對資料進行Join操作。

3、重點應用

1、Broadcast Join

我們經常會有根據一批樣本資料，進行多維度的關聯查詢，而樣本資料往往資料體量不大，而關聯的維度表卻非常龐大，在Doris裡面可以快速使用Broadcast Join進行秒級的關聯查詢。

2、Colocation Join

Broadcast Join解決的是小樣本資料（百萬內）與大資料體量也就是小表與大表之間的關聯查詢，而Colocation Join解決的就是大表與大表之間的秒級關聯，在我們的平臺中，分析建模人員經常需要對指定一批人群進行多維度的人群分析刻畫，而這一批人群往往資料體量很龐大，這就涉及到了大表與大表間的關聯查詢。兩者做關聯使用Shuffle Join肯定是不合適，而Broadcast Join在篩選出來的資料量大的話顯然也不合適，節點越多效能也會越差。Colocation Join提供的是本地行優化，來減少資料在節點之間的傳輸耗時，以此來加速查詢。所以目前我們該場景就是用Colocation Join來解決大表與大表間的秒級關聯。

3、Doris On ES

基於多維度人群篩選步驟，目前我們使用的是Doris On ES的解決方案。通過Doris，將條件下推到ES，篩選出我們想要的人群，拉到Doris之後再和畫像寬表做關聯得到畫像的統計資料。目前我們還有一個樣本提數的場景準備改造。以前該場景是基於SparkSQL的解決方案，每個任務的速度基本上是幾分鐘到二十多分鐘不等。由於是使用Spark，併發量上不去，繁忙的時候排隊現象比較嚴重。最近我們基於Doris On ES去測試相同的場景，提取一兩百萬的資料，都能在半分鐘之內得到結果，該業務場景目前正在開發改造當中。

4、遇到的問題

我們從今年的5月份開始調研和使用Doris，由於平臺開發時間比較緊，前期對Doris的調研和測試工作比較少，開發過程遇到了很多的問題，其中大部分是我們對Doris的配置不瞭解造成的。目前Doris發展很快，程式碼的迭代更新比較頻繁，但官方文件對各種配置的說明沒有跟上，這是我們認為Doris亟待改進的地方。

我們最開始使用的是apache的0.12.rc3版本，使用過程中遇到了一些bug，比如Doris On ES查詢時，多個條件組合在一起就會查詢失敗、ES多索引同別名查詢失敗、BE記憶體寫亂經常出現掛掉等。這些bug在我們的業務場景無法繞過的，所以我們在Doris開發者的建議下已經對Doris的版本升級過兩三次了。以下是一些比較常見的問題以及解決方法：

1、客戶端查詢經常碰到 failed to initialize storage reader. 這類錯誤提示不太明確，只能到BE的log裡面檢視，原因一般都是記憶體不足，加大exec_mem_limit即可解決該問題。

2、failed to send brpc batch, error=The server is overcrowded. 大查詢很容易會碰到這個異常，原因是BE之間shuffle大量的資料，最開始用的0.12.0-rc03版本BRPC socket_max_unwritten_bytes預設是64M，引數不可更改。之後增加了brpc_socket_max_unwritten_bytes引數，解決方法是升級版本，增大這個引數的值。

3、無法發揮機器多核平行計算的能力。原因一般有兩個，一是FE的並行引數預設是1，需要自行更改，二是表設計不合理導致資料只落到一個bucket裡面。

4、BE經常被系統幹掉。原因是BE預設使用80%的實體記憶體，而我們是BE和FE以及ES混合部署，BE無法用到80%的記憶體。在進行耗記憶體的join查詢時，BE經常因為佔用大量記憶體而被系統幹掉。這種情況基本上都是在測試環境機器配置比較低的時候遇到。解決辦法是降低BE使用的記憶體佔比以及FE的併發度。

5、不支援blob、text等文字型別，但是分析任務提交的引數有大量過濾標籤以及分析標籤等，想要將這些引數儲存，卻無法直接儲存到Doris的一個或者varchar型別的欄位裡。原因是Doris預設限制了每張表中每一行資料的大小是100k。解決辦法是修改max_layout_length_per_row引數來增大每一行的資料大小。

6、insert into/ stream load等可能會丟資料，原因是enable_insert_strict/strict_mode預設設定為false時，對於一些不符合表字段規範的資料會被過濾掉；設定為true的時候，只要遇到不符合規則的記錄就丟擲異常。

7、Document has not a scroll id field，ES多索引同別名異常或多條件組合查詢異常。兩種情況都是Doris On ES之前版本的一些bug，經過版本升級即可解決。

8、failed to send batch；intolerable failure in opening node channels ；Comparison method violates its general contract!，頻繁出現異常還經常會導致BE掛掉。經Doris開發者分析，原因是之前的版本存在BE寫記憶體錯誤的bug。後來我們升級到最新的版本，就沒有再遇到這個問題。

9、bitmap在某些情況下查詢會卡死，目前定位到原因是基數太大。一個bitmap超過了200M，rpc傳送包時被拒絕了。解決辦法是升級到最新版本，並修改引數brpc_max_body_size。

10、有時候元資料查詢太慢，慢的時候大概耗時10秒。該問題已反饋給Doris的開發者，目前還在優化的過程中。

4、總結和展望

由於Doris專案歷史比較長，一路走來，它的整體架構改動還是比較大的。在2018年貢獻給Apache之後，開源社群給Doris專案增加了很多功能，比如Colocation Join、Bitmap支援都是開源之後才有的。目前Doris專案還在快速發展，還在不斷地更新迭代，是一個處於高速發展期的開源產品，使用過程中難免會遇到一些問題。總體來說，Doris是一個優秀的產品。

在這裡要非常感謝鼎石科技團隊，特別是@趙純和@李超勇兩位大神熱情、給力、靠譜的技術支援，為我們使用Doris提供有力的保證。目前我們使用Doris的解決方案在一些新場景下還在持續優化，也希望社群能儘快解決和採納使用者提出的各類問題和建議，這樣就能給我們提供更多的優化方案，把Doris做得越來越好。

作者：羅義華，雲真信大資料工程師