**導讀：** MOKA 主要有兩大業務線 MOKA 招聘（智慧化招聘管理系統）和 MOKA People（智慧化人力資源管理系統），MOKA BI 透過全方位資料統計和可靈活配置的實時報表，賦能於智慧化招聘管理系統和人力資源管理系統。為了提供更完備的資料支援，助力企業提升招聘競爭力，MOKA 引入效能強悍的 [Apache Doris](https://github.com/apache/doris) 對早期架構進行升級轉型，成就了 Moka BI 強大的效能與優秀的使用者體驗。

作者**｜**Moka 資料架構師 張寶銘

# 業務需求

MOKA 主要有兩大業務線 MOKA 招聘（智慧化招聘管理系統）和 MOKA People（智慧化人力資源管理系統）。

-   MOKA 招聘系統覆蓋社招、校招、內推、獵頭管理等場景，讓 HR 獲得更高效的招聘體驗，更便捷的協作體驗，讓管理者獲得招聘資料洞見，讓招聘降本增效的同時，樹立企業在候選人心目中的專業形象。
-   MOKA People 覆蓋企業所需要的組織人事、假期考勤、薪酬、績效、審批等高頻業務場景，打通從招聘到人力資源管理的全流程，為 HR 工作提效賦能。透過多維度資料洞見，助力管理者高效科學決策。全生態對接，更加註重全員體驗，是一款工作體驗更愉悅的人力資源管理系統。

而 MOKA BI 透過全方位資料統計和可靈活配置的實時報表，賦能於智慧化招聘管理系統和人力資源管理系統。透過 PC 端和移動端的多樣化報表展示，為企業改善招聘業務提供資料支援，全面提升招聘競爭力，從而助力科學決策。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ca6bfd5e11ea4e9a92d6012601ee549c~tplv-k3u1fbpfcp-zoom-1.image)

# MOKA BI 早期架構

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a9785a9867a3432786ffe0a866c940e7~tplv-k3u1fbpfcp-zoom-1.image)

Moka BI 數倉早期架構是類 Lambda 架構，實時處理和離線處理並存。

-   實時部分資料主要來源為結構化的資料，Canal 採集 MySQL 或 DBLE（基於 MySQL 的分散式中介軟體）的 Binlog 輸出至 Kafka 中；未建模的資料按照公司分庫，儲存在業務 DBLE 中，透過 Flink 進行實時建模，將計算後的資料實時寫入業務 DBLE 庫，透過 DBLE 提供報表查詢能力，支援資料大屏和實時報表統計。
-   離線部分涵蓋了實時部分資料，其結構化資料來源於 DBLE 的 Binlog，明細資料在 Hbase 中實時更新，並對映成 Hive 表，非結構化資料透過 ETL 流程，儲存至 Hive 中，透過 Spark 進行進行離線部分建模計算，離線數倉 ADS 層資料輸出至 MySQL 和 Redis 支援離線報表統計，明細資料又為指標預測和搜尋等外部應用提供資料支援。

## **現狀與問題**

在早期數倉架構中，為了實現實時建模以及實時報表查詢功能，就必須要求底層資料庫能夠承載業務資料的頻繁插入、更新及刪除操作，並要求支援標準 SQL，因此當時我們選擇 DBLE 作為資料儲存、建模、查詢的底層庫。早期 Moka BI 灰度期使用者較少，業務資料量以及報表的使用量都比較低，DBLE 尚能滿足業務需求，但隨著 Moka BI 逐漸面向所有使用者開放，DBLE 逐漸無法適應 BI 報表的查詢分析效能要求，同時實時與離線架構分離、儲存成本高且資料不易維護，亟需進行升級轉型。

# 技術選型

為匹配業務飛速增長的要求、滿足更復雜的查詢需求，我們決定引入一款效能突出的 OLAP 引擎對 Moka BI 進行升級改造。同時出於多樣化分析場景的考慮，我們希望其能夠支撐更廣泛的應用場景。調研的主要方向包括 報表的實時查詢能力、資料的更新能力、標準的查詢 SQL 以及資料庫的可維護性、擴充套件性、穩定性等。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7690c66e83594d178ba224b924d1cddf~tplv-k3u1fbpfcp-zoom-1.image)

確定調研方向後，我們首先對 Greenplum 展開了調研，其特點主要是資料載入和批次 DML 處理快，但受限於主從雙層架構設計、存在效能瓶頸，且併發能力很有限、效能隨著併發量增加而快速下降，同時其使用的是 PG 語法、不支援 MySQL 語法，在進行引擎切換時成本較高，因此在基本功能調研結束後便不再考慮使用。

隨後我們對 ClickHouse 進行了調研，ClickHouse 在單表查詢場景下效能表現非常優異的，但是在多表 Join 場景中效能表現不盡如人意，另外 ClickHouse 缺少資料實時更新和刪除的能力，僅適用於批次刪除或修改資料，同時 ClickHouse 對 SQL 的支援也比較有限，使用起來需要一定的學習成本。

