Doris 實時數倉建設實踐

概述

Drois 從早期的百度項目，到開源Apache Doris，到商業化的StarRocks，到各大雲服務商，陸續上線，作為新一代的OLAP解決方案，在應用場景上表現得非常好

整理對近期對Doris實時數倉建設的一些思考

背景

1. 公司有很多業務線，每個業務線有自己的産品，沉澱了各自業務的資料，也使用了各種不同的存儲媒體，Mysql,Elasticsearch,Oracle,MongoDB 等等
2. 公司希望将資料打通，對資料聯合跨庫分析，輸出結果
3. 至于實時數倉的需求，主要是目前很少有人能接受 T+1的資料
4. 公司目前的資料量在PB級以下，Hadoop生态暫時不需要涉及，目前Doris也在持續疊代，期待越來越好

主體思路

1. 使用Doris對各類資料源進行整合，實作資料層面的打通
2. 建立研發的資料庫設計使用标準，以及實時數倉的相應規範，資料分層
3. 建立統一的資料名額管理，資料資産管理

步驟：

一、 使用Doris對各類資料源進行整合

1. 資料整合形式主要分為 『建立外表』、『資料導入』 兩種，我們在部份業務初期，并未使用資料導入方式，因為資料導入需要額外的元件及維護成本，并且業務初期，需求變更導緻的表結構變更是常事，還有業務初期資料量不大。綜合以上考慮，在業務初始 基本政策是『建立外表』，建立的外表，Doris能夠将跨庫的SQL文法自動拆解，轉換為各種類型的存儲媒體需要的文法結構，然後在Doris中進行資料合并。如：基于Doris實作Mysql與Es的聯表查詢
2. 當某張表達到了一定量級，業務的資料庫不能滿足分析需求，同時也是對業務庫産生了影響，影響客戶層面的正常使用，此時就有必要使用『資料導入』，将資料導入到Doris 基于Doris的能力進行針對性優化
3. 為了避免從『建立外表』->『資料導入』變更帶來的影響。表、字段、列類型 都不會改變，即業務不需要調整
4. 『資料導入』我們使用Flink CDC 配合Doris提供的Flink Doris Connector , 将業務庫的資料一比一實時的同步到數倉，即 增、删、改 行為的同步，Flink exactly once + 唯一模型 + 批量删除 實作兩端資料的一緻性，這是我們的資料分層中的原始資料層ODS層
5. 單純的将資料一比一複制過來，并不能對查詢帶來明顯的性能提升，如果業務庫資源不錯，還有可能更慢。需要在表結構（如分區分桶，合适的字段類型）與物化視圖上 作文章，做大吞與大并發的取舍,能夠得到明顯的性能提升
6. 做到這一步後，如果希望有更高的查詢性能要求，則需要對表結構進行變更，同時業務查詢邏輯也需要配合做調整。做數倉的同鞋都知道，業務庫的設計結構并不适合做分析，可能一個簡單的名額輸出，會跨個10-20張表也不是沒可能，是以更進一步可以根據傳統的次元模組化理論，如星型模型，基于Flink對資料進行實時清洗，生成基于事實的不更新大寬表,和帶常更新字段的次元表，分别使用Duplicate模型與Unique模型
7. 做到這一步後因為對原始的表進行了便于OLAP場景的重新規劃，減少了不必要的表連接配接，是以性能上會再一次得到提升，并且因為明細表使用了Duplicate，是以可以通過物化視圖對資料進行預聚合，進一對對查詢性能的提升

數倉建設不能一蹴而就，需要循序漸進，更高的查詢性能要求，意味着更高的維護、開發成本 , 總結資料整合及優化曆程是：

1. 建立外表 - 實作跨庫連表分析
2. 資料導入 - 減少業務庫性能壓力
3. 對資料導入的表進行表結構優化 - 增加查詢性能
4. 對資料導入的表建立物化視圖 - 增加查詢性能
5. 次元模型規劃次元表與事實表 - 增加查詢性能
6. 對通過模組化生成的事實表做物化視圖 - 增加查詢性能

話外篇

1. 在前面四步中，與業務的表結構是沒有變化的，是以為了能對曆史統計分析型系統做優化，我們開發Springboot Starter插件，通過加注解和攔截器或配置的方式，将本來在業務庫中執行的查詢邏輯轉發到數倉執行，将執行結果封裝成業務需要的格式，業務代碼邏輯基本不用調整，以一個比較小的代價優化曆史系統
2. 為了減少資料導入的成本，基于Flink CDC + Checkpoint + Exactly once + Flink Doris Connector + Doris批量删除方法 開發了mongodb-to-doris,mysql-to-doris 等Flink程式，抽象參數，實作複用

二、建立研發的資料庫設計使用标準，以及實時數倉的相應規範，資料分層

1. 在數倉建設過程中，最大的敵手是業務資料的不規範導緻了一系列故障，資料不準等問題，如：
   1. 使用19位以上的雪花算法生成的ID, 在Doris中會發生精度丢失
   2. 髒資料，如時間字段發生在了2036年/1970年，沒法建分區
   3. 明明在業務上有值的，硬是有幾條為Null
   4. 無主鍵設計
   5. update_time,create_time 邏輯不對,有的代碼維護，有的系統生成
   6. 這裡叫has_delete,另一邊叫is_validate
   7. 字段長度問題
   8. 消息中件間使用不規範，多個系統資料對不上 - 系統間資料如何保證一緻性
   9. 命名結構不統一 sex,gender , update_time,update_date
   10. 屬性值不統一，這邊0表示男，那邊0表示女
   11. 我一定要用mongo存個2M的二進制圖檔進去
2. 這些上遊的代碼品質，資料品質問題，SQL查詢，表結構設計等問題傳遞到下遊數倉來，發生了一系列的災難
3. 是以建立實時數倉的同時，亦要去抓上遊，把上遊抓好，數倉這個下遊就能輕松很多，有的時候不是你不夠優秀，而是上遊拉跨了
4. 上遊的優化思路可以是将每一個業務系統當成一個小型的數倉，每個小的數倉合并成一個大的數倉，統一規範，統一命名，統一标準，以一個人的視角來通盤設計 。 圍繞這個思路建立相關的研發規範

話外篇

1. 深入到業務中非常有必要

三、建立統一的資料名額管理，資料資産管理

1. 實時數倉的建設不僅是資料的維護，也是企業資料資産的維護，彙聚了海量的業務資料，能否使這些資料産生價值，能否在老闆有某個想法的時候快速響應，能否在客戶有資料疑問的時候快速應答，能否在資料錯誤的時候快速定位
2. 這塊市面上已經有比較好用的雲服務産品、開源項目等，能夠協助來做這方面的工作
3. 這是一個長期且需要耐心的工作