Využití paralelismu dotazů v Azure Stream AnalyticsLeverage query parallelization in Azure Stream Analytics

V tomto článku se dozvíte, jak využít paralelismus v Azure Stream Analytics.This article shows you how to take advantage of parallelization in Azure Stream Analytics. Naučíte se, jak škálovat Stream Analytics úlohy konfigurací vstupních oddílů a optimalizací definice analytického dotazu.You learn how to scale Stream Analytics jobs by configuring input partitions and tuning the analytics query definition. Je možné, že budete chtít být obeznámeni s pojmem jednotky streamování popsané v tématu pochopení a úprava jednotek streamování.As a prerequisite, you may want to be familiar with the notion of Streaming Unit described in Understand and adjust Streaming Units.

Jaké jsou části Stream Analytics úlohy?What are the parts of a Stream Analytics job?

Definice úlohy Stream Analytics zahrnuje aspoň jeden vstup streamování, dotaz a výstup.A Stream Analytics job definition includes at least one streaming input, a query, and output. Vstupy jsou místo, odkud úloha čte datový proud z.Inputs are where the job reads the data stream from. Dotaz slouží k transformaci vstupního datového proudu a výstup je, kde úloha odešle výsledky úlohy do.The query is used to transform the data input stream, and the output is where the job sends the job results to.

Oddíly ve vstupech a výstupechPartitions in inputs and outputs

Dělení umožňuje rozdělit data na podmnožiny na základě klíče oddílu.Partitioning lets you divide data into subsets based on a partition key. Pokud je vaše zadání (například Event Hubs) rozdělené podle klíče, důrazně doporučujeme tento klíč oddílu zadat při přidávání vstupu do úlohy Stream Analytics.If your input (for example Event Hubs) is partitioned by a key, it is highly recommended to specify this partition key when adding input to your Stream Analytics job. Škálování Stream Analytics úlohy využívá oddíly ve vstupu a výstupu.Scaling a Stream Analytics job takes advantage of partitions in the input and output. Stream Analytics úloha může spotřebovávat a zapisovat různé oddíly paralelně, což zvyšuje propustnost.A Stream Analytics job can consume and write different partitions in parallel, which increases throughput.

VstupyInputs

Všechny vstupy Azure Stream Analytics můžou využít dělení na oddíly:All Azure Stream Analytics input can take advantage of partitioning:

  • EventHub (nutnost nastavení klíče oddílu explicitně pomocí klíčového slova PARTITION BY, pokud se používá úroveň kompatibility 1,1 nebo nižší)EventHub (need to set the partition key explicitly with PARTITION BY keyword if using compatibility level 1.1 or below)
  • IoT Hub (je potřeba nastavit klíč oddílu explicitně pomocí klíčového slova PARTITION BY, pokud se používá úroveň kompatibility 1,1 nebo nižší)IoT Hub (need to set the partition key explicitly with PARTITION BY keyword if using compatibility level 1.1 or below)
  • Blob StorageBlob storage

VýstupyOutputs

Při práci s Stream Analytics můžete využívat dělení ve výstupech:When you work with Stream Analytics, you can take advantage of partitioning in the outputs:

  • Azure Data Lake StorageAzure Data Lake Storage
  • Azure FunctionsAzure Functions
  • Tabulka AzureAzure Table
  • Úložiště objektů BLOB (klíč oddílu můžete explicitně nastavit)Blob storage (can set the partition key explicitly)
  • Cosmos DB (je potřeba nastavit klíč oddílu explicitně)Cosmos DB (need to set the partition key explicitly)
  • Event Hubs (je potřeba nastavit klíč oddílu explicitně)Event Hubs (need to set the partition key explicitly)
  • IoT Hub (je potřeba nastavit klíč oddílu explicitně)IoT Hub (need to set the partition key explicitly)
  • Service BusService Bus
  • SQL a Azure synapse Analytics s volitelným rozdělením na oddíly: Další informace najdete na stránce výstup do Azure SQL Database.SQL and Azure Synapse Analytics with optional partitioning: see more information on the Output to Azure SQL Database page.

Power BI nepodporuje dělení.Power BI doesn't support partitioning. Můžete však stále rozdělit vstup, jak je popsáno v této části .However you can still partition the input as described in this section

Další informace o oddílech najdete v následujících článcích:For more information about partitions, see the following articles:

Paralelní úlohy zpracovatelnéEmbarrassingly parallel jobs