緊接著我們對近幾年勢如破竹的 Apache Doris 進行了調研，在調研中發現，Doris 支援實時匯入，同時也支援資料的實時更新與刪除，可以實現 Exactly-Once 語義；其次，在實時查詢方面，Doris 可以實現秒級查詢，且在多表 Join 能力的支援上更加強勁；除此之外，Doris 簡單易用，部署只需兩個程式，不依賴其他系統，相容 MySQL 協議，並且使用標準 SQL ，可快速上手，部署及學習成本投入均比較低。

## **Benchmark**

在初步調研的基礎之上，我們進一步將 Apache Doris 、Clickhouse 與當下使用的 DBLE 在查詢效能上進行了多輪測試對比，查詢耗時如下：

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f3c3bf23f8874ae4af1a9fea364bc06a~tplv-k3u1fbpfcp-zoom-1.image)

-   **多表 Join**：隨著 SQL Join 數量的增多，Doris 和 ClickHouse 效能表現差距越來越大，Doris 的查詢延遲相對比較穩定，最長耗時僅為 3.2s；而 ClickHouse 的查詢延遲呈現指數增長，最長耗時甚至達到 17.8s，二者效能最高相差 5 倍，DBLE 的查詢效能則遠不如這兩款產品。
-   **慢查詢：** 線上上慢查詢 SQL 的對比測試中，Doris 的效能同樣非常穩定，不同的 SQL 查詢基本都能在 1s 內返回查詢結果，ClickHouse 與之對比查詢延遲波動較大、效能表現很不穩定，二者相同 SQL 效能差距最大超過 10 餘倍。

**透過以上調研對比，可以看出 Apache Doris 不管是在基本功能上、還是查詢效能上表現都更勝一籌，因此我們將目標鎖定了 Doris，並決定儘快引入 Apache Doris 作為 Moka** **BI** **新一代** **數倉** **架構的查詢引擎。**

# 新版架構

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/20a0be39810942a78bb1d66018744c84~tplv-k3u1fbpfcp-zoom-1.image)

在引入 Doris 之後，Moka BI 數倉架構的主要變化是將 OLAP 和 OLTP 進行分離，即使用 DBLE 支援資料的實時建模，資料來源於 Moka 系統的業務資料，包含了結構化和半結構化的資料，透過 Flink 讀取 DBLE Binlog，完成資料去重、合併後寫入 Kafka，Doris 透過 Routine Load 讀取 Kafka 完成資料寫入，此時 DBLE 僅作為資料建模合成使用，由 Doris 提供報表查詢能力。

基於 Doris 列儲存、高併發、高效能等特性，Moka BI 報表採用自助方式構建完成，支撐客戶根據需求靈活配置行、列、篩選的場景。與傳統報表按需求定製開發方式對比，這種自助式報表構建非常靈活，平臺開發與需求開發完全獨立，需求完成速度得到極大的提升。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5de38af04e544c0ca59e43dfe9c7f015~tplv-k3u1fbpfcp-zoom-1.image)

資料匯入方面，資料透過 Routine Load 定期批次匯入到 Doris 資料倉儲中，保證了資料的準實時同步。透過對系統資料收集與建模，及時向客戶提供最新的業務資料，以幫助客戶快速瞭解招聘情況，並做出有效的調整。

資料更新方面，Doris 在大資料量（單表幾十億）的場景下，表現出了突出的資料更新和刪除能力，Moka BI 讀取的是業務庫的 Binlog 資料，其中有大量的更新以及刪除操作，Doris 可以透過 Routine Load 的 Delete 配置實現實時刪除，根據 Key 實現冪等性寫入，配合 Flink 可以做到真正的 Exactly-Once。在架構中增加了 Routine Load 後，數倉可以實現 1 分鐘級別的準實時 **，** 同時結合 Routine load + Kafka 可以實現流量的削峰，保證叢集穩定，並且可以透過重置 Kafka 偏移量來實現間資料重寫，透過 Kafka 實現多點消費等。

資料查詢方面，充分利用 Doris 的多表 Join 能力，使得系統能夠實現實時查詢。我們將不同的資料表按照關聯欄位進行連線，形成一個完整的資料集，基於資料集可進行各種資料分析和視覺化操作，同時可高效應對任意條件組合的查詢場景以及需要靈活定製需求的查詢分析場景，**在某些報表中，需要 Join 的表可能達到幾十張，Doris 強大的 Join 效能，使 Moka** **BI** **的報表查詢可以達到秒級響應。**

運維管理方面，Doris 部署運維簡單方便，不依賴第三方元件，無損彈性擴縮容，自動資料均衡，叢集高可用。Doris 叢集僅有 FE 和 BE 兩個元件，不依賴 Zookeeper 等元件即可實現高可用，部署、運維方便，相比傳統的 Hadoop 元件，非常友好，支援彈性擴容，只需簡單配置即可實現無損擴容，並且可以自動負載資料到擴容的節點，大大降低了我們引入新技術棧的難度和運維壓力。

# 調優實踐

