Zpracování streamů s využitím Azure Stream Analytics

Cosmos DB
Event Hubs
Monitor
Stream Analytics

Tato referenční architektura ukazuje kompletní kanál zpracování streamování .This reference architecture shows an end-to-end stream processing pipeline. Kanál ingestuje data ze dvou zdrojů, koreluje záznamy ve dvou datových proudech a vypočte klouzavý průměr v časovém intervalu.The pipeline ingests data from two sources, correlates records in the two streams, and calculates a rolling average across a time window. Výsledky jsou uloženy pro další analýzu.The results are stored for further analysis.

Logo GitHubu : referenční implementace pro tuto architekturu je k dispozici na GitHubu.GitHub logo A reference implementation for this architecture is available on GitHub.

Referenční architektura pro vytvoření kanálu zpracování datového proudu pomocí Azure Stream Analytics

Scénář: společnost taxislužby shromažďuje data o každé taxislužbyové cestě.Scenario: A taxi company collects data about each taxi trip. V tomto scénáři předpokládáme, že existují dvě samostatná zařízení odesílající data.For this scenario, we assume there are two separate devices sending data. Taxislužby má měřič, který odesílá informace o každé jízdní — době, vzdálenosti a vyzvednutí a umístění dropoff.The taxi has a meter that sends information about each ride — the duration, distance, and pickup and dropoff locations. Samostatné zařízení přijímá platby od zákazníků a odesílá data o tarifech.A separate device accepts payments from customers and sends data about fares. Společnost taxislužby chce vypočítat průměrnou špičku na ujeté km v reálném čase, aby bylo možné sledovat trendy.The taxi company wants to calculate the average tip per mile driven, in real time, in order to spot trends.

ArchitekturaArchitecture

Tato architektura se skládá z následujících součástí.The architecture consists of the following components.

Zdroje dat.Data sources. V této architektuře existují dva zdroje dat, které generují datové proudy v reálném čase.In this architecture, there are two data sources that generate data streams in real time. První datový proud obsahuje jízdní informace a druhý obsahuje informace o tarifech.The first stream contains ride information, and the second contains fare information. Referenční architektura zahrnuje simulované generátory dat, který čte ze sady statických souborů a vkládá data do 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. V reálné aplikaci by zdroje dat byly zařízení nainstalovaná v taxislužby kabinách.In a real application, the data sources would be devices installed in the taxi cabs.

Event Hubs Azure.Azure Event Hubs. Event Hubs je služba pro přijímání událostí.Event Hubs is an event ingestion service. Tato architektura používá dvě instance centra událostí, jednu pro každý zdroj dat.This architecture uses two event hub instances, one for each data source. Každý zdroj dat pošle datový proud dat do přidruženého centra událostí.Each data source sends a stream of data to the associated event hub.

Azure Stream Analytics.Azure Stream Analytics. Stream Analytics je modul pro zpracování událostí.Stream Analytics is an event-processing engine. Úloha Stream Analytics načte datové proudy ze dvou Center událostí a provede zpracování streamu.A Stream Analytics job reads the data streams from the two event hubs and performs stream processing.

Cosmos DB.Cosmos DB. Výstupem z Stream Analytics úlohy je řada záznamů, které jsou zapsány jako dokumenty JSON do databáze Cosmos DB dokumentů.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 BI.Microsoft Power BI. Power BI je sada nástrojů pro obchodní analýzy, která slouží k analýze dat pro obchodní přehledy.Power BI is a suite of business analytics tools to analyze data for business insights. V této architektuře načte data z Cosmos DB.In this architecture, it loads the data from Cosmos DB. To umožňuje uživatelům analyzovat kompletní sadu historických dat, která se shromažďují.This allows users to analyze the complete set of historical data that's been collected. Výsledky můžete také streamovat přímo z Stream Analytics do Power BI pro zobrazení dat v reálném čase.You could also stream the results directly from Stream Analytics to Power BI for a real-time view of the data. Další informace najdete v článku o streamování v reálném čase v Power BI.For more information, see Real-time streaming in Power BI.

Azure monitor.Azure Monitor. Azure monitor shromažďuje metriky výkonu o službách Azure nasazených v řešení.Azure Monitor collects performance metrics about the Azure services deployed in the solution. Díky vizualizaci na řídicím panelu můžete získat přehled o stavu řešení.By visualizing these in a dashboard, you can get insights into the health of the solution.

Přijímání datData ingestion

