Big data-architecturen

Een big data-architectuur beheert de opname, verwerking en analyse van gegevens die te groot of complex zijn voor traditionele databasesystemen. De drempelwaarde voor het invoeren van het gebied van big data varieert per organisatie, afhankelijk van hun hulpprogramma's en gebruikersmogelijkheden. Sommige organisaties beheren honderden gigabytes aan gegevens en andere organisaties beheren honderden terabytes. Naarmate de hulpprogramma's voor het werken met big datasets zich ontwikkelen, verschuift de definitie van big data niet alleen op de gegevensgrootte tot het benadrukken van de waarde die is afgeleid van geavanceerde analyses. Hoewel deze typen scenario's vaak grote hoeveelheden gegevens bevatten.

Het gegevenslandschap is de afgelopen jaren veranderd. Wat u met gegevens kunt doen, of wat er op dit gebied van u wordt verwacht, is veranderd. De opslagkosten zijn aanzienlijk gedaald, terwijl de methoden voor het verzamelen van gegevens steeds verder worden uitgebreid. Sommige gegevens komen snel aan en vereisen continue verzameling en observatie. Andere gegevens komen langzamer binnen, maar in grote segmenten en vaak in de vorm van decennia aan historische gegevens. Mogelijk ondervindt u een probleem met geavanceerde analyses of een probleem waarbij machine learning moet worden opgelost. Big data-architecturen streven ernaar om deze uitdagingen op te lossen.

Big data-oplossingen hebben doorgaans betrekking op een of meer van de volgende typen workloads:

• Batchverwerking van big data-bronnen in rust
• Realtime verwerking van big data in beweging
• Interactieve verkenning van big data
• Voorspellende analyse en machine learning

Overweeg big data-architecturen wanneer u de volgende taken moet uitvoeren:

• Gegevens opslaan en verwerken in volumes die te groot zijn voor een traditionele database
• Ongestructureerde gegevens transformeren voor analyse en rapportage
• Niet-gebonden gegevensstromen vastleggen, verwerken en analyseren in realtime of met lage latentie

Onderdelen van een big data-architectuur

In het volgende diagram ziet u de logische onderdelen van een big data-architectuur. Afzonderlijke oplossingen bevatten mogelijk niet elk item in dit diagram.

Het proces begint bij gegevensbronnen. De gegevens gaan naar gegevensopslag en realtime berichtopname, die zijn verbonden. De gegevens in gegevensopslag gaan naar batchverwerking, om vervolgens naar de analytische dataopslag en dan naar analyse en rapportage te gaan, of rechtstreeks naar analyse en rapportage. De gegevens in real-time berichtverwerking gaan naar streamverwerking. Vervolgens gaat u naar het analytische gegevensarchief en vervolgens naar analyse en rapportage, of rechtstreeks naar analyse en rapportage. Machine learning verwijst naar batchverwerking en stroomverwerking.

De meeste big data-architecturen bevatten enkele of alle volgende onderdelen:

• Gegevensbronnen: Alle big data-oplossingen beginnen met een of meer gegevensbronnen. Voorbeelden zijn:

  • Toepassingsgegevensarchieven, zoals relationele databases.
  • Statische bestanden die toepassingen produceren, zoals webserverlogboekbestanden.
  • Realtime-gegevensbronnen, zoals IoT-apparaten (Internet of Things).

• Gegevensopslag: Gegevens voor batchverwerkingsbewerkingen worden doorgaans opgeslagen in een gedistribueerd bestandsarchief dat grote hoeveelheden grote bestanden in verschillende indelingen kan bevatten. Dit soort opslag wordt vaak een data lakegenoemd. Opties voor het implementeren van deze opslag zijn Onder andere Azure Data Lake Store, blobcontainers in Azure Storage of OneLake in Microsoft Fabric.

• Batchverwerking: De gegevenssets zijn groot, dus een big data-oplossing verwerkt vaak gegevensbestanden met behulp van langlopende batchtaken om gegevens te filteren, aggregeren en anderszins voor te bereiden op analyse. Meestal zijn deze taken het lezen van bronbestanden, het verwerken ervan en het schrijven van de uitvoer naar nieuwe bestanden. U kunt de volgende opties gebruiken:

  • Voer U-SQL-taken uit in Azure Data Lake Analytics.

  • Gebruik Hive-, Pig- of aangepaste MapReduce-taken in een Azure HDInsight Hadoop-cluster.

  • Gebruik Java-, Scala- of Python-programma's in een HDInsight Spark-cluster.

  • Gebruik python-, Scala- of SQL-taal in Azure Databricks-notebooks.

  • Gebruik python-, Scala- of SQL-taal in Fabric-notebooks.

• Realtime berichtopname: Als de oplossing realtime bronnen bevat, moet de architectuur realtime berichten vastleggen en opslaan voor stroomverwerking. U kunt bijvoorbeeld een eenvoudig gegevensarchief hebben dat binnenkomende berichten verzamelt voor verwerking. Veel oplossingen hebben echter een opslag voor berichtopname nodig om te fungeren als buffer voor berichten en om uitschalen, betrouwbare bezorging en andere semantiek voor berichten in de wachtrij te ondersteunen. Dit deel van een streamingarchitectuur wordt vaak streambuffering genoemd. Opties zijn onder andere Azure Event Hubs, Azure IoT Hub en Kafka.

• Stroomverwerking: Nadat de oplossing realtime berichten heeft vastgelegd, moet deze worden verwerkt door de gegevens te filteren, te aggregeren en voor te bereiden op analyse. De verwerkte streamgegevens worden vervolgens naar een uitvoersink geschreven.

  • Azure Stream Analytics is een beheerde stroomverwerkingsservice die gebruikmaakt van continu uitgevoerde SQL-query's die worden uitgevoerd op niet-gebonden streams.

  • U kunt opensource-technologieën voor Apache Streaming gebruiken, zoals Spark Streaming, in een HDInsight-cluster of Azure Databricks.

  • Azure Functions is een serverloze rekenservice waarmee gebeurtenisgestuurde code kan worden uitgevoerd, wat ideaal is voor lichtgewicht stroomverwerkingstaken.

  • Fabric ondersteunt realtime gegevensverwerking met behulp van gebeurtenisstromen en Spark-verwerking.

• Machine learning: Voor het analyseren van voorbereide gegevens uit batch- of stroomverwerking kunt u machine learning-algoritmen gebruiken om modellen te bouwen die resultaten voorspellen of gegevens classificeren. Deze modellen kunnen worden getraind op grote gegevenssets. U kunt de resulterende modellen gebruiken om nieuwe gegevens te analyseren en voorspellingen te doen.

  Gebruik Azure Machine Learning om deze taken uit te voeren. Machine Learning biedt hulpprogramma's voor het bouwen, trainen en implementeren van modellen. U kunt ook vooraf gebouwde API's van Azure AI-services gebruiken voor algemene machine learning-taken, zoals vision-, spraak-, taal- en besluitvormingstaken.

• Analytische gegevensopslag: Veel big data-oplossingen bereiden gegevens voor op analyse en leveren vervolgens de verwerkte gegevens in een gestructureerde indeling waarop analytische hulpprogramma's query's kunnen uitvoeren. Het analytische gegevensarchief dat deze query's dient, kan een relationeel datawarehouse van Kimball zijn. De meeste traditionele BI-oplossingen (Business Intelligence) gebruiken dit type datawarehouse. U kunt de gegevens ook presenteren via een NoSQL-technologie met lage latentie, zoals HBase of een interactieve Hive-database die metagegevensabstractie biedt voor gegevensbestanden in het gedistribueerde gegevensarchief.

  • Azure Synapse Analytics is een beheerde service voor grootschalige, cloudgebaseerde datawarehousing.

  • HDInsight ondersteunt Interactive Hive, HBase en Spark SQL. Deze hulpprogramma's kunnen gegevens leveren voor analyse.

  • Fabric biedt verschillende gegevensarchieven, waaronder SQL-databases, datawarehouses, lakehouses en eventhouses. Deze hulpprogramma's kunnen gegevens leveren voor analyse.

  • Azure biedt andere analytische gegevensarchieven, zoals Azure Databricks, Azure Data Explorer, Azure SQL Database en Azure Cosmos DB.

• Analyse en rapportage: De meeste big data-oplossingen streven ernaar om inzicht te krijgen in de gegevens via analyse en rapportage. Om gebruikers in staat te stellen de gegevens te analyseren, kan de architectuur een gegevensmodelleringslaag bevatten, zoals een multidimensionale online analytische verwerkingskubus of gegevensmodel in tabelvorm in Azure Analysis Services. Het kan ook ondersteuning bieden voor selfservice BI met behulp van de modellerings- en visualisatietechnologieën in Power BI of Excel.

  Gegevenswetenschappers of gegevensanalisten kunnen ook analyseren en rapporteren via interactieve gegevensverkenning. Voor deze scenario's ondersteunen veel Azure-services analytische notebooks, zoals Jupyter, om deze gebruikers in staat te stellen hun bestaande vaardigheden te gebruiken met Python of Microsoft R. Voor grootschalige gegevensverkenning kunt u Microsoft R Server gebruiken, zelfstandig of met Spark. U kunt Fabric ook gebruiken om gegevensmodellen te bewerken, wat flexibiliteit en efficiëntie biedt voor gegevensmodellering en -analyse.

• Orkestratie: De meeste big data-oplossingen bestaan uit herhaalde gegevensverwerkingsbewerkingen die zijn ingekapseld in werkstromen. De operaties voeren de volgende taken uit:

  • Brongegevens transformeren
  • Gegevens verplaatsen tussen meerdere bronnen en sinks
  • De verwerkte gegevens inladen in een analytische gegevensopslag
  • De resultaten rechtstreeks naar een rapport of dashboard pushen

  Als u deze werkstromen wilt automatiseren, gebruikt u een indelingstechnologie zoals Azure Data Factory, Fabric of Apache Oozie en Apache Sqoop.

Lambda-architectuur

Wanneer u met grote gegevenssets werkt, kan het lang duren voordat het type query's wordt uitgevoerd dat clients nodig hebben. Deze query's kunnen niet in realtime worden uitgevoerd. En ze vereisen vaak algoritmen zoals MapReduce die parallel in de hele gegevensset werken. De queryresultaten worden afzonderlijk van de onbewerkte gegevens opgeslagen en gebruikt voor verdere query's.

Een nadeel van deze benadering is dat deze latentie introduceert. Als de verwerking enkele uren duurt, kan een query resultaten retourneren die enkele uren oud zijn. In het ideale geval krijgt u in realtime resultaten, mogelijk met een verlies van nauwkeurigheid en combineert u deze resultaten met de resultaten van batchanalyses.

De Lambda-architectuur lost dit probleem op door twee paden voor de gegevensstroom te maken. Alle gegevens die in het systeem binnenkomen, doorlopen de volgende twee paden:

• In een batchlaag (koud pad) worden alle binnenkomende gegevens opgeslagen in de onbewerkte vorm en worden batchverwerking op de gegevens uitgevoerd. Het resultaat van deze verwerking wordt opgeslagen als een batchweergave.

• In een snelheidslaag (dynamisch pad) worden gegevens in realtime geanalyseerd. Deze laag is ontworpen voor een lage latentie. Dit gaat ten koste van de nauwkeurigheid.

De batchlaag wordt opgenomen in de leveringslaag waarmee de batchweergave wordt geïndexeerd voor het efficiënt uitvoeren van query's. De snelheidslaag werkt de leveringslaag bij met incrementele updates op basis van de meest recente gegevens.

De gegevensstroombron is een geïntegreerd logboek met gebeurtenisgegevens. De gegevens gaan naar de snelheidslaag of de batchlaag. Vanaf de snelheidslaag verwijst een ononderbroken lijn naar de analyseclient en een stippellijn naar de ondersteunende laag. Vanuit de batchlaag gaan de gegevens naar de serverlaag en vervolgens naar de analyseclient. De snelheidslaag wordt gelabeld als een heet pad. De batchlaag en de serverlaag worden gelabeld als een koud pad.

Gegevens die in het hot path stromen, moeten snel worden verwerkt vanwege vereisten voor vertraging die door de snelheidslaag worden opgelegd. Snelle verwerking zorgt ervoor dat gegevens direct kunnen worden gebruikt, maar kunnen onnauwkeurigheid veroorzaken. Denk bijvoorbeeld aan een IoT-scenario waarbij talloze temperatuursensoren telemetriegegevens verzenden. De snelheidslaag kan een schuivend tijdvenster van de binnenkomende gegevens verwerken.

Gegevens die naar het koude pad stromen, zijn niet onderhevig aan dezelfde lage latentievereisten. Het koude pad biedt een hoge nauwkeurigheidsberekening voor grote gegevenssets, maar kan lang duren.

Uiteindelijk komen het hete en het koude pad samen in de clienttoepassing voor analyse. Als de client tijdig, maar mogelijk minder nauwkeurige gegevens in realtime moet weergeven, verwerft het het resultaat van de snelle route. Anders selecteert de client resultaten van het koude pad om minder actuele maar meer nauwkeurige gegevens weer te geven. Met andere woorden: het dynamische pad bevat gegevens voor een relatief klein tijdvenster, waarna de resultaten kunnen worden bijgewerkt met nauwkeurigere gegevens uit het koude pad.

De onbewerkte gegevens die op de batchlaag zijn opgeslagen, zijn onveranderbaar. Binnenkomende gegevens worden toegevoegd aan de bestaande gegevens en de vorige gegevens worden niet overschreven. Wijzigingen in de waarde van een bepaalde datum worden opgeslagen als een nieuw tijdstempelgebeurtenisrecord. Records van gebeurtenissen met een tijdstempel maken het mogelijk om op elk gewenst moment opnieuw te berekenen in de geschiedenis van de verzamelde gegevens. De mogelijkheid om de batchweergave opnieuw te compileren op basis van de oorspronkelijke onbewerkte gegevens is belangrijk omdat hiermee nieuwe weergaven kunnen worden gemaakt naarmate het systeem zich ontwikkelt.

Kappa-architectuur

Een nadeel van de Lambda-architectuur is de complexiteit. Verwerkingslogica wordt weergegeven op twee verschillende plaatsen, de koude en dynamische paden, via verschillende frameworks. Dit proces leidt tot dubbele berekeningslogica en complex beheer van de architectuur voor beide paden.

De Kappa-architectuur is een alternatief voor de Lambda-architectuur. Het heeft dezelfde basisdoelen als de Lambda-architectuur, maar alle gegevens stromen via één pad via een stroomverwerkingssysteem.

De gegevensstroombron is een geïntegreerd logboek met gebeurtenisgegevens. De gegevens gaan naar de snelheidslaag of langetermijnopslag. De regel van de brongegevens naar de langetermijnopslag leest 'spiegelgebeurtenissen naar langetermijnopslag'. De langetermijnopslag verwijst naar de snelheidslaag. Deze regel leest 'logboek gebeurtenissen opnieuw compileren vanuit de opslag, indien nodig'. De snelheidslaag wijst naar de analytics-client en is groen omlijnd.

Net als bij de batchlaag van de Lambda-architectuur zijn de gebeurtenisgegevens onveranderbaar en worden alle gegevens verzameld in plaats van een subset van gegevens. De gegevens worden opgenomen als een stroom gebeurtenissen in een gedistribueerd, fouttolerant geïntegreerd logboek. Deze gebeurtenissen worden geordend en de status van een gebeurtenis wordt alleen gewijzigd wanneer er een nieuwe gebeurtenis wordt toegevoegd. Net als bij de snelheidslaag van de Lambda-architectuur wordt alle gebeurtenisverwerking uitgevoerd op de invoerstroom en behouden als een realtime weergave.

Als u de volledige gegevensset opnieuw moet compileren (gelijk aan wat de batchlaag in de Lambda-architectuur doet), kunt u de stroom opnieuw afspelen. Dit proces maakt doorgaans gebruik van parallelle uitvoering om de berekening tijdig te voltooien.

Lakehouse-architectuur

Een data lake is een gecentraliseerde gegevensopslagplaats waarin gestructureerde gegevens (databasetabellen), semi-gestructureerde gegevens (XML-bestanden) en ongestructureerde gegevens (afbeeldingen en audiobestanden) worden opgeslagen. Deze gegevens hebben de onbewerkte, oorspronkelijke indeling en vereisen geen vooraf gedefinieerd schema. Een data lake kan grote hoeveelheden gegevens verwerken, zodat deze geschikt is voor het verwerken en analyseren van big data. Data Lakes maakt gebruik van goedkope opslagoplossingen, die een rendabele manier bieden om grote hoeveelheden gegevens op te slaan.

Een datawarehouse is een gecentraliseerde opslagplaats waarin gestructureerde en semi-gestructureerde gegevens worden opgeslagen voor rapportage-, analyse- en BI-doeleinden. Datawarehouses kunnen u helpen bij het nemen van weloverwogen beslissingen door een consistent en uitgebreid overzicht van uw gegevens te bieden.

De Lakehouse-architectuur combineert de beste elementen van data lakes en datawarehouses. Het patroon is bedoeld om een geïntegreerd platform te bieden dat zowel gestructureerde als ongestructureerde gegevens ondersteunt, waardoor efficiënt gegevensbeheer en analyses mogelijk zijn. Deze systemen maken doorgaans gebruik van goedkope cloudopslag in open indelingen, zoals Parquet of Optimized Row Columnar, om zowel onbewerkte als verwerkte gegevens op te slaan.

Veelvoorkomende gebruiksvoorbeelden voor een lakehouse-architectuur zijn:

• Unified Analytics: Ideaal voor organisaties die één platform nodig hebben voor zowel historische als realtime gegevensanalyse

• Machine learning: Biedt ondersteuning voor geavanceerde analyses en machine learning-workloads door de integratie van mogelijkheden voor gegevensbeheer

• Gegevensbeheer: Zorgt voor naleving en gegevenskwaliteit voor grote gegevenssets

Internet der Dingen

De IoT vertegenwoordigt elk apparaat dat verbinding maakt met internet en gegevens verzendt of ontvangt. IoT-apparaten zijn onder andere pc's, mobiele telefoons, smart watches, slimme thermostaten, slimme koelkasten, verbonden auto's en implantaten voor hartbewaking.

Het aantal verbonden apparaten groeit elke dag en ook de hoeveelheid gegevens die ze genereren. Deze gegevens worden vaak verzameld in omgevingen met aanzienlijke beperkingen en soms hoge latentie. In andere gevallen verzenden duizenden of miljoenen apparaten gegevens uit omgevingen met lage latentie, waarvoor snelle opname en verwerking is vereist. U moet deze beperkingen en unieke vereisten op de juiste manier afhandelen.

Gebeurtenisafhankelijke architecturen zijn essentieel voor IoT-oplossingen. In het volgende diagram ziet u een logische architectuur voor IoT. In het diagram worden de onderdelen voor gebeurtenisstreaming van de architectuur benadrukt.

De gegevensstroom begint met apparaten aan de linkerkant, verbonden met een veldgateway, die vervolgens verbinding maakt met een cloudgateway. De cloudgateway maakt verbinding met verschillende taken via streamverwerking. De taken omvatten koude opslag, analyse van dynamische paden, meldingen en machine learning. Batch-analyse verwijst naar koude opslag. Streamverwerking verwijst naar de back-end van de toepassing, die verwijst naar aansturing en beheer, de inrichtings-API en het apparaatregister. De inrichtings-API verwijst naar het apparaatregister. Opdracht en beheer verwijst naar de oorspronkelijke veldgateway en naar andere apparaten, niet naar de oorspronkelijke apparaten in de gegevensstroom.

De cloudgateway neemt apparaatgebeurtenissen op bij de cloudgrens via een betrouwbaar berichtensysteem met lage latentie.

Apparaten kunnen gebeurtenissen rechtstreeks naar de cloudgateway of via een veldgateway verzenden. Een veldgateway is een gespecialiseerd apparaat of gespecialiseerde software, meestal op dezelfde locatie als de apparaten, waarmee gebeurtenissen worden ontvangen en doorgestuurd naar de cloudgateway. De veldgateway kan ook de onbewerkte apparaatgebeurtenissen vooraf verwerken, waaronder het uitvoeren van filter-, aggregatie- of protocoltransformatiefuncties.

Na opname doorlopen gebeurtenissen een of meer stroomprocessors die de gegevens naar bestemmingen kunnen routeren, zoals opslag, of analyses en andere verwerkingen kunnen uitvoeren.

Veelvoorkomende verwerkingstypen zijn:

• Gebeurtenisgegevens schrijven naar koude opslag voor archivering of batchanalyse.

• Dynamische padanalyse. Analyseer de gebeurtenisstroom in bijna realtime om afwijkingen te detecteren, patronen te herkennen in lopende tijdvensters of waarschuwingen te activeren wanneer er een specifieke voorwaarde in de stream voorkomt.

• Verwerken van speciale typen niet-telemetrieberichten van apparaten, zoals meldingen en alarmen.

• Machinaal leren

In het vorige diagram zijn de grijze vakken onderdelen van een IoT-systeem die niet rechtstreeks zijn gerelateerd aan gebeurtenisstreaming. Ze zijn opgenomen in het diagram voor volledigheid.

• Het apparaatregister is een database van de ingerichte apparaten, waaronder de apparaat-id's en meestal metagegevens van apparaten, zoals locatie.

• De inrichtings-API is een algemene externe interface voor het inrichten en registreren van nieuwe apparaten.

• In sommige IoT-oplossingen kunnen opdracht- en besturingsberichten naar apparaten worden verzonden.

Volgende stappen

• IoT Hub
• Event Hubs
• Stream Analytics
• Azure Data Explorer
• Stof
• Azure Databricks

Verwante middelen

• IoT-architecturen
• Architectuurstijl voor big data
• Moderne analysearchitectuur met Azure Databricks
• Big data-architecturen met Fabric