IOTA大數據架構是一種基於AI生態下的全新的數據架構模式，2018年，易觀首次提出這一概念。IOTA的整體思路是設定標准數據模型，通過邊緣計算技術把所有的計算過程分散在數據產生、計算和查詢過程當中，以統一的數據模型貫穿始終，從而提高整體的計算效率，同時滿足計算的需要，可以使用各種Ad-hoc Query來查詢底層數據。
IOT大潮下，智能手機、PC、智能硬件設備的計算能力越來越強，業務要求數據有實時的響應能力，Lambda架構已經不能適應當今大數據分析時代的需求。IOTA架構如下圖：
IOTA架構 --- 數據流轉過程示例
Common Data Model
- 貫穿整體業務始終的數據模型，這個模型是整個業務的核心，要保持SDK、cache、歷史數據、查詢引擎保持一致。
- 對於用戶數據分析來講可以定義為“主-謂-賓”或者“對象-事件”這樣的抽象模型來滿足各種各樣的查詢。
用戶行為“主-謂-賓”模型示例：
- 智能手表：X用戶 – 進行了 – 游泳運動
- 視頻APP：X用戶 – 播放 – 影片
- 電商網站：X用戶 – 購買 – 手機（ 2018/12/11 18:00:00 ， IP ， GPS）
用戶行為“對象-事件”模型
- 事件(Event)：主要是描述用戶做了什么事情，記錄用戶觸發的行為，例如注冊、登錄、支付事件等等
- 事件屬性： 更精准的描述用戶行為，例如事件發生的位置、方式和內容
- 每一條event數據對應用戶的一次行為信息， 例如瀏覽、登錄、搜索事件等等
--- 當然，根據業務需求的不同，也可以使用“產品-事件”、“地點-時間”模型等等。模型本身也可以根據協議（例如 protobuf）來實現SDK端定義，中央存儲的方式。此處核心是，從SDK到存儲到處理是統一的一個Common Data Model。
Edge SDK
- 這是數據的采集端，不僅僅是過去的簡單的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頁面來講，沒有計算工作量，只要求埋點格式即可。
一個穩定的數據采集端需要有如下功能，存儲、回數、控制、保護:
- 存儲：數據存儲，校驗當前存儲數據合法性，及防止數據被第三方篡改
- 回數：數據上報，加密上報數據，防止被第三方截取，保證不受 HOOK 等影響，防止 DNS 污染等。
- 控制：控制發送策略，可以指定 3G / 4G / wifi 環境上傳，可以調整上報時間頻次、本地數據緩存規則全部可動態調整
- 保護：有自保護機制。不要影響用戶的正常使用，減少因逆向導致的數據異常
顯而易見，普通的采集端都具有這些功能。作為 IOTA 架構下的采集端進行了哪些優化呢？如下:
- 統一模型：在 IOTA 架構下從數據采集到數據接收以及數據處理都是用一套數據模型。
- 聚合：同樣的數據進行邊緣聚合計算，如某些用戶訪問路徑可以直接由采集端來完成，生成對應類似漏斗的事件。一般這個計算是服務器下發策略來動態控制的，當然也可以隨時做出調整，值得注意的是這是不可以逆的運算，並且這種模式只適用於適合間隔發送模式的數據
- 校驗：數據的完整和有效性可以放到采集端處理，確保 SDK 給 server 的數據不是被修改的，產生的數據是合理的，這就要求采集端加入防作弊的功能。這是一個成熟產品長期需要投入的項目，大部分公司的風控做的也有一部分這樣的工作。
- 實時：數據實時上報給服務器，這樣才能讓用戶感覺到零延遲，實時計算。如12306購票，要立即的進行查看結果，不能等得到次日才看到結果。同樣的帶來另一個問題，
- 高可控：高可控是對數據采集最基礎，也是最重要的一個要求。不然面對攻擊，服務器無法實時監控，動態調整，立即處理，可能會導致服務器的短時間無法正常工作(如數據處理延遲，嚴重的乃至宕機)
Real Time Data
- 實時數據緩存區，這部分是為了達到實時計算的目的，海量數據接收不可能海量實時入歷史數據庫，那樣會出現建立索引延遲、歷史數據碎片文件等問題。因此，有一個實時數據緩存區來存儲最近幾分鍾或者幾秒鍾的數據。這塊可以使用Kudu或者Hbase等組件來實現。這部分數據會通過Dumper來合並到歷史數據當中。此處的數據模型和SDK端數據模型是保持一致的，都是Common Data Model，例如“主-謂-賓”模型。
Historical Data
- 歷史數據沉浸區，這部分是保存了大量的歷史數據，為了實現Ad-hoc查詢，將自動建立相關索引提高整體歷史數據查詢效率，從而實現秒級復雜查詢百億條數據的反饋。例如可以使用HDFS存儲歷史數據，此處的數據模型依然SDK端數據模型是保持一致的Common Data Model。
-
當buffer區的數據量達到一定規模時，調度會啟動DumpMR(Spark、MR任務)會將緩沖區數據flush到HDFS中去，因為還要支持數據的實時查詢，我們采用R/W表切換方案，即一直寫入一張表直到閾值，就寫入新表，老表開始轉為ORC格式。
HDFS高效存儲：
- 按天分區
- 基於用戶ID，事件時間排序
- 冷熱分層
- Orc存儲
- BloomFilter
- 稀疏索引
- Snappy壓縮
小文件問題：
- 不按事件分區
- MergerMR定時合並小文件
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 vs Lambda
IOTA vs Kappa
參考資料