Pro simulaci zdroje dat tato referenční architektura používá datovou sadu dat New York City taxislužby data [1].To simulate a data source, this reference architecture uses the New York City Taxi Data dataset[1]. Tato datová sada obsahuje data o cestách taxislužby v New Yorku po čtyřech letech (2010 – 2013).This dataset contains data about taxi trips in New York City over a four-year period (2010–2013). Obsahuje dva typy záznamů: jízdní data a data tarifů.It contains two types of record: ride data and fare data. Jízdní data zahrnují dobu trvání cesty, vzdálenost cest a místo vyzvednutí a dropoff.Ride data includes trip duration, trip distance, and pickup and dropoff location. Data tarifů zahrnují výši tarifů, daní a tipů.Fare data includes fare, tax, and tip amounts. Mezi společná pole v obou typech záznamů patří číslo Medallion, licence pro napadení a ID dodavatele.Common fields in both record types include medallion number, hack license, and vendor ID. Společně tato tři pole jednoznačně identifikují taxislužby a ovladač.Together these three fields uniquely identify a taxi plus a driver. Data jsou uložena ve formátu CSV.The data is stored in CSV format.

[1] Donovan, Brian; Work, Dan (2016): New Yorku City taxislužby Trip data (2010-2013).[1] Donovan, Brian; Work, Dan (2016): New York City Taxi Trip Data (2010-2013). Univerzita Illinois na Urbana – Champaign.University of Illinois at Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

Generátor dat je aplikace .NET Core, která načte záznamy a odesílá je do Azure Event Hubs.The data generator is a .NET Core application that reads the records and sends them to Azure Event Hubs. Generátor odesílá jízdní data ve formátu JSON a data tarifů ve formátu CSV.The generator sends ride data in JSON format and fare data in CSV format.

Event Hubs používá k segmentaci dat oddíly .Event Hubs uses partitions to segment the data. Oddíly umožňují příjemci číst jednotlivé oddíly paralelně.Partitions allow a consumer to read each partition in parallel. Když odesíláte data do Event Hubs, můžete klíč oddílu zadat explicitně.When you send data to Event Hubs, you can specify the partition key explicitly. V opačném případě se záznamy přiřazují oddílům v kruhovém dotazování.Otherwise, records are assigned to partitions in round-robin fashion.

V tomto konkrétním scénáři by data dat a tarifů měly končit stejným ID oddílu pro daný taxislužby CAB.In this particular scenario, ride data and fare data should end up with the same partition ID for a given taxi cab. To umožňuje Stream Analytics použít stupeň paralelismu při korelaci dvou datových proudů.This enables Stream Analytics to apply a degree of parallelism when it correlates the two streams. Záznam v oddílu n jízdních dat bude odpovídat záznamu v oddílu n dat tarifů.A record in partition n of the ride data will match a record in partition n of the fare data.

Diagram zpracování streamu pomocí Azure Stream Analytics a Event Hubs

V generátoru dat má model Common data model pro oba typy záznamů PartitionKey vlastnost, která je zřetězením Medallion , HackLicense a VendorId .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}";
    }

Tato vlastnost slouží k poskytnutí explicitního klíče oddílu při posílání do 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);
}

Zpracování streamůStream processing

Úloha zpracování datového proudu je definována pomocí dotazu SQL s několika různými kroky.The stream processing job is defined using a SQL query with several distinct steps. První dva kroky jednoduše vybere záznamy ze dvou vstupních proudů.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
),

Další krok spojí dva vstupní proudy, abyste vybrali vyhovující záznamy z každého streamu.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
)

Tento dotaz spojuje záznamy se sadou polí, které jednoznačně identifikují odpovídající záznamy ( PartitionId a PickupTime ).This query joins records on a set of fields that uniquely identify matching records (PartitionId and PickupTime).

Poznámka

Chceme, TaxiRide TaxiFare aby datové proudy a byly spojeny jedinečnou kombinací Medallion , HackLicense VendorId a PickupTime .We want the TaxiRide and TaxiFare streams to be joined by the unique combination of Medallion, HackLicense, VendorId and PickupTime. V tomto případě PartitionId zahrnuje Medallion HackLicense pole a, VendorId ale to by nemělo být považováno za obecně.In this case the PartitionId covers the Medallion, HackLicense and VendorId fields, but this should not be taken as generally the case.

V Stream Analytics se spojení dočasná, což znamená, že záznamy jsou propojeny v rámci určitého časového období.In Stream Analytics, joins are temporal, meaning records are joined within a particular window of time. V opačném případě může úloha potřebovat počkat neomezenou dobu na shodu.Otherwise, the job might need to wait indefinitely for a match. Funkce DateDiff určuje, jak daleko můžou být v čase pro shodu oddělené dva odpovídající záznamy.The DATEDIFF function specifies how far two matching records can be separated in time for a match.

