如同 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 資料庫 時，它可提供更大的彈性，但代價是延遲稍高。 此解決方案最適合延遲需求大於一秒的作業。 當您使用此方法時，可以充分發揮 Power BI 的功能，進一步切割和分析報表數據，並提供更多的視覺化選項。 您也可以獲得使用其他儀表板解決方案的彈性，例如 Tableau。
SQL 不是高吞吐量數據存放區。 從 Azure 串流分析到 SQL Database 的最大輸送量目前大約為 24 MB/秒。 如果您的解決方案中的事件來源以較高的速率產生資料，您必須在串流分析中使用處理邏輯，以降低前往 SQL 的輸出速率。 您可以使用篩選、視窗匯總、與時態聯結比對模式，以及分析函式等技術。 您可以使用 Azure 串流分析輸出至 Azure SQL 資料庫 中所述的技術，將輸出速率優化至 SQL。
使用事件傳訊將即時深入解析納入您的應用程式中
串流分析的第二個最常使用方式是產生即時警示。 在此解決方案模式中，串流分析中的商務邏輯可以用來偵測時態性和空間模式或異常，然後產生警示訊號。 不過，不同於將 Power BI 作為偏好端點的儀表板解決方案 (串流分析使用 Power BI)，您可以使用其他中繼資料接收器。 這些接收器包括事件中樞、服務匯流排和 Azure Functions。 作為應用程式開發者，您必須決定最適合您情境的資料匯入點。
您必須實作下游事件取用者邏輯，以在現有的商務工作流程中產生警示。 因為您可以在 Azure Functions 中實作自訂邏輯，所以 Azure Functions 是您可以執行此整合的最快速方式。 如需使用 Azure Functions 作為 Stream Analytics 作業輸出的指南，請參閱 從 Azure 串流分析作業執行 Azure Functions。 Azure Functions 也支援各種類型的通知，包括文字和電子郵件。 您也可以使用 Logic Apps 進行這類整合，並在串流分析與 Logic Apps 之間使用事件中樞。
另一方面，Azure 事件中樞 服務提供最具彈性的整合點。 許多其他服務，如 Azure Data Explorer，也能從事件中樞接收事件。 這些服務可以直接從 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 串流分析中處理可設定的閾值型規則。
將機器學習新增至您的即時深入解析
Azure 串流分析的內建異常偵測模型是將 Machine Learning 導入即時應用程式的便利方式。 欲了解更廣泛的機器學習需求，請參閱 Azure Stream Analytics 與 Azure Machine Learning 的整合。 你可以部署 Azure Machine Learning 的模型，並在 Stream Analytics 查詢中將它們呼叫為使用者定義函數（UDF）。
對於想將線上訓練與評分整合進同一串流分析管道的進階使用者，請參考如何使用線性迴歸來實作這個範例說明。
即時資料倉儲
另一個常見的模式是即時資料倉儲，也稱為串流資料倉儲。 除了從您的應用程式抵達事件中樞和 IoT 中樞的事件之外，在 IoT Edge 上執行的 Azure 串流分析可用來滿足資料清理、減少資料，以及資料存放區和轉寄需求。 在 IoT Edge 上執行的串流分析可以正常處理系統中的頻寬限制和連線問題。 串流分析可以在寫入 Azure Synapse Analytics 時支援高達 200 MB/秒的輸送量速率。
封存即時資料以供分析
大部分資料科學和分析活動仍然是離線進行。 您可以透過 Azure Data Lake Store Gen2 輸出和 Parquet 輸出格式，在 Azure 串流分析中封存數據。 這項功能消除了直接將資料輸入 Azure Synapse Analytics、Azure Databricks、Microsoft Fabric 及 Azure HDInsight 的阻力。 Azure 串流分析作為此解決方案中的近乎即時擷取、轉換、載入（ETL）引擎。 您可以使用各種計算引擎探索 Data Lake 中的封存資料。
使用參考資料進行擴充
資料擴充通常是 ETL 引擎的需求。 Azure 串流分析支援從 SQL Database 和 Azure Blob 儲存體使用參考資料進行資料擴充。 您可以針對在 Azure Data Lake 和 Azure Synapse Analytics 中登陸的資料進行資料強化。
運用封存資料中的洞察
如果您結合離線分析模式與近乎即時的應用程式模式，您可以建立意見反應迴圈。 意見反應迴圈可讓應用程式自動調整以變更資料中的模式。 此意見反應迴圈可以像變更警示的閾值一樣簡單，或與重新定型 Machine Learning 模型一樣複雜。 相同的解決方案架構可以套用至在雲端和 IoT Edge 上執行的 ASA 作業。
Apache Kafka 整合
Stream Analytics 透過 Azure Event Hubs 與 Kafka 端點，支援 Apache Kafka 作為輸入與輸出。 此模式可實現：
- 從現有 Kafka 架構遷移至 Azure
- 將內部部署的 Kafka 叢集連接到 Azure 的混合方案
- 與 Apache Kafka 生態系統工具與連接器的整合
湖存放庫架構的 Delta Lake 輸出
對於現代湖屋架構，Stream Analytics 可以直接在 Azure Data Lake Storage Gen2 中寫入 Delta Lake 格式 。 三角洲湖提供：
- ACID 交易以實現可靠的資料擷取
- 結構描述執行和演變
- 用於資料版本管理的時間旅行功能
- 統一批次與串流資料存取
選擇合適的圖案
請使用這張表格，幫助選擇適合你情境的模式：
| 情境 | 建議模式 | 主要優點 |
|---|---|---|
| 即時數據儀表板 | Power BI 串流資料集 | 最低延遲 |
| 複雜報告 | SQL Database + Power BI | 完整商業智慧功能 |
| 事件驅動警示 | Event Hubs + Azure Functions | 彈性整合 |
| 資料湖分析 | 三角洲湖的產出 | ACID 交易 |
| Kafka 工作負載 | 事件中樞 Kafka 端點 | 協定相容性 |
如何監控 ASA 作業
Azure 串流分析作業可以全年無休地執行，以即時持續處理傳入事件。 其運作時間保證對於整體應用程式的健康情況至關重要。 雖然串流分析是業界中唯一提供 99.9% 可用性保證的串流分析服務，但您仍可能會遭遇某程度的停機時間。 多年來，串流分析引進了計量、記錄和作業狀態，以反映作業的健康情況。 所有這些資料都透過 Azure Monitor 服務呈現，並可匯出至 Log Analytics 工作空間進行更深入的分析。 如需詳細資訊，請參閱使用 Azure 入口網站監視串流分析作業。
有兩個需要監視的關鍵事項：
-
首先，您必須確認作業正在執行。 若沒有處於執行中狀態的作業，則不會產生任何新的計量或記錄。 作業可能會因為各種原因而變更為失敗狀態，例如 SU 使用率層級過高（也就是資源耗盡）。
-
此指標會反映處理管線在牆鐘時間 (秒) 上落後多少。 某些延遲歸因於固有的處理邏輯。 因此，監視不斷上升的趨勢比監視絕對值更為重要。 穩定狀態延遲應由您的應用程式設計解決，而不是由監視或警示解決。
設定警報和儀錶板
設定 Azure Monitor 警示以進行主動監控：
- SU 利用率 - 當持續超過 80% 時警示，以防止工作失敗
- 浮水印延遲 - 對顯示處理延遲的增加趨勢發出警示
- 輸入/輸出事件 - 監控顯示連線問題的突發斷線
- 執行時錯誤 - 追蹤反序列化與資料轉換失敗
為了集中可觀察，請將串流分析的指標與日誌匯出至日誌分析工作區。 這會啟用以下功能：
- 跨工作相關性與分析
- 自訂 Kusto 查詢以進行深度診斷
- 與 Azure 儀表板及工作簿的整合
失敗時，活動記錄和診斷記錄是開始尋找錯誤的最佳位置。
建置復原性和任務關鍵性應用程式
不論 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 Stream Analytics 了解各種解決方案模式。 接下來，您可以深入了解並建立第一個串流分析工作：