新架構實際的落地使用中，我們總結了一些調優的經驗，在此分享給大家。

在 Moka BI 報表查詢許可權場景中，同樣配置的報表，**有許可權認證**時查詢速度比**沒有許可權認證**時慢 30% 左右，甚至出現查詢超時，而**超管許可權**查詢時則正常，這一現象在資料量較大的客戶報表中尤為明顯。

人力資源管理業務的資料許可權有著極為嚴格和精細的管控需求，除了 SaaS 業務自身對於不同租戶間的資料隔離要求外，還需要針對業務人員的身份角色、管理部門範疇以及被管理人員的資訊敏感程度對可見資料的範圍進行進一步細分，因此在 Moka BI 許可權功能模組的設計之時就考慮並實現了極為靈活的自定義配置化方案。例如 HRBP 與 PayRoll、HRIS 等角色的可見欄位不同、不同職級或部門但角色一致使用者的可見資料區間不同，同時針對部分敏感的人員資訊還需要做資料過濾，或者出於管理授權的需求臨時開通某一許可權，甚至以上許可權要求還會進行多重的交叉組合，以保證每一使用者可檢視的資料、報表、資訊均被限制在許可權範圍以內。

因此當使用者需要對資料包表進行查詢時，會先在 Moka BI 的許可權管理模組進行多重驗證，驗證資訊會透過`  in  `的方式拼接在查詢 SQL 中並傳遞給 OLAP 系統。隨著客戶業務體量的增大，對於許可權管控的要求越精細、最終所產生的 SQL 就越複雜，部分業務規模比較大的客戶報表會出現上千甚至更多的許可權限制，因此造成 OLAP 系統的 id 過濾時間變長，導致報表查詢延遲增加，給大客戶造成了體驗不佳。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3c1e3f9eb7674afab066f166a4142ce0~tplv-k3u1fbpfcp-zoom-1.image)

**解決方案：**

為適配該業務場景，我們透過檢視官方的文件發現 Doris Bloom Filter 索引的特性可以很好的解決該問題

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/550798e56e704e3e9dd927e0f9847e44~tplv-k3u1fbpfcp-zoom-1.image)

Doris BloomFilter 索引使用場景：

-   BloomFilter 適用於非字首過濾。
-   查詢會根據該列高頻過濾，而且查詢條件大多是`  in  `和`  =  `過濾。
-   不同於 Bitmap，BloomFilter 適用於高基數列，比如 UserID。因為如果建立在低基數的列上，比如 “性別” 列，則每個 Block 幾乎都會包含所有取值，導致 BloomFilter 索引失去意義。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0568e0172e3f46ea9c251cade3093063~tplv-k3u1fbpfcp-zoom-1.image)

經過驗證，可以透過上方對比報表看到，**將相關 ID 欄位增加 BloomFilter 索引後** **，許可權驗證場景查詢速度提升約 30% ，有許可權驗證的報表超時的問題也得到了改善。**

# 收益與總結

**目前 Moka** **BI** **Doris 有兩個叢集，** **共 40 臺伺服器，** **數倉** **共維護了 400 多張表** **，其中 50 多張表資料量超過 1 億，總資料量為 T** **B** **級別。**

引入 Apache Doris 改造了新的資料倉儲之後，滿足了日益增長的分析需求以及對資料實時性的要求，總體收益包含以下幾點：

1.  **高效能資料查詢：** Doris 基於列儲存技術，能夠快速處理大量的資料，並支援高併發的線上查詢，解決了關係型資料庫無法支援的複雜查詢問題，複雜 SQL 查詢的速度上升了一個資料量級。
1.  **資料倉儲** **的可擴充套件性：** Doris 採用分散式叢集架構，可以透過增加節點來線性提升儲存和查詢瓶頸，打破了關係型資料庫資料單點限制問題，查詢效能得以顯著提升。
1.  **更廣泛的應用：** 基於 Doris 構建了統一的資料查詢平臺，應用不再侷限於報表服務，對於離線的查詢也有很好的支撐，可以說 Doris 的引入是構建數倉一體化的前奏。
1.  **實現自助式分析：** 基於 Doris 強大的查詢能力，我們引入了全新的報表構建方式，透過使用者自助構建報表方式，能夠快速滿足使用者的各種靈活需求。

在使用 Doris 的兩年多時間裡，Moka BI 與 Apache Doris 共同成長、共同進步，可以說 Doris 成就了 Moka BI 強大的效能與優秀的使用者體驗；也正是 Moka BI 特殊的使用場景，也豐富了 Doris 的最佳化方向，我們提的很多 Issue 與建議，經過版本更新迭代後使其更具競爭力。在未來的時間裡，Moka BI 也會緊跟社群腳步，不斷最佳化、回饋社群，希望 [Apache Doris](https://github.com/apache/doris) 和 [SelectDB](https://cn.selectdb.com/) 發展越來越好、越來越強大。

查詢提速 20 倍，Apache Doris 在 Moka BI SaaS 服務場景下的應用實踐

相關文章