大數據分析的下一代的架構的思考

這些年隨著hadoop和大數據以及去IOE的流行，很多公司開始著手將第一代的BI系統遷往大數據平台。oracle裡邊的數據量越來越大，很多的報表已經無法通過oracle計算出來，而oracle成本地增加也促使他們開始追逐大數據的風。

第一代的IOTA的架構主要是lambda的架構，目前很多公司依然在往這條的道路上遷移。典型的Lambda架構主要解決兩個方面實時計算與離線計算。下圖是典型的Lambda的架構圖。

從上圖我們可以看到其實數據進入包含兩塊一個是類似傳統的BI比如資料庫的數據通過ETL的工具進入到大數據平台然後進行ETL的計算，另外的一塊主要是類似點擊流IOT等實時的數據通過流處理的工具進行計算。無論是實時計算還是離線的計算，最終用戶要拿到計算的結果都是通過結果資料庫提供給堆外的用戶系統去使用。

經過多年的實踐這一套方法已經在很多公司落地成熟，但是隨著數據量的越來越大這種問題也是越來越突出。

一般而言ETL計算的都是T+1的報表，大部分是在晚上12點鐘之後開始抽取相關資料庫的數據然後開始計算，當數據量越來越大的時候報表計算的時間就會變長，第二天早上看到報表的時間也會相應推遲甚至跑不出來。

實時在白天計算的數據跟T+1計算的數據有出入

數倉的架構必然會產生大量的中間表，這導致大數據平台數據集聚膨脹。

針對以上的問題Linkedin 提出了kappa的相關思想，希望通過流去統一相關的計算。

基本的架構圖如下稍微做了一些改動。

那如何用流計算系統對全量數據進行重新計算，步驟如下：

1、用Kafka或類似的分散式隊列保存數據，需要幾天數據量就保存幾天。

2、當需要全量計算時，重新起一個流計算實例，從頭開始讀取數據進行處理，並輸出到一個結果存儲中。

3、當新的實例完成後，停止老的流計算實例，並把老的一引起結果刪除。

這種方法的認可度很低，主要是有以下的缺點。

歷史數據和實時數據計算都通過流計算計算量太大，資源消耗太多

實時的計算嚴重依賴外部的redis等組件，資源消耗巨大

所以按照目前業界對數據的實時性越來越高的要求以及數據量越來越大的趨勢，我覺得未來應該是統一的計算模式，而不再分離線與實時的這種方式。具體的架構圖如下：

其實我們都知道當你要建立通用的實時流計算你必須統一處理格式，否則每來一種格式你就解析一下，這種服務與交互方式是無法想像的。原來資料庫的抽取的方式無非就是採用類似jdbc將數據select出來，這種方式一般都是T+1的方式，因為業務資料庫一般白天服務的時候不讓你動。那實時數據的獲取一般是通過log獲取如mysql的binlog與oracle的redolog。那為何不把這些傳輸的數據格式進行統一。同樣的點擊流，日誌的獲取方式也可以進行協議的統一。

如果實時的獲取數據不成問題那麼，接下來便是計算。通過相關的ad-hoc計算引擎對數據進行實時計算，並每隔一段時間將數據通過dumper將數據歸檔到歷史資料庫當中，可以在一張表下建實時和離線的目錄，ad-hoc可以自由選擇需要計算的區域。

除此之外其實我們知道目前的移動端和web端其實是具備一定的計算能力的，可以通過server對前端埋點的SDK計算配置，讓前端對相關的數據進行預計算。同樣的通過ad-hoc的計算結果也可以通過sdkserver推送回去進行實時的反饋。

其實目前已經有一些比較不錯的ad-hoc引擎在像這個方向上努力。筆者目前了解的有palo,indexR等。之後有時間可以深入剖析下ad-hoc引擎。雖然去ETL似乎還很遠，需求和渴望就在哪，技術的方向就在哪！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！