歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
在本文中，我們將圍繞物聯網或流處理系統的一些技術問題建立完整的基礎和多方面的理解，以便讀者在規劃物聯網系統時能夠做出明智的決策或是有根據地提出問題。我們的意圖是為開始考慮流處理和物聯網的人們建立多方面的基礎，不管你是否真的需要一個流處理器，我們都將深入到流處理（物聯網的核心）裡面，然後討論 Lambda 架構，並給出一些對感測器可以做什麼的大致上的思考。
流處理的開源框架
事件流處理平臺就像把瑞士軍刀，你可以讓在資料流裡運動的資料（data-in-motion）做幾乎任何你想做的事情。
瞭解 ESP 體系結構的最簡單的方法是將其視為三個層面或三個功能 —— 輸入，處理和輸出。
輸入層會接受幾乎所有型別的基於時間的流資料，並經常有存在多個輸入流的情況。在主 ESP 處理器中會發生各種會被稱為程式或操作的動作。這些程式的結果會傳遞給訂閱者的一些介面，後者可以通過人機介面傳送警報或建立機器來進行自動操作，並將資料傳遞給像 Fast 和 Forever 這樣的資料儲存服務裡。
流處理平臺確實可以直接接收資料流，但要注意他們並不善於儲存一些會意外丟失的資料，因此你仍然會需要像 Kafka 這樣的一個能夠回退並重放丟失的資料的資料採集端。在不久的將來，很多流處理器可能會解決這個問題，然後你就需要重新考慮 Kafka 端的必要性了。
流處理的要求
對流處理器常會有這些要求：
- 高速：視具體具體業務需求而定，通常每秒要能採集並處理數百萬個事件。
- 易擴充套件：全部東西都要在分散式叢集上執行。
- 容錯：這與保證不丟失資料不同。
- 確定處理：這有兩種做法：每個事件至少處理一次，和每個事件正好處理一次。不過 “正好處理一次” 的標準很難保證。這是我們將放在稍後討論的一個深入的主題。
- 能執行你的應用程式執行的必需程式
ESP 程式能做什麼？
在採集端進行資料清理的能力（類似於一種迷你 MDM）是其功能強大的真正體現。在資料清理之後會多次複製資料流，以便每個相同的資料流可以同時用於不同的分析程式中，而不用讓這些程式程式排隊等待前面的分析程式完成分析。下面是一個醫療業務示例的圖表，該示例描述了一種在上一章提到過的工作方式，說明了多個資料流會由靜態資料來擴大，並會由不同型別的邏輯同時處理。每個塊都表示了在 ESP 中需要由你來編寫的單獨程式。
有很多不同型別的邏輯可以通過這些 ESP 程式來得到應用，包括：
- 計算
- 複製，建立多個處理路徑 —— 每個處理路徑具有不同的保留時間，例如 5 - 15 分鐘。
- 統計
- 計數
- 過濾，它讓你能只從資料流中保留有用的資料，並放棄其餘資料，從而大大減少儲存空間。
- 函式（用於變換）
- 合併多個流為一個
- 通知性質的電子郵件，文字或多媒體形式
- 模式（特定關注事件的 EOI，用於檢測）
- 流程（用於應用高階的預測模型）
- 文字內容，用於檢測例如受關注的推特模式這樣的資訊。
- 文字情感，用於監控社交媒體流中的積極或消極的情緒。
開源的和專有的軟體包在能做的工作上都有著一些區別，因此你應該根據你所需要完成的東西來核對這些軟體包的內容。
流處理的開源選項
主要的開源框架選項（全是 Apache 的）如下：
Samza： 一個分散式的流處理框架。它使用 Kafka 來進行訊息傳遞，由 YARN 來提供容錯性、處理器隔離、安全性，以及資源管理。
NiFi：這是一個相當新興的開源專案，仍處於完善之中。它與其他專案的區別在於它有使用者友好的拖曳式的圖形介面，以及我們可以輕鬆地根據特定需求來對它進行定製。
Storm：一款經過充分測試的基於事件的流處理器。它最初由推特開發。
SPARK Streaming： SPARK Streaming 是 SPARK 的四個組成部分之一，它是第一個能在單一企業級平臺上整合批量處理和流處理的元件。
SPARK 流媒體和 Storm：最常見的開源軟體包
SPARK 已被推出好幾年了，但在去年它的使用率有了驚人的增長，現已在大多數新專案中取代了 Hadoop / MapReduce 的地位，並且許多既有的 Hadoop / MapReduce 系統也都遷移到了 SPARK。SPARK 的開發工作正在朝著成為物聯網應用所需的唯一技術棧發展。
SPARK 由五個元件組成，所有這些元件都支援 Scala，Java，Python 還有 R 語言。
- SPARK：作為一個在系統中處於核心地位的應用程式，它是一個與 HDFS 和其他 NoSQL DB 相容的批處理引擎。它能比 Hadoop / MapReduce 快 10 倍到 100 倍，因此它十分流行。
- ML.lib：一個自帶的功能強大的資料科學以及機器學習演算法庫。
- SPARK SQL：用於直接支援 SQL 查詢。
- SPARK Streaming：SPARK 整合的流處理引擎。
- GraphX：強大的圖形資料庫引擎，可用於流式應用程式之外。
相比之下，Storm 就是一個純粹的事件流處理器。Storm 和 SPARK Streaming 之間的差異不大，不過它們為傳入資料分割槽的方式便截然不同了。這是後面討論的一個進一步的話題。
如果你已經熟悉了關於資料分割槽的知識並且確定這不會對你的應用造成損害，那麼開源的 SPARK / SPARK Streaming 便是最好的選擇。
Lambda 架構：速度加上安全
IoT 流處理應用的標準參考體系結構被稱為 Lambda 體系結構，該體系結構包含一個加速層（Speed Layer）和一個安全層（Safety Layer）。
傳入資料流會由資料採集應用（Kafka）複製，並朝兩個方向傳送，一個是安全層，另一個是流處理平臺（SPARK Streaming 或 Storm）。這可以確保丟失的資料都得以找回，以確保所有資料都至少得到了一次處理。
對流處理端的查詢可能是提取靜態資料來加到流處理器中的資料流，或者可能用於通過任意數量的媒體（包括電子郵件，SMS，客戶的應用程式，還有儀表板）向下遊的事件消費者傳送訊息、警報或資料。警報也是在流處理器中的本地環境生成的。
對安全層的儲存的查詢將被批量用於建立進一步的分析過程並嵌入到流處理器中，或者用於響應特殊查詢，例如開發新的預測模型。
你真的需要一個流處理器嗎？
你應該在設計物聯網平臺時考慮到引入流處理器的必要性。對某些只需要很少數量或很少種類的感測器的情況，省掉流處理器自身會帶來的系統複雜度可能會更好。
如果 “實時“ 這段時間很長
當實時互動的時間相當長的時候，例如在通知終端使用者任何新的發現只能每天發生一次或甚至更少時，對感測器的資料進行批量處理在一些情況下是完全合理的。
從架構的立場來看，感測器資料將到達資料採集應用（Kafka）並直接傳送到儲存器裡面。若使用常規的批處理程式，今天的資料會在夜裡被分析，並且需要傳送給使用者的任何重要訊號會放到第二天才傳送。
當 “實時” 會是 24 小時或更長的時間，在某些情況下至多縮短至 12 小時左右時，批處理會是一個可行的選擇。如果實時互動的時間需求比這更短，流處理會是一個更具吸引力的選擇。
其實配置流處理來評估任何時間段（包括數天，數週甚至數月）的資料也是可以的，但在某些時候簡化系統的價值會超過引入流處理的價值。
感測器資料的四種應用
感測器資料有四種範圍很廣的應用。這也可以為你決定是否引入流處理提供參考。以下舉一些例子。
直接使用：例如，直接從感測器讀取 GPS 座標，然後把座標放到地圖上，就能輕鬆建立出一個 “手機去哪裡” 的小應用。這一應用可能還需要引入與使用者有關的靜態資料（比如，需要知道使用者的居住地址來限制顯示地圖的比例），而這可以通過標準表連線（standard table join）來在流處理器外部完成，也可以在流處理器裡面完成。
專家規則：不用資料科學，編寫能為傳入資料流賦予意義的規則也是可行的。例如，可以設計了一個專家規則來與患者的靜態資料相結合，讓這一規則在患者體溫達到 103° 的時候呼叫醫護幫助。
預測分析：接下來的兩個應用程式都屬於資料科學領域。資料科學家會使用預測分析技術來在資料中找到有意義的資訊。
無監督學習： 在預測分析中，無監督學習意味著應用像聚類（clustering）和細分（segementation）這樣的技術，而這些技術不需要指示了特定的結果的歷史資料。例如，FitBit 裡的加速度計可以很容易地瞭解到你現在的活動比最近活躍還是不活躍，或者你比其他一些你拿來比較的 FitBit 使用者相對活躍還是不活躍。給閱讀這一過程賦予一些內容就可能需要引入使用者的靜態資料。
無監督學習的優勢在於，它在放置感測器之後幾乎就可以立即部署起來，畢竟它不需要花大量時間用訓練資料來建立模型。
給定傳送警報的閾值會需要一些無監督建模方法的幫助。例如一個符合標準的訊息的更改週期可以設為應該超出每天 20％ 或一個相似使用者組的標準差。
這些演算法會由資料科學家根據批量處理資料進行完善並匯出到流處理器中，作為公式應用於資料流。
監督學習：使用訓練資料來開發預測模型，而在訓練資料中結果是已知的。這又需要部分檢測到了行為和當前狀態的樣例，還有一部分狀態未知的樣例。
例如，我們可以記錄電機的溫度，振動和功耗，以及測量後 12 小時內電機是否發生故障。如果有足夠多的訓練資料，我們就可以開發出一個預測模型，提前 12 小時預測可能發生的障礙。
然後將以代數公式（幾行 C，Java，Python 或 R 程式碼）形式表示的模型匯出到流處理器，以便在處理資料流時對資料進行評分，當分數顯示即將發生故障時自動傳送警報。
在流處理中使用複雜的預測模型很有好處。不過如果想要預測的事件很罕見，比如這一事件佔所有測量資料的比例很小，或者這一事件需要很長時間才可能發生一次（收集足夠的訓練資料要等上很長時間），那麼收集足夠的訓練資料就會是個問題。
問答
基於雲端計算的物聯網應用場景有哪些？
相關閱讀
啟動物聯網專案所需的一切：第 1 章
啟動物聯網專案所需的一切：第 3 章
此文已由作者授權騰訊雲+社群釋出，原文連結：https://cloud.tencent.com/developer/article/1098214?fromSource=waitui
