華為云計(jì)算 云知識(shí) 面對(duì)IoT數(shù)據(jù)的爆發(fā),傳統(tǒng)大數(shù)據(jù)平臺(tái)架構(gòu)正在發(fā)生哪些適應(yīng)性變化?
面對(duì)IoT數(shù)據(jù)的爆發(fā),傳統(tǒng)大數(shù)據(jù)平臺(tái)架構(gòu)正在發(fā)生哪些適應(yīng)性變化?

一、傳統(tǒng) 大數(shù)據(jù) 平臺(tái)Lambda架構(gòu):

兩條數(shù)據(jù)流獨(dú)立處理:

1.實(shí)時(shí)流,多采用Flink,Storm或者Spark Streaming

2.批處理,如采用MapReduce,Spark SQL等

關(guān)鍵問題:

1.計(jì)算結(jié)果容易不一致,如批計(jì)算的結(jié)果更全面,與流計(jì)算有差異

2.IoT時(shí)代數(shù)據(jù)量巨大,夜間批計(jì)算時(shí)間窗可能不夠3.數(shù)據(jù)源一旦變化,適配工作量巨大。

二、一種改良的大數(shù)據(jù)平臺(tái)架構(gòu)Kappa

一條數(shù)據(jù)流統(tǒng)一處理:

1.改進(jìn)流計(jì)算來解決批量數(shù)據(jù)處理的問題,統(tǒng)一業(yè)務(wù)處理邏輯

2.如需重新計(jì)算,需重啟一個(gè)流計(jì)算實(shí)例

關(guān)鍵問題:

1.流式處理對(duì)于高吞吐的歷史數(shù)據(jù)處理存在瓶頸,很難適合IoT數(shù)據(jù)量

2.開發(fā)周期長(zhǎng),不同數(shù)據(jù)格式都要開發(fā)不同的streaming程序

3.成本高,很依賴高性能存儲(chǔ)如 redis ,hbase等。

三、Apache IoTDB項(xiàng)目

以處理IoT時(shí)序數(shù)據(jù)為核心:

1.基于時(shí)序優(yōu)化的文件存儲(chǔ)格式TsFile,可與HDFS同步

2.提供數(shù)據(jù)模型能力(物的層次結(jié)構(gòu))

3.融入主流生態(tài),如Hadoop, Spark, and Grafana等

4.高壓縮低成本,存儲(chǔ)在硬盤上的成本<$0.23/GB (Azure 約$3/GB)

關(guān)鍵問題:

1.通過JDBC接口與云端DB互通,有功能局限

四、以模型驅(qū)動(dòng)的IoTA架構(gòu)

云邊協(xié)同,模型驅(qū)動(dòng)的分析架構(gòu):

1.貫穿整體業(yè)務(wù)始終的數(shù)據(jù)模型,一致體驗(yàn),去ETL化

2.邊緣計(jì)算SDK,邊緣側(cè)可部署數(shù)據(jù)分析邏輯,增強(qiáng)時(shí)效性

關(guān)鍵問題:

1.期望構(gòu)建標(biāo)準(zhǔn)化的數(shù)據(jù)模型,達(dá)到去ETL化的效果,可能需要較長(zhǎng)時(shí)間的演化2.并未完全解決流批分離處理架構(gòu)下分析結(jié)果可能不一。