Dela via

Arkitekturer för stordata

En stordataarkitektur hanterar inmatning, bearbetning och analys av data som är för stora eller komplexa för traditionella databassystem. Tröskelvärdet för att komma in i stordataområdet varierar mellan organisationer, beroende på deras verktyg och användarfunktioner. Vissa organisationer hanterar hundratals gigabyte data och andra organisationer hanterar hundratals terabyte. I takt med att verktygen för att arbeta med stordatamängder utvecklas övergår definitionen av stordata från att enbart fokusera på datastorlek till att betona värdet som härleds från avancerad analys. Även om dessa typer av scenarier tenderar att ha stora mängder data.

Under åren har datalandskapet förändrats. Det du kan göra, eller förväntas göra, med data har förändrats. Kostnaden för lagring har minskat dramatiskt, medan metoderna för datainsamling fortsätter att expandera. Vissa data kommer i snabb takt och kräver kontinuerlig insamling och observation. Andra data kommer långsammare, men i stora segment och ofta i form av årtionden av historiska data. Du kan stöta på ett problem med avancerad analys eller ett problem som kräver maskininlärning. Stordataarkitekturer strävar efter att lösa dessa utmaningar.

Stordatalösningar omfattar 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

Överväg stordataarkitekturer när du behöver utföra följande uppgifter:

  • Lagra och bearbeta data i volymer som är för stora för en traditionell databas
  • Transformera ostrukturerade data för analys och rapportering
  • Samla in, bearbeta och analysera obundna dataströmmar i realtid eller med låg svarstid

Komponenter i en arkitektur för stordata

Följande diagram visar de logiska komponenterna i en stordataarkitektur. Enskilda lösningar kanske inte innehåller alla objekt i det här diagrammet.

Diagram som visar den övergripande datapipelinen.

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

  • Datakällor: Alla stordatalösningar börjar med en eller flera datakällor. Exempel är:

    • Programdatalager, till exempel relationsdatabaser.
    • Statiska filer som program skapar, till exempel webbserverloggfiler.
    • Realtidsdatakällor, till exempel IoT-enheter (Internet of Things).

  • 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 Store, blobcontainrar i Azure Storage eller OneLake i Microsoft Fabric.

  • Satsvis bearbetning: Datauppsättningarna är stora, så en stordatalösning bearbetar ofta datafiler med hjälp av långvariga batchjobb för att filtrera, aggregera och på annat sätt förbereda data för analys. Vanligtvis omfattar dessa jobb att läsa källfiler, bearbeta dem och skriva utdata till nya filer. Du kan använda följande alternativ:

    • Använd Python-, Scala- eller SQL-språk i Azure Databricks-notebook-filer.
    • Använd Python-, Scala- eller SQL-språk i Fabric Notebooks.

  • Inmatning av meddelanden i realtid: Om lösningen innehåller realtidskällor måste arkitekturen samla in och lagra realtidsmeddelanden för dataströmbearbetning. Du kan till exempel ha ett enkelt datalager som samlar in inkommande meddelanden för bearbetning. Många lösningar behöver dock ett meddelandeinmatningslager för att fungera som en buffert för meddelanden och för att stödja skalbar bearbetning, tillförlitlig leverans och andra semantik för meddelandeköer. Den här delen av en strömningsarkitektur kallas ofta för strömbuffertning. Några exempel på alternativ är Azure Event Hubs, Azure IoT Hub och Kafka.

  • Dataströmbearbetning: När lösningen har avbildat realtidsmeddelanden måste den bearbeta dem genom att filtrera, aggregera och förbereda data för analys. De bearbetade dataströmmen skrivs sedan till en utdatamottagare.

    • Du kan använda Apache-strömningstekniker med öppen källkod, till exempel Spark Streaming, strömningstekniker i Azure Databricks.
    • Azure Functions är en serverlös beräkningstjänst som kan köra händelsedriven kod, vilket är perfekt för lätta dataströmbearbetningsuppgifter.
    • Fabric stöder databearbetning i realtid med hjälp av händelseströmmar och Spark-bearbetning.

  • Analysdatalager: Många stordatalösningar förbereder data för analys och hanterar sedan bearbetade data i ett strukturerat format som analysverktyg kan köra frågor mot. Det analysdatalager som hanterar dessa frågor kan vara ett relationsdatalager i Kimball-stil. De flesta traditionella BI-lösningar (Business Intelligence) använder den här typen av informationslager. Du kan också presentera data via en NoSQL-teknik med låg svarstid, till exempel HBase eller en interaktiv Hive-databas som tillhandahåller en metadataabstraktion över datafiler i det distribuerade datalagret.

    • Fabric tillhandahåller olika datalager, inklusive SQL-databaser, informationslager, sjöhus och eventhouses. Dessa verktyg kan hantera data för analys.
    • Azure tillhandahåller andra analytiska datalager, till exempel Azure Databricks, Azure Data Explorer, Azure SQL Database och Azure Cosmos DB.

  • Analys och rapportering: De flesta stordatalösningar strävar efter att ge insikter om data genom analys och rapportering. För att ge användarna möjlighet att analysera data kan arkitekturen innehålla ett datamodelleringslager, till exempel en flerdimensionell onlineanalysbearbetningskub eller tabelldatamodell 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.

    Dataforskare eller dataanalytiker kan också analysera och rapportera genom interaktiv datautforskning. I dessa scenarier stöder många Azure-tjänster analytiska notebook-filer, till exempel Jupyter, för att göra det möjligt för dessa användare att använda sina befintliga kunskaper med Python eller Microsoft R. För storskalig datautforskning kan du använda Microsoft R Server, antingen fristående eller med Spark. Du kan också använda Fabric för att redigera datamodeller, vilket ger flexibilitet och effektivitet för datamodellering och analys.

  • Orkestrering: De flesta stordatalösningar består av upprepade databearbetningsåtgärder som kapslas in i arbetsflöden. Operationerna utför följande uppgifter:

    • Transformera källdata
    • Flytta data mellan flera källor och mottagare
    • Läs in bearbetade data i ett analysdatalager
    • Skicka resultatet direkt till en rapport eller instrumentpanel

    Om du vill automatisera dessa arbetsflöden använder du en orkestreringsteknik som Azure Data Factory, Fabric eller Apache Oozie och Apache Sqoop.

Lambda-arkitektur

När du arbetar med stora datauppsättningar kan det ta lång tid att köra den typ av frågor som klienter behöver. Dessa frågor kan inte utföras i realtid, och de kräver ofta distribuerade bearbetningsalgoritmer, till exempel MapReduce som körs parallellt över hela datauppsättningen. Frågeresultaten lagras separat från rådata och används för ytterligare frågor.

En nackdel med den här metoden är att den ger svarstid. Om bearbetningen tar några timmar kan en fråga returnera resultat som är flera timmar gamla. Helst bör du få vissa resultat i realtid, eventuellt med en förlust av noggrannhet, och kombinera dessa resultat med resultaten från batchanalys.

Lambda-arkitekturen åtgärdar det här problemet genom att skapa två sökvägar för dataflödet. Alla data som kommer in i systemet går igenom följande två sökvägar:

  • Ett batchlager (kall väg) lagrar alla inkommande data i råform och utför batchbearbetning på denna data. Resultatet av den här bearbetningen lagras som en batchvy.

  • Ett hastighetslager (frekvent sökväg) analyserar data i realtid. Det här lagret är utformat för kort svarstid, på bekostnad av precision.

Batchlagret matas in i ett tjänsteskikt som indexerar batchvyn för effektiva förfrågningar. Hastighetslagret uppdaterar betjäningslagret med inkrementella uppdateringar baserat på senaste data.

Diagram som visar Lambda-arkitekturen.

Data som flödar in i den heta vägen måste bearbetas snabbt på grund av latenskrav som påtvingas av hastighetslagret. Snabbbearbetning säkerställer att data är redo för omedelbar användning men kan medföra felaktigheter. Tänk dig till exempel ett IoT-scenario där många temperatursensorer skickar telemetridata. Hastighetslagret kan bearbeta ett glidande tidsfönster för inkommande data.

Data som flödar in i den kalla vägen omfattas inte av samma låglatenskrav. Den kalla sökvägen ger hög noggrannhetsberäkning över stora datamängder, men det kan ta lång tid.

Slutligen konvergerar den heta och kalla sökvägen i klientprogrammet för analys. Om klienten behöver visa aktuella, men potentiellt mindre exakta data i realtid, hämtar den sitt resultat från den heta sökvägen. Annars väljer klienten resultat från den kalla sökvägen för att visa mindre aktuella men mer exakta data. Med andra ord innehåller den heta sökvägen data under en relativt kort tidsperiod, och därefter kan resultaten uppdateras med mer exakta data från den kalla sökvägen.

Rådata som lagras på batchlagret är oföränderliga. Inkommande data läggs till i befintliga data och tidigare data skrivs inte över. Ändringar av värdet för ett visst datum lagras som en ny tidsstämplad händelsepost. Tidsstämplade händelseposter möjliggör omberäkning när som helst i historiken för de data som samlas in. Det är viktigt att du kan kompilera om batchvyn från de ursprungliga rådata eftersom den gör det möjligt att skapa nya vyer allt eftersom systemet utvecklas.

Maskininlärning i Lambda-arkitektur

Lambda-arkitekturer stöder maskininlärningsarbetsbelastningar genom att tillhandahålla både historiska data för modellträning och realtidsdata för slutsatsdragning. Batchlagret möjliggör träning på omfattande historiska datauppsättningar med hjälp av Azure Machine Learning - eller Fabric Data Science-arbetsbelastningar. Hastighetsskiktet underlättar modellinferens och bedömning i realtid. Den här dubbla metoden möjliggör modeller som tränats på fullständiga historiska data samtidigt som man ger omedelbara förutsägelser om inkommande dataströmmar.

Kappa-arkitektur

En nackdel med Lambda-arkitekturen är dess komplexitet. Bearbetningslogik visas på två olika ställen, de kalla och heta vägarna, via olika ramverk. Den här processen leder till duplicerad beräkningslogik och komplex hantering av arkitekturen för båda sökvägarna.

Kappa-arkitekturen är ett alternativ till Lambda-arkitekturen. Den har samma grundläggande mål som Lambda-arkitekturen, men all data flödar genom en enda väg via ett system för strömbearbetning av data.

Diagram som visar Kappa-arkitekturen.

I likhet med Lambda-arkitekturens batchlager är händelsedata oföränderliga och allt samlas in i stället för en delmängd data. Data matas in som en ström av händelser i en distribuerad, feltolerant enhetlig logg. De här händelserna är ordnade, och det aktuella tillståndet för en händelse ändras bara av att en ny händelse läggs till. På samma sätt som Lambda-arkitekturens hastighetslager utförs all händelsebearbetning på indataströmmen och sparas som en realtidsvy.

Om du behöver omkompilera hela datamängden (vilket motsvarar vad batchlagret gör i Lambda-arkitekturen) kan du spela upp strömmen igen. Den här processen använder vanligtvis parallellitet för att slutföra beräkningen i rätt tid.

Maskininlärning i Kappa-arkitektur

Kappa-arkitekturer möjliggör enhetliga arbetsflöden för maskininlärning genom att bearbeta alla data via en enda pipeline för direktuppspelning. Den här metoden förenklar modelldistribution och underhåll eftersom samma bearbetningslogik gäller både historiska data och realtidsdata. Du kan använda Azure Machine Learning- eller Fabric Data Science-arbetsbelastningar för att skapa modeller som bearbetar strömmande data, vilket möjliggör kontinuerlig inlärning och anpassning i realtid. Arkitekturen stöder onlineinlärningsalgoritmer som uppdaterar modeller stegvis när nya data tas emot.

Lakehouse-arkitektur

En datasjö är en centraliserad datalagringsplats som lagrar strukturerade data (databastabeller), halvstrukturerade data (XML-filer) och ostrukturerade data (bilder och ljudfiler). Dessa data är i dess råa, ursprungliga format och kräver inte fördefinierat schema. En datasjö kan hantera stora mängder data, så den är lämplig för bearbetning och analys av stordata. Datasjöar använder lagringslösningar till låg kostnad, vilket är ett kostnadseffektivt sätt att lagra stora mängder data.

Ett informationslager är en centraliserad lagringsplats som lagrar strukturerade och halvstrukturerade data i rapporterings-, analys- och BI-syfte. Informationslager kan hjälpa dig att fatta välgrundade beslut genom att tillhandahålla en konsekvent och omfattande vy över dina data.

Lakehouse-arkitekturen kombinerar de bästa elementen i datasjöar och informationslager. Mönstret syftar till att tillhandahålla en enhetlig plattform som stöder både strukturerade och ostrukturerade data, vilket möjliggör effektiv datahantering och analys. Dessa system använder vanligtvis molnlagring till låg kostnad i öppna format, till exempel Parquet eller Optimerad radkolumn, för att lagra både rådata och bearbetade data.

Ett diagram som visar ett dataflöde från källan till transformerings- och lagringsfasen och sedan till fasen för användning och visualisering.

Vanliga användningsfall för en lakehouse-arkitektur är:

  • Enhetlig analys: Perfekt för organisationer som behöver en enda plattform för både historisk dataanalys och realtidsdataanalys
  • Datastyrning: Säkerställer efterlevnad och datakvalitet i stora datauppsättningar

Maskininlärning i Lakehouse-arkitektur

Lakehouse-arkitekturer är utmärkta för att stödja maskininlärningsarbetsflöden från slutpunkt till slutpunkt genom att ge enhetlig åtkomst till både strukturerade och ostrukturerade data. Dataexperter kan använda Fabric Data Science-arbetsbelastningar för att få åtkomst till rådata för undersökande analys, funktionsutveckling och modellträning utan komplex dataflytt. Arkitekturen stöder hela livscykeln för maskininlärning, från förberedelse av data och modellutveckling med hjälp av Azure Machine Learning- eller Fabric-notebook-filer, till modelldistribution och övervakning. Det enhetliga lagringslagret möjliggör effektivt samarbete mellan datatekniker och dataforskare samtidigt som data härstamning och styrning bibehålls.

IoT-teknik

IoT representerar alla enheter som ansluter till Internet och skickar eller tar emot data. IoT-enheter inkluderar datorer, mobiltelefoner, smarta klockor, smarta termostater, smarta kylskåp, anslutna bilar och hjärtövervakningsimplantat.

Antalet anslutna enheter växer varje dag, och det gör även mängden data som de genererar. Dessa data samlas ofta in i miljöer som har betydande begränsningar och ibland långa svarstider. I andra fall skickar tusentals eller miljontals enheter data från miljöer med låg latens, vilket kräver snabb inmatning och bearbetning. Du måste planera för att hantera dessa begränsningar och unika krav.

Händelsedrivna arkitekturer är centrala för IoT-lösningar. Följande diagram visar en logisk arkitektur för IoT. Diagrammet betonar komponenterna för händelseströmning i arkitekturen.

Diagram som visar IoT-arkitekturen.

Molngatewayen matar in enhetshändelser vid molngränsen via ett tillförlitligt meddelandesystem med låg svarstid.

Enheter kan skicka händelser direkt till molngatewayen eller via en fältgateway. En fältgateway är en särskild enhet eller programvara, vanligtvis samordnad med enheterna, som tar emot händelser och vidarebefordrar dem till molngatewayen. Fältgatewayen kan också förbearbeta de råa enhetshändelserna, som omfattar att utföra filtrerings-, aggregerings- eller protokolltransformeringsfunktioner.

Efter inmatningen går händelser via en eller flera dataströmprocessorer som kan dirigera data till mål, till exempel lagring, eller utföra analys och annan bearbetning.

Vanliga typer av bearbetning är:

  • Skriva händelsedata till kall lagring för arkivering eller batchanalys.

  • Analys av heta vägar. Analysera händelseströmmen nästan i realtid för att identifiera avvikelser, identifiera mönster över rullande tidsfönster eller utlösa aviseringar när ett specifikt villkor inträffar i strömmen.

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

  • Maskininlärning för förebyggande underhåll, avvikelseidentifiering och intelligent beslutsfattande.

I föregående diagram är de grå rutorna komponenter i ett IoT-system som inte är direkt relaterade till händelseströmning. De ingår i diagrammet för fullständighet.

  • Enhetsregistret är en databas med etablerade enheter, inklusive enhets-ID:n och vanligtvis enhetsmetadata, 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.

Maskininlärning i IoT-arkitektur

IoT-arkitekturer använder maskininlärning för intelligent edge-databehandling och molnbaserad analys. Edge-enheter kan köra enkla modeller för beslutsfattande i realtid, medan omfattande modeller bearbetar aggregerade data i molnet med hjälp av Azure Machine Learning- eller Fabric Data Science-arbetsbelastningar. Vanliga program är förebyggande underhåll, avvikelseidentifiering och automatiserade svarssystem. Arkitekturen stöder både strömmande analys för omedelbara insikter och batchbearbetning för modellträning och förfining med historiska IoT-data.

Nästa steg