Best practices voor ontwikkelaars voor Databricks

Deze pagina bevat aanbevolen procedures voor uw levenscyclus van data engineering en ontwikkeling, waaronder versiebeheer, omgevingsbeheer, hulpprogramma's voor ontwikkelaars en beheerde implementaties.

Bronbeheer

Versiebeheer alle bestanden

Declaratieve automatisering is gebaseerd op het idee dat als er iets niet in versiebeheer staat, deze niet bestaat. Daarom raadt Databricks u aan om vrijwel elk bestand versiebeheer uit te geven, waaronder:

• Alle notitieblokken en bronbestanden (.py, .sql)
• Configuratiebestanden bundelen (databricks.yml en omgevingsspecifieke YAML-onderdrukkingen)

Voer echter niet het volgende door:

• Bouw artefacten, zoals .jar of .whl bestanden. Upload in plaats daarvan gecompileerde binaire bestanden naar Unity Catalog-volumes tijdens CI. Zie het uploaden van JAR.
• Tokens of inloggegevens. Gebruik secretbeheer op werkruimteniveau, ondersteund door een cloudsecretmanager (zoals AWS Secrets Manager of Azure Key Vault), en synchroniseer waarden naar secret scopes in Databricks. Zie Geheimbeheer.
• Voorbeelden van lokale gegevens en bestanden met PII. Gebruik .gitignore dit om ze uit te sluiten.

Eén opslagplaats

Databricks raadt u aan om één opslagplaats te gebruiken voor al uw code (broncode en configuratiebestanden), omdat hiermee samenwerking en code en aanbevolen procedures worden gedeeld voor zowel mensen als AI. Als u meerdere bundels hebt voor afzonderlijke implementatielevenscycli, moet u deze in één opslagplaats bewaren.

De enige uitzondering op de aanbeveling voor één opslagplaats is in gereglementeerde branches waar meerdere opslagplaatsen nodig zijn voor vertrouwelijkheidsdoeleinden.

Strategie voor vertakking op basis van trunk

Gebruik een trunk-based branchingstrategie om samenvoegingsconflicten te minimaliseren en ervoor te zorgen dat de hoofdvertakking altijd direct inzetbaar is.

Een eenvoudige werkstroom is:

1. Ontwikkel lokaal of in de werkruimte en implementeer deze in een Databricks-ontwikkelwerkruimte om wijzigingen te testen.
2. Maak een korte functievertakking naar updates voor versiebeheer en synchroniseer regelmatig de wijzigingen in uw lokale of werkruimte.
3. Wanneer het testen is voltooid, voegt u de featurebranch samen met de hoofdbranch.
4. CI/CD implementeert automatisch de hoofdvertakking naar een faseringswerkruimte en geautomatiseerde tests worden geactiveerd.
5. Wanneer de faseringstests en controles worden uitgevoerd, implementeert CI/CD de hoofdvertakking naar een productiewerkruimte.

Deze stappen worden beschreven in het volgende diagram:

Werkruimteconfiguratie

Werkruimte-omgevingen isoleren

Isoleer werkruimteomgevingen om de impact van een mislukte implementatie te minimaliseren. Voorbeeld:

• Kleine teams (maximaal 5 data engineers): begin met twee werkruimten (ontwikkeling en productie) in één cloudaccount.
• Groeiende teams (5+ data engineers): verplaats naar drie werkruimten (ontwikkeling, fasering en productie). Fasering moet functioneel representatief zijn voor productie , dezelfde bundelconfiguratie, hetzelfde schema en kritieke integraties , zelfs als deze omlaag wordt geschaald.
• Gereguleerde branches (banken, gezondheidszorg, defensie): werkruimten en cloudaccounts fysiek isoleren om gegevenslekken te voorkomen. Isolatie beheren via IAM- en Unity Catalog-grenzen binnen één account is mogelijk, maar biedt een minder robuuste beveiligingspostuur.

Gebruik voor productiewerkruimten waar mogelijk serverloze berekeningen met netwerkbeleid. Configureer anders cloudaccounts zodanig dat ze gebruikmaken van privésubnetten of VNets met strikt beheerd uitgaand verkeer en netwerkbeveiligingsmaatregelen.

Zie Contextgebaseerde netwerkbeleidsregels voor meer informatie.

Gegevensopslag isoleren

• Gebruik één Unity Catalog-metastore en maak afzonderlijke catalogi voor ontwikkelaars, fasering (indien van toepassing) en productie, waarbij uw werkruimte-indeling wordt gespiegeld.
• Gebruik persoonlijke schema's voor afzonderlijke ontwikkelaars voor ontwikkelings- en faseringscatalogussen (niet-productie).
• Koppel de productiecatalogus in de modus ISOLATED alleen aan de productiewerkruimte. Door de isolatiemodus van een catalogus in te stellen op ISOLATED, wordt ervoor gezorgd dat productiegegevens niet toegankelijk zijn vanuit ontwikkel- of stagingomgevingen, zelfs als een identiteit onjuist is geconfigureerd.
• Reserveer afzonderlijke metastores, accounts of regio's alleen voor organisaties met wettelijke vereisten, vereisten inzake gegevenssoevereiniteit of vereisten voor meerdere regio's waarin isolatie op catalogusniveau niet kan voorzien.

Tabel- en kolommetagegevens behandelen als code

Tabel- en kolomopmerkingen behandelen als onderdeel van uw code. Bewaar ze in .sql bestanden naast uw declaratieve Automation Bundles-definities en implementeer ze via een metagegevenstaak, zodat nauwkeurige, bedrijfsgerichte definities altijd beschikbaar zijn. Schrijf opmerkingen die beschrijven wat een rij vertegenwoordigt, de eenheden en geldige waarden in gewone taal in plaats van de kolomnaam te herhalen.

Persoonlijke schema's configureren

Configureer bundels tijdens de ontwikkeling voor het gebruik van een persoonlijk schema per gebruiker, bijvoorbeeld dev_${user_name}. Dit voorkomt dat ontwikkelaars elkaars tabellen in een gedeelde werkruimte overschrijven.

Serverloze rekenkracht gebruiken

Gebruik serverloze rekenkracht om clusterbeheer te vereenvoudigen en de kosten te optimaliseren. Zie Verbinding maken met serverloze berekeningen.

Aanbevelingen voor CI/CD

Declaratieve Automatiseringsbundels voor CI/CD

Declaratieve Automation-bundels (voorheen bekend als Databricks Asset Bundles) bieden een krachtige, uniforme benadering voor het beheren van code, werkstromen en infrastructuur binnen het Databricks-ecosysteem en worden aanbevolen voor uw CI/CD-pijplijnen.

Zie CI/CD-werkstromen op Databricks voor meer informatie over het gebruik van bundels voor CI/CD-werkstromen.

Voor meer informatie over declaratieve automatiseringsbundels, zie Wat zijn declaratieve automatiseringsbundels?.

Terraform alleen gebruiken voor externe resources

Gebruik Terraform om de volgende resources te definiëren:

• Op cloudniveau en externe bronnen
• Beheeracties die niet-bevoegde gebruikers niet mogen uitvoeren, zoals het inrichten van werkruimten of configuratie van cloudnetwerken

Gebruik declaratieve automatiseringsbundels voor alle andere Databricks-resources.

Bundelbeheer

Kleine bundels maken

Databricks raadt aan kleine, gerichte bundels te ontwikkelen via één grote bundel.

• Zet alles wat één team bezit in één bundel.
• Test en implementeer via dezelfde CI/CD-pijplijn die dezelfde levenscyclus en releasefrequentie deelt.
• Elke bundel moet betrekking hebben op alle omgevingen voor een bepaald project (dev, fasering, productie) in plaats van afzonderlijke bundels per omgeving te gebruiken.

Maak afzonderlijke bundels voor:

• Verschillende producten of domeinen, bijvoorbeeld 'Factureringsanalyse' en 'Fraudedetectie'
• Verschillende eigendoms- of machtigingsgrenzen
• Workloads met duidelijk verschillende levenscycli
• Gevallen waarin u onafhankelijke promotie of terugdraaiactie nodig hebt

Sync.paths gebruiken om gedeelde mappen te synchroniseren

Wanneer u meerdere bundels in één repository beheert, gebruikt u sync.paths om gedeelde mappen van buiten de hoofdmap van de bundel te synchroniseren. Hierdoor kunnen verschillende projecten een gemeenschappelijke bibliotheekmap delen, zoals ../common, terwijl afzonderlijke implementatie-identiteiten behouden blijven.

Afhankelijkheden tussen bundels modelleren in CI/CD

Wanneer Bundel B afhankelijk is van assets die door Bundel A zijn gepubliceerd, leg die afhankelijkheid dan vast in uw CI/CD- of orchestratielaag in plaats van beide samen te voegen tot één bundel.

• Maak de implementatie- en publicatiewerkstroom van Bundel A een expliciete vereiste voor Bundel B. Wire your pipeline, zodat Bundle B pas wordt gestart nadat de implementatie van Bundle A is geslaagd en alle vereiste validatiecontroles zijn geslaagd.
• Geef gepubliceerde asset-id's of locaties door als invoer voor de pijplijn en faal direct als upstream-assets ontbreken. Dit zorgt ervoor dat Bundle B nooit wordt geïmplementeerd op basis van een gedeeltelijk gepubliceerde status.

Zie Bundels en bundelbestanden delen voor meer informatie over het delen van bundels.

Aangepaste bundelsjablonen

Gebruik aangepaste declaratieve Automation-bundelsjablonen als het standaardstartpunt voor nieuwe projecten, zodat elk project dezelfde kaders overneemt: machtigingen, taggen, clusterbeleid, CI/CD-bedrading en basislijnen voor exemplaren, zonder dat elk team helemaal opnieuw hoeft op te lossen.

Sjablonen moeten gedeelde, langlevende conventies coderen, zoals governance, standaardinstellingen voor prestaties, de indeling van de omgeving en quotumlimieten. Vermijd app-specifieke bedrijfslogica, geheimen of eenmalige configuratie in sjablonen.

Parameteriseer alleen invoerwaarden waarvan wordt verwacht dat ze per team, project of omgeving variëren:

• Project of toepassingsnaam
• Doelwerkruimte-instellingen
• Catalogus- of schemanamen
• Service-principal-id's
• Planningen en meldingsinstellingen

Houd platformbescherming en gedeelde standaardinstellingen vast in de sjabloon in plaats van ze te parameteriseren.

Zie Declaratieve Automation Bundles-projectsjablonen voor meer informatie over aangepaste bundelsjablonen en hoe u deze kunt maken.

Plannen voor terugdraaiacties en hotfixes

Houd bundels klein genoeg zodat u een gerichte terugdraaiactie kunt uitvoeren op één bundel in plaats van een terugdraaiactie te coördineren voor veel niet-gerelateerde workloads.

Tijdens een incident:

1. Herstel of draai de betreffende bundel terug naar de laatst bekende goede versie.
2. Gebruik alleen een hotfix voor urgente, beperkte oplossingen die niet kunnen wachten op de normale promotiestroom.
3. Merge elke hotfix onmiddellijk na validatie terug naar de main branch, zodat de trunk de enige bron van waarheid blijft.

Algemene ontwikkeling

Gebruik service-principals of OIDC

Gebruik service-principals voor alle niet-ontwikkelingsautomatisering om geautomatiseerde werkstromen van afzonderlijke gebruikersaccounts los te koppelen en ervoor te zorgen dat taken blijven worden uitgevoerd wanneer interne gebruikers vertrekken. Zie Service principals.

• Gebruik afzonderlijke service-principals voor implementatie en runtime. Een speciale implementatieservice-principal voor bundelimplementaties moet minimale gegevenstoegang hebben. Elke productietaak of pijplijn moet een eigen run-as-service-principal hebben die alleen is afgestemd op de gegevens en resources die voor de workload nodig zijn. Deze scheiding zorgt ervoor dat implementaties veilig blijven wanneer u machtigingen voor gegevenstoegang roteert of verdraait, en vermijdt het koppelen van infrastructuurwijzigingen aan productiegegevenstoegang.
• Gereguleerde branches: Gebruik OIDC (Workload Identity Federation) voor CI/CD. Dit elimineert langlevende geheimen in GitHub Actions of Azure DevOps. Zie Workload-identiteitsfederatie inschakelen in CI/CD.

Hulpprogramma's voor Databricks-ontwikkelaars gebruiken

Ontwikkel in de gebruikersinterface van de Databricks-werkruimte met behulp van Git-mappen of in een lokale IDE. Als u Visual Studio Code of een compatibele fork gebruikt, installeert u de officiële Databricks-extensie voor:

• Databricks-specifieke agentvaardigheden
• Toegang tot Unity Catalog en bestandssysteem
• Mogelijkheden voor externe ontwikkeling voor het uitvoeren van workloads op Databricks Compute

Zie de Databricks-extensie voor Visual Studio Code voor meer informatie.

Bedrijfslogica in notebooks minimaliseren

Behandel notebooks niet als de primaire container voor bedrijfslogica. Gebruik ze alleen voor verkenning en visualisatie.

• Python: Plaats kernlogica in importeerbare .py modules in src/ of src/py/, en roep deze functies aan vanuit notebooks.
• SQL: Behoud query's in bestanden in .sqlsrc/ of src/sql/, en verwijs naar deze bestanden vanuit taken en pijplijnen in plaats van SQL in notebooks in te schrijven.

Gebruik notebooks alleen als dunne indelings- en visualisatielagen die de onderliggende code aanroepen. Deze aanpak maakt testen en hergebruik eenvoudiger.

Wanneer u een notebook-intensief project migreert, moet u dit stapsgewijs doen. Extraheer één herbruikbare module of SQL-bestand tegelijk en gebruik declaratieve Automation-bundels om gemigreerde assets onder dezelfde implementatie- en testwerkstroom te brengen als de rest van het project.

Context dynamisch doorgeven

Vermijd statische variabelen voor taakafhankelijkheden. Gebruik dynamische waardeverwijzingen, zoals {{tasks.<task_key>.values.<value_key>}}, om runtimecontext door te geven tussen taken in een job met meerdere fasen.

Testen en waarneembaarheid

Testlagen implementeren

Gebruik drie testlagen die overeenkomen met de wijze waarop uw bundels naar productie gaan:

1. Eenheidstests: Houd bedrijfslogica in importeerbare src/ modules en bedek deze met pytest of een gelijkwaardig framework. Voer deze uit bij elke pull request, zodat fouten merges blokkeren.
2. Bundelvalidatie: lokaal uitvoeren bundle validate . In CI geeft u de voorkeur bundle deploy aan een niet-productiewerkruimte om YAML- en resourcetoewijzingsproblemen te ondervangen voordat productie wordt geïmplementeerd.
3. Integratietests in staging: Voer na uitrol naar staging end-to-end-jobs uit met controles op voltooiing en kritieke datakwaliteitscontroles, zoals controles op het aantal rijen of schemaverwachtingen.

Beschouw "alle tests slagen op de hoofdtak en in de stagingomgeving" als het toelatingscriterium voor het promoveren van artefacten naar productie.

Gebruik voor Lakeflow Spark-declaratieve pijplijnen de ingebouwde ontwikkel- en validatiefuncties in plaats van ad-hoc notebookuitvoeringen. Test pijplijnlogica voor kleine, representatieve gegevenssets met records met fouten en gebruik de ontwikkelingsmodus om wijzigingen te valideren voordat u productietabellen bijwerkt.

Logboekregistratie behandelen als onderdeel van de implementatie

Beschouw voor workloads die met Declarative Automation Bundles zijn uitgerold metrics en logging als onderdeel van het deploymentcontract, in plaats van als iets dat elk project afzonderlijk definieert.

• Gestructureerde logboeken consistent verzenden tussen taken, pijplijnen en taken. Neem de bundelnaam, doelomgeving, workloadnaam, uitvoerings-id en eventuele bedrijfs-id op die nodig zijn om fouten te traceren.
• Houd een standaardset operationele metrische gegevens bij voor elke productieworkload: uitvoeringsstatus, duur, aantal nieuwe pogingen en indicatoren voor doorvoer of versheid, indien relevant.
• Codeer deze conventies in gedeelde bibliotheken, herbruikbare workloaddefinities of bundelsjablonen, zodat teams geen waarneembaarheidspatronen voor elk project hoeven te maken.