本篇文章給大家分享的是有關(guān)KubeEdge和Kuiper解決邊緣流式數(shù)據(jù)處理是怎樣的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
成都創(chuàng)新互聯(lián)公司專注于涵江企業(yè)網(wǎng)站建設(shè),響應式網(wǎng)站,商城網(wǎng)站建設(shè)。涵江網(wǎng)站建設(shè)公司,為涵江等地區(qū)提供建站服務。全流程按需策劃，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務
KubeEdge 是一個開源的邊緣計算平臺，它在Kubernetes原生的容器編排和調(diào)度能力之上，擴展實現(xiàn)了 云邊協(xié)同、計算下沉、海量邊緣設(shè)備管理、邊緣自治等能力。KubeEdge還將通過插件的形式支持5G MEC、AI云邊協(xié)同等場景，目前在很多領(lǐng)域都已落地應用。
Kuiper是從2019年初開始做的，在2019年10月份，發(fā)布了第一個版本，一直持續(xù)迭代到現(xiàn)在，它的整個架構(gòu)是一個比較經(jīng)典的流式處理架構(gòu)。
產(chǎn)品設(shè)計目標：在云端運行的流式處理，像Spark與Flink可以運行在邊緣端
整體架構(gòu)可分為3部分，左側(cè)為sources,代表數(shù)據(jù)來源的位置，數(shù)據(jù)來源可能是KubeEdge里面有個邊緣端的MQTT macOS broker，也可能是文件、窗口、數(shù)據(jù)庫；
右側(cè)為Sinks，代表數(shù)據(jù)處理完成后所要存儲的位置，也就是目標系統(tǒng)，目標可以是MQTT，可以將其存到文件、數(shù)據(jù)庫里面，也可以調(diào)用HTTP service；
中間部分分成了這幾層，最上層為數(shù)據(jù)業(yè)務邏輯處理，這個層面提供了SQL statement、Rule Parser，SQL processors進行處理后并將其轉(zhuǎn)化成SQL plan；下面層為Streaming runtime和SQL runtime, 運行最終執(zhí)行出來的 plan；最底層為storage，用來存儲有些消息流出。
流式處理：實現(xiàn)在邊緣端的實時流式處理
規(guī)則引擎：靈活定義規(guī)則引擎，實現(xiàn)告警和消息轉(zhuǎn)發(fā)
數(shù)據(jù)格式與協(xié)議轉(zhuǎn)換：實現(xiàn)邊緣與云端不同類型的數(shù)據(jù)格式與異構(gòu)協(xié)議之間靈活轉(zhuǎn)換，實現(xiàn)IT&OT融合
部分架構(gòu)圖
Kuiper是裝在 KubeEdge MQTT Broker后面，整個都運行在邊緣端，底下為不同的Mapper，也就是接入各種各樣不同的協(xié)議。邊緣MQTT Broker用來交換消息。
數(shù)據(jù)處理的類型：
從設(shè)備模型文件定義中獲取類型定義
將數(shù)據(jù)轉(zhuǎn)換為Kuiper的數(shù)據(jù)類型
創(chuàng)建流時，可使用schema-less流定義
支持的數(shù)據(jù)類型有int、string、bool、float
下圖為部分配置文件，包括設(shè)備的名稱、屬性、name、data type、Description等。
部分配置文件
保存設(shè)備模型文件
在ect/mqtt_source.yaml中配置模型文件信息
KubeEdgeVersion:目前未使用，為適配將來不同的版本模型文件預留
KubeEdgeModelFile：模型文件路徑
通過config-map下發(fā)配置，保存到相關(guān)目錄下
1）定義流：類似余數(shù)據(jù)庫中表格的定義
DATASOURCE=”$hw/events/device/+/twin/update”為KubeEdge里定義好的topic
2）定義并提交規(guī)則
用SQL實現(xiàn)業(yè)務邏輯，并將運行結(jié)果發(fā)送到指定目標
支持的SQL
SELECT/FROM/WHERE/ORDER
JOIN/GROUP/HAVING
4類時間窗口+1個計數(shù)窗口
60+SQL函數(shù)
3）運行
1）運用Kuiper-Kubernetes-tool
2）該程序為一個工具類，單獨運行在容器中，執(zhí)行通過config-map下發(fā)的命令配置文件
配置文件中用于指定kuiper服務所在的地址和端口等信息
命令文件所在的目錄
3）通過config-map下發(fā)命令執(zhí)行文件，該工具定期自動掃描文件，然后執(zhí)行命令
另外一種方式是通過管理控制臺來管理很多Kuiper節(jié)點，因為Kuiper可以運行在很多節(jié)點上。
比如Kuiper可以運行在車聯(lián)網(wǎng)的盒子里面，車聯(lián)網(wǎng)有很多車，可以通過Kuiper-manager把所有的實例都接入進來，統(tǒng)一對其進行規(guī)則更新。
第一步是安裝插件，我們提供了一些插件的知識，比如要接入不同的源，如果我們這邊的源不支持，則可以自己寫個插件，將插件進行安裝，安裝上去之后我們提供安卓插件界面，就可以使用了。
接下來為創(chuàng)建流定義
下圖為數(shù)據(jù)存儲的位置，下圖所示為將數(shù)據(jù)保存到文件系統(tǒng)，進行路徑的指定。
下圖為可視化的編輯界面，可以進行規(guī)則的編寫。
該案例是一個非常典型的使用場景。K8s+CloudCore部署在云端，將規(guī)則通過管理通道下放到Kuiper，Kuiper的位置是放在MQTT broker，會將數(shù)據(jù)定義，實現(xiàn)數(shù)據(jù)的清洗。目前通道有兩條，第一條是將處理完的消息發(fā)往Cloud MQTT broker，第二條通道比如本地要做數(shù)據(jù)持久化，可將其存到Influxdb這個持續(xù)數(shù)據(jù)庫，我們在邊緣發(fā)生的一些第三方應用可以直接去調(diào)Influxdb里面的數(shù)據(jù)，做一些展示可視化等。底層是通過Mapper把不同的數(shù)據(jù)給接上來。
LF EdgeX Foundry內(nèi)置規(guī)則引擎，于2020年4月Geneva版本中已經(jīng)正式發(fā)布。
實現(xiàn)與ERP、MES等IT系統(tǒng)數(shù)據(jù)交換，我們提供了一個非常靈活的擴展能力，包括異構(gòu)數(shù)據(jù)通過擴展插件采集后，可以利用SQL內(nèi)置函數(shù)或者擴展函數(shù)進行快速、靈活處理；第二點是拿到數(shù)據(jù)處理結(jié)果后，通過sink的數(shù)據(jù)模板可以對分析結(jié)果進行轉(zhuǎn)換，靈活適配各類目標系統(tǒng)所需的數(shù)據(jù)格式和協(xié)議，比如同樣一條溫度大于30度的規(guī)則，如果要去發(fā)送控制設(shè)備的指令，并且要發(fā)到微信上。這兩個不同的目標系統(tǒng)，它所需要的接口和數(shù)據(jù)是不一樣的，但對于這個規(guī)則是一樣的，那么可以在 data里面，根據(jù)同一條規(guī)則觸發(fā)兩個不同的操作，你可以指定不同的 topic，數(shù)據(jù)即可發(fā)送，不需再進行復雜的編程；第三點是利用SAP NetWeaver RFC SDK,實現(xiàn)從SAP中讀取數(shù)據(jù)，處理并轉(zhuǎn)換后發(fā)送到別的異構(gòu)系統(tǒng)。
Kuiper 支持并發(fā)運行數(shù)千條規(guī)則
8000規(guī)則*0.1消息/秒/規(guī)則，共計的TPS為800條/秒
規(guī)則定義
源：MQTT
SQL:select temperature from source where temperature＞20（90%數(shù)據(jù)被過濾）
目標：日志
配置
AWS:2core*4GB
Ubuntu
資源使用
Memory:89%~72%;0.4MB/rule
GPU:25%
AWS t2.micro 配置10k+/s消息吞吐
以上就是KubeEdge和Kuiper解決邊緣流式數(shù)據(jù)處理是怎樣的，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
