在本文中，我們將圍繞物聯(lián)網(wǎng)或流處理系統(tǒng)的一些技術(shù)問題建立完整的基礎(chǔ)和多方面的理解，以便讀者在規(guī)劃物聯(lián)網(wǎng)系統(tǒng)時能夠做出明智的決策或是有根據(jù)地提出問題。我們的意圖是為開始考慮流處理和物聯(lián)網(wǎng)的人們建立多方面的基礎(chǔ)，不管你是否真的需要一個流處理器，我們都將深入到流處理(物聯(lián)網(wǎng)的核心)里面，然后討論 Lambda 架構(gòu)，并給出一些對傳感器可以做什么的大致上的思考。

　　流處理的開源框架

　　事件流處理平臺就像把瑞士軍刀，你可以讓在數(shù)據(jù)流里運動的數(shù)據(jù)(data-in-motion)做幾乎任何你想做的事情。

　　了解 ESP 體系結(jié)構(gòu)的最簡單的方法是將其視為三個層面或三個功能 —— 輸入，處理和輸出。

　　輸入層會接受幾乎所有類型的基于時間的流數(shù)據(jù)，并經(jīng)常有存在多個輸入流的情況。在主 ESP 處理器中會發(fā)生各種會被稱為程序或操作的動作。這些程序的結(jié)果會傳遞給訂閱者的一些接口，后者可以通過人機(jī)界面發(fā)送警報或創(chuàng)建機(jī)器來進(jìn)行自動操作，并將數(shù)據(jù)傳遞給像 Fast 和 Forever 這樣的數(shù)據(jù)存儲服務(wù)里。

　　流處理平臺確實可以直接接收數(shù)據(jù)流，但要注意他們并不善于保存一些會意外丟失的數(shù)據(jù)，因此你仍然會需要像 Kafka 這樣的一個能夠回退并重放丟失的數(shù)據(jù)的數(shù)據(jù)采集端。在不久的將來，很多流處理器可能會解決這個問題，然后你就需要重新考慮 Kafka 端的必要性了。

　　流處理的要求

　　對流處理器常會有這些要求：

　　高速 ：視具體具體業(yè)務(wù)需求而定，通常每秒要能采集并處理數(shù)百萬個事件。

　　易擴(kuò)展 ：全部東西都要在分布式集群上運行。

　　容錯 ：這與保證不丟失數(shù)據(jù)不同。

　　確定處理 ：這有兩種做法：每個事件至少處理一次，和每個事件正好處理一次。不過 “正好處理一次” 的標(biāo)準(zhǔn)很難保證。這是我們將放在稍后討論的一個深入的主題。

　　能執(zhí)行你的應(yīng)用程序運行的必需程序

　　ESP 程序能做什么?

　　在采集端進(jìn)行數(shù)據(jù)清理的能力(類似于一種迷你 MDM)是其功能強(qiáng)大的真正體現(xiàn)。在數(shù)據(jù)清理之后會多次復(fù)制數(shù)據(jù)流，以便每個相同的數(shù)據(jù)流可以同時用于不同的分析程序中，而不用讓這些程序程序排隊等待前面的分析程序完成分析。下面是一個醫(yī)療業(yè)務(wù)示例的圖表，該示例描述了一種在上一章提到過的工作方式，說明了多個數(shù)據(jù)流會由靜態(tài)數(shù)據(jù)來擴(kuò)大，并會由不同類型的邏輯同時處理。每個塊都表示了在 ESP 中需要由你來編寫的單獨程序。

　　有很多不同類型的邏輯可以通過這些 ESP 程序來得到應(yīng)用，包括：

　　計算

　　復(fù)制，建立多個處理路徑 —— 每個處理路徑具有不同的保留時間，例如 5 - 15 分鐘。

　　統(tǒng)計

　　計數(shù)

　　過濾，它讓你能只從數(shù)據(jù)流中保留有用的數(shù)據(jù)，并放棄其余數(shù)據(jù)，從而大大減少存儲空間。

　　函數(shù)(用于變換)

　　合并多個流為一個

　　通知性質(zhì)的電子郵件，文字或多媒體形式

　　模式(特定關(guān)注事件的 EOI，用于檢測)

　　流程(用于應(yīng)用高級的預(yù)測模型)

　　文本內(nèi)容，用于檢測例如受關(guān)注的推特模式這樣的信息。

　　文本情感，用于監(jiān)控社交媒體流中的積極或消極的情緒。

　　開源的和專有的軟件包在能做的工作上都有著一些區(qū)別，因此你應(yīng)該根據(jù)你所需要完成的東西來核對這些軟件包的內(nèi)容。

　　流處理的開源選項

　　主要的開源框架選項(全是 Apache 的)如下：

　　Samza： 一個分布式的流處理框架。它使用 Kafka 來進(jìn)行消息傳遞，由 YARN 來提供容錯性、處理器隔離、安全性，以及資源管理。

　　NiFi：這是一個相當(dāng)新興的開源項目，仍處于完善之中。它與其他項目的區(qū)別在于它有用戶友好的拖曳式的圖形界面，以及我們可以輕松地根據(jù)特定需求來對它進(jìn)行定制。

　　Storm：一款經(jīng)過充分測試的基于事件的流處理器。它最初由推特開發(fā)。

　　SPARK Streaming： SPARK Streaming 是 SPARK 的四個組成部分之一，它是第一個能在單一企業(yè)級平臺上整合批量處理和流處理的組件。

　　SPARK 流媒體和 Storm：最常見的開源軟件包

　　SPARK 已被推出好幾年了，但在去年它的使用率有了驚人的增長，現(xiàn)已在大多數(shù)新項目中取代了 Hadoop / MapReduce 的地位，并且許多既有的 Hadoop / MapReduce 系統(tǒng)也都遷移到了 SPARK。SPARK 的開發(fā)工作正在朝著成為物聯(lián)網(wǎng)應(yīng)用所需的唯一技術(shù)棧發(fā)展。

　　SPARK 由五個組件組成，所有這些組件都支持 Scala，Java，Python 還有 R 語言。

　　SPARK ：作為一個在系統(tǒng)中處于核心地位的應(yīng)用程序，它是一個與 HDFS 和其他 NoSQL DB 兼容的批處理引擎。它能比 Hadoop / MapReduce 快 10 倍到 100 倍，因此它十分流行。

　　ML.lib ：一個自帶的功能強(qiáng)大的數(shù)據(jù)科學(xué)以及機(jī)器學(xué)習(xí)算法庫。

　　SPARK SQL ：用于直接支持 SQL 查詢。

　　SPARK Streaming ：SPARK 集成的流處理引擎。

　　GraphX ：強(qiáng)大的圖形數(shù)據(jù)庫引擎，可用于流式應(yīng)用程序之外。

　　相比之下，Storm 就是一個純粹的事件流處理器。Storm 和 SPARK Streaming 之間的差異不大，不過它們?yōu)閭魅霐?shù)據(jù)分區(qū)的方式便截然不同了。這是后面討論的一個進(jìn)一步的話題。

　　如果你已經(jīng)熟悉了關(guān)于數(shù)據(jù)分區(qū)的知識并且確定這不會對你的應(yīng)用造成損害，那么開源的 SPARK / SPARK Streaming 便是最好的選擇。

　　Lambda 架構(gòu)：速度加上安全

　　IoT 流處理應(yīng)用的標(biāo)準(zhǔn)參考體系結(jié)構(gòu)被稱為 Lambda 體系結(jié)構(gòu) ，該體系結(jié)構(gòu)包含一個 加速層(Speed Layer) 和一個 安全層(Safety Layer) 。

　　傳入數(shù)據(jù)流會由數(shù)據(jù)采集應(yīng)用(Kafka)復(fù)制，并朝兩個方向發(fā)送，一個是安全層，另一個是流處理平臺(SPARK Streaming 或 Storm)。這可以確保丟失的數(shù)據(jù)都得以找回，以確保所有數(shù)據(jù)都至少得到了一次處理。

　　對流處理端的查詢可能是提取靜態(tài)數(shù)據(jù)來加到流處理器中的數(shù)據(jù)流，或者可能用于通過任意數(shù)量的媒體(包括電子郵件，SMS，客戶的應(yīng)用程序，還有儀表板)向下游的事件消費者發(fā)送消息、警報或數(shù)據(jù)。警報也是在流處理器中的本地環(huán)境生成的。

　　對安全層的存儲的查詢將被批量用于創(chuàng)建進(jìn)一步的分析過程并嵌入到流處理器中，或者用于響應(yīng)特殊查詢，例如開發(fā)新的預(yù)測模型。

　　你真的需要一個流處理器嗎?

　　你應(yīng)該在設(shè)計物聯(lián)網(wǎng)平臺時考慮到引入流處理器的必要性。對某些只需要很少數(shù)量或很少種類的傳感器的情況，省掉流處理器自身會帶來的系統(tǒng)復(fù)雜度可能會更好。

　　如果 “實時“ 這段時間很長

　　當(dāng)實時交互的時間相當(dāng)長的時候，例如在通知終端用戶任何新的發(fā)現(xiàn)只能每天發(fā)生一次或甚至更少時，對傳感器的數(shù)據(jù)進(jìn)行批量處理在一些情況下是完全合理的。

　　從架構(gòu)的立場來看，傳感器數(shù)據(jù)將到達(dá)數(shù)據(jù)采集應(yīng)用(Kafka)并直接發(fā)送到存儲器里面。若使用常規(guī)的批處理程序，今天的數(shù)據(jù)會在夜里被分析，并且需要發(fā)送給用戶的任何重要信號會放到第二天才發(fā)送。

