工業(yè)場景下IOT數(shù)據(jù)處理

昨天偶然聊起工業(yè)場景下IOT時序處理問題，有人討論時序數(shù)據(jù)庫哪家強，有人詢問數(shù)據(jù)收集應該用云服務商的PaaS還是自己搭建，不一而足。筆者認為沒有最強的產品，只有最合適的架構。拋開具體應用場景而去談單一產品性能，無異于緣木求魚，刻舟求劍。針對客戶具體情況，選擇相應的架構，靈活結合開源工具和云廠商服務；同時以實用性為原則，解決問題而非為了所謂的最新科技而選擇一些實用性有限的產品。在此分享個人一點看法，水平有限，拋磚引玉，歡迎切磋討論。

創(chuàng)新互聯(lián)建站是專業(yè)的三穗網(wǎng)站建設公司，三穗接單;提供網(wǎng)站制作、成都做網(wǎng)站,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行三穗網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

 

首先，我們可以把整個系統(tǒng)分成幾部分，隨后逐一探討。在此暫且采用將整個架構分為，終端、分析、行動三部分。

在“終端”部分，微軟近期動作很大，預期投入50億美金進行IOT研發(fā)的大部分都花在了這里，其中產品AzureSphere備受期待，目前已經(jīng)和臺積電等廠商聯(lián)合生產開發(fā)中，×××還要飛一會~其最大的優(yōu)勢就是雙套安全機制，確保客戶終端安全

暗黑科技Azuresphere傳送門：https://azure.microsoft.com/en-us/services/azure-sphere/

 

在“分析”部分，微軟IOT solution包含了豐富的產品。

傳送門：https://azure.microsoft.com/zh-cn/overview/iot/

 

先從數(shù)據(jù)收集說起，常見幾種收集方式如下：

其中最常被比較的兩種方式為使用云廠商PaaS （在此以微軟IOT Hub，Event Hub為例）vs 開源自建（在此以Kafka為例），對比如下：

	使用微軟服務 （IOT Hub）	使用微軟服務 （Event Hub）	自建 （Kafka）
托管	是	是	無
并行	是	是	是
傳輸方向	雙向	單向	單向
設備管理	有	無	無
傳遞	可配置	至少一次	至少一次
支持協(xié)議	MQTT，HTTPS，AMQP	HTTPS、AMQP 1.0、 Apache Kafka	Kafka
可擴展性	相對高（可輕松擴展到TB級）	相對高（可輕松擴展到TB級）	相對低
直接成本	高	中	低
管理成本	低	低	高

 

真實工業(yè)情況下，能否用云廠商PaaS收集數(shù)據(jù)往往其決定因素的是客戶終端設備，特別是該設備支持的協(xié)議。比方Honeywell的工業(yè)機器大部分可以用微軟IOT收集數(shù)據(jù)；比方Siemens自成體系，并未開放，微軟只能在Siemens自己收集完數(shù)據(jù)，加工整理之后，通過客戶傳給微軟，做做數(shù)據(jù)分析展現(xiàn)之類的后續(xù)工作。

 

其中IOT Hub還在不斷演進當中，接下來devices streams即將登場，會給設備端鏈接帶來更好的易用性和安全性：

https://azure.microsoft.com/zh-cn/blog/introducing-iot-hub-device-streams-in-public-preview/

 

如果客戶使用開源，會常見Kafka, Flume, Storm等名詞，可參見以下blog，內有基礎介紹和分步驟代碼：

http://www.cnblogs.com/smartloli/p/4615908.html

https://www.cnblogs.com/smartloli/p/4632644.html

 

數(shù)據(jù)存儲、計算各家云廠商都有功能強大的服務，所實現(xiàn)功能也大同小異，在此不贅述。謹在此提兩個技術細節(jié)問題供探討：

數(shù)據(jù)庫選擇：時序數(shù)據(jù)庫雖然喧囂之上，但是實際應用者寥寥。針對需要長期展現(xiàn)的類似matrix數(shù)據(jù)有一定應用場景價值。更多情況下，傳統(tǒng)數(shù)據(jù)庫或者Hadoop體系就有均有豐富的最佳實踐，選擇時根據(jù)實際情況而定，簡簡單單能夠解決問題就好。

壓縮數(shù)據(jù)：這項技術特別容易被忽略，但是特別是在大數(shù)據(jù)量情況下可以考慮。在這里需要做一個平衡，就是壓縮和解壓縮帶來計算量的增大和存儲/網(wǎng)絡負載減少之間的取舍。其好處一方面顯而易見的好處是壓縮數(shù)據(jù)可以節(jié)約存儲成本，還有可以在分布式計算情況下節(jié)約各個節(jié)點之間傳輸數(shù)據(jù)的網(wǎng)絡壓力，減少傳輸時間，從而增加運算速度。

常見壓縮工具對比如下：

接下來就是數(shù)據(jù)分析引擎的選擇，常見選擇標準為查詢的兼容性和時延：

 

除了工具推陳出新，隨著架構的演進，現(xiàn)在serverless大行其道，傳統(tǒng)架構也可以進擊發(fā)展為分為fast path和slow path雙通道的全自動連接架構。

 

“行動”部分，根據(jù)客戶具體應用場景而定，有的采用預防性維護，有的采取遠程開關機等等，在此不展開。

 

工業(yè)數(shù)據(jù)分析曾經(jīng)甚囂塵上，似乎傳統(tǒng)制造業(yè)要執(zhí)數(shù)字化轉型之牛耳，言必及GE；而隨著一系列泡沫擠出，Predix也落得一個出售的命運，頗有點“看斜陽照大地阡陌，從頭轉“的味道了。作為從業(yè)人員，大勢不能違，從小處做起，積點滴，匯江海，共勉之。

技術博大精深，個人能力有限，行文粗鄙，拋磚引玉，歡迎探討指正，共精進。

 

參考材料：

微軟IOT參考架構：

Azure IoT Reference Architecture Guide

 

微軟在IOT成熟案例：

Rolls Royce  https://customers.microsoft.com/en-us/story/rollsroycestory

 

POC含具體步驟的blog在此：

https://mp.weixin.qq.com/s/rMJZ2At6AGVqTVZ5ZB0GLA?

POC代碼在此：

https://github.com/jurejoy/Temperature-Forecast

 

新聞標題：工業(yè)場景下IOT數(shù)據(jù)處理
分享路徑：http://bm7419.com/article14/goiode.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供建站公司、品牌網(wǎng)站建設、云服務器、服務器托管、網(wǎng)頁設計公司、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)