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

Azure Cosmos DB

Azure Event Hubs

Azure Monitor

Azure Stream Analytics

Tato referenční architektura ukazuje kompletní kanál zpracování datových proudů. Kanál ingestuje data ze dvou zdrojů, koreluje záznamy ve dvou datových proudech a vypočítá průběžný průměr v časovém intervalu. Výsledky se ukládají pro další analýzu.

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Tato architektura se skládá z následujících součástí:

Zdroje dat. V této architektuře existují dva zdroje dat, které generují datové proudy v reálném čase. První proud obsahuje informace o jízdě a druhý obsahuje informace o jízdném. Referenční architektura zahrnuje simulovaný generátor dat, který čte ze sady statických souborů a odesílá data do služby Event Hubs. Ve skutečné aplikaci by zdroje dat byly zařízení nainstalovaná v taxislužbách.

Azure Event Hubs. Event Hubs je služba pro příjem událostí. Tato architektura používá dvě instance centra událostí, jednu pro každý zdroj dat. Každý zdroj dat odešle datový proud do přidruženého centra událostí.

Azure Stream Analytics. Stream Analytics je modul pro zpracování událostí. Úloha Stream Analytics čte datové proudy ze dvou center událostí a provádí zpracování datových proudů.

azure Cosmos DB. Výstup úlohy Stream Analytics je řada záznamů, které se zapisují jako dokumenty JSON do databáze dokumentů Azure Cosmos DB.

Microsoft Power BI. Power BI je sada nástrojů pro obchodní analýzy, které analyzují data pro obchodní přehledy. V této architektuře načte data ze služby Azure Cosmos DB. To umožňuje uživatelům analyzovat celou sadu shromážděných historických dat. Výsledky můžete také streamovat přímo ze Stream Analytics do Power BI pro zobrazení dat v reálném čase. Další informace najdete v článku o streamování v reálném čase v Power BI.

Azure Monitor Azure Monitor shromažďuje metriky výkonu o službách Azure nasazených v řešení. Vizualizací těchto prvků na řídicím panelu získáte přehled o stavu řešení.

Podrobnosti scénáře

Scénář: Taxislužba shromažďuje data o každé jízdě taxíkem. V tomto scénáři předpokládáme, že existují dvě samostatná zařízení, která odesílají data. Taxi má měřič, který odesílá informace o každé jízdě – dobu trvání, vzdálenost a vyzvednutí a odkládací místa. Samostatné zařízení přijímá platby od zákazníků a odesílá data o jízdné. Taxislužba chce v reálném čase vypočítat průměrný tip na ujetou míli, aby bylo možné identifikovat trendy.

Potenciální případy použití

Toto řešení je optimalizované pro scénář maloobchodního prodeje.

Příjem dat

K simulaci zdroje dat tato referenční architektura používá ^{datovou sadu dat taxislužby New Yorku[1].}. Tato datová sada obsahuje data o jízdách taxíkem v New Yorku za čtyři roky (2010–2013). Obsahuje dva typy záznamů: údaje o jízdě a údaje o ceně. Data o jízdě zahrnují dobu jízdy, vzdálenost jízdy a místa vyzvednutí a vysazení. Údaje o jízdné zahrnují ceny jízdné, daně a tipové částky. Mezi běžná pole v obou typech záznamů patří číslo medailiónu, licence hacku a ID dodavatele. Společně tato tři pole jednoznačně identifikují taxi a řidiče. Data se ukládají ve formátu CSV.

[1] Donovan, Brian; Work, Dan (2016): Údaje o cestách taxíkem v New Yorku (2010-2013). Univerzita Illinois v Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

Generátor dat je .NET aplikace, která čte záznamy a odesílá je do Azure Event Hubs. Generátor odesílá data jízdy ve formátu JSON a data jízdného ve formátu CSV.

Služba Event Hubs používá k segmentování dat oddíly . Oddíly umožňují příjemci číst každý oddíl paralelně. Když odesíláte data do služby Event Hubs, můžete klíč oddílu explicitně zadat. V opačném případě se záznamy přiřazují k oddílům kolovým způsobem.

