Redigera

Dela via


Databehandling i nära realtid i Lakehouse

Azure AI Search
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs
Azure Synapse Analytics

Datadrivna företag måste hålla sina serverdels- och analyssystem i nästan realtidssynkronisering med kundinriktade program. Effekten av transaktioner, uppdateringar och ändringar måste återspeglas korrekt genom processer från slutpunkt till slutpunkt, relaterade program och OLTP-system (onlinetransaktionsbearbetning). Den tolerabla svarstiden för ändringar i OLTP-program som ska återspeglas i de nedströmssystem som använder data kan vara bara några minuter.

Den här artikeln beskriver en lösning från slutpunkt till slutpunkt för databearbetning i nära realtid för att hålla Lakehouse-data synkroniserade. Lösningen använder Azure Event Hubs, Azure Synapse Analytics och Azure Data Lake Storage för databearbetning och analys.

Apache® och Apache Spark är antingen registrerade varumärken eller varumärken som tillhör Apache Software Foundation i USA och/eller andra länder. Inget godkännande från Apache Software Foundation underförstås av användningen av dessa märken.

Arkitektur

Ett diagram som visar dataflödet för databehandlingslösningen från slutpunkt till slutpunkt.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

  1. Ändringsdatainsamling är en förutsättning för att källsystem ska kunna lyssna på ändringar. Debezium-anslutningsappar kan ansluta till olika källsystem och utnyttja ändringar när de sker. Anslutningsapparna kan samla in ändringar och skapa händelser från olika hanteringssystem för relationsdatabaser (RDBMS). För att installera en Debezium-anslutningsapp krävs ett Kafka-anslutningssystem.

  2. Anslutningsapparna extraherar ändringsdata och skickar de insamlade händelserna till Azure Event Hubs. Event Hubs kan ta emot stora mängder data från flera källor.

  3. Event Hubs strömmar direkt data till Azure Synapse Analytics Spark-pooler eller kan skicka data till en Azure Data Lake Storage-landningszon i rådataformat.

  4. Andra batchdatakällor kan använda Azure Synapse-pipelines för att kopiera data till Data Lake Storage och göra dem tillgängliga för bearbetning. Ett ETL-arbetsflöde (extrahera, transformera och läsa in) från slutpunkt till slutpunkt kan behöva länka olika steg eller lägga till beroenden mellan stegen. Azure Synapse-pipelines kan samordna arbetsflödesberoenden inom det övergripande bearbetningsramverket.

  5. Azure Synapse Spark-pooler använder apache Spark-strukturerade API:er för direktuppspelning som stöds fullt ut för att bearbeta data i Spark-strömningsramverket. Databearbetningssteget innehåller datakvalitetskontroller och valideringar av affärsregler på hög nivå.

  6. Data Lake Storage lagrar verifierade data i det öppna Delta Lake-formatet . Delta Lake ger atomitet, konsekvens, isolering och hållbarhet (ACID) semantik och transaktioner, skalbar metadatahantering samt enhetlig strömning och batchdatabearbetning för befintliga datasjöar.

    Om du använder index för frågeacceleration utökas Delta med ytterligare prestandaförbättringar. Data från den verifierade zonen Data Lake Storage kan också vara en källa för ytterligare avancerad analys och maskininlärning.

  7. Data från den verifierade zonen Data Lake Storage, omvandlade och berikade med fler regler till sitt slutliga bearbetade tillstånd, läses in till en dedikerad SQL-pool för att köra storskaliga analysfrågor.

  8. Power BI använder data som exponeras via den dedikerade SQL-poolen för att skapa instrumentpaneler och rapporter i företagsklass.

  9. Du kan också använda insamlade rådata i Data Lake Store-landningszonen och verifierade data i Delta-format för:

    • Ytterligare ad hoc- och undersökande analys via serverlösa Azure Synapse SQL-pooler.
    • Maskininlärning via Azure Mašinsko učenje.
  10. För vissa gränssnitt med låg svarstid måste data avnormaliseras för ensiffriga serverfördröjningar. Det här användningsscenariot gäller främst API-svar. Det här scenariot frågar dokument i ett NoSQL-datalager, till exempel Azure Cosmos DB, för svar på ensiffriga millisekunder.

  11. Azure Cosmos DB-partitioneringsstrategin kanske inte lämpar sig för alla frågemönster. I så fall kan du utöka lösningen genom att indexera de data som API:erna behöver komma åt med Azure Cognitive Search. Azure Cosmos DB och Cognitive Search kan uppfylla de flesta scenarier som kräver svar på frågor med låg svarstid.

Komponenter

