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

導讀： 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 端和移動端的多樣化報表展示，為企業改善招聘業務提供資料支援，全面提升招聘競争力，進而助力科學決策。

MOKA BI 早期架構

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 以及資料庫的可維護性、擴充性、穩定性等。

确定調研方向後，我們首先對 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 在查詢性能上進行了多輪測試對比，查詢耗時如下：

• 多表 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 新一代 數倉 架構的查詢引擎。

新版架構

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

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

資料導入方面，資料通過 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 過濾時間變長，導緻報表查詢延遲增加，給大客戶造成了體驗不佳。

解決方案：

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

Doris BloomFilter 索引使用場景：

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

經過驗證，可以通過上方對比報表看到，将相關 ID 字段增加 BloomFilter 索引後 ，權限驗證場景查詢速度提升約 30% ，有權限驗證的報表逾時的問題也得到了改善。

收益與總結

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

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

1. 高性能資料查詢： Doris 基于列存儲技術，能夠快速處理大量的資料，并支援高并發的線上查詢，解決了關系型資料庫無法支援的複雜查詢問題，複雜 SQL 查詢的速度上升了一個資料量級。
2. 資料倉庫 的可擴充性： Doris 采用分布式叢集架構，可以通過增加節點來線性提升存儲和查詢瓶頸，打破了關系型資料庫資料單點限制問題，查詢性能得以顯著提升。
3. 更廣泛的應用： 基于 Doris 建構了統一的資料查詢平台，應用不再局限于報表服務，對于離線的查詢也有很好的支撐，可以說 Doris 的引入是建構數倉一體化的前奏。
4. 實作自助式分析： 基于 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/） 發展越來越好、越來越強大。