Azure Stream Analytics によるストリーム処理パイプラインStream processing pipeline with Azure Stream Analytics

この参照アーキテクチャでは、エンド ツー エンドのストリーム処理パイプラインを示します。This reference architecture shows an end-to-end stream processing pipeline. このパイプラインでは、2 つのソースからデータを取り込み、2 つのストリームのレコードを関連付けて、時間枠全体の移動平均を計算します。The pipeline ingests data from two sources, correlates records in the two streams, and calculates a rolling average across a time window. 結果が保存され、さらに詳しい分析が行われます。The results are stored for further analysis.

GitHub ロゴ このアーキテクチャのリファレンス実装は、GitHub で入手できます。GitHub logo A reference implementation for this architecture is available on GitHub.

Azure Stream Analytics を使用したストリーム処理パイプラインの作成の参照アーキテクチャ

シナリオ :タクシー会社が各乗車に関するデータを収集しています。Scenario : A taxi company collects data about each taxi trip. このシナリオでは、データを送信する 2 つのデバイスがあることを想定しています。For this scenario, we assume there are two separate devices sending data. タクシーには、各乗車の情報 (走行時間、距離、乗車場所と降車場所) を送信するメーターがあります。The taxi has a meter that sends information about each ride — the duration, distance, and pickup and dropoff locations. 別のデバイスでは、乗客からの支払いを受け付け、料金に関するデータを送信します。A separate device accepts payments from customers and sends data about fares. タクシー会社では、傾向をつかむために、走行 1 マイルあたりの平均チップをリアルタイムで計算したいと考えています。The taxi company wants to calculate the average tip per mile driven, in real time, in order to spot trends.

ArchitectureArchitecture

アーキテクチャは、次のコンポーネントで構成されます。The architecture consists of the following components.

データ ソースData sources. このアーキテクチャには、リアルタイムでデータ ストリームを生成する 2 つのデータ ソースがあります。In this architecture, there are two data sources that generate data streams in real time. 1 つ目のストリームには乗車情報が含まれ、2 つ目のストリームには料金情報が含まれます。The first stream contains ride information, and the second contains fare information. 参照アーキテクチャには、一連の静的ファイルから読み取り、データを Event Hubs にプッシュするシミュレートされたデータ ジェネレーターが含まれています。The reference architecture includes a simulated data generator that reads from a set of static files and pushes the data to Event Hubs. 実際のアプリケーションでは、データ ソースはタクシーに設置されたデバイスになります。In a real application, the data sources would be devices installed in the taxi cabs.

Azure Event HubsAzure Event Hubs. Event Hubs はイベント取り込みサービスです。Event Hubs is an event ingestion service. このアーキテクチャでは、2 つのイベント ハブ インスタンス (データ ソースごとに 1 つ) を使用します。This architecture uses two event hub instances, one for each data source. 各データ ソースは、関連付けられたイベント ハブにデータ ストリームを送信します。Each data source sends a stream of data to the associated event hub.

Azure Stream AnalyticsAzure Stream Analytics. Stream Analytics はイベント処理エンジンです。Stream Analytics is an event-processing engine. Stream Analytics ジョブでは、2 つのイベント ハブからデータ ストリームを読み取り、ストリーム処理を実行します。A Stream Analytics job reads the data streams from the two event hubs and performs stream processing.

Cosmos DBCosmos DB. Stream Analytics ジョブの出力は一連のレコードであり、JSON ドキュメントとして Cosmos DB ドキュメント データベースに書き込まれます。The output from the Stream Analytics job is a series of records, which are written as JSON documents to a Cosmos DB document database.

Microsoft Power BIMicrosoft Power BI. Power BI は、データを分析してビジネスの分析情報を得る一連のビジネス分析ツールです。Power BI is a suite of business analytics tools to analyze data for business insights. このアーキテクチャでは、Cosmos DB からデータを読み込みます。In this architecture, it loads the data from Cosmos DB. これにより、ユーザーは収集された過去のデータの完全なセットを分析できます。This allows users to analyze the complete set of historical data that's been collected. また、Stream Analytics から Power BI に結果を直接ストリーミングして、データのリアルタイム ビューを表示することもできます。You could also stream the results directly from Stream Analytics to Power BI for a real-time view of the data. 詳細については、「Power BI のリアルタイム ストリーミング」をご覧ください。For more information, see Real-time streaming in Power BI.

