L'editore di Netology ha parlato con il team leader del gruppo BI in Pavel Sayapin sulle sfide che affrontano i data engineer nel suo team, quali strumenti utilizzano e come avvicinarsi alla scelta degli strumenti per risolvere problemi legati ai dati, inclusi quelli non convenzionali. Pavel è docente nel corso "».
Cosa fanno i data engineer in Profi.ru
Profi.ru è un servizio che facilita l'incontro tra clienti e specialisti di diversi settori. Nel database del servizio ci sono oltre 900.000 specialisti per 700 tipologie di servizi: tutor, riparatori, allenatori, esperti di bellezza, artisti e altri. Ogni giorno vengono registrati oltre 10.000 nuovi ordini — tutto ciò genera circa 100 milioni di eventi al giorno. Mantenere l'ordine in una quantità così grande di dati è impossibile senza data engineer professionisti.
Idealmente, un Data Engineer sviluppa una cultura del lavoro con i dati, grazie alla quale l'azienda può ottenere profitti aggiuntivi o ridurre i costi. Porta valore al business, lavorando in team e fungendo da anello importante tra i vari partecipanti — dai sviluppatori ai consumatori business delle relazioni. Tuttavia, in ogni azienda le responsabilità possono variare, quindi analizziamo questi aspetti attraverso l'esempio di Profi.ru.
Raccolgono dati per supportare le decisioni e li forniscono all'utente finale — top manager, product manager, analista
I dati devono essere comprensibili per prendere decisioni e facili da usare. Non dovrebbe essere necessario cercare una descrizione o formulare complicate query SQL che considerano vari fattori. L'immagine ideale è che l'utente guarda il dashboard e trova tutto ciò di cui ha bisogno. Se mancano dati in qualche segmento, l'utente accede al database e con una semplice query SQL ottiene ciò che serve.
Il posto del processo di Data Quality nella struttura complessiva del data warehouse
Un'importanza particolare è dedicata alla documentazione esplicativa sul lavoro con i dati. Questo semplifica il lavoro sia per il data engineer (che non viene distratto da domande) sia per l'utente dei dati (che può trovare da solo le risposte ai suoi interrogativi). In Profi.ru questi documenti sono raccolti su un forum interno.
Per comodità si intende anche la velocità di accesso ai dati. Velocità = disponibilità in un solo passo, clic — dashboard. Ma nella pratica la situazione è più complessa.
Lo stesso Tableau, dal punto di vista dell'utente finale del dashboard, non permette di visualizzare tutte le possibili dimensioni. L'utente si accontenta dei filtri forniti dal creatore del dashboard. Questo genera due scenari:
- Il creatore realizza molteplici segmenti per il dashboard ⟶ il numero di pagine aumenta considerevolmente. Questo riduce l'accessibilità dei dati: diventa difficile capire dove si trovano le informazioni.
- Il creatore crea solo segmenti chiave. Trovare informazioni è più facile, ma per segmenti leggermente meno standard, bisognerà comunque andare nella base dati o consultare gli analisti. Anche questo influisce negativamente sull'accessibilità.
L'accessibilità è un concetto ampio. Si tratta della disponibilità dei dati nella forma adeguata, della possibilità di ottenere informazioni dai dashboard e del necessario taglio dei dati.
Accumula i dati da tutte le fonti in un unico luogo
Le fonti di dati possono essere interne ed esterne. Ad esempio, per alcune aziende che dipendono da report meteorologici, è necessario raccogliere e conservare dati da fonti esterne.
È importante archiviare le informazioni indicando la fonte, e assicurarsi che i dati siano facilmente reperibili. In Profi.ru, questa funzione è risolta attraverso documentazione automatizzata. La documentazione delle fonti di dati interne utilizza file YML.
Creano dashboard
La visualizzazione dei dati è meglio realizzarla con uno strumento professionale, ad esempio, Tableau.
La maggior parte delle persone prende decisioni in modo emotivo — la chiarezza visiva e l'estetica sono fondamentali. Lo stesso Excel non è molto adatto per la visualizzazione, in quanto non copre tutte le esigenze degli utenti. Per esempio, un product manager ama immergersi nei numeri, ma in modo da trovare comodo farlo. Questo gli consente di risolvere i propri compiti, e non di pensare a come ottenere informazioni e raccogliere metriche.
Una visualizzazione dei dati di qualità consente di prendere decisioni più facilmente e rapidamente.
Maggiore è il grado di una persona, più acuta è la necessità di avere a disposizione, sul telefono, dati aggregati. I dettagli non servono ai top manager — è importante controllare la situazione complessiva, e il BI è uno strumento utile per questo.
Esempio di dashboard per product manager di Profi.ru (una delle schede). Per motivi di riservatezza, i nomi delle metriche e degli assi sono nascosti.
Esempi di compiti reali
Compito 1 — trasferire i dati dai sistemi originali (operativi) a un data warehouse o ETL
Uno dei compiti di routine di un data engineer.
A tal fine possono essere utilizzati:
- script personalizzati eseguiti tramite cron o con l'aiuto di un orchestratore speciale come Airflow o Prefect;
- soluzioni ETL open source: Pentaho Data Integration, Talend Data Studio e altre;
- soluzioni proprietarie: Informatica PowerCenter, SSIS e altre;
- soluzioni cloud: Matillion, Panoply e altre.
Nel formato più semplice, il compito si risolve scrivendo un file YML di circa 20 righe. Ci vogliono circa 5 minuti.
Nel caso più complesso, quando è necessario aggiungere una nuova fonte — ad esempio, un nuovo database — può richiedere fino a diversi giorni.
In Profi, questo semplice compito — con un processo ben collaudato — consiste nei seguenti passaggi:
- Chiarire con il cliente quali dati sono necessari e dove si trovano.
- Capire se ci sono accessi a questi dati.
- Se non ci sono accessi, richiederli agli amministratori.
- Aggiungere un nuovo ramo in Git con il codice del compito in Jira.
- Creare una migrazione per l'aggiunta di dati al modello di ancoraggio tramite uno script Python interattivo.
- Aggiungere i file di caricamento (file YML con la descrizione di dove provengono i dati e in quale tabella vengono inseriti).
- Testare nell'ambiente di staging.
- Caricare i dati nel repository.
- Creare una pull request.
- Sostenere la revisione del codice.
- Dopo aver superato la revisione del codice, i dati vengono caricati nel ramo master e distribuiti automaticamente in produzione (CI/CD).
Compito 2 — posizionare in modo conveniente i dati caricati
Un altro compito frequente è posizionare i dati caricati in modo che l'utente finale (o lo strumento BI) possa lavorarci comodamente, senza dover compiere movimenti superflui per svolgere la maggior parte delle attività. In altre parole, costruire o aggiornare il Dimension Data Store (DDS).
A tal fine possono essere utilizzate soluzioni dal primo compito, poiché anche questo è un processo ETL. Nella variante più semplice, l'aggiornamento del DDS avviene tramite script SQL.
Compito 3 — di tipo atipico
In Profi nasce l'analisi in streaming. Viene generata una grande quantità di eventi dalle squadre di prodotto — li registriamo in ClickHouse. Tuttavia, non è possibile inserire record singoli in grandi quantità, quindi è necessario raggruppare i record in batch. Questo significa che non si può scrivere direttamente — è necessario un gestore intermedio.
Utilizziamo un motore basato su Apache Flink. Per ora, l'ordine delle operazioni è il seguente: il motore elabora il flusso di eventi in ingresso ⟶ li memorizza in pacchetti su ClickHouse ⟶ calcola in tempo reale il numero di eventi negli ultimi 15 minuti ⟶ li trasmette a un servizio che determina se ci sono anomalie - confronta i valori degli ultimi 15 minuti con una retrospettiva di 3 mesi ⟶ se ci sono anomalie, invia una notifica su Slack.
Schema per l'analisi frontale (parte del caricamento)
Il framework Apache Flink garantisce la consegna almeno una volta. Tuttavia, esiste la possibilità di duplicati. Nel caso di RabbitMQ, questo può essere risolto utilizzando il Correlation ID. In questo modo si garantisce una consegna unica ⟶ integrità dei dati.
Calcoliamo il numero di eventi ancora una volta con Apache Flink, visualizzando i dati tramite un dashboard personalizzato, scritto in NodeJS, + frontend in ReactJS. Una rapida ricerca non ha fornito soluzioni simili. Inoltre, il codice si è rivelato semplice: la scrittura non ha richiesto molto tempo.
Il monitoraggio è piuttosto tecnico. Analizziamo le anomalie per prevenire problemi nelle fasi iniziali. Alcune metriche globali significative dell'azienda non sono ancora incluse nel monitoraggio, poiché il settore dell'analisi in streaming è ancora in fase di sviluppo.
Strumenti principali per i data engineer
Le mansioni dei data engineer sono più o meno chiare, ora parliamo un po' degli strumenti utilizzati per affrontarle. Naturalmente, gli strumenti possono (e devono) variare tra le diverse aziende: tutto dipende dal volume dei dati, dalla loro velocità di arrivo e dalla loro eterogeneità. Può anche dipendere dalle preferenze di un esperto verso un particolare strumento, solamente perché ha esperienza con esso e lo conosce bene. In Profi.ru ci siamo concentrati su queste opzioni →
Per la visualizzazione dei dati - Tableau, Metabase
Abbiamo scelto Tableau da tempo. Questo sistema consente di analizzare rapidamente grandi volumi di dati, senza richiedere un'implementazione costosa. Per noi è comodo, bello e familiare - lavoriamo spesso con esso.
Pochi conoscono Metabase, ma è molto buono per la prototipazione.
Degli strumenti di visualizzazione, si può ancora parlare di Superset di Airbnb. La sua caratteristica principale è la possibilità di molte connessioni a database e opportunità di visualizzazione. Tuttavia, per l'utente medio risulta meno conveniente rispetto a Metabase: non è possibile unire le tabelle, per farlo è necessario creare viste separate.
In Metabase è possibile unire le tabelle; inoltre, il servizio lo fa automaticamente tenendo conto dello schema del database. Anche l'interfaccia di Metabase è più semplice e gradevole.
Ci sono davvero molti strumenti: cerca semplicemente il tuo.
Per lo storage dei dati: ClickHouse, Vertica
ClickHouse è uno strumento gratuito e veloce per memorizzare eventi di prodotto. Qui gli analisti possono eseguire analisi autonome (se dispongono dei dati sufficienti) oppure i data engineer prendono gli aggregati e li caricano nuovamente in Vertica per costruire le vetrine.
Vertica è un prodotto fantastico e utile per visualizzare le vetrine finali.
Per la gestione dei flussi di dati e per l'elaborazione: Airflow
Carichiamo i dati tramite strumenti da console. Ad esempio, tramite il client fornito con MySQL, in questo modo le operazioni risultano più rapide.
Il vantaggio degli strumenti da console è la velocità. I dati non vengono trasferiti attraverso la memoria dello stesso processo Python. Gli svantaggi sono la riduzione del controllo sui dati che transitano da un database all'altro.
Il linguaggio di programmazione principale è Python
Python ha una barriera d'ingresso molto più bassa e in azienda ci sono competenze relative a questo linguaggio. Un'altra ragione è che i DAG di Airflow vengono scritti in Python. Questi script sono semplicemente wrapper sui caricamenti, il lavoro principale viene svolto tramite script da console.
Utilizziamo Java per lo sviluppo di analisi in tempo reale.
L'approccio nella scelta degli strumenti per i dati è quello di evitare di creare uno zoo tecnologico.
Ci sono molti strumenti sul mercato per lavorare con i dati in ogni fase: dalla loro generazione all'esposizione su un dashboard per il consiglio di amministrazione. Non è sorprendente che alcune aziende possano avere una serie di soluzioni non collegate, il cosiddetto zoo tecnologico.
Uno zoo tecnologico è composto da strumenti che svolgono le stesse funzioni. Ad esempio, Kafka e RabbitMQ per la messaggistica o Grafana e Zeppelin per la visualizzazione.
è evidente quante soluzioni duplicative possano esistere
In molti possono anche utilizzare diversi strumenti ETL per scopi personali. In Profi si presenta proprio questa situazione. L'ETL principale è su Airflow, ma qualcuno utilizza Pentaho per caricamenti personali. Testano ipotesi e non hanno bisogno di passare questi dati attraverso ingegneri. Gli strumenti di "self-service" sono principalmente utilizzati da specialisti abbastanza esperti che si occupano di attività di ricerca, esplorando nuovi percorsi di sviluppo del prodotto. Il loro set di dati per l'analisi è interessante principalmente per loro, e inoltre, cambia costantemente. Pertanto, non ha senso caricare questi dati sulla piattaforma principale.
Tornando allo zoo. Spesso l'uso di tecnologie duplicate è legato al fattore umano. Team interni isolati sono abituati a lavorare con uno strumento piuttosto che con un altro che l'altra squadra potrebbe non utilizzare. E a volte l'autonomia è l'unica strada per risolvere compiti particolari. Ad esempio, se il team R&D ha bisogno di testare qualcosa usando uno strumento specifico — è semplicemente comodo, qualcuno del team l'ha già utilizzato o c'è un altro motivo. Aspettare che un amministratore di sistema installi e configuri questo strumento richiede tempo. Inoltre, gli amministratori ponderati e meticolosi devono anche dimostrare che è davvero necessario. Così, il team installa lo strumento sulle proprie macchine virtuali e risolve le proprie esigenze specifiche.
Uno zoo di soluzioni non è un problema, a patto che non richieda un notevole dispendio di risorse da parte dell'amministratore per supportare lo strumento. È importante considerare come l'uso dello strumento influisce sulle risorse di supporto.
Un'altra ragione comune per cui emergono nuovi strumenti è il desiderio di provare un prodotto sconosciuto in un'area abbastanza nuova, dove non esistono ancora standard o raccomandazioni validate. L'ingegnere dei dati, come lo sviluppatore, deve sempre esplorare nuovi strumenti nella speranza di trovare soluzioni più efficienti per le sfide attuali o per essere aggiornato su ciò che offre il mercato.
La tentazione di provare nuovi strumenti è davvero grande. Ma per fare una scelta sensata, è necessaria prima di tutto l'autodisciplina. Questa aiuta a non lasciarsi sopraffare completamente dagli impulsi esplorativi e a considerare le possibilità dell'azienda nel supporto infrastrutturale per il nuovo strumento.
Non bisogna utilizzare la tecnologia solo per il gusto di farlo. È meglio affrontare la questione in modo pragmatica: compito ⟶ insieme di strumenti che possono risolvere quel compito.
E poi valutare ciascuno di essi e scegliere il migliore. Ad esempio, questo strumento può risolvere il compito in modo più efficace, ma non ci sono competenze su di esso, e questo è leggermente meno efficace, ma in azienda ci sono persone che sanno come usarlo. Questo strumento è a pagamento, ma facile da mantenere e usare, mentre questo è un open source alla moda, ma per il suo supporto sono necessari amministratori fissi. Si presentano tali dicotomie, per risolvere le quali è necessaria una mente lucida.
La scelta dello strumento è per metà un salto di fede, per metà un'esperienza personale. Non c'è certezza assoluta che lo strumento si adatterà.
Ad esempio, in Profi abbiamo iniziato con Pentaho, perché c'era competenza su questo strumento, ma alla fine si è rivelata una scelta errata. Il repository interno di Pentaho, man mano che il progetto cresceva, ha iniziato a rallentare notevolmente il lavoro. Per salvare i dati, a proposito, ci volevano un minuto, e se hai l'abitudine di salvare costantemente il lavoro, il tempo semplicemente sfuggiva dalle mani. A questo si aggiungeva un avvio complicato e le attività programmate — il computer si bloccava.
La sofferenza è finita dopo il passaggio a Airflow — uno strumento popolare, con una grande comunità.
La presenza di una comunità per il servizio o lo strumento è importante per risolvere compiti difficili — si può chiedere consiglio ai colleghi.
Se l'azienda è matura e dispone di risorse, vale la pena considerare l'acquisto di supporto tecnico. Questo aiuterà a risolvere rapidamente i problemi e a ricevere raccomandazioni sull'uso del prodotto.
Parlando dell'approccio alla scelta, in Profi si seguono i seguenti principi:
- Non prendere decisioni da soli. Quando una persona sceglie qualcosa, è automaticamente convinta di avere ragione. Altro è convincere gli altri, quando bisogna portare argomenti seri a sostegno. Questo aiuta anche a vedere i punti deboli dello strumento.
- Consultare il principale specialista dei dati (dialogo verticale). Questo può essere il Chief Data Engineer o il responsabile del team BI. I vertici vedono la situazione in modo più ampio.
- Comunicare con altri team (dialogo orizzontale). Quali strumenti utilizzano e quanto sono efficaci? Forse uno strumento di un collega può risolvere anche le vostre esigenze, evitando di dover creare uno zoo di soluzioni.
Competenze interne come valida alternativa a un fornitore esterno di servizi
Un approccio alla scelta degli strumenti può essere considerato anche l'utilizzo delle competenze interne dell'azienda.
Spesso si presentano situazioni in cui un'azienda ha una sfida complessa, ma non ha i fondi per realizzarla. La sfida è ampia e importante e, idealmente, sarebbe meglio coinvolgere un fornitore esterno che abbia l'esperienza adeguata. Ma poiché non ci sono queste possibilità (fondi), viene affidata l'attività al team interno. Inoltre, di solito le aziende ripongono maggiore fiducia nei loro dipendenti se questi hanno già dimostrato la loro efficacia.
Esempi di tali attività, in cui una nuova direzione si sviluppa grazie ai dipendenti, includono l'esecuzione di test di carico e la creazione di un data warehouse. Soprattutto il data warehouse, poiché è una storia unica per ogni azienda. Non è possibile acquistarlo, si può solo assumere esperti esterni che lo costruiscano con il supporto del team interno.
A proposito, man mano che la nuova direzione si sviluppa, il team può rendersi conto che la necessità di un fornitore di servizi esterno è venuta meno.
In Profi, l'implementazione di BI è stata in-house. La principale difficoltà è stata che l'azienda voleva lanciare BI rapidamente. Ma per costruire un progetto del genere era necessario tempo: sviluppare competenze, caricare dati, costruire un modello di data warehouse comodo, scegliere gli strumenti e apprenderli.
La fase principale — quella intensa — in cui tutto veniva costruito e prendeva forma, è durata circa un anno. Il progetto si sviluppa ancora oggi.
Quando si costruisce un data warehouse aziendale è importante aderire a standard elevati, difendere le proprie posizioni e non fare le cose in modo approssimativo a favore del business.
Con grande dolore abbiamo dovuto rifare gran parte del progetto, che all'epoca doveva essere fatto in fretta.
Ma a volte l'approccio "veloce" è ragionevole. Ad esempio, nello sviluppo di prodotti, può essere persino l'unico modo corretto. È necessario procedere rapidamente, testare le ipotesi di prodotto e altro ancora. Ma il sistema di archiviazione deve essere basato su un'architettura solida, altrimenti non potrà adattarsi rapidamente alla crescita del business e il progetto si fermerà.
In questo progetto complesso il nostro leader ha dato un grande aiuto, sostenendo l'andamento dei lavori, spiegando alla direzione cosa stiamo facendo, ottenendo risorse e semplicemente proteggendoci. Senza un tale supporto, non sono sicuro che saremmo riusciti a lanciare il progetto.
In queste situazioni, giocano un ruolo importante i cosiddetti early adopters, ovvero coloro che sono disposti a provare cose nuove, tra top manager, analisti e product manager. Affinché un argomento grezzo prenda piede, sono necessari dei pionieri che confermino che tutto funziona e che sia comodo da usare.
Se qualcuno vuole condividere la soluzione del terzo problema di cui sopra - benvenuto 🙂
Fonte: habr.com