Den här lösningen använder följande Azure-komponenter:

  • Event Hubs är en hanterad, distribuerad inmatningstjänst som kan skalas för att mata in stora mängder data. Med mekanismen för Event Hubs-prenumerant-utgivare kan olika program skicka meddelanden till ämnen i Event Hubs, och nedströmsanvändare kan ansluta till och bearbeta meddelanden. Funktionen Event Hubs Capture kan skriva meddelanden till Data Lake Storage i AVRO-format när de anländer. Den här möjligheten möjliggör enkel bearbetning av mikrobatch och långsiktiga kvarhållningsscenarier. Event Hubs erbjuder också ett Kafka-kompatibelt API och stöder schemaregister.

  • Data Lake Storage utgör lagringsundersystemet som lagrar alla data i rådata och validerade format. Data Lake Storage kan hantera transaktioner i stor skala och har stöd för olika filformat och storlekar. Hierarkiska namnområden hjälper till att organisera data i en välbekant mappstruktur och har stöd för posix-behörigheter (Portable Operating System Interface for UniX). Drivrutinen för Azure Blob Filesystem (ABFS) erbjuder ett Hadoop-kompatibelt API.

  • Azure Synapse Analytics är en obegränsad analystjänst som sammanför dataintegrering, lagring av företagsdata och stordataanalys. Den här lösningen använder följande funktioner i Azure Synapse Analytics-ekosystemet:

    • Azure Synapse Spark-pooler erbjuder en Spark-körning på begäran som lägger till inbyggda prestandaförbättringar i Spark med öppen källkod. Kunder kan konfigurera flexibla autoskalningsinställningar, skicka jobb via fjärranslutning via Apache Livy-slutpunkten och använda Synapse Studio Notebook-gränssnittet för interaktiva upplevelser.

    • Azure Synapse SQL-serverlösa pooler tillhandahåller ett gränssnitt för att fråga lakehouse-data med hjälp av en välbekant T-SQL-syntax. Det finns ingen infrastruktur att konfigurera och Azure Synapse-arbetsytedistribution skapar automatiskt slutpunkten. Azure Synapse SQL-serverlösa pooler möjliggör grundläggande identifiering och utforskning av data på plats och är ett bra alternativ för användar ad hoc-frågeanalys.

    • Azure Synapse-dedikerade SQL-pooler lagrar data i relationstabeller med kolumnlagring. Dedikerade SQL-pooler använder en skalbar arkitektur för att distribuera databearbetning över flera noder. PolyBase-frågor för in data i SQL-pooltabeller. Tabellerna kan ansluta till Power BI för analys och rapportering.

  • Power BI tillhandahåller ett visuellt gränssnitt för att skapa och komma åt rapporter och instrumentpaneler. Power BI Desktop kan ansluta till olika datakällor, kombinera källorna till en datamodell och skapa rapporter eller instrumentpaneler. Med Power BI kan du transformera data baserat på affärskrav och dela visuella objekt och rapporter med andra via usluga Power BI.

  • Azure Cosmos DB är en hanterad, multimodal NoSQL-databas som stöder öppna API:er som MongoDB och Cassandra. Den här lösningen använder Azure Cosmos DB för program som kräver ensiffriga svarstider för millisekunder och hög tillgänglighet. Azure Cosmos DB erbjuder skrivningar i flera regioner i alla Azure-regioner. Du kan använda Azure Synapse Link för Azure Cosmos DB för att härleda insikter och köra analys över data i realtid.

  • Azure Cognitive Search är en molnsöktjänst som kan indexera de data som dina program och API:er behöver. Cognitive Search har valfria AI-berikningsfunktioner som hjälper till med textextrahering och härleder text från icke-textfiler. Cognitive Search integreras med tjänster som Azure Data Lake Storage och Azure Cosmos DB för enkel åtkomst och indexering av data. Du kan köra frågor mot indexerade data med hjälp av ett REST-API eller .NET SDK. Om du vill hämta data från två separata index kan du kombinera dem till ett enda index eller använda komplexa datatyper.

Information om scenario

Arbetsflödet från slutpunkt till slutpunkt för att bearbeta ändringar nästan i realtid kräver:

  • En CDC-teknik (Change Data Capture). OLTP-programmen kan ha olika serverdelsdatalager, till exempel SQL Server, MySQL och Oracle. Det första steget är att lyssna på ändringar när de sker och sprida dem framåt.
  • En inmatningsbuffert för att publicera ändringshändelserna i stor skala. Den här tjänsten bör ha möjlighet att hantera stora mängder data när meddelanden tas emot. Enskilda prenumeranter kan ansluta till det här systemet och bearbeta data.
  • Distribuerad och skalbar lagring för data som de är i ett rådataformat.
  • Ett distribuerat, effektivt dataströmbearbetningssystem som gör att användarna kan starta om och hantera tillstånd.
  • Ett analyssystem som körs i stor skala för att driva affärsbeslut.
  • Ett analysgränssnitt för självbetjäning.
  • För API-svar med låg svarstid ska en NoSQL-databas lagra avnormaliserad representation av data.
  • I vissa fall kan ett system för indexering av data uppdatera indexet med jämna mellanrum och göra de senaste data tillgängliga för nedströmsförbrukning.

Alla föregående tekniker bör använda relevanta säkerhetskonstruktioner för perimetersäkerhet, autentisering, auktorisering och datakryptering.

Potentiella användningsfall

Den här lösningen passar bra för:

  • Branscher som behöver sprida ändringar från OLTP till onlineanalysbearbetning (OLAP).
  • Program som kräver datatransformering eller berikning.

Scenariot för databearbetning i realtid är särskilt viktigt för finansbranschen. Om till exempel en försäkring, ett kreditkort eller en bankkund gör en betalning och sedan omedelbart kontaktar kundtjänst måste kundsupportagenten ha den senaste informationen.

Liknande scenarier gäller för detaljhandels-, handels- och hälsovårdssektorerna. Om du aktiverar dessa scenarier effektiviseras verksamheten, vilket leder till ökad produktivitet i organisationen och ökad kundnöjdhet.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

  • Event Hubs erbjuder 90 dagars datakvarhållning på premium- och dedikerade nivåer. För redundansscenarier kan du konfigurera ett sekundärt namnområde i den kopplade regionen och aktivera det under redundansväxlingen.

  • Azure Synapse Spark-pooljobb återvinns var sjunde dag när noder tas ned för underhåll. Tänk på den här aktiviteten när du arbetar med serviceavtal (SLA) som är knutna till systemet. Den här begränsningen är inte ett problem för många scenarier där mål för återställningstid (RTO) är cirka 15 minuter.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

  • Du kan välja från olika Event Hubs-nivåer baserat på arbetsbelastningsegenskaper. Event Hubs fakturerar Capture Storage separat, baserat på mängden data som lagras på Data Lake Storage.

  • Överväg hantering av objektlivscykel via nivåer i Azure Data Lake Storage. I takt med att data åldras kan du flytta data från en frekvent nivå, där du behöver komma åt senaste data för analys, till en kall lagringsnivå som är mycket lägre. Den kalla lagringsnivån är ett kostnadseffektivt alternativ för långsiktig kvarhållning.

  • Du kan pausa den dedikerade SQL-poolen när du inte använder den i utvecklings- eller testmiljöerna. Du kan schemalägga ett skript för att pausa poolen efter behov, eller så kan du pausa poolen manuellt via portalen.

  • Azure Cosmos DB erbjuder olika etableringsmodeller, till exempel serverlöst, manuellt etablerat dataflöde och autoskalning. Överväg att använda serverlös etablering för dina utvecklings- och testarbetsbelastningar. Du kan också använda autoskalning, där du kan ange maximalt antal enheter för begäranden per sekund (RU/s) i containern. Dataflödet i containern skalas automatiskt mellan 10 % av maximala RU/s som ett lägre tröskelvärde och det högsta konfigurerade RU/s.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

  • Du kan skala Event Hubs via partitionering. Överväg att partitionera dina data för att bevara händelseordningen via en incheckningslogg. Med partitionering kan du skapa flera parallella loggar genom att maximera den tillgängliga dataflödeskapaciteten.

  • Du kan konfigurera Azure Synapse Spark-pooler med SKU:er för små, medelstora eller stora virtuella datorer (VM), baserat på arbetsbelastningen. Du kan också konfigurera autoskalning i Azure Synapse Spark-pooler för att ta hänsyn till spikiga arbetsbelastningar. Om du behöver fler beräkningsresurser skalas klustren automatiskt upp för att möta efterfrågan och skalas ned när bearbetningen är klar.

  • Använd metodtips för att utforma tabeller i den dedikerade SQL-poolen. Associerade prestanda- och skalbarhetsgränser gäller, baserat på den nivå som SQL-poolen körs på.

  • Azure Cosmos DB använder partitioner för att skala containrar baserat på en partitionsnyckel. Alla data som baseras på en partitionsnyckel utgör en logisk partition. Se till att välja rätt partitioneringsstrategi baserat på arbetsbelastningskrav. Du kan också använda index för snabbare datahämtning.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Annan deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg