此參考架構顯示端對端串流處理管線。 管線會從兩個來源擷取資料、在兩個串流中將記錄相互關聯，並計算時間範圍內的移動平均。 結果會儲存以供進一步分析。
GitHub 上提供此架構的參考實架構
下載這個架構的 Visio 檔案 。
工作流程
此架構由下列元件組成：
資料來源。 在此架構中，有兩個資料來源會即時產生資料流。 第一個資料流包含車程資訊，而第二個包含費用資訊。 參考架構包含模擬的資料產生器，可讀取一組靜態檔案，並將資料推送到事件中樞。 在實際的應用程式中，資料來源會是安裝在計程車上的裝置。
Azure 事件中樞. 事件中樞是事件擷取服務。 此架構使用兩個事件中樞執行個體，分別用於兩個資料來源。 每個資料來源會將資料流傳送至相關聯的事件中樞。
Azure 串流分析。 串流分析是事件處理引擎。 串流分析作業會從兩個事件中樞讀取資料流，並執行串流處理。
Azure Cosmos DB。 串流分析作業的輸出是一系列記錄，這些記錄會以 JSON 檔的形式寫入 Azure Cosmos DB 檔資料庫。
Microsoft Power BI。 Power BI 是一套用來分析資料以產生商業見解的商務分析工具。 在此架構中，它會從 Azure Cosmos DB 載入資料。 這可讓使用者分析收集到的一組完整歷程記錄資料。 您也可以直接從串流分析將結果串流到 Power BI，以取得資料的即時檢視。 如需詳細資訊，請參閱 Power BI 中的即時串流。
Azure 監視器。 Azure 監視器會收集解決方案中部署的 Azure 服務相關效能計量。 透過儀表板中的資料視覺化，您可以取得解決方案健康情況的深入解析。
實例詳細資料
案例：計程車公司會收集有關每趟計程車車程的資料。 在此案例中，我們假設有兩個不同的裝置會傳送資料。 計程車有一個計量，可傳送每個車程的相關資訊—持續時間、距離和下車位置。 另一個裝置會接收客戶付款，並傳送費用相關資料。 計程車公司想要即時計算出平均每英里的小費，以便找出趨勢。
潛在使用案例
此解決方案已針對零售案例進行優化。
資料擷取
若要模擬資料來源，此參考架構會使用紐約市計程車資料資料集[1]。 此資料集包含紐約市計程車車程的四年期間 (2010–2013) 的相關資料。 其中包含兩種類型的記錄：車程資料和車資資料。 車程資料包括路程持續時間、路程距離和上下車地點。 費用資料包括費用、稅金和小費金額。 在這兩種記錄類型中共同欄位包含計程車牌照號碼、計程車執照和廠商識別碼。 這三個欄位可唯一識別一輛計程車加上司機。 資料會以 CSV 格式儲存。
[1] Donovan， Brian;Work，Dan (2016) ：紐約市計程車車程資料 (2010-2013) 。 伊利諾大學香檳分校。 https://doi.org/10.13012/J8PN93H8
資料產生器為 .NET Core 應用程式，可讀取記錄並將其傳送到 Azure 事件中樞。 產生器會以 JSON 格式傳送車程資料，以 CSV 格式傳送費用資料。
事件中樞使用分割區來分割資料。 資料分割可讓取用者平行讀取每個分割。 將資料傳送至事件中樞時，您可以明確指定分割區索引鍵。 否則，記錄會以循環配置資源的方式指派給分割區。
在此特定案例中，車程資料和費用資料最後應具有指定計程車的同一分割區識別碼。 這可讓串流分析在將兩個資料流相互關聯時套用平行處理原則。 車程資料分割區 n 中的記錄會比對到費用資料分割區 n 中的記錄。
在資料產生器中，這兩種記錄類型的共同資料模型具有 PartitionKey 屬性，其為 Medallion、HackLicense 和 VendorId 的串連。
public abstract class TaxiData
{
public TaxiData()
{
}
[JsonProperty]
public long Medallion { get; set; }
[JsonProperty]
public long HackLicense { get; set; }
[JsonProperty]
public string VendorId { get; set; }
[JsonProperty]
public DateTimeOffset PickupTime { get; set; }
[JsonIgnore]
public string PartitionKey
{
get => $"{Medallion}_{HackLicense}_{VendorId}";
}
在傳送至事件中樞時，這個屬性用來提供明確的分割區索引鍵：
using (var client = pool.GetObject())
{
return client.Value.SendAsync(new EventData(Encoding.UTF8.GetBytes(
t.GetData(dataFormat))), t.PartitionKey);
}
串流處理
串流處理作業使用 SQL 查詢搭配數個不同步驟來定義。 前兩個步驟僅從兩個輸入資料流中選取記錄。
WITH
Step1 AS (
SELECT PartitionId,
TRY_CAST(Medallion AS nvarchar(max)) AS Medallion,
TRY_CAST(HackLicense AS nvarchar(max)) AS HackLicense,
VendorId,
TRY_CAST(PickupTime AS datetime) AS PickupTime,
TripDistanceInMiles
FROM [TaxiRide] PARTITION BY PartitionId
),
Step2 AS (
SELECT PartitionId,
medallion AS Medallion,
hack_license AS HackLicense,
vendor_id AS VendorId,
TRY_CAST(pickup_datetime AS datetime) AS PickupTime,
tip_amount AS TipAmount
FROM [TaxiFare] PARTITION BY PartitionId
),
下一個步驟會將兩個輸入資料流聯結，從每個資料流中選取相符的記錄。
Step3 AS (
SELECT tr.TripDistanceInMiles,
tf.TipAmount
FROM [Step1] tr
PARTITION BY PartitionId
JOIN [Step2] tf PARTITION BY PartitionId
ON tr.PartitionId = tf.PartitionId
AND tr.PickupTime = tf.PickupTime
AND DATEDIFF(minute, tr, tf) BETWEEN 0 AND 15
)
此查詢會聯結一組欄位上的記錄，以唯一識別相符記錄 (PartitionId 和 PickupTime) 。
注意
我們希望 TaxiRide 和 TaxiFare 資料流程以 、 HackLicenseVendorId 和 PickupTime 的唯一組合 Medallion 聯結。 在此案例中，涵蓋 PartitionIdMedallion 、 HackLicense 和 VendorId 欄位，但不應該將此視為一般情況。
在串流分析中，聯結是時態性，表示記錄已加入特定的時間範圍內。 否則，作業可能需要無限期等待相符項目。 DATEDIFF 函式可指定針對符合項目，兩筆相符記錄的時間可以間隔多久。
作業的最後一個步驟會計算每英里的平均小費，依 5 分鐘跳動視窗分組。
SELECT System.Timestamp AS WindowTime,
SUM(tr.TipAmount) / SUM(tr.TripDistanceInMiles) AS AverageTipPerMile
INTO [TaxiDrain]
FROM [Step3] tr
GROUP BY HoppingWindow(Duration(minute, 5), Hop(minute, 1))
串流分析提供多種時間範圍函式。 跳動視窗會以一段固定時間向前移動，在此案例中為每個躍點 1 分鐘。 目的是要計算過去 5 分鐘的移動平均。
在此所示的架構中，只有串流分析作業的結果會儲存至 Azure Cosmos DB。 在巨量資料案例中，也請考慮使用事件中樞擷取，將原始事件資料儲存至 Azure Blob 儲存體。 保留未經處理資料可讓您在稍後對歷程記錄資料執行批次查詢，以便從資料中找出新的深入解析。
考量
這些考慮會實作 Azure Well-Architected Framework 的要素，這是一組可用來改善工作負載品質的指引原則。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。
延展性
事件中樞
事件中樞的輸送量容量會以輸送量單位來測量。 您可以啟用自動擴充以自動調整事件中樞，這會根據流量 (上限為設定的最大值) 自動調整輸送量單位。
串流分析
對於串流分析，配置給作業的計算資源會以串流單位測量。 如果作業可以平行處理，則串流分析作業可進行最佳調整。 如此一來，串流分析可以將作業分散至多個計算節點。
對於事件中樞輸入，使用 PARTITION BY 關鍵字來分割串流分析作業。 資料會根據事件中樞分割區分割為子集。
時間範圍函式和時態性聯結需要額外的 SU。 可能的話，請使用 PARTITION BY 以便每個分割區可個別處理。 如需詳細資訊，請參閱了解和調整串流單位。
如果無法平行處理整個串流分析作業，請嘗試將作業分成多個步驟，從一或多個平行步驟開始。 如此一來，第一個步驟即可平行執行。 例如，在此參考架構中：
- 步驟 1 和 2 是簡單的
SELECT陳述式，可選取單一分割區內的記錄。 - 步驟 3 會跨兩個輸入資料流執行資料分割的聯結。 此步驟是由於相符記錄共用相同的分割區索引鍵，因此每個輸入資料流一定會有相同的分割區識別碼。
- 步驟 4 會彙總所有資料分割。 此步驟無法平行處理。
使用串流分析作業圖表，查看有多少分割區指派給作業中的每個步驟。 下圖顯示此參考架構的作業圖表：
Azure Cosmos DB
Azure Cosmos DB 的輸送量容量是以 要求單位 (RU) 來測量。 若要調整超過 10，000 RU 的 Azure Cosmos DB 容器，您必須在建立容器時指定分割區 索引鍵 ，並在每份檔中包含分割區索引鍵。
在此參考架構中，新文件每分鐘只會建立一次 (跳動視窗間隔)，因此輸送量需求相當低。 基於這個理由，此案例不需要指派分割區索引鍵。
監視
使用任何串流處理解決方案，請務必監視系統效能與健康情況。 Azure 監視器會為架構中使用的 Azure 服務收集計量和診斷記錄。 Azure 監視器內建於 Azure 平台，且不需要您應用程式中任何額外的程式碼。
任何下列警告信號表示您應相應放大相關的 Azure 資源：
- 事件中樞會對要求進行節流，否則會接近每日的訊息配額。
- 串流分析作業持續使用超過 80% 的配置串流單位 (SU)。
- Azure Cosmos DB 會開始節流要求。
參考架構包含部署至 Azure 入口網站的自訂儀表板。 部署架構之後，您可以開啟Azure 入口網站並從儀表板清單中選取 TaxiRidesDashboard 來檢視儀表板。 如需在 Azure 入口網站建立及部署自訂儀表板的詳細資訊，請參閱以程式設計方式建立 Azure 儀表板。
串流分析作業執行大約一小時後，下圖會顯示儀表板。
左下方的面板顯示出串流分析作業的 SU 耗用量在前 15 分鐘攀升，然後再下降。 作業達到穩定狀態時，這是典型的模式。
請注意，事件中樞正在對要求進行節流，如右上角面板所示。 偶爾節流的要求不是問題，因為收到節流錯誤時，事件中樞用戶端 SDK 會自動重試。 不過，如果您看到一致的節流錯誤，表示事件中樞需要更多輸送量單位。 以下圖表顯示使用事件中樞自動擴充功能的測試回合，其可自動相應放大所需的輸送量單位。
自動擴充已於 06:35 標記啟用。 事件中樞自動向上調整至 3 個輸送量單位時，您會在節流的要求中看到 p 下降。
有趣的是，這樣做的副作用是在串流分析作業中增加 SU 使用率。 藉由節流，事件中樞會以人為方式減少串流分析作業的擷取率。 實際上常見到，解決一個效能瓶頸會帶來另一個瓶頸。 在此案例中，為串流分析作業配置額外的 SU 解決了問題。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。
使用 Azure 定價計算機來估計成本。 以下是此參考架構中使用的服務一些考慮。
Azure 串流分析
Azure 串流分析是以處理資料到服務所需的串流單位數目來定價， ($0.11/小時) 。
如果您未即時處理資料或少量資料，串流分析可能會很昂貴。 針對這些使用案例，請考慮使用 Azure Functions 或 Logic Apps 將資料從Azure 事件中樞移至資料存放區。
Azure 事件中樞 和 Azure Cosmos DB
如需Azure 事件中樞和 Azure Cosmos DB 的成本考慮，請參閱使用 Azure Databricks 的串流處理參考架構。
DevOps
針對生產、部署和測試環境，各別建立資源群組。 個別的資源群組可讓您更輕鬆地管理部署、刪除測試部署及指派存取權限。
使用Azure Resource Manager範本，在基礎結構作為 Code (IaC) Process 之後部署 Azure 資源。 使用範本時，使用Azure DevOps Services或其他 CI/CD 解決方案將部署自動化會比較容易。
將每個工作負載放在個別的部署範本中，並將資源儲存在原始檔控制系統中。 您可以將範本一起或個別部署為 CI/CD 程式的一部分，讓自動化程式更容易。
在此架構中，Azure 事件中樞、Log Analytics 和 Azure Cosmos DB 會識別為單一工作負載。 這些資源包含在單一 ARM 範本中。
請考慮暫存工作負載。 部署至各種階段，並在每個階段執行驗證檢查，再移至下一個階段。 如此一來，您就可以以高度控制的方式將更新推送至生產環境，並將未預期的部署問題降到最低。
請考慮使用 Azure 監視器 來分析串流處理管線的效能。 如需詳細資訊，請參閱監視 Azure Databricks。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework中的營運卓越要素。
部署此案例
若要部署及執行參考實作，請依照 GitHub 讀我檔案中的步驟。
相關資源
您可以檢閱下列 Azure 範例案例，其中示範使用相同技術的一些特定解決方案：