Delen via


Best practices voor kostenoptimalisatie

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

1. Kies optimale middelen

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.

Gebruik job compute

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 taakberekening zijn de niet-interactieve werklasten echter aanzienlijk goedkoper dan bij algemene rekendiensten. Zie het prijsoverzicht om Jobs Compute en All-Purpose Compute te vergelijken.

Een extra voordeel voor sommige taken is dat elke taak kan worden uitgevoerd op een nieuw rekenproces, waardoor workloads van elkaar worden geïsoleerd. Multitask-taken kunnen echter ook rekenresources opnieuw gebruiken voor alle taken, zodat de opstarttijd van de rekenkracht slechts één keer per taak 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.

Gebruik actuele runtimes 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 inferentie 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-modeluitvoering

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 overloopbelastingen
  • Rekenen die is geoptimaliseerd voor gestructureerde streaming-workloads en onderhoudstaken (zoals optimaliseren en opschonen)
  • 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 overflow tijdens shuffles en caching.

Aanvullende overwegingen zijn onder andere het type en de grootte van worker-instances, die ook van invloed zijn op de voorgaande factoren. Houd rekening met het volgende bij het bepalen van de grootte van uw computercapaciteit:

  • 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.

Prestatiegeoptimaliseerde queryengines evalueren

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

Gebruik automatisch schaalbare compute-resources

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 aan lakeflow-declaratieve pijplijnen te gebruiken 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 niet-actieve exemplaren, worden de start- en autoschalingstijden 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. De facturering door instanceproviders is van toepassing.

Rekenbeleid gebruiken om kosten te beheren

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

3. Kosten bewaken en beheren

Kostenbeheer in Databricks is een essentieel aspect van het optimaliseren van clouduitgaven terwijl de prestaties behouden blijven. Het proces kan worden onderverdeeld in drie belangrijke gebieden:

  • Configuratie
  • Controle
  • Beheer

De volgende best practices hebben betrekking op deze drie gebieden.

Tagging instellen voor kostentoewijzing

Als u de kosten in het algemeen wilt bewaken en databricks-gebruik nauwkeurig wilt toewijzen aan de bedrijfseenheden en teams van uw organisatie (bijvoorbeeld voor terugstortingen in uw organisatie), kunt u werkruimten, clusters, SQL-magazijnen en pools taggen.

In de installatiefase moeten organisaties effectieve tagprocedures implementeren. Dit omvat het maken van labelnaamconventies in de hele organisatie. Het is belangrijk om zowel algemene tags te gebruiken die het gebruik toewijzen aan specifieke gebruikersgroepen als gedetailleerdere tags die zeer specifieke inzichten bieden, bijvoorbeeld op basis van rollen, producten of services.

Begin met taggen vanaf het begin van het gebruik van Databricks. Naast de standaardtags die door Databricks zijn ingesteld, stelt u ten minste de aangepaste tags _Business Units_ en _Projects_ in en vult u deze in voor uw specifieke organisatie. Als u onderscheid wilt maken tussen ontwikkeling, kwaliteitscontrole en productiekosten, kunt u overwegen om de tag Environment toe te voegen aan werkruimten en rekenresources.

De tags worden zowel doorgegeven aan gebruikslogboeken als aan cloudproviderresources voor kostenanalyse. Totale kosten omvatten Databricks Units (DBU's) plus virtuele machine, schijf en bijbehorende netwerkkosten. Houd er rekening mee dat de DBU-kosten voor serverloze services al de kosten van de virtuele machine bevatten.

Omdat het toevoegen van tags alleen van invloed is op toekomstig gebruik, is het beter om te beginnen met een meer gedetailleerde tagstructuur. Het is altijd mogelijk om tags te negeren als praktisch gebruik in de loop van de tijd laat zien dat ze geen invloed hebben op kostenkennis en toeschrijving. Ontbrekende tags kunnen echter niet worden toegevoegd aan eerdere gebeurtenissen.

Budgetten en waarschuwingen instellen om het bijhouden van accountuitgaven mogelijk te maken.

Met budgetten kunt u het gebruik in uw hele account bewaken. Ze bieden een manier om financiële doelen in te stellen en u kunt uitgaven voor de hele rekening bijhouden of filters toepassen om de uitgaven van specifieke teams, projecten of werkruimten bij te houden. Als uw account gebruikmaakt van serverloze rekenkracht, moet u begrotingsbeleid gebruiken om uw serverloze verbruik toe te wijzen. Zie Serverloos gebruik toewijzen met budgetbeleid.

Het wordt aanbevolen e-mailmeldingen in te stellen wanneer het maandelijkse budget wordt bereikt om onverwachte overschrijdingen te voorkomen.

Kosten bewaken om uitgaven af te stemmen op verwachtingen

Dashboards voor waarneembaarheid van kosten helpen bij het visualiseren van uitgavenpatronen en budgetbeleid helpen serverloos rekengebruik toe te schrijven aan specifieke gebruikers, groepen of projecten, waardoor nauwkeurigere kostentoewijzing mogelijk is. Databricks biedt een scala aan hulpprogramma's en functies om de kosten bij te houden en te analyseren:

  • Gebruik bewaken in de accountconsole: Databricks biedt AI/BI-dashboards voor kostenbeheer in de accountconsole, die kunnen worden geïmporteerd door accountbeheerders in elke werkruimte met Unity Catalog in hun account. Hiermee kunt u het accountgebruik of één werkruimtegebruik bewaken.

  • Gebruik budgetten om accountuitgaven te bewaken: Met budgetten kunt u het gebruik in uw account bewaken.
    Budgetbeleid kan worden gebruikt om serverloos gebruik toe te passen door tags toe te passen op serverloze rekenactiviteiten die worden gemaakt door een gebruiker die is toegewezen aan het beleid.

  • Kosten voor het uitgaand verkeer van Delta Sharing bewaken en beheren: In tegenstelling tot andere platformen voor gegevensdeling is bij Delta Sharing geen gegevensreplicatie vereist. 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.

  • Kosten bewaken met behulp van systeemtabellen: met de systeemtabel system.billing.usage kunt u kosten bewaken. Aangepaste tags die worden toegepast op werkruimten en rekenresources, worden doorgegeven aan deze systeemtabel. U kunt de kosten van serverloze berekeningen, taakkosten en modelleringskosten bewaken.

  • Kosten bewaken met behulp van Azure Cost Manager: Kostenanalyse is een hulpprogramma voor het analyseren van kosten in Azure. De tags van Azure Databricks-resources zijn beschikbaar in dit hulpprogramma voor gedetailleerde analyse.

Kosten beheren om het gebruik af te stemmen op de behoeften van de organisatie

Kostenbeheer gaat verder dan de technische implementatie om bredere organisatorische strategieën op te nemen:

  • Ontwikkel en plan een huishoudtaak om tags (incrementeel) toe te passen of op te schonen. De taak moet veerkrachtig zijn om niet te worden onderbroken door problemen met individuele bronnen. Alle wijzigingen moeten naar een auditlogboek worden geschreven.
  • Voer regelmatig kostencontroles uit om alle actieve resources, hun uitgaven en hun afstemming op organisatorische behoeften te controleren. Het delen van maandelijkse kostenrapporten helpt bij het bijhouden van verbruiksverhogingen en afwijkingen, en moedigt proactief kostenbeheer in alle teams aan.
  • Resourcetoewijzing optimaliseren via strategieën zoals automatisch schalen en automatisch beëindigen, waarmee resources dynamisch worden toegewezen op basis van workloadvereisten; zie de andere aanbevolen procedures in dit hoofdstuk.
  • Informeer teams over de gevolgen voor de kosten van hun resourcegebruik en train op aanbevolen procedures voor kostenoptimalisatie.
  • Gebruik rekenbeleid als hulpprogramma om het type en de grootte van rekenresources te bepalen die bepaalde gebruikers kunnen maken en openen.

Over het algemeen moet kostenoptimalisatie worden gezien als een doorlopend proces en strategieën moeten regelmatig worden bekeken in het geval van schalen, nieuwe projecten of onverwachte kostenpieken. Gebruik de systeemeigen mogelijkheden voor kostenbeheer van Databricks en hulpprogramma's van derden voor uitgebreide controle en optimalisatie.

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 instanties op aanvraag en met 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.