Azure 串流分析解決方案模式

如同 Azure 中的其他許多服務，串流分析最適合與其他服務搭配使用，以建立較大的端對端解決方案。 本文討論簡單的 Azure 串流分析解決方案和各種架構模式。 您可以在這些模式的基礎上建置，以開發更複雜的解決方案。 本文所述的模式可用於各種案例。 案例特定模式的範例可以在 Azure 解決方案架構上取得。

建立串流分析作業以增強即時儀表板體驗

使用 Azure 串流分析時，您可以快速地建立即時儀表板和警示。 簡單的解決方案會從事件中樞或 IoT 中樞擷取事件，並使用串流資料集饋送 Power BI 儀表板。 如需詳細資訊，請參閱詳細教學課程使用串流分析來分析詐騙通話資料，並在 Power BI 儀表板中將結果視覺化。

只需要幾分鐘的時間即可從 Azure 入口網站建置此解決方案。 沒有涉及大量編碼，而且 SQL 語言用來表達商務邏輯。

此解決方案模式提供從事件來源到瀏覽器中 Power BI 儀表板的最低延遲。 Azure 串流分析是唯一具有此內建功能的 Azure 服務。

針對儀表板使用 SQL

Power BI 儀表板提供低延遲，但是無法用來產生完整的 Power BI 報表。 常見的報告模式是先將資料輸出至 SQL Database。 然後使用 Power BI 的 SQL 連接器來查詢 SQL 以取得最新的資料。

使用 SQL Database 可讓您更有彈性，但是代價是有較高的延遲。 此解決方案最適合延遲需求大於一秒的作業。 透過此方法，您可以將 Power BI 功能最大化，以進一步配量和切割報表的資料，以及更多視覺效果選項。 您也可以獲得使用其他儀表板解決方案的彈性，例如 Tableau。

SQL 不是高輸送量資料存放區。 從 Azure 串流分析到 SQL Database 的最大輸送量目前大約為 24 MB/秒。 如果您的解決方案中的事件來源以較高的速率產生資料，您必須在串流分析中使用處理邏輯，以降低前往 SQL 的輸出速率。 您可以使用篩選、視窗型彙總、具有時態性聯結的模式比對，以及分析函式等技術。 前往 SQL 的輸出速率可以使用 Azure 串流分析輸出至 Azure SQL Database 中所述的技術進一步最佳化。

使用事件傳訊將即時深入解析納入您的應用程式中

串流分析的第二個最常使用方式是產生即時警示。 在此解決方案模式中，串流分析中的商務邏輯可以用來偵測時態性和空間模式或異常，然後產生警示訊號。 不過，不同於串流分析在其中使用 Power BI 作為慣用端點的儀表板解決方案，您可以使用各種中繼資料接收器。 這些接收器包括事件中樞、服務匯流排和 Azure Functions。 做為應用程式建立者，您必須決定最適合您情節的資料接收器。

必須實作下游事件消費者邏輯，才能在現有的商務工作流程中產生警示。 因為您可以在 Azure Functions 中實作自訂邏輯，所以 Azure Functions 是您可以執行此整合的最快速方式。 使用 Azure 函式作為串流分析作業輸出的教學課程，可在從 Azure 串流分析作業執行 Azure Functions 中找到。 Azure Functions 也支援各種類型的通知，包括文字和電子郵件。 邏輯應用程式也可用於這類整合，搭配串流分析與邏輯應用程式之間的事件中樞。

另一方面，事件中樞提供最有彈性的整合點。 許多其他服務 (例如 Azure 資料總管和時間序列深入解析) 都可以取用來自事件中樞的事件。 這些服務可以直接從 Azure 串流分析連線到事件中樞接收器，以完成解決方案。 事件中樞也是 Azure 上可供這類整合案例使用的最高輸送量傳訊訊息代理程式。

動態應用程式和網站

您可以使用 Azure 串流分析和 Azure SignalR Service，建立自訂的即時視覺效果，例如儀表板或地圖視覺效果。 使用 SignalR，Web 用戶端可以即時更新並顯示動態內容。

透過資料存放區將即時深入解析併入您的應用程式

現今大部分的 Web 服務和 Web 應用程式都會使用要求/回應模式來提供展示層。 要求/回應模式很容易建置，且可以使用無狀態前端和可調整的存放區 (例如 Azure Cosmos DB) 來輕鬆調整低回應時間。

高資料量通常會在 CRUD 型系統中產生效能瓶頸。 事件來源解決方案模式是用來解決效能瓶頸。 從傳統資料存放區擷取時態性模式和深入解析也很困難且效率不佳。 現代化大量資料驅動應用程式通常會採用以資料流程為基礎的架構。 Azure 串流分析作為移動中資料的計算引擎，是該架構中的關鍵。

在此解決方案模式中，事件會由 Azure 串流分析處理並彙總到資料存放區。 應用程式層會使用傳統要求/回應模式與資料存放區互動。 由於串流分析能夠即時處理大量事件，因此應用程式是高度可調整，而不需要大量增加資料存放區層。 資料存放區層基本上是系統中的具體化檢視。 Azure 串流分析輸出至 Azure Cosmos DB 描述 Azure Cosmos DB 如何作為串流分析輸出。

在處理邏輯很複雜且需要獨立升級邏輯特定部分的實際應用程式中，可以將多個串流分析作業與事件中樞一起組成作為中繼事件訊息代理程式。

此模式可改善系統的復原能力和管理性。 不過，即使串流分析保證只處理一次，重複事件還是可能會落在中繼事件中樞。 下游串流分析作業務必使用回顧視窗中的邏輯索引鍵來刪除重複事件。 如需事件傳遞的詳細資訊，請參閱事件傳遞保證參考。

使用參考資料進行應用程式自訂

Azure 串流分析參考資料功能專為使用者自訂而設計，例如警示閾值、處理規則和地理柵欄。 應用程式層可以接受參數變更，並將其儲存在 SQL Database 中。 串流分析作業會定期查詢資料庫中的變更，並透過參考資料聯結來讓自訂參數可供存取。 如需如何使用參考資料進行應用程式自訂的詳細資訊，請參閱 SQL 參考資料和參考資料聯結。

此模式也可以用來實作規則引擎，其中規則的閾值是從參考資料定義。 如需規則的詳細資訊，請參閱在 Azure 串流分析中處理可設定的閾值型規則。

將 Machine Learning 新增至您的即時深入解析

Azure 串流分析的內建異常偵測模型是將 Machine Learning 導入即時應用程式的便利方式。 針對更廣泛的 Machine Learning 需求，請參閱 Azure 串流分析與 Azure Machine Learning 的評分服務整合。

針對想要將線上訓練和評分納入相同串流分析管線的進階使用者，請參閱如何使用線性迴歸完成這項操作的這個範例。

即時資料倉儲

另一個常見的模式是即時資料倉儲，也稱為串流資料倉儲。 除了從您的應用程式抵達事件中樞和 IoT 中樞的事件之外，在 IoT Edge 上執行的 Azure 串流分析可用來滿足資料清理、減少資料，以及資料存放區和轉寄需求。 在 IoT Edge 上執行的串流分析可以正常處理系統中的頻寬限制和連線問題。 串流分析可以在寫入 Azure Synapse Analytics 時支援高達 200 MB/秒的輸送量速率。

封存即時資料以供分析

大部分資料科學和分析活動仍然是離線進行。 Azure 串流分析可透過 Azure Data Lake Store Gen2 輸出和 Parquet 輸出格式封存資料。 這項功能會移除將資料直接饋送至 Azure Data Lake Analytics、Azure Databricks 和 Azure HDInsight 所造成的衝突。 Azure 串流分析是用來作為此解決方案中的近乎即時 ETL 引擎。 您可以使用各種計算引擎探索 Data Lake 中的封存資料。

使用參考資料進行擴充

資料擴充通常是 ETL 引擎的需求。 Azure 串流分析支援從 SQL Database 和 Azure Blob 儲存體使用參考資料進行資料擴充。 您可以針對 Azure Data Lake 和 Azure Synapse Analytics 中的資料登陸完成資料擴充。

從封存的資料操作深入解析

如果您結合離線分析模式與近乎即時的應用程式模式，您可以建立意見反應迴圈。 意見反應迴圈可讓應用程式自動調整以變更資料中的模式。 此意見反應迴圈可以像變更警示的閾值一樣簡單，或與重新定型 Machine Learning 模型一樣複雜。 相同的解決方案架構可以套用至在雲端和 IoT Edge 上執行的 ASA 作業。

如何監視 ASA 作業

Azure 串流分析作業可以全年無休地執行，以即時持續處理傳入事件。 其運作時間保證對於整體應用程式的健康情況至關重要。 雖然串流分析是產業中唯一提供 99.9% 可用性保證的串流分析服務，但仍可能會引發一定程度的停機時間。 多年來，串流分析引進了計量、記錄和作業狀態，以反映作業的健康情況。 它們全都透過 Azure 監視器服務呈現，並可進一步匯出至 OMS。 如需詳細資訊，請參閱使用 Azure 入口網站監視串流分析作業。

有兩個需要監視的關鍵事項：

• 作業失敗狀態

  首先，最重要的是您必須確定作業正在執行。 若沒有處於執行中狀態的作業，則不會產生任何新的計量或記錄。 作業可能會由於各種原因而變更為失敗狀態，包括具有高 SU 使用率層級 (例如，資源不足)。

• 浮水印延遲計量

  此計量反映了您的處理管線在掛鐘時間方面落後了多長時間 (秒)。 某些延遲歸因於固有的處理邏輯。 因此，監視不斷上升的趨勢比監視絕對值更為重要。 穩定狀態延遲應由您的應用程式設計解決，而不是由監視或警示解決。

失敗時，活動記錄和診斷記錄是開始尋找錯誤的最佳位置。

建置復原性和任務關鍵性應用程式

不論 Azure 串流分析的 SLA 保證，以及您執行端對端應用程式的謹慎程度，都會發生中斷。 如果您的應用程式是任務關鍵性，您必須為中斷做好準備，才能正常復原。

針對警示應用程式，最重要的是偵測下一個警示。 您可以選擇在復原時從目前時間重新啟動作業，忽略過去的警示。 作業開始時間語意是第一次輸出時間，而不是第一次輸入時間。 輸入會向後倒轉回適當的時間量，以確保指定時間的第一個輸出已完成且正確。 您不會收到部分彙總，並因此意外觸發警示。

您也可以選擇從過去某個時間量開始輸出。 事件中樞和 IoT 中樞的保留原則都會保留合理的資料量，以允許過去的處理。 換來的是您可以趕上目前時間的速度，並開始產生及時的新警示。 資料會隨著時間快速遺失其價值，因此請務必快速趕上目前的時間。 有兩種方式可以快速趕上：

• 在趕上時，佈建更多資源 (SU)。
• 從目前時間重新啟動。

從目前開始重新啟動很簡單，代價是在處理期間留下間距。 針對警示案例，以這種方式重新啟動可能沒問題，但是對於儀表板案例而言可能會有問題，而且是封存和資料倉儲案例的非入門項目。

佈建更多資源可以加速程序，但是處理速率激增的影響很複雜。

• 測試您的作業是否可調整為大量的 SU。 並非所有查詢都是可調整的。 您必須確定查詢已平行化。

• 請確定上游事件中樞或 IoT 中樞有足夠的分割區，讓您可以新增更多輸送量單位 (TU) 來調整輸入輸送量。 請記住，每個事件中樞 TU 的輸出速率上限為 2 MB/秒。

• 請確定您已在輸出接收器中佈建足夠的資源 (也就是 SQL Database、Azure Cosmos DB)，因此不會針對輸出中的激增進行節流，這有時可能會導致系統鎖定。

最重要的事項是預期處理速率變更、在進入生產環境之前測試這些案例，並準備好在失敗復原期間正確調整處理。

在傳入事件全部延遲的極端案例中，如果您已將延遲抵達時間範圍套用至作業，可能會捨棄所有延遲的事件。 捨棄事件似乎在開始時是一種異常行為；不過，考慮串流分析是即時處理引擎，其預期傳入的事件接近時鐘時間。 必須捨棄違反這些條件約束的事件。

Lambda 架構或回填程序

幸運的是，先前的資料封存模式可用來正常處理這些延遲事件。 其概念是封存作業會在抵達時間處理傳入事件，並將事件以及其事件時間封存到 Azure Blob 或 Azure Data Lake Store 中的正確時間貯體中。 事件多晚抵達並不重要，永遠不會捨棄。 一律會落在正確的時間貯體中。 在復原期間，可以重新處理封存的事件，並將結果回填至您選擇的存放區。 這類似於 Lambda 模式的實作方式。

回填程序必須使用離線批次處理系統來完成，這很可能是與 Azure 串流分析不同的程式設計模型。 這表示您必須重新實作整個處理邏輯。

對於回填，至少暫時佈建更多資源給輸出接收，以處理比穩定狀態處理需求更高的輸送量，仍然非常重要。

案例	僅從現在重新啟動	從上次停止的時間重新啟動	立即重新啟動 + 使用封存事件回填
儀表板	產生間距	適用於短暫中斷	用於長時間中斷
警示	可接受	適用於短暫中斷	非必要
事件來源應用程式	可接受	適用於短暫中斷	用於長時間中斷
資料倉儲	資料遺失	可接受	非必要
離線分析	資料遺失	可接受	非必要

融會貫通

很難想像上述的所有解決方案模式都可以在複雜的端對端系統中結合在一起。 合併的系統可以包含儀表板、警示、事件來源應用程式、資料倉儲和離線分析功能。

關鍵在於以可組合模式設計您的系統，讓每個子系統可以獨立建置、測試、升級和復原。

下一步

您現在已看到各種使用 Azure 串流分析的解決方案模式。 接下來，您可以深入了解並建立您的第一個串流分析作業：

• 使用 Azure 入口網站建立串流分析作業。
• 使用 Azure PowerShell 建立串流分析作業。
• 使用 Visual Studio 建立串流分析作業。