Azure MonitorAzure Monitor. Azure Monitor は、ソリューションにデプロイされた Azure サービスに関するパフォーマンス メトリックを収集します。Azure Monitor collects performance metrics about the Azure services deployed in the solution. ダッシュボードでこれらを視覚化することで、ソリューションの正常性を把握できます。By visualizing these in a dashboard, you can get insights into the health of the solution.

データ インジェストData ingestion

データ ソースをシミュレートするために、この参照アーキテクチャでは New York City Taxi Data データセット[1] を使用します。To simulate a data source, this reference architecture uses the New York City Taxi Data dataset[1]. このデータセットには、ニューヨーク市の 4 年間 (2010 年から 2013 年) のタクシー乗車に関するデータが含まれています。This dataset contains data about taxi trips in New York City over a four-year period (2010–2013). 乗車データと料金データの 2 種類のレコードがあります。It contains two types of record: ride data and fare data. 乗車データには、走行時間、乗車距離、乗車場所と降車場所が含まれます。Ride data includes trip duration, trip distance, and pickup and dropoff location. 料金データには、料金、税、チップの金額が含まれます。Fare data includes fare, tax, and tip amounts. この 2 種類のレコードの共通フィールドには、営業許可番号、タクシー免許、ベンダー ID があります。Common fields in both record types include medallion number, hack license, and vendor ID. この 3 つのフィールドを組み合わせて、タクシーと運転手が一意に識別されます。Together these three fields uniquely identify a taxi plus a driver. データは CSV 形式で保存されます。The data is stored in CSV format.

[1] Donovan, Brian; Work, Dan (2016):New York City Taxi Trip Data (2010-2013).[1] Donovan, Brian; Work, Dan (2016): New York City Taxi Trip Data (2010-2013). イリノイ大学アーバナシャンペーン校。University of Illinois at Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

データ ジェネレーターは、レコードを読み取り、Azure Event Hubs に送信する .NET Core アプリケーションです。The data generator is a .NET Core application that reads the records and sends them to Azure Event Hubs. ジェネレーターは、JSON 形式の乗車データと CSV 形式の料金データを送信します。The generator sends ride data in JSON format and fare data in CSV format.

Event Hubs では、パーティションを使用してデータをセグメント化します。Event Hubs uses partitions to segment the data. 複数のパーティションでは、コンシューマーは各パーティションを並列で読み取ることができます。Partitions allow a consumer to read each partition in parallel. Event Hubs にデータを送信するときに、パーティション キーを明示的に指定できます。When you send data to Event Hubs, you can specify the partition key explicitly. それ以外の場合は、ラウンド ロビン方式でパーティションにレコードが割り当てられます。Otherwise, records are assigned to partitions in round-robin fashion.

このシナリオでは、特定のタクシーの乗車データと料金データは、最終的に同じパーティション ID を共有します。In this particular scenario, ride data and fare data should end up with the same partition ID for a given taxi cab. これにより、Stream Analytics は 2 つのストリームを関連付けるときに、ある程度の並列処理を適用できます。This enables Stream Analytics to apply a degree of parallelism when it correlates the two streams. 乗車データのパーティション n 内のレコードは、料金データのパーティション n 内のレコードに対応します。A record in partition n of the ride data will match a record in partition n of the fare data.

Azure Stream Analytics と Event Hubs によるストリーム処理のダイアグラム

データ ジェネレーターでは、両方のレコードの種類の共通データ モデルに、MedallionHackLicenseVendorId を連結した PartitionKey プロパティがあります。In the data generator, the common data model for both record types has a PartitionKey property which is the concatenation of Medallion, HackLicense, and 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}";
    }

このプロパティを使用して、Event Hubs への送信時に明示的なパーティション キーが提供されます。This property is used to provide an explicit partition key when sending to Event Hubs:

using (var client = pool.GetObject())
{
    return client.Value.SendAsync(new EventData(Encoding.UTF8.GetBytes(
        t.GetData(dataFormat))), t.PartitionKey);
}

ストリーム処理Stream processing

ストリーム処理ジョブは、複数の異なるステップで SQL クエリを使用して定義されます。The stream processing job is defined using a SQL query with several distinct steps. 最初の 2 つのステップでは、2 つの入力ストリームからレコードを選択するだけです。The first two steps simply select records from the two input streams.

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
),

次のステップでは、2 つの入力ストリームを結合して、各ストリームから一致するレコードを選択します。The next step joins the two input streams to select matching records from each stream.

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
)

このクエリでは、一致するレコードを一意に識別する一連のフィールド (PartitionIdPickupTime) でレコードを結合します。This query joins records on a set of fields that uniquely identify matching records (PartitionId and PickupTime).

注意

TaxiRide および TaxiFare ストリームは、MedallionHackLicenseVendorIdPickupTime の一意の組み合わせによって結合します。We want the TaxiRide and TaxiFare streams to be joined by the unique combination of Medallion, HackLicense, VendorId and PickupTime. この場合、PartitionIdMedallionHackLicenseVendorId の各フィールドを対象としますが、これは一般的ではありません。In this case the PartitionId covers the Medallion, HackLicense and VendorId fields, but this should not be taken as generally the case.

Stream Analytics では、結合は " 一時的 " なものであり、特定の期間内だけレコードが結合されます。In Stream Analytics, joins are temporal , meaning records are joined within a particular window of time. それ以外は、ジョブでは一致を無期限に待つ必要があります。Otherwise, the job might need to wait indefinitely for a match. DATEDIFF 関数は、一致と見なされるために、一致する 2 つのレコードの許容される時間の間隔を指定します。The DATEDIFF function specifies how far two matching records can be separated in time for a match.

ジョブの最後のステップでは、5 分のホッピング ウィンドウでグループ化された、1 マイルあたりの平均チップを計算します。The last step in the job computes the average tip per mile, grouped by a hopping window of 5 minutes.

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))

Stream Analytics には、ウィンドウ関数がいくつか用意されています。Stream Analytics provides several windowing functions. ホッピング ウィンドウは、一定期間単位で時間が進みます (この例では、1 ホップあたり 1 分)。A hopping window moves forward in time by a fixed period, in this case 1 minute per hop. 結果は、過去 5 分間の移動平均を計算したものです。The result is to calculate a moving average over the past 5 minutes.

ここで示すアーキテクチャでは、Stream Analytics ジョブの結果だけが Cosmos DB に保存されます。In the architecture shown here, only the results of the Stream Analytics job are saved to Cosmos DB. ビッグ データ シナリオでは、Event Hubs Capture を使用して、生イベント データを Azure Blob Storage に保存することも検討してください。For a big data scenario, consider also using Event Hubs Capture to save the raw event data into Azure Blob storage. 生データを保持すると、データから新しい分析情報を引き出すために、後で過去のデータに対してバッチ クエリを実行できます。Keeping the raw data will allow you to run batch queries over your historical data at later time, in order to derive new insights from the data.

スケーラビリティに関する考慮事項Scalability considerations

Event HubsEvent Hubs

Event Hubs のスループット容量は、スループット ユニットで測定されます。The throughput capacity of Event Hubs is measured in throughput units. 自動インフレを有効にすると、イベント ハブを自動スケーリングできます。自動インフレでは、トラフィックに基づいて、スループット ユニットが構成済みの最大値まで自動的にスケーリングされます。You can autoscale an event hub by enabling auto-inflate, which automatically scales the throughput units based on traffic, up to a configured maximum.

Stream AnalyticsStream Analytics

Stream Analytics の場合、ジョブに割り当てられたコンピューティング リソースがストリーミング ユニットで測定されます。For Stream Analytics, the computing resources allocated to a job are measured in Streaming Units. ジョブを並列化できる場合は、Stream Analytics ジョブが最も効果的にスケーリングされます。Stream Analytics jobs scale best if the job can be parallelized. この場合、Stream Analytics は複数のコンピューティング ノードにジョブを分散できます。That way, Stream Analytics can distribute the job across multiple compute nodes.

Event Hubs の入力では、PARTITION BY キーワードを使用して Stream Analytics ジョブをパーティション分割します。For Event Hubs input, use the PARTITION BY keyword to partition the Stream Analytics job. データは、Event Hubs のパーティションに基づいてサブセットに分割されます。The data will be divided into subsets based on the Event Hubs partitions.

ウィンドウ関数と一時的な結合には追加の SU が必要です。Windowing functions and temporal joins require additional SU. 可能であれば、各パーティションが個別に処理されるように、PARTITION BY を使用します。When possible, use PARTITION BY so that each partition is processed separately. 詳細については、「ストリーミング ユニットの理解と調整」をご覧ください。For more information, see Understand and adjust Streaming Units.

Stream Analytics ジョブ全体を並列化できない場合は、ジョブを複数のステップに分割し、1 つ以上の並列ステップから開始することを試みます。If it's not possible to parallelize the entire Stream Analytics job, try to break the job into multiple steps, starting with one or more parallel steps. これにより、最初のステップを並列実行できます。That way, the first steps can run in parallel. たとえば、この参照アーキテクチャでは、ステップは次のようになります。For example, in this reference architecture:

  • ステップ 1 と 2 は、1 つのパーティション内のレコードを選択する単純な SELECT ステートメントです。Steps 1 and 2 are simple SELECT statements that select records within a single partition.
  • ステップ 3 では、2 つの入力ストリーム間でパーティション結合を実行します。Step 3 performs a partitioned join across two input streams. このステップでは、一致するレコードは同じパーティション キーを共有するので、各入力ストリームに同じパーティション ID が含まれていることが保証されるという事実を利用しています。This step takes advantage of the fact that matching records share the same partition key, and so are guaranteed to have the same partition ID in each input stream.
  • ステップ 4 では、すべてのパーティションにわたる集計を実行します。Step 4 aggregates across all of the partitions. このステップは並列化できません。This step cannot be parallelized.

ジョブの各ステップに割り当てられているパーティションの数を確認するには、Stream Analytics のジョブ ダイアグラムを使用します。Use the Stream Analytics job diagram to see how many partitions are assigned to each step in the job. 次の図は、この参照アーキテクチャのジョブ ダイアグラムを示しています。The following diagram shows the job diagram for this reference architecture:

ジョブ ダイアグラム

Cosmos DBCosmos DB

Cosmos DB のスループット容量は、要求ユニット (RU) で測定されます。Throughput capacity for Cosmos DB is measured in Request Units (RU). Cosmos DB コンテナーを 10,000 RU を超えてスケーリングするには、コンテナーの作成時にパーティション キーを指定し、すべてのドキュメントにパーティション キーを含める必要があります。In order to scale a Cosmos DB container past 10,000 RU, you must specify a partition key when you create the container, and include the partition key in every document.

この参照アーキテクチャでは、新しいドキュメントは 1 分に 1 回だけ (ホッピング ウィンドウ間隔) 作成されるので、スループット要件は非常に低くなっています。In this reference architecture, new documents are created only once per minute (the hopping window interval), so the throughput requirements are quite low. そのため、このシナリオではパーティション キーを割り当てる必要はありません。For that reason, there's no need to assign a partition key in this scenario.

監視に関する考慮事項Monitoring considerations

ストリーム処理ソリューションでは、システムのパフォーマンスと正常性を監視することが重要です。With any stream processing solution, it's important to monitor the performance and health of the system. Azure Monitor は、アーキテクチャで使用されている Azure サービスのメトリックと診断ログを収集します。Azure Monitor collects metrics and diagnostics logs for the Azure services used in the architecture. Azure Monitor は Azure プラットフォームに組み込まれており、アプリケーションにコードを追加する必要はありません。Azure Monitor is built into the Azure platform and does not require any additional code in your application.

次の警告シグナルは、該当する Azure リソースをスケールアウトする必要があることを示しています。Any of the following warning signals indicate that you should scale out the relevant Azure resource:

  • Event Hubs が要求を調整しているか、1 日のメッセージ クォータに近づいている。Event Hubs throttles requests or is close to the daily message quota.
  • Stream Analytics ジョブが、割り当てられたストリーミング ユニット (SU) の 80% 以上を常に使用している。The Stream Analytics job consistently uses more than 80% of allocated Streaming Units (SU).
  • Cosmos DB が要求を調整し始めている。Cosmos DB begins to throttle requests.

参照アーキテクチャには、Azure portal にデプロイされるカスタム ダッシュボードが含まれています。The reference architecture includes a custom dashboard, which is deployed to the Azure portal. アーキテクチャをデプロイしたら、Azure portal を開き、ダッシュボードの一覧から TaxiRidesDashboard を選択することでダッシュボードを表示できます。After you deploy the architecture, you can view the dashboard by opening the Azure portal and selecting TaxiRidesDashboard from list of dashboards. Azure portal でのカスタム ダッシュボードの作成とデプロイの詳細については、「プログラムによる Azure ダッシュボードの作成」をご覧ください。For more information about creating and deploying custom dashboards in the Azure portal, see Programmatically create Azure Dashboards.

次の画像は、Stream Analytics ジョブが約 1 時間実行された後のダッシュボードを示しています。The following image shows the dashboard after the Stream Analytics job ran for about an hour.

タクシー乗車情報ダッシュボードのスクリーンショット

左下のパネルは、Stream Analytics ジョブの SU 消費量が最初の 15 分間に上昇した後、横ばい状態になっていることを示しています。The panel on the lower left shows that the SU consumption for the Stream Analytics job climbs during the first 15 minutes and then levels off. これは、ジョブが定常状態に達するときの一般的なパターンです。This is a typical pattern as the job reaches a steady state.

右上のパネルに示すように、Event Hubs が要求を調整していることに注意してください。Notice that Event Hubs is throttling requests, shown in the upper right panel. Event Hubs クライアント SDK は、調整エラーが発生すると自動的に再試行するため、不定期に調整される要求は問題ありません。An occasional throttled request is not a problem, because the Event Hubs client SDK automatically retries when it receives a throttling error. ただし、調整エラーが常に発生する場合は、イベント ハブにより多くのスループット ユニットが必要であることを意味しています。However, if you see consistent throttling errors, it means the event hub needs more throughput units. 次のグラフは、必要に応じてスループット ユニットを自動的にスケールアウトする、Event Hubs の自動インフレ機能を使用したテストの実行を示しています。The following graph shows a test run using the Event Hubs auto-inflate feature, which automatically scales out the throughput units as needed.

Event Hubs の自動スケールのスクリーンショット

自動インフレは、06:35 マークあたりで有効化されました。Auto-inflate was enabled at about the 06:35 mark. Event Hubs が 3 スループット ユニットに自動的にスケールアップされたため、調整された要求数が激減していることがわかります。You can see the p drop in throttled requests, as Event Hubs automatically scaled up to 3 throughput units.

興味深いのは、これには、Stream Analytics ジョブの SU 使用率が増加するという副作用があったことです。Interestingly, this had the side effect of increasing the SU utilization in the Stream Analytics job. 調整によって、Event Hubs は Stream Analytics ジョブの取り込み率を故意に下げていました。By throttling, Event Hubs was artificially reducing the ingestion rate for the Stream Analytics job. パフォーマンスの 1 つのボトルネックの解消によって、別のボトルネックが明らかになることは実際によくあります。It's actually common that resolving one performance bottleneck reveals another. この例では、Stream Analytics ジョブに追加の SU を割り当てることで問題が解決されました。In this case, allocating additional SU for the Stream Analytics job resolved the issue.

コストに関する考慮事項Cost considerations

コストの見積もりには、Azure 料金計算ツールをご利用ください。Use the Azure pricing calculator to estimate costs. ここでは、この参照アーキテクチャで使用されるサービスに関するいくつかの考慮事項を示します。Here are some considerations for services used in this reference architecture.

Azure Stream AnalyticsAzure Stream Analytics

Azure Stream Analytics の価格は、サービスに入力されるデータを処理するために必要なストリーミング ユニット ($0.11/時) の数に基づいて決まります。Azure Stream Analytics is priced by the number of streaming units ($0.11/hour) required to process the data into the service.

リアルタイムでデータを処理していない場合、または処理するデータが少量ではない場合は、Stream Analytics のコストが高くなる可能性があります。Stream Analytics can be expensive if you are not processing the data in real-time or small amounts of data. それらのユース ケースについては、Azure Functions または Logic Apps を使用して、Azure Event Hubs からデータ ストアにデータを移動することを検討してください。For those use cases, consider using Azure Functions or Logic Apps to move data from Azure Event Hubs to a data store.

Azure Event Hubs および Azure Cosmos DBAzure Event Hubs and Azure Cosmos DB

Azure Event Hubs と Cosmos DB のコストに関する考慮事項については、Azure Databricks によるストリーム処理に関する参照アーキテクチャの「コストに関する考慮事項」を参照してください。For cost considerations about Azure Event Hubs and Cosmos DB, see Cost considerations see the Stream processing with Azure Databricks reference architecture.

ソリューションのデプロイ方法Deploy the solution

リファレンス実装をデプロイおよび実行するには、GitHub readme の手順に従ってください。To the deploy and run the reference implementation, follow the steps in the GitHub readme.

DevOps の考慮事項DevOps considerations

  • 運用、開発、およびテスト環境それぞれに対して個別のリソース グループを作成してください。Create separate resource groups for production, development, and test environments. 個別のリソース グループにより、デプロイの管理、テスト デプロイの削除、およびアクセス権の割り当てが行いやすくなります。Separate resource groups make it easier to manage deployments, delete test deployments, and assign access rights.

  • Azure Resource Manager テンプレートを使用して、コードとしてのインフラストラクチャ (IaC) プロセスに従って Azure リソースをデプロイします。Use Azure Resource Manager template to deploy the Azure resources following the infrastructure as Code (IaC) Process. テンプレートを使用すると、Azure DevOps Services またはその他の CI/CD ソリューションを使用したデプロイの自動化が簡単になります。With templates, automating deployments using Azure DevOps Services, or other CI/CD solutions is easier.

  • 各ワークロードを別々のデプロイ テンプレートに配置し、リソースをソース管理システムに格納します。Put each workload in a separate deployment template and store the resources in source control systems. テンプレートは一緒にデプロイすることも、CI/CD プロセスの一環として個別にデプロイすることもできるため、自動化プロセスが簡単になります。You can deploy the templates together or individually as part of a CI/CD process, making the automation process easier.

    このアーキテクチャでは、Azure Event Hubs、Log Analytics、および Cosmos DB が 1 つのワークロードとして識別されます。In this architecture, Azure Event Hubs, Log Analytics, and Cosmos DB are identified as a single workload. これらのリソースは、1 つの ARM テンプレートに含まれます。These resources are included in a single ARM template.

  • ワークロードをステージングすることを検討してください。Consider staging your workloads. さまざまなステージにデプロイし、各ステージで検証チェックを実行してから、次のステージに進みます。Deploy to various stages and run validation checks at each stage before moving to the next stage. これにより、高度に制御された方法で運用環境に更新プログラムをプッシュし、予期しないデプロイの問題を最小限に抑えることができます。That way you can push updates to your production environments in a highly controlled way and minimize unanticipated deployment issues.

  • ストリーム処理パイプラインのパフォーマンスを分析するには、Azure Monitor の使用を検討してください。Consider using Azure Monitor to analyze the performance of your stream processing pipeline. 詳細については、「Azure Databricks の監視」を参照してください。For more information, see Monitoring Azure Databricks.

詳細については、「Microsoft Azure Well-Architected Framework」の DevOps のセクションを参照してください。For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

同じテクノロジの一部を使用する具体的なソリューションを示す次の Azure のサンプル シナリオをレビューできます。You may wish to review the following Azure example scenarios that demonstrate specific solutions using some of the same technologies: