下一代大数据即时分析架构--IOTA架构
經(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ù)架構(gòu)的變化。
▌Lambda架構(gòu)
在過去Lambda數(shù)據(jù)架構(gòu)成為每一個公司大數(shù)據(jù)平臺必備的架構(gòu),它解決了一個公司大數(shù)據(jù)批量離線處理和實時數(shù)據(jù)處理的需求。一個典型的Lambda架構(gòu)如下:
?
數(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架構(gòu)經(jīng)歷多年的發(fā)展,其優(yōu)點是穩(wěn)定,對于實時計算部分的計算成本可控,批量處理可以用晚上的時間來整體批量計算,這樣把實時計算和離線計算高峰分開,這種架構(gòu)支撐了數(shù)據(jù)行業(yè)的早期發(fā)展,但是它也有一些致命缺點,并在大數(shù)據(jù)3.0時代越來越不適應數(shù)據(jù)分析業(yè)務的需求。缺點如下:
● 實時與批量計算結(jié)果不一致引起的數(shù)據(jù)口徑問題:因為批量和實時計算走的是兩個計算框架和計算程序,算出的結(jié)果往往不同,經(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)生大量的中間結(jié)果表,造成數(shù)據(jù)急速膨脹,加大服務器存儲壓力。?
▌Kappa架構(gòu)
針對Lambda架構(gòu)的需要維護兩套程序等以上缺點,LinkedIn的Jay Kreps結(jié)合實際經(jīng)驗和個人體會提出了Kappa架構(gòu)。Kappa架構(gòu)的核心思想是通過改進流計算系統(tǒng)來解決數(shù)據(jù)全量處理的問題,使得實時計算和批處理過程使用同一套代碼。此外Kappa架構(gòu)認為只有在有必要的時候才會對歷史數(shù)據(jù)進行重復計算,而如果需要重復計算時,Kappa架構(gòu)下可以啟動很多個實例進行重復計算。
一個典型的Kappa架構(gòu)如下圖所示:
?
Kappa架構(gòu)的核心思想,包括以下三點:
?
1.用Kafka或者類似MQ隊列系統(tǒng)收集各種各樣的數(shù)據(jù),你需要幾天的數(shù)據(jù)量就保存幾天。
2.當需要全量重新計算時,重新起一個流計算實例,從頭開始讀取數(shù)據(jù)進行處理,并輸出到一個新的結(jié)果存儲中。
3.當新的實例做完后,停止老的流計算實例,并把老的一些結(jié)果刪除。
Kappa架構(gòu)的優(yōu)點在于將實時和離線代碼統(tǒng)一起來,方便維護而且統(tǒng)一了數(shù)據(jù)口徑的問題。而Kappa的缺點也很明顯:
●?流式處理對于歷史數(shù)據(jù)的高吞吐量力不從心:所有的數(shù)據(jù)都通過流式計算,即便通過加大并發(fā)實例數(shù)亦很難適應IOT時代對數(shù)據(jù)查詢響應的即時性要求。
●?開發(fā)周期長:此外Kappa架構(gòu)下由于采集的數(shù)據(jù)格式的不統(tǒng)一,每次都需要開發(fā)不同的Streaming程序,導致開發(fā)周期長。
●?服務器成本浪費:Kappa架構(gòu)的核心原理依賴于外部高性能存儲redis,hbase服務。但是這2種系統(tǒng)組件,又并非設計來滿足全量數(shù)據(jù)存儲設計,對服務器成本嚴重浪費。
IOTA架構(gòu)
而在IOT大潮下,智能手機、PC、智能硬件設備的計算能力越來越強,而業(yè)務需求要求數(shù)據(jù)實時響應需求能力也越來越強,過去傳統(tǒng)的中心化、非實時化數(shù)據(jù)處理的思路已經(jīng)不適應現(xiàn)在的大數(shù)據(jù)分析需求,我提出新一代的大數(shù)據(jù)IOTA架構(gòu)來解決上述問題,整體思路是設定標準數(shù)據(jù)模型,通過邊緣計算技術把所有的計算過程分散在數(shù)據(jù)產(chǎn)生、計算和查詢過程當中,以統(tǒng)一的數(shù)據(jù)模型貫穿始終,從而提高整體的預算效率,同時滿足即時計算的需要,可以使用各種Ad-hoc Query來查詢底層數(shù)據(jù)。
關于IOTA架構(gòu)的分析請查閱附件!
本文對比了 Lambda數(shù)據(jù)架構(gòu)的痛點,通過實踐和總結(jié)出新一代大數(shù)據(jù)分析架構(gòu)IOTA架構(gòu),歡迎加入微信群討論
總結(jié)
以上是生活随笔為你收集整理的下一代大数据即时分析架构--IOTA架构的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: MySQL数据库备份工具mysqldum
- 下一篇: Exp8 web基础 20154301仉