Apache Doris 在同程數科數倉建設中的實踐

導讀：隨著大資料的進一步發展，實時分析資料庫的發展也越來越繁榮。Apache Doris 作為一個高效能、簡單易用、支援實時的 MPP 架構分析資料庫也被越來越多的公司使用。今天會和大家分享一下 Apache Doris 在同程數科數倉建設中的實踐。

今天的介紹會圍繞下面四點展開：

• 業務場景

• 架構演變

• 收益現狀

• 未來展望

分享嘉賓｜王星 同程數科 大資料高階工程師

編輯整理｜劉步龍

出品社群｜DataFun

---

01

業務場景

首先分享一下我們的業務場景。

1. 企業介紹

同程數科是屬於同程集團旗下的一個旅遊產業金融服務平臺。前身為同程金服，成立於 2015 年 11 月。願景是“以數字科技引領旅遊產業”，希望以科技的力量來賦能旅遊產業。業務包含四大主要板塊，產業金融服務、消費金融服務、金融科技和數字科技。現在累計服務使用者超過千萬，涵蓋了 76 座城市。

2. 業務需求

針對以上業務，我們基於 Doris 實現的需求主要包括四大類：

• 看板類：業務實時駕駛艙；T+1 業務看板
• 預警類：實時業務流程預警（比如：風控熔斷、資金異常、流量監控）
• 分析類：資料查詢分析；臨時取數；實時使用者標籤查詢
• 財務類：財務清算對賬；支付對賬

02

架構演變

1. 架構演變——架構 1.0

在 1.0 架構中我們引用了 StreamSets、Kudu、Impala 等技術。實時數倉鏈路是，先透過 SteamSets 採集資料庫的 binlog，實時寫入 Kudu，再透過 Impala 等工具查詢和使用。實時計算部分是，將埋點資料傳送到 kafka，之後透過 Flink 做實時計算，最終結果資料一部分落入分析庫，一部分落入 Hive 中，用於數倉中使用。

隨著業務的發展，1.0 架構的弊端也逐漸顯現出來了。

架構 1.0 的優點為：

• 使用 CDH 構建，在現有 CDH 叢集下，能夠快速相互整合並投入使用
• 實時採集能夠視覺化配置式開發

架構 1.0 的不足為：

• 引入元件過多，（元件、作業）維護複雜，問題排查困難，資料修復困難
• 資料開發鏈路過長，對數倉人員技術要求高，開發效率低
• 聚合查詢能力不足，大表 join 效率不高
• 離線與實時叢集未做分離，導致資源相互競爭
• 有預警能力，但是作業自動恢復能力不足

2. 架構演變——架構 2.0

在架構 2.0 的選型中，我們引入了 Doris，對實時數倉進行了改造。首先透過 Canal去採集業務庫資料，這也是一個 CDC 的能力。將採集的資料放入 kafka，之後使用Doris Routine Load 進行資料載入。之前實時計算流程沒有太大的改變，唯一變化的地方就是 Doris 對 Hive 資料的接入比較友好，透過 Broker Load，可以很方便的將離線叢集資料直接接入到 Doris 中。

之所以選擇 Doris 主要是基於以下幾個原因：

• 豐富的資料接入能力（支援眾多資料來源）
• 採用 MySQL 協議通訊
• Doris SQL 基本覆蓋 MySQL 語法
• 支援MPP平行計算能力
• 官方文件健全，上手較快

3. 架構 2.0——Doris 部署架構

上圖是 Doris 的部署架構，架構特點如下：

• Doris 的部署不依賴於現有大資料的元件，可獨立部署。
• 整體分兩層：FE（前端節點）、BE（後端節點）。FE主要負責接收請求和返回請求，對後設資料和叢集的管理，以及查詢計劃的生成；BE 主要負責資料節點的管理，和對執行計劃的執行。
• Doris 整體運維簡便，高可用，可擴充套件性強。

我們曾經歷了一次機房遷移，我們採用的是滾動式遷移，12 臺 Doris 機器，在 3天內完成了全部遷移工作。遷移過程中，時間主要用在了對機器下架、搬移和上架動作上。遷移 Doris 時，用到的指令主要是對 FE 節點縮容與擴容，以及 BE 節點的縮容與擴容。對於 BE 節點，建議不要使用 DROPP 強制縮容，因為資料無法恢復，而是儘量使用 DECOMMISSION（解除）的方式，遷移資料後縮容。

4. Doris 實時系統架構

上圖是我們基於 Doris 的實時數倉架構。首先是資料來源來自於我們各個業務線，資料採集主要透過 Canal 和 API 介面，Canal 採集使用的是 Canal-Admin 維護。然後將採集到的資料傳送到 kafka 訊息佇列，再透過 Routine Load 接入 Doris 叢集。

