Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

Ciao a tutti, mi chiamo Alessandro e sono un ingegnere della qualità dei dati, che si occupa di controllare la qualità dei dati. In questo articolo parlerò di come sono arrivato a questo punto e perché nel 2020 questa area del testing ha raggiunto il suo apice.

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

Tendenza globale

Il mondo di oggi sta vivendo un'altra rivoluzione tecnologica, uno degli aspetti di questa è l'uso dei dati accumulati da parte di diverse aziende per alimentare il loro ciclo di vendita, profitto e PR. Sembra che avere buoni dati (di qualità) e menti capaci di trasformarli in denaro (elaborarli correttamente, visualizzarli, costruire modelli di machine learning, ecc.) sia diventato oggi la chiave del successo per molti. Se 15-20 anni fa lavorare intensamente sull'accumulo e la monetizzazione dei dati era appannaggio principalmente delle grandi aziende, oggi è alla portata di quasi tutte le aziende sensate.

Di conseguenza, alcuni anni fa, tutti i portali di ricerca lavoro nel mondo si sono riempiti di offerte per Data Scientist, perché si era convinti che assumere un professionista del genere potesse portare alla creazione di un super modello di machine learning, prevedere il futuro e compiere un “salto quantico” per l'azienda. Col tempo, le persone hanno capito che questo approccio non funziona quasi mai, poiché non tutti i dati che arrivano a questo tipo di specialisti sono adeguati per l'allenamento dei modelli.

E sono cominciate le richieste da parte dei Data Scientist: "Acquistiamo altri dati da questi e quelli…", "Ci mancano dati…", "Abbiamo bisogno di ulteriori dati e possibilmente di qualità…". Basandosi su queste richieste, sono emerse numerose interazioni tra le aziende che possiedono vari set di dati. Naturalmente, questo ha richiesto un'organizzazione tecnica del processo - collegarsi alla fonte dei dati, estrarli, controllare che siano stati caricati in modo completo, ecc. Il numero di questi processi è aumentato e oggi abbiamo una grande domanda per un altro tipo di specialisti - ingegneri della qualità dei dati - coloro che monitorano il flusso dei dati nel sistema (data pipelines), la qualità dei dati in entrata e in uscita, traendo conclusioni sulla loro sufficienza, integrità e altre caratteristiche.

La tendenza verso ingegneri della qualità dei dati ci è arrivata dagli Stati Uniti, dove, nel bel mezzo dell'era capitalista, nessuno è disposto a perdere la battaglia per i dati. Qui di seguito ho presentato screenshot di due dei siti di ricerca lavoro più popolari negli USA: www.monster.com e www.dice.com — sui quali sono visualizzati i dati aggiornati al 17 marzo 2020 sul numero di offerte di lavoro ricevute, in base alle parole chiave: Data Quality e Data Scientist.

www.monster.com

Data Scientists – 21416 offerte
Data Quality – 41104 offerte

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia
Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

www.dice.com

Data Scientists – 404 offerte
Data Quality – 2020 offerte

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia
Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

È ovvio che queste professioni non competono affatto tra loro. Con gli screenshot ho semplicemente voluto illustrare la situazione attuale del mercato del lavoro in termini di richieste per ingegneri della qualità dei dati, di cui ora c'è molta più necessità rispetto ai Data Scientist.

Nel giugno 2019, EPAM, in risposta alle esigenze del moderno mercato IT, ha separato l'area della qualità dei dati in una pratica autonoma. Gli ingegneri della qualità dei dati gestiscono i dati durante il loro lavoro quotidiano, verificano il loro comportamento in nuove condizioni e sistemi, controllano la pertinenza dei dati, la loro sufficienza e attualità. Nonostante tutto ciò, nella pratica, gli ingegneri della qualità dei dati dedicano davvero poco tempo al testing funzionale classico, MA questo dipende molto dal progetto (farò un esempio più avanti).

Le responsabilità degli ingegneri della qualità dei dati non si limitano a controlli manuali/automatici di routine su "nulls, count e sums" nelle tabelle del DB, ma richiedono una comprensione profonda delle esigenze aziendali del cliente e, di conseguenza, la capacità di trasformare i dati disponibili in informazioni commerciali utili.

Teoria della qualità dei dati

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

Per avere una visione più completa del ruolo di un ingegnere della qualità dei dati, analizziamo cos'è la qualità dei dati in teoria.

Qualità dei dati — è una delle fasi del Data Management (un intero mondo che vi lasciamo per un autoapprendimento) e si occupa dell'analisi dei dati secondo i seguenti criteri:

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia
Non credo sia necessario scomporre ogni punto (in teoria chiamati "data dimensions"), sono ben descritti nell'immagine. Ma il processo di testing non implica la copia rigorosa di queste caratteristiche nei test case e la loro verifica. Nella qualità dei dati, come in qualsiasi altro tipo di testing, è necessario partire prima di tutto dai requisiti di qualità dei dati concordati con gli stakeholder del progetto che prendono decisioni aziendali.

A seconda del progetto, un ingegnere Data Quality può svolgere diverse funzioni, da un semplice tester automatizzato che effettua una valutazione superficiale della qualità dei dati, a un professionista che esegue una profilazione approfondita in base ai criteri sopra menzionati.

Una descrizione molto dettagliata dei processi di Data Management, Data Quality e argomenti correlati è fornita nel libro intitolato «DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition». Consiglio vivamente questo libro come introduzione a questo tema (il link lo trovate alla fine dell'articolo).

La mia storia

Nel settore IT, ho iniziato come Junior Tester in aziende di prodotto per diventare Lead Data Quality Engineer in EPAM. Dopo circa due anni di lavoro come tester, ero fermamente convinto di aver svolto ogni tipo di testing: regressivo, funzionale, di stress, di stabilità, di sicurezza, UI, ecc., e di aver utilizzato un gran numero di strumenti di testing, lavorando con tre linguaggi di programmazione: Java, Scala, Python.

Ripensando al passato, capisco il perché della mia variegata esperienza professionale: ho partecipato a progetti focalizzati sulla gestione dei dati, grandi e piccoli. Questo mi ha introdotto a una vasta gamma di strumenti e opportunità di crescita.

Per apprezzare la varietà di strumenti e possibilità di acquisire nuove conoscenze e competenze, basta guardare l'immagine qui sotto, che mostra i più popolari nel mondo «Data & AI».

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia
Tali illustrazioni sono prodotte annualmente da uno dei noti venture capitalist, Matt Turck, proveniente dallo sviluppo software. Ecco link il suo blog e la società di venture capital, dove lavora come partner.

Ho registrato una rapida crescita professionale, soprattutto quando ero l'unico tester del progetto o, perlomeno, all'inizio di un progetto. In quel momento, sei responsabile dell'intero processo di testing e non hai la possibilità di fare un passo indietro, solo di andare avanti. Inizialmente questo mi spaventava, ma ora vedo chiaramente tutti i vantaggi di questa esperienza:

  • Inizi a comunicare con l'intero team come mai prima d'ora, poiché non ci sono intermediari nel dialogo: né test manager né colleghi tester.
  • L’immersione nel progetto diventa incredibilmente profonda e hai informazioni su tutti i componenti, sia in generale che nei dettagli.
  • Gli sviluppatori non ti vedono più come 'quello del testing che non si sa cosa faccia', ma piuttosto come un pari, che porta un enorme valore al team con i suoi test automatizzati e la capacità di prevedere i bug in un determinato punto del prodotto.
  • Come risultato, sei più efficace, più qualificato, più richiesto.

Con l'espansione del progetto, in 100% dei casi, sono diventato mentore per i nuovi tester che vi arrivavano, insegnando loro e trasmettendo le conoscenze che avevo acquisito. Tuttavia, a seconda del progetto, non sempre ricevevo specialisti di alto livello nel testing automatizzato e c'era la necessità di formarli nell'automazione (per chi era interessato), o di creare strumenti per il loro utilizzo nelle attività quotidiane (strumenti per la generazione di dati e il loro caricamento nel sistema, strumenti per test di carico/testing di stabilità 'veloce' ecc.).

Un esempio concreto di progetto

Sfortunatamente, a causa degli obblighi di riservatezza, non posso parlare in dettaglio dei progetti su cui ho lavorato, ma posso fornire esempi tipici di compiti di un Data Quality Engineer in uno di questi progetti.

L'obiettivo del progetto era implementare una piattaforma per la preparazione dei dati per l'addestramento di modelli di machine learning. Il cliente era una grande azienda farmaceutica dagli Stati Uniti. Tecnologicamente, si trattava di un cluster Kubernetes, che si alzava su AWS EC2 istanze, con diversi microservizi e una base Open Source del progetto EPAM — Legion, adattato alle esigenze del cliente specifico (ora il progetto è rinato in odahu). I processi ETL erano organizzati tramite Apache Airflow e trasferivano i dati dal sistema SalesForce del cliente in AWS S3 Buckets. Dopo, un'immagine Docker del modello di machine learning veniva implementata sulla piattaforma, che si addestrava su dati aggiornati e forniva previsioni tramite API REST, rispondendo alle esigenze aziendali e risolvendo problemi specifici.

Visivamente, il tutto aveva un aspetto simile a questo:

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia
C'è stata abbondanza di test funzionali in questo progetto, e considerando la velocità dello sviluppo delle funzionalità e la necessità di mantenere il ritmo del ciclo di rilascio (sprint di due settimane), era fondamentale pensare subito all'automazione dei test dei nodi critici del sistema. La maggior parte della piattaforma basata su Kubernetes era coperta da test automatici, realizzati in Robot Framework + Python, ma era anche necessario mantenere e ampliare questi test. Inoltre, per facilità del cliente, è stata creata una GUI per gestire i modelli di machine learning, implementati sul cluster, insieme alla possibilità di specificare da dove e verso dove trasferire i dati per l'addestramento dei modelli. Questa ampia integrazione ha comportato un'espansione delle verifiche funzionali automatizzate, che sono state per lo più realizzate tramite chiamate API REST e un numero ridotto di test end-to-end. Circa a metà di tutto questo percorso, si è unito a noi un tester manuale che si è dimostrato eccellente nel test di accettazione delle versioni del prodotto e nella comunicazione con il cliente riguardo all'accettazione di un nuovo rilascio. Inoltre, grazie all'arrivo di questo nuovo specialista, siamo riusciti a documentare il nostro lavoro e aggiungere alcune verifiche manuali molto importanti, che era difficile automatizzare subito.

Infine, dopo aver raggiunto la stabilità dalla piattaforma e dalla GUI sopra di essa, abbiamo iniziato a costruire pipeline ETL utilizzando gli Apache Airflow DAG. Il controllo automatizzato della qualità dei dati è stato effettuato scrivendo appositi DAG di Airflow che controllavano i dati in base ai risultati del processo ETL. In questo progetto siamo stati fortunati, e il cliente ci ha fornito accesso a dataset anonimi, su cui abbiamo eseguito i test. I dati sono stati controllati riga per riga per verificare la corrispondenza dei tipi, la presenza di dati danneggiati, il numero totale di record prima e dopo, e il confronto delle trasformazioni effettuate dal processo ETL in termini di aggregazione, modifica dei nomi delle colonne e altro ancora. Inoltre, queste verifiche sono state scalate su diverse fonti di dati, ad esempio oltre a SalesForce anche su MySQL.

Le verifiche finali della qualità dei dati sono state effettuate a livello di S3, dove erano archiviati e pronti per l'uso per l'addestramento dei modelli di machine learning. Per ottenere dati dal file CSV finale, archiviato nel bucket S3 e per la loro validazione, è stato scritto codice utilizzando boto3 client.

C'era anche una richiesta da parte del cliente di archiviare una parte dei dati in un bucket S3 e un'altra parte in un altro. Questo ha richiesto la scrittura di ulteriori verifiche per controllare l'affidabilità di tale suddivisione.

Esperienza generica su altri progetti

Ecco un elenco delle attività tipiche di un ingegnere della qualità dei dati:

  • Preparare dati di test (validi, non validi, grandi, piccoli) tramite uno strumento automatizzato.
  • Caricare il set di dati preparato nella fonte originale e verificare la sua prontezza per l'uso.
  • Eseguire processi ETL per l'elaborazione del set di dati dalla sorgente originale a quella finale o intermedia, utilizzando un determinato insieme di impostazioni (nel caso si possano specificare parametri configurabili per il task ETL).
  • Verificare i dati elaborati dal processo ETL in termini di qualità e conformità ai requisiti aziendali.

In questo caso, l'accento delle verifiche deve cadere non solo sul fatto che il flusso di dati nel sistema abbia funzionato e sia arrivato alla fine (che fa parte del test funzionale), ma principalmente sulla verifica e validazione dei dati rispetto ai requisiti attesi, identificazione di anomalie e altro.

Strumenti

Una delle tecniche per tale controllo dei dati può essere l'organizzazione di verifiche a catena a ciascuna fase di elaborazione dei dati, il cosiddetto "data chain" — controllo dei dati dalla sorgente al punto di utilizzo finale. Questo tipo di verifiche è generalmente implementato scrivendo query SQL di controllo. È chiaro che tali query devono essere il più leggere possibile e controllare singoli aspetti della qualità dei dati (metadati delle tabelle, righe vuote, NULL, errori di sintassi — altri attributi richiesti delle verifiche).

Nel caso di test di regressione, in cui si usano set di dati già pronti (immutabili o leggermente modificabili), nel codice dei test automatici possono essere memorizzati già pronti modelli di verifica dei dati rispetto alla qualità (descrizioni dei metadati attesi delle tabelle; campioni di oggetti a riga, che possono essere selezionati casualmente durante il test, e altro).

Durante i test, è necessario anche scrivere processi ETL di prova, utilizzando framework come Apache Airflow, Apache Spark o strumenti black-box cloud come il GCP Dataprep, GCP Dataflow e altro ancora. Questa situazione obbliga il test engineer a immergersi nei principi di funzionamento degli strumenti sopra citati, permettendo di condurre test funzionali (ad esempio, sui processi ETL già esistenti nel progetto) in modo più efficace e di utilizzarli per la verifica dei dati. In particolare, per Apache Airflow sono già disponibili operatori pronti per lavorare con i popolari database analitici, come il GCP BigQuery. Un esempio base del suo utilizzo è già stato descritto qui, quindi non mi ripeterò.

Oltre alle soluzioni pronte, nessuno vieta di implementare le proprie tecniche e strumenti. Questo non solo porterà vantaggi al progetto, ma anche al Data Quality Engineer, che così amplerà la sua visione tecnica e le sue abilità di programmazione.

Come funziona in un progetto reale

Una buona illustrazione degli ultimi paragrafi sulla «data chain», ETL e verifiche sempre presenti è il seguente processo da uno dei progetti reali:

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

Qui, nell'ingresso della nostra sistema, si raccolgono diversi dati (naturalmente, preparati da noi): validi, non validi, misti, ecc.; successivamente vengono filtrati e immagazzinati temporaneamente, per poi essere soggetti a una serie di trasformazioni e infine posizionati nel data store finale, da dove si svolgeranno le analisi, la costruzione di data mart e la ricerca di business insights. In un tale sistema, senza controllare funzionalmente il funzionamento dei processi ETL, ci concentriamo sulla qualità dei dati prima e dopo le trasformazioni, nonché sull'uscita in analisi.

Riassumendo quanto detto, indipendentemente dai luoghi in cui ho lavorato, sono sempre stato coinvolto in progetti Data, che condividevano le seguenti caratteristiche:

  • Solo attraverso l'automazione si possono testare alcuni casi e raggiungere un ciclo di rilascio accettabile per il business.
  • Il tester in un progetto del genere è uno dei membri più rispettati del team, poiché porta un enorme vantaggio a ciascuno dei partecipanti (accelerazione dei test, dati di qualità per il Data Scientist, identificazione dei difetti nelle prime fasi).
  • Non importa se lavori sulla tua attrezzatura o nel cloud: tutte le risorse sono astratte in cluster come Hortonworks, Cloudera, Mesos, Kubernetes, ecc.
  • I progetti sono costruiti su un approccio a microservizi, predominano i calcoli distribuiti e paralleli.

Vorrei sottolineare che, impegnandosi nella testing della Data Quality, il professionista si sposta sul codice del prodotto e sugli strumenti utilizzati.

Caratteristiche distintive del testing della Data Quality

Inoltre, ho identificato alcune (preavviso: queste sono MOLTO generali e puramente soggettive) caratteristiche distintive del testing nei progetti Data (Big Data) rispetto ad altri ambiti:

Tester di grandi e piccoli dati: tendenze, teoria, la mia storia

Link utili

  1. Teoria: DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition.
  2. Centro di formazione EPAM 
  3. Materiali raccomandati per un Data Quality engineer alle prime armi:
    1. Corso gratuito su Stepik: Introduzione ai database
    2. Corso su LinkedIn Learning: Data Science Foundations: Data Engineering.
    3. Articoli:
    4. Video:

Conclusione

Qualità dei dati è un settore molto giovane e promettente, farne parte significa essere parte di una sorta di startup. Entrando nella Data Quality, ti immergerai in un gran numero di tecnologie moderne richieste, ma la cosa più importante è che si apriranno davanti a te enormi opportunità per generare e realizzare le tue idee. Potrai applicare un approccio di miglioramento continuo non solo nel progetto ma anche per te stesso, sviluppandoti in modo costante come professionista.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS | ProHoster