Zpracovatelné paralelní úloha je nejškálovatelný scénář v Azure Stream Analytics.An embarrassingly parallel job is the most scalable scenario in Azure Stream Analytics. Připojí jeden oddíl vstupu k jedné instanci dotazu k jednomu oddílu výstupu.It connects one partition of the input to one instance of the query to one partition of the output. Tento paralelismus má následující požadavky:This parallelism has the following requirements:

  1. Pokud vaše logika dotazu závisí na stejném klíči, který je zpracováván stejnou instancí dotazu, je nutné zajistit, aby události přešly do stejného oddílu vašeho vstupu.If your query logic depends on the same key being processed by the same query instance, you must make sure that the events go to the same partition of your input. Pro Event Hubs nebo IoT Hub to znamená, že data události musí mít nastavenou hodnotu PartitionKey .For Event Hubs or IoT Hub, this means that the event data must have the PartitionKey value set. Alternativně můžete použít rozdělené odesílatele.Alternatively, you can use partitioned senders. Pro úložiště objektů blob to znamená, že se události odesílají do stejné složky oddílu.For blob storage, this means that the events are sent to the same partition folder. Příkladem může být instance dotazu, která agreguje data na ID uživatele, kde je vstupní centrum událostí dělené jako klíč oddílu pomocí userID.An example would be a query instance that aggregates data per userID where input event hub is partitioned using userID as partition key. Pokud však logika dotazu nevyžaduje, aby se stejný klíč zpracoval pomocí stejné instance dotazu, můžete tento požadavek ignorovat.However, if your query logic does not require the same key to be processed by the same query instance, you can ignore this requirement. Příkladem této logiky je jednoduchý dotaz SELECT-Project-Filter.An example of this logic would be a simple select-project-filter query.

  2. Dalším krokem je vytvoření oddílů dotazu.The next step is to make your query is partitioned. Pro úlohy s úrovní kompatibility 1,2 nebo vyšší (doporučeno) je možné zadat vlastní sloupec jako klíč oddílu ve vstupním nastavení a úloha bude paralellized automaticky.For jobs with compatibility level 1.2 or higher (recommended), custom column can be specified as Partition Key in the input settings and the job will be paralellized automatically. Úlohy s úrovní kompatibility 1,0 nebo 1,1 vyžadují, abyste v všech krocích dotazu používali partition by PartitionID .Jobs with compatibility level 1.0 or 1.1, requires you to use PARTITION BY PartitionId in all the steps of your query. Je povoleno více kroků, ale všechny musí být rozděleny stejným klíčem.Multiple steps are allowed, but they all must be partitioned by the same key.

  3. Většina výstupů podporovaných v Stream Analytics může využít dělení.Most of the outputs supported in Stream Analytics can take advantage of partitioning. Pokud použijete typ výstupu, který nepodporuje vytváření oddílů vaší úlohy, nebude zpracovatelné paralelní.If you use an output type that doesn't support partitioning your job won't be embarrassingly parallel. Pro výstupy centra událostí se ujistěte, že je sloupec klíč oddílu nastavený na stejný klíč oddílu, který se používá v dotazu.For Event Hub outputs, ensure Partition key column is set to the same partition key used in the query. Další podrobnosti najdete v části s výstupem .Refer to the output section for more details.

  4. Počet vstupních oddílů musí být stejný jako počet výstupních oddílů.The number of input partitions must equal the number of output partitions. Výstup služby Blob Storage může podporovat oddíly a zdědí schéma dělení nadřazeného dotazu.Blob storage output can support partitions and inherits the partitioning scheme of the upstream query. Když je zadaný klíč oddílu pro úložiště objektů blob, budou se data rozdělit na oddíly na vstupním oddílu, takže výsledek bude pořád plně paralelní.When a partition key for Blob storage is specified, data is partitioned per input partition thus the result is still fully parallel. Tady jsou příklady hodnot oddílů, které umožňují plně paralelní úlohu:Here are examples of partition values that allow a fully parallel job:

    • 8 vstupních oddílů centra událostí a 8 výstupních oddílů centra událostí8 event hub input partitions and 8 event hub output partitions
    • 8 vstupních oddílů centra událostí a výstupu služby Blob Storage8 event hub input partitions and blob storage output
    • 8 vstupních oddílů centra událostí a výstupu služby Blob Storage dělené vlastním polem s libovolnou mohutnosti8 event hub input partitions and blob storage output partitioned by a custom field with arbitrary cardinality
    • 8 vstupních oddílů služby Blob Storage a výstupu služby Blob Storage8 blob storage input partitions and blob storage output
    • 8 vstupních oddílů služby Blob Storage a 8 výstupních oddílů centra událostí8 blob storage input partitions and 8 event hub output partitions

Následující části popisují některé příklady scénářů, které jsou zpracovatelné paralelní.The following sections discuss some example scenarios that are embarrassingly parallel.

Jednoduchý dotazSimple query

  • Vstup: centrum událostí s 8 oddílyInput: Event hub with 8 partitions
  • Výstup: centrum událostí s 8 oddíly ("sloupec klíče oddílu" musí být nastaven na použití "PartitionId")Output: Event hub with 8 partitions ("Partition key column" must be set to use "PartitionId")

Dotaz:Query:

    --Using compatibility level 1.2 or above
    SELECT TollBoothId
    FROM Input1
    WHERE TollBoothId > 100
    
    --Using compatibility level 1.0 or 1.1
    SELECT TollBoothId
    FROM Input1 PARTITION BY PartitionId
    WHERE TollBoothId > 100

Tento dotaz je jednoduchým filtrem.This query is a simple filter. Proto se nemusíte starat o dělení vstupu, který se odesílá do centra událostí.Therefore, we don't need to worry about partitioning the input that is being sent to the event hub. Všimněte si, že úlohy s úrovní kompatibility před 1,2 musí zahrnovat oddíl podle identifikátoru PartitionID , takže splní #2 požadavku ze starší verze.Notice that jobs with compatibility level before 1.2 must include PARTITION BY PartitionId clause, so it fulfills requirement #2 from earlier. Pro výstup musíme v úloze nakonfigurovat výstup centra událostí tak, aby byl klíč oddílu nastavený na PartitionID.For the output, we need to configure the event hub output in the job to have the partition key set to PartitionId. Od poslední kontroly se ujistěte, že počet vstupních oddílů je stejný jako počet výstupních oddílů.One last check is to make sure that the number of input partitions is equal to the number of output partitions.

Dotaz s klíčem seskupeníQuery with a grouping key

  • Vstup: centrum událostí s 8 oddílyInput: Event hub with 8 partitions
  • Výstup: BLOB StorageOutput: Blob storage

Dotaz:Query:

    --Using compatibility level 1.2 or above
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    
    --Using compatibility level 1.0 or 1.1
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Tento dotaz obsahuje klíč seskupení.This query has a grouping key. Proto se události seskupené dohromady musí odeslat do stejného oddílu centra událostí.Therefore, the events grouped together must be sent to the same Event Hub partition. Vzhledem k tomu, že v tomto příkladu budeme seskupovat podle TollBoothID, měli byste se ujistit, že se při posílání událostí do centra událostí používá jako klíč oddílu TollBoothID.Since in this example we group by TollBoothID, we should be sure that TollBoothID is used as the partition key when the events are sent to Event Hub. Potom můžeme v ASA použít oddíl podle identifikátoru PartitionID k dědění z tohoto schématu oddílu a povolení úplného paralelismu.Then in ASA, we can use PARTITION BY PartitionId to inherit from this partition scheme and enable full parallelization. Vzhledem k tomu, že výstupem je úložiště objektů blob, nemusíte si dělat starosti s konfigurací hodnoty klíče oddílu, jak #4 podle požadavků.Since the output is blob storage, we don't need to worry about configuring a partition key value, as per requirement #4.

Příklady scénářů, které nejsou zpracovatelné paralelníExample of scenarios that are not embarrassingly parallel

V předchozí části jsme ukázali, že jsme zpracovatelné paralelní scénáře.In the previous section, we showed some embarrassingly parallel scenarios. V této části se podíváme na scénáře, které nesplňují všechny požadavky zpracovatelné Parallel.In this section, we discuss scenarios that don't meet all the requirements to be embarrassingly parallel.

Počet neodpovídajících oddílůMismatched partition count

  • Vstup: centrum událostí s 8 oddílyInput: Event hub with 8 partitions
  • Výstup: centrum událostí s 32 oddílyOutput: Event hub with 32 partitions

Pokud se počet vstupních oddílů neshoduje s počtem výstupních oddílů, topologie nebude zpracovatelné paralelně bez ohledu na dotaz.If the input partition count doesn't match the output partition count, the topology isn't embarrassingly parallel irrespective of the query. Pořád ale můžeme získat nějakou úroveň nebo paralelní zpracování.However we can still get some level or parallelization.