在 Doris 數倉部分，主要分為三層：DWD 明細層，DWS 彙總層和 ADS 應用層。DWD 層用的是unique模型，DWS 和 ADS 層用的是 aggregate 模型。

資料最終應用在實時看板、挖掘分析、資料服務等。

5. Doris 新數倉特點

資料匯入方式簡便，針對不同場景資料採用方式如下：

• routine load：業務資料（寫入kafka）實時接入 Doris
• broker load：離線資料定時或手工匯入 Doris（包含：基礎維度表、歷史資料等）
• insert into：定時作業，從 DWD 層處理出 DWS 層，之後處理出 ADS 層
• 良好的資料模型，使開發效率更高
• unique 模型：業務資料接入 Doris 時使用，防止重複採集
• aggregate 模型：從 DWD 層到 DWS 或 ADS 層使用，幫我們減少了很大一部分 SQL 程式碼量
• 使用門檻低，查詢效率高
• 基於 MySQL 協議，標準的 SQL 查詢語法，查詢分析無壓力
• 使用物化檢視達到預計算效果，如果查詢命中，將快速響應
• 部署架構簡便，運維維護成本低
• 針對 FE、BE、BROKER 角色，配置監控，異常重啟

6. 如何更友好地使用 Doris

對於一個新元件大家可能會更關心以下幾點：

• 快速開發：如何能夠簡單快速的將資料匯入 Doris，並快速實現 ETL 開發
• 排程管理：如何管理上線的任務，保證任務排程的穩定，以及排程恢復能力
• 資料查詢：生產與辦公網路隔離，如何讓大家安全便捷的查詢分析
• 叢集管理：如何感知節點異常，並且能夠重試自動恢復
• 整體宗旨：高效率、高質量、高穩定。

7. 資料平臺——Doris 開發

（1）Doris 資料開發：快速構建程式碼，實現 routine load、broker load 任務開發

對於資料接入這一塊，我們做了一些半自動化的工作，透過選擇資料來源和表生成一些routine load 指令碼，相當於也是一些快速生成元件。然後只要對 kafka 的 topic 進行修改指定，就可以快速形成一個 routine load 任務。broker load 任務也是類似的動作，我們選擇數倉的源和表，就可以透過後設資料快速生成 broker load 指令碼。

（2）routine load、broker load、常規任務提交或測試

當任務生成之後， 就是如何提交和管理。routine load 是一個常駐程式，我們進行一次提交就可以了，提交後會變成 running 的狀態。如果有異常會在頁面顯示和告警出來。

（3）Doris 排程與監控

這個圖是我們提交作業之後進行作業的監控和管理。監控會對任務定時掃描，如果出現問題會有提醒，同時會嘗試將任務重新拉起。

（4）自研查詢頁面和 Doris Help 整合

由於我們生產和辦公網段是隔離的，所以查詢只能透過 web 的形式。為了解決查詢問題，我們在平臺裡面開發了一些查詢頁面，可以將 DB 下面所有的表給列出來。上圖中右半部分是查詢編輯的頁面，下面是查詢展示結果。同時我們也整合了 Doris Help 的功能，透過關鍵字，就可以查詢到 Doris 內部整合的幫助和示例。

（5）節點監控

上圖是叢集監控，當出現異常時，會自動提醒並嘗試拉起節點。

03

收益現狀

透過升級架構，使得成本大大的降低，效益增長也十分明顯。新架構帶來的效益如下：

• 資料接入：新架構資料接入程式碼可快速構建，3-5 分鐘完成一個接入。老架構手工部分比較多。接入一張表需要 20-30 分鐘。
• 資料開發：Doris 自帶 unique、aggregate 模型，能夠加速 ETL 開發過程。老架構資料 ETL 過程沒有底層資料模型支撐，很多處理邏輯需要自行開發。 
• 資料查詢：基於 Doris 新架構帶有物化檢視或 Rollup 物化索引提升查詢效率。同時大表 join 時 Doris 內部提供很多最佳化機制。
• 資料包表：基於 Doris 的查詢展示，報表相應速度基本在秒級或毫秒級響應。
• 環境維護：沒有 Hadoop 數倉環境複雜，整個平臺鏈路方案清晰。同時 Doris 叢集的運維成本遠低於 Hadoop 叢集運維（遷移一次就懂了）。

04

未來展望

對與新架構的提升，我們有如下願景：

• 嘗試引入 Doris Manager 對叢集進行維護和管理
• 實現基於 Flink CDC 方式的資料接入。這是我們 3.0 架構規劃（進行中）
• 對現有 Doris 叢集進行升級，使用新特性，更快速響應需求
• 針對“指標管理體系”、“資料質量監控體系”進行強化建設