Dela via

Arkitekturformat för stordata

En arkitektur för stordata är utformad för att hantera inmatning, bearbetning och analys av data som är för stora eller komplexa för traditionella databassystem.

Logiskt diagram över ett arkitekturformat för stordata.

Stordatalösningar innehåller vanligtvis en eller flera av följande typer av arbetsbelastningar:

  • Batchbearbetning av stordatakällor i viloläge
  • Realtidsbearbetning av stordata i rörelse
  • Interaktiv utforskning av stordata
  • Förutsägelseanalys och maskininlärning

De flesta stordataarkitekturer innehåller några eller alla följande komponenter:

  • Datakällor: Stordatalösningar kan börja med en eller flera datakällor.

    • Datalager, till exempel relationsdatabaser

    • Filer som program skapar, till exempel webbserverloggfiler och API-svar

    • Realtidsdatakällor, till exempel strömmande enheter, webhooks eller program uppströms relationsdatabasen

  • Datalagring: Data för batchbearbetningsåtgärder lagras vanligtvis i ett distribuerat fillager som kan innehålla stora mängder stora filer i olika format. Den här typen av lagring kallas ofta för en datasjö. Alternativen för att implementera den här lagringen är Azure Data Lake Storage eller Microsoft Fabric OneLake.

  • Satsvis bearbetning: När data behöver förberedas för analys och göras tillgängliga för rapporter som återspeglar tidigare händelser eller trender är batchbearbetning användbart. De här jobben handlar vanligtvis om att läsa källfiler, bearbeta dem och skriva utdata till nya filer. Alternativen omfattar användning av dataflöden eller datapipelines i Infrastrukturresurser.

  • Realtidsbearbetning: Om lösningen innehåller realtidskällor måste arkitekturen innehålla ett sätt att samla in och lagra realtidsmeddelanden för dataströmbearbetning. Data kan vara i rörelse från det ögonblick de genereras genom dess rensning, transformering och eventuell användning i operativa åtgärder eller analytiska åtgärder. Många lösningar behöver stöd för utskalningsbearbetning, tillförlitlig leverans och annan meddelandekösemantik. Alternativen är Fabric Real-Time Intelligence eventstreams, Azure Event Hubs, Azure IoT Hub och Apache Kafka.

  • Analysdatalager: Många stordatalösningar förbereder data för analys och hanterar sedan bearbetade data i ett strukturerat format som kan efterfrågas med hjälp av analysverktyg. Beroende på ditt scenario kan det analysdatalager som används för att hantera dessa frågor vara ett händelsehus i Microsoft Fabric för att bearbeta data i rörelse och dataströmmen bearbetas under flygning. Eller så kan det vara ett dimensionellt informationslager, enligt de flesta traditionella BI-lösningar (Business Intelligence) eller ett sjöhus (Brons, Silver och Guld). Microsoft Fabric har flera alternativ, till exempel eventhouses, lager och sjöhus. Varje alternativ kan efterfrågas med hjälp av SQL eller Spark, beroende på användningsfallet. Använd beslutsguiden för Infrastrukturdatalager för att vägleda ditt beslut.

  • Analys och rapportering: Ett av målen med datalösningar bör vara att ge insikter om data via analys och rapportering. För att ge användarna möjlighet att analysera data kan arkitekturen innehålla ett datamodelleringslager, till exempel en flerdimensionell OLAP-kub (Online Analytical Processing) eller tabelldatamodellen i Azure Analysis Services. Det kan också stödja självbetjänings-BI med hjälp av modellerings- och visualiseringsteknikerna i Power BI eller Excel. Analys och rapportering kan också ske i form av interaktiv datautforskning av dataforskare eller dataanalytiker. I dessa scenarier tillhandahåller Microsoft Fabric verktyg som notebook-filer, där användarna kan välja SQL eller ett programmeringsspråk som de väljer.

  • Åtgärder och aviseringar: Ett annat mål med en stordatalösning bör vara att ge operativa insikter om affärsprocessens aktuella tillstånd. Arkitekturen bör innehålla ett åtgärdssystemlager som tar dataströmmar i realtid när de bearbetas och identifierar undantag och avvikelser som inträffar inom organisationen. I stället för att en användare kontrollerar en rapport kan du använda dessa aviseringssystem för att proaktivt meddela användare och ledningen om avvikande aktiviteter. Real-Time Aviseringar om aktivering av intelligens ger den här typen av proaktiv övervakning.

  • Orkestrering: Stordatalösningar kan bestå av upprepade databearbetningsåtgärder inkapslade i arbetsflöden. Dessa arbetsflöden transformerar källdata, flyttar data mellan flera källor och mottagare, läser in bearbetade data i ett analysdatalager eller skickar resultatet direkt till en rapport eller instrumentpanel. Om du vill automatisera dessa arbetsflöden kan du använda en orkestreringsteknik som Azure Data Factory eller Microsoft Fabric-pipelines.

Microsoft tillhandahåller många tjänster för stordataarkitektur som är grupperade ungefär i följande kategorier:

  • SaaS-lösningar (Programvara som en tjänst), till exempel Microsoft Fabric

  • Hanterade tjänster som Data Lake Storage, Azure Stream Analytics, Event Hubs, IoT Hub, Azure Data Factory, Azure SQL Database och Azure Cosmos DB

När ska den här arkitekturen användas?

Tänk på den här arkitekturstilen när du behöver vidta följande åtgärder:

  • Agera på data i realtid när data genereras.
  • Lagra och bearbeta data i volymer som är för stora för en traditionell databas.
  • Transformera ostrukturerade data för analys och rapportering.
  • Använd Azure Machine Learning eller Azure AI-tjänster.

Fördelar

  • Teknikval: Microsoft Fabric tillhandahåller många av dessa tjänster via ett SaaS-gränssnitt och ansluter de olika komponenterna i förväg. Den här metoden förenklar processen med att skapa datalösningar från slutpunkt till slutpunkt. Du kan också blanda och matcha Hanterade Azure-tjänster för att dra nytta av befintliga kunskaper eller teknikinvesteringar.

  • Prestanda genom parallellitet: Stordatalösningar drar nytta av parallellitet, vilket möjliggör högpresterande lösningar som skalas till stora mängder data.

  • Elastisk skala: Alla komponenter i stordataarkitekturen stöder utskalningsetablering. Därför kan du justera din lösning för små eller stora arbetsbelastningar och endast betala för de resurser du använder.

  • Samverkan med befintliga lösningar: Komponenterna i stordataarkitekturen används också för IoT-bearbetning (Internet of Things) och företags-BI-lösningar. Med den här mångsidigheten kan du skapa en integrerad lösning för dataarbetsbelastningar.

Utmaningar

  • Kompetensuppsättning: Vissa stordatatekniker är mycket specialiserade och förlitar sig på ramverk och språk som skiljer sig från dem som används i allmänna programarkitekturer. Alternativt växer nyare API:er fram som bygger på mer etablerade språk.

  • Säkerhet: Stordatalösningar förlitar sig vanligtvis på att lagra alla statiska data i en centraliserad datasjö. Det kan vara svårt att skydda åtkomsten till dessa data, särskilt när flera program och plattformar måste mata in och använda data.

Metodtips

  • Använd parallellitet. De flesta stordatabearbetningstekniker distribuerar arbetsbelastningen över flera bearbetningsenheter. Den här distributionen kräver att statiska datafiler skapas och lagras i ett delat format. Distribuerade filsystem som Hadoop Distributed File System (HDFS) kan optimera läs- och skrivprestanda. Flera klusternoder utför parallellt den faktiska bearbetningen, vilket minskar de totala jobbtiderna. Vi rekommenderar att du använder ett delat dataformat, till exempel Parquet.

  • Partitionsdata. Batchbearbetning sker vanligtvis enligt ett återkommande schema, till exempel varje vecka eller månad. Partitionera datafiler och datastrukturer, till exempel tabeller, baserat på tidsperioder som överensstämmer med bearbetningsschemat. Den här strategin förenklar datainmatning och jobbschemaläggning, gör felsökningen enklare och kan avsevärt förbättra frågeprestandan.

  • Använd schema-on-read-semantik. Med hjälp av en datasjö kan du kombinera lagring för filer i flera format, oavsett om de är strukturerade, halvstrukturerade eller ostrukturerade. Använd schema-on-read-semantik , som projicerar ett schema på data under bearbetningen i stället för vid tidpunkten för lagringen. Den här metoden ger flexibilitet i lösningen och hjälper till att förhindra flaskhalsar vid datainmatning som dataverifiering och typkontroll orsakar.

  • Bearbeta batchdata vid ankomst. Traditionella BI-lösningar använder ofta en ETL-process (extract, transform, and load) för att flytta data till ett informationslager. Men med större mängder data och en större mängd olika format antar stordatalösningar vanligtvis varianter av ETL, till exempel extrahering, inläsning och transformering (ELT).

  • Bearbeta strömmande data under flygning. För strömningslösningar transformerar du nyttolasten medan data överförs. Eftersom du hanterar mycket mindre paket via nätverket är det mycket enklare att transformera dessa mindre rader under genereringen. Landa den transformerade strömmen i en motor som är optimerad för händelsebaserade data, till exempel ett händelsehus för Real-Time Intelligence, vilket gör data omedelbart tillgängliga för åtgärder.

  • Balansera användnings- och tidskostnader. För batchbearbetningsjobb är det viktigt att tänka på kostnaden per enhet för beräkningsnoderna och kostnaden per minut för att använda dessa noder för att slutföra jobbet. Ett batchjobb kan till exempel ta åtta timmar med fyra klusternoder. Det kan dock visa sig att jobbet endast använder alla fyra noderna under de första två timmarna, och därefter krävs bara två noder. I så fall ökar körningen av hela jobbet på två noder den totala jobbtiden men fördubblar den inte, så den totala kostnaden är mindre. I vissa affärsscenarier kan en längre bearbetningstid vara att föredra framför den högre kostnaden för att använda underutnyttade klusterresurser.

  • Separata resurser. När det är möjligt bör du separera resurser baserat på arbetsbelastningarna för att undvika scenarier som en arbetsbelastning som använder alla resurser medan den andra väntar.

  • Samordna datainmatning. I vissa fall kan befintliga företagsprogram skriva datafiler för batchbearbetning direkt till Azure Storage Blob-containrar, där underordnade tjänster som Microsoft Fabric kan använda dem. Du behöver dock ofta samordna inmatningen av data från lokala eller externa datakällor till datasjön. Använd ett orkestreringsarbetsflöde eller en pipeline, till exempel de som stöds av Azure Data Factory eller Microsoft Fabric, för att uppnå förutsägbar och centralt hanterad dataflytt.

  • Rensa känsliga data tidigt. Arbetsflödet för datainmatning bör rensa känsliga data tidigt i processen för att undvika att lagra dem i datasjön.

IoT-arkitektur

IoT är en specialiserad delmängd av stordatalösningar. Följande diagram visar en möjlig logisk arkitektur för IoT. Diagrammet betonar komponenterna för händelseströmning i arkitekturen.

Diagram över en IoT-arkitektur.

Molngatewayen matar in enhetshändelser vid molngränsen. Den använder ett tillförlitligt meddelandesystem med låg svarstid för att säkerställa effektiv dataöverföring.

Enheter kan skicka händelser direkt till molngatewayen eller via en fältgateway. En fältgateway är en specialiserad enhet eller programvara, vanligtvis samlokaliserad med enheterna, som tar emot händelser och vidarebefordrar dem till molngatewayen. Fältgatewayen kan också förbearbeta råa enhetshändelser genom att utföra funktioner som filtrering, aggregering eller protokolltransformering.

Efter inmatningen går händelser genom en eller flera dataströmprocessorer som kan dirigera data eller utföra analys och annan bearbetning.

Överväg följande vanliga typer av bearbetning:

  • Data läses in i ett händelsebaserat datalager, till exempel ett händelsehus i Real-Time Intelligence för att kontextualisera IoT-enheten med metadata, till exempel byggplats och enhetsinformation.

  • Analysera händelseströmmen i realtid för att identifiera avvikelser, identifiera mönster över rullande tidsfönster eller utlösa aviseringar när specifika villkor inträffar i strömmen.

  • Hantering av särskilda typer av icke-telemetrimeddelanden från enheter, till exempel meddelanden och larm.

  • Bedömningshändelser med hjälp av maskininlärningsmodeller för att identifiera avvikelser, förutsäga fel eller klassificera enhetsbeteende.

De grå rutorna visar komponenter i ett IoT-system som inte är direkt relaterade till eventstreaming. De ingår här för fullständighet.

  • Enhetsregistret är en databas med etablerade enheter. Den innehåller enhets-ID:n och innehåller vanligtvis metadata, till exempel plats.

  • Etablerings-API:et är ett vanligt externt gränssnitt för etablering och registrering av nya enheter.

  • Vissa IoT-lösningar tillåter att kommando- och kontrollmeddelanden skickas till enheter.