網(wǎng)易實(shí)時(shí)數(shù)倉(cāng)實(shí)踐與展望

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

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

①?流式處理與批量處理

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

② Kudu痛點(diǎn)

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

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

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

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

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

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

2. 展望：流批一體的配套存儲(chǔ)

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

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

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

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

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

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

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

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

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

3. 數(shù)倉(cāng)分級(jí)

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

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

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

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

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

4. 實(shí)時(shí)數(shù)倉(cāng)trade off

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

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

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

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