作者 | 杭州度言軟體大資料團隊

杭州度言軟體有限公司（度言軟體）成立於2014年，是信貸不良資產處置技術服務供應商，以“智慧科技賦能不良資產處置，推動貸後行業合規高效發展”為使命，運用雲通訊、大資料、人工智慧等智慧科技為信貸不良資產處置業務賦能，提供貸後管理通訊能力支撐，實現了催收作業的智慧化管理，客戶群體為銀行、消費金融公司、AMC 等金融機構和為這些機構提供人力資源外包服務的相關公司，目前已擁有 2000 多家企業客戶。

度言軟體以圍繞信貸不良資產案件高效流轉管理為目的核心，從機構管理、團隊管理、坐席管理、外呼作業、調解法訴等環節入手，幫助客戶構建數智化的業務管理體系，以數字化系統提升管理效能、以智慧化工具賦能處置作業，打通金融機構、外包服務公司、司法系統等多方的業務系統，並按照監管要求**對外呼行為、錄音檔案、溝通記錄等案件相關資料進行記錄、彙集、稽核、統計和分析，具有海量賬號同時登陸、資料請求高併發、多來源資料彙總接入的特點要求。**

# 業務需求

2021 年之前，度言軟體旗下產品的資料需求主要由傳統資料庫 MySQL，MongoDB，ElasticSearch 為主的技術架構來實現，近兩年隨著業務不斷髮展帶而來資料量的高速增長，傳統的數倉技術架構已初顯瓶頸，難以滿足客戶日益豐富多樣化的資料及分析需求。為了給客戶提供更優質的服務體驗，度言軟體亟需對現有的技術架構做出最佳化和重構。

# 早期架構及痛點

## 數倉架構 1.0 版本

初創期間，由於公司業務量相對較少，主要還是以 OLTP 業務和少量的業務報表服務為主，並且對於資料分析方面的需求也很少，僅透過傳統的資料庫基本就能滿足早期的業務資料需求。**數倉** **架構 1.0 如下圖所示：**

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

## 數倉架構 2.0 版本

隨著公司業務的不斷擴充套件，資料體量也出現極速增長的態勢，業務側對於資料分析方面的需求也逐漸多了起來，為此我們成立了專門的大資料團隊，為搭建新的數倉及業務資料分析需求進行服務。**如下圖所示為數倉架構 2.0** ：

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

數倉架構 2.0 版本是基於 MaxCompute + Hologres/MySQL 來搭建的。資料來源主要有 MySQL 和 MongoDB 的業務資料以及埋點日誌資料；資料首先採集到資料匯流排 DataHub 中，後經過 DataHub 直接匯入到 MaxCompute，MaxCompute 作為一個離線數倉，我們將其進行了傳統的數倉分層；資料的加工處理和分析計算主要在離線數倉中進行，並將計算好的結果匯出到 MySQL中，來對接 QuickBI 展示報表。此外，我們還嘗試了將 Hologres 用作實時數倉，作為 MongoDB 的替換方案，用於業務上的查詢系統。

## 早期架構存在的問題：

1.  **響應速度較慢**。MySQL 對於大表的聚合計算並不友好，響應速度較慢。產品側要求資料查詢響應時間在 5 秒以內，雖然我們也基於 MySQL 進行了許多最佳化，但最佳化效果十分有限，仍無法達到 5s 的響應要求；我們甚至嘗試了直接用 MaxCompute 對接 QuickBI，希望基於 MaxCompute 的查詢加速和 QuickBI 的快取來幫助我們解決問題，然而結果並不理想。
1.  **維繫維度表成本高、難度大。** 離線數倉在資料同步的時效性上並不佔優勢(每 5 分鐘進行一次批次同步)，因此不太適合資料頻繁更新和刪除的場景，同時也給維度表的維護帶來了額外的工作量。在資料更新和刪除場景中，我們需要定期透過過濾和去重來保持資料的一致性，而事實上，大多時候需要報表資料實時關聯維度表，這讓我們直接放棄了在離線數倉中維繫維度表的方案。
1.  **不支援高併發點查詢場景。** 原實時數倉雖然可以滿足我們對資料分析的部分效能要求，但其對高併發的點查場景並不太友好，不管是採用列式儲存還是行級儲存建表，最佳化之後的響應時長在 500 毫秒左右，綜合來看價效比不算太高。

