啓動物聯網項目所需的一切：關於流處理

時間 2020-01-22

標籤啓動聯網項目所需一切關於處理简体版

原文原文鏈接

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~算法

在本文中，咱們將圍繞物聯網或流處理系統的一些技術問題創建完整的基礎和多方面的理解，以便讀者在規劃物聯網系統時可以作出明智的決策或是有根據地提出問題。咱們的意圖是爲開始考慮流處理和物聯網的人們創建多方面的基礎，無論你是否真的須要一個流處理器，咱們都將深刻到流處理（物聯網的核心）裏面，而後討論 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 的四個組成部分之一，它是第一個能在單一企業級平臺上整合批量處理和流處理的組件。oop

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 代碼）形式表示的模型導出到流處理器，以便在處理數據流時對數據進行評分，當分數顯示即將發生故障時自動發送警報。

在流處理中使用複雜的預測模型頗有好處。不過若是想要預測的事件很罕見，好比這一事件佔全部測量數據的比例很小，或者這一事件須要很長時間纔可能發生一次（收集足夠的訓練數據要等上很長時間），那麼收集足夠的訓練數據就會是個問題。