此參考架構會顯示端對端串流處理管線。 管線會擷取來自兩個來源的數據、將兩個數據流中的記錄相互關聯，並計算時間範圍內滾動平均值。 結果會儲存以供進一步分析。
GitHub 上提供此架構的參考實作。
架構
工作流程
架構包含下列元件：
數據源。 在此架構中，有兩個數據源會即時產生數據流。 第一個數據流包含車程資訊，第二個數據流包含車資資訊。 參考架構包含仿真的數據產生器，可從一組靜態檔案讀取，並將數據推送至事件中樞。 在實際的應用程式中，數據源會是安裝在計程車上的裝置。
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] 多諾萬， 布賴恩;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 和 TaxiFarePickupTime的唯一組合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 左右啟用。 您可以看到節流要求中的 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 Resource Manager 範本 ，在基礎結構即程式代碼 （IaC） 程序之後部署 Azure 資源。 透過範本，使用 Azure DevOps Services 或其他 CI/CD 解決方案將部署自動化會比較容易。
將每個工作負載放在個別的部署範本中，並將資源儲存在原始檔控制系統中。 您可以將範本一起或個別部署為 CI/CD 程式的一部分，讓自動化程式更容易。
在此架構中，Azure 事件中樞、Log Analytics 和 Azure Cosmos DB 會識別為單一工作負載。 這些資源包含在單一 ARM 範本中。
請考慮暫存工作負載。 部署至各種階段，並在每個階段執行驗證檢查，再移至下一個階段。 如此一來，您就可以以高度控制的方式將更新推送至生產環境，並將未預期的部署問題降到最低。
請考慮使用 Azure 監視器 來分析串流處理管線的效能。 如需詳細資訊，請參閱 監視 Azure Databricks。
如需詳細資訊，請參閱 Microsoft Azure 良好架構架構中的卓越營運支柱。
部署此案例
若要部署並執行參考實作，請遵循 GitHub 自述檔中的步驟。
相關資源
您可能想要檢閱下列 Azure 範例案例 ，以示範使用一些相同技術的特定解決方案：