實時數倉在新東方線上教育的落地實踐

語言: CN / TW / HK

背景介紹

在傳統資料倉庫方面,通常以T+1離線批量計算為主,按照數倉建模方式,把要處理的業務按照主題域劃分,構建各種資料模型,來滿足公司經營分析,財務分析等各種公司管理層的資料需求。
然而,隨著線上教育快速發展市場競爭非常激烈,T+1的方式在某些需求上很難對業務產生實際的價值,很可能因為資料延遲導致業務動作滯後,管理要求跟進不及時,最終導致客戶流失,影響公司業務發展。 目前遇到的主要痛點如下:

  1. 續費業務場景
    線上教育上課主要分為4個時段(春季,暑假,秋季,寒假)。當每一個時段上課要結束的時候,就會有一個續費週期,每個學科每個班級續費率的高低直接影響公司是否盈利的問題。所以實時的觀測每個學科每個班級每個學科負責人每個教學負責人的續費率完成情況就顯的尤為重要
  2. 直播到課人/率場景
  3. 演算法線索分場景
    每當進行廣告投放的時候,針對每一個銷售線索給出一個評分值,來評估這個線索可能轉化的高低,利於銷售人員更好的跟進,提高轉化率

實時數倉技術架構

實時數倉選型

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

  • 基於hive/spark小時級方案雖然能滿足快速響應業務需求和變化的特點,但延遲性還是很高,並且大量的小時任務對叢集計算資源有很大壓力,很有可能導致這一批小時任務根本跑不完。
  • 分鐘級spark-streaming方案,能夠滿足資料時效性需求,但採用純程式碼方式來開發,無法滿足快速變化的資料需求

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

實時數倉方案:

分別可以採用lambda架構和kappa架構

  1. lambda架構
    如上圖所例項:存在離線和實時兩條鏈路。實時部分以訊息佇列的方式實時增量消費,一般以flink和kafka的組合實現,維度表存在mysql資料庫或者hbase;離線部分一般採用T+1週期排程分析歷史存量資料,每天凌晨產出,更新覆蓋前一天的結果資料,計算引擎通常會選擇hive. 優點是資料準確度高,出錯後容易修復資料;缺點是架構複雜,運維成本高。
  2. kappa架構 kappa架構是由LinkedIn的Jay Kreps提出的,作為lambda方案的一個簡化版,它移除了離線生產鏈路,思路是通過在kafka裡儲存全量歷史資料,當需要歷史計算的時候,就啟動一個任務從頭開始消費資料。優點是架構相對簡化,資料來源單一,共用一套程式碼,開發效率高;缺點是必須要求訊息佇列中儲存了存量資料,而且主要業務邏輯在計算層,比較消耗記憶體計算資源。
    但由於之前流處理系統本身不成熟,對視窗計算,事件時間,亂序問題和SQL支援上的不成熟,導致大部分公司普遍採用了lambda架構方案。但自從2020年2月11日,flink釋出了1.10以及隨後的1.11版本,引入了blink planner和hive整合極大的增強了在SQL和流批一體支援上,這為真正實現kappa架構帶來了一絲希望。
準實時數倉方案:

其核心思路是,採用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. 對於一些分析類查詢需求,通過doris的export功能匯出到hive通過presto提供查詢
  5. BI查詢直接通過mysql協議訪問db,配合查詢層快取來提供報表分析服務
  6. 每層ETL任務通過自研排程系統排程執行,報警監控一體化
使用doris遇到的一些問題

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

  1. 表資料副本不一致問題
    xxx
  2. union all資料為NULL問題
    xxx
  3. load 很高 IO高磁碟寫入資料量很大
    xxx
  4. socket 檔案控制代碼洩漏問題
    xxx

使用總結

  • 在資源有限的情況,實時數倉還不能完全代替離線數倉。實時數倉對資源要求較高,成本換時間。離線數倉是時間換成本。也許在不久的將來隨著算力的提高,新的技術的應用可以實現,但,目前還沒有。
  • 隨著資料量的增加計算延遲也會增加,兩者呈線性關係。這就需要在業務需求和成本上做一個折中
  • 使用doris支撐了公司大部分實時資料需求,在保證開發成本和使用靈活性方面非常友好
  • 未來隨著flink SQL方面越來越成熟可以把計算任務壓力進一步轉移到flink上,結合doris的olap能力,可以提供更低延遲資料需求