Dotazování pomocí nerozděleného výstupuQuery using non-partitioned output

  • Vstup: centrum událostí s 8 oddílyInput: Event hub with 8 partitions
  • Výstup: Power BIOutput: Power BI

Výstup Power BI v současné době nepodporuje dělení.Power BI output doesn't currently support partitioning. Proto tento scénář není zpracovatelné paralelně.Therefore, this scenario is not embarrassingly parallel.

Dotaz na více kroků s různými hodnotami oddílůMulti-step query with different PARTITION BY values

  • Vstup: centrum událostí s 8 oddílyInput: Event hub with 8 partitions
  • Výstup: centrum událostí s 8 oddílyOutput: Event hub with 8 partitions
  • Úroveň kompatibility: 1,0 nebo 1,1Compatibility level: 1.0 or 1.1

Dotaz:Query:

    WITH Step1 AS (
    SELECT COUNT(*) AS Count, TollBoothId, PartitionId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
    )

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1 Partition By TollBoothId
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Jak vidíte, druhý krok používá TollBoothId jako klíč rozdělení do oddílů.As you can see, the second step uses TollBoothId as the partitioning key. Tento krok není stejný jako první krok, a proto je pro nás potřeba provést náhodné provedení.This step is not the same as the first step, and it therefore requires us to do a shuffle.

Dotaz na více kroků s různými hodnotami oddílůMulti-step query with different PARTITION BY values

  • Vstup: centrum událostí s 8 oddílyInput: Event hub with 8 partitions
  • Výstup: centrum událostí s 8 oddíly ("sloupec klíče oddílu" musí být nastaven na použití "TollBoothId")Output: Event hub with 8 partitions ("Partition key column" must be set to use "TollBoothId")
  • Úroveň kompatibility – 1,2 nebo vyššíCompatibility level - 1.2 or above

Dotaz:Query:

    WITH Step1 AS (
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    )

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Úroveň kompatibility 1,2 nebo vyšší umožňuje spuštění paralelního dotazu ve výchozím nastavení.Compatibility level 1.2 or above enables parallel query execution by default. Například dotaz z předchozí části bude rozdělený tak dlouho, dokud je sloupec "TollBoothId" nastaven jako klíč vstupního oddílu.For example, query from the previous section will be partitioned as long as "TollBoothId" column is set as input Partition Key. Klauzule PARTITION BY PartitionId není povinná.PARTITION BY PartitionId clause is not required.

Vypočítat maximální počet jednotek streamování úlohyCalculate the maximum streaming units of a job

Celkový počet jednotek streamování, které může úloha Stream Analytics použít, závisí na počtu kroků v dotazu definovaném pro úlohu a na počtu oddílů pro každý krok.The total number of streaming units that can be used by a Stream Analytics job depends on the number of steps in the query defined for the job and the number of partitions for each step.

Kroky v dotazuSteps in a query

Dotaz může mít jeden nebo několik kroků.A query can have one or many steps. Každý krok je poddotaz definovaný pomocí klíčového slova with .Each step is a subquery defined by the WITH keyword. Dotaz, který je mimo klíčové slovo with (pouze jeden dotaz), se také počítá jako krok, například příkaz Select v následujícím dotazu:The query that is outside the WITH keyword (one query only) is also counted as a step, such as the SELECT statement in the following query:

Dotaz:Query:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        FROM Input1 Partition By PartitionId
        GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
    )
    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute,3), TollBoothId

Tento dotaz má dva kroky.This query has two steps.

Poznámka

Tento dotaz se podrobněji popisuje dále v článku.This query is discussed in more detail later in the article.

Oddíl a krokPartition a step

Rozdělení kroku na oddíly vyžaduje tyto podmínky:Partitioning a step requires the following conditions:

  • Vstupní zdroj musí být rozdělený na oddíly.The input source must be partitioned.
  • Příkaz Select dotazu musí číst z rozděleného vstupního zdroje.The SELECT statement of the query must read from a partitioned input source.
  • Dotaz v kroku musí mít oddíl podle klíčového slova.The query within the step must have the PARTITION BY keyword.

