做業幫基於 Apache Doris(Incubating) 的數倉實踐

【本文經做者受權轉載，原則做者 糜利敏，聯繫方式見文章末尾】

關於 Apache Doris(Incubating)

Apache Doris(Incubating) 一款基於大規模並行處理技術的交互式SQL分析數據庫，由百度於2018年貢獻給 Apache 基金會，目前在 Apache 基金會孵化器中。

Github: https://github.com/apache/incubator-doris，歡迎你們 Star、提 Issue、Pull Request。

官方網站：http://doris.incubator.apache.org/  能夠查看更多安裝、部署、使用文檔，也歡迎對文檔內容進行校對或建議。

開發者郵件列表：dev@doris.apache.org，（如何訂閱請戳這裏）

背景

做業幫大數據團隊主要負責建設公司級數倉，向各個產品線提供面向業務的數據信息，如到課時長、答題狀況等，服務於拉新、教學、BI等多個重要業務線。在過去數月內，咱們經過對Doris的應用實踐，構建了數倉實時查詢系統。本文總結並分享下期間的工做內容，也歡迎你們一塊兒討論。

典型的數倉從邏輯上劃分爲：

大數據團隊主要負責到ODS-DWS的建設，從DWS到ADS通常是數倉系統和業務線系統的邊界。

在過去，因爲缺失統一的查詢系統，探索了不少模式來支持各個業務線發展。

• 非流量類
  • Kafka 。業務線從kafka接數據本身作數據的聚合計算。主要問題在於徹底沒有數倉的概念，業務線在作大量重複的建設
  • Spark + ES。每來一個業務需求，就構建一個Spark+ES集羣（spark負責計算寫入到ES，ES業務層直接使用）。效率低、構建成本高，且ES高效的使用自己自己就須要學習ES的接口以及內部原理，對於業務線很難有這樣的精力去作
  • ES + 自定義API。大數據將數據寫入ES後，並case by case構建api。初步有了數倉的接口，可是接口不具備Sql的能力，只能基於需求case by case的構建，效率過低。
  • ……
• 流量類（如pv、uv等）
  • 因爲數據量大，每每須要預聚合，引入druid

 

這些「煙囪」式的系統構建方式，致使系統愈來愈難以維護，且業務接入效率也逐步下降。

所以，統一整個查詢引擎，對於數倉建設在提升業務支持效率、下降維護成本上都具備很是重大的意義。

整體方案

通過過去數月的探索與實踐，咱們確立了以Doris爲基礎的數倉實時查詢系統。同時也對整個數倉的數據計算系統作了一次大的重構，最終總體的架構圖以下：

如圖所示（從下到上），原始業務層日誌經數據攝入系統進入數倉，在數據清洗計算層，咱們將原來的Spark系統升級到了Flink，而且基於Flink-Sql提供了統一數據開發框架，從原有的代碼開發升級到Sql開發來極大的提高數據的研發效率。

其後查詢系統將Kafka的數據實時同步到查詢引擎內，並經過OpenAPI的統一接口對外提供查詢服務。

接下來，重點講下查詢系統的工做。

查詢引擎選型

實時查詢系統的核心在於肯定查詢引擎。

社區的查詢引擎較多，如Impala、Presto、Doris、ES（xpack），以及雲上的ADB等。這塊考慮到調研成本、團隊技術生態、維護成本等多種因素，咱們最後選擇了Doris 做爲咱們的查詢引擎。

在性能調研時，咱們也走了一些彎路：第一次使用Doris來作查詢引擎，發現使用咱們的業務Sql，延遲數據比較大，且CPU使用率很高（IDLE < 10%），

緣由在於使用了AGGREGATE模型，如對於訂單數據，通常會將用戶支付金額等做爲指標列（如一個用戶從訂單預訂到支付，狀態的改變會修改支付金額值），可是業務端的Sql中有大量的基於支付金額（指標列）的篩選查詢，如統計支付金額 > 某個值的用戶數。

Doris對於指標列的篩選成本較高，底層採用了類LSM-Tree的結構，所以爲了肯定某一行的數據是否該被篩選，須要掃描全部底層文件內包含該行的數據，進而聚合計算後才能夠決策是否結果集包含該行（UNIQ模型相似）。而DUPLICATE表沒法更新列。

最終使用Doris on ES，主要考慮點

• 任意列檢索。基於ES的倒排索引，我們能夠對任意列進行檢索（篩選）。這個模型大大下降了業務同窗的學習理解成本，能夠和mysql一樣方便的構建數據模型。
• ES的易用性以及整個技術生態在公司內相對成熟的多，維護成本較低。如數據修改能夠直接覆蓋最新值，很是簡單。
• Doris on ES在數據Scan上作了大量的優化操做，如列存、local優先、響應內容過濾、順序掃描、提早終止等，對於數據的掃描性能能夠達到~30w/s
• Doris 提供了更強大的Sql語法（如join、多列group by……），且整個查詢過程保障了數據的準確度。大大提升了數據使用的效率和數據查詢質量。
  • 因爲ES缺乏分佈式計算層，導致ES-Sql須要配置size，否則會導致返回的數據會少於預期的數據

固然，對於流量分析的場景，因爲指標列通常是pv、uv等，業務上並無對指標的篩選過濾需求，且Doris自身支持RollUP，所以很是適合流量類的查詢分析。

所以，經過Doris咱們統一了整個查詢引擎端的實現，這樣對於後續整個數倉的進一步建設就打下了很是重要的基礎。

應用實踐

基於業務場景，咱們對需求進行了分類：面向業務工做臺的非流量類需求以及流量分析類需求。

非流量類

在實際的應用中，業務側的需求主要分兩類：

• 明細查詢。教研工做臺須要關注每一個老師的明細信息，如某課程的學生的到課狀況、課前預習狀況……
• 聚合查詢。部門組織上會關注整個部門、小組內的統計信息，如到課率、拉新率等

這些需求在前端查詢，均須要保障低延遲。

而明細查詢對於數據的時效性要求更高，所以對於明細類查詢，業務側會直接訪問Doris on ES中的數據進行查詢，這樣基於Doris on ES的任意列檢索能力能夠保障業務查詢模式的靈活性以及數據的時鮮性。

而對於聚合查詢，因爲不一樣指標的Sql計算的數據範圍不一樣，且業務側對於聚合的計算沒有明細查詢的時效性，所以，咱們經過微批（如1min、5mins、10mins……）的調度能力按期計算聚合指標，並存放到ADS層的業務數據庫中供前端平臺查詢。

爲了提升數據使用效率，方便業務側得到特定時間窗口的數據，在數據模型上，咱們統一設置了Meta字段如數據更新時間，這樣業務能夠用來劃分每次更新的數據窗口，作增量計算。

這個模式的主要好處

• 業務端延遲可控、穩定性好。聚合查詢的延遲隨着具體的Sql不一樣而不一樣，按期執行後的數據存放到業務層Mysql中，能夠最大化能夠保證查詢延遲
• 數據修復成本低、維護方便。一旦數據有異常，能夠自動觸發對應的數據窗口進行從新計算
  • 原來基於流式計算的修數，須要從源頭修復，且必須驅動主流事件觸發，成本很是高，而基於doris on es，不一樣的事件能夠更新不一樣的列或者表，只要在數據查詢時join便可
• 高性能。通常業務每次讀取部分列，這個模式反而能夠發揮ES適合大寬表的場景以及Doris on ES列存讀取模式的實現，更保障了這快的高性能

流量類

對於流量，在數據清洗後，直接基於kafka入Doris便可，這塊主要是利用Doris RollUp的能力，提供低延遲的數據查詢能力

OneService

雖然上述能夠初步知足業務的需求，可是從站在最終系統可持續運維的目標態來看，還有不少潛在的問題須要提供解決的空間

• 如何保障查詢穩定性
  • 多個用戶Sql查詢，某個查詢致使集羣被打垮，如何快速止損
  • 多個場景都在查詢某一張表，如何作到可控的降級
• 如何保障入庫的數據質量
  • 避免數據亂序覆蓋……
  • 保障數據在多個庫之間的無損、低成本遷移……如從Hive遷移到Doris、ES遷移到Mysql……
• 如何提升易用性
  • 數倉內支持Sql的系統不少，如Hive的Hql、Flink-Sql……在部分函數語法上會因爲差別，如何透明的打平這些差別。而不是讓用戶不斷的學習異構語法
  • 數據若是跨雲同步，提供多集羣數據同步、查詢切換，如何對業務透明的完成
  • 部分表須要自動Rotate的能力，自動刪除過期的數據
  • ……

上述的這些問題雖然短時間內沒法一一解決，可是須要提供一個能力：未來解決時控制成本，儘可能作到對業務無感知。

這些都須要進一步定義出系統的接口邊界，不然耦合各個系統，後續使用的用戶越多，問題持續時間越久、遷移成本也越高。

所以咱們設計了OneModel來統一數據模型，而且構建了OpenAPI來統一服務接口。

目前完成的功能包括

• OpenAPI上
  • Sql緩存
  • 基於業務線的查詢條件控制，如query_timeout
• OneModel
  • 隨着Flink系統的引入，結合原離線數倉的表，數據表在不一樣存儲上分佈愈來愈多如Kafka、Redis、Doris、Hive……，所以構建<數據表，Schema，存儲>的元數據，支持數據表在不一樣存儲上的映射關係，統一表邏輯視圖，提高使用效率
  • 引入了Json-schema，保證入庫質量符合數據模型定義
• 其餘
  • Rotate Table
  • 規範化數據協議，基於數據版本解決數據寫入時亂序問題
  • ……

基於上述的設計，一方面支持業務功能的同時，更重要的是切分了整個系統的接口，來下降各個系統的耦合。有幾點具體的好處:

• 數據清洗系統和查詢系統基於Kafka解耦，這樣當查詢系統臨時異常時，不會阻塞計算系統。且多個Topic能夠自然支持正常數據流&修數數據流的同步入庫。
• 業務層經過統一的接口來進行數據訪問，在訪問入口處能夠統一方便的進行流量調度，統一的解決穩定性問題
• 因爲整個系統閉包，且接口基於數據協議耦合，穩定性和易用性獲得了兼顧

應用表現

基於Doris on ES的查詢系統上線數月，一直到經歷了運營大促的活動，均表現出了很是好的穩定性。天天百萬級次調用，99分位延遲~秒級

咱們的人效也獲得了了數十倍的提高：從過去一個需求「進入查詢系統到對外交付數據」須要數人周，提高到當前模式的小時級甚至分鐘級。

總結與規劃

經過引入doris，解決了咱們明細&聚合數據查詢不統一的問題，奠基了整個數據中臺在查詢側的基石，對於後續數倉向數據中臺發展的路徑起到了很是關鍵的做用。

規劃

• 跨集羣實時同步。在異地多活等場景下，目前缺乏類似mysql-binlog的實時同步能力，須要構建低成本的數據實時同步能力，支持在線業務的穩定性。
• Doris on ES多表Join性能。在長尾的需求下，Join須要掃描兩張表的所有數據進行內存計算，尤爲是大表Join大表，延遲就會升高。
• Doris on ES表分區能力。如對於ES的Rotate表，目前Doris沒法識別新表或者自動刪除老的表映射，須要頻繁創建Doris表來對應ES.Index。
• Doris on ES表自動同步能力。如ES表Schema修改後，能夠自動同步到Doris。
• Doris平臺化運維，如建表、修改表、數據導出…… 

更多Doris on ES的2020規劃，請參見：https://github.com/apache/incubator-doris/issues/3306

致謝

在此很是感謝百度Doris團隊特別是@wuyunfeng、@imay 等同窗熱情、給力、靠譜的技術支持！！！咱們也但願後續一塊兒參與到Doris的開發建設中來！

歡迎來撩！

在線教育屬於當前還在持續高速增加的業務賽道，做業幫做爲一家專一於K12的在線教育公司，當前已經累計激活用戶8億+，月活1.7億+。

做業幫大數據團隊致力於面向公司構建數據中臺，這裏能夠接觸到大數據下的分佈式計算、存儲等多種前沿的工程架構技術，歡迎各位感興趣的小夥伴來撩~

聯繫郵箱：milimin@zuoyebang.com