# 解決思路

為了解決上述問題，我們希望理想數倉能具有如下特性：

1.  實現一站式實時數倉，能同時滿足多種不同業務資料需求，大大簡化大資料架構體系；
1.  可同時支援 OLAP，Ad-hoc 和高 QPS 點查場景；
1.  資料接入友好，寫入即可見，對資料增刪改和聚合等都有較好的支援；
1.  架構簡單，運維部署和維護簡單，有較好的監控體系。

# 技術選型

在 2022 年 3 月份，我們對市場上主流的的幾款即席查詢資料庫進行了調研，調研中我們發現每個產品只能滿足某 1 個或幾個特定的使用場景，沒有一個產品可以完全滿足所有的選型要求，而同時採用多個產品，將大大增加開發運維成本，同時也會使架構變得更加龐大複雜，這並不符合我們對理想數倉的要求。

正在這時，我們從開源社群、技術媒體等渠道瞭解到了[ Apache Doris](https://github.com/apache/doris) ，經初步調研，我們發現 Doris 基本可以滿足我們對理想數倉的所有要求。接著我們對 Doris 展開了深入調研，並使我們最終決定使用 Doris：Doris 架構非常簡單，只有 FE 和 BE 兩類程式，這兩類程式都可以進行橫向擴充套件，單叢集可以支援到數百臺機器、數十 PB 的儲存容量，並且這兩類程式透過一致性協議來保證服務的高可用和資料的高可靠。這種高度整合的架構設計極大的降低了分散式系統的運維成本，同時也不需要依賴於 Hadoop，避免了我們需要投入成本來額外部署 Hadoop 叢集。

# 基於 Doris 的新數倉架構設計

最初使用 Doris 的初衷是替換部分 MySQL 資料量較大的報表，基於 MySQL 的查詢約需要幾十秒的響應時間，在替換為 Doris 後，查詢效能有了顯著提升，幾秒內即可返回結果，最長的 SQL 執行時間大概在 8 秒左右，速度相較於之前提升了8 倍。Doris 的初步應用就給了我們一個意外的驚喜，因此我們決定使用 Doris 完全替換掉早期數倉中的 MySQL，在這使用過程中，我們又發現 Doris 遠比我們想象的要強大，目前已將客戶報表及公司內部運營決策資料全部遷移至 Apache Doris，並計劃用 Apache Doris 來替換 MongoDB 和 ElasticSearch，用於業務上高 QPS 的點查場景。**以下是基於 Doris 的新數倉架構設計及使用情況：**

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

## **資料建模：**

我們在業務上使用最多的是 Unique 模型和 Aggregate 模型，這兩種模型基本能夠滿足業務需求。

-   Unique 模型主要用於維度表和業務表(原始表)的接入，確保資料匯入過程中的一致性。
-   Aggregate主要用於報表資料的匯入，Aggregate 分為 Key (維度列) 和 Value（指標列），Value 列支援四種聚合方式：`sum` ,`replace`,`max`,`min`。當前主要以`replace` 聚合方式為主，方便統計資料重複匯入和修正結果，後續也會嘗試更多的方式來充分發揮 Doris 的效能。

### **資料接入：**

1.  使用 Flink-Doris-Connector 進行實時匯入：主要用於業務資料的匯入，基於MySQL 的 Binlog 日誌寫入到 Kafka 後，透過 Flink 解析加工後準實時寫入 Doris。
1.  使用 DataX 進行離線匯入：主要用於對接離線數倉已計算後的報表資料。

### **資料開發：**

目前 Doris 主要以提供終端查詢為主，複雜的 SQL 開發任務執行比較少，為儘可能減少 Doris 在資料加工方面的資源消耗，當前僅有報表叢集在凌晨執行少量的 SQL 任務，主要以 Doris SQL 透過 insert into 的方式來匯入。

### **資料管理：**

Doris 支援將當前資料以檔案的形式透過 Broker 備份到遠端儲存系統中，後可以透過恢復命令從遠端儲存系統中將資料恢復到任意 Doris 叢集。透過該功能，Doris 可支援定期對資料進行快照備份，也可以透過該功能在不同叢集間進行資料遷移。我們也會定期將叢集資料備份到阿里雲 OSS 上，作為備用資料恢復方案。另外，在這期間我們對 Doris 叢集進行了一次拆分，將報表叢集和業務上的高併發查詢叢集分開，採用了 Doris 的資料備份和遷移功能。

### **監控和報警：**

我們使用官網推薦的 Prometheus 和 Grafana 進行監控項的採集和展示，Doris 本身提供了豐富的監控指標和標準監控模版，可以非常便捷地對 Doris 叢集使用情況進行監控和報警。

另外，為了進一步對慢 SQL 進行最佳化，我們還部署了審計日誌外掛，對於特定使用者和特定的慢 SQL 進行最佳化和資源限制。如下是我們日常使用中的一些指標：

**慢 SQL 查詢：**

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

對於一些長文字 SQL，無法完全展示，可以進一步檢視`fe.audit.log`。

**主要查詢統計指標：**

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

# 最佳化實踐：

## 提高併發

我們考慮在資源給定的情況下，如何最大程度地提高併發。剛開始引入 Doris 叢集的時候，我們嘗試對複雜 SQL 進行壓測（SQL 層面最佳化已完成），但始終無法達到預期的壓測效果。後來我們嘗試**調低** `parallel_fragment_exec_instance_num` **的值**，順利完成了壓測目標。

> **需要說明的是：**
>
> ` parallel_fragment_exec_instance_num  `指的是 Scan Node 在每個 BE 節點上執行例項的個數，相當於在整個查詢計劃執行過程中的併發度，調高該引數可以提升查詢效率，但同時也會增加更多機器資源的消耗。因此在資源有限且查詢耗時滿足業務需求的情況下，透過調低引數來節省單個 SQL 的資源消耗，有助於提高並發表現。另外，我們透過 Doris 社群瞭解到，在即將釋出的新版本中將實現引數自動設定，無需進行手動調整。

如下圖，我們可以看到，在引數設定為 16 的時候，異常率高達 82.84%，並且期間還出現了 BE 當機重啟，將引數調低至 8 後，異常率也同步降低到了 27.66%。最後我們將引數設定為最小值 1 後，異常率為 0，查詢響應也能達到預期目標。

說明：測試環境已重新取數，配置較低，資料僅用來說明 `parallel_fragment_exec_instance_num` 變動所帶來的效果。

當引數調整為 1：`parallel_fragment_exec_instance_num = 1`

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

當引數調整為 8：`parallel_fragment_exec_instance_num = 8`

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

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

當引數調整為 16：`parallel_fragment_exec_instance_num = 16`

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

## BE 記憶體問題

最初我們使用的是 Doris 0.15 的版本。由於剛開始處於測試階段，Doris 叢集配置比較低或引數配置的不合理，當某些 SQL 掃描資料量較大時，就可能因為記憶體問題導致 BE 當機。

在向社群諮詢後，瞭解到 Supervisor 是用 Python 開發的一套通用的程式管理程式，能將一個普通的命令列程式變為後臺 Daemon，並監控程式狀態，異常退出時能自動重啟，因此我們參照官網給出的例子直接用 Supervisor 對 Doris 的 FE 和 BE 程式進行管理。

但是在執行了一段時間後，新的問題又出現了(已升級到 1.1.0 版本)。Doris 的 BE 節點記憶體一直在緩慢上升狀態，並且達到了設定的最大記憶體引數 80% 後仍在繼續上漲。後經分析發現 BE 存在記憶體洩漏問題，因此設定的引數並未生效。為此，我們將 Supervisor 切換為 Systemd 來守護 FE、BE 程式，限制整個節點的記憶體使用上限。不過在 Doris 1.1.3 推出之後，此問題已得到徹底的修復。

## 資源佔用

在遷移完新叢集后，我們發現透過 Flink-Doris-Connector 資料匯入佔用非常高的叢集資源，雖然設定了按批次寫入(每 3s 寫入一次 )，以限制資料的匯入頻率，但叢集資源的佔用仍未得到較大改善。因此我們在叢集資源和資料實時可見性方面做了權衡，介於我們對資料實時性的要求相對不是太高，所以我們將每 3s 寫入一次改為每 10s 或 20s 寫入一次，調整寫入時間後，叢集的 CPU 資源佔用下降明顯，得到改善。

# 應用現狀

目前度言軟體有 2 個 Doris 叢集，1 個叢集用作線上業務的查詢系統，主要是應對高 QPS 的點查場景，我們將原先基於業務庫 MySQL 和 MongoDB 的查詢遷移至 Doris，一方面減少了業務庫的讀寫壓力，同時也提高了使用者查詢服務的使用體驗。在 Doris 中，最複雜的查詢在 1 秒以內即可響應，響應速度提升了十幾倍；另外 1 個叢集主要用作即席查詢(AD-Hoc Query)和報表分析，具體包括公司內部使用的所有報表和一些臨時查詢、客戶報表、資料實時大屏。

總而言之，使用 Doris 替換了部分業務使用場景後，使用者在產品上的使用體驗有了進一步得到提升，頁面開啟更加流暢，原本因為查詢慢而不能實現的功能，當前已經實現並上線使用。同時在資源成本上也減輕了 MySQL 和 MongoDB 資料庫的壓力，不需要頻繁進行升配和磁碟升級。

# 總結規劃

## 效果總結

1.  Doris 完美覆蓋了原本需要多個技術棧才能實現的業務場景，極大地簡化了大資料的架構體系。
1.  Doris 對 Join 支援較好，因此我們選擇了將維度表放到 Doris 中進行維護，相較於之前在離線數倉中進行維護，明顯地提高了開發的效率，並降低了資料出錯的可能性，滿足了業務上對維度表近實時更新的需求。
1.  Doris 支援 MySQL 協議和標準 SQL，開發人員學習成本低，上手簡單，可以快速將原先的業務遷移至 Doris 上來。
1.  Doris 社群活躍，版本迭代速度快。在遇到任何問題時，都可以向社群求助，[SelectDB](https://cn.selectdb.com/) 為 Apache Doris 組建了一支全職專業的技術支援入隊，24H 內即可得到社群的響應回覆。

## 未來規劃

到目前為止，基於 Doris 的實時數倉搭建已基本完成，但我們對 Doris 的進一步嘗試才剛剛開始，比如 BE 的多磁碟部署，物化檢視的使用，Doris-On-ES，Doris 多租戶和資源劃分等。

**此外，我們也希望 Doris 未來能對以下功能進行進一步最佳化：**

1.  Flink-Doris-Connector 能支援單 Sink 同時寫入多張表，不需要再透過分流後多個 Sink 寫入。
1.  物化檢視能夠支援多表 Join，不再侷限於單表。
1.  進一步最佳化資料的底層 Compaction，在保證資料可見性的同時能夠儘可能降低資源消耗。
1.  Doris-Manager 提供對慢 SQL 的最佳化建議以及表資訊收集，對於不合理的建表進行一定的提示。

從 3 月份使用 Doris 以來，我們一直都和 Doris 社群保持著密切的聯絡，後續我們也將繼續圍繞 Doris 作為實時數倉應用到更多的業務使用場景中，對於使用中遇到的問題和最佳化的方案，我們也會持續和社群保持熱切聯絡，為社群進步貢獻我們的一份力量。

複雜查詢響應速度提升10+倍，度言軟體基於 Apache Doris 實時數倉建設實踐

相關文章