經(jīng)過(guò)這么多年的發(fā)展,已經(jīng)從大數(shù)據(jù)1.0的BI/Datawarehouse時(shí)代,經(jīng)過(guò)大數(shù)據(jù)2.0的Web/APP過(guò)渡,進(jìn)入到了IOT的大數(shù)據(jù)3.0時(shí)代,而隨之而來(lái)的是數(shù)據(jù)架構(gòu)的變化。
▌Lambda架構(gòu)
在過(guò)去Lambda數(shù)據(jù)架構(gòu)成為每一個(gè)公司大數(shù)據(jù)平臺(tái)必備的架構(gòu),它解決了一個(gè)公司大數(shù)據(jù)批量離線處理和實(shí)時(shí)數(shù)據(jù)處理的需求。一個(gè)典型的Lambda架構(gòu)如下:
數(shù)據(jù)從底層的數(shù)據(jù)源開(kāi)始,經(jīng)過(guò)各種各樣的格式進(jìn)入大數(shù)據(jù)平臺(tái),在大數(shù)據(jù)平臺(tái)中經(jīng)過(guò)Kafka、Flume等數(shù)據(jù)組件進(jìn)行收集,然后分成兩條線進(jìn)行計(jì)算。一條線是進(jìn)入流式計(jì)算平臺(tái)(例如 Storm、Flink或者Spark Streaming),去計(jì)算實(shí)時(shí)的一些指標(biāo);另一條線進(jìn)入批量數(shù)據(jù)處理離線計(jì)算平臺(tái)(例如Mapreduce、Hive,Spark SQL),去計(jì)算T+1的相關(guān)業(yè)務(wù)指標(biāo),這些指標(biāo)需要隔日才能看見(jiàn)。
Lambda架構(gòu)經(jīng)歷多年的發(fā)展,其優(yōu)點(diǎn)是穩(wěn)定,對(duì)于實(shí)時(shí)計(jì)算部分的計(jì)算成本可控,批量處理可以用晚上的時(shí)間來(lái)整體批量計(jì)算,這樣把實(shí)時(shí)計(jì)算和離線計(jì)算高峰分開(kāi),這種架構(gòu)支撐了數(shù)據(jù)行業(yè)的早期發(fā)展,但是它也有一些致命缺點(diǎn),并在大數(shù)據(jù)3.0時(shí)代越來(lái)越不適應(yīng)數(shù)據(jù)分析業(yè)務(wù)的需求。缺點(diǎn)如下:
實(shí)時(shí)與批量計(jì)算結(jié)果不一致引起的數(shù)據(jù)口徑問(wèn)題:因?yàn)榕亢蛯?shí)時(shí)計(jì)算走的是兩個(gè)計(jì)算框架和計(jì)算程序,算出的結(jié)果往往不同,經(jīng)??吹揭粋€(gè)數(shù)字當(dāng)天看是一個(gè)數(shù)據(jù),第二天看昨天的數(shù)據(jù)反而發(fā)生了變化。
批量計(jì)算在計(jì)算窗口內(nèi)無(wú)法完成:在IOT時(shí)代,數(shù)據(jù)量級(jí)越來(lái)越大,經(jīng)常發(fā)現(xiàn)夜間只有4、5個(gè)小時(shí)的時(shí)間窗口,已經(jīng)無(wú)法完成白天20多個(gè)小時(shí)累計(jì)的數(shù)據(jù),保證早上上班前準(zhǔn)時(shí)出數(shù)據(jù)已成為每個(gè)大數(shù)據(jù)團(tuán)隊(duì)頭疼的問(wèn)題。
數(shù)據(jù)源變化都要重新開(kāi)發(fā),開(kāi)發(fā)周期長(zhǎng):每次數(shù)據(jù)源的格式變化,業(yè)務(wù)的邏輯變化都需要針對(duì)ETL和Streaming做開(kāi)發(fā)修改,整體開(kāi)發(fā)周期很長(zhǎng),業(yè)務(wù)反應(yīng)不夠迅速。
服務(wù)器存儲(chǔ)大:數(shù)據(jù)倉(cāng)庫(kù)的典型設(shè)計(jì),會(huì)產(chǎn)生大量的中間結(jié)果表,造成數(shù)據(jù)急速膨脹,加大服務(wù)器存儲(chǔ)壓力。
▌Kappa架構(gòu)
針對(duì)Lambda架構(gòu)的需要維護(hù)兩套程序等以上缺點(diǎn),LinkedIn的Jay Kreps結(jié)合實(shí)際經(jīng)驗(yàn)和個(gè)人體會(huì)提出了Kappa架構(gòu)。Kappa架構(gòu)的核心思想是通過(guò)改進(jìn)流計(jì)算系統(tǒng)來(lái)解決數(shù)據(jù)全量處理的問(wèn)題,使得實(shí)時(shí)計(jì)算和批處理過(guò)程使用同一套代碼。此外Kappa架構(gòu)認(rèn)為只有在有必要的時(shí)候才會(huì)對(duì)歷史數(shù)據(jù)進(jìn)行重復(fù)計(jì)算,而如果需要重復(fù)計(jì)算時(shí),Kappa架構(gòu)下可以啟動(dòng)很多個(gè)實(shí)例進(jìn)行重復(fù)計(jì)算。
一個(gè)典型的Kappa架構(gòu)如下圖所示:
Kappa架構(gòu)的核心思想,包括以下三點(diǎn):
1.用Kafka或者類(lèi)似MQ隊(duì)列系統(tǒng)收集各種各樣的數(shù)據(jù),你需要幾天的數(shù)據(jù)量就保存幾天。
2.當(dāng)需要全量重新計(jì)算時(shí),重新起一個(gè)流計(jì)算實(shí)例,從頭開(kāi)始讀取數(shù)據(jù)進(jìn)行處理,并輸出到一個(gè)新的結(jié)果存儲(chǔ)中。
3.當(dāng)新的實(shí)例做完后,停止老的流計(jì)算實(shí)例,并把老的一些結(jié)果刪除。
Kappa架構(gòu)的優(yōu)點(diǎn)在于將實(shí)時(shí)和離線代碼統(tǒng)一起來(lái),方便維護(hù)而且統(tǒng)一了數(shù)據(jù)口徑的問(wèn)題。而Kappa的缺點(diǎn)也很明顯:
流式處理對(duì)于歷史數(shù)據(jù)的高吞吐量力不從心:所有的數(shù)據(jù)都通過(guò)流式計(jì)算,即便通過(guò)加大并發(fā)實(shí)例數(shù)亦很難適應(yīng)IOT時(shí)代對(duì)數(shù)據(jù)查詢(xún)響應(yīng)的即時(shí)性要求。
開(kāi)發(fā)周期長(zhǎng):此外Kappa架構(gòu)下由于采集的數(shù)據(jù)格式的不統(tǒng)一,每次都需要開(kāi)發(fā)不同的Streaming程序,導(dǎo)致開(kāi)發(fā)周期長(zhǎng)。
服務(wù)器成本浪費(fèi):Kappa架構(gòu)的核心原理依賴(lài)于外部高性能存儲(chǔ)redis,hbase服務(wù)。但是這2種系統(tǒng)組件,又并非設(shè)計(jì)來(lái)滿足全量數(shù)據(jù)存儲(chǔ)設(shè)計(jì),對(duì)服務(wù)器成本嚴(yán)重浪費(fèi)。
▌IOTA架構(gòu)
而在IOT大潮下,智能手機(jī)、PC、智能硬件設(shè)備的計(jì)算能力越來(lái)越強(qiáng),而業(yè)務(wù)需求要求數(shù)據(jù)實(shí)時(shí)響應(yīng)需求能力也越來(lái)越強(qiáng),過(guò)去傳統(tǒng)的中心化、非實(shí)時(shí)化數(shù)據(jù)處理的思路已經(jīng)不適應(yīng)現(xiàn)在的大數(shù)據(jù)分析需求,我提出新一代的大數(shù)據(jù)IOTA架構(gòu)來(lái)解決上述問(wèn)題,整體思路是設(shè)定標(biāo)準(zhǔn)數(shù)據(jù)模型,通過(guò)邊緣計(jì)算技術(shù)把所有的計(jì)算過(guò)程分散在數(shù)據(jù)產(chǎn)生、計(jì)算和查詢(xún)過(guò)程當(dāng)中,以統(tǒng)一的數(shù)據(jù)模型貫穿始終,從而提高整體的預(yù)算效率,同時(shí)滿足即時(shí)計(jì)算的需要,可以使用各種Ad-hoc Query來(lái)查詢(xún)底層數(shù)據(jù):
IOTA整體技術(shù)結(jié)構(gòu)分為幾部分:
Common Data Model:貫穿整體業(yè)務(wù)始終的數(shù)據(jù)模型,這個(gè)模型是整個(gè)業(yè)務(wù)的核心,要保持SDK、cache、歷史數(shù)據(jù)、查詢(xún)引擎保持一致。對(duì)于用戶(hù)數(shù)據(jù)分析來(lái)講可以定義為“主-謂-賓”或者“對(duì)象-事件”這樣的抽象模型來(lái)滿足各種各樣的查詢(xún)。以大家熟悉的APP用戶(hù)模型為例,用“主-謂-賓”模型描述就是“X用戶(hù) – 事件1 – A頁(yè)面(2018/4/11 20:00) ”。當(dāng)然,根據(jù)業(yè)務(wù)需求的不同,也可以使用“產(chǎn)品-事件”、“地點(diǎn)-時(shí)間”模型等等。模型本身也可以根據(jù)協(xié)議(例如 protobuf)來(lái)實(shí)現(xiàn)SDK端定義,中央存儲(chǔ)的方式。此處核心是,從SDK到存儲(chǔ)到處理是統(tǒng)一的一個(gè)Common Data Model。
Edge SDKs Edge Servers:這是數(shù)據(jù)的采集端,不僅僅是過(guò)去的簡(jiǎn)單的SDK,在復(fù)雜的計(jì)算情況下,會(huì)賦予SDK更復(fù)雜的計(jì)算,在設(shè)備端就轉(zhuǎn)化為形成統(tǒng)一的數(shù)據(jù)模型來(lái)進(jìn)行傳送。例如對(duì)于智能Wi-Fi采集的數(shù)據(jù),從AC端就變?yōu)?ldquo;X用戶(hù)的MAC 地址-出現(xiàn)- A樓層(2018/4/11 18:00)”這種主-謂-賓結(jié)構(gòu),對(duì)于攝像頭會(huì)通過(guò)Edge AI Server,轉(zhuǎn)化成為“X的Face特征- 進(jìn)入- A火車(chē)站(2018/4/11 20:00)”。也可以是上面提到的簡(jiǎn)單的APP或者頁(yè)面級(jí)別的“X用戶(hù) – 事件1 – A頁(yè)面(2018/4/11 20:00) ”,對(duì)于APP和H5頁(yè)面來(lái)講,沒(méi)有計(jì)算工作量,只要求埋點(diǎn)格式即可。
Real Time Data:實(shí)時(shí)數(shù)據(jù)緩存區(qū),這部分是為了達(dá)到實(shí)時(shí)計(jì)算的目的,海量數(shù)據(jù)接收不可能海量實(shí)時(shí)入歷史數(shù)據(jù)庫(kù),那樣會(huì)出現(xiàn)建立索引延遲、歷史數(shù)據(jù)碎片文件等問(wèn)題。因此,有一個(gè)實(shí)時(shí)數(shù)據(jù)緩存區(qū)來(lái)存儲(chǔ)最近幾分鐘或者幾秒鐘的數(shù)據(jù)。這塊可以使用Kudu或者Hbase等組件來(lái)實(shí)現(xiàn)。這部分?jǐn)?shù)據(jù)會(huì)通過(guò)Dumper來(lái)合并到歷史數(shù)據(jù)當(dāng)中。此處的數(shù)據(jù)模型和SDK端數(shù)據(jù)模型是保持一致的,都是Common Data Model,例如“主-謂-賓”模型。
Historical Data:歷史數(shù)據(jù)沉浸區(qū),這部分是保存了大量的歷史數(shù)據(jù),為了實(shí)現(xiàn)Ad-hoc查詢(xún),將自動(dòng)建立相關(guān)索引提高整體歷史數(shù)據(jù)查詢(xún)效率,從而實(shí)現(xiàn)秒級(jí)復(fù)雜查詢(xún)百億條數(shù)據(jù)的反饋。例如可以使用HDFS存儲(chǔ)歷史數(shù)據(jù),此處的數(shù)據(jù)模型依然SDK端數(shù)據(jù)模型是保持一致的Common Data Model。
Dumper:Dumper的主要工作就是把最近幾秒或者幾分鐘的實(shí)時(shí)數(shù)據(jù),根據(jù)匯聚規(guī)則、建立索引,存儲(chǔ)到歷史存儲(chǔ)結(jié)構(gòu)當(dāng)中,可以使用map reduce、C、Scala來(lái)撰寫(xiě),把相關(guān)的數(shù)據(jù)從Realtime Data區(qū)寫(xiě)入Historical Data區(qū)。
Query Engine:查詢(xún)引擎,提供統(tǒng)一的對(duì)外查詢(xún)接口和協(xié)議(例如SQL JDBC),把Realtime Data和Historical Data合并到一起查詢(xún),從而實(shí)現(xiàn)對(duì)于數(shù)據(jù)實(shí)時(shí)的Ad-hoc查詢(xún)。例如常見(jiàn)的計(jì)算引擎可以使用presto、impala、clickhouse等。
Realtime model feedback:通過(guò)Edge computing技術(shù),在邊緣端有更多的交互可以做,可以通過(guò)在Realtime Data去設(shè)定規(guī)則來(lái)對(duì)Edge SDK端進(jìn)行控制,例如,數(shù)據(jù)上傳的頻次降低、語(yǔ)音控制的迅速反饋,某些條件和規(guī)則的觸發(fā)等等。簡(jiǎn)單的事件處理,將通過(guò)本地的IOT端完成,例如,嫌疑犯的識(shí)別現(xiàn)在已經(jīng)有很多攝像頭本身帶有此功能。
IOTA大數(shù)據(jù)架構(gòu),主要有如下幾個(gè)特點(diǎn):
去ETL化:ETL和相關(guān)開(kāi)發(fā)一直是大數(shù)據(jù)處理的痛點(diǎn),IOTA架構(gòu)通過(guò)Common Data Model的設(shè)計(jì),專(zhuān)注在某一個(gè)具體領(lǐng)域的數(shù)據(jù)計(jì)算,從而可以從SDK端開(kāi)始計(jì)算,中央端只做采集、建立索引和查詢(xún),提高整體數(shù)據(jù)分析的效率。
Ad-hoc即時(shí)查詢(xún):鑒于整體的計(jì)算流程機(jī)制,在手機(jī)端、智能IOT事件發(fā)生之時(shí),就可以直接傳送到云端進(jìn)入real time data區(qū),可以被前端的Query Engine來(lái)查詢(xún)。此時(shí)用戶(hù)可以使用各種各樣的查詢(xún),直接查到前幾秒發(fā)生的事件,而不用在等待ETL或者Streaming的數(shù)據(jù)研發(fā)和處理。
邊緣計(jì)算(Edge-Computing):將過(guò)去統(tǒng)一到中央進(jìn)行整體計(jì)算,分散到數(shù)據(jù)產(chǎn)生、存儲(chǔ)和查詢(xún)端,數(shù)據(jù)產(chǎn)生既符合Common Data Model。同時(shí),也給與Realtime model feedback,讓客戶(hù)端傳送數(shù)據(jù)的同時(shí)馬上進(jìn)行反饋,而不需要所有事件都要到中央端處理之后再進(jìn)行下發(fā)。
如上圖,IOTA架構(gòu)有各種各樣的實(shí)現(xiàn)方法,為了驗(yàn)證IOTA架構(gòu),易觀也自主設(shè)計(jì)并實(shí)現(xiàn)了“秒算”引擎,目前支持易觀內(nèi)部月活5.5億設(shè)備端進(jìn)行計(jì)算的同時(shí),也基于“秒算”引擎研發(fā)出了可以獨(dú)立部署在企業(yè)客戶(hù)內(nèi),進(jìn)行數(shù)字用戶(hù)分析和營(yíng)銷(xiāo)的“易觀方舟”,可以訪問(wèn)ark.analysys.cn進(jìn)行體驗(yàn)。
在大數(shù)據(jù)3.0時(shí)代,Lambda大數(shù)據(jù)架構(gòu)已經(jīng)無(wú)法滿足企業(yè)用戶(hù)日常大數(shù)據(jù)分析和精益運(yùn)營(yíng)的需要,去ETL化的IOTA大數(shù)據(jù)架構(gòu)才是未來(lái)。