Best practices voor prestatie-efficiëntie

In dit artikel worden aanbevolen procedures voor prestatie-efficiëntie beschreven, georganiseerd op basis van architectuurprincipes die in de volgende secties worden vermeld.

1. Verticaal schalen, horizontaal schalen en lineaire schaalbaarheid

Voordat we aan de slag gaan met de aanbevolen procedures, gaan we eens kijken naar een aantal gedistribueerde computingconcepten: horizontaal schalen, verticaal schalen en lineaire schaalbaarheid.

• Verticaal schalen: schaal verticaal door resources toe te voegen aan of te verwijderen van één computer, meestal CPU's, geheugen of GPU's. Dit betekent meestal dat de werkbelasting wordt gestopt, naar een grotere machine wordt verplaatst en opnieuw wordt opgestart. Er gelden limieten voor verticale schaalaanpassing: er is mogelijk geen grotere machine of de prijs van de volgende grotere machine kan verbieden.
• Horizontaal schalen: schaal horizontaal door knooppunten toe te voegen aan of te verwijderen uit een gedistribueerd systeem. Wanneer de limieten voor verticaal schalen worden bereikt, is de oplossing horizontaal te schalen: Gedistribueerde computing maakt gebruik van systemen met meerdere computers ( clusters genoemd) om workloads uit te voeren. Het is belangrijk om te begrijpen dat de workloads voor dit mogelijk zijn, moeten worden voorbereid op parallelle uitvoering, zoals ondersteund door de engines van het Databricks Data Intelligence Platform, Apache Spark en Photon. Hierdoor kunnen meerdere goedkope machines worden gecombineerd tot een groter computersysteem. Wanneer er meer rekenresources nodig zijn, voegt horizontaal schalen meer knooppunten toe aan het cluster en worden ze verwijderd wanneer ze niet meer nodig zijn. Hoewel er technisch gezien geen limiet is (en de Spark-engine het complexe onderdeel van taakverdeling doet), verhogen grote aantallen knooppunten de beheercomplexiteit.
• Lineaire schaalbaarheid, wat betekent dat wanneer u meer resources toevoegt aan een systeem, de relatie tussen doorvoer en resources die worden gebruikt lineair is. Dit is alleen mogelijk als de parallelle taken onafhankelijk zijn. Zo niet, dan zijn tussenliggende resultaten op één set knooppunten nodig op een andere set knooppunten in het cluster voor verdere berekening. Deze gegevensuitwisseling tussen knooppunten omvat het transporteren van de resultaten via het netwerk van de ene set knooppunten naar een andere set knooppunten, wat veel tijd kost. Over het algemeen heeft gedistribueerde computing enige overhead voor het beheren van de distributie en uitwisseling van gegevens. Als gevolg hiervan kunnen kleine gegevenssetworkloads die op één knooppunt kunnen worden geanalyseerd, nog trager zijn wanneer ze worden uitgevoerd op een gedistribueerd systeem. Het Databricks Data Intelligence Platform biedt flexibele computing (één knooppunt en gedistribueerd) om te voldoen aan de unieke behoeften van uw workloads.

2. Serverloze architecturen gebruiken

Serverloze rekenkracht gebruiken

Met serverloze rekenkracht op het Databricks Data Intelligence Platform wordt de rekenlaag uitgevoerd in het Azure Databricks-account van de klant. De services worden volledig beheerd en continu verbeterd door Databricks. Naast klanten die alleen betalen voor wat ze gebruiken, resulteert dit in een verbeterde productiviteit:

• Cloudbeheerders hoeven geen complexe cloudomgevingen meer te beheren, zoals het aanpassen van quota, het maken en onderhouden van netwerkresources en het maken en onderhouden van verbinding met factureringsbronnen. Ze kunnen hun tijd richten op projecten met een hogere waarde in plaats van cloudonderdelen op laag niveau te beheren.
• Gebruikers profiteren van bijna nul opstartlatentie van clusters en verbeterde gelijktijdigheid van query's.

Databricks biedt beheerde services voor verschillende workloads:

• Serverloze SQL-warehouses voor SQL-workloads

  Werkruimtebeheerders kunnen serverloze SQL-warehouses maken die direct rekenproces mogelijk maken en worden beheerd door Databricks. Gebruik ze met Databricks SQL-query's, net zoals bij de oorspronkelijke Databricks SQL-warehouses. Serverloze compute wordt geleverd met een zeer snelle opstarttijd voor SQL-warehouses en de infrastructuur wordt beheerd en geoptimaliseerd door Databricks.

• Serverloze taken voor efficiënte en betrouwbare werkstromen

  Met serverloze berekening voor taken kunt u uw Databricks-taak uitvoeren zonder infrastructuur te configureren en te implementeren. Met serverloze berekeningen richt u zich op het implementeren van uw pijplijnen voor gegevensverwerking en analyse, en Databricks beheert efficiënt rekenresources, waaronder het optimaliseren en schalen van rekenkracht voor uw workloads. Automatisch schalen en Photon worden automatisch ingeschakeld voor de rekenresources die uw taak uitvoeren.

  U kunt de kosten bewaken van taken die gebruikmaken van serverloze berekeningen voor taken door een query uit te voeren op de factureerbare gebruikssysteemtabel .

• Serverloze rekenkracht voor notebooks

  Als uw werkruimte is ingeschakeld voor serverloze interactieve berekeningen, hebben alle gebruikers in de werkruimte toegang tot serverloze berekeningen voor notebooks. Er zijn geen extra machtigingen vereist.

Een service op bedrijfsniveaumodel gebruiken

Mosaic AI Model Serving biedt een uniforme interface voor het implementeren, beheren en opvragen van AI-modellen. Elk model dat u gebruikt, is beschikbaar als een REST API die u kunt integreren in uw web- of clienttoepassing.

Modelservice biedt een service met hoge beschikbaarheid en lage latentie voor het implementeren van modellen. De service wordt automatisch omhoog of omlaag geschaald om te voldoen aan de vraagwijzigingen, waardoor de infrastructuurkosten worden bespaard terwijl de latentieprestaties worden geoptimaliseerd. Deze functionaliteit maakt gebruik van serverloze berekeningen.

3. Werkbelastingen ontwerpen voor prestaties

Inzicht krijgen in uw gegevensopname- en toegangspatronen

Vanuit prestatieperspectief gedragen gegevenstoegangspatronen, zoals 'aggregaties versus punttoegang' of 'scannen versus zoeken', zich anders, afhankelijk van de gegevensgrootte. Grote bestanden zijn efficiënter voor scanquery's en kleinere bestanden zijn beter voor zoekopdrachten, omdat u minder gegevens moet lezen om de specifieke rijen te vinden.

Voor opnamepatronen is het gebruikelijk om DML-instructies te gebruiken. DML-instructies zijn het meest presterend wanneer de gegevens zijn geclusterd en u kunt gewoon de sectie met gegevens isoleren. Het is belangrijk om de gegevens geclusterd en afolatabel te houden tijdens opname: overweeg om een natuurlijke sorteervolgorde te behouden en zoveel mogelijk filters toe te passen op de doeltabel voor opname. Voor toevoeg- en overschrijfworkloads is er niet veel om rekening mee te houden omdat dit een relatief goedkope bewerking is.

De opname- en toegangspatronen wijzen vaak op een duidelijke gegevensindeling en clustering. Als dat niet het geval is, bepaalt u wat belangrijker is voor uw bedrijf en richt u zich op hoe u dat doel beter kunt bereiken.

Parallelle berekeningen gebruiken waar het nuttig is

Tijd tot waarde is een belangrijke dimensie bij het werken met gegevens. Hoewel veel gebruiksvoorbeelden eenvoudig kunnen worden geïmplementeerd op één computer (kleine gegevens, weinig en eenvoudige rekenstappen), zijn er vaak gebruiksvoorbeelden die grote gegevenssets moeten verwerken, lange uitvoeringstijden moeten hebben vanwege gecompliceerde algoritmen of moeten worden herhaald van 100 en 1000 keer.

De clusteromgeving van het Databricks-platform is een uitstekende omgeving voor het efficiënt distribueren van deze workloads. Sql-query's worden automatisch parallelliseert op alle knooppunten van een cluster en biedt bibliotheken voor Python en Scala om hetzelfde te doen. Onder de schermen analyseren de Engines Apache Spark- en Photon-engines de query's, bepalen de optimale manier van parallelle uitvoering en beheren ze de gedistribueerde uitvoering op een flexibele manier.

Op dezelfde manier als batchtaken distribueert Structured Streaming streamingtaken over het cluster voor de beste prestaties.

Een van de eenvoudigste manieren om parallelle computing te gebruiken, is met Delta Live Tables. U declareert de taken en afhankelijkheden van een taak in SQL of Python en vervolgens verwerkt Delta Live Tables de uitvoeringsplanning, efficiënte infrastructuurinstallatie, taakuitvoering en bewaking.

Voor gegevenswetenschappers is Pandas een Python-pakket dat gebruiksvriendelijke gegevensstructuren en hulpprogramma's voor gegevensanalyse biedt voor de programmeertaal Python. Pandas schaalt echter niet uit naar big data. De Pandas-API in Spark vult deze kloof door pandas-equivalente API's te bieden die op Apache Spark werken.

Daarnaast wordt het platform geleverd met geparallelliseerde machine learning-algoritmen in de standaard machine learning-bibliotheek MLlib. Het ondersteunt out-of-the-box multi-GPU-gebruik. Deep Learning kan ook worden geparallelliseerd met behulp van DeepSpeed Distributor of TorchDistributor.

De hele uitvoeringsketen analyseren

De meeste pijplijnen of verbruikspatronen hebben betrekking op een keten van systemen. Met BI-hulpprogramma's wordt de prestaties bijvoorbeeld beïnvloed door verschillende factoren:

• Het BI-hulpprogramma zelf.
• De connector die het BI-hulpprogramma en de SQL-engine verbindt.
• De SQL-engine waarnaar het BI-hulpprogramma de query verzendt.

Voor de beste prestaties moet de hele keten worden overwogen en geselecteerd/afgestemd op de beste prestaties.

Liever grotere clusters

Plan grotere clusters, met name als de werkbelasting lineair wordt geschaald. In dit geval is het gebruik van een groot cluster voor een workload niet duurder dan het gebruik van een kleiner cluster. Het is gewoon sneller. De sleutel is dat u het cluster huurt voor de duur van de workload. Dus als u twee werkclusters maakt en het een uur duurt, betaalt u voor deze werknemers voor het volledige uur. Als u een vier werkrolcluster maakt en dit slechts een half uur duurt (dit is waar lineaire schaalbaarheid binnenkomt), zijn de kosten hetzelfde. Als de kosten het primaire stuurprogramma zijn met een zeer flexibele SLA, is een cluster voor automatisch schalen meestal de goedkoopste, maar niet noodzakelijkerwijs de snelste.

Notitie

Het voorkeur geven aan grote clusters is niet vereist voor serverloze berekeningen, omdat clusters automatisch worden beheerd.

Systeemeigen Spark-bewerkingen gebruiken

Door de gebruiker gedefinieerde functies (UDF's) zijn een uitstekende manier om de functionaliteit van Spark SQL uit te breiden. Gebruik echter geen Python- of Scala UDF's als er een systeemeigen functie bestaat:

• Spark SQL
• PySpark

Redenen:

• Serialisatie is vereist om gegevens over te dragen tussen Python en Spark. Hierdoor worden query's aanzienlijk vertraagd.
• Verbeterde inspanningen om functionaliteit te implementeren en te testen die al bestaat in het platform.

Als systeemeigen functies ontbreken en als Python UDF's moeten worden geïmplementeerd, gebruikt u Pandas UDF's. Apache Arrow zorgt ervoor dat gegevens efficiënt heen en weer worden verplaatst tussen Spark en Python.

Systeemeigen platformen gebruiken

Photon is de engine in Azure Databricks die snelle queryprestaties tegen lage kosten biedt, van gegevensopname, ETL, streaming, gegevenswetenschap en interactieve query's, rechtstreeks op uw data lake. Photon is compatibel met Apache Spark-API's, dus aan de slag is net zo eenvoudig als het inschakelen ervan: geen codewijzigingen en geen vergrendeling.

Photon maakt deel uit van een runtime met hoge prestaties waarmee uw bestaande SQL- en DataFrame-API-aanroepen sneller worden uitgevoerd, waardoor de totale kosten per workload worden verminderd. Photon wordt standaard gebruikt in Databricks SQL-warehouses.

Inzicht in uw hardware- en workloadtype

Niet alle cloud-VM's worden gelijk gemaakt. De verschillende families van machines die door cloudproviders worden aangeboden, zijn allemaal verschillend genoeg om van belang te zijn. Er zijn duidelijke verschillen - RAM en kernen - en subtielere verschillen - processortype en -generatie, garanties voor netwerkbandbreedte en lokale opslag met hoge snelheid versus lokale schijf versus externe schijf. Er zijn ook verschillen in de "spot"-markten. Deze moeten worden begrepen voordat u beslist over het beste VM-type voor uw workload.

Notitie

Dit is niet vereist voor serverloze berekeningen, omdat serverloze berekeningen automatisch clusters beheren.

Caching gebruiken

In cache worden vaak gebruikte gegevens op een sneller medium opgeslagen, waardoor de tijd die nodig is om deze op te halen in vergelijking met toegang tot de oorspronkelijke gegevensbron verkort. Dit resulteert in lagere latentie en snellere reactietijden, waardoor de algehele prestaties en gebruikerservaring van een toepassing aanzienlijk kunnen worden verbeterd. Door het aantal aanvragen naar de oorspronkelijke gegevensbron te minimaliseren, helpt caching het netwerkverkeer en de kosten voor gegevensoverdracht te verminderen. Deze efficiëntiewinst kan met name nuttig zijn voor toepassingen die afhankelijk zijn van externe API's of databases met betalen per gebruik. Het kan helpen de belasting gelijkmatiger over het systeem te verdelen, waardoor knelpunten en potentiële downtime worden voorkomen.

Er zijn verschillende soorten caching beschikbaar in Azure Databricks. Dit zijn de kenmerken van elk type:

• Schijfcache gebruiken

  In de schijfcache (voorheen bekend als 'Delta-cache') worden kopieën van externe gegevens opgeslagen op de lokale schijven (bijvoorbeeld SSD) van de virtuele machines. Het kan de prestaties voor een breed scala aan query's verbeteren, maar kan niet worden gebruikt om de resultaten van willekeurige subquery's op te slaan. De schijfcache detecteert automatisch wanneer gegevensbestanden worden gemaakt of verwijderd en werkt de inhoud dienovereenkomstig bij. De aanbevolen (en eenvoudigste) manier om schijfcaching te gebruiken, is door bij het configureren van uw cluster een werkroltype met SSD-volumes te kiezen. Dergelijke werkrollen zijn ingeschakeld en geconfigureerd voor schijfcaching.

• Spark-caching voorkomen

  De Spark-cache (met behulp .persist() en .unpersist()) kan het resultaat opslaan van subquerygegevens en -gegevens die zijn opgeslagen in andere indelingen dan Parquet (zoals CSV, JSON en ORC). Als u echter op de verkeerde locaties in een query wordt gebruikt, kan het al het geheugen verbruiken en zelfs query's aanzienlijk vertragen. Vermijd spark-caching als vuistregel, tenzij u precies weet wat de impact is.

• Queryresultatencache

  Per clustercache van queryresultaten voor alle query's via SQL-warehouses. Als u wilt profiteren van het opslaan van queryresultaten, richt u zich op deterministische query's die bijvoorbeeld geen predicaten gebruiken, zoals = NOW(). Wanneer een query deterministisch is en de onderliggende gegevens een Delta-indeling hebben en ongewijzigd zijn, retourneert SQL Warehouses het resultaat rechtstreeks vanuit de cache met queryresultaten.

• Databricks SQL-gebruikersinterface opslaan in cache

  In cache opslaan per gebruiker van alle query- en verouderde dashboardresultaten resulteert in de Databricks SQL-gebruikersinterface.

Compressie gebruiken

Delta Lake in Azure Databricks kan de snelheid van het lezen van query's uit een tabel verbeteren. Een manier is om kleine bestanden samen te zetten in grotere bestanden. U activeert compressie door de opdracht OPTIMIZE uit te voeren. Zie De indeling van het gegevensbestand optimaliseren.

Delta Lake biedt opties voor het automatisch configureren van de doelbestandsgrootte voor schrijfbewerkingen en voor OPTIMIZE bewerkingen. Databricks tunest automatisch veel van deze instellingen en maakt functies mogelijk die de prestaties van tabellen automatisch verbeteren door te zoeken naar bestanden met de juiste grootte:

• Automatisch comprimeren combineert kleine bestanden in Delta-tabelpartities om kleine bestandsproblemen automatisch te verminderen. Automatische compressie vindt plaats nadat een schrijfbewerking naar een tabel is geslaagd en synchroon wordt uitgevoerd op het cluster dat de schrijfbewerking heeft uitgevoerd. Met automatisch comprimeren worden alleen bestanden gecomprimeerd die nog niet eerder zijn gecomprimeerd.
• Geoptimaliseerde schrijfbewerkingen verbeteren de bestandsgrootte wanneer gegevens worden geschreven en profiteren van latere leesbewerkingen in de tabel. Geoptimaliseerde schrijfbewerkingen zijn het meest effectief voor gepartitioneerde tabellen, omdat ze het aantal kleine bestanden verminderen dat naar elke partitie wordt geschreven.

Zie Delta Lake configureren voor het beheren van de bestandsgrootte voor meer informatie.

Gegevens overslaan gebruiken

Het overslaan van gegevens kan de queryprestaties aanzienlijk verbeteren door gegevens over te slaan die niet voldoen aan de querycriteria. Dit vermindert de hoeveelheid gegevens die moeten worden gelezen en verwerkt, wat leidt tot snellere uitvoeringstijden van query's.

Hiervoor worden gegevens die worden overgeslagen automatisch verzameld wanneer u gegevens naar een Delta-tabel schrijft (standaard verzamelt Delta Lake in Azure Databricks statistieken over de eerste 32 kolommen die zijn gedefinieerd in uw tabelschema). Delta Lake in Azure Databricks gebruikt deze informatie (minimum- en maximumwaarden) op het moment van query's om snellere query's te bieden. Zie Gegevens overslaan voor Delta Lake.

De volgende technieken kunnen worden toegepast voor het overslaan van gegevens:

• Z-ordering, een techniek voor het collocateren van gerelateerde informatie in dezelfde set bestanden. Deze co-locatie wordt automatisch gebruikt in Azure Databricks door Delta Lake-algoritmen voor het overslaan van gegevens. Dit gedrag vermindert de hoeveelheid gegevens die Delta Lake moet lezen aanzienlijk.

• Liquid-clustering vereenvoudigt beslissingen over de gegevensindeling en optimaliseert de queryprestaties. Het vervangt partitionering en z-volgorde in de loop van de tijd. Databricks raadt vloeibare clustering aan voor alle nieuwe deltatabellen. Liquid clustering biedt de flexibiliteit om clustersleutels opnieuw te definiëren zonder bestaande gegevens te herschrijven, zodat gegevensindelingen zich in de loop van de tijd kunnen ontwikkelen met analytische behoeften. Databricks raadt vloeibare clustering aan voor alle nieuwe deltatabellen.

  Tabellen met de volgende kenmerken profiteren van vloeistofclustering:

  • Gefilterd op kolommen met een hoge kardinaliteit.
  • Met aanzienlijk scheve gegevensdistributie.
  • Dat groeit snel en vereist onderhoud en afstemming.
  • Met gelijktijdige schrijfaanvragen.
  • Met toegangspatronen die na verloop van tijd veranderen.
  • Waarbij een typische partitiesleutel de tabel met te veel of te weinig partities kan verlaten.

Zie de uitgebreide handleiding voor het optimaliseren van Databricks-, Spark- en Delta Lake-workloads voor meer informatie en technieken.

Voorspellende optimalisatie inschakelen voor Delta Lake

Met voorspellende optimalisatie hoeft u geen onderhoudsbewerkingen voor Delta-tabellen in Databricks handmatig te beheren. Als voorspellende optimalisatie is ingeschakeld, identificeert Databricks automatisch tabellen die baat hebben bij onderhoudsbewerkingen en voert ze uit voor de gebruiker. Onderhoudsbewerkingen worden alleen uitgevoerd als dat nodig is, waardoor zowel onnodige uitvoeringen voor onderhoudsbewerkingen als de last van het bijhouden en oplossen van problemen worden voorkomen.

Overpartitionering voorkomen

In het verleden was partitioneren de meest voorkomende manier om gegevens over te slaan. Partitionering is echter statisch en manifesteert zichzelf als een bestandssysteemhiërarchie. Er is geen eenvoudige manier om partities te wijzigen naarmate de toegangspatronen na verloop van tijd veranderen. Partitionering leidt vaak tot overpartitionering, met andere woorden te veel partities met te kleine bestanden, wat resulteert in slechte queryprestaties.

Databricks raadt u aan geen tabellen onder de 1 TB te partitioneren en dat u alleen partitioneert op basis van een kolom als u verwacht dat de gegevens in elke partitie ten minste 1 GB zijn.

Ondertussen is een betere keuze dan partitioneren Z-ordering of de nieuwere Liquid Clustering (zie hierboven).

Joinprestaties optimaliseren

• Overweeg optimalisatie van bereikdeelname.

  Een bereikdeelname vindt plaats wanneer twee relaties worden samengevoegd met behulp van een interval of intervalover overlapvoorwaarde. De ondersteuning voor optimalisatie van bereikdeelnames in Databricks Runtime kan leiden tot een verbetering van de grootte in queryprestaties, maar vereist zorgvuldige afstemming.

• Adaptieve queryuitvoering gebruiken.

  Adaptieve queryuitvoering (AQE) is heroptimalisatie van query's die wordt gedaan tijdens het uitvoeren van query's. Het heeft vier belangrijke functies:

  • Hiermee wijzigt u de samenvoegbewerking dynamisch in broadcast-hash-join.
  • Worden partities dynamisch samengemeld na een willekeurige uitwisseling.
  • Verwerkt dynamisch scheefheid in sort merge join en shuffle hash join.
  • Automatisch worden lege relaties gedetecteerd en doorgegeven.

  Het wordt aanbevolen om AQE ingeschakeld te houden. Verschillende functies kunnen afzonderlijk worden geconfigureerd.

Zie de uitgebreide handleiding voor het optimaliseren van Databricks-, Spark- en Delta Lake-workloads voor meer informatie.

Tabel analyseren uitvoeren om tabelstatistieken te verzamelen

De ANALYZE TABLE instructie verzamelt statistieken over tabellen in een opgegeven schema. Deze statistieken worden door de queryoptimalisatie gebruikt om een optimaal queryplan te genereren, het juiste jointype te selecteren, de juiste buildzijde te selecteren in een hash-join of de joinvolgorde in een multi-way join te kalibreren.

Voorspellende optimalisatie voert automatisch de opdracht ANALYZE (openbare preview) uit, een opdracht voor het verzamelen van statistieken op tabellen beheerd door Unity Catalog. Databricks raadt aan voorspellende optimalisatie in te schakelen voor alle beheerde tabellen in Unity Catalog om het onderhoud van gegevens te vereenvoudigen en de opslagkosten te verlagen. Zie Voorspellende optimalisatie voor beheerde tabellen van Unity Catalog.

4. Prestatietests uitvoeren in het bereik van de ontwikkeling

Testen op gegevens die representatief zijn voor productiegegevens

Voer prestatietests uit op productiegegevens (alleen-lezen) of vergelijkbare gegevens. Wanneer u vergelijkbare gegevens gebruikt, moeten kenmerken zoals volume, bestandsindeling en scheeftrekken van gegevens vergelijkbaar zijn met de productiegegevens, omdat dit een aanzienlijke invloed heeft op de prestaties.

Overweeg resources vooraf tewarmen

Ongeacht de query- en gegevensindeling is de eerste query in een cluster altijd langzamer dan volgende query's. Dit komt doordat alle verschillende subsystemen beginnen en alle benodigde gegevens lezen. Het voorafwarmen heeft een aanzienlijke invloed op de resultaten van de prestatietest:

• Voorafwarmclusters: clusterbronnen moeten worden geïnitialiseerd op meerdere lagen. Het is mogelijk om clusters vooraf tewarmen: Databricks-pools zijn een set niet-actieve, kant-en-klare exemplaren. Wanneer clusterknooppunten worden gemaakt met behulp van deze niet-actieve exemplaren, worden opstart- en automatische schaalaanpassingstijden van het cluster verminderd.
• Prewarm-caches: wanneer caching deel uitmaakt van de installatie, zorgt de eerste uitvoering ervoor dat de gegevens zich in de cache bevinden, waardoor volgende taken sneller worden uitgevoerd. Caches kunnen vooraf worden opgewarmd door specifieke query's uit te voeren om caches te initialiseren (bijvoorbeeld nadat een cluster opnieuw is opgestart). Dit kan de prestaties van de eerste paar query's aanzienlijk verbeteren.

Als u het gedrag voor de verschillende scenario's wilt begrijpen, test u de prestaties van de eerste uitvoering met en zonder voorafgaande en latere uitvoeringen.

Knelpunten identificeren

Knelpunten zijn gebieden in uw workload die de algehele prestaties kunnen verminderen naarmate de belasting toeneemt in de productie. Als u deze tijdens het ontwerp identificeert en test op basis van hogere workloads, kunt u de workloads stabiel houden in de productieomgeving.

5. Prestaties bewaken

Queryprestaties bewaken

Het bewaken van queryprestaties helpt u inzicht te krijgen in de manier waarop resources worden gebruikt door verschillende query's. U kunt query's identificeren die langzaam worden uitgevoerd, zodat u prestatieknelpunten in uw systeem kunt opsporen. U kunt ook query's identificeren die aanzienlijke systeembronnen verbruiken, wat kan leiden tot instabiliteit of downtime. Met deze informatie kunt u resourcetoewijzing optimaliseren, verspilling verminderen en ervoor zorgen dat resources efficiënt worden gebruikt.

Het Databricks Data Intelligence Platform heeft verschillende bewakingsmogelijkheden (zie Operational Excellence - Bewaking, waarschuwingen en logboekregistratie instellen), waarvan sommige kunnen worden gebruikt voor prestatiebewaking:

• Queryprofiel: gebruik de functie queryprofiel om prestatieknelpunten op te lossen tijdens het uitvoeren van query's. Het biedt visualisatie van elke querytaak en gerelateerde metrische gegevens, zoals de tijd die is besteed, het aantal verwerkte rijen en het gebruikte geheugen.
• SQL Warehouse-bewaking: SQL-magazijnen bewaken door livestatistieken weer te geven, grafieken met piekquery's, grafieken met clusters uit te voeren en tabel met querygeschiedenis

Streamingworkloads bewaken

Met streamingbewaking kunt u gegevens analyseren en problemen detecteren wanneer ze optreden, zodat u realtime inzicht krijgt in de prestaties en het gedrag van uw systeem. Door streaminggegevens te analyseren, kunt u trends, patronen en mogelijkheden voor optimalisatie identificeren. Dit kan u helpen uw systeem af te stemmen, het resourcegebruik te verbeteren en de kosten te verlagen.

Voor streamingquery's gebruikt u de ingebouwde structured streaming-bewaking in de Spark-gebruikersinterface of pusht u metrische gegevens naar externe services met behulp van de interface van de Apache Spark Streaming Query Listener-interface.

Taakprestaties bewaken

Met taakbewaking kunt u problemen in uw Databricks-taken identificeren en oplossen, zoals fouten, vertragingen of prestatieknelpunten. Taakbewaking biedt inzicht in de prestaties van taken, zodat u het resourcegebruik kunt optimaliseren, de verspilling kunt verminderen en de algehele efficiëntie kunt verbeteren.