iota

IOTA大數據架構是一種基於AI生態下的全新的數據架構模式，2018年，易觀首次提出這一概念。IOTA的整體思路是設定標準數據模型，通過邊緣計算技術把所有的計算過程分散在數據產生、計算和查詢過程當中，以統一的數據模型貫穿始終，從而提高整體的計算效率，同時滿足計算的需要，可以使用各種Ad-hoc Query來查詢底層數據。

貫穿整體業務始終的數據模型，這個模型是整個業務的核心，要保持SDK、cache、歷史數據、查詢引擎保持一致。對於用户數據分析來講可以定義為“主-謂-賓”或者“對象-事件”這樣的抽象模型來滿足各種各樣的查詢。以大家熟悉的APP用户模型為例，用“主-謂-賓”模型描述就是“X用户–事件1 – A頁面（2018/4/11 20:00）”。當然，根據業務需求的不同，也可以使用“產品-事件”、“地點-時間”模型等等。模型本身也可以根據協議（例如protobuf）來實現SDK端定義，中央存儲的方式。此處核心是，從SDK到存儲到處理是統一的一個Common Data Model。

這是數據的採集端，不僅僅是過去的簡單的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頁面來講，沒有計算工作量，只要求埋點格式即可。

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

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

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

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

通過Edge computing技術，在邊緣端有更多的交互可以做，可以通過在Realtime Data去設定規則來對EdgeSDK端進行控制，例如，數據上傳的頻次降低、語音控制的迅速反饋，某些條件和規則的觸發等等。簡單的事件處理，將通過本地的IOT端完成，例如，嫌疑犯的識別已經有很多攝像頭本身帶有此功能。 ^[1] 

ETL和相關開發一直是大數據處理的痛點，IOTA架構通過Common Data Model的設計，專注在某一個具體領域的數據計算，從而可以從SDK端開始計算，中央端只做採集、建立索引和查詢，提高整體數據分析的效率。

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

將過去統一到中央進行整體計算，分散到數據產生、存儲和查詢端，數據產生既符合Common Data Model。同時，也給與Realtime model feedback，讓客户端傳送數據的同時馬上進行反饋，而不需要所有事件都要到中央端處理之後再進行下發。 ^[1] 

在大數據3.0時代，Lambda大數據架構已經無法滿足企業用户日常大數據分析和精益運營的需要，去ETL化的IOTA大數據架構才是未來。 ^[1]