網易實時數倉實踐與展望

導讀: 隨着大數據技術的進步,各種計算框架的湧現,數據倉庫相關技術難題已經從離線數倉逐漸過渡到實時數倉,越來越多的企業對數據的實時性提出了嚴格的要求,如何滿足企業的低延時的數據需求,如何看待批量處理和實時處理的關係,實時數倉應該如何分級,各家可能都有自己的理解,本文主要介紹網易的實時計算平臺的建設實踐以及網易對於實時數倉方面的一些規劃及展望,希望能夠起到拋磚引玉的作用。

01 實時計算平臺實踐

1. 網易實時計算平臺:Sloth

網易的實時計算平臺Sloth譯成中文是樹懶的意思,繼承了網易喜歡用動物系命名大數據組件的風格,如果你看過《瘋狂動物城》,一定會對劇中的flash印象深刻。Sloth平臺的建設始於2017年12月份,至今已有3年的時間,期間平臺的彈性計算單元(ECU)規模一直呈現指數級增長,目前ECU已經突破50000個,運行的CPU數量已經達到15110核,內存超過了34T。

2. 平臺架構

從功能的角度來看,Sloth平臺主要分成兩大塊:

  • Admin:主要負責一些異步的服務,比如說任務的監控,告警,恢復和診斷。
  • Server:主要完成一些應用層面的服務,同時它也是一個無狀態的PAAS服務,既面向我們web的終端用戶,也面向大數據平臺內部的其他模塊。從功能上來看,它負責資源的管理,任務的開發及運維,同步事件的管理等任務。

從數據層面來看,我們實時數倉的架構主要分爲四個層面:

① Source層

關係型數據:NDC是公司專門處理關係型數據的組件,它會將mysql等關係型數據庫的binlog日誌解析成特殊的數據格式然後插入到我們的kafka消息隊列。

日誌型數據:datastream是公司的專門負責日誌收集的平臺,它會將收集的日誌信息插入到我們的消息隊列。

② 消息隊列

目前我們選用的是kafka。

③ 計算層

目前我們選用的是flink來完成數據的清洗,轉換及聚合。

④ Sink層

kudu是我們主推的存儲格式,kudu不僅可以提供一個高效的用於數據分析的列存格式,同時也支持數據實時的upsert及delete。當體量比較小的時候,也可以選用mysql或者redis這種可以實時變更的存儲組件。

3. 一站式實時計算開發IDE

我們主推的開發模式是sql模式,同時我們也支持jar包模式。

我們提供高度集成的IDE,支持代碼的離線調試,線上調試,版本管理,版本比對及配置管理。

4. 一站式實時任務運維

運維我們主要分爲三大版塊,分別是任務的運維,服務器監控及異常告警,下面我們分別看一下:

① 任務的運維

我們提供豐富的界面和菜單來支持任務的運維工作,通過頁面的菜單點擊我們可以輕鬆的查看任務信息,運行時的參數,高級的配置,運行記錄,操作記錄及運行日誌。

② 服務器壓力的監控

我們在grafana的基礎上進行了二次開發,圖形化的展示平臺的吞吐量,延遲,IO,QPS等關鍵信息。

③ 告警的設置

在Sloth平臺設置告警非常簡單,你可以在界面上配置多個規則,比如說任務失敗次數,數據延遲超多少閥值,報警間隔,告警的接收人,發送方式等。

5. 統一元數據中心

無論是離線數倉還是實時數倉,都需要做好元數據的管理工作,Sloth平臺也有統一的元數據中心,下面簡單介紹一下我們的元數據管理方式,元數據登記以及統一元數據所帶來的好處。

元數據管理

Hive metastore元數據管理體系是業界公認的標準,包括flink在1.10版本之後也開始打造自己的catalog機制,網易也遵循了這套邏輯,將數據統一分成了instance-> database -> table 的層級。

數據源登記

  • 對於關係型數據庫,本身就有schema信息,比如說mysql本身就有schema,database和table的概念,那麼我們只需要把mysql登記進來,賦予一個instance_name,那麼以後就可以通過instance_name.database.table 的方式來訪問。
  • 對於NOSQL類的數據源,有些數據源沒有database的概念,比如說hbase,我們可以指定一個default的database。
  • 對於消息隊列,本身沒有元數據,平臺本身提供一個default的catalog可以直接使用,同時用戶需要自定義database和table。

