此參考架構顯示了端對端流處理管線。 管線會擷取來自兩個來源的數據、將兩個數據流中的記錄相互關聯，並計算時間範圍內滾動平均值。 結果被儲存以供進一步分析。
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年）計程車車程的相關數據。 其中包含兩種類型的記錄：車程數據和票價數據。 車程數據報含車程持續時間、車程距離和上車和下車位置。 票價資料包括票價、稅金和小費金額。 兩種記錄類型中的常見欄位包括獎章號碼、駭客許可證和供應商 ID。 這三個字段共同唯一地標識出租車和司機。 資料以 CSV 格式儲存。
[1] Donovan, Brian; Work, Dan (2016): New York City Taxi Trip Data (2010-2013).[1] 布萊恩‧多諾萬； Work，Dan (2016)：紐約市計程車出行資料（2010-2013）。 伊利諾大學厄巴納香檳校區。 https://doi.org/10.13012/J8PN93H8
資料產生器是一個 .NET Core 應用程式，它會讀取記錄並將其傳送到 Azure 事件中心。 生成器會傳送 JSON 格式的乘車資料和 CSV 格式的票價資料。
事件中心使用分區來分段資料。 分割區允許使用者並行讀取每個分割區。 將資料傳送到事件中心時，可以明確指定分區鍵。 否則，記錄將以循環方式分配給分割區。
在此特定案例中，車程數據和車資數據最後應該會包含指定計程車的相同分割區標識符。 這可讓串流分析在將兩個數據流相互關聯時套用一定程度的平行處理原則。 乘車資料的分區 n 中的記錄將與票價資料的分區 n 中的記錄相符。
在數據產生器中，這兩種記錄類型的通用數據模型都有 屬性PartitionKey，這是、 HackLicense和 VendorId的Medallion串連。
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 和數據流聯結成、 HackLicenseVendorId 和 TaxiFare PickupTime的唯一組合Medallion。 在此案例中，涵蓋 PartitionId Medallion、 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 結構完善的架構。
延展性
事件中樞
事件中心的輸送量以輸送量單位來衡量。 您可以透過啟用自動擴充來自動縮放事件中心，該功能會根據流量自動縮放輸送量單位，直到達到設定的最大值。
串流分析
針對串流分析，配置給作業的計算資源會以串流單位來測量。 如果可平行處理作業，串流分析作業會調整得最好。 如此一來，串流分析就可以將作業分散到多個計算節點。
針對事件中樞輸入，使用 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 左右啟用。 您可以看到節流要求中的 p 下降，因為事件中樞會自動相應增加至 3 個輸送量單位。
有趣的是，這有增加串流分析作業中 SU 使用率的副作用。 透過節流，事件中樞會人為地降低串流分析作業的擷取速率。 解決一個效能瓶頸實際上很常見，這會顯示另一個瓶頸。 在此情況下，為串流分析作業配置其他 SU 解決了問題。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。
使用 Azure 定價計算機來預估成本。 以下是此參考架構中使用的服務的一些注意事項。
Azure 串流分析
Azure 串流分析是由處理數據至服務所需的串流單位數目（$0.11/小時）來定價。
如果您不是以即時或少量的數據處理數據，串流分析可能會很昂貴。 針對這些使用案例，請考慮使用 Azure Functions 或 Logic Apps 將數據從 Azure 事件中樞 移至數據存放區。
Azure 事件中樞 和 Azure Cosmos DB
如需 Azure 事件中樞 和 Azure Cosmos DB 的成本考慮，請參閱使用 Azure Databricks 串流處理參考架構的成本考慮。
DevOps
為生產、開發和測試環境建立單獨的資源組。 單獨的資源群組可以更輕鬆地管理部署、刪除測試部署和指派存取權限。
使用 Azure 資源管理器範本依照基礎架構即程式碼 (IaC) 流程部署 Azure 資源。 透過模板，使用 Azure DevOps 服務或其他 CI/CD 解決方案進行自動化部署變得更加容易。
將每個工作負載放入單獨的部署範本中，並將資源儲存在來源控制系統中。 您可以將範本一起部署或單獨部署作為 CI/CD 流程的一部分，從而使自動化流程更加輕鬆。
在此體系架構中，Azure 事件中心、記錄分析和 Azure Cosmos DB 被識別為單一工作負載。 這些資源包含在單一 ARM 範本中。
考慮暫存您的工作負載。 部署到各個階段並在每個階段執行驗證檢查，然後再進入下一階段。 這樣您就可以以高度受控的方式將更新推送到生產環境，並最大限度地減少意外的部署問題。
考慮使用 Azure 監視器來分析流處理管線的效能。 有關詳細資訊，請參閱監視 Azure Databricks。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的卓越營運支柱。
部署此案例
若要部署並執行參考實現，請按照 GitHub 自述文件中的步驟操作。
相關資源
您可能想要檢閱下列 Azure 範例案例 ，以示範使用一些相同技術的特定解決方案：