作者 | 付帥
策劃 | 凌敏
業務背景
橙聯股份是一家服務全球跨境電商的科技公司，致力於透過市場分析、系統研發及資源整合，為客戶提供物流、金融、大資料等多方面的服務產品，為全球跨境電商提供高品質、全方位的服務解決方案。
隨著公司業務的發展和資料的不斷增長，早期基於 MySQL 的傳統數倉架構已經無法應對公司資料的快速增長。業務的需求和運營的決策對於資料時效性的要求越來越高，對數倉準實時能力的需求越發強烈。
為了適應快速的增長需求，橙聯於 2022 年正式引入 Apache Doris，以 Apache Doris 為核心構建了新的數倉架構，構建過程中對服務穩定性、查詢穩定性、資料同步等多方面進行了最佳化，同時建立了以 Apache Doris 為核心的資料中臺，在這一過程中積累了諸多使用及最佳化經驗，在此分享給大家。
數倉架構演進
早期數倉架構
公司在成⽴初期業務量不⼤，資料團隊規模⽐較⼩，對資料的需求僅侷限於少量 T + 1 定製化報表需求。因此，早期數倉架構十分簡單，如下圖所示，直接使用 MySQL 構建數倉集市層，使用數倉集市層的資料進行報表開發，基於商業化的報表平臺向需求方提供 T + 1 的資料報表服務。
存在的問題
隨著公司業務規模擴大、資料量激增以及對資料時效性要求不斷提高，使⽤ MySQL 進⾏資料分析越來越不能滿⾜業務⽅的要求。
沒有對數倉進⾏分層劃域，煙囪式的開發模式資料復⽤性很差，開發成本⾼，業務⽅提出的需求不能快速得到響應。對資料的質量和元資料的管理缺乏管控。
新數倉架構
為了解決舊架構日益凸顯的問題，適應快速增長的資料和業務需求，今年正式引入 Apache Doris 構建新的數倉架構。
選擇 Apache Doris 的原因：
易⽤性 - 在當前應用場景下，引入新技術，將面臨大量報表遷移問題，因此必須要考慮的產品易用性問題，而 Apache Doris 在學習成本、報表遷移成本、服務運維成本上有著非常優秀的表現，具體包括：
採用MySQL 協議和語法，⽀持標準 SQL，可以透過各類客戶端⼯具來訪問 Doris，能夠與 BI ⼯具⽆縫對接。
支援多表 Join，針對不同場景的 Join 提供了多種最佳化⽅案。
生態擴充套件完善，離線資料的⾼效批次導⼊、流式資料的低延遲實時導⼊都有很好的⽀持。
相較於業界其他熱⻔ OLAP 資料庫，Doris 的分散式架構⾮常簡潔，只有 FE、BE 兩個程序，運⾏不依賴任何第三⽅系統。
支援彈性伸縮，對於部署、運維⾮常友好。
效能 - 當前報表存在大量降耦聚合操作，對多表關聯的查詢效能和實時查詢的時效性有著十分高的要求，而 Apache Doris 基於 MPP 架構實現，並自帶了⾼效的列式儲存引擎，可以支援：
資料的預聚合以及預聚合結果的自動更新。
資料的實時更新。
高併發查詢。
基於以上的原因，最終選擇了以 Apache Doris 為核心構建新的數倉。
架構介紹
Apache Doris 的數倉架構十分簡潔，不依賴 Hadoop 生態元件，構建及運維成本較低。
如以上架構圖所示，我們的資料來源共有 4 種，業務資料 MySQL、檔案系統 CSV、埋點資料和第三方系統 API；針對不同的需求，使用了不同的資料匯入方式，檔案資料匯入使用 Doris Stream Load，離線資料使用 DataX doriswriter 進行資料初始化，實時增量資料使用 Flink CDC + Flink Doris Connector 的方式進行資料同步；資料儲存和計算層使用了 Doris ，在分層設計上採用 ODS（Operation Data Store 資料準備區，也稱為貼源層）、 明細層 DWD、中間層 DWM、服務層 DWS、應用層 ADS 的分層思想，ODS 之後的分層資料透過 DolphinScheduler 排程 Doris SQL 進行增量和全量的資料更新。最終上層資料應用使用自研的一站式資料服務平臺，可以和 Apache Doris 無縫對接，提供自助報表、自助取數、資料大屏、使用者行為分析的資料應用服務。
基於 Apache Doris 的數倉架構方案可同時支援離線和準實時應用場景，準實時的 Apache Doris 數倉可以覆蓋 80% 以上的業務場景。這套架構大大降低了研發成本，提高了開發效率。
當然在架構構建過程中也遇到一些問題和挑戰，我們針對問題進行了相應的最佳化。
Apache Doris 構建數倉最佳化方案
在數倉的使用過程中，主要遇到三方面問題。首先是服務穩定性問題，其次是查詢速度逐漸變慢的問題，最後是 Doris 資料同步和 Doris SQL 排程問題。具體體現在以下：
服務穩定性
最佳化前
在 Apache Doris 使用初期，FE 和 BE 的部署方式如下：
FE 負責元資料的管理、使用者請求接入、查詢的解析規劃，資源佔用較低，因此將 FE 和其他大資料元件混合部署 FE*3。
BE 負責資料儲存、計算、查詢計劃的執行，資源佔用較大，因此 BE 進行獨立部署且分配了較多的資源 BE（16C 128G 4T*
1
）*
7。
基於以上方式部署，使用初期執行的穩定性還不錯。然而在使用了一段時間之後，這種部署方式暴露的問題就越來越明顯。
存在的問題
首先，FE 混合部署存在資源競爭。其他元件與 FE 服務競爭資源，導致 FE 資源不足，服務執行穩定性不好。具體問題表現在：每當機器資源使用率打滿，就會導致 FE 節點無法連線，長時間獲取不到心跳而被 FE 叢集判定為離線。
其次，BE 單磁碟存在 Compaction 效率低的問題。初期，我們在部署 BE 時，每個節點只分配了 1 塊 4T 的磁碟，雖然磁碟的空間並不小，但是磁碟的數量比較少，Compaction 執行緒數只有 2，Compaction 效率很低，這是導致 BE Compaction Score 不健康的原因之⼀。
Compaction 配置引數
compaction_task_num_per_disk 每個磁碟上的任務數，預設為 2
max_compaction_threads Compaction 執行緒的總數，預設為 10
total_permits_for_compaction_score Compaction 任務配額，預設 10000
Compaction 工作機制：Apache Doris 的資料寫⼊模型使⽤了與 LSM-Tree 類似的資料結構。資料以追加（Append）的⽅式寫⼊磁碟，在讀邏輯中，需要透過 Merge-on-Read 合併處理寫入的資料。Merge-on-Read 會影響讀取的效率，為了降低資料讀取時需要合併的資料量，使⽤ LSM-Tree 的系統會引⼊後臺資料合併邏輯，以⼀定策略定期的對資料進⾏合併。
最佳化後
為了解決以上的問題，對部署方式進行了最佳化以提升服務的穩定性：
FE 進行獨⽴部署，避免了 FE 混合部署資源競爭問題
BE 進行磁碟拆分，多磁碟部署，從原來一塊 4T 磁碟變更為 5 塊 1T 磁碟，使 BE Compaction 執行緒數提升 5 倍，Compaction 效率、磁碟 I/O 頻寬也得到了提升
增加客戶端連線代理層 ProxySQL，對 FE 連線進⾏負載均衡，解決 FE 連線單點問題
增加 Supervisor 對 FE、BE 服務程序狀態監控，FE、BE 程序意外宕機可以快速恢復
經過以上對部署的最佳化，Apache Doris 服務的穩定性有了很大的提升，基本可以滿足目前對穩定性的需求。
查詢穩定性
初期剛部署時，無論進行資料匯入還是資料查詢，執行起來都比較順暢。但隨著承載的表和資料匯入作業數量不斷增多，查詢穩定性問題逐漸暴露出來。
最佳化前
存在的問題
隨著使用時間和資料量的增加，叢集開始頻繁出現不可用的問題，主要體現在以下幾個方面：
DDL 操作很難執行，查詢速度變得比較緩慢
FE 服務頻繁出現 OOM 宕機，有時候甚至出現無法連線的情況
下圖是生產環境某張表的體積的大小和 Tablet 數量的情況。這張表的體積只有 275M，但是 Tablet 的數量卻達到了 7410，這非常不合理。進一步排查確認整個叢集 Tablet 數量非常龐大，叢集只有 5T 的資料量，然而 Tablet 數量達到 150 萬。
最初我們對 Apache Doris 表資料量大小、分割槽粒度、Bucket 數量、Tablet 數量的關係及 Tablet 數量對叢集的影響沒有清晰的概念。開發人員在 Apache Doris 使用中更多的是追求查詢速度，將大部分的動態分割槽表的分割槽粒度設定的比較小，分割槽 Bucket 數量設定卻比較大。
經過與 Apache Doris 社群小夥伴的溝通交流，瞭解到 Tablet 數量過大可能會導致元資料管理和運維壓力增大，出現查詢速度緩慢、FE 不穩定的問題。
最佳化方案
首先明確 Tablet 數量的計算方式，Tablet 數量 = 分割槽數量*
Bucket 數量*
副本數。結合當前實際使用情況，確認可以在分割槽粒度和 Bucket 數量上進⾏最佳化。我們將分割槽的粒度從按天、按周分割槽更改為按月分割槽，Bucket 數量按照資料體積大小進行合理的配置。如下圖所示，是建議資料體積大小對應的 Bucket 數量設定。
本次的最佳化目標是將 Tablet 數量從 150 萬降低到 15 萬，同時我們也對未來的增長速度進行了規劃，在三副本情況下，期望 Tablet 數量增長速度是 30000/TB。
最佳化後
實際上，在僅對 ODS 表進⾏了分割槽粒度和 Bucket 數量調整後，叢集 Tablet 數量從 150 萬下降到了 50 萬，效果顯著。
最佳化前的 FE
下圖是 FE JVM Heap Stat 的監控情況，每當 FE 執行 Checkpoint 時，元資料就會在記憶體中複製一份。體現在 FE JVM Heap Stat 上就是形成一個個的波峰。最佳化之前 FE 對記憶體佔用幾乎持續在 90% 以上，而且每一個波峰都非常的尖銳。
最佳化後的 FE
最佳化後，FE 堆記憶體佔用明顯下降，波峰也變得很平緩。FE 的穩定性得到了比較明顯的提升。
最佳化前、後的 BE
BE Compaction Score 監控反映版本的堆積情況，版本堆積的數值在 100 內屬於正常範圍，超過 100 說明叢集可能存在潛在風險。上文也講到，查詢時需要先進行檔案合併，再進行資料查詢，如果 Tablet 版本過多，版本合併會影響到查詢的速度和穩定性。
經過磁碟的部署最佳化和 Tablet 最佳化後，BE Compaction Score 可以穩定在 50 以內，查詢的穩定性和效能都得到了非常大的提升。
資料同步最佳化
最佳化前
MySQL 資料同步使用 Flink CDC -> Kafka -> Flink Doris Connector -> Doris 的方式全量 + 增量進入 Apache Doris。
在這個方案中，雖然 Flink CDC 支援全量歷史資料的初始化，但由於歷史遺留問題，部分表資料量較大，單表有幾億資料，而且這種表大多是沒有設定任何分割槽和索引，在執行簡單的 COUNT 查詢時都需要花費十幾分鐘的時間。
其次，Flink CDC 雖然可以進行增量資料同步，但對於這類表的全量資料初始化幾乎是不能實現的，因為 Flink CDC 做全量同步要先讀取全量資料，然後對資料分塊，再做資料同步，這種情況下，讀取是非常非常緩慢的。
最佳化後
全量同步使用 MySQL Dump -> CSV -> Doris Stream Load -> Doris
增量同步使用 Flink CDC -> Kafka -> Flink Doris Connector -> Doris
資料排程最佳化
我們在使用 DolphinScheduler 進行 Doris SQL 的任務排程時，同一 node 下配置多條 SQL 時會出現 node 執行狀態異常的情況，導致工作流 DAG 的 node 依賴失效，前一個節點未執行完，後一個節點就開始執行，結果會有缺資料甚至沒有資料的情況。這個問題是因為 DolphinScheduler 2。x 在同一個 node 下不支援按順序執行 MySQL 的多段 SQL，而 Doris 在 DolphinScheduler 中使用 MySQL 資料來源建立連線。
此問題在 DolphinScheduler 3。0。0 版本被修復，配置中可以設定多段 SQL 的分隔符，解決了 DAG 依賴關係失效的問題。
Apache Doris 元資料管理和資料血緣實現方案
在沒有元資料管理和資料血緣之前，我們經常會遇到一些問題，比如想找一個指標，卻不知道指標在哪張表，只能找相關開發人員來確認，當然也存在開發人員忘記指標的位置和邏輯的情況。因此只能透過層層篩選確認，此過程十分耗費時間。
之前我們將表的分層劃域、指標口徑、負責人等資訊放在 Excel 表中，這種維護方式很難保證其完整性，維護起來也比較困難。當需要對數倉進行最佳化時，無法確認哪些表是可以複用的、哪些表是可以合併的。當需要對錶結構進行變更時，或者需要對指標的邏輯進行修改時，也無法確定變更是否會對下游的報表產生影響。
在以上問題背景下，我們經常遭到使用者的投訴，接下來介紹如何透過元資料管理和資料血緣分析方案來解決這些問題。
實現方案
元資料管理和資料血緣是圍繞 Apache Doris 展開，同時對 DolphinScheduler 的元資料進行了整合。
我們將元資料分為物理元資料和業務元資料兩大類：
物理元資料維護表的屬性資訊和排程資訊
業務元資料維護資料在應用過程中約定的口徑和規範資訊
資料血緣實現了表級血緣和欄位級血緣：
表級血緣支援粗粒度表關係和跨層引用分析
欄位級血緣支援細粒度的影響分析
上圖中，右側表格是物理元資料業務，元資料指標和血緣分析能夠提供的資料服務。
接下來，一起看下元資料管理和資料血緣的架構和工作原理。
架構介紹
元資料管理和資料血緣實現方案技術棧
資料採集：使用 Apache Doris 提供的審計日誌外掛 Doris Audit Plugin 進行資料採集
資料儲存：對審計日誌外掛做了定製化開發，使用 Kafka 儲存 Doris 審計日誌資料
血緣解析：使用 Druid 進行 Doris SQL 解析
血緣關係儲存：使用 Nebula Graph 儲存血緣關係資料
業務元資料：因為業務元資料經常發生 CRUD，因此使用 MySQL 儲存業務元資料資訊
搜尋資料：使用 ElasticSearch 儲存血緣關係查詢索引以及表和欄位的搜尋索引資料
接下來介紹一下個架構四個組成部分：審計日誌的採集和清洗服務、血緣解析服務、元資料資訊整合服務、應用介面服務。
Apache Doris 審計日誌的採集 / 清洗服務
考慮到如果將資料清洗邏輯放在審計日誌外掛中，當資料清洗邏輯發生變更，可能會出現資料遺漏，這樣會對血緣分析和元資料管理產生影響，所以我們將審計日誌外掛資料採集和資料清洗進行了解耦，對 Apache Doris 的審計日誌外掛進行了改造，改造後審計日誌外掛可以實現審計日誌資料的格式化以及將資料傳送到 Kafka 的功能。
資料清洗服務，首先在清洗邏輯中增加資料重排邏輯，針對多個審計日誌外掛傳送的資料進行重新排序，解決資料亂序的問題。其次把非標準 SQL 轉化成標準 SQL，雖然 Apache Doris 支援 MySQL 協議以及標準 SQL 語法，但有一些建表語句、SQL 查詢語法與標準 SQL 存在一定差異，因此將非標準 SQL 轉化為 MySQL 的標準語句，最後將資料傳送到 ES 和 Kafka 中。
血緣解析服務
血緣解析服務使用 Druid 進行 Doris SQL 的解析，透過 Druid 抽象語法樹逐層遞迴獲取表和欄位的血緣關係，最後將血緣關係資料封裝傳送到圖資料庫、血緣查詢索引發送到 ES 。進行血緣解析的同時會將物理元資料和業務元資料傳送到對應儲存位置。
元資料資訊整合服務
元資料資訊整合服務借鑑了 Metacat 的架構實現方案。
Connector Manager 負責建立 Apache Doris 和 DolphinScheduler 的元資料鏈接，同時也支援後續其他型別資料來源接入的擴充套件。
Meta Service 負責元資料資訊獲取的具體實現。Apache Doris 元資料資訊主要從 information Schema 庫、Restful API、以及 SHOW SQL 的查詢結果三種途徑來獲取。DolphinScheduler 的工作流元資料資訊和排程記錄資訊從 DolphinScheduler 元資料庫獲取。
應用介面服務
我們提供了 3 種類型的應用介面服務，分別是血緣應用介面服務、元資料應用介面服務和資料行為分析應用介面服務。
血緣應用介面服務提供表、欄位、血緣關係、影響分析的查詢服務。
元資料應用介面服務提供元資料的查詢和欄位搜尋的服務。
資料行為分析應用介面服務提供表結構變更記錄、資料讀寫記錄、產出資訊的查詢服務。
以上就是元資料管理和資料血緣分析架構的整體方案的全部內容介紹。
總結及收益
今年我們完成了以 Apache Doris 為核心的準實時數倉建設，Apache Doris 經過半年的使用和最佳化，現在已經趨於穩定，能夠滿足我們生產的要求。
新的準實時數倉，對資料計算效率、資料時效的提升是巨大的。
以 On Time Delivery 業務場景報表計算為例，計算 1000w 單軌跡節點時效變化，使用 Apache Doris 之前需要計算 2 個多小時，並且計算消耗的資源非常大，只能在空閒時段進行錯峰計算；使用 Apache Doris 之後，只需要 3Min 就可以完成計算，之前每週更新一次的全鏈路物流時效報表，現在可以做到每 10 分鐘更新最新的資料，達到了準實時的資料時效。
得益於 Apache Doris 的標準化 SQL，上手難度小，學習成本低，報表的遷移工作全員都可以參與。
原來報表使用 PowerBI 進行開發，需要對 PowerBI 有非常深入的瞭解，學習成本很高，開發週期也很長，而且 PowerBI 不使用標準 SQL，程式碼可讀性差；現在基於 Doris SQL 加上自研的拖拉拽形式的報表平臺，報表的開發成本直線下降，大部分需求的開發週期從周下降到了天。
未來規劃
後續我們也將繼續推進基於 Apache Doris 的資料中臺建設，對元資料管理的完善、資料血緣的解析率持續進行最佳化，考慮到資料血緣是大家都渴望的應用，在未來血緣解析成熟後，我們會考慮將其貢獻給社群。
與此同時，我們正在著手進行使用者行為分析平臺的構建，也在考慮使用 Apache Doris 作為核心的儲存和計算引擎。目前 Apache Doris 在部分分析場景支援的函式還不夠豐富，例如在有序視窗漏斗分析場景，雖然 Apache Doris 已經支援了 window_funnel 函式，但是每層漏斗轉化的計算需要用到的 Array 相關計算函式還沒有得到很好的支援。不過好在即將釋出的 Apache Doris 1。2 版本將包含了 Array 型別以及相關函式，相信未來在越來越多的分析場景中 Apache Doris 都將得到落地。
作者介紹
付帥，橙聯（中國）有限公司數字化團隊，大資料研發經理，負責數字化團隊資料中臺的研發以及 OLAP 引擎的應用落地及效能最佳化。
炒股開戶享福利，入金抽188元紅包，100%中獎！
開啟App看更多精彩內容