V tomto konkrétním scénáři by data o jízdě a jízdném měla skončit se stejným ID oddílu pro dané taxi. Stream Analytics tak může při korelaci těchto dvou datových proudů použít určitý stupeň paralelismu. Záznam v oddílu n dat o jízdě bude odpovídat záznamu v oddílu n dat jízdy.

V generátoru dat má společný datový model pro oba typy PartitionKey záznamů vlastnost, která je zřetězením Medallion, HackLicensea 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 se používá k poskytnutí explicitního klíče oddílu při odesílání do služby Event Hubs:

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

Zpracování datových proudů

Úloha zpracování datových proudů se definuje pomocí dotazu SQL s několika různými kroky. První dva kroky vyberou záznamy ze dvou vstupních datových proudů.

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í streamy a vybere z každého datového proudu odpovídající záznamy.

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 spojí záznamy v sadě polí, která jednoznačně identifikují odpovídající záznamy (PartitionId a PickupTime).

Poznámka:

Chceme, aby byly datové proudy TaxiRide a TaxiFare spojeny jedinečnou kombinací Medallion, HackLicense, VendorId a PickupTime. V tomto případě PartitionId zahrnuje pole Medallion, HackLicense a VendorId, ale nemělo by to být považováno za pravidlo.

V Stream Analytics jsou spojení dočasná, což znamená, že záznamy jsou spojené v určitém časovém intervalu. V opačném případě může úloha na neomezenou dobu čekat na odpovídající akci. Funkce DATEDIFF určuje, jak dlouho mohou být dva odpovídající záznamy v čase odděleny, aby se považovaly za shodu.

Poslední krok v úloze vypočítá průměrné spropitné za míli v rámci pěti minutového skákajícího okna.

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 okenních funkcí. Posuvné okno se posouvá v čase o pevné období, v tomto případě o jednu minutu na skok. Výsledkem je výpočet klouzavého průměru za posledních pět minut.

V této architektuře se do Azure Cosmos DB ukládají jenom výsledky úlohy Stream Analytics. V případě scénáře s velkými objemy dat zvažte použití funkce Event Hubs Capture k uložení nezpracovaných dat událostí do úložiště objektů blob v Azure. Udržování nezpracovaných dat vám umožní spouštět dávkové dotazy nad historickými daty později, aby bylo možné z dat odvodit nové přehledy.

Úvahy

Tyto úvahy implementují pilíře Azure Well-Architected Framework, což je sada zásad, které lze použít ke zlepšení kvality zátěže (workload). Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Optimalizace nákladů

Optimalizace nákladů spočívá ve hledání způsobů, jak snížit zbytečné výdaje a zlepšit provozní efektivitu. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu proOptimalizace nákladů .

K odhadu nákladů použijte cenovou kalkulačku Azure. Tady je několik důležitých informací o službách používaných v této referenční architektuře.

Azure Stream Analytics

Služba Azure Stream Analytics je cenná počtem jednotek streamování (0,11 USD/hodina) potřebných ke zpracování dat do služby.

Stream Analytics může být nákladný, pokud data nezpracováváte v reálném čase nebo v malých objemech dat. V těchto případech použití zvažte použití Azure Functions nebo Logic Apps k přesunu dat z Azure Event Hubs do úložiště dat.

Azure Event Hubs a Azure Cosmos DB

Důležité informace o nákladech služby Azure Event Hubs a Azure Cosmos DB najdete v referenční architektuře azure Databricks ke zpracování datových proudů .

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace naleznete v tématu kontrolní seznam pro kontrolu efektivity provozu.

Sledování

U jakéhokoli řešení zpracování datových proudů je důležité monitorovat výkon a stav systému. Azure Monitor shromažďuje metriky a diagnostické protokoly pro služby Azure používané v architektuře. Azure Monitor je integrovaný do platformy Azure a nevyžaduje žádný další kód ve vaší aplikaci.

Kterýkoli z následujících upozornění signalizuje, že byste měli škálovat příslušný prostředek Azure:

• Služba Event Hubs omezuje požadavky nebo se blíží denní kvótě zpráv.
• Úloha Stream Analytics konzistentně využívá více než 80 % přidělených jednotek streamování (SU).
• Azure Cosmos DB začne požadavky omezovat.

Referenční architektura zahrnuje vlastní řídicí panel, který se nasadí na web Azure Portal. Po nasazení architektury můžete řídicí panel zobrazit otevřením webu Azure Portal a výběrem TaxiRidesDashboard ze seznamu řídicích panelů. Další informace o vytváření a nasazování vlastních řídicích panelů na webu Azure Portal najdete v tématu Programové vytváření řídicích panelů Azure.

Následující obrázek ukazuje řídicí panel po spuštění úlohy Stream Analytics přibližně hodinu.

Na panelu vlevo dole vidíte, že spotřeba SU pro úlohu Stream Analytics během prvních 15 minut stoupá a pak se vyrovná. Jedná se o typický vzor, protože úloha dosáhne stabilního stavu.

Všimněte si, že služba Event Hubs omezuje požadavky, což je zobrazeno v pravém horním rohu. Občasný omezovaný požadavek není problém, protože klient SDK služby Event Hubs při přijetí chyby omezování automaticky obnoví. Pokud se ale zobrazí konzistentní chyby omezování, znamená to, že centrum událostí potřebuje více jednotek propustnosti. Následující graf ukazuje testovací běh pomocí funkce automatického nafouknutí služby Event Hubs, která podle potřeby automaticky škáluje jednotky propustnosti.

Automatické nafouknutí bylo povoleno přibližně u značky 06:35. Když služba Event Hubs automaticky škálovala na 3 jednotky propustnosti, můžete vidět pokles parametru p v omezených požadavcích.

Zajímavé je, že to mělo vedlejší účinek zvýšení využití SU v úloze Stream Analytics. Díky omezování se služba Event Hubs uměle snížila rychlost příjmu pro úlohu Stream Analytics. Ve skutečnosti je běžné, že řešení jednoho kritického bodu výkonu odhalí další. V tomto případě se problém vyřešil přidělením dalších SU pro úlohu Stream Analytics.

DevOps

• Vytvořte samostatné skupiny prostředků pro produkční, vývojové a testovací prostředí. 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.

• Pomocí šablony Azure Resource Manager nasadit prostředky Azure podle procesu Infrastruktura jako Kód (IaC). Díky šablonám je snazší automatizovat nasazení pomocí Azure DevOps Services nebo jiných řešení CI/CD.

• Každou úlohu umístěte do samostatné šablony nasazení a uložte prostředky do systémů správy zdrojového kódu. Šablony můžete nasadit společně nebo jednotlivě jako součást procesu CI/CD, což usnadňuje proces automatizace.

  V této architektuře jsou služby Azure Event Hubs, Log Analytics a Azure Cosmos DB označené jako jedna úloha. Tyto prostředky jsou součástí jedné šablony ARM.

• Zvažte etapizaci úloh. Nasaďte je do různých fází a před pokračováním v další fázi spusťte kontroly ověřování v každé fázi. Díky tomu můžete odesílat aktualizace do produkčních prostředí vysoce kontrolovaným způsobem a minimalizovat neočekávané problémy s nasazením.

• Zvažte použití služby Azure Monitor k analýze výkonu kanálu zpracování datových proudů.

Další informace najdete v pilíři efektivity provozu v architektuře Microsoft Azure Well-Architected Framework.

Efektivita výkonu

Efektivita výkonu je schopnost vaší úlohy škálovat tak, aby splňovala požadavky, které na ni mají uživatelé efektivním způsobem. Další informace naleznete v tématu Kontrola návrhu kontrolní seznam pro zvýšení efektivity výkonu.

Centra událostí

Kapacita propustnosti služby Event Hubs se měří v jednotkách propustnosti. Centrum událostí můžete automaticky škálovat tak, že povolíte automatické nafouknutí, které automaticky škáluje jednotky propustnosti na základě provozu až na nakonfigurované maximum.

Stream Analytics

U Stream Analytics se výpočetní prostředky přidělené úloze měří ve streamovacích jednotkách. Úlohy Stream Analytics se dají škálovat nejlépe, pokud je možné úlohu paralelizovat. Stream Analytics tak může distribuovat úlohu napříč několika výpočetními uzly.

Pro vstup služby Event Hubs použijte klíčové slovo PARTITION BY k rozdělení úlohy Stream Analytics. Data se rozdělí na podmnožiny podle oddílů systému Event Hubs.

Funkce oken a dočasné spojení vyžadují další SU. Pokud je to možné, použijte PARTITION BY, aby se každý oddíl zpracovával samostatně. Další informace najdete v tématu Pochopit a upravit jednotky streamování.

Pokud není možné paralelizovat celou úlohu Stream Analytics, zkuste ji rozdělit do několika kroků, a to od jednoho nebo několika paralelních kroků. Tímto způsobem se první kroky můžou spustit paralelně. Například v této referenční architektuře:

• Kroky 1 a 2 jsou SELECT příkazy, které vyberou záznamy v rámci jednoho oddílu.
• Krok 3 provede dělené spojení mezi dvěma vstupními datovými proudy. Tento krok využívá skutečnost, že odpovídající záznamy sdílejí stejný klíč oddílu, a proto je zaručeno, že v každém vstupním streamu bude mít stejné ID oddílu.
• Krok 4 agreguje napříč všemi oddíly. Tento krok nelze paralelizovat.

Pomocí diagramu úlohy Stream Analytics zjistíte, kolik oddílů je přiřazeno k jednotlivým krokům úlohy. Následující diagram znázorňuje diagram úloh pro tuto referenční architekturu:

Azure Cosmos DB

Kapacita propustnosti služby Azure Cosmos DB se měří v jednotkách žádostí (RU). Každý kontejner Azure Cosmos DB vyžaduje klíč partition a každý dokument musí obsahovat tento klíč. Jeden fyzický oddíl dokáže obsloužit až 10 000 RU/s, takže Azure Cosmos DB distribuuje data napříč několika fyzickými oddíly podle klíče oddílu, aby bylo možné škálovat nad tento limit. Zvolte klíč oddílu, který rovnoměrně rozloží data i objem požadavků, abyste předešli přetíženým oddílům.

V této referenční architektuře se nové dokumenty vytvářejí jenom jednou za minutu (interval přeskakující okno), takže požadavky na propustnost jsou nízké. I tak zvolte klíč oddílu, který bude vyhovovat očekávaným způsobům dotazování i budoucímu růstu.

Související prostředky

• zpracování streamu s využitím služby Azure Databricks

Tato referenční architektura ukazuje kompletní kanál zpracování datových proudů. Kanál ingestuje data ze dvou zdrojů, koreluje záznamy ve dvou datových proudech a vypočítá průběžný průměr v časovém intervalu. Výsledky se ukládají pro další analýzu.

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Tato architektura se skládá z následujících součástí:

Zdroje dat. V této architektuře existují dva zdroje dat, které generují datové proudy v reálném čase. První proud obsahuje informace o jízdě a druhý obsahuje informace o jízdném. Referenční architektura zahrnuje simulovaný generátor dat, který čte ze sady statických souborů a odesílá data do služby Event Hubs. Ve skutečné aplikaci by zdroje dat byly zařízení nainstalovaná v taxislužbách.

Azure Event Hubs. Event Hubs je služba pro příjem událostí. Tato architektura používá dvě instance centra událostí, jednu pro každý zdroj dat. Každý zdroj dat odešle datový proud do přidruženého centra událostí.

Azure Stream Analytics. Stream Analytics je modul pro zpracování událostí. Úloha Stream Analytics čte datové proudy ze dvou center událostí a provádí zpracování datových proudů.

azure Cosmos DB. Výstup úlohy Stream Analytics je řada záznamů, které se zapisují jako dokumenty JSON do databáze dokumentů Azure Cosmos DB.

Microsoft Power BI. Power BI je sada nástrojů pro obchodní analýzy, které analyzují data pro obchodní přehledy. V této architektuře načte data ze služby Azure Cosmos DB. To umožňuje uživatelům analyzovat celou sadu shromážděných historických dat. Výsledky můžete také streamovat přímo ze Stream Analytics do Power BI pro zobrazení dat v reálném čase. Další informace najdete v článku o streamování v reálném čase v Power BI.

Azure Monitor Azure Monitor shromažďuje metriky výkonu o službách Azure nasazených v řešení. Vizualizací těchto prvků na řídicím panelu získáte přehled o stavu řešení.

Podrobnosti scénáře

Scénář: Taxislužba shromažďuje data o každé jízdě taxíkem. V tomto scénáři předpokládáme, že existují dvě samostatná zařízení, která odesílají data. Taxi má měřič, který odesílá informace o každé jízdě – dobu trvání, vzdálenost a vyzvednutí a odkládací místa. Samostatné zařízení přijímá platby od zákazníků a odesílá data o jízdné. Taxislužba chce v reálném čase vypočítat průměrný tip na ujetou míli, aby bylo možné identifikovat trendy.

Potenciální případy použití

Toto řešení je optimalizované pro scénář maloobchodního prodeje.

Příjem dat

K simulaci zdroje dat tato referenční architektura používá ^{datovou sadu dat taxislužby New Yorku[1].}. Tato datová sada obsahuje data o jízdách taxíkem v New Yorku za čtyři roky (2010–2013). Obsahuje dva typy záznamů: údaje o jízdě a údaje o ceně. Data o jízdě zahrnují dobu jízdy, vzdálenost jízdy a místa vyzvednutí a vysazení. Údaje o jízdné zahrnují ceny jízdné, daně a tipové částky. Mezi běžná pole v obou typech záznamů patří číslo medailiónu, licence hacku a ID dodavatele. Společně tato tři pole jednoznačně identifikují taxi a řidiče. Data se ukládají ve formátu CSV.

[1] Donovan, Brian; Work, Dan (2016): Údaje o cestách taxíkem v New Yorku (2010-2013). Univerzita Illinois v Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

Generátor dat je .NET aplikace, která čte záznamy a odesílá je do Azure Event Hubs. Generátor odesílá data jízdy ve formátu JSON a data jízdného ve formátu CSV.

Služba Event Hubs používá k segmentování dat oddíly . Oddíly umožňují příjemci číst každý oddíl paralelně. Když odesíláte data do služby Event Hubs, můžete klíč oddílu explicitně zadat. V opačném případě se záznamy přiřazují k oddílům kolovým způsobem.

V tomto konkrétním scénáři by data o jízdě a jízdném měla skončit se stejným ID oddílu pro dané taxi. Stream Analytics tak může při korelaci těchto dvou datových proudů použít určitý stupeň paralelismu. Záznam v oddílu n dat o jízdě bude odpovídat záznamu v oddílu n dat jízdy.

V generátoru dat má společný datový model pro oba typy PartitionKey záznamů vlastnost, která je zřetězením Medallion, HackLicensea 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 se používá k poskytnutí explicitního klíče oddílu při odesílání do služby Event Hubs:

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

Zpracování datových proudů

Úloha zpracování datových proudů se definuje pomocí dotazu SQL s několika různými kroky. První dva kroky vyberou záznamy ze dvou vstupních datových proudů.

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í streamy a vybere z každého datového proudu odpovídající záznamy.

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 spojí záznamy v sadě polí, která jednoznačně identifikují odpovídající záznamy (PartitionId a PickupTime).

Poznámka:

Chceme, aby byly datové proudy TaxiRide a TaxiFare spojeny jedinečnou kombinací Medallion, HackLicense, VendorId a PickupTime. V tomto případě PartitionId zahrnuje pole Medallion, HackLicense a VendorId, ale nemělo by to být považováno za pravidlo.

V Stream Analytics jsou spojení dočasná, což znamená, že záznamy jsou spojené v určitém časovém intervalu. V opačném případě může úloha na neomezenou dobu čekat na odpovídající akci. Funkce DATEDIFF určuje, jak dlouho mohou být dva odpovídající záznamy v čase odděleny, aby se považovaly za shodu.

Poslední krok v úloze vypočítá průměrné spropitné za míli v rámci pěti minutového skákajícího okna.

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 okenních funkcí. Posuvné okno se posouvá v čase o pevné období, v tomto případě o jednu minutu na skok. Výsledkem je výpočet klouzavého průměru za posledních pět minut.

V této architektuře se do Azure Cosmos DB ukládají jenom výsledky úlohy Stream Analytics. V případě scénáře s velkými objemy dat zvažte použití funkce Event Hubs Capture k uložení nezpracovaných dat událostí do úložiště objektů blob v Azure. Udržování nezpracovaných dat vám umožní spouštět dávkové dotazy nad historickými daty později, aby bylo možné z dat odvodit nové přehledy.

Úvahy

Tyto úvahy implementují pilíře Azure Well-Architected Framework, což je sada zásad, které lze použít ke zlepšení kvality zátěže (workload). Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Optimalizace nákladů

Optimalizace nákladů spočívá ve hledání způsobů, jak snížit zbytečné výdaje a zlepšit provozní efektivitu. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu proOptimalizace nákladů .

K odhadu nákladů použijte cenovou kalkulačku Azure. Tady je několik důležitých informací o službách používaných v této referenční architektuře.

Azure Stream Analytics

Služba Azure Stream Analytics je cenná počtem jednotek streamování (0,11 USD/hodina) potřebných ke zpracování dat do služby.

Stream Analytics může být nákladný, pokud data nezpracováváte v reálném čase nebo v malých objemech dat. V těchto případech použití zvažte použití Azure Functions nebo Logic Apps k přesunu dat z Azure Event Hubs do úložiště dat.

Azure Event Hubs a Azure Cosmos DB

Důležité informace o nákladech služby Azure Event Hubs a Azure Cosmos DB najdete v referenční architektuře azure Databricks ke zpracování datových proudů .

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace naleznete v tématu kontrolní seznam pro kontrolu efektivity provozu.

Sledování

U jakéhokoli řešení zpracování datových proudů je důležité monitorovat výkon a stav systému. Azure Monitor shromažďuje metriky a diagnostické protokoly pro služby Azure používané v architektuře. Azure Monitor je integrovaný do platformy Azure a nevyžaduje žádný další kód ve vaší aplikaci.

Kterýkoli z následujících upozornění signalizuje, že byste měli škálovat příslušný prostředek Azure:

• Služba Event Hubs omezuje požadavky nebo se blíží denní kvótě zpráv.
• Úloha Stream Analytics konzistentně využívá více než 80 % přidělených jednotek streamování (SU).
• Azure Cosmos DB začne požadavky omezovat.

Referenční architektura zahrnuje vlastní řídicí panel, který se nasadí na web Azure Portal. Po nasazení architektury můžete řídicí panel zobrazit otevřením webu Azure Portal a výběrem TaxiRidesDashboard ze seznamu řídicích panelů. Další informace o vytváření a nasazování vlastních řídicích panelů na webu Azure Portal najdete v tématu Programové vytváření řídicích panelů Azure.

Následující obrázek ukazuje řídicí panel po spuštění úlohy Stream Analytics přibližně hodinu.

Na panelu vlevo dole vidíte, že spotřeba SU pro úlohu Stream Analytics během prvních 15 minut stoupá a pak se vyrovná. Jedná se o typický vzor, protože úloha dosáhne stabilního stavu.

Všimněte si, že služba Event Hubs omezuje požadavky, což je zobrazeno v pravém horním rohu. Občasný omezovaný požadavek není problém, protože klient SDK služby Event Hubs při přijetí chyby omezování automaticky obnoví. Pokud se ale zobrazí konzistentní chyby omezování, znamená to, že centrum událostí potřebuje více jednotek propustnosti. Následující graf ukazuje testovací běh pomocí funkce automatického nafouknutí služby Event Hubs, která podle potřeby automaticky škáluje jednotky propustnosti.

Automatické nafouknutí bylo povoleno přibližně u značky 06:35. Když služba Event Hubs automaticky škálovala na 3 jednotky propustnosti, můžete vidět pokles parametru p v omezených požadavcích.

Zajímavé je, že to mělo vedlejší účinek zvýšení využití SU v úloze Stream Analytics. Díky omezování se služba Event Hubs uměle snížila rychlost příjmu pro úlohu Stream Analytics. Ve skutečnosti je běžné, že řešení jednoho kritického bodu výkonu odhalí další. V tomto případě se problém vyřešil přidělením dalších SU pro úlohu Stream Analytics.

DevOps

• Vytvořte samostatné skupiny prostředků pro produkční, vývojové a testovací prostředí. 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.

• Pomocí šablony Azure Resource Manager nasadit prostředky Azure podle procesu Infrastruktura jako Kód (IaC). Díky šablonám je snazší automatizovat nasazení pomocí Azure DevOps Services nebo jiných řešení CI/CD.

• Každou úlohu umístěte do samostatné šablony nasazení a uložte prostředky do systémů správy zdrojového kódu. Šablony můžete nasadit společně nebo jednotlivě jako součást procesu CI/CD, což usnadňuje proces automatizace.

  V této architektuře jsou služby Azure Event Hubs, Log Analytics a Azure Cosmos DB označené jako jedna úloha. Tyto prostředky jsou součástí jedné šablony ARM.

• Zvažte etapizaci úloh. Nasaďte je do různých fází a před pokračováním v další fázi spusťte kontroly ověřování v každé fázi. Díky tomu můžete odesílat aktualizace do produkčních prostředí vysoce kontrolovaným způsobem a minimalizovat neočekávané problémy s nasazením.

• Zvažte použití služby Azure Monitor k analýze výkonu kanálu zpracování datových proudů.

Další informace najdete v pilíři efektivity provozu v architektuře Microsoft Azure Well-Architected Framework.

Efektivita výkonu

Efektivita výkonu je schopnost vaší úlohy škálovat tak, aby splňovala požadavky, které na ni mají uživatelé efektivním způsobem. Další informace naleznete v tématu Kontrola návrhu kontrolní seznam pro zvýšení efektivity výkonu.

Centra událostí

Kapacita propustnosti služby Event Hubs se měří v jednotkách propustnosti. Centrum událostí můžete automaticky škálovat tak, že povolíte automatické nafouknutí, které automaticky škáluje jednotky propustnosti na základě provozu až na nakonfigurované maximum.

Stream Analytics

U Stream Analytics se výpočetní prostředky přidělené úloze měří ve streamovacích jednotkách. Úlohy Stream Analytics se dají škálovat nejlépe, pokud je možné úlohu paralelizovat. Stream Analytics tak může distribuovat úlohu napříč několika výpočetními uzly.

Pro vstup služby Event Hubs použijte klíčové slovo PARTITION BY k rozdělení úlohy Stream Analytics. Data se rozdělí na podmnožiny podle oddílů systému Event Hubs.

Funkce oken a dočasné spojení vyžadují další SU. Pokud je to možné, použijte PARTITION BY, aby se každý oddíl zpracovával samostatně. Další informace najdete v tématu Pochopit a upravit jednotky streamování.

Pokud není možné paralelizovat celou úlohu Stream Analytics, zkuste ji rozdělit do několika kroků, a to od jednoho nebo několika paralelních kroků. Tímto způsobem se první kroky můžou spustit paralelně. Například v této referenční architektuře:

• Kroky 1 a 2 jsou SELECT příkazy, které vyberou záznamy v rámci jednoho oddílu.
• Krok 3 provede dělené spojení mezi dvěma vstupními datovými proudy. Tento krok využívá skutečnost, že odpovídající záznamy sdílejí stejný klíč oddílu, a proto je zaručeno, že v každém vstupním streamu bude mít stejné ID oddílu.
• Krok 4 agreguje napříč všemi oddíly. Tento krok nelze paralelizovat.

Pomocí diagramu úlohy Stream Analytics zjistíte, kolik oddílů je přiřazeno k jednotlivým krokům úlohy. Následující diagram znázorňuje diagram úloh pro tuto referenční architekturu:

Azure Cosmos DB

Kapacita propustnosti služby Azure Cosmos DB se měří v jednotkách žádostí (RU). Každý kontejner Azure Cosmos DB vyžaduje klíč partition a každý dokument musí obsahovat tento klíč. Jeden fyzický oddíl dokáže obsloužit až 10 000 RU/s, takže Azure Cosmos DB distribuuje data napříč několika fyzickými oddíly podle klíče oddílu, aby bylo možné škálovat nad tento limit. Zvolte klíč oddílu, který rovnoměrně rozloží data i objem požadavků, abyste předešli přetíženým oddílům.

V této referenční architektuře se nové dokumenty vytvářejí jenom jednou za minutu (interval přeskakující okno), takže požadavky na propustnost jsou nízké. I tak zvolte klíč oddílu, který bude vyhovovat očekávaným způsobům dotazování i budoucímu růstu.

Související prostředky

• zpracování streamu s využitím služby Azure Databricks