Poslední krok v úloze vypočítá průměrnou špičku za kilometr a seskupí se skákající oknem po dobu 5 minut.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 poskytuje několik funkcí okna.Stream Analytics provides several windowing functions. Okno skákající se posune v čase o pevné období, v tomto případě 1 minutu na segment směrování.A hopping window moves forward in time by a fixed period, in this case 1 minute per hop. Výsledkem je vypočítat klouzavý průměr za posledních 5 minut.The result is to calculate a moving average over the past 5 minutes.

V níže uvedené architektuře jsou do Cosmos DB uloženy pouze výsledky Stream Analytics úlohy.In the architecture shown here, only the results of the Stream Analytics job are saved to Cosmos DB. V případě scénáře s velkými objemy dat zvažte také použití Event Hubs Capture k uložení dat nezpracované události do úložiště objektů BLOB v Azure.For a big data scenario, consider also using Event Hubs Capture to save the raw event data into Azure Blob storage. Uchovávání nezpracovaných dat vám umožní v pozdější době spouštět dávkové dotazy v historických datech, aby bylo možné z těchto dat odvodit nové poznatky.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.

Aspekty zabezpečeníScalability considerations

Event HubsEvent Hubs

Kapacita propustnosti Event Hubs se měří v jednotkách propustnosti.The throughput capacity of Event Hubs is measured in throughput units. Centrum událostí můžete automaticky škálovat tím, že povolíte Automatickéškálování, které automaticky škáluje jednotky propustnosti na základě provozu až po nakonfigurované maximum.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

V případě Stream Analytics se v jednotkách streamování měří výpočetní prostředky přidělené úloze.For Stream Analytics, the computing resources allocated to a job are measured in Streaming Units. Stream Analytics úlohy se nejlépe škálují, pokud je možné úlohu paralelně provést.Stream Analytics jobs scale best if the job can be parallelized. Tímto způsobem může Stream Analytics distribuovat úlohu mezi několik výpočetních uzlů.That way, Stream Analytics can distribute the job across multiple compute nodes.

Pro Event Hubs vstup použijte PARTITION BY klíčové slovo pro rozdělení úlohy Stream Analytics.For Event Hubs input, use the PARTITION BY keyword to partition the Stream Analytics job. Data budou rozdělena na podmnožiny na základě oddílů Event Hubs.The data will be divided into subsets based on the Event Hubs partitions.

Funkce oken a dočasná spojení vyžadují další SU.Windowing functions and temporal joins require additional SU. Pokud je to možné, použijte, PARTITION BY aby se každý oddíl zpracoval samostatně.When possible, use PARTITION BY so that each partition is processed separately. Další informace najdete v tématu pochopení a úprava jednotek streamování.For more information, see Understand and adjust Streaming Units.

Pokud není možné paralelizovat celou úlohu Stream Analytics, zkuste úlohu rozdělit do několika kroků, počínaje jedním nebo několika paralelními kroky.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. V takovém případě je možné první postup spustit paralelně.That way, the first steps can run in parallel. Například v této referenční architektuře:For example, in this reference architecture:

  • Kroky 1 a 2 jsou jednoduché SELECT příkazy, které v rámci jednoho oddílu vyberou záznamy.Steps 1 and 2 are simple SELECT statements that select records within a single partition.
  • Krok 3 provádí spojování oddílů mezi dvěma vstupními proudy.Step 3 performs a partitioned join across two input streams. Tento krok využívá skutečnost, že odpovídající záznamy sdílejí stejný klíč oddílu, a proto je zaručeno, že mají v každém vstupním datovém proudu stejné ID oddílu.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.
  • Krok 4 agreguje napříč všemi oddíly.Step 4 aggregates across all of the partitions. Tento krok nejde rozparalelně provést.This step cannot be parallelized.

Pomocí diagramu Stream Analytics úlohy můžete zjistit, kolik oddílů je přiřazeno k jednotlivým krokům v rámci úlohy.Use the Stream Analytics job diagram to see how many partitions are assigned to each step in the job. Diagram úloh pro tuto referenční architekturu znázorňuje následující diagram:The following diagram shows the job diagram for this reference architecture:

Diagram úloh

Cosmos DBCosmos DB

Kapacita propustnosti pro Cosmos DB se měří v jednotkách žádosti (ru).Throughput capacity for Cosmos DB is measured in Request Units (RU). Aby bylo možné škálovat kontejner Cosmos DB v minulosti 10 000 RU, je nutné při vytváření kontejneru zadat klíč oddílu a zahrnout klíč oddílu do každého dokumentu.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.

V této referenční architektuře se nové dokumenty vytvářejí jenom jednou za minutu (interval okna skákající), takže požadavky na propustnost jsou poměrně nízké.In this reference architecture, new documents are created only once per minute (the hopping window interval), so the throughput requirements are quite low. Z tohoto důvodu není nutné v tomto scénáři přiřazovat klíč oddílu.For that reason, there's no need to assign a partition key in this scenario.

Monitorování – požadavkyMonitoring considerations

V případě řešení pro zpracování datových proudů je důležité monitorovat výkon a stav systému.With any stream processing solution, it's important to monitor the performance and health of the system. Azure monitor shromažďuje metriky a diagnostické protokoly pro služby Azure používané v architektuře.Azure Monitor collects metrics and diagnostics logs for the Azure services used in the architecture. Azure Monitor je součástí platformy Azure a nevyžaduje žádný další kód ve vaší aplikaci.Azure Monitor is built into the Azure platform and does not require any additional code in your application.

Libovolný z následujících varovných signálů indikuje, že byste měli škálovat relevantní prostředek Azure:Any of the following warning signals indicate that you should scale out the relevant Azure resource:

  • Event Hubs omezuje požadavky nebo se blíží k denní kvótě zprávy.Event Hubs throttles requests or is close to the daily message quota.
  • Úloha Stream Analytics konzistentně používá více než 80% přidělených jednotek streamování (SU).The Stream Analytics job consistently uses more than 80% of allocated Streaming Units (SU).
  • Cosmos DB začne omezovat požadavky.Cosmos DB begins to throttle requests.

Referenční architektura obsahuje vlastní řídicí panel, který je nasazený do Azure Portal.The reference architecture includes a custom dashboard, which is deployed to the Azure portal. Po nasazení architektury si řídicí panel můžete zobrazit otevřením Azure Portal a výběrem TaxiRidesDashboard ze seznamu řídicích panelů.After you deploy the architecture, you can view the dashboard by opening the Azure portal and selecting TaxiRidesDashboard from list of dashboards. Další informace o vytváření a nasazování vlastních řídicích panelů v Azure Portal najdete v tématu programové vytváření řídicích panelů Azure.For more information about creating and deploying custom dashboards in the Azure portal, see Programmatically create Azure Dashboards.

Následující obrázek znázorňuje řídicí panel, když Stream Analytics úloha běžela přibližně hodinu.The following image shows the dashboard after the Stream Analytics job ran for about an hour.

Snímek obrazovky s řídicím panelem taxislužby jezdí

Na panelu vlevo dole vidíte, že spotřeba SU pro Stream Analytics úlohy stoupá během prvních 15 minut a pak úrovně jsou vypnuté.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. Toto je typický vzor, protože úloha dosáhne stabilního stavu.This is a typical pattern as the job reaches a steady state.

Všimněte si, že Event Hubs omezuje požadavky, které se zobrazují v pravém horním panelu.Notice that Event Hubs is throttling requests, shown in the upper right panel. Příležitostné omezení nepředstavuje problém, protože se sada SDK klienta Event Hubs automaticky opakuje, když obdrží chybu omezení.An occasional throttled request is not a problem, because the Event Hubs client SDK automatically retries when it receives a throttling error. Pokud se ale zobrazí konzistentní chyby omezování, znamená to, že centrum událostí potřebuje víc jednotek propustnosti.However, if you see consistent throttling errors, it means the event hub needs more throughput units. Následující graf znázorňuje testovací běh pomocí funkce Event Hubs automatické deflace, která automaticky škáluje jednotky propustnosti podle potřeby.The following graph shows a test run using the Event Hubs auto-inflate feature, which automatically scales out the throughput units as needed.

Snímek obrazovky Event Hubs automatického škálování

Automatické vystavení bylo povoleno v přibližně značce 06:35.Auto-inflate was enabled at about the 06:35 mark. Můžete se podívat na omezené požadavky v p, protože Event Hubs automaticky škálovat až na 3 jednotky propustnosti.You can see the p drop in throttled requests, as Event Hubs automatically scaled up to 3 throughput units.

V podstatě to mělo vedlejší dopad na zvýšení využití SU v Stream Analytics úlohy.Interestingly, this had the side effect of increasing the SU utilization in the Stream Analytics job. Omezením Event Hubs byl uměle snížena míra přijímání zpráv Stream Analytics úlohy.By throttling, Event Hubs was artificially reducing the ingestion rate for the Stream Analytics job. Je vlastně běžné, že řešení jednoho kritického bodu výkonu odhaluje další.It's actually common that resolving one performance bottleneck reveals another. V takovém případě problém vyřešila dodateča SU pro Stream Analytics úlohy.In this case, allocating additional SU for the Stream Analytics job resolved the issue.

