Zpracování streamů s využitím 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.

Referenční implementace pro tuto architekturu je k dispozici na GitHubu.

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ízdě. 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 vypočítat průměrný tip na míle řízený v reálném čase, aby bylo možné odhalit 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 jízdě. Data o jízdě zahrnují dobu jízdy, vzdálenost jízdy a vyzvednutí a umístění pro vyzvednutí. Ú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): New York City Taxi Trip Data (2010-2013). University of Illinois ve společnosti Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

Generátor dat je aplikace .NET Core, která čte záznamy a odesílá je do služby 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 způsobem kruhového dotazování.

V tomto konkrétním scénáři by data jízdy a jízdné měly skončit se stejným ID oddílu pro danou taxislužba. 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 jednoduše 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).

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 čekat na shodu na neomezenou dobu. Funkce DATEDIFF určuje, jak daleko mohou být dva odpovídající záznamy odděleny v čase pro shodu.

Poslední krok v úloze vypočítá průměrnou špičku na míli seskupenou o 5minutovým oknem.

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í pro práci s okny. Přeskakující okno se posune v čase o pevné období, v tomto případě 1 minutu na segment směrování. Výsledkem je výpočet klouzavého průměru za posledních 5 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.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Škálovatelnost

Event Hubs

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ěří v jednotkách streamování. Ú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 PARTITION BY klíčové slovo k rozdělení úlohy Stream Analytics. Data se rozdělí na podmnožinu na základě oddílů služby Event Hubs.

Funkce oken a dočasné spojení vyžadují další SU. Pokud je to možné, použijte PARTITION BY ho, aby se každý oddíl zpracovával samostatně. Další informace najdete v tématu Vysvětlení a úprava jednotek 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 jednoduché SELECT příkazy, které vybírají 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 všechny 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). Pokud chcete škálovat kontejner Azure Cosmos DB po 10 000 RU, musíte při vytváření kontejneru zadat klíč oddílu a zahrnout klíč oddílu do každého dokumentu.

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 poměrně nízké. Z tohoto důvodu není nutné v tomto scénáři přiřazovat klíč oddílu.

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 omezovat požadavky.

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 má požadavky na omezování, které se zobrazují v pravém horním panelu. Občasný omezený požadavek není problém, protože klientská sada SDK služby Event Hubs se při přijetí chyby omezování automaticky opakuje. 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 až 3 jednotky propustnosti, můžete vidět pokles 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.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace 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

Informace o nákladech na službu Azure Event Hubs a Azure Cosmos DB najdete v tématu Důležité informace o nákladech na zpracování datových proudů s referenční architekturou Azure Databricks .

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 Manageru nasaďte prostředky Azure po procesu infrastruktury jako kódu (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 přípravu úloh. Nasaďte je do různých fází a před přechodem na 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 tématu Monitorování Azure Databricks.

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

Nasazení tohoto scénáře

Pokud chcete nasadit a spustit referenční implementaci, postupujte podle kroků v souboru readme GitHubu.

Související prostředky

Můžete si projít následující ukázkový scénář Azure, který ukazuje konkrétní řešení s využitím některých stejných technologií:

• Zjišťování možných podvodů v reálném čase