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

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

①?流式處理與批量處理

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

② Kudu痛點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 數(shù)倉分級

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

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

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

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

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

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

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

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

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

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