Když je dotaz rozdělený na oddíly, vstupní události se zpracují a agreguje v samostatných skupinách oddílů a pro každou skupinu se vygenerují události s výstupem.When a query is partitioned, the input events are processed and aggregated in separate partition groups, and outputs events are generated for each of the groups. Pokud chcete kombinovat agregaci, musíte pro agregaci vytvořit druhý krok bez oddílů.If you want a combined aggregate, you must create a second non-partitioned step to aggregate.

Vypočítat maximální počet jednotek streamování pro úlohuCalculate the max streaming units for a job

Všechny kroky, které nejsou rozdělené do oddílů, můžou společně škálovat až šest jednotek streamování (SUs) pro úlohu Stream Analytics.All non-partitioned steps together can scale up to six streaming units (SUs) for a Stream Analytics job. Kromě toho můžete přidat 6 služby SUs pro každý oddíl do děleného kroku.In addition to this, you can add 6 SUs for each partition in a partitioned step. V následující tabulce vidíte některé Příklady .You can see some examples in the table below.

DotazQuery Maximální služba SUs pro úlohuMax SUs for the job
  • Dotaz obsahuje jeden krok.The query contains one step.
  • Tento krok není rozdělený.The step is not partitioned.
66
  • Vstupní datový proud je rozdělen o 16.The input data stream is partitioned by 16.
  • Dotaz obsahuje jeden krok.The query contains one step.
  • Tento krok je rozdělený na oddíly.The step is partitioned.
96 (6 × 16 oddílů)96 (6 * 16 partitions)
  • Dotaz obsahuje dva kroky.The query contains two steps.
  • Ani jeden z kroků není rozdělený.Neither of the steps is partitioned.
66
  • Vstupní datový proud je rozdělen podle 3.The input data stream is partitioned by 3.
  • Dotaz obsahuje dva kroky.The query contains two steps. Vstupní krok je rozdělený na oddíly a druhý krok ne.The input step is partitioned and the second step is not.
  • Příkaz Select načte z rozděleného vstupu.The SELECT statement reads from the partitioned input.
24 (18 pro dělené kroky + 6 pro kroky bez oddílů)24 (18 for partitioned steps + 6 for non-partitioned steps

Příklady škálováníExamples of scaling

Následující dotaz vypočítá počet vozidel v rámci tří minut, který prochází telefonní stanicí, která má tři tollbooths.The following query calculates the number of cars within a three-minute window going through a toll station that has three tollbooths. Tento dotaz se dá škálovat až na šest SUs.This query can be scaled up to six SUs.

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Aby bylo možné použít pro dotaz více SUs, musí být vstupní datový proud i dotaz rozděleny na oddíly.To use more SUs for the query, both the input data stream and the query must be partitioned. Vzhledem k tomu, že oddíl datového proudu je nastavený na hodnotu 3, může se škálovat následující upravený dotaz až o 18 SUs:Since the data stream partition is set to 3, the following modified query can be scaled up to 18 SUs:

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Když je dotaz rozdělený na oddíly, vstupní události se zpracují a agreguje do samostatných skupin oddílů.When a query is partitioned, the input events are processed and aggregated in separate partition groups. Výstupní události jsou také generovány pro každou skupinu.Output events are also generated for each of the groups. Dělení může způsobit neočekávané výsledky, když pole Seskupit podle není klíč oddílu ve vstupním datovém proudu.Partitioning can cause some unexpected results when the GROUP BY field is not the partition key in the input data stream. Například pole TollBoothId v předchozím dotazu není klíčem oddílu Input1.For example, the TollBoothId field in the previous query is not the partition key of Input1. Výsledkem je, že data z TollBooth #1 lze rozložit do více oddílů.The result is that the data from TollBooth #1 can be spread in multiple partitions.

Každý z oddílů Input1 se zpracuje samostatně pomocí Stream Analytics.Each of the Input1 partitions will be processed separately by Stream Analytics. Výsledkem je, že se vytvoří několik záznamů o počtu automobilů pro stejné tollboothy ve stejném Bubnovém okně.As a result, multiple records of the car count for the same tollbooth in the same Tumbling window will be created. Pokud se klíč vstupního oddílu nedá změnit, můžete tento problém vyřešit přidáním kroku, který není rozdělený na oddíly pro agregaci hodnot napříč oddíly, jako v následujícím příkladu:If the input partition key can't be changed, this problem can be fixed by adding a non-partition step to aggregate values across partitions, as in the following example:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        FROM Input1 Partition By PartitionId
        GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
    )

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Tento dotaz lze škálovat na 24 SUs.This query can be scaled to 24 SUs.

