Domande frequenti su bundle di automazione dichiarativa

Questo articolo elenca le domande frequenti sui bundle di automazione dichiarativa (in precedenza noti come bundle di asset di Databricks).

Perché i bundle di asset di Databricks sono stati rinominati in Bundle di automazione dichiarativa?

Il nuovo nome Bundle di automazione dichiarativa riflette in modo più accurato l'utilizzo e le funzionalità dei bundle. Inoltre, il termine asset ha causato confusione perché ha più di un significato in Databricks. Questa modifica del nome è non invasiva. Non è necessario modificare il bundle comando dell'interfaccia della riga di comando e tutta la configurazione esistente.

Come posso utilizzare i pacchetti di automazione dichiarativa come parte della mia pipeline CI/CD su Azure Databricks?

È possibile usare bundle di automazione dichiarativa per definire e gestire gli asset a livello di codice nell'implementazione CI/CD di Azure Databricks, che in genere include:

• Notebook: i notebook di Azure Databricks sono spesso una parte fondamentale dei flussi di lavoro di data engineering e data science. È possibile usare il controllo della versione per i notebook e convalidarli e testarli come parte di una pipeline CI/CD. È possibile eseguire test automatizzati sui notebook per verificare se funzionano come previsto.
• Librerie: gestire le dipendenze della libreria necessarie per eseguire il codice distribuito. Usare il controllo della versione nelle librerie e includerli nei test e nella convalida automatizzati.
• Flussi di lavoro: i processi Lakeflow sono costituiti da processi che consentono di pianificare ed eseguire attività automatizzate usando notebook o processi Spark.
• Pipeline di dati: è anche possibile includere pipeline di dati nell'automazione CI/CD, usando le pipeline dichiarative di Lakeflow Spark, il framework in Databricks per dichiarare le pipeline di dati.
• Infrastruttura: la configurazione dell'infrastruttura include definizioni e informazioni di provisioning per cluster, aree di lavoro e archiviazione per gli ambienti di destinazione. Le modifiche all'infrastruttura possono essere convalidate e testate come parte di una pipeline CI/CD, assicurandosi che siano coerenti e senza errori.

Perché è necessario disporre di ambienti di destinazione di sviluppo e produzione separati?

Gli ambienti di sviluppo e prodotto separati consentono di:

• Isolare in modo sicuro le modifiche di sviluppo in modo che non influiscano accidentalmente sulla produzione.
• Impedire la duplicazione del codice personalizzando le risorse da applicare a un ambiente di destinazione specifico.
• Ottimizzare e semplificare CI/CD con una configurazione specifica dell'ambiente, ad esempio percorsi del database, avvisi e controlli di accesso.
• Riutilizzare i flussi di lavoro tra team e ambienti.

Utilizzare le destinazioni per definire gli ambienti di distribuzione dei bundle. Si veda Obiettivi.

Come si rendono coerenti i bundle nell'organizzazione?

Usare i modelli di aggregazione per una struttura coerente, ridurre gli errori di configurazione e promuovere le procedure consigliate. È possibile usare modelli di bundle predefiniti oppure creare modelli di bundle personalizzati. Consultare Modelli di progetto bundle di automazione dichiarativa.

Ci sono molte ripetizioni tra i bundle, ad esempio le stesse definizioni di cluster. Qual è il modo migliore per gestirlo?

Le variabili personalizzate sono il modo migliore per gestire le ripetizioni, nonché le impostazioni specifiche del contesto. Vedere Variabili personalizzate.

Quali sono alcune procedure consigliate quando si usano i bundle nel flusso di distribuzione?

Databricks consiglia:

• Passare dalle distribuzioni manuali all'automazione affidabile usando flussi di lavoro integrati con Git.
• Convalidare prima di distribuire un bundle usando databricks bundle validate nella pipeline CI/CD.
• Passaggi di deploy separati per garantire che le modifiche siano esaminate e intenzionali.
• Parametrizzare gli ambienti (sviluppo, staging, produzione) con override per isolare i cambiamenti.
• Eseguire i test di integrazione dopo la distribuzione per rilevare i problemi in anticipo.
• Usare GitHub Actions, Azure DevOps o GitLab CI per attivare le distribuzioni al commit o al merge delle pull request.
• Monitorare cosa viene distribuito, dove e quando, così che ogni distribuzione sia mappato a una versione del commit e del bundle.

È possibile trasferire processi, pipeline, dashboard e altri oggetti Databricks esistenti nel mio pacchetto?

Sì. Usare il databricks bundle generate comando per generare un file di configurazione per un processo, una pipeline o un dashboard esistente nel bundle locale, quindi usare databricks bundle deployment bind per associare la risorsa bundle alla risorsa corrispondente nell'area di lavoro. Questo è l'ideale per integrare flussi di lavoro esistenti in uno sviluppo strutturato e versionato. L'associazione risolve anche i percorsi relativi trasformandoli in riferimenti assoluti nell'area di lavoro, evitando errori di percorso.

Vedere Migrare risorse esistenti in un bundle.

Come posso testare il mio bundle in modo iterativo?

È possibile sviluppare più rapidamente con distribuzioni iterative ed esecuzioni:

• Convalida prima della distribuzione
• Distribuire in modo incrementale
• Eseguire solo ciò che è necessario
• Modifica e ripetizione

Ciò accelera i test e il debug, riduce il cambio di contesto, consente un'iterazione più sicura e veloce senza ridistribuire completamente e applica disciplina quando si passa alla produzione.