大數據分析的下一代架構--IOTA

IOTA是什麼？你是否爲下一代大數據架構作好準備？

通過這麼多年的發展，已經從大數據1.0的BI/Datawarehouse時代，通過大數據2.0的Web/APP過渡，進入到了IOT的大數據3.0時代，而隨之而來的是數據架構的變化。

▌Lambda架構

在過去Lambda數據架構成爲每個公司大數據平臺必備的架構，它解決了一個公司大數據批量離線處理和實時數據處理的需求。一個典型的Lambda架構以下：

數據從底層的數據源開始，通過各類各樣的格式進入大數據平臺，在大數據平臺中通過Kafka、Flume等數據組件進行收集，而後分紅兩條線進行計算。一條線是進入流式計算平臺（例如 Storm、Flink或者Spark Streaming），去計算實時的一些指標；另外一條線進入批量數據處理離線計算平臺（例如Mapreduce、Hive，Spark SQL），去計算T+1的相關業務指標，這些指標須要隔日才能看見。

Lambda架構經歷多年的發展，其優勢是穩定，對於實時計算部分的計算成本可控，批量處理能夠用晚上的時間來總體批量計算，這樣把實時計算和離線計算高峯分開，這種架構支撐了數據行業的早期發展，可是它也有一些致命缺點，並在大數據3.0時代愈來愈不適應數據分析業務的需求。缺點以下：

● 實時與批量計算結果不一致引發的數據口徑問題：由於批量和實時計算走的是兩個計算框架和計算程序，算出的結果每每不一樣，常常看到一個數字當天看是一個數據，次日看昨天的數據反而發生了變化。

● 批量計算在計算窗口內沒法完成：在IOT時代，數據量級愈來愈大，常常發現夜間只有四、5個小時的時間窗口，已經沒法完成白天20多個小時累計的數據，保證早上上班前準時出數據已成爲每一個大數據團隊頭疼的問題。

●數據源變化都要從新開發，開發週期長：每次數據源的格式變化，業務的邏輯變化都須要針對ETL和Streaming作開發修改，總體開發週期很長，業務反應不夠迅速。

● 服務器存儲大：數據倉庫的典型設計，會產生大量的中間結果表，形成數據急速膨脹，加大服務器存儲壓力。

▌Kappa架構

針對Lambda架構的須要維護兩套程序等以上缺點，LinkedIn的Jay Kreps結合實際經驗和我的體會提出了Kappa架構。Kappa架構的核心思想是經過改進流計算系統來解決數據全量處理的問題，使得實時計算和批處理過程使用同一套代碼。此外Kappa架構認爲只有在有必要的時候纔會對歷史數據進行重複計算，而若是須要重複計算時，Kappa架構下能夠啓動不少個實例進行重複計算。

一個典型的Kappa架構以下圖所示：

Kappa架構的核心思想，包括如下三點：

1.用Kafka或者相似MQ隊列系統收集各類各樣的數據，你須要幾天的數據量就保存幾天。

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

3.當新的實例作完後，中止老的流計算實例，並把老的一些結果刪除。

Kappa架構的優勢在於將實時和離線代碼統一塊兒來，方便維護並且統一了數據口徑的問題。而Kappa的缺點也很明顯：

● 流式處理對於歷史數據的高吞吐量力不從心：全部的數據都經過流式計算，即使經過加大併發實例數亦很難適應IOT時代對數據查詢響應的即時性要求。

● 開發週期長：此外Kappa架構下因爲採集的數據格式的不統一，每次都須要開發不一樣的Streaming程序，致使開發週期長。

● 服務器成本浪費：Kappa架構的核心原理依賴於外部高性能存儲redis,hbase服務。可是這2種系統組件，又並不是設計來知足全量數據存儲設計，對服務器成本嚴重浪費。

▌IOTA架構

而在IOT大潮下，智能手機、PC、智能硬件設備的計算能力愈來愈強，而業務需求要求數據實時響應需求能力也愈來愈強，過去傳統的中心化、非實時化數據處理的思路已經不適應如今的大數據分析需求，我提出新一代的大數據IOTA架構來解決上述問題，總體思路是設定標準數據模型，經過邊緣計算技術把全部的計算過程分散在數據產生、計算和查詢過程中，以統一的數據模型貫穿始終，從而提升總體的預算效率，同時知足即時計算的須要，可使用各類Ad-hoc Query來查詢底層數據：

IOTA總體技術結構分爲幾部分：

● Common Data Model：貫穿總體業務始終的數據模型，這個模型是整個業務的核心，要保持SDK、cache、歷史數據、查詢引擎保持一致。對於用戶數據分析來說能夠定義爲「主-謂-賓」或者「對象-事件」這樣的抽象模型來知足各類各樣的查詢。以你們熟悉的APP用戶模型爲例，用「主-謂-賓」模型描述就是「X用戶 – 事件1 – A頁面（2018/4/11 20:00） 」。固然，根據業務需求的不一樣，也可使用「產品-事件」、「地點-時間」模型等等。模型自己也能夠根據協議（例如 protobuf）來實現SDK端定義，中央存儲的方式。此處核心是，從SDK到存儲處處理是統一的一個Common Data Model。

● Edge SDKs & Edge Servers：這是數據的採集端，不只僅是過去的簡單的SDK，在複雜的計算狀況下，會賦予SDK更復雜的計算，在設備端就轉化爲造成統一的數據模型來進行傳送。例如對於智能Wi-Fi採集的數據，從AC端就變爲「X用戶的MAC 地址-出現- A樓層（2018/4/11 18:00）」這種主-謂-賓結構，對於攝像頭會經過Edge AI Server，轉化成爲「X的Face特徵- 進入- A火車站（2018/4/11 20:00）」。也能夠是上面提到的簡單的APP或者頁面級別的「X用戶 – 事件1 – A頁面（2018/4/11 20:00） 」，對於APP和H5頁面來說，沒有計算工做量，只要求埋點格式便可。

● Real Time Data：實時數據緩存區，這部分是爲了達到實時計算的目的，海量數據接收不可能海量實時入歷史數據庫，那樣會出現創建索引延遲、歷史數據碎片文件等問題。所以，有一個實時數據緩存區來存儲最近幾分鐘或者幾秒鐘的數據。這塊可使用Kudu或者Hbase等組件來實現。這部分數據會經過Dumper來合併到歷史數據當中。此處的數據模型和SDK端數據模型是保持一致的，都是Common Data Model，例如「主-謂-賓」模型。

● Historical Data：歷史數據沉浸區，這部分是保存了大量的歷史數據，爲了實現Ad-hoc查詢，將自動創建相關索引提升總體歷史數據查詢效率，從而實現秒級複雜查詢百億條數據的反饋。例如可使用HDFS存儲歷史數據，此處的數據模型依然SDK端數據模型是保持一致的Common Data Model。

● Dumper：Dumper的主要工做就是把最近幾秒或者幾分鐘的實時數據，根據匯聚規則、創建索引，存儲到歷史存儲結構當中，可使用map reduce、C、Scala來撰寫，把相關的數據從Realtime Data區寫入Historical Data區。

● Query Engine：查詢引擎，提供統一的對外查詢接口和協議（例如SQL JDBC），把Realtime Data和Historical Data合併到一塊兒查詢，從而實現對於數據實時的Ad-hoc查詢。例如常見的計算引擎可使用presto、impala、clickhouse等。

● Realtime model feedback：經過Edge computing技術，在邊緣端有更多的交互能夠作，能夠經過在Realtime Data去設定規則來對Edge SDK端進行控制，例如，數據上傳的頻次下降、語音控制的迅速反饋，某些條件和規則的觸發等等。簡單的事件處理，將經過本地的IOT端完成，例如，嫌疑犯的識別如今已經有不少攝像頭自己帶有此功能。

IOTA大數據架構，主要有以下幾個特色：

● 去ETL化：ETL和相關開發一直是大數據處理的痛點，IOTA架構經過Common Data Model的設計，專一在某一個具體領域的數據計算，從而能夠從SDK端開始計算，中央端只作採集、創建索引和查詢，提升總體數據分析的效率。

● Ad-hoc即時查詢：鑑於總體的計算流程機制，在手機端、智能IOT事件發生之時，就能夠直接傳送到雲端進入real time data區，能夠被前端的Query Engine來查詢。此時用戶可使用各類各樣的查詢，直接查到前幾秒發生的事件，而不用在等待ETL或者Streaming的數據研發和處理。

● 邊緣計算（Edge-Computing）：將過去統一到中央進行總體計算，分散到數據產生、存儲和查詢端，數據產生既符合Common Data Model。同時，也給與Realtime model feedback，讓客戶端傳送數據的同時立刻進行反饋，而不須要全部事件都要到中央端處理以後再進行下發。

如上圖，IOTA架構有各類各樣的實現方法，爲了驗證IOTA架構，易觀也自主設計並實現了「秒算」引擎，目前支持易觀內部月活5.5億設備端進行計算的同時，也基於「秒算」引擎研發出了能夠獨立部署在企業客戶內，進行數字用戶分析和營銷的「易觀方舟」，能夠訪問ark.analysys.cn進行體驗。

在大數據3.0時代，Lambda大數據架構已經沒法知足企業用戶平常大數據分析和精益運營的須要，去ETL化的IOTA大數據架構纔是將來。