替換Kudu,Hologres助力好未來網校實時數倉降本增效

語言: CN / TW / HK

客戶介紹

好未來(NYSE:TAL)是一家以智慧教育和開放平臺為主體,在全球範圍內服務公辦教育,助力民辦教育,探索未來教育新模式的科技教育公司。好未來的前身學而思成立於 2003年,2010年在美國紐交所正式掛牌交易。好未來以“愛和科技讓教育更美好”為使命,致力成為受尊敬的教育機構。當前,好未來已構建起從工具、平臺到內容的多元化教育生態,滿足從-1歲到 24歲各年齡段人群個性化學習需求。目前,好未來旗下擁有學而思素養、學而思網校、彼芯、美校、學而思國際、學而思文創出版中心、學而思大學生、媽媽幫等品牌,並戰略投資了赫石少兒體能等多個品牌。集團業務覆蓋素質教育、技術服務、海外教育服務、數字內容出版、教育硬體、託管服務等領域。

學而思網校,紐交所上市公司好未來旗下線上教育品牌,為6-14歲的孩子提供素質教育服務。2008年成立至今,積累了十餘年教研經驗和學習資料,陪伴千萬孩子成長,在家長間口口相傳。學而思網校首創“直播+輔導”的雙師教學模式,大力投入AI和全真網際網路等前沿技術,持續推動教育創新。2021年學而思網校全面升級素養體系,推出人文美育、科學創想、程式設計與機器人等熱門素養課程。

網校實時數倉發展背景介紹

網校實時數倉1.0從2019年開始搭建,基於Kudu OLAP引擎構建,前期承載業務不多,任務量不大,執行穩定、效能也很高,比較適合前期的技術選型;自2020年後,網校進入業務快速發展期,實時開始承接更多的業務需求,包括營銷域、交易域、教學域等資料域的建設以及實時大屏,隨著需求增多,實時數倉任務量、資料量也不斷攀升,Kudu開始遇見技術瓶頸,無法快速滿足業務需求,運維難、成本貴等問題也開始凸顯。

image.png

與此同時,2021年7月教育行業遭受“雙減”,公司業務開始面臨業務縮減以及轉型等業務變化,大量學科類、無效任務空跑,造成資源的極大浪費,成本治理提升日程,開始著手調研建設成本更低的實時數倉OLAP引擎。經過市面上幾款OLAP引擎的對比,最終選型Hologres,並於2022年1月開始實時數倉升級,經過半年多的成本治理以及數倉建設,網校實時數倉邁入2.0階段,相比於1.0版數倉,更加穩定、可靠,建設成本也更低。此次升級主要是針對實時數倉的底層OLAP引擎的升級,使用阿里雲Hologres替換Kudu,實現實時數倉降本增效,助力業務更加精細化增長。

實時數倉1.0:以Kudu為OLAP引擎,技術瓶頸凸顯

1、網校實時數倉1.0全景圖

實時數倉1.0支撐著網校大部分的線上資料,用於報表分析,精準營銷等多個場景,其業務資料流程如下圖:

  1. ODS層主要儲存日誌、業務庫同步過來的原始資料,包括使用者行為等埋點日誌以及業務資料等。
  2. ODS層資料清洗後,寫入DWD層,並在DWD層對根據業務需求資料做細分,分為教學、交易、營銷等明細資料。
  3. DWS層將DWD資料與學員、課程、班級、講次資訊等維表進行關聯,生成業務寬表或者業務模型彙總等資料。
  4. ADS層從DWS獲取資料,面向應用層,主要是使用MSQL、Polardb作為查詢引擎,根據業務場景對接實時看板、實時大屏、實時介面等,賦能實時銷量、轉化、續報、線上、出勤、完課等場景。

image.png

2、基於Kudu架構的場景方案

整個實時數倉1.0都是基於Kudu來建設的。其背後的技術架構如下圖:

image.png

根據業務的時效性,將網校的場景分為分鐘級場景和實時秒級場景。

1)準實時數倉模型(分鐘級):

在分鐘級實時數倉中,會通過Spark/Flink對資料進行預處理後寫入Kudu,並在Kudu中根據ODS、DWD、DWS分層計算,然後將資料寫入ADS層的PolarDB或者MySQL,最後對接實時大屏、報表等業務。

image.png

2)實時數倉模型(實時秒級):