Důležité informace o nákladechCost considerations

K odhadu nákladů použijte cenovou kalkulačku Azure.Use the Azure pricing calculator to estimate costs. Zde jsou některé informace o službách používaných v této referenční architektuře.Here are some considerations for services used in this reference architecture.

Azure Stream AnalyticsAzure Stream Analytics

Ceny Azure Stream Analytics se účtují podle počtu jednotek streamování ($ 0,11/hour) potřebných ke zpracování dat do služby.Azure Stream Analytics is priced by the number of streaming units ($0.11/hour) required to process the data into the service.

Stream Analytics může být nákladné, pokud data nezpracováváte v reálném čase nebo malým množstvím dat.Stream Analytics can be expensive if you are not processing the data in real-time or small amounts of data. Pro tyto případy použití zvažte použití Azure Functions nebo Logic Apps k přesunu dat z Azure Event Hubs do úložiště dat.For those use cases, consider using Azure Functions or Logic Apps to move data from Azure Event Hubs to a data store.

Event Hubs a Azure Cosmos DB AzureAzure Event Hubs and Azure Cosmos DB

Informace o nákladech týkajících se Azure Event Hubs a Cosmos DB najdete v tématu věnovaném nákladům na zpracování datových proudů s Azure Databricks referenční architekturou.For cost considerations about Azure Event Hubs and Cosmos DB, see Cost considerations see the Stream processing with Azure Databricks reference architecture.

Nasazení řešeníDeploy the solution

Pokud chcete nasadit a spustit referenční implementaci, postupujte podle pokynů v souboru Readme pro GitHub.To the deploy and run the reference implementation, follow the steps in the GitHub readme.

Důležité informace o DevOpsDevOps considerations

  • Vytvořte samostatné skupiny prostředků pro produkční, vývojové a testovací prostředí.Create separate resource groups for production, development, and test environments. Samostatné skupiny prostředků usnadňují správu nasazení, odstraňování testovacích nasazení a přiřazování přístupových práv.Separate resource groups make it easier to manage deployments, delete test deployments, and assign access rights.

  • Pomocí šablony Azure Resource Manager nasaďte prostředky Azure, které následují po procesu infrastruktury jako kódu (IAC).Use Azure Resource Manager template to deploy the Azure resources following the infrastructure as Code (IaC) Process. Díky šablonám je automatizace nasazení pomocí Azure DevOps Servicesnebo jiných řešení CI/CD jednodušší.With templates, automating deployments using Azure DevOps Services, or other CI/CD solutions is easier.

  • Jednotlivé úlohy umístěte do samostatné šablony nasazení a uložte je do systému správy zdrojů.Put each workload in a separate deployment template and store the resources in source control systems. Šablony můžete nasadit společně nebo jednotlivě jako součást procesu CI/CD, což usnadňuje proces automatizace.You can deploy the templates together or individually as part of a CI/CD process, making the automation process easier.

    V této architektuře se Azure Event Hubs, Log Analytics a Cosmos DB označují jako jedna úloha.In this architecture, Azure Event Hubs, Log Analytics, and Cosmos DB are identified as a single workload. Tyto prostředky jsou zahrnuté v jedné šabloně ARM.These resources are included in a single ARM template.

  • Zvažte přípravu vašich úloh.Consider staging your workloads. Nasaďte je do různých fází a před přechodem do další fáze spusťte kontroly ověřování v každé fázi.Deploy to various stages and run validation checks at each stage before moving to the next stage. Tímto způsobem můžete nabízet aktualizace do vašich produkčních prostředí vysoce kontrolovaným způsobem a minimalizovat neočekávané problémy s nasazením.That way you can push updates to your production environments in a highly controlled way and minimize unanticipated deployment issues.

  • Zvažte použití Azure monitor k analýze výkonu kanálu zpracování streamu.Consider using Azure Monitor to analyze the performance of your stream processing pipeline. Další informace najdete v tématu monitorování Azure Databricks.For more information, see Monitoring Azure Databricks.

Další informace naleznete v části DevOps v tématu Microsoft Azure Well-Architected Framework.For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

Možná si budete chtít projít následující příklady scénářů Azure , které předvádějí konkrétní řešení pomocí některých z těchto technologií:You may wish to review the following Azure example scenarios that demonstrate specific solutions using some of the same technologies: