Aanbevolen procedures voor betrouwbaarheid

In dit artikel worden aanbevolen procedures voor betrouwbaarheid beschreven op basis van architectuurprincipes die in de volgende secties worden vermeld.

1. Ontwerp voor fout

Een gegevensindeling gebruiken die ACID-transacties ondersteunt

ACID-transacties zijn een essentiële functie voor het onderhouden van gegevensintegriteit en consistentie. Als u een gegevensindeling kiest die ACID-transacties ondersteunt, kunt u pijplijnen bouwen die eenvoudiger en betrouwbaarder zijn.

Delta Lake is een opensource-opslagframework dat ACID-transacties biedt, evenals schema-afdwinging, schaalbare verwerking van metagegevens en het combineren van streaming- en batchgegevensverwerking. Delta Lake is volledig compatibel met de Apache Spark-API's en is ontworpen voor een nauwe integratie met gestructureerde streaming, zodat u eenvoudig één kopie van gegevens kunt gebruiken voor zowel batch- als streamingbewerkingen en incrementele verwerking op schaal kunt bieden.

Een flexibele gedistribueerde gegevensengine gebruiken voor alle workloads

Apache Spark, als rekenengine van Azure Databricks Lakehouse, is gebaseerd op flexibele gedistribueerde gegevensverwerking. Als een interne Spark-taak geen resultaat retourneert zoals verwacht, worden de ontbrekende taken automatisch opnieuw gepland in Apache Spark en wordt de hele taak uitgevoerd. Dit is handig voor out-of-code-fouten, zoals een kort netwerkprobleem of een ingetrokken spot-VM. Deze tolerantie is ingebouwd in de engine om te werken met zowel de SQL-API als de Spark DataFrame-API.

In databricks lakehouse, Photon, een systeemeigen vectorengine die volledig is geschreven in C++, is een krachtige rekenkracht die compatibel is met Apache Spark-API's.

Ongeldige of niet-conforme gegevens automatisch redden

Ongeldige of niet-conforme gegevens kunnen ertoe leiden dat workloads die afhankelijk zijn van een bestaande gegevensindeling vastlopen. Als u de end-to-end-tolerantie van het hele proces wilt verhogen, is het raadzaam om ongeldige en niet-conforme gegevens bij opname uit te filteren. Ondersteuning voor geredde gegevens zorgt ervoor dat u nooit gegevens kwijtraakt of mist tijdens opname of ETL. De kolom met geredde gegevens bevat gegevens die niet zijn geparseerd, omdat deze ontbreken in het opgegeven schema, omdat er een type niet overeenkomt of omdat de kolomtekst in de record of het bestand niet overeenkomt met die in het schema.

• Databricks Auto Loader: Auto Loader is het ideale hulpprogramma voor het streamen van de bestandsopname. Het ondersteunt geredde gegevens voor JSON en CSV. Voor JSON bevat de kolom met geredde gegevens bijvoorbeeld gegevens die niet zijn geparseerd, mogelijk omdat deze ontbreekt in het opgegeven schema, omdat er een type niet overeenkomt of omdat de behuizing van de kolom niet overeenkomt. De kolom met geredde gegevens maakt deel uit van het schema dat standaard door autolader _rescued_data wordt geretourneerd wanneer het schema wordt afgeleid.
• Delta Live Tables: Een andere optie voor het bouwen van werkstromen voor tolerantie is het gebruik van Delta Live-tabellen met kwaliteitsbeperkingen. Zie Gegevenskwaliteit beheren met Delta Live Tables. Kant-en-klare Delta Live-tabellen ondersteunen drie modi: Ongeldige records behouden, neerzetten en mislukken. Als u ongeldige records in quarantaine wilt plaatsen, kunnen verwachtingsregels op een specifieke manier worden gedefinieerd, zodat ongeldige records worden opgeslagen ('in quarantaine geplaatst') in een andere tabel. Zie Quarantaine ongeldige gegevens.

Taken configureren voor automatische nieuwe pogingen en beëindiging

Gedistribueerde systemen zijn complex en een storing in één punt kan mogelijk doorwerken in het hele systeem.

• Azure Databricks-taken ondersteunen beleid voor opnieuw proberen voor taken die bepalen wanneer en hoe vaak mislukte uitvoeringen opnieuw worden uitgevoerd. Zie Beleid voor opnieuw proberen instellen.
• U kunt optionele duurdrempels voor een taak configureren, inclusief een verwachte voltooiingstijd voor de taak en een maximale voltooiingstijd voor de taak.
• Delta Live Tables automatiseert ook het herstel van fouten door het escaleren van nieuwe pogingen om de snelheid en betrouwbaarheid te verdelen. Zie Ontwikkelings- en productiemodi.

Aan de andere kant kan een vastgelopen taak verhinderen dat de hele taak wordt voltooid, wat resulteert in hoge kosten. Databricks-taken ondersteunen time-outconfiguratie om taken te beëindigen die langer duren dan verwacht.

Schaalbare en productiemodelmodelinfrastructuur gebruiken

Voor batch- en streamingdeductie gebruikt u Azure Databricks-taken en MLflow om modellen te implementeren als Apache Spark UDF's om jobplanning, nieuwe pogingen, automatisch schalen enzovoort te gebruiken. Zie Modellen implementeren voor batchdeductie en voorspelling.

Het leveren van modellen biedt een schaalbare infrastructuur op productieniveau voor realtime modelverdiening . Het verwerkt uw machine learning-modellen met behulp van MLflow en maakt ze beschikbaar als REST API-eindpunten. Deze functionaliteit maakt gebruik van serverloze berekeningen, wat betekent dat de eindpunten en gekoppelde rekenresources worden beheerd en uitgevoerd in het Azure Databricks-cloudaccount.

Beheerde services waar mogelijk gebruiken

Maak gebruik van beheerde services (serverloze compute) van het Databricks Data Intelligence Platform, zoals:

• serverloze SQL-warehouses
• modellering
• serverloze taken
• serverloze rekenkracht voor notebooks
• Delta Live-tabellen

Deze services worden beheerd door Databricks op een betrouwbare en schaalbare manier zonder extra kosten voor de klant, waardoor workloads betrouwbaarder worden.

2. Gegevenskwaliteit beheren

Een gelaagde opslagarchitectuur gebruiken

Cureer gegevens door een gelaagde architectuur te maken en ervoor te zorgen dat de gegevenskwaliteit toeneemt naarmate de gegevens door de lagen worden verplaatst. Een algemene gelaagde benadering is:

• Onbewerkte laag (brons): Brongegevens worden opgenomen in het lakehouse in de eerste laag en moeten daar worden bewaard. Wanneer alle downstreamgegevens worden gemaakt op basis van de onbewerkte laag, is het mogelijk om de volgende lagen van deze laag zo nodig opnieuw te bouwen.
• Gecureerde laag (zilver): het doel van de tweede laag is om opgeschoonde, verfijnde, gefilterde en geaggregeerde gegevens te bewaren. Het doel van deze laag is om een solide, betrouwbare basis te bieden voor analyse en rapportage voor alle rollen en functies.
• Laatste laag (goud): De derde laag is gebouwd rond bedrijfs- of projectbehoeften. Het biedt een andere weergave als gegevensproducten voor andere bedrijfseenheden of projecten, het voorbereiden van gegevens rond beveiligingsbehoeften (zoals geanonimiseerde gegevens) of optimaliseren voor prestaties (zoals met vooraf geaggregeerde weergaven). De gegevensproducten in deze laag worden beschouwd als de waarheid voor het bedrijf.

De laatste laag mag alleen gegevens van hoge kwaliteit bevatten en volledig worden vertrouwd vanuit bedrijfsperspectief.

Gegevensintegriteit verbeteren door gegevensredundantie te verminderen

Als u gegevens kopieert of dupliceert, ontstaat gegevensredundantie en leidt dit tot verlies van integriteit, verlies van gegevensherkomst en vaak verschillende toegangsmachtigingen. Dit vermindert de kwaliteit van de gegevens in het lakehouse.

Een tijdelijke of wegwerpkopie van gegevens is op zichzelf niet schadelijk. Soms is het noodzakelijk om flexibiliteit, experimenten en innovatie te vergroten. Wanneer deze kopieën echter operationeel worden en regelmatig worden gebruikt om zakelijke beslissingen te nemen, worden ze gegevenssilo's. Wanneer deze gegevenssilo's niet synchroon worden, heeft dit een aanzienlijke negatieve invloed op de integriteit en kwaliteit van de gegevens, waardoor vragen worden gesteld zoals 'Welke gegevensset is de master?' of 'Is de gegevensset actueel?

Schema's actief beheren

Onbeheerde schemawijzigingen kunnen leiden tot ongeldige gegevens en mislukte taken die gebruikmaken van deze gegevenssets. Azure Databricks heeft verschillende methoden om het schema te valideren en af te dwingen:

• Delta Lake ondersteunt schemavalidatie en schema-afdwinging door schemavariaties automatisch af te handelen om te voorkomen dat slechte records worden ingevoegd tijdens opname. Zie Schema afdwingen.
• Auto Loader detecteert de toevoeging van nieuwe kolommen terwijl deze uw gegevens verwerkt. Standaard zorgt de toevoeging van een nieuwe kolom ervoor dat uw streams stoppen met een UnknownFieldException. Auto Loader ondersteunt verschillende modi voor de ontwikkeling van schema's.

Beperkingen en gegevens verwachtingen gebruiken

Delta-tabellen bieden ondersteuning voor standaard sql-beperkingsbeheercomponenten die ervoor zorgen dat de kwaliteit en integriteit van gegevens die aan een tabel worden toegevoegd, automatisch worden gecontroleerd. Wanneer een beperking wordt geschonden, genereert Delta Lake een InvariantViolationException foutmelding om aan te geven dat de nieuwe gegevens niet kunnen worden toegevoegd. Zie Beperkingen voor Azure Databricks.

Om deze verwerking verder te verbeteren, ondersteunt Delta Live Tables verwachtingen: Verwachtingen definiëren beperkingen voor gegevenskwaliteit voor de inhoud van een gegevensset. Een verwachting bestaat uit een beschrijving, een invariant en een actie die moet worden ondernomen als een record de invariant schendt. Verwachtingen voor query's maken gebruik van Python-decorators of SQL-beperkingsclausules. Zie Gegevenskwaliteit beheren met Delta Live Tables.

Een gegevensgerichte benadering gebruiken voor machine learning

Een leidraad die de kern van de AI-visie voor het Databricks Data Intelligence Platform blijft, is een gegevensgerichte benadering van machine learning. Naarmate generatieve AI vaker voorkomt, blijft dit perspectief net zo belangrijk.

De belangrijkste onderdelen van elk ML-project kunnen gewoon worden beschouwd als gegevenspijplijnen: Functie-engineering, training, modelimplementatie, deductie en bewakingspijplijnen zijn allemaal gegevenspijplijnen. Als zodanig vereist het operationeel maken van een ML-oplossing het samenvoegen van gegevens uit voorspellings-, bewakings- en functietabellen met andere relevante gegevens. De eenvoudigste manier om dit te bereiken is door AI-oplossingen te ontwikkelen op hetzelfde platform dat wordt gebruikt voor het beheren van productiegegevens. Gegevensgerichte MLOps en LLMOps bekijken

3. Ontwerpen voor automatisch schalen

Automatisch schalen inschakelen voor ETL-workloads

Met automatisch schalen kunnen clusters de grootte automatisch wijzigen op basis van workloads. Automatische schaalaanpassing kan profiteren van veel use cases en scenario's vanuit zowel kosten- als prestatieperspectief. De documentatie bevat overwegingen voor het bepalen of automatisch schalen moet worden gebruikt en hoe u het meeste voordeel krijgt.

Voor streamingworkloads raadt Databricks het gebruik van Delta Live Tables aan met automatische schaalaanpassing. Dankzij verbeterde automatische schaalaanpassing van Databricks wordt het clustergebruik geoptimaliseerd door clusterresources automatisch toe te wijzen op basis van het workloadvolume, met minimale gevolgen voor de latentie van gegevensverwerking van uw pijplijnen.

Automatisch schalen inschakelen voor SQL Warehouse

De schaalparameter van een SQL-warehouse stelt het minimum en het maximum aantal clusters in waarvoor query's die naar het magazijn worden verzonden, worden gedistribueerd. De standaardwaarde is één cluster zonder automatisch schalen.

Als u meer gelijktijdige gebruikers voor een bepaald magazijn wilt verwerken, verhoogt u het aantal clusters. Als u wilt weten hoe Azure Databricks clusters toevoegt aan en verwijdert uit een magazijn, raadpleegt u het gedrag voor het aanpassen, schalen en in de wachtrij plaatsen van SQL Warehouse.

4. Herstelprocedures testen

Herstellen van fouten met query's voor gestructureerd streamen

Structured Streaming biedt fouttolerantie en gegevensconsistentie voor streamingquery's. Met Databricks-taken kunt u eenvoudig uw Structured Streaming-query's configureren om automatisch opnieuw op te starten bij fouten. Door controlepunten voor een streamingquery in te schakelen, kunt u de query opnieuw starten na een fout. De opnieuw gestarte query wordt voortgezet vanaf waar de mislukte query is gebleven. Zie controlepunten en productieoverwegingen voor gestructureerd streamen voor gestructureerde streaming.

ETL-taken herstellen met behulp van mogelijkheden voor gegevenstijdreizen

Ondanks grondige tests kan een taak mislukken in productie of onverwachte, zelfs ongeldige gegevens produceren. Soms kan dit worden opgelost met een extra taak na het begrijpen van de oorzaak van het probleem en het oplossen van de pijplijn die het probleem in de eerste plaats heeft veroorzaakt. Dit is echter vaak niet eenvoudig en de betreffende taak moet worden teruggedraaid. Met Delta Time travel kunnen gebruikers eenvoudig wijzigingen terugdraaien naar een oudere versie of tijdstempel, de pijplijn herstellen en de vaste pijplijn opnieuw opstarten.

Een handige manier om dit te doen is de RESTORE opdracht.

Een jobautomatiseringsframework gebruiken met ingebouwd herstel

Databricks-taken zijn ontworpen voor herstel. Wanneer een taak in een taak met meerdere taken mislukt (en, als zodanig, alle afhankelijke taken), bieden Azure Databricks-taken een matrixweergave van de uitvoeringen waarmee u het probleem kunt onderzoeken dat de fout heeft veroorzaakt. Zie Weergaveuitvoeringen voor een taak. Of het nu gaat om een kort netwerkprobleem of een echt probleem in de gegevens, u kunt dit oplossen en een herstelbewerking starten in Azure Databricks Jobs. Hiermee worden alleen de mislukte en afhankelijke taken uitgevoerd en blijven de geslaagde resultaten van de eerdere uitvoering behouden, bespaart u tijd en geld, zie Problemen met taken oplossen en herstellen

Een herstelpatroon voor noodgevallen configureren

Voor een cloudeigen platform voor gegevensanalyse, zoals Azure Databricks, is een duidelijk patroon voor herstel na noodgevallen essentieel. Het is essentieel dat uw gegevensteams het Azure Databricks-platform kunnen gebruiken, zelfs in het zeldzame geval van een regionale, servicebrede storing van een cloudserviceprovider, ongeacht of dit wordt veroorzaakt door een regionale ramp, zoals een orkaan, aardbeving of een andere bron.

Azure Databricks is vaak een belangrijk onderdeel van een algemeen gegevensecosysteem dat veel services bevat, waaronder upstream-services voor gegevensopname (batch/streaming), cloudeigen opslag zoals Azure Data Lake Storage Gen2, downstreamhulpprogramma's en services zoals business intelligence-apps en indelingsprogramma's. Sommige van uw gebruiksscenario's zijn mogelijk bijzonder gevoelig voor een regionale servicebrede storing.

Herstel na noodgevallen omvat een reeks beleidsregels, hulpprogramma's en procedures die het herstel of de voortzetting van essentiële technologie-infrastructuur en -systemen mogelijk maken na een natuur- of door mensen geïnduceerde ramp. Een grote cloudservice zoals Azure dient veel klanten en heeft ingebouwde beveiligingen tegen één fout. Een regio is bijvoorbeeld een groep gebouwen die zijn verbonden met verschillende energiebronnen om ervoor te zorgen dat één stroomstoring geen regio uitvalt. Cloudregiofouten kunnen echter optreden en de ernst van de fout en de impact ervan op uw bedrijf kunnen variëren.

5. Implementaties en workloads automatiseren

Zie Operational Excellence - Implementaties en workloads automatiseren.

6. Systemen en workloads bewaken

Zie Operational Excellence: bewaking, waarschuwingen en logboekregistratie instellen.