　　當(dāng) “實時” 會是 24 小時或更長的時間，在某些情況下至多縮短至 12 小時左右時，批處理會是一個可行的選擇。如果實時交互的時間需求比這更短，流處理會是一個更具吸引力的選擇。

　　其實配置流處理來評估任何時間段(包括數(shù)天，數(shù)周甚至數(shù)月)的數(shù)據(jù)也是可以的，但在某些時候簡化系統(tǒng)的價值會超過引入流處理的價值。

　　傳感器數(shù)據(jù)的四種應(yīng)用

　　傳感器數(shù)據(jù)有四種范圍很廣的應(yīng)用。這也可以為你決定是否引入流處理提供參考。以下舉一些例子。

　　直接使用：例如，直接從傳感器讀取 GPS 坐標(biāo)，然后把坐標(biāo)放到地圖上，就能輕松創(chuàng)建出一個 “手機(jī)去哪里” 的小應(yīng)用。這一應(yīng)用可能還需要引入與用戶有關(guān)的靜態(tài)數(shù)據(jù)(比如，需要知道用戶的居住地址來限制顯示地圖的比例)，而這可以通過標(biāo)準(zhǔn)表連接(standard table join)來在流處理器外部完成，也可以在流處理器里面完成。

　　專家規(guī)則：不用數(shù)據(jù)科學(xué)，編寫能為傳入數(shù)據(jù)流賦予意義的規(guī)則也是可行的。例如，可以設(shè)計了一個專家規(guī)則來與患者的靜態(tài)數(shù)據(jù)相結(jié)合，讓這一規(guī)則在患者體溫達(dá)到 103° 的時候呼叫醫(yī)護(hù)幫助。

　　預(yù)測分析：接下來的兩個應(yīng)用程序都屬于數(shù)據(jù)科學(xué)領(lǐng)域。數(shù)據(jù)科學(xué)家會使用預(yù)測分析技術(shù)來在數(shù)據(jù)中找到有意義的信息。

　　無監(jiān)督學(xué)習(xí)： 在預(yù)測分析中，無監(jiān)督學(xué)習(xí)意味著應(yīng)用像聚類(clustering)和細(xì)分(segementation)這樣的技術(shù)，而這些技術(shù)不需要指示了特定的結(jié)果的歷史數(shù)據(jù)。例如，F(xiàn)itBit 里的加速度計可以很容易地了解到你現(xiàn)在的活動比最近活躍還是不活躍，或者你比其他一些你拿來比較的 FitBit 用戶相對活躍還是不活躍。給閱讀這一過程賦予一些內(nèi)容就可能需要引入用戶的靜態(tài)數(shù)據(jù)。

　　無監(jiān)督學(xué)習(xí)的優(yōu)勢在于，它在放置傳感器之后幾乎就可以立即部署起來，畢竟它不需要花大量時間用訓(xùn)練數(shù)據(jù)來建立模型。

　　給定發(fā)送警報的閾值會需要一些無監(jiān)督建模方法的幫助。例如一個符合標(biāo)準(zhǔn)的消息的更改周期可以設(shè)為應(yīng)該超出每天 20% 或一個相似用戶組的標(biāo)準(zhǔn)差。

　　這些算法會由數(shù)據(jù)科學(xué)家根據(jù)批量處理數(shù)據(jù)進(jìn)行完善并導(dǎo)出到流處理器中，作為公式應(yīng)用于數(shù)據(jù)流。

　　監(jiān)督學(xué)習(xí)：使用訓(xùn)練數(shù)據(jù)來開發(fā)預(yù)測模型，而在訓(xùn)練數(shù)據(jù)中結(jié)果是已知的。這又需要部分檢測到了行為和當(dāng)前狀態(tài)的樣例，還有一部分狀態(tài)未知的樣例。

　　例如，我們可以記錄電機(jī)的溫度，振動和功耗，以及測量后 12 小時內(nèi)電機(jī)是否發(fā)生故障。如果有足夠多的訓(xùn)練數(shù)據(jù)，我們就可以開發(fā)出一個預(yù)測模型，提前 12 小時預(yù)測可能發(fā)生的障礙。

　　然后將以代數(shù)公式(幾行 C，Java，Python 或 R 代碼)形式表示的模型導(dǎo)出到流處理器，以便在處理數(shù)據(jù)流時對數(shù)據(jù)進(jìn)行評分，當(dāng)分?jǐn)?shù)顯示即將發(fā)生故障時自動發(fā)送警報。

　　在流處理中使用復(fù)雜的預(yù)測模型很有好處。不過如果想要預(yù)測的事件很罕見，比如這一事件占所有測量數(shù)據(jù)的比例很小，或者這一事件需要很長時間才可能發(fā)生一次(收集足夠的訓(xùn)練數(shù)據(jù)要等上很長時間)，那么收集足夠的訓(xùn)練數(shù)據(jù)就會是個問題。