6 scomode verità su Apache Airflow (e cosa fare al riguardo)

I team dei dati che lavorano con processi di acquisizione complessi adorano Apache Airflow.

Puoi definire i tuoi workflow in Python, il sistema ha un'ampia estensibilità e offre una buona varietà di plug-in. L'ottantasei percento dei suoi utenti si dichiara soddisfatto e intende continuare a utilizzarlo rispetto ad altri motori per workflow. Un uguale numero di persone afferma di consigliare il prodotto.

Ma, come tutti i software, e soprattutto quelli di tipo open source, Airflow è afflitto da una serie di lacune e carenze che dovrai compensare. Per gli sviluppatori che stanno appena iniziando a familiarizzare con il sistema, ciò significa che l'inizio è lento e il cammino è difficile. In questo articolo, discutiamo di questi problemi e di alcune possibili soluzioni.

Airflow è un cavallo di battaglia con i paraocchi. Non fa nulla per correggere la rotta se qualcosa va storto con i dati, ma solo con la pipeline. Praticamente ogni utente ha sperimentato qualche versione di Airflow indicante che un lavoro è completato per poi controllare i dati solo per scoprire che mancava una colonna ed è tutto sbagliato, oppure che nessun dato è effettivamente passato attraverso i sistemi.

Questo è particolarmente vero una volta che l'organizzazione dei dati matura e si passa da 10 a migliaia di grafici aciclici di dati (DAG). In tale situazione, è probabile che tu stia utilizzando quei DAG per inserire dati da API e fonti di dati esterne, il che rende ancora più difficile il controllo della qualità dei dati in Airflow. Non puoi "pulire" il set di dati di origine o implementare lì le tue policy di governance.

Sebbene tu possa creare avvisi Slack per controllare manualmente ogni esecuzione, per incorporare Airflow come parte utile della tua organizzazione di data engineering e rispettare i tuoi SLA, devi automatizzare i controlli di qualità. E per farlo, devi avere visibilità non solo per vedere se un lavoro è stato eseguito, ma anche per capire se è stato eseguito correttamente. E se non è stato eseguito correttamente, perché e da dove è partito l'errore. Altrimenti, vivrai la stessa cosa a ripetizione.

Non si tratta di una sfida semplice e, se vogliamo essere sinceri, è il motivo per cui è stato creato IBM® Databand. La maggior parte degli strumenti di observability dei prodotti, come Datadog e New Relic, non sono stati concepiti per analizzare le pipeline e non riescono a isolare l'origine dei problemi, a raggruppare i problemi concomitanti per suggerire una causa principale o delle correzioni.

Tuttavia, la necessità dell'osservabilità non è ancora pienamente compresa, nemmeno all'interno della comunità Airflow. Oggi, solo il 32% afferma di aver implementato la misurazione della qualità dei dati, anche se il fatto che i redattori del sondaggio pongano questa domanda è un segno di miglioramento. Non avevano posto questa domanda nei sondaggi del 2019 o del 2020.

Come si monitora la qualità dei dati in Airflow? In realtà, Airflow ti porta a metà strada. Come sottolineano i suoi responsabili, "Quando i workflow vengono definiti come codice, diventano più gestibili, controllabili in versione, testabili e collaborativi".

Airflow offre quella rappresentazione formale del codice. Quello di cui hai bisogno è uno strumento di observability realizzato specificamente per monitorare le pipeline di dati. Quelli realizzati per monitorare i prodotti sono una misura a metà strada, ma di solito fanno parte del percorso perché hanno già queste licenze.

Riscontriamo che le organizzazioni ingegneristiche attraversano diverse fasi nel loro percorso verso la piena maturità dell'osservabilità:

• Pre-consapevolezza: mancato monitoraggio della qualità dei dati (68% della community Airflow).
• Nastro adesivo e filo di imballaggio: prendere in prestito gli strumenti di observability del prodotto e farlo funzionare, anche se non è l'ideale.
• Soluzione progettata su misura: adozione di strumenti di osservabilità a pipeline completa come Databand per automatizzare gli avvisi, isolare le cause principali e applicare correzioni più rapidamente. Imposta il machine learning in base ai parametri di dati attesi, ricevi avvisi Slack che indicano dati mancanti o cambiamenti nello schema in Airflow Scheduler, traccia il percorso dei problemi e conduci test retrospettivi con i dati storici.

Imparare a usare Airflow richiede un investimento di tempo. Numerosi articoli e thread di Stack Overflow documentano le difficoltà degli sviluppatori che si bloccano con domande di base, come: "Perché il lavoro che avevo programmato non è iniziato?" (Una risposta comune: Airflow Scheduler inizia la pianificazione alla fine del periodo di tempo pianificato, non all'inizio. Ne parlerò più avanti.)

Inoltre, per diventare competente con Airflow, dovrai imparare a usare Celery Executor e RabbitMQ o Redis, e non c'è modo di evitarlo.

Questa frizione è sufficiente perché alcune organizzazioni come la società di software CMS Bluecore decidessero che era più semplice codificare essenzialmente la propria interfaccia Airflow. In questo modo, ogni nuovo sviluppatore assunto o assegnato non avrebbe dovuto imparare tutti i nuovi operatori, ma avrebbe potuto fare affidamento su quelli di Kubernetes con cui aveva già familiarità.

Questi ostacoli all'apprendimento rappresentano un problema ricorrente per la community, tanto che i "problemi di onboarding" si sono meritati una domanda a parte nel sondaggio della community di Airflow del 2021 (nella foto sotto).

Tra le principali lamentele degli utenti c'erano "la mancanza di best practice sullo sviluppo di DAG" e "l'assenza da un'opzione facile da lanciare". Quest'ultimo problema è stato parzialmente affrontato nella versione 2.0 di Airflow (rilasciata dopo il sondaggio), ma questa versione è eseguita su un database SQLite in cui non è possibile la parallelizzazione e tutto avviene in sequenza.
Come sottolinea la guida rapida di Airflow, "questo è molto limitante" e "si dovrebbe superare molto rapidamente".

Il caso d'uso principale di Airflow è la programmazione di lotti periodici, non di esecuzioni frequenti, come anche la sua stessa documentazione attesta: "I workflow sono per lo più statici o in lento cambiamento". Questo significa che ci sono poche funzionalità per coloro che hanno bisogno di campionare o inviare dati in modo ad hoc e continuativo, il che lo rende meno che ideale per alcuni casi d'uso di ETL e data science.

C'è di più. Ne abbiamo accennato in precedenza, ma Airflow Scheduler esegue i processi schedule_interval alla fine dell'intervallo di avvio di Airflow Scheduler, non all'inizio, il che significa che dovrai fare più calcoli di quanti vorresti e, occasionalmente, potresti avere delle sorprese.

Per eseguire correttamente questi lavori pianificati, è necessario apprendere le sfumature specifiche di Airflow tra operatori e attività, il funzionamento dei DAG, gli argomenti predefiniti, il database dei metadati di Airflow, l'home director per l'implementazione dei DAG e molto altro ancora.

La soluzione? Potresti prendere in considerazione l'idea di unirti al 6% utenti di Airflow che sviluppano la propria interfaccia grafica e rinominano gli operatori con termini che hanno più senso per loro.

Troverai che molte pratiche tradizionali di sviluppo software e DevOps sono assenti in Airflow, e una delle principali è la capacità di mantenere le versioni delle tue pipeline. Non esiste un modo semplice per documentare tutto ciò che hai costruito e, se necessario, ripristinare una versione precedente. Se, ad esempio, elimini un'attività dal tuo DAG e la reimplementi, perdi i metadati associati sull'istanza dell'attività.

Questo rende Airflow un po' fragile e, a meno che tu non abbia scritto uno script per acquisire tutto ciò in modo autonomo, rende i problemi di debug molto più complessi. Non è possibile effettuare un test retrospettivo delle possibili correzioni rispetto ai dati storici per convalidarle.

Ancora una volta, Airflow fornisce la rappresentazione formale del codice. La tua sfida è applicare altri strumenti di sviluppo software e DevOps per colmare la funzionalità mancante.

Non c'è molto altro da dire qui. Non è possibile, a meno che non si utilizzino file Docker Compose specifici non facenti parte dell'archivio principale.

Airflow Scheduler non funziona? Meglio riempire la tazzina di caffè. Potresti aver bisogno di un bel po' di tempo per eseguire il debug.

Questo perché, a nostro avviso, Airflow non distingue sufficientemente tra operatori che orchestrano e operatori che eseguono. Molti operatori fanno entrambe le cose. E sebbene questo possa aver aiutato con la codifica iniziale della piattaforma, è un'inclusione fatale che rende molto difficile il debug. Se qualcosa va storto, gli sviluppatori dovranno esaminare prima i parametri DataFlow e poi l'operatore stesso, ogni singola volta.

Per questo motivo, gli strumenti come Databand possono rivelarsi di grande aiuto. Databand eccelle nell'aiutarti a comprendere lo stato della tua infrastruttura a tutti i livelli: Airflow globale, DAG, attività e parti rivolte agli utenti. Invece di dedicare tempo all'ingegneria dei dati per apprendere funzionalità altamente specifiche, Databand permette ai data engineer di concentrarsi davvero sulla risoluzione dei problemi per l'azienda.

Come ogni collaboratore open source che si prende del tempo per proporre nuove modifiche, speriamo che questo articolo sia interpretato come la lettera d'amore che è. Noi di Databand siamo contributori attivi alla comunità di Airflow e siamo ansiosi di vederlo crescere oltre i suoi limiti attuali e servire meglio un maggior numero di casi d'uso di ETL e data science.

Come abbiamo detto prima, l'86% degli utenti ha intenzione di continuare a utilizzarlo rispetto ad altri motori operativi. Un altro 86% afferma che lo consiglierebbe vivamente. Siamo lieti di poter dire che apparteniamo a entrambi i gruppi: è uno strumento fantastico. E per coloro che stanno appena iniziando a familiarizzare con Airflow, sappiate che se vi avvicinate a questo programma tenendo a mente i problemi sopra menzionati, Airflow Scheduler può valere lo sforzo. Scopri come Databand riunisce tutte le attività di observability Airflow per semplificare e centralizzare l'observability Apache Airflow. Se desideri approfondire ulteriormente l'argomento, prenota subito una demo.