Poznámka

Pokud se připojujete ke dvěma datovým proudům, ujistěte se, že jsou datové proudy rozdělené podle klíče oddílu sloupce, který používáte k vytvoření spojení.If you are joining two streams, make sure that the streams are partitioned by the partition key of the column that you use to create the joins. Také se ujistěte, že v obou datových proudech máte stejný počet oddílů.Also make sure that you have the same number of partitions in both streams.

Dosažení vyšších propustností ve velkém měřítkuAchieving higher throughputs at scale

Zpracovatelné paralelní úloha je nutná, ale není dostatečná pro udržení vyšší propustnosti ve velkém měřítku.An embarrassingly parallel job is necessary but not sufficient to sustain a higher throughput at scale. Každý systém úložiště a příslušný výstup Stream Analytics obsahuje variace toho, jak dosáhnout nejlepší možné propustnosti zápisu.Every storage system and its corresponding Stream Analytics output has variations on how to achieve the best possible write throughput. Stejně jako u všech scénářů ve velkém měřítku se dají vyřešit některé výzvy, které je možné vyřešit pomocí správných konfigurací.As with any at-scale scenario, there are some challenges which can be solved by using the right configurations. Tato část pojednává o konfiguracích pro několik běžných výstupů a obsahuje ukázky pro udržení sazeb ingestování 1 tisíc, 5K a 10 000 událostí za sekundu.This section discusses configurations for a few common outputs and provides samples for sustaining ingestion rates of 1K, 5K and 10K events per second.

Následující poznámky používají úlohu Stream Analytics s dotazem bez stavu (Passthrough), základní jazyk JavaScript UDF, který zapisuje do centra událostí, Azure SQL DB nebo Cosmos DB.The following observations use a Stream Analytics job with stateless (passthrough) query, a basic JavaScript UDF which writes to Event Hub, Azure SQL DB, or Cosmos DB.

Centrum událostíEvent Hub

Rychlost přijímání zpráv (události za sekundu)Ingestion Rate (events per second) Jednotky streamováníStreaming Units Výstupní prostředkyOutput Resources
1 tis.1K 11 2 TU2 TU
5K5K 66 6.6 TU
10K10K 1212 10 Z10 TU

Řešení centra událostí se škáluje lineárně v podobě jednotek streamování (SU) a propustnosti, takže je nejúčinnější a výkonný způsob analýzy a streamování dat z Stream Analytics.The Event Hub solution scales linearly in terms of streaming units (SU) and throughput, making it the most efficient and performant way to analyze and stream data out of Stream Analytics. Úlohy je možné škálovat až do 192 SU, což zhruba souvisí se zpracováním až 200 MB/s, nebo 19 000 000 000 000 událostí za den.Jobs can be scaled up to 192 SU, which roughly translates to processing up to 200 MB/s, or 19 trillion events per day.

Azure SQLAzure SQL

Rychlost přijímání zpráv (události za sekundu)Ingestion Rate (events per second) Jednotky streamováníStreaming Units Výstupní prostředkyOutput Resources
1 tis.1K 33 S3S3
5K5K 1818 P4P4
10K10K 3636 P6P6

Azure SQL podporuje zapisování paralelně, označované jako dědění oddílů, ale není ve výchozím nastavení povolené.Azure SQL supports writing in parallel, called Inherit Partitioning, but it's not enabled by default. Povolení dědění rozdělení na oddíly, společně s plně paralelním dotazem, ale nemusí být dostačující pro dosažení vyšší propustnosti.However, enabling Inherit Partitioning, along with a fully parallel query, may not be sufficient to achieve higher throughputs. Propustnost zápisu SQL závisí významně na konfiguraci databáze a schématu tabulek.SQL write throughputs depend significantly on your database configuration and table schema. Článek o výkonu SQL Output obsahuje další podrobnosti o parametrech, které můžou maximalizovat propustnost zápisu.The SQL Output Performance article has more detail about the parameters that can maximize your write throughput. Jak je uvedeno ve výstupu Azure Stream Analytics Azure SQL Database článku, toto řešení se neškáluje lineárně jako plně paralelní kanál nad rámec 8 oddílů a může vyžadovat přerozdělení do výstupu SQL (viz do).As noted in the Azure Stream Analytics output to Azure SQL Database article, this solution doesn't scale linearly as a fully parallel pipeline beyond 8 partitions and may need repartitioning before SQL output (see INTO). Skladové jednotky úrovně Premium se potřebují pro udržení vysokého vstupně-výstupních operací spolu se režiemi ze záloh protokolů při každém několika minutách.Premium SKUs are needed to sustain high IO rates along with overhead from log backups happening every few minutes.

