昨天偶然聊起工業(yè)場(chǎng)景下IOT時(shí)序處理問(wèn)題,有人討論時(shí)序數(shù)據(jù)庫(kù)哪家強(qiáng),有人詢問(wèn)數(shù)據(jù)收集應(yīng)該用云服務(wù)商的PaaS還是自己搭建,不一而足。筆者認(rèn)為沒有最強(qiáng)的產(chǎn)品,只有最合適的架構(gòu)。拋開具體應(yīng)用場(chǎng)景而去談單一產(chǎn)品性能,無(wú)異于緣木求魚,刻舟求劍。針對(duì)客戶具體情況,選擇相應(yīng)的架構(gòu),靈活結(jié)合開源工具和云廠商服務(wù);同時(shí)以實(shí)用性為原則,解決問(wèn)題而非為了所謂的最新科技而選擇一些實(shí)用性有限的產(chǎn)品。在此分享個(gè)人一點(diǎn)看法,水平有限,拋磚引玉,歡迎切磋討論。
成都網(wǎng)絡(luò)公司-成都網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)10余年經(jīng)驗(yàn)成就非凡,專業(yè)從事成都網(wǎng)站制作、成都網(wǎng)站建設(shè),成都網(wǎng)頁(yè)設(shè)計(jì),成都網(wǎng)頁(yè)制作,軟文發(fā)稿,1元廣告等。10余年來(lái)已成功提供全面的成都網(wǎng)站建設(shè)方案,打造行業(yè)特色的成都網(wǎng)站建設(shè)案例,建站熱線:028-86922220,我們期待您的來(lái)電!首先,我們可以把整個(gè)系統(tǒng)分成幾部分,隨后逐一探討。在此暫且采用將整個(gè)架構(gòu)分為,終端、分析、行動(dòng)三部分。
在“終端”部分,微軟近期動(dòng)作很大,預(yù)期投入50億美金進(jìn)行IOT研發(fā)的大部分都花在了這里,其中產(chǎn)品AzureSphere備受期待,目前已經(jīng)和臺(tái)積電等廠商聯(lián)合生產(chǎn)開發(fā)中,×××還要飛一會(huì)~其大的優(yōu)勢(shì)就是雙套安全機(jī)制,確??蛻艚K端安全
暗黑科技Azuresphere傳送門:https://azure.microsoft.com/en-us/services/azure-sphere/
在“分析”部分,微軟IOT solution包含了豐富的產(chǎn)品。
傳送門:https://azure.microsoft.com/zh-cn/overview/iot/
先從數(shù)據(jù)收集說(shuō)起,常見幾種收集方式如下:
其中最常被比較的兩種方式為使用云廠商PaaS (在此以微軟IOT Hub,Event Hub為例)vs 開源自建(在此以Kafka為例),對(duì)比如下:
使用微軟服務(wù) (IOT Hub) | 使用微軟服務(wù) (Event Hub) | 自建 (Kafka) | |
托管 | 是 | 是 | 無(wú) |
并行 | 是 | 是 | 是 |
傳輸方向 | 雙向 | 單向 | 單向 |
設(shè)備管理 | 有 | 無(wú) | 無(wú) |
傳遞 | 可配置 | 至少一次 | 至少一次 |
支持協(xié)議 | MQTT,HTTPS,AMQP | HTTPS、AMQP 1.0、 Apache Kafka | Kafka |
可擴(kuò)展性 | 相對(duì)高(可輕松擴(kuò)展到TB級(jí)) | 相對(duì)高(可輕松擴(kuò)展到TB級(jí)) | 相對(duì)低 |
直接成本 | 高 | 中 | 低 |
管理成本 | 低 | 低 | 高 |
真實(shí)工業(yè)情況下,能否用云廠商PaaS收集數(shù)據(jù)往往其決定因素的是客戶終端設(shè)備,特別是該設(shè)備支持的協(xié)議。比方Honeywell的工業(yè)機(jī)器大部分可以用微軟IOT收集數(shù)據(jù);比方Siemens自成體系,并未開放,微軟只能在Siemens自己收集完數(shù)據(jù),加工整理之后,通過(guò)客戶傳給微軟,做做數(shù)據(jù)分析展現(xiàn)之類的后續(xù)工作。
其中IOT Hub還在不斷演進(jìn)當(dāng)中,接下來(lái)devices streams即將登場(chǎng),會(huì)給設(shè)備端鏈接帶來(lái)更好的易用性和安全性:
https://azure.microsoft.com/zh-cn/blog/introducing-iot-hub-device-streams-in-public-preview/
如果客戶使用開源,會(huì)常見Kafka, Flume, Storm等名詞,可參見以下blog,內(nèi)有基礎(chǔ)介紹和分步驟代碼:
http://www.cnblogs.com/smartloli/p/4615908.html
https://www.cnblogs.com/smartloli/p/4632644.html
數(shù)據(jù)存儲(chǔ)、計(jì)算各家云廠商都有功能強(qiáng)大的服務(wù),所實(shí)現(xiàn)功能也大同小異,在此不贅述。謹(jǐn)在此提兩個(gè)技術(shù)細(xì)節(jié)問(wèn)題供探討:
數(shù)據(jù)庫(kù)選擇:時(shí)序數(shù)據(jù)庫(kù)雖然喧囂之上,但是實(shí)際應(yīng)用者寥寥。針對(duì)需要長(zhǎng)期展現(xiàn)的類似matrix數(shù)據(jù)有一定應(yīng)用場(chǎng)景價(jià)值。更多情況下,傳統(tǒng)數(shù)據(jù)庫(kù)或者Hadoop體系就有均有豐富的最佳實(shí)踐,選擇時(shí)根據(jù)實(shí)際情況而定,簡(jiǎn)簡(jiǎn)單單能夠解決問(wèn)題就好。
壓縮數(shù)據(jù):這項(xiàng)技術(shù)特別容易被忽略,但是特別是在大數(shù)據(jù)量情況下可以考慮。在這里需要做一個(gè)平衡,就是壓縮和解壓縮帶來(lái)計(jì)算量的增大和存儲(chǔ)/網(wǎng)絡(luò)負(fù)載減少之間的取舍。其好處一方面顯而易見的好處是壓縮數(shù)據(jù)可以節(jié)約存儲(chǔ)成本,還有可以在分布式計(jì)算情況下節(jié)約各個(gè)節(jié)點(diǎn)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)壓力,減少傳輸時(shí)間,從而增加運(yùn)算速度。
常見壓縮工具對(duì)比如下:
接下來(lái)就是數(shù)據(jù)分析引擎的選擇,常見選擇標(biāo)準(zhǔn)為查詢的兼容性和時(shí)延:
除了工具推陳出新,隨著架構(gòu)的演進(jìn),現(xiàn)在serverless大行其道,傳統(tǒng)架構(gòu)也可以進(jìn)擊發(fā)展為分為fast path和slow path雙通道的全自動(dòng)連接架構(gòu)。
“行動(dòng)”部分,根據(jù)客戶具體應(yīng)用場(chǎng)景而定,有的采用預(yù)防性維護(hù),有的采取遠(yuǎn)程開關(guān)機(jī)等等,在此不展開。
工業(yè)數(shù)據(jù)分析曾經(jīng)甚囂塵上,似乎傳統(tǒng)制造業(yè)要執(zhí)數(shù)字化轉(zhuǎn)型之牛耳,言必及GE;而隨著一系列泡沫擠出,Predix也落得一個(gè)出售的命運(yùn),頗有點(diǎn)“看斜陽(yáng)照大地阡陌,從頭轉(zhuǎn)“的味道了。作為從業(yè)人員,大勢(shì)不能違,從小處做起,積點(diǎn)滴,匯江海,共勉之。
技術(shù)博大精深,個(gè)人能力有限,行文粗鄙,拋磚引玉,歡迎探討指正,共精進(jìn)。
參考材料:
微軟IOT參考架構(gòu):
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
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無(wú)理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì),專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。