應用實踐——新東方實時數倉實踐

背景介紹

在傳統資料倉儲方面，通常以 T+1 離線批量計算為主，按照數倉建模方式，把要處理的業務按照主題域劃分，構建各種資料模型，來滿足公司經營分析，財務分析等各種公司管理層的資料需求。

然而，隨著線上教育快速發展市場競爭非常激烈，T+1 的方式在某些需求上很難對業務產生實際的價值，很可能因為資料延遲導致業務動作滯後，管理要求跟進不及時，最終導致客戶流失，影響公司業務發展。

目前我們遇到的主要痛點如下：

·續費業務場景：線上教育上課主要分為 4 個時段(春季，暑假，秋季，寒假)。當每一個時段上課要結束的時候，就會有一個續費週期，每個學科每個班級續費率的高低直接影響公司是否盈利的問題。所以實時的觀測每個學科每個班級每個學科負責人每個教學負責人的續費率完成情況就顯得尤為重要。

·直播行課場景：分析課中學員與老師互動行為，其中包含實時的連麥、發言、紅包等行為資料，同時分析學員實時到課、完課、考試等資料對於管理學員和調整老師動作有重要的指導意義。

·銷售場景：監控新線索的實時分配，以及後續銷售外呼頻次、外呼時長，統計銷售線索覆蓋量，外呼覆蓋量等指標。通過分析銷售對於學員的跟進與轉化資料，對比個人和團隊當日人次和金額達成目標，指導運營管理動作。

·演算法線索分場景：每當進行廣告投放的時候，針對每一個銷售線索給出一個評分值，來評估這個線索可能轉化的高低，利於銷售人員更好的跟進，提高轉化率。

實時數倉技術架構

01 實時數倉選型

在 2020 年以前公司實時資料部分，主要由小時級和分鐘級的支援。小時級部分使用基於 Hive/Spark 的小時級任務方案，分鐘級使用 Spark-Streaming 方案。

·基於 Hive/Spark 小時級方案雖然能滿足快速響應業務需求和變化的特點，但延遲性還是很高，並且大量的小時任務對叢集計算資源有很大壓力，很有可能導致這一批小時任務根本跑不完。

·分鐘級 Spark-Streaming 方案，能夠滿足資料時效性需求，但採用純程式碼方式來開發，無法滿足快速變化的資料需求

基於此，我們開始調研業界方案，目前業界有主要有兩種實時數倉方案，分別是實時數倉方案和準實時數倉方案。

02 實時數倉方案

實時數倉方案分別可以採用 Lambda 架構和 Kappa 架構。

Lambda 架構

如上圖所示例，Lambda 架構存在離線和實時兩條鏈路，實時部分以訊息佇列的方式實時增量消費，一般以 Flink 和 Kafka 的組合實現，維度表存在 MySQL 資料庫或者 Hbase ;離線部分一般採用 T+1 週期排程分析歷史存量資料，每天凌晨產出，更新覆蓋前一天的結果資料，計算引擎通常會選擇 Hive ，優點是資料準確度高，出錯後容易修復資料;缺點是架構複雜，運維成本高。

Kappa 架構

Kappa 架構是由 LinkedIn 的 Jay Kreps 提出的(參考 Paper: )，作為 Lambda 方案的一個簡化版，它移除了離線生產鏈路，思路是通過在 Kafka 裡儲存全量歷史資料，當需要歷史計算的時候，就啟動一個任務從頭開始消費資料。優點是架構相對簡化，資料來源單一，共用一套程式碼，開發效率高;缺點是必須要求訊息佇列中儲存了存量資料，而且主要業務邏輯在計算層，比較消耗記憶體計算資源。

但由於之前流處理系統本身不成熟，對視窗計算、事件時間、亂序問題和 SQL 支援上的不成熟，導致大部分公司普遍採用 Lambda 架構方案。但自從 2020 年 2 月 11 日，Flink 釋出了 1.10 以及隨後的 1.11 版本，引入了 Blink Planner 和 Hive 整合極大地增強了對於 SQL 和流批一體支援，這為真正實現 Kappa 架構帶來了一絲希望。

03 準實時數倉方案

準實時數倉方案

其核心思路是，採用 OLAP 引擎來解決聚合計算和明細資料查詢問題，配合分鐘級別排程(一般是 30 或者 15 分鐘)能力來支援業務實時資料需求。該架構優點是：

·一般 OLAP 引擎都對 SQL 的支援度很好，開發成本極低少量人員都可以支援複雜的業務需求，靈活應對業務變化。對於差錢的公司來說無疑非常節約成本的(財大氣粗的公司除外);

·對於資料修復成本低，因為可以基於一個週期內的資料進行全量計算，所以修復資料只需要重跑任務即可;

·對於運維成本也較低，只需要監控任務執行成功失敗即可;

·對於資料時效性要求較高的場景，配合 Flink 實時計算能力，在資料接入的時候進行部分聚合計算，之後再把結果寫入 OLAP 引擎，不需要再配合排程計算，以此來到達秒級延遲。

該架構的缺點是：

·將計算轉移到了 OLAP 引擎並同時兼顧了計算和查詢需求，對 OLAP 引擎效能有較高的要求;

·因為計算轉移到了 OLAP 端，所以這種方案適用的資料體量規模有一定限制。

基於 Doris 的準實時方案

結合公司資料規模、業務靈活性、成本方面的考慮，我們選用的準實時的方案。那麼接下來的就是確定採用什麼 OLAP 引擎的問題了，目前業界開源的 OLAP 引擎主要有 Clickhouse、Durid、Doris、Impala+Kudu、Presto等。

這些引擎目前業界都有公司採用，比如：頭條採用 Clickhouse(因為頭條資料量巨大，並且頭條專門有一個團隊來優化和改進 Clickhouse 的核心，有錢就是好)，快手採用 Durid 、Doris 美團/作業幫有采用，Impala+Kudu 網易是深度使用者，Presto 主要用做 Adhoc 查詢。

對此可以看到這些引擎都可以採用，主要問題是，是否對這些引擎有足夠的掌握程度以及引擎本身學習成本。經過一番對比，結合之前本身對 Doris 有一定的瞭解，再橫向對比了使用公司的規模，最後選擇了 Doris 引擎。

Doris 的優點如下：

·單表和多表 Join 查詢效能都很強，可以同時較好支援寬表查詢場景和複雜多表查詢，靈活性高

·支援實時資料更新操作

·支援流式和批量資料匯入

·相容 MySQL 協議和標準 SQL

·支援 HA，線上升級擴容，運維成本低

總體架構

系統架構方案

上圖是目前公司採用的架構方案，總體流程如下：

·1. 資料接入部分，分為業務資料和日誌資料。業務資料通過 Binlog 方式收集到 Kafka 後，再通過 Flink 寫入到 Doris ODS 層中

·2. MDS 層，採用每 10 分鐘、半小時、一小時進行增量或全量的方式更新，構建業務模型層

·3. ADS 層，構建大寬表層加速上層查詢速度

·4. 對於一些臨時的 Ad hoc 大查詢需求，通過 Doris 的 Export 功能匯出到 Hive 通過 Presto 提供查詢，避免影響線上業務核心報表

·5. BI 查詢直接通過 MySQL 協議訪問 DB，配合查詢層快取來提供報表分析服務

·6. 每層 ETL 任務通過自研排程系統排程執行，報警監控一體化

在實際業務應用中也遇到了一些問題，主要有如下幾個方面的問題。

Socket 檔案描述符洩漏問題

因為進行查詢和 ETL 都需要通過 JDBC 或 MySQL 客戶端與 FE 的 9030 埠連線，在測試使用 0.10 版本時發現有的 Socket 的檔案描述符沒有辦法正常關閉，每小時都會產生幾十個 FD 洩露，最後達到上限無法建立新的 Socket 連線，只能通過重啟的方式釋放掉關閉異常的 FD 。

經過排查所有相關連線使用的程式碼，發現並沒有可能產生連線不關閉的部分，諮詢發現其他 Doris 使用者並沒有出現過類似問題，經過反覆和社群溝通最終確定是 MysqlNIOServer 的 Bug ，目前已經修復。

語法相關問題

·union all null值問題

在使用 with 語句生成的虛擬臨時表時，如果有值為 null 的欄位，這個欄位在後續使用時的值會變成空字串，不論是直接插入表還是通過 not null 進行過濾都無法得到正確結果。

·常量值 Join 時會關聯出錯誤資料

如果 with 查詢中使用了 case when 等對欄位進行常量值賦值的情況，如果 Join 關聯時的關聯條件使用到了這個欄位，則有可能出現錯誤關聯的情況，例如無法關聯上的資料錯誤的關聯上了。

·lead 和 lag 函式導致的資料錯位

如圖所示，在使用 lead 或者 lag 函式對資料處理時，會出現時間資料錯位的問題。

以上三個在使用時發現的問題，經過與百度 Doris 團隊開發者的反饋，現在這兩個問題已經在新版本中完成修復。

副本不一致

為了保證資料的高可用，避免因為某個 BE 磁碟損壞導致的資料丟失，同時可以提高本地計算的概率，通常會給表設定大於 1 的副本數，雖然 TabletChecker 和 TabletScheduler 會定期檢查所有分片，並對不健康的分片進行修復，然而依然會出現某些副本不一致的情況。

針對某些副本不一致的情況我們進行研究，發現在使用 Uniq 模型時，如果進行 ETL 插入的資料含有多條相同 Unique Key 且沒有對這些資料進行排序時，不同副本中實際存入的資料可能會出現不一致的情況。後續對 SQL 進行改進，對 Unique Key 進行去重或者排序之後，這種情況的副本不一致就沒有再次出現。

Json 解析時如果含有製表符則無法解析

在使用 getjsonobject 解析 Json 格式的字串時，如果字串中含有製表符，最後的解析會失敗，這時必須對字串進行字元替換，將製表符替換成空字元，然後再解析 Json 。

使用總結

·在資源有限的情況，實時數倉還不能完全代替離線數倉。實時數倉對資源要求較高，成本換時間。離線數倉是時間換成本。也許在不久的將來隨著算力的提高，新的技術的應用可以實現，但目前還沒有。

·隨著資料量的增加計算延遲也會增加，兩者呈線性關係，這就需要在業務需求和成本上做一個折中。

·使用 Doris 支撐了公司大部分實時資料需求，在保證開發成本和使用靈活性方面非常友好。

·未來隨著 Flink SQL 方面越來越成熟可以把計算任務壓力進一步轉移到 Flink 上，結合Doris 的 OLAP 能力，可以提供更低延遲資料需求。