Best practices voor kostenoptimalisatie

In dit artikel worden aanbevolen procedures beschreven voor het ondersteunen van principes van kostenoptimalisatie, georganiseerd op principe.

1. Kies optimale resources

Geoptimaliseerde gegevensindelingen voor prestaties gebruiken

Als u optimaal gebruik wilt maken van het Databricks Data Intelligence Platform, moet u Delta Lake gebruiken als uw opslagframework. Het helpt bij het bouwen van eenvoudigere en betrouwbaardere ETL-pijplijnen en wordt geleverd met veel prestatieverbeteringen waarmee workloads aanzienlijk kunnen worden versneld vergeleken met het gebruik van Parquet, ORC en JSON. Bekijk aanbevelingen voor optimalisatie in Azure Databricks. Als de workload ook wordt uitgevoerd op een taakrekenproces, wordt dit rechtstreeks omgezet in een kortere uptime van rekenresources, wat leidt tot lagere kosten.

Taak berekenen gebruiken

Een taak is een manier om niet-interactieve code uit te voeren op een Databricks-rekenproces. U kunt bijvoorbeeld een ETL-workload (Extract, Transform en Load) interactief of volgens planning uitvoeren. Natuurlijk kunt u taken ook interactief uitvoeren in de gebruikersinterface van het notebook. Bij het berekenen van taken kosten de niet-interactieve workloads echter aanzienlijk minder dan op alle rekendoeleinden. Zie het prijsoverzicht om Jobs Compute en All-Purpose Compute te vergelijken.

Een extra voordeel voor sommige taken is dat elke taak of werkstroom kan worden uitgevoerd op een nieuw rekenproces, waardoor workloads van elkaar worden geïsoleerd. Multitask-werkstromen kunnen echter ook rekenresources voor alle taken opnieuw gebruiken, zodat de opstarttijd van de rekenkracht slechts eenmaal per werkstroom plaatsvindt. Zie Rekenproces configureren voor taken.

SQL Warehouse gebruiken voor SQL-workloads

Voor interactieve SQL-workloads is een Databricks SQL Warehouse de meest rendabele engine. Bekijk het prijsoverzicht. Alle SQL-magazijnen worden standaard geleverd met Photon, waardoor uw bestaande SQL- en DataFrame-API-aanroepen worden versneld en de totale kosten per workload worden verlaagd.

Bovendien bieden serverloze SQL-warehouses ondersteuning voor intelligent workloadbeheer (IWM), een set functies die de serverloze mogelijkheden van Databricks SQL verbeteren om snel en rendabel grote aantallen query's te verwerken.

Up-to-date runtimes gebruiken voor uw workloads

Het Azure Databricks-platform biedt verschillende runtimes die zijn geoptimaliseerd voor data engineering-taken (Databricks Runtime) of machine learning-taken (Databricks Runtime voor Machine Learning). De runtimes zijn gebouwd om de beste selectie van bibliotheken voor de taken te bieden en ervoor te zorgen dat alle geleverde bibliotheken up-to-date zijn en optimaal samenwerken. De Databricks Runtimes worden regelmatig uitgebracht en bieden prestatieverbeteringen tussen belangrijke releases. Deze prestatieverbeteringen leiden vaak tot kostenbesparingen als gevolg van efficiënter gebruik van rekenresources.

Alleen GPU's gebruiken voor de juiste workloads

Virtuele machines met GPU's kunnen berekeningen voor Deep Learning aanzienlijk versnellen, maar zijn aanzienlijk duurder dan alleen-CPU-machines. Gebruik ALLEEN GPU-exemplaren voor workloads met gpu-versnelde bibliotheken.

De meeste workloads maken geen gebruik van gpu-versnelde bibliotheken, dus ze profiteren niet van instanties met GPU-functionaliteit. Werkruimtebeheerders kunnen GPU-machines en rekenresources beperken om onnodig gebruik te voorkomen. Zie het blogbericht 'Zijn GPU's echt duur? Benchmarking GPU's voor deductie op Databricks-clusters.'

Serverloze services gebruiken voor uw workloads

BI-gebruiksvoorbeelden

BI-workloads verbruiken doorgaans gegevens in bursts en genereren meerdere gelijktijdige query's. Iemand die een BI-hulpprogramma gebruikt, kan bijvoorbeeld een dashboard bijwerken of een query schrijven en vervolgens de resultaten analyseren zonder verdere interactie met het platform. In dit scenario is het gegevensplatform:

• Beëindigt niet-actieve rekenresources om kosten te besparen.
• Biedt snel de rekenresources wanneer de gebruiker nieuwe of bijgewerkte gegevens aanvraagt met het BI-hulpprogramma.

Niet-serverloze Azure Databricks SQL-warehouses hebben een opstarttijd van minuten, dus veel gebruikers accepteren de hogere kosten en beëindigen ze niet tijdens niet-actieve perioden. Aan de andere kant worden serverloze SQL-warehouses binnen enkele seconden gestart en opgeschaald, zodat zowel directe beschikbaarheid als niet-actieve beëindiging kunnen worden bereikt. Dit resulteert in een geweldige gebruikerservaring en totale kostenbesparingen.

Bovendien worden serverloze SQL-warehouses eerder dan niet-serverloze magazijnen omlaag geschaald, wat weer resulteert in lagere kosten.

ML- en AI-model die worden geleverd

De meeste modellen worden geleverd als een REST API voor integratie in uw web- of clienttoepassing; de service voor het model ontvangt in de loop van de tijd verschillende hoeveelheden aanvragen en een modelserviceplatform moet altijd voldoende resources bieden, maar slechts zo veel als nodig is (upscaling en downscaling).

Mozaïek AI Model Serving maakt gebruik van serverloze berekeningen en biedt een maximaal beschikbare en lage latentieservice voor het implementeren van modellen. De service wordt automatisch omhoog of omlaag geschaald om te voldoen aan wijzigingen in de vraag, waardoor de infrastructuurkosten worden verlaagd terwijl de latentieprestaties worden geoptimaliseerd.

Het juiste exemplaartype gebruiken

Het gebruik van de nieuwste generatie cloudexemplaren biedt bijna altijd prestatievoordelen, omdat ze de beste prestaties en de nieuwste functies bieden.

Op basis van uw workloads is het ook belangrijk om de juiste instantiefamilie te kiezen om de beste prestatie-/prijsverhouding te krijgen. Enkele eenvoudige vuistregels zijn:

• Geoptimaliseerd geheugen voor ML, zware shuffle en overloopworkloads
• Berekening die is geoptimaliseerd voor gestructureerde streamingworkloads en onderhoudstaken (zoals optimaliseren en vacuüm)
• Opslag geoptimaliseerd voor workloads die profiteren van caching, zoals ad-hoc en interactieve gegevensanalyse
• GPU geoptimaliseerd voor specifieke ML- en DL-workloads
• Algemeen gebruik bij afwezigheid van specifieke vereisten

De meest efficiënte rekenkracht kiezen

Azure Databricks voert één uitvoerder per werkknooppunt uit. Daarom worden de termen uitvoerder en werker door elkaar gebruikt in de context van de Azure Databricks-architectuur. Clustergrootte wordt vaak in termen van het aantal werknemers gehouden, maar er zijn andere belangrijke factoren om rekening mee te houden:

• Totaal aantal uitvoerkernen (compute): het totale aantal kernen voor alle uitvoerders. Hiermee bepaalt u de maximale parallelle uitvoering van een rekenproces.
• Totaal geheugen voor uitvoerders: de totale hoeveelheid RAM-geheugen voor alle uitvoerders. Hiermee bepaalt u hoeveel gegevens in het geheugen kunnen worden opgeslagen voordat deze naar de schijf worden overgeslagen.
• Lokale opslag van uitvoerprogramma: het type en de hoeveelheid lokale schijfopslag. Lokale schijf wordt voornamelijk gebruikt in het geval van overloop tijdens willekeurige volgordes en caching.

Aanvullende overwegingen zijn onder andere het type werkexemplaren en de grootte, die ook van invloed zijn op de voorgaande factoren. Houd rekening met het volgende bij het aanpassen van de grootte van uw rekenproces:

• Hoeveel gegevens verbruikt uw workload?
• Wat is de rekenkundige complexiteit van uw workload?
• Waar leest u gegevens vandaan?
• Hoe worden de gegevens gepartitioneerd in externe opslag?
• Hoeveel parallelle uitvoering hebt u nodig?

Details en voorbeelden vindt u onder Overwegingen voor rekengrootte.

Query-engines evalueren die zijn geoptimaliseerd voor prestaties

Photon is een krachtige Databricks-systeemeigen vectorische query-engine waarmee uw SQL-workloads en DataFrame-API-aanroepen worden versneld (voor gegevensopname, ETL, streaming, gegevenswetenschap en interactieve query's). 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.

De waargenomen versnelling kan leiden tot aanzienlijke kostenbesparingen en taken die regelmatig worden uitgevoerd, moeten worden geëvalueerd om te zien of ze niet alleen sneller, maar ook goedkoper zijn met Photon.

2. Resources dynamisch toewijzen

Berekeningen automatisch schalen gebruiken

Met automatisch schalen worden werknemers dynamisch in Databricks verplaatst om rekening te houden met de kenmerken van uw taak. Bepaalde onderdelen van uw pijplijn zijn mogelijk rekenintensiefer dan andere onderdelen en Databricks voegt automatisch extra werkrollen toe tijdens deze fasen van uw taak (en verwijdert ze wanneer ze niet meer nodig zijn). Automatisch schalen kan de totale kosten verlagen ten opzichte van een rekenproces met een statisch formaat.

Automatisch schalen van rekenkracht heeft beperkingen bij het omlaag schalen van clustergrootte voor gestructureerde streamingworkloads. Databricks raadt het gebruik van Delta Live Tables aan met verbeterde automatische schaalaanpassing voor streamingworkloads.

Automatische beëindiging gebruiken

Azure Databricks biedt verschillende functies om de kosten te beheren door niet-actieve resources te verminderen en te bepalen wanneer rekenresources kunnen worden geïmplementeerd.

• Configureer automatische beëindiging voor alle interactieve rekenresources. Na een opgegeven niet-actieve tijd wordt de rekenresource afgesloten. Zie Automatische beëindiging.
• Voor gebruiksscenario's waarbij berekeningen alleen tijdens kantooruren nodig zijn, kunnen rekenresources worden geconfigureerd met automatische beëindiging en kan een gepland proces de rekenkracht opnieuw starten (en eventueel gegevens voorafwarmen indien nodig) in de ochtend voordat gebruikers weer op hun bureaublad zijn. Zie CACHE SELECT.
• Als de opstarttijden van rekenprocessen te lang zijn, kunt u overwegen clustergroepen te gebruiken, raadpleegt u best practices voor pools. Azure Databricks-pools zijn een set niet-actieve, kant-en-klare exemplaren. Wanneer clusterknooppunten worden gemaakt met behulp van de niet-actieve exemplaren, worden de start- en automatisch schalen van clusters verminderd. Als de pools geen niet-actieve exemplaren hebben, worden de pools uitgebreid door een nieuw exemplaar van de instantieprovider toe te wijzen om tegemoet te komen aan de aanvraag van het cluster.

Azure Databricks brengt geen kosten in rekening voor Databricks Units (DBU's), terwijl exemplaren niet actief zijn in de pool, wat resulteert in kostenbesparingen. Facturering van exemplaarproviders is van toepassing.

Rekenbeleid gebruiken om kosten te beheren

Rekenbeleid kan veel kostenspecifieke beperkingen voor rekenresources afdwingen. Zie Operational Excellence - Rekenbeleid gebruiken. Voorbeeld:

• Schakel automatische schaalaanpassing van clusters in met een ingesteld minimumaantal werkknooppunten.
• Schakel automatische beëindiging van het cluster in met een redelijke waarde (bijvoorbeeld 1 uur) om te voorkomen dat u betaalt voor niet-actieve tijden.
• Zorg ervoor dat alleen kostenefficiënte VM-exemplaren kunnen worden geselecteerd. Volg de aanbevolen procedures voor clusterconfiguratie. Zie aanbevelingen voor compute-configuratie.
• Pas een spot-exemplaarstrategie toe.

3. Kosten bewaken en beheren

Kosten bewaken

Gebruik Azure Cost Manager om azure Databricks-kosten te analyseren. Compute- en werkruimtetags worden ook geleverd aan Azure Cost Manager. Zie Tagclusters voor kostentoeschrijving.

Tagclusters voor kostentoewijzing

Als u kosten in het algemeen wilt bewaken en azure Databricks-gebruik nauwkeurig wilt toewijzen aan de bedrijfseenheden en teams van uw organisatie voor terugstortingsdoeleinden, kunt u clusters, SQL-magazijnen en pools taggen. Deze tags worden doorgegeven aan gedetailleerde Databricks Units (DBU) en cloudprovider-VM en blobopslaggebruik voor kostenanalyse.

Zorg ervoor dat kostenbeheer en -toeschrijving worden overwogen bij het instellen van werkruimten en clusters voor teams en use cases. Dit stroomlijnt taggen en verbetert de nauwkeurigheid van kostentoewijzing.

Totale kosten omvatten de virtuele DBU-machine, schijf en eventuele bijbehorende netwerkkosten. Voor serverloze SQL-warehouses omvatten de DBU-kosten al de virtuele machine en schijfkosten.

De tags van Azure Databricks-resources kunnen worden gebruikt in de hulpprogramma's voor kostenanalyse in Azure Portal

Waarneembaarheid implementeren om kosten bij te houden en terug te betalen

Wanneer u met complexe technische ecosystemen werkt, is het proactief begrijpen van de onbekende elementen essentieel voor het onderhouden van platformstabiliteit en het beheren van de kosten. Waarneembaarheid biedt een manier om systemen te analyseren en te optimaliseren op basis van de gegevens die ze genereren. Dit verschilt van bewaking, die zich richt op het identificeren van nieuwe patronen in plaats van het bijhouden van bekende problemen.

Databricks biedt geweldige waarneembaarheidsmogelijkheden met behulp van systeemtabellen die door Databricks gehoste analytische opslag zijn van de operationele gegevens van een klantaccount die zijn gevonden in de systeemcatalogus. Ze bieden historische waarneembaarheid in het account en bevatten gebruiksvriendelijke tabellaire informatie over platformtelemetrie.

Zie blog: Intelligently Balance Cost Optimization & Betrouwbaarheid in Databricks

Kostenrapporten regelmatig delen

Genereer maandelijkse kostenrapporten om de groei en afwijkingen van het verbruik bij te houden. Deel deze rapporten per use-case of team met de teams die eigenaar zijn van de workloads met behulp van clustertags. Dit elimineert verrassingen en stelt teams in staat om hun workloads proactief aan te passen als de kosten te hoog worden.

Kosten voor uitgaand verkeer van Delta Sharing bewaken en beheren

In tegenstelling tot andere platforms voor het delen van gegevens, vereist Delta Sharing geen gegevensreplicatie. Dit model heeft veel voordelen, maar het betekent dat uw cloudleverancier kosten voor uitgaande gegevens kan in rekening brengen wanneer u gegevens deelt in clouds of regio's. Zie Kosten voor uitgaand verkeer van Delta Sharing bewaken en beheren (voor providers) om de kosten voor uitgaand verkeer te bewaken en te beheren.

4. Kostenefficiënte workloads ontwerpen

Altijd ingeschakelde en geactiveerde streaming verdelen

Als mensen traditioneel nadenken over streaming, komen termen zoals 'realtime', '24/7' of 'always on' in gedachten. Als gegevensopname in realtime plaatsvindt, moeten de onderliggende rekenresources 24/7 worden uitgevoerd, waardoor elke uur van de dag kosten in rekening worden gebracht.

Niet elke use-case die afhankelijk is van een continue stroom gebeurtenissen, vereist echter dat deze gebeurtenissen onmiddellijk worden toegevoegd aan de analysegegevensset. Als voor de bedrijfsvereiste voor de use-case alleen om de paar uur of elke dag nieuwe gegevens nodig zijn, kan aan die vereiste worden voldaan met slechts een paar uitvoeringen per dag, wat resulteert in een aanzienlijke vermindering van de workloadkosten. Databricks raadt aan structured streaming te gebruiken met de AvailableNow trigger voor incrementele workloads die geen lage latentievereisten hebben. Zie Incrementele batchverwerking configureren.

Balans tussen overtollige instanties op aanvraag en capaciteitsoverschot

Spot-exemplaren profiteren van overtollige virtuele-machineresources in de cloud die tegen een lagere prijs beschikbaar zijn. Om kosten te besparen, biedt Azure Databricks ondersteuning voor het maken van clusters met behulp van spot-exemplaren. Databricks raadt aan dat het eerste exemplaar (het Spark-stuurprogramma) altijd een on-demand virtuele machine moet zijn. Spot-exemplaren zijn een goede keuze voor workloads waarbij het acceptabel is langer te duren, omdat een of meer spot-exemplaren zijn verwijderd door de cloudprovider.