分享嘉賓：馬進 網易杭研 技術專家

編輯整理：張滿意

出品平臺：DataFunTalk

導讀：隨著大數據技術的進步，各種計算框架的涌現，數據倉庫相關技術難題已經從離線數倉逐漸過渡到實時數倉，越來越多的企業對數據的實時性提出了嚴格的要求，如何滿足企業的低延時的數據需求，如何看待批量處理和實時處理的關系，實時數倉應該如何分級，各家可能都有自己的理解，本文主要介紹網易的實時計算平臺的建設實踐以及網易對于實時數倉方面的一些規劃及展望，希望能夠起到拋磚引玉的作用。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來同時支持批計算和流計算，最后我們淺談了數據倉庫的等級劃分以及建設實時數倉時需要考量的三個重要環節。

今天的分享就到這里，謝謝大家。

---

在文末分享、點贊、在看，給個三連擊唄~~

寫在最后：

另外，還有一些朋友一直在問，數據倉庫、數據湖、數據中臺都有啥區別啊？這些也都很火啊，能不能講講？這些也早已分享過了，

點擊查看：辨析數倉、大數據、數據中臺的實質(內附21張架構圖)，數據庫、數據倉庫、數據湖、數據中臺全給你講清楚了。

點擊查看：漫談 | 大牛帶你從0到1構建數據倉庫實戰，給你完整的數倉建設流程。

點擊查看：系列 | 漫談數倉第二篇NO.2 數據模型(維度建模)，給你所有建模方法。

點擊查看：數據倉庫(離線+實時)大廠優秀案例匯總(建議收藏)，給你業務梳理、指標體系梳理、維度梳理、事實表梳理、命名規范、數據倉庫設計文檔，外加數倉維度建模電子書和大廠數倉建設實戰經驗。

升職加薪，天天開心！

您的在看和轉發是對我們最大的支持，O(∩_∩)O:

往期精彩回顧

往期推薦

數據湖VS數據倉庫之爭？阿里提出大數據架構新概念：湖倉一體！

深度 | 一文帶你了解Hadoop大數據原理與架構(文末贈書)

詳解數據倉庫的實施步驟

進階 ｜Hive 復雜數據類型

Flink系列 - 實時數倉之ETL實戰(二)

Flink系列 - 實時數倉之熱門商品統計-TopN(三)

歡迎加入?數倉中臺交流群，跟同行零距離交流。如想進群，請加v：iom1128，備注：數倉，審核通過自主入群。

入群請聯系小助手：iom1128『紫霞仙子』

！關注不迷路~ 各種福利、資源定期分享！

如果你覺得有用，就請幫忙分享一下，碼字不易，我需要您的鼓勵！ 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的数仓 调度_网易实时数仓实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。