分享嘉賓：馬進(jìn) 網(wǎng)易杭研 技術(shù)專家

編輯整理：張滿意

出品平臺：DataFunTalk

導(dǎo)讀：隨著大數(shù)據(jù)技術(shù)的進(jìn)步，各種計算框架的涌現(xiàn)，數(shù)據(jù)倉庫相關(guān)技術(shù)難題已經(jīng)從離線數(shù)倉逐漸過渡到實時數(shù)倉，越來越多的企業(yè)對數(shù)據(jù)的實時性提出了嚴(yán)格的要求，如何滿足企業(yè)的低延時的數(shù)據(jù)需求，如何看待批量處理和實時處理的關(guān)系，實時數(shù)倉應(yīng)該如何分級，各家可能都有自己的理解，本文主要介紹網(wǎng)易的實時計算平臺的建設(shè)實踐以及網(wǎng)易對于實時數(shù)倉方面的一些規(guī)劃及展望，希望能夠起到拋磚引玉的作用。01實時計算平臺實踐

1. 網(wǎng)易實時計算平臺：Sloth

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

2.?平臺架構(gòu)

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

• Admin：主要負(fù)責(zé)一些異步的服務(wù)，比如說任務(wù)的監(jiān)控，告警，恢復(fù)和診斷。

• Server：主要完成一些應(yīng)用層面的服務(wù)，同時它也是一個無狀態(tài)的PAAS服務(wù)，既面向我們web的終端用戶，也面向大數(shù)據(jù)平臺內(nèi)部的其他模塊。從功能上來看，它負(fù)責(zé)資源的管理，任務(wù)的開發(fā)及運維，同步事件的管理等任務(wù)。

從數(shù)據(jù)層面來看，我們實時數(shù)倉的架構(gòu)主要分為四個層面：

① Source層

關(guān)系型數(shù)據(jù)：NDC是公司專門處理關(guān)系型數(shù)據(jù)的組件，它會將mysql等關(guān)系型數(shù)據(jù)庫的binlog日志解析成特殊的數(shù)據(jù)格式然后插入到我們的kafka消息隊列。

日志型數(shù)據(jù)：datastream是公司的專門負(fù)責(zé)日志收集的平臺，它會將收集的日志信息插入到我們的消息隊列。

② 消息隊列

目前我們選用的是kafka。

③ 計算層

目前我們選用的是flink來完成數(shù)據(jù)的清洗，轉(zhuǎn)換及聚合。

④ Sink層

kudu是我們主推的存儲格式，kudu不僅可以提供一個高效的用于數(shù)據(jù)分析的列存格式，同時也支持?jǐn)?shù)據(jù)實時的upsert及delete。當(dāng)體量比較小的時候，也可以選用mysql或者redis這種可以實時變更的存儲組件。

3.?一站式實時計算開發(fā)IDE

我們主推的開發(fā)模式是sql模式，同時我們也支持jar包模式。

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

4.?一站式實時任務(wù)運維

運維我們主要分為三大版塊，分別是任務(wù)的運維，服務(wù)器監(jiān)控及異常告警，下面我們分別看一下：

① 任務(wù)的運維

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

② 服務(wù)器壓力的監(jiān)控

我們在grafana的基礎(chǔ)上進(jìn)行了二次開發(fā)，圖形化的展示平臺的吞吐量，延遲，IO，QPS等關(guān)鍵信息。

③ 告警的設(shè)置

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

5.?統(tǒng)一元數(shù)據(jù)中心

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

元數(shù)據(jù)管理：

Hive metastore元數(shù)據(jù)管理體系是業(yè)界公認(rèn)的標(biāo)準(zhǔn)，包括flink在1.10版本之后也開始打造自己的catalog機制，網(wǎng)易也遵循了這套邏輯，將數(shù)據(jù)統(tǒng)一分成了instance-> database -> table 的層級。

數(shù)據(jù)源登記：

• 對于關(guān)系型數(shù)據(jù)庫，本身就有schema信息，比如說mysql本身就有schema，database和table的概念，那么我們只需要把mysql登記進(jìn)來，賦予一個instance_name，那么以后就可以通過instance_name.database.table 的方式來訪問。

• 對于NOSQL類的數(shù)據(jù)源，有些數(shù)據(jù)源沒有database的概念，比如說hbase，我們可以指定一個default的database。

• 對于消息隊列，本身沒有元數(shù)據(jù)，平臺本身提供一個default的catalog可以直接使用，同時用戶需要自定義database和table。

統(tǒng)一元數(shù)據(jù)所帶來的好處：

• 簡化了開發(fā)流程，節(jié)省了代碼量，規(guī)避了先定義DDL然后在定義DML的開發(fā)流程

• 一次登記，多處復(fù)用

• 允許字段發(fā)生變更，通過set設(shè)置屬性，可以實現(xiàn)相同的元數(shù)據(jù)在不同的任務(wù)中具有一定的多樣性

6.?其他工作

• 混合部署，開展基于yarn和k8s的混合部署實踐，改善資源利用率

