在我以前的博客，我們已經(jīng)討論了對物聯(lián)網(wǎng)的炒作和現(xiàn)實(shí)的對比，并介紹了物聯(lián)網(wǎng)服務(wù)的框架。在物聯(lián)網(wǎng)的產(chǎn)業(yè)方面，有一些商業(yè)模式使物聯(lián)網(wǎng)貨幣化。近日，Kaggle已經(jīng)與一家主要工業(yè)集團(tuán)進(jìn)行合作。其目標(biāo)是開發(fā)者和數(shù)據(jù)科學(xué)家們運(yùn)行公共需求以創(chuàng)造最好的新算法，來減少航空旅行延誤。
作為一名飛行常客，我總是驚訝于航班有多少次不得不處于靜止模式并且只是環(huán)繞著機(jī)場。很多因素會導(dǎo)致這些延遲包括天氣狀況、交通擁堵和門的可用性。其中一個(gè)有趣的統(tǒng)計(jì)是，即使是削減掉10英里的平均飛行便可以為航空公司節(jié)省數(shù)百萬美元的燃油成本。
其中物聯(lián)網(wǎng)和大數(shù)據(jù)的銜接是一個(gè)很好的例子。該算法涉及到對飛行的歷史事件、飛行計(jì)劃、飛行軌道（實(shí)際GPS信息），天氣和FAA計(jì)劃的整體歷史分析。物聯(lián)網(wǎng)的真正好處是，飛行修正可以實(shí)時(shí)通過傳感數(shù)據(jù)完成，并且通過大數(shù)據(jù)分析還未出現(xiàn)的模式的可行性。
這帶來了一個(gè)有趣的悖論 –大數(shù)據(jù)的精神分裂癥性質(zhì)。為了提供一個(gè)可操作的見解，實(shí)時(shí)數(shù)據(jù)流分析是必須的。但是，這個(gè)時(shí)間點(diǎn)流傳感器數(shù)據(jù)沒有多大用處，除非我們知道相互依賴的歷史數(shù)據(jù)和相互作用的模式。
傳統(tǒng)的大數(shù)據(jù)解決方案，如Hadoop，依賴于使用各種基于MapReduce的HDFS架構(gòu)進(jìn)行批處理。最近，已經(jīng)有許多個(gè)流處理系統(tǒng)，如正在得到了很多的關(guān)注的ApacheSpark。我們需要一個(gè)統(tǒng)一的基于依賴批處理和流處理的解決方案。作為IT領(lǐng)導(dǎo)者，最后我想要的是一個(gè)架構(gòu)，在那里我可以維護(hù)多個(gè)代碼庫以解決單個(gè)業(yè)務(wù)問題。一種辦法是在MapReduce和風(fēng)暴或類似的系統(tǒng)之上構(gòu)建流處理應(yīng)用程序。
在物聯(lián)網(wǎng)的世界里，最關(guān)鍵的成功因素之一是，我們?nèi)绾文軌虍a(chǎn)生上下文敏感的，真正可操作的警報(bào)。這是一個(gè)老問題，對于這個(gè)問題人們已經(jīng)不再關(guān)注汽車報(bào)警器在停車場熄聲了。在物聯(lián)網(wǎng)解決方案需要緊縮億萬傳感器數(shù)據(jù)元素，并找到可行的模式。例如，什么真正構(gòu)成信用卡購買欺詐交易？什么天氣模式以及飛行員的技能和機(jī)場設(shè)備實(shí)際上會導(dǎo)致延遲？以下提議的架構(gòu)解決了這個(gè)難題。
大數(shù)據(jù)決策模式
有一個(gè)提供實(shí)時(shí)可操作警報(bào)的儀表盤。儀表板獲得其標(biāo)定的動(dòng)力來自一個(gè)規(guī)則引擎。規(guī)則引擎不斷在批處理模式下運(yùn)行，并通過數(shù)據(jù)挖掘算法和機(jī)器學(xué)習(xí)更新自己。實(shí)時(shí)流數(shù)據(jù)通過該批次系統(tǒng)生成動(dòng)態(tài)規(guī)則連續(xù)搜索。這確保了只有在真正需要的時(shí)候警報(bào)才會響起。
一些開源的大數(shù)據(jù)技術(shù)來共同實(shí)現(xiàn)這一架構(gòu)。其中一個(gè)亮點(diǎn)是采用ApacheKafka（高通量分布式消息系統(tǒng)）。Kafka允許監(jiān)聽多個(gè)傳感器的話題，并提供流數(shù)據(jù)到ApacheStorm。Apache Flume 起著輸送成批處理和流式數(shù)據(jù)儲存庫中數(shù)據(jù)的作用。
京公網(wǎng)安備 11010502049343號