MLOps: orchestrazione della pipeline di dati
Parte 1 di Dataform 101: Fondamenti di un singolo repository, Dataform multiambiente con controllo degli accessi con privilegi minimi e infrastruttura come impostazione del codice
Formato dati è un nuovo servizio integrato nella suite di servizi GCP che consente ai team di sviluppare e rendere operative pipeline di dati complesse basate su SQL. Dataform consente l'applicazione delle migliori pratiche di ingegneria del software come test, ambienti, controllo delle versioni, gestione delle dipendenze, orchestrazione e documentazione automatizzata alle pipeline di dati. È un cavallo di battaglia per l'orchestrazione del flusso di lavoro SQL serverless all'interno di GCP. In genere, come mostrato nell'immagine sopra, Dataform prende i dati grezzi, li trasforma con tutte le migliori pratiche ingegneristiche e produce dati adeguatamente strutturati pronti per il consumo.
L'ispirazione per questo post è arrivata mentre ero lì migrazione uno dei Dataform legacy dei nostri progetti dall'interfaccia utente web a GCP BigQuery. Durante la migrazione, ho trovato termini come configurazione del rilascio, configurazione del flusso di lavoro e area di lavoro di sviluppo davvero confusi e difficili da comprendere. Ciò serve come motivazione per scrivere un post che spiega alcune delle nuove terminologie utilizzate nel Dataform GCP. Inoltre, vorrei toccare alcuni flussi di base che sottolineano le operazioni Dataform multiambiente a repository singolo in GCP. Esistono diversi modi per configurare Dataform, quindi assicurati di dare un'occhiata migliori pratiche da Google.
Questa è la prima parte di una serie in due parti che tratta i fondamenti e la configurazione di Dataform. Nella parte 2, fornirei una panoramica della configurazione di Terraform che mostra come implementare il controllo di accesso minimo durante il provisioning di Dataform. Se vuoi dare una sbirciatina a questo, assicurati di dare un'occhiata a pronti contro termine.
L'implementazione in Dataform è simile al flusso di lavoro GitHub. Confronterò la somiglianza tra i due e creerò analogie per renderlo comprensibile. È facile immaginare Dataform come un repository GitHub locale. Durante la configurazione di Dataform, verrà richiesto che un repository remoto sia configurato in modo simile al modo in cui GitHub locale è accoppiato con l'origine remota. Tenendo presente questa configurazione dello scenario, esaminiamo rapidamente alcune terminologie Dataform.
Aree di lavoro di sviluppo
Questo è analogo al ramo GitHub locale. In modo simile al modo in cui viene creato un ramo da GitHub main, una nuova area di lavoro di sviluppo Dataform estrarrebbe una copia modificabile del codice repository Dataform principale. Gli spazi di lavoro di sviluppo sono indipendenti l'uno dall'altro in modo simile ai rami GitHub. Lo sviluppo e le sperimentazioni del codice avranno luogo all'interno dell'area di lavoro di sviluppo e una volta eseguito il commit e il push del codice, viene creato un ramo remoto con nome simile all'area di lavoro di sviluppo. Vale la pena ricordare che il repository GitHub da cui un codice modificabile viene archiviato in un'area di lavoro di sviluppo è configurabile. Potrebbe provenire dal ramo principale o da qualsiasi altro ramo nel repository remoto.
Configurazione del rilascio
Dataform utilizza un mix di .sqlx script con Javascript .js per le trasformazioni e la logica dei dati. Di conseguenza, genera innanzitutto una compilazione della base di codice per ottenere una rappresentazione della pipeline standard e riproducibile della base di codice e garantire che gli script possano essere materializzati in dati. La configurazione della versione è il processo automatizzato mediante il quale avviene questa compilazione. Al momento della configurazione, Dataform estrae il codice in un repository principale remoto (questo è configurabile e può essere modificato per indirizzare qualsiasi ramo remoto) e lo compila in un file di configurazione JSON. Il processo di verifica del codice e di generazione della compilazione è ciò che copre la configurazione del rilascio.
Configurazione del flusso di lavoro
Quindi l'output della configurazione di rilascio è a .json file di configurazione. La configurazione del flusso di lavoro determina quando eseguire il file di configurazione, quale identità dovrebbe eseguirlo e in quale ambiente verrà manifestato o scritto l'output del file di configurazione.
Poiché la configurazione del flusso di lavoro richiederebbe l'output della configurazione del rilascio, è ragionevole garantire che venga eseguito dopo la configurazione del rilascio. Il motivo è che la configurazione del rilascio dovrà prima autenticarsi nel repository remoto (che a volte fallisce), estrarre il codice e compilarlo. Questi passaggi avvengono in pochi secondi ma potrebbero richiedere più tempo in caso di errore della connessione di rete. Poiché la configurazione del flusso di lavoro richiede il file .jsonfile compilato generato dalla configurazione del rilascio, ha senso pianificarlo più tardi rispetto alla configurazione del rilascio. Se pianificata allo stesso tempo, la configurazione del flusso di lavoro potrebbe utilizzare la compilazione precedente, il che significa che le modifiche più recenti non verranno immediatamente riflesse nelle tabelle BQ fino all'esecuzione della configurazione del flusso di lavoro successiva.
Ambienti
Una delle caratteristiche di Dataform è la funzionalità che consente di manifestare il codice in diversi ambienti come sviluppo, staging e produzione. Lavorare con più ambienti comporta la sfida di come impostare Dataform. I repository dovrebbero essere creati in più ambienti o in un solo ambiente? Google ha discusso al meglio alcuni di questi compromessi in Dataform pratiche sezione. Questo post illustra la configurazione di Dataform per ambienti di gestione temporanea e di produzione con entrambi i dati materializzati in entrambi gli ambienti da un unico repository.
Gli ambienti sono configurati come progetti GCP con un account di servizio personalizzato per ciascuno. Dataform viene creato solo nell'ambiente/progetto di staging perché apporteremo molte modifiche ed è meglio sperimentare all'interno dell'ambiente di staging (o non di produzione). Inoltre, l'ambiente di staging viene selezionato come l'ambiente in cui si manifesta il codice di sviluppo. Ciò significa che il set di dati e le tabelle generati dall'area di lavoro di sviluppo vengono manifestati all'interno dell'ambiente di staging.
Una volta terminato lo sviluppo, il codice viene impegnato e inviato al repository remoto. Da lì, è possibile generare un PR e unirlo al repository principale dopo la revisione. Durante il flusso di lavoro pianificato, vengono eseguite sia le configurazioni di rilascio che quelle di flusso di lavoro. Dataform è configurato per compilare codice dal ramo principale ed eseguirlo all'interno dell'ambiente di produzione. Pertanto, solo il codice rivisto va in produzione e l'eventuale codice di sviluppo rimane nell'ambiente di staging.
In sintesi, dal flusso dell'architettura Dataform sopra riportato, il codice sviluppato negli spazi di lavoro di sviluppo viene manifestato nell'ambiente di staging o inviato a GitHub remoto dove viene sottoposto a peer review e unito al ramo principale. La configurazione del rilascio compila il codice dal ramo principale mentre la configurazione del flusso di lavoro prende il codice compilato e ne manifesta i dati nell'ambiente di produzione. Pertanto, solo il codice rivisto nel ramo principale di GitHub si manifesta nell'ambiente di produzione.
L'autenticazione per Dataform potrebbe essere complessa e complicata, soprattutto durante la configurazione per più ambienti. Utilizzerò esempi di ambienti di staging e produzione per spiegare come è possibile farlo. Analizziamo dove è necessaria l'autenticazione e come viene eseguita.
La figura sopra mostra un semplice flusso di lavoro Dataform che possiamo utilizzare per tenere traccia di dove è necessaria l'autenticazione e per quali risorse. Il flusso descrive cosa accade quando Dataform viene eseguito nell'area di lavoro di sviluppo e nei tempi previsti (configurazioni di rilascio e flusso di lavoro).
Utente macchina
Parliamo degli utenti della macchina. Dataform richiede credenziali per accedere a GitHub durante il check-out del codice archiviato su un repository remoto. È possibile utilizzare credenziali individuali, ma la pratica migliore è utilizzare un utente macchina in un'organizzazione. Questa pratica garantisce che l'orchestrazione della pipeline Dataform sia indipendente dalle identità individuali e non venga influenzata dalla loro abbandono. Configurare l'utente della macchina significa utilizzare un'identità non legata a un individuo per configurare l'account GitHub come dettagliato Qui. Nel caso di Dataform, viene generato un token di accesso personale (PAT) per l'account utente della macchina e archiviato come segreto nel gestore segreti GCP. L'utente della macchina deve essere aggiunto anche come collaboratore esterno al repository remoto Dataform con accesso in lettura e scrittura. Vedremo come Dataform è configurato per accedere al segreto più avanti nel codice Terraform. Se l'utente decide di utilizzare la propria identità invece di un utente macchina, è necessario generare un token come dettagliato Qui.
Flusso di autenticazione GitHub
Dataform utilizza il suo account di servizio predefinito per l'implementazione, quindi quando deve essere eseguita un'azione Dataform, inizia con l'account di servizio predefinito. Presumo che tu abbia configurato un utente macchina, aggiunto l'utente come collaboratore al repository remoto e aggiunto l'utente PAT come segreto al gestore segreti GCP. Per autenticarsi su GitHub, l'account di servizio predefinito deve estrarre il segreto dal gestore dei segreti. È richiesto un account di servizio predefinito secretAccessor ruolo per accedere al segreto. Una volta effettuato l'accesso al segreto, l'account di servizio predefinito ora può impersonare l'utente della macchina e poiché l'utente della macchina viene aggiunto come collaboratore nel repository Git remoto, l'account di servizio predefinito ora ha accesso al repository GitHub remoto come collaboratore. Il flusso è mostrato nella figura del flusso di lavoro di autenticazione GitHub.
Autenticazione dell'area di lavoro di sviluppo
Quando l'esecuzione viene attivata dall'area di lavoro di sviluppo, l'account del servizio predefinito presuppone che l'account del servizio personalizzato dell'ambiente di staging manifesti l'output all'interno dell'ambiente di staging. Per poter rappresentare l'account del servizio personalizzato dell'ambiente di staging, l'account del servizio predefinito richiede il file iam.serviceAccountTokenCreator ruolo nell'account del servizio di gestione temporanea. Ciò consente all'account di servizio predefinito di creare un token di breve durata, simile al PAT utilizzato per impersonare l'utente della macchina, per l'account di servizio personalizzato di staging e, come tale, di impersonificarlo. Pertanto, all'account del servizio personalizzato di staging vengono concesse tutte le autorizzazioni necessarie per scrivere sulle tabelle BQ e l'account del servizio predefinito erediterà queste autorizzazioni quando lo rappresenta.
Autenticazione della configurazione del flusso di lavoro
Dopo aver controllato il repository, la configurazione del rilascio genererà una configurazione compilata .jsonfile da cui le configurazioni del flusso di lavoro genereranno i dati. Per scrivere i dati nelle tabelle BQ di produzione, l'account di servizio predefinito richiede il file iam.serviceAccountTokenCreator ruolo nell'account del servizio personalizzato di produzione. Analogamente a quanto avviene per l'account del servizio personalizzato di staging, all'account del servizio di produzione vengono concesse tutte le autorizzazioni necessarie per scrivere nelle tabelle BQ dell'ambiente di produzione e l'account del servizio predefinito erediterà tutte le autorizzazioni quando lo rappresenta.
Riepilogo
In sintesi, l'account di servizio predefinito è il protagonista principale. Impersona l'utente macchina per autenticarsi su GitHub come collaboratore utilizzando l'utente macchina PAT. Inoltre, esegue l'autenticazione negli ambienti di staging e di produzione impersonando i rispettivi account di servizio personalizzati utilizzando un token di breve durata generato con il ruolo serviceAccountTokenCreator. Con questa consapevolezza, è giunto il momento di fornire Dataform all'interno di GCP utilizzando Terraform. Cerca la parte 2 di questo post per questo e / o controlla il pronti contro termine per il codice.
Credito immagine: Tutte le immagini in questo post sono state create dall'autore
Riferimenti
Fonte: towardsdatascience.com