在實時秒級的場景中,對資料的時效性要求非常高,採用Flink+Kafka架構,DWD明細資料同時會落地一份到Kudu,DWS層計算過程中 關聯Kudu維表、以及歷史DWD資料來完成彙總模型構建,輸出結果資料到ADS層的PolarDB、MySQL、Kafka訊息佇列等,最後對接線上服務。

image.png

網校實時80%左右場景,使用分鐘級實現;20%場景使用秒級實時鏈路實現。當然也有部分場景可能使用混合鏈路實現,比如實時線上、出勤,Flink程式實時接入心跳明細資料到數倉DWD層,然後在DWS層進行分鐘級彙總班級出勤、線上等資料,在ADS層進行資料的輸出。

3、業務挑戰:Kudu技術瓶頸凸顯,業務成本治理刻不容緩

實時數倉1.0中,Kudu作為底層OLAP引擎,使用Impala進行資料載入、運算,當業務上量時,Kudu的技術瓶頸開始凸顯,主要表現在以下幾個方面:

  1. 業務發展後期,Impala伺服器記憶體壓力較大,記憶體不足問題頻發:網校80%的業務使用分鐘級數倉實現且都是每隔5分鐘計算一次,Impala承載Kudu資料的載入、計算,大量複雜計算的Sql任務在同一時間瞬時打到伺服器,導致Impala節點記憶體壓力較大,甚至出現部分批次任務執行失敗情況。
  2. 運維困難:缺乏Kudu專業運維同學,當某個資料指標計算出現問題,或者叢集不穩定時,有比較長的運維流程和修訂流程,嚴重影響實時服務的穩定性,無法保證實時資料的SLA,使得使用者體驗非常不好。
  3. 故障恢復時間長,當出現節點故障的時候,為了快速恢復業務,短期靠擴容節點來暫時解決問題,導致運維和成本壓力逐步增大。
  4. “雙減”原因,急需對成本進行治理,迫切需要將Kudu切換到建設成本更低、更穩定、可靠的OLAP引擎。

綜上,基於Kudu實時數倉,正逢“雙減”,面臨著業務快速變化、成本壓力以及運維困難等一系列的內、外部挑戰,我們迫切的希望能夠找到一款OLAP產品將Kudu進行替換,解決當前遇見的各種問題,搭建一個更加簡潔、易用、運維便捷、資源動態伸縮容的數倉底座。

實時數倉2.0:Hologres讀寫分離部署全面替換Kudu

基於實時數倉1.0的技術痛點,在對市面上的多種OLAP引擎進行調研以及對比後,我們最終選擇了阿里雲Hologres替換Kudu搭建網校實時數倉,即實時數倉2.0版本。

1、OLAP引擎技術選型需求:高吞吐、高可用

根據業務,我們梳理了對OLAP引擎的需求如下:

  • 強大的OLAP能力
  • 支援SQL,支援更新、刪除、Upsert操作
  • 高吞吐、高可用
  • 運維方便,資源伸縮便捷

同時我們也對比了市面上常見的OLAP引擎,如下表所示,最終選擇了Hologres為新的OLAP引擎

image.png

2、Hologres全面替換Kudu作為主OLAP引擎

選擇了Hologres作為實時數倉的主OLAP引擎之後,通過Hologres替換了Kudu的所有資料處理鏈路,同時也通過Hologres讀寫分離部署的方式,以只讀從例項(簡稱從庫)替換了原PolarDB/MySQL等查詢引擎,以此構成了實時數倉2.0。資料鏈路如下:

  1. 資料分為離線和實時兩部分。離線部分資料來源資料通過集團採集工具T-Collect接入Hologres ODS層,實時部分通過Flink實時接入MySQL Binlog、埋點日誌等資料入倉。
  2. 在Hologres中對數倉分為ODS、DWD、DWS、ADS等4層,每一層的資料通過集團T-Data平臺分鐘級排程、清洗,並最後由Hologres從庫提供線上服務出口。
  3. 實時和離線資料統一由Hologres儲存,並由從庫作為查詢引擎統一提供線上資料出口,支撐的業務場景包括實時看板、實時大屏、實時介面服務、實時推送等場景。

image.png

3、查詢引擎統一切換到Hologres從例項

實時數倉1.0計算在Kudu中,算完之後把結果同步到查詢引擎PolarDB或者MySQL中,實時鏈路相對來說比較長,而且資料移動成本也很高,對實時資料的穩定性有一定的影響。

實時數倉2.0中,我們採用Hologres共享儲存多例項的高可用部署方案,Hologres主例項承載資料的載入、計算,從庫共享主庫的所有表和資料承載資料查詢,實現讀寫分離方案,並且從庫作為實時數倉唯一的資料出口,統一數倉技術架構。這種方案的好處是減少了ADS層資料同步匯出鏈路的維護,降低了開發成本。

Hologres的共享儲存多例項的高可用部署方案如下圖所示:

image.png

實時數倉2.0查詢引擎統一升級切換到Hologres從庫後的資料流轉圖前後對比如下:

image.png

同時,我們計劃對外開放Hologres從庫ADS層,分析師或者懂SQL的產品老師後期可通過集團T-Query平臺查詢工具對實時資料進行探索、分析,自滿足部分臨時需求,減少人工需求、釋放實時數倉開發人力。

助力數倉業務升級,完成降本增效

實時數倉2.0經過半年多的建設,在成本治理上取得了非常好的效果,同時基於Hologres的實時數倉架構在集團推廣應用上也有比較成功的案例:

1、百萬級寫入和毫秒級查詢能力

  • 實際業務中,Hologres的寫入能力達到百萬行+/秒,業務就能快速拿到資料並查詢。同時在查詢上不僅能支援秒級OLAP分析,還能支援線上服務毫秒級響應,使得業務探索資料的效率變得更快。
  • 通過Hologres多子例項的部署方式,天然的就支援了網校實時數倉的多個查詢場景,統一了資料的出口,簡化了數倉的使用。並且寫入和查詢之間互不影響,非常有效的做到了讀、寫分離。

2、降低成本近百萬/年

  • 實時數倉底座升級Hologres後,無需維護多套系統,通過Hologres一套系統支援了實時數倉的全部場景,OLAP引擎成本相比Kudu節約了近百萬/年的費用。
  • 公司業務轉型背景下,通過資料治理、任務治理等任務數下降80%,Yarn佇列資源成本節約幾十萬/月,資料冗餘儲存減少90%,提升了資料的利用率。

3、減少運維壓力

  • 通過Hologres替換Kudu後,依託阿里強大的技術運維能力,很大程度減少了我們在運維層面上的壓力,更加專注於業務開發,有更多精力去做好實時資料的穩定性、準確性、及時性,把使用者體驗做好。
  • 週末、暑假等業務高峰資源不足時,可隨時進行擴容;業務低峰時,可以對資源進行縮容處理,做到很好的一個資源伸縮和成本控制。

4、集團內Hologres實時數倉架構推廣

  • 網校實時數倉天然帶有K9基因,希望學成功複製網校實時數倉2.0架構,並承載核心實時資料服務,比如實時續報、轉化、企微等

未來規劃和期望

未來規劃:

  • 網校實時數倉的持續建設
  • 資料治理:元資料、資料質量、資料資產、資料安全等
  • 流批一體技術探索

最後談一談,在Hologres使用過程中碰到一些問題以及對Hologres的期待

  • Hologres暫時還不支援自定義函式,系統自帶函式滿足不了部分特殊需求,自定義函式這塊可以同阿里的技術夥伴一起去共建、推動此功能的實現、上線。
  • 其次是Hologres許可權配置問題,目前支援簡單許可權模型、專家許可權模型和Schema級別許可權模型三種模式,專家模型功能最強大(支援細粒度表級別許可權控制),但配置比較複雜,需要執行的命令細節多,從而運維不方便,線上使用的是簡單許可權模型,許可權要控制到schema、表級別,需要在應用系統層面加一層庫、表許可權管理系統,增加了開發成本;開源Hadoop離線數倉有Range等許可權控制框架,能做到精準庫、表等許可權控制,期望Hologres以後能把許可權模型優化得更加簡單易用,更多白屏化操作,方便上手。
  • 同時,我們期待Hologres後面可以支援查詢開源架構Hive表的資料,這樣的話做流批一體可以有更加便捷、簡單的實現方案。

相信Hologres未來會變得越來越好用,變成一款功能更全面、更加強大的OLAP引擎!我們也希望通過Hologres建設出更加優秀的實時數倉,賦能更多的業務。

作者:劉標新,好未來網校實時數倉開發工程師、負責人。王洋,好未來網校實時數倉開發工程師

參考文章:

學而思網校:https://touch.xueersi.com/

實時數倉Hologres核心技術揭祕:https://developer.aliyun.com/article/779118

實時數倉Hologres共享儲存例項介紹:https://help.aliyun.com/document_detail/360394.html