七年一劍，華麗蛻變。自2012年起連續(xù)6年15場峰會，凝聚大量技術專家，博觀而約取,厚積而薄發(fā)。2018WOT全球軟件與運維技術峰會揚帆起航，圍繞12大核心熱點，匯聚海內(nèi)外60位一線專家，打造高端技術盛宴!

近日，2018WOT全球軟件與運維技術峰會重量級嘉賓，擁有13年大數(shù)據(jù)工作經(jīng)驗的資深專家——易觀智庫CTO郭煒將在5月18日的2018WOT峰會上分享他的***觀點，那就是Lambda架構已死，新一代去ETL化的IOTA架構才是未來，郭煒將就Lambda與Kappa架構的發(fā)展及優(yōu)缺點展開，分享IOTA大數(shù)據(jù)架構的思路及優(yōu)缺點，以及易觀在IOTA架構領域的實踐經(jīng)驗，以下為郭煒先生整理出的實踐心得，供大家先睹為快。

易觀智庫CTO郭煒

經(jīng)過這么多年的發(fā)展，已經(jīng)從大數(shù)據(jù)1.0的BI/Datawarehouse時代，經(jīng)過大數(shù)據(jù)2.0的Web/APP過渡，進入到了IOT的大數(shù)據(jù)3.0時代，而隨之而來的是數(shù)據(jù)架構的變化。

▌Lambda架構

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

數(shù)據(jù)從底層的數(shù)據(jù)源開始，經(jīng)過各種各樣的格式進入大數(shù)據(jù)平臺，在大數(shù)據(jù)平臺中經(jīng)過Kafka、Flume等數(shù)據(jù)組件進行收集，然后分成兩條線進行計算。一條線是進入流式計算平臺(例如 Storm、Flink或者Spark Streaming)，去計算實時的一些指標;另一條線進入批量數(shù)據(jù)處理離線計算平臺(例如Mapreduce、Hive，Spark SQL)，去計算T+1的相關業(yè)務指標，這些指標需要隔日才能看見。

Lambda架構經(jīng)歷多年的發(fā)展，其優(yōu)點是穩(wěn)定，對于實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了數(shù)據(jù)行業(yè)的早期發(fā)展，但是它也有一些致命缺點，并在大數(shù)據(jù)3.0時代越來越不適應數(shù)據(jù)分析業(yè)務的需求。缺點如下：

● 實時與批量計算結果不一致引起的數(shù)據(jù)口徑問題：因為批量和實時計算走的是兩個計算框架和計算程序，算出的結果往往不同，經(jīng)?？吹揭粋€數(shù)字當天看是一個數(shù)據(jù)，第二天看昨天的數(shù)據(jù)反而發(fā)生了變化。

● 批量計算在計算窗口內(nèi)無法完成：在IOT時代，數(shù)據(jù)量級越來越大，經(jīng)常發(fā)現(xiàn)夜間只有4、5個小時的時間窗口，已經(jīng)無法完成白天20多個小時累計的數(shù)據(jù)，保證早上上班前準時出數(shù)據(jù)已成為每個大數(shù)據(jù)團隊頭疼的問題。

●數(shù)據(jù)源變化都要重新開發(fā)，開發(fā)周期長：每次數(shù)據(jù)源的格式變化，業(yè)務的邏輯變化都需要針對ETL和Streaming做開發(fā)修改，整體開發(fā)周期很長，業(yè)務反應不夠迅速。

● 服務器存儲大：數(shù)據(jù)倉庫的典型設計，會產(chǎn)生大量的中間結果表，造成數(shù)據(jù)急速膨脹，加大服務器存儲壓力。

▌Kappa架構

針對Lambda架構的需要維護兩套程序等以上缺點，LinkedIn的Jay Kreps結合實際經(jīng)驗和個人體會提出了Kappa架構。Kappa架構的核心思想是通過改進流計算系統(tǒng)來解決數(shù)據(jù)全量處理的問題，使得實時計算和批處理過程使用同一套代碼。此外Kappa架構認為只有在有必要的時候才會對歷史數(shù)據(jù)進行重復計算，而如果需要重復計算時，Kappa架構下可以啟動很多個實例進行重復計算。

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

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

1.用Kafka或者類似MQ隊列系統(tǒng)收集各種各樣的數(shù)據(jù)，你需要幾天的數(shù)據(jù)量就保存幾天。

2.當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數(shù)據(jù)進行處理，并輸出到一個新的結果存儲中。

3.當新的實例做完后，停止老的流計算實例，并把老的一些結果刪除。

Kappa架構的優(yōu)點在于將實時和離線代碼統(tǒng)一起來，方便維護而且統(tǒng)一了數(shù)據(jù)口徑的問題。

而Kappa的缺點也很明顯：

● 流式處理對于歷史數(shù)據(jù)的高吞吐量力不從心：所有的數(shù)據(jù)都通過流式計算，即便通過加大并發(fā)實例數(shù)亦很難適應IOT時代對數(shù)據(jù)查詢響應的即時性要求。

● 開發(fā)周期長：此外Kappa架構下由于采集的數(shù)據(jù)格式的不統(tǒng)一，每次都需要開發(fā)不同的Streaming程序，導致開發(fā)周期長。

● 服務器成本浪費：Kappa架構的核心原理依賴于外部高性能存儲redis,hbase服務。但是這2種系統(tǒng)組件，又并非設計來滿足全量數(shù)據(jù)存儲設計，對服務器成本嚴重浪費。

▌IOTA架構

而在IOT大潮下，智能手機、PC、智能硬件設備的計算能力越來越強，而業(yè)務需求要求數(shù)據(jù)實時響應需求能力也越來越強，過去傳統(tǒng)的中心化、非實時化數(shù)據(jù)處理的思路已經(jīng)不適應現(xiàn)在的大數(shù)據(jù)分析需求，我提出新一代的大數(shù)據(jù)IOTA架構來解決上述問題，整體思路是設定標準數(shù)據(jù)模型，通過邊緣計算技術把所有的計算過程分散在數(shù)據(jù)產(chǎn)生、計算和查詢過程當中，以統(tǒng)一的數(shù)據(jù)模型貫穿始終，從而提高整體的預算效率，同時滿足即時計算的需要，可以使用各種Ad-hoc Query來查詢底層數(shù)據(jù)：

IOTA整體技術結構分為幾部分：

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

● Edge SDKs & Edge Servers：這是數(shù)據(jù)的采集端，不僅僅是過去的簡單的SDK，在復雜的計算情況下，會賦予SDK更復雜的計算，在設備端就轉(zhuǎn)化為形成統(tǒng)一的數(shù)據(jù)模型來進行傳送。例如對于智能Wi-Fi采集的數(shù)據(jù)，從AC端就變?yōu)?ldquo;X用戶的MAC 地址-出現(xiàn)- A樓層(2018/4/11 18:00)”這種主-謂-賓結構，對于攝像頭會通過Edge AI Server，轉(zhuǎn)化成為“X的Face特征- 進入- A火車站(2018/4/11 20:00)”。也可以是上面提到的簡單的APP或者頁面級別的“X用戶 – 事件1 – A頁面(2018/4/11 20:00) ”，對于APP和H5頁面來講，沒有計算工作量，只要求埋點格式即可。

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

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

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

● Query Engine：查詢引擎，提供統(tǒng)一的對外查詢接口和協(xié)議(例如SQL JDBC)，把Realtime Data和Historical Data合并到一起查詢，從而實現(xiàn)對于數(shù)據(jù)實時的Ad-hoc查詢。例如常見的計算引擎可以使用presto、impala、clickhouse等。

● Realtime model feedback：通過Edge computing技術，在邊緣端有更多的交互可以做，可以通過在Realtime Data去設定規(guī)則來對Edge SDK端進行控制，例如，數(shù)據(jù)上傳的頻次降低、語音控制的迅速反饋，某些條件和規(guī)則的觸發(fā)等等。簡單的事件處理，將通過本地的IOT端完成，例如，嫌疑犯的識別現(xiàn)在已經(jīng)有很多攝像頭本身帶有此功能。

IOTA大數(shù)據(jù)架構，主要有如下幾個特點：

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

● Ad-hoc即時查詢：鑒于整體的計算流程機制，在手機端、智能IOT事件發(fā)生之時，就可以直接傳送到云端進入real time data區(qū)，可以被前端的Query Engine來查詢。此時用戶可以使用各種各樣的查詢，直接查到前幾秒發(fā)生的事件，而不用在等待ETL或者Streaming的數(shù)據(jù)研發(fā)和處理。

● 邊緣計算(Edge-Computing)：將過去統(tǒng)一到中央進行整體計算，分散到數(shù)據(jù)產(chǎn)生、存儲和查詢端，數(shù)據(jù)產(chǎn)生既符合Common Data Model。同時，也給與Realtime model feedback，讓客戶端傳送數(shù)據(jù)的同時馬上進行反饋，而不需要所有事件都要到中央端處理之后再進行下發(fā)。

如上圖，IOTA架構有各種各樣的實現(xiàn)方法，為了驗證IOTA架構，易觀也自主設計并實現(xiàn)了“秒算”引擎，目前支持易觀內(nèi)部月活5.5億設備端進行計算的同時，也基于“秒算”引擎研發(fā)出了可以獨立部署在企業(yè)客戶內(nèi)，進行數(shù)字用戶分析和營銷的“易觀方舟”，可以訪問ark.analysys.cn進行體驗。

在大數(shù)據(jù)3.0時代，Lambda大數(shù)據(jù)架構已經(jīng)無法滿足企業(yè)用戶日常大數(shù)據(jù)分析和精益運營的需要，去ETL化的IOTA大數(shù)據(jù)架構才是未來。

嘉賓簡介：

郭煒先生畢業(yè)于北大研究生數(shù)據(jù)挖掘?qū)I(yè)，加入易觀之前，郭煒曾任聯(lián)想研究院大數(shù)據(jù)總監(jiān)，萬達電商數(shù)據(jù)部總經(jīng)理等職務，并曾在中金、IBM、Teradata公司擔任過大數(shù)據(jù)方向重要管理崗位，有13的大數(shù)據(jù)工作經(jīng)驗。

5月18-19日，北京•粵財JW萬豪酒店，全球最值得關注的IT技術盛宴與您不見不散。2018WOT全球軟件與運維技術峰會一定是您發(fā)現(xiàn)全新思路、挖掘***思想、拓展人脈的重要平臺。

目前我們的各項票種已全面發(fā)售。需要提醒您的是，購票越早，折扣越大!與KOL零距離交流，呈現(xiàn)不一樣的“英雄盛宴”!

點擊官網(wǎng)了解詳情：wot.51cto.com

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】