Cosmos DBCosmos DB

Rychlost přijímání zpráv (události za sekundu)Ingestion Rate (events per second) Jednotky streamováníStreaming Units Výstupní prostředkyOutput Resources
1 tis.1K 33 20 TISÍC RU20K RU
5K5K 2424 60K RU60K RU
10K10K 4848 120K RU120K RU

Cosmos DB výstup z Stream Analytics byl aktualizován tak, aby používal nativní integraci do úrovně kompatibility 1,2.Cosmos DB output from Stream Analytics has been updated to use native integration under compatibility level 1.2. Úroveň kompatibility 1,2 umožňuje významně vyšší propustnost a snižuje spotřebu RU v porovnání s 1,1, což je výchozí úroveň kompatibility pro nové úlohy.Compatibility level 1.2 enables significantly higher throughput and reduces RU consumption compared to 1.1, which is the default compatibility level for new jobs. Toto řešení využívá kontejnery CosmosDB rozdělené na/deviceId a zbytek řešení je identický nakonfigurované.The solution uses CosmosDB containers partitioned on /deviceId and the rest of solution is identically configured.

Všechny datové proudy ve zkušebních ukázkách Azure používají jako vstup centrum událostí jako vstup, který je dodaný zátěží pro simulaci testovacích klientů.All Streaming at Scale Azure samples use an Event Hub as input that is fed by load simulating test clients. Každá vstupní událost je dokument 1 KB JSON, který překládá nakonfigurovanou rychlost přijímání do propustnosti (1 MB/s, 5 MB/s a 10 MB/s) snadno.Each input event is a 1KB JSON document, which translates configured ingestion rates to throughput rates (1MB/s, 5MB/s and 10MB/s) easily. Události simulují zařízení IoT odesílající následující data JSON (ve zkrácené formě) až do zařízení 1 tisíc:Events simulate an IoT device sending the following JSON data (in a shortened form) for up to 1K devices:

{
    "eventId": "b81d241f-5187-40b0-ab2a-940faf9757c0",
    "complexData": {
        "moreData0": 51.3068118685458,
        "moreData22": 45.34076957651598
    },
    "value": 49.02278128887753,
    "deviceId": "contoso://device-id-1554",
    "type": "CO2",
    "createdAt": "2019-05-16T17:16:40.000003Z"
}

Poznámka

Konfigurace se mohou měnit v důsledku různých komponent používaných v řešení.The configurations are subject to change due to the various components used in the solution. Pokud chcete přesnější odhad, přizpůsobte si ukázky podle svého scénáře.For a more accurate estimate, customize the samples to fit your scenario.

Identifikace kritických bodůIdentifying Bottlenecks

Pomocí podokna metrik v Azure Stream Analytics úlohy můžete identifikovat kritická místa ve vašem kanálu.Use the Metrics pane in your Azure Stream Analytics job to identify bottlenecks in your pipeline. Zkontrolujte vstupní/výstupní události pro propustnost a "zpoždění vodoznaku" nebo nevyřízené události , abyste viděli, jestli úloha nepracuje se vstupní sazbou.Review Input/Output Events for throughput and "Watermark Delay" or Backlogged Events to see if the job is keeping up with the input rate. V případě metrik centra událostí vyhledejte omezené požadavky a odpovídajícím způsobem upravte prahové jednotky.For Event Hub metrics, look for Throttled Requests and adjust the Threshold Units accordingly. V případě Cosmos DB metriky si přečtěte maximální počet spotřebovaných ru/s na rozsah klíče oddílu propustnost, abyste zajistili, že rozsahy klíčů oddílu budou jednotně spotřebovány.For Cosmos DB metrics, review Max consumed RU/s per partition key range under Throughput to ensure your partition key ranges are uniformly consumed. V případě služby Azure SQL DB Sledujte protokol IO a CPU.For Azure SQL DB, monitor Log IO and CPU.

Získání pomociGet help

Pokud chcete získat další pomoc, vyzkoušejte si naši stránku Microsoft Q&Azure Stream Analytics.For further assistance, try our Microsoft Q&A question page for Azure Stream Analytics.

Další krokyNext steps