• 上游整合：對上游的數(shù)據(jù)庫，只需要對數(shù)據(jù)庫地址做一次性登記，就可以將數(shù)據(jù)庫的表作為批表和流表source和flink實現(xiàn)無縫接合。省去用戶在不同系統(tǒng)之間的跳轉(zhuǎn)

• 自動伸縮：根據(jù)業(yè)務(wù)流量，數(shù)據(jù)量自動調(diào)整內(nèi)存和并發(fā)度，以適配業(yè)務(wù)流量的峰谷模型。

• 增強診斷功能，提升運維效率，減小運維壓力

02實時數(shù)倉規(guī)劃與展望

1. 現(xiàn)狀及痛點分析

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

①?流式處理與批量處理

熟悉大數(shù)據(jù)的人都知道統(tǒng)計百度熱詞的過程相當(dāng)于一個wordcount + topn 操作，這個任務(wù)既可以用spark跑批模式實現(xiàn)，也可以用flink流式計算實現(xiàn)，下面我們來分析一下跑批模式和流式計算模式完成這個統(tǒng)計的消耗情況。

跑批模式：

流式計算模式：

結(jié)果對比：

② Kudu痛點

目前市面上的支持實時讀寫的大數(shù)據(jù)存儲基本上采用的都是PDT tree或者LSM tree這種數(shù)據(jù)結(jié)構(gòu)，這種數(shù)據(jù)結(jié)構(gòu)主要采用的是寫優(yōu)化策略，首先數(shù)據(jù)會有一個基線版本，當(dāng)對數(shù)據(jù)進(jìn)行修改時，不會立即修改基線版本的數(shù)據(jù)，而是寫入一個新版本的數(shù)據(jù)，這種寫入是采用append的模式實現(xiàn)的，所以寫延遲非常低，那么讀取的時候我們就需要合并多個版本的數(shù)據(jù)返回最新版本的數(shù)據(jù)，它的讀延遲就會比較高。所以為了照顧到讀延遲問題，隔一段時間就需要執(zhí)行一次合并版本的操作形成一個新的基線版本，這個過程叫compaction。這種機制會帶來一個問題，就是當(dāng)一秒鐘之內(nèi)發(fā)生大量的修改時，這時數(shù)據(jù)就會有很多個版本，compaction的過程就會帶來大量的cpu和內(nèi)存消耗，這個問題我們稱之為寫放大問題。

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

③ 實時規(guī)模與成本的負(fù)相關(guān)

根據(jù)前面的分析，我們得到了一個結(jié)論：

• 批計算的成本和數(shù)據(jù)體量是呈現(xiàn)線性關(guān)系的，因為數(shù)據(jù)體量大的情況下，由于是順序IO，我們只需要增加機器就可以解決。

• 而流計算的成本卻隨著數(shù)據(jù)體量的增長呈現(xiàn)指數(shù)級增長，原因是流式計算過程中會遇到隨機IO的問題，流式計算框架的checkpoint的瓶頸，存儲組件的寫放大問題，存算不分離的問題，以及小文件問題等等。

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

基于之前的提出的這些問題，我們展望一下如何實現(xiàn)一個流批一體的配套存儲：

首先，我們需要實現(xiàn)存算分離，核心思路是：

• 把kudu的compaction操作從存儲端剝離出來。

• 把compaction操作交給外部的定時調(diào)度來完成，比如說我們正在做的arctic服務(wù)，提供分鐘級甚至是小時級的調(diào)度，犧牲掉一部分的實時性，但是提高了服務(wù)的穩(wěn)定性。拿百度熱詞這個例子，我們可以看出熱詞每秒鐘都在更新，但是我們沒有必要每秒鐘更新一下數(shù)據(jù)，我一分鐘更新一下數(shù)據(jù)完全是可以的。

• 對于一些數(shù)據(jù)準(zhǔn)確性特別高的，我們應(yīng)該提供一種同步的compaction機制，在讀取數(shù)據(jù)的時候執(zhí)行，比如說用flink讀取數(shù)據(jù)的時候執(zhí)行compaction后再返回，這種情況我們稱之為merge on read。

• 同時也可以提供一個異步的compaction機制，這種情況下，你讀取的時候，讀取到的是上一次compaction執(zhí)行完成之后的結(jié)果，這種情況我們稱之為copy on write。

其次，我們應(yīng)該提供一個流批一體的API：

批量讀取的api其實很好解決，我們的hdfs上的存儲結(jié)構(gòu)像parquet，kudu本身就是可以批量讀取的，那么什么是流式讀取的api呢？試想一下我們的消息隊列，像kafka提供了一個時間戳，我可以隨時回到這個時間戳對應(yīng)的偏移，然后消費之后的數(shù)據(jù)，所以我們的想法是只要我們給定一個起始時間就能增量的讀取某個時間點之后的數(shù)據(jù)就可以了，這個也類似mysql的binlog。

無論是批量的讀取還是流式的讀取，它們的存儲應(yīng)該是同一套。

3. 數(shù)倉分級

我認(rèn)為數(shù)倉可以根據(jù)實時性的要求分成不同的等級：

• 毫秒-秒級：實時性要求最高的等級，沒有調(diào)度延遲，我們把這種場景比喻成私家車，這種情況下，道路治理是最關(guān)鍵的，要避免堵車，結(jié)合我們的實時計算來講的話，私家車就是一個單獨的事件，處理過程中要防止產(chǎn)生數(shù)據(jù)堆積，該級別更加注重端到端的情況，通常是一個特定的任務(wù)或者路線。

• 分鐘級：實時性高，有一定的調(diào)度延遲，我們把這種場景比喻成地鐵，吞吐量比私家車交通要更高，是一種小批量運輸，地鐵交通注重的是換乘和復(fù)用，注重優(yōu)化線路和站點，就和我們的workflow比較類似。

• 小時-天級：實時性要求低，調(diào)度延遲高，我們把這種場景比喻成高鐵，吞吐量大，執(zhí)行速度最快的交通工具，你準(zhǔn)備數(shù)據(jù)的時間可能超過真正執(zhí)行的時間，這種就是我們傳統(tǒng)的離線數(shù)倉的模式。

最后概括一下，如果把數(shù)倉比喻成交通的話，實時數(shù)倉就好比是城市交通，離線數(shù)倉就好比是城際交通。

4. 實時數(shù)倉trade off

在構(gòu)建實時數(shù)倉時，我們通常需要考慮三個重要的環(huán)節(jié)：

• 實時性，這個需要根據(jù)業(yè)務(wù)來確定延遲的等級，是秒級呢？還是分鐘級？

• 可用性，因為越高的實時性意味著對可用性的要求越高，對異常恢復(fù)的時間要求更短，比如說百度詞條的案例，你的實時性要求如果是分鐘級的，那么你發(fā)生故障了，一分鐘內(nèi)恢復(fù)不會產(chǎn)生太大的問題，但是如果是秒級的話，一分鐘可能就會釀成事故。同時低延遲的這種隨機IO更容易造成文件碎片化的問題，所以我們需要對小文件進(jìn)行一個治理；在可用性方面，緩沖能力也尤為重要，我們的系統(tǒng)總會出現(xiàn)一定的峰值，比如說雙十一0點的時候，流量可能是一年的峰值，但是出于成本考慮，我們不可能根據(jù)峰值無限的擴容，因此我們要具備很強大的消息緩沖能力。

• 成本，實時計算的成本與數(shù)據(jù)體量是呈指數(shù)級增長的，其中一個主要的原因就是寫放大問題，為了解決寫放大問題，我們展望了一個存算分離的存儲體系，降低compaction的頻率，并提供流批一體的API來提升效能。

03總結(jié)

本文主要講述了網(wǎng)易的實時數(shù)倉的產(chǎn)品形態(tài)，并結(jié)合實際的案例分析了網(wǎng)易實時數(shù)倉目前面臨的難點，一方面剖析了批計算與流計算各自的消耗情況，一方面剖析了現(xiàn)有存儲體系的存算不分離問題，從而得出流計算的成本隨數(shù)據(jù)體量呈指數(shù)級增長的結(jié)論，緊接著我們提出了一種存算分離且批流一體的存儲架構(gòu)，通過剝離compaction，把compaction交給外部服務(wù)或者計算框架來實現(xiàn)存算分離，以及提供統(tǒng)一的API來同時支持批計算和流計算，最后我們淺談了數(shù)據(jù)倉庫的等級劃分以及建設(shè)實時數(shù)倉時需要考量的三個重要環(huán)節(jié)。

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

---

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

寫在最后：

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

點擊查看：辨析數(shù)倉、大數(shù)據(jù)、數(shù)據(jù)中臺的實質(zhì)(內(nèi)附21張架構(gòu)圖)，數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)湖、數(shù)據(jù)中臺全給你講清楚了。

點擊查看：漫談 | 大牛帶你從0到1構(gòu)建數(shù)據(jù)倉庫實戰(zhàn)，給你完整的數(shù)倉建設(shè)流程。

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

點擊查看：數(shù)據(jù)倉庫(離線+實時)大廠優(yōu)秀案例匯總(建議收藏)，給你業(yè)務(wù)梳理、指標(biāo)體系梳理、維度梳理、事實表梳理、命名規(guī)范、數(shù)據(jù)倉庫設(shè)計文檔，外加數(shù)倉維度建模電子書和大廠數(shù)倉建設(shè)實戰(zhàn)經(jīng)驗。

升職加薪，天天開心！

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

往期精彩回顧

往期推薦

數(shù)據(jù)湖VS數(shù)據(jù)倉庫之爭？阿里提出大數(shù)據(jù)架構(gòu)新概念：湖倉一體！

深度 | 一文帶你了解Hadoop大數(shù)據(jù)原理與架構(gòu)(文末贈書)

詳解數(shù)據(jù)倉庫的實施步驟

進(jìn)階 ｜Hive 復(fù)雜數(shù)據(jù)類型

Flink系列 - 實時數(shù)倉之ETL實戰(zhàn)(二)

Flink系列 - 實時數(shù)倉之熱門商品統(tǒng)計-TopN(三)

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

入群請聯(lián)系小助手：iom1128『紫霞仙子』

！關(guān)注不迷路~ 各種福利、資源定期分享！

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。