Sviluppare pipeline di tabelle live delta
Lo sviluppo e il test del codice della pipeline differiscono da altri carichi di lavoro di Apache Spark. Questo articolo offre una panoramica delle funzionalità supportate, delle procedure consigliate e delle considerazioni per lo sviluppo di codice della pipeline. Per altre raccomandazioni e procedure consigliate, vedere l'applicazione di procedure consigliate di sviluppo software & DevOps alle pipeline di tabelle live Delta.
Nota
È necessario aggiungere codice sorgente a una configurazione della pipeline per convalidare il codice o eseguire un aggiornamento. Consultare Configurare una pipeline Delta Live Tables.
Quali file sono validi per il codice sorgente della pipeline?
Il codice della pipeline delle tabelle live delta può essere Python o SQL. È possibile avere una combinazione di file di codice sorgente Python e SQL che eseguono il backup di una singola pipeline, ma ogni file può contenere solo un linguaggio. Vedere Sviluppare codice della pipeline con Python e Sviluppare codice della pipeline con SQL.
È possibile usare notebook e file dell'area di lavoro quando si specifica il codice sorgente per una pipeline. I file dell'area di lavoro rappresentano script Python o SQL creati nell'IDE preferito o nell'editor di file di Databricks. Vedi Che cosa sono i file dell'area di lavoro?.
Se si sviluppa codice Python come moduli o librerie, è necessario installare e importare il codice e quindi chiamare i metodi da un notebook Python o un file dell'area di lavoro configurato come codice sorgente. Consulta Gestire le dipendenze Python per le pipeline di Delta Live Tables.
Nota
Se è necessario usare comandi SQL arbitrari in un notebook Python, è possibile usare il modello di sintassi spark.sql("<QUERY>") per eseguire SQL come codice Python.
Le funzioni del catalogo di Unity consentono di registrare funzioni python arbitrarie definite dall'utente per l'uso in SQL. Consulta le funzioni definite dall'utente nel Unity Catalog.
Panoramica delle funzionalità di sviluppo di tabelle live Delta
Le tabelle dinamiche Delta estendono e sfruttano molte funzionalità di Azure Databricks e introduce nuove funzionalità e concetti. La tabella seguente offre una breve panoramica dei concetti e delle funzionalità che supportano lo sviluppo di codice della pipeline:
| Caratteristica | Descrizione |
|---|---|
| Modalità di sviluppo | Le nuove pipeline sono configurate per l'esecuzione in modalità di sviluppo per impostazione predefinita. Databricks consiglia di usare la modalità di sviluppo per lo sviluppo interattivo e i test. Vedere Modalità di sviluppo e produzione. |
| Convalidare | Un aggiornamento Validate verifica la correttezza del codice sorgente della pipeline senza eseguire un aggiornamento in alcuna tabella. Consulta per controllare la presenza di errori in una pipeline senza attendere l'aggiornamento delle tabelle. |
| Notebook | I notebook configurati come codice sorgente per una pipeline di tabelle live Delta offrono opzioni interattive per la convalida del codice e l'esecuzione di aggiornamenti. Consultare Sviluppare ed eseguire il debug delle pipeline delle tabelle live Delta nei notebook. |
| Parametri | Sfruttare i parametri nelle configurazioni del codice sorgente e della pipeline per semplificare il test e l'estendibilità. Consultare Usare i parametri con le pipeline di tabelle Delta Live. |
| Aggregazioni di asset di Databricks | I bundle di asset di Databricks consentono di spostare le configurazioni della pipeline e il codice sorgente tra aree di lavoro. Consultare Convertire una pipeline Delta Live Tables in un progetto Databricks Asset Bundle. |
Creare set di dati di esempio per lo sviluppo e il test
Databricks consiglia di creare set di dati di sviluppo e test per testare la logica della pipeline con dati previsti e record potenzialmente non validi o danneggiati. Esistono diversi modi per creare set di dati che possono essere utili per lo sviluppo e il test, tra cui:
- Selezionare un subset di dati da un set di dati di produzione.
- Usare dati anonimi o generati artificialmente per le origini contenenti informazioni personali.
- Creare dati di test con risultati ben definiti in base alla logica di trasformazione downstream.
- Prevedere potenziali danneggiamenti dei dati, record in formato non valido e modifiche ai dati upstream creando record che interrompono le aspettative dello schema dei dati.
Ad esempio, se si dispone di un notebook che definisce un set di dati usando il codice seguente:
CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")
È possibile creare un set di dati di esempio contenente record specifici usando una query simile alla seguente:
CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading
Nell'esempio seguente viene illustrato il filtro dei dati pubblicati per creare un subset dei dati di produzione per lo sviluppo o il test:
CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY
Per usare questi diversi set di dati, creare più pipeline con i notebook che implementano la logica di trasformazione. Ogni pipeline può leggere i dati dal set di dati input_data, ma è configurato per includere il notebook che crea il set di dati specifico per l'ambiente.