統一元數據所帶來的好處

  • 簡化了開發流程,節省了代碼量,規避了先定義DDL然後在定義DML的開發流程
  • 一次登記,多處複用
  • 允許字段發生變更,通過set設置屬性,可以實現相同的元數據在不同的任務中具有一定的多樣性

6. 其他工作

  • 混合部署,開展基於yarn和k8s的混合部署實踐,改善資源利用率
  • 上游整合:對上游的數據庫,只需要對數據庫地址做一次性登記,就可以將數據庫的表作爲批表和流表source和flink實現無縫接合。省去用戶在不同系統之間的跳轉
  • 自動伸縮:根據業務流量,數據量自動調整內存和併發度,以適配業務流量的峯谷模型。
  • 增強診斷功能,提升運維效率,減小運維壓力

02 實時數倉規劃與展望

1. 現狀及痛點分析

下面我們以一個百度熱詞統計案例來分析一下流式處理與批量處理的成本消耗及網易目前遇到的一個存儲痛點。

① 流式處理與批量處理

熟悉大數據的人都知道統計百度熱詞的過程相當於一個wordcount + topn 操作,這個任務既可以用spark跑批模式實現,也可以用flink流式計算實現,下面我們來分析一下跑批模式和流式計算模式完成這個統計的消耗情況。

跑批模式

流式計算模式

結果對比

② Kudu痛點

目前市面上的支持實時讀寫的大數據存儲基本上採用的都是PDT tree或者LSM tree這種數據結構,這種數據結構主要採用的是寫優化策略,首先數據會有一個基線版本,當對數據進行修改時,不會立即修改基線版本的數據,而是寫入一個新版本的數據,這種寫入是採用append的模式實現的,所以寫延遲非常低,那麼讀取的時候我們就需要合併多個版本的數據返回最新版本的數據,它的讀延遲就會比較高。所以爲了照顧到讀延遲問題,隔一段時間就需要執行一次合併版本的操作形成一個新的基線版本,這個過程叫compaction。這種機制會帶來一個問題,就是當一秒鐘之內發生大量的修改時,這時數據就會有很多個版本,compaction的過程就會帶來大量的cpu和內存消耗,這個問題我們稱之爲寫放大問題。

因爲compaction的存在,kudu成了一個存算不分離的存儲系統,它需要去綜合考慮寫延遲,讀延遲和compaction的性能,雖然他可以實時upsert或者delete,但是極端情況下它會遇到寫放大的問題,而且網易線上也確實經歷過這樣的事故。

③ 實時規模與成本的負相關

根據前面的分析,我們得到了一個結論:

  • 批計算的成本和數據體量是呈現線性關係的,因爲數據體量大的情況下,由於是順序IO,我們只需要增加機器就可以解決。
  • 而流計算的成本卻隨着數據體量的增長呈現指數級增長,原因是流式計算過程中會遇到隨機IO的問題,流式計算框架的checkpoint的瓶頸,存儲組件的寫放大問題,存算不分離的問題,以及小文件問題等等。

2. 展望:流批一體的配套存儲

基於之前的提出的這些問題,我們展望一下如何實現一個流批一體的配套存儲:

首先,我們需要實現存算分離,核心思路是

  • 把kudu的compaction操作從存儲端剝離出來。
  • 把compaction操作交給外部的定時調度來完成,比如說我們正在做的arctic服務,提供分鐘級甚至是小時級的調度,犧牲掉一部分的實時性,但是提高了服務的穩定性。拿百度熱詞這個例子,我們可以看出熱詞每秒鐘都在更新,但是我們沒有必要每秒鐘更新一下數據,我一分鐘更新一下數據完全是可以的。
  • 對於一些數據準確性特別高的,我們應該提供一種同步的compaction機制,在讀取數據的時候執行,比如說用flink讀取數據的時候執行compaction後再返回,這種情況我們稱之爲merge on read。
  • 同時也可以提供一個異步的compaction機制,這種情況下,你讀取的時候,讀取到的是上一次compaction執行完成之後的結果,這種情況我們稱之爲copy on write。

其次,我們應該提供一個流批一體的API

批量讀取的api其實很好解決,我們的hdfs上的存儲結構像parquet,kudu本身就是可以批量讀取的,那麼什麼是流式讀取的api呢?試想一下我們的消息隊列,像kafka提供了一個時間戳,我可以隨時回到這個時間戳對應的偏移,然後消費之後的數據,所以我們的想法是隻要我們給定一個起始時間就能增量的讀取某個時間點之後的數據就可以了,這個也類似mysql的binlog。

無論是批量的讀取還是流式的讀取,它們的存儲應該是同一套。

3. 數倉分級

我認爲數倉可以根據實時性的要求分成不同的等級:

  • 毫秒-秒級:實時性要求最高的等級,沒有調度延遲,我們把這種場景比喻成私家車,這種情況下,道路治理是最關鍵的,要避免堵車,結合我們的實時計算來講的話,私家車就是一個單獨的事件,處理過程中要防止產生數據堆積,該級別更加註重端到端的情況,通常是一個特定的任務或者路線。
  • 分鐘級:實時性高,有一定的調度延遲,我們把這種場景比喻成地鐵,吞吐量比私家車交通要更高,是一種小批量運輸,地鐵交通注重的是換乘和複用,注重優化線路和站點,就和我們的workflow比較類似。
  • 小時-天級:實時性要求低,調度延遲高,我們把這種場景比喻成高鐵,吞吐量大,執行速度最快的交通工具,你準備數據的時間可能超過真正執行的時間,這種就是我們傳統的離線數倉的模式。

最後概括一下,如果把數倉比喻成交通的話,實時數倉就好比是城市交通,離線數倉就好比是城際交通。

4. 實時數倉trade off

在構建實時數倉時,我們通常需要考慮三個重要的環節:

  • 實時性,這個需要根據業務來確定延遲的等級,是秒級呢?還是分鐘級?
  • 可用性,因爲越高的實時性意味着對可用性的要求越高,對異常恢復的時間要求更短,比如說百度詞條的案例,你的實時性要求如果是分鐘級的,那麼你發生故障了,一分鐘內恢復不會產生太大的問題,但是如果是秒級的話,一分鐘可能就會釀成事故。同時低延遲的這種隨機IO更容易造成文件碎片化的問題,所以我們需要對小文件進行一個治理;在可用性方面,緩衝能力也尤爲重要,我們的系統總會出現一定的峯值,比如說雙十一0點的時候,流量可能是一年的峯值,但是出於成本考慮,我們不可能根據峯值無限的擴容,因此我們要具備很強大的消息緩衝能力。
  • 成本,實時計算的成本與數據體量是呈指數級增長的,其中一個主要的原因就是寫放大問題,爲了解決寫放大問題,我們展望了一個存算分離的存儲體系,降低compaction的頻率,並提供流批一體的API來提升效能。

03 總結

本文主要講述了網易的實時數倉的產品形態,並結合實際的案例分析了網易實時數倉目前面臨的難點,一方面剖析了批計算與流計算各自的消耗情況,一方面剖析了現有存儲體系的存算不分離問題,從而得出流計算的成本隨數據體量呈指數級增長的結論,緊接着我們提出了一種存算分離且批流一體的存儲架構,通過剝離compaction,把compaction交給外部服務或者計算框架來實現存算分離,以及提供統一的API來同時支持批計算和流計算,最後我們淺談了數據倉庫的等級劃分以及建設實時數倉時需要考量的三個重要環節。

今天的分享就到這裏,謝謝大家。

作者介紹

馬進,網易杭研技術專家

馬進,網易杭研技術專家、網易流計算團隊負責人。負責網易數據庫中間件、數倉團隊,主導數據庫中間件的各類項目研發,曾先後參與分佈式數據庫DDB,緩存NKV,分佈式事務協調器TCC,數據運河NDC等項目。專注於分佈式系統架構與數據庫技術,熱衷於構建高效的,高性能的分佈式後臺系統。

本文來自 DataFunTalk

原文鏈接

網易實時數倉實踐與展望

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章