L'editore di Netology ha parlato con il team leader del team BI in Pavel Sayapin su quali problemi risolvono gli ingegneri dei dati del suo team, che tipo di strumenti utilizzano a questo scopo e come scegliere gli strumenti giusti per risolvere i problemi relativi ai dati, compresi quelli atipici. Pavel è un insegnante del corso "'.
Cosa fanno gli ingegneri dei dati su Profi.ru
Profi.ru è un servizio che aiuta a incontrare clienti e specialisti di vari settori. Il database dei servizi comprende più di 900mila specialisti in 700 tipologie di servizi: tutor, riparatori, formatori, esperti di bellezza, artisti e altri. Ogni giorno vengono registrati più di 10mila nuovi ordini: tutto ciò fornisce circa 100 milioni di eventi al giorno. È impossibile mantenere l'ordine in una tale quantità di dati senza ingegneri informatici professionisti.
Idealmente, un Data Engineer sviluppa una cultura dei dati attraverso la quale un'azienda può generare profitti aggiuntivi o ridurre i costi. Apporta valore all'azienda lavorando in gruppo e fungendo da collegamento importante tra i vari partecipanti, dagli sviluppatori ai consumatori aziendali di reporting. Ma i compiti possono differire in ogni azienda, quindi vediamoli usando Profi.ru come esempio.
Raccogli i dati per il processo decisionale e forniscili all'utente finale: top manager, product manager, analista
I dati devono essere chiari per il processo decisionale e facili da usare. Non è necessario lottare per trovare una descrizione o scrivere una query SQL complessa che tenga conto di molti fattori diversi. Un'immagine ideale: l'utente guarda il dashboard ed è soddisfatto di tutto. E se in qualche sezione non ci sono abbastanza dati, vanno al database e, utilizzando una semplice query SQL, ottengono ciò di cui hanno bisogno.
Collocazione del processo di Data Quality nella struttura complessiva del data warehouse
La documentazione esplicativa sull'utilizzo dei dati è importante. Ciò semplifica il lavoro sia dell'ingegnere dei dati (non sono distratti dalle domande) sia dell'utente dei dati (può trovare da solo le risposte alle sue domande). Su Profi.ru tali documenti vengono raccolti nel forum interno.
Comodità significa anche velocità di acquisizione dei dati. Velocità = accessibilità in un solo passaggio, clic - dashboard. Ma in pratica tutto è più complicato.
Lo stesso Tableau, dal punto di vista dell'utente finale della dashboard, non permette di visualizzare tutte le misure possibili. L'utente si accontenta dei filtri realizzati dallo sviluppatore della dashboard. Ciò dà luogo a due scenari:
- Lo sviluppatore apporta molti tagli alla dashboard ⟶ il numero di pagine aumenta notevolmente. Ciò riduce la disponibilità dei dati: diventa difficile capire dove si trova ogni cosa.
- Lo sviluppatore crea solo sezioni chiave. È più facile trovare informazioni, ma per una sezione un po’ meno standard bisogna comunque rivolgersi al database o agli analisti. Il che ha anche un effetto negativo sull’accessibilità.
L’accessibilità è un concetto ampio. Ciò include la disponibilità dei dati nella forma corretta e la capacità di ottenere informazioni sui dashboard, nonché la necessaria sezione trasversale dei dati.
Accumula dati da tutte le fonti in un unico posto
Le origini dati possono essere interne o esterne. Ad esempio, l'attività di qualcuno dipende dalle previsioni del tempo che devono essere raccolte e archiviate, da fonti esterne.
Le informazioni devono essere archiviate indicando la fonte e anche in modo che i dati possano essere facilmente reperiti. In Profi.ru questo problema viene risolto utilizzando la documentazione automatizzata. I file YML vengono utilizzati come documentazione sulle origini dati interne.
Fanno dashboard
La visualizzazione dei dati viene eseguita meglio con uno strumento professionale, ad esempio Tableau.
La maggior parte delle persone prende decisioni emotivamente; la chiarezza e l’estetica sono importanti. Excel, tra l'altro, non è molto adatto alla visualizzazione: non copre tutte le esigenze degli utenti dei dati. Ad esempio, a un product manager piace seppellirsi nei numeri, ma in un modo che renda conveniente farlo. Ciò gli consente di risolvere i suoi problemi, invece di pensare a come ottenere informazioni e raccogliere parametri.
La visualizzazione dei dati di alta qualità rende più semplice e veloce prendere decisioni.
Più alta è la posizione di una persona, maggiore è la necessità di avere dati aggregati a portata di mano, sul telefono. I top manager non hanno bisogno di dettagli: è importante controllare la situazione nel suo insieme e la BI è un buon strumento per questo.
Esempio di dashboard del prodotto Profi.ru (uno dei fogli). Per motivi di riservatezza delle informazioni, i nomi delle metriche e degli assi sono nascosti
Esempi di problemi reali
Attività 1: trasferire i dati dai sistemi di origine (operativi) in un data warehouse o ETL
Uno dei compiti di routine di un ingegnere dei dati.
Per questo è possibile utilizzare quanto segue:
- script autoprodotti lanciati tramite cron o utilizzando un orchestratore speciale come Airflow o Prefect;
- Soluzioni ETL open source: Pentaho Data Integration, Talend Data Studio e altri;
- soluzioni proprietarie: Informatica PowerCenter, SSIS e altre;
- soluzioni cloud: Matillion, Panoply e altri.
In un'implementazione semplice, il problema viene risolto scrivendo un file YML di 20 righe, operazione che richiede circa 5 minuti.
Nel caso più complesso, quando è necessario aggiungere una nuova fonte, ad esempio un nuovo database, possono essere necessari diversi giorni.
In Profi, questo semplice compito, con un processo semplificato, consiste nei seguenti passaggi:
- Scopri dal cliente quali dati sono necessari e dove si trovano.
- Capire se è possibile accedere a questi dati.
- Se non c'è accesso, chiedi agli amministratori.
- Aggiungi un nuovo ramo in Git con il codice di emissione in Jira.
- Crea una migrazione per aggiungere dati al modello di ancoraggio tramite uno script Python interattivo.
- Aggiungi file di download (file YML che descrive da dove provengono i dati e in quale tabella sono scritti).
- Provalo sul supporto.
- Carica i dati nel repository.
- Crea una richiesta pull.
- Passa attraverso la revisione del codice.
- Dopo aver superato la revisione del codice, i dati vengono caricati nel ramo master e automaticamente distribuiti in produzione (CI/CD).
Attività 2: posiziona comodamente i dati scaricati
Un'altra attività comune è organizzare i dati caricati in modo che l'utente finale (o lo strumento BI) possa lavorarci facilmente e non debba effettuare movimenti non necessari per completare la maggior parte delle attività. Cioè, crea o aggiorna un Dimension Data Store (DDS).
A questo scopo è possibile utilizzare le soluzioni del compito 1, poiché anche questo è un processo ETL. Nella versione più semplice, DDS viene aggiornato utilizzando script SQL.
Il compito 3 è uno dei compiti atipici
L'analisi dello streaming sta emergendo in Profi. Un gran numero di eventi vengono generati dai team di prodotto: li registriamo in ClickHouse. Ma non puoi inserire record uno alla volta in grandi numeri, quindi devi combinare i record in batch. Cioè, non puoi scrivere direttamente: hai bisogno di un processore intermedio.
Utilizziamo un motore basato su Apache Flink. Finora, la procedura è la seguente: il motore elabora il flusso di eventi in entrata ⟶ li inserisce in batch in ClickHouse ⟶ conta il numero di eventi in 15 minuti in movimento ⟶ li trasferisce al servizio, che determina se ci sono anomalie - li confronta con i valori degli stessi 15 minuti con una profondità di 3 mesi ⟶ se presente, invia un avviso a Slack.
Schema per l'analisi di prima linea (parte del download)
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 l'ID di correlazione. Quindi la consegna unica ⟶ è garantita l'integrità dei dati.
Contiamo il numero di eventi, sempre utilizzando Apache Flink, lo visualizziamo attraverso una dashboard personalizzata scritta in NodeJS + front in ReactJS. Una rapida ricerca non ha prodotto soluzioni simili. E il codice stesso si è rivelato semplice: la scrittura non ha richiesto molto tempo.
Il monitoraggio è piuttosto tecnico. Cerchiamo anomalie al fine di prevenire problemi nelle fasi iniziali. Alcuni parametri globali significativi dell'azienda non sono ancora inclusi nel monitoraggio, poiché la direzione dell'analisi dello streaming è in fase di formazione.
Strumenti di base per gli ingegneri dei dati
I compiti degli ingegneri dei dati sono più o meno chiari, ora parliamo un po' degli strumenti utilizzati per risolverli. Naturalmente, gli strumenti nelle diverse aziende possono (e dovrebbero) differire: tutto dipende dal volume dei dati, dalla velocità di ricezione e dall'eterogeneità. Può anche dipendere dalla propensione dello specialista verso un particolare strumento solo perché ci ha lavorato e lo conosce bene. Profi.ru ha optato per queste opzioni →
Per la visualizzazione dei dati: Tableau, Metabase
Tableau è stato scelto molto tempo fa. Questo sistema consente di analizzare rapidamente grandi quantità di dati senza richiedere costose implementazioni. Per noi è conveniente, bello e familiare: spesso ci lavoriamo.
Poche persone conoscono Metabase, ma è molto utile per la prototipazione.
Tra gli strumenti di visualizzazione si può parlare anche di Superset di Airbnb. La sua particolarità sono le numerose connessioni a database e funzionalità di visualizzazione. Tuttavia, per l'utente medio è meno conveniente di Metabase: non può unire tabelle, per questo è necessario creare visualizzazioni separate.
In Metabase puoi connettere le tabelle, inoltre, il servizio lo fa da solo, tenendo conto dello schema del database. E l'interfaccia di Metabase è più semplice e piacevole.
Ci sono molti strumenti: trova il tuo.
Per l'archiviazione dei dati – ClickHouse, Vertica
ClickHouse è uno strumento gratuito e veloce per archiviare eventi di prodotto. Su di esso, gli analisti stessi eseguono analisi separate (se hanno dati sufficienti) oppure i data engineer prendono gli aggregati e li ricaricano in Vertica per creare vetrine.
Vertica è un prodotto interessante e facile da usare per la visualizzazione delle vetrine finali.
Per gestire i flussi di dati ed eseguire calcoli - Flusso d'aria
Carichiamo i dati tramite gli strumenti della console. Ad esempio, tramite un client fornito con MySQL, questo è più veloce.
Il vantaggio degli strumenti della console è la velocità. I dati non vengono pompati attraverso la memoria dello stesso processo Python. Lo svantaggio è che c’è meno controllo sui dati che volano in transito da un database all’altro.
Il principale linguaggio di programmazione è Python
Python ha una soglia di ingresso molto più bassa + l'azienda ha competenze in questo linguaggio. Un altro motivo è che i DAG Airflow sono scritti in Python. Questi script sono solo un wrapper sui download; il lavoro principale viene svolto tramite script della console.
Utilizziamo Java per sviluppare analisi in tempo reale.
Approccio alla scelta degli strumenti di dati: cosa fare per evitare di creare uno zoo tecnologico
Esistono molti strumenti sul mercato per lavorare con i dati in ogni fase: dalla loro apparizione alla visualizzazione su una dashboard per il consiglio di amministrazione. Non sorprende che alcune aziende possano ritrovarsi con una serie di soluzioni non correlate: un cosiddetto zoo tecnologico.
Uno zoo tecnologico è costituito da strumenti che svolgono le stesse funzioni. Ad esempio, Kafka e RabbitMQ per la messaggistica o Grafana e Zeppelin per la visualizzazione.
— puoi vedere quante soluzioni duplicate possono esserci
Inoltre, molte persone possono utilizzare diversi strumenti ETL per scopi personali. Questa è esattamente la situazione a Profi. L'ETL principale è su Airflow, ma alcune persone usano Pentaho per download personali. Testano le ipotesi e non hanno bisogno di far passare questi dati agli ingegneri. Fondamentalmente, gli strumenti "self-service" vengono utilizzati da specialisti abbastanza esperti che sono impegnati in attività di ricerca, studiando nuove modalità di sviluppo del prodotto. Il loro set di dati per l'analisi interessa principalmente loro e inoltre è in continua evoluzione. Di conseguenza, non ha senso aggiungere questi carichi alla piattaforma principale.
Ritorno allo zoo. Spesso l'uso di tecnologie duplicate è associato al fattore umano. I team interni distaccati sono abituati a lavorare con uno strumento o un altro che un altro team potrebbe non utilizzare. E a volte l’autonomia è l’unico modo per risolvere problemi particolari. Ad esempio, il team di ricerca e sviluppo deve testare qualcosa utilizzando un determinato strumento: è semplicemente conveniente, qualcuno del team lo ha già utilizzato o c'è un altro motivo. L'attesa per gli amministratori di sistema è lunga per installare e configurare questo strumento. Allo stesso tempo, gli amministratori attenti e meticolosi devono ancora dimostrare che ciò è veramente necessario. Quindi il team installa lo strumento sulle proprie macchine virtuali e risolve i problemi specifici.
Le soluzioni Zoo non rappresentano un problema solo se non richiedono un impegno significativo da parte dell'amministratore di sistema per supportare lo strumento. È necessario considerare l'impatto dell'uso dello strumento sulle risorse di supporto.
Un altro motivo comune per la comparsa di nuovi strumenti è il desiderio di provare un prodotto sconosciuto in un'area abbastanza nuova in cui gli standard non sono ancora stati formati o non esistono raccomandazioni comprovate. Un ingegnere dei dati, come uno sviluppatore, dovrebbe sempre esplorare nuovi strumenti nella speranza di trovare una soluzione migliore a un problema attuale o di stare al passo con ciò che il mercato ha da offrire.
La tentazione di provare nuovi strumenti è davvero tanta. Ma per fare una scelta adeguata, serve prima autodisciplina. Ti aiuterà a non cedere completamente agli impulsi della ricerca, ma a tenere conto delle capacità dell’azienda nel supportare l’infrastruttura per un nuovo strumento.
Non usare la tecnologia fine a se stessa. È meglio affrontare la questione in modo pragmatico: un compito ⟶ una serie di strumenti in grado di risolvere questo problema.
E poi valuta ciascuno di essi e scegli quello ottimale. Ad esempio, questo strumento può risolvere un problema in modo più efficiente, ma non ha competenza, e questo è leggermente meno efficace, ma ci sono persone in azienda che sanno come lavorarci. Questo strumento è a pagamento, ma facile da supportare e utilizzare, ed è un open source alla moda, ma richiede uno staff di amministratori per supportarlo. Si creano tali dicotomie, la cui soluzione richiede sangue freddo.
Scegliere uno strumento è per metà un atto di fede e per metà un'esperienza personale. Non esiste la certezza assoluta che lo strumento sia adatto.
Ad esempio, Profi ha iniziato con Pentaho perché aveva esperienza in questo strumento, ma alla fine si è rivelata una decisione sbagliata. Man mano che il progetto cresceva, il repository interno di Pentaho iniziò a rallentare in modo significativo. A proposito, ci è voluto un minuto per salvare i dati e se hai l'abitudine di salvare costantemente il tuo lavoro, il tempo ti è semplicemente scivolato tra le dita. A ciò si aggiungevano un avvio complesso e attività pianificate: il computer si bloccava.
La sofferenza è finita dopo essere passato ad Airflow, uno strumento popolare con una vasta comunità.
La presenza di un servizio o di uno strumento comunitario è importante per risolvere problemi complessi: puoi chiedere consiglio ai tuoi colleghi.
Se l’azienda è matura e dispone delle risorse, ha senso pensare all’acquisto di supporto tecnico. Ciò ti aiuterà a risolvere rapidamente i problemi e a ricevere consigli su come utilizzare il prodotto.
Se parliamo dell'approccio alla selezione, Profi aderisce ai seguenti principi:
- Non prendere decisioni da solo. Quando una persona sceglie qualcosa, è automaticamente convinta di avere ragione. Un'altra cosa è convincere gli altri quando è necessario fare una difesa seria. Ciò aiuta anche a vedere i punti deboli dello strumento.
- Consultarsi con il Chief Data Scientist (dialogo verticale). Potrebbe essere il Chief Data Engineer, il capo del team BI. I top vedono la situazione in un’ottica più ampia.
- Comunicare con gli altri team (dialogo orizzontale). Quali strumenti usano e quanto bene? Forse lo strumento dei tuoi colleghi può risolvere anche i tuoi problemi e non dovrai creare uno zoo di soluzioni.
Competenze interne come sostituto efficace di un fornitore di servizi esterno
Anche l’utilizzo delle competenze interne all’azienda può essere considerato un approccio alla scelta degli strumenti.
Molto spesso ci sono situazioni in cui un'azienda ha un compito complesso, ma non ci sono soldi per implementarlo. Il compito è ampio e importante ed è meglio coinvolgere un fornitore di servizi esterno che abbia l'esperienza in materia. Ma poiché non esiste tale opportunità (denaro), il team interno è incaricato di risolvere il problema. Inoltre, le aziende solitamente si fidano maggiormente dei propri dipendenti se questi hanno già dimostrato la propria efficacia.
Esempi di tali attività quando i dipendenti sviluppano una nuova direzione includono il test di carico e la creazione di un data warehouse. Soprattutto il data warehouse in quanto è una storia unica per ogni azienda. Il magazzino non può essere acquistato, è possibile solo assumere specialisti esterni che lo costruiranno con il supporto di un team interno.
A proposito, man mano che la nuova direzione si sviluppa, il team potrebbe rendersi conto che la necessità di un fornitore di servizi esterno non è più necessaria.
Presso Profi, l'implementazione della BI era interna. La difficoltà principale era che l'azienda voleva lanciare rapidamente la BI. Ma la realizzazione di un progetto del genere ha richiesto tempo: acquisire competenze, caricare dati, creare un comodo layout di archiviazione, scegliere gli strumenti e padroneggiarli.
La fase principale, calda, in cui tutto veniva costruito e cristallizzato, è durata circa un anno. E il progetto è ancora in fase di sviluppo.
Quando si costruisce un data warehouse aziendale, è importante aderire a standard elevati, difendere le proprie posizioni e non fare cose per compiacere l'azienda.
Con grande sofferenza abbiamo rielaborato gran parte del progetto, che poi doveva essere realizzato in tempi brevi.
Ma a volte è appropriato un approccio rapido. Pertanto, nello sviluppo del prodotto potrebbe anche essere l'unico corretto. Dobbiamo andare avanti rapidamente, testare ipotesi di prodotto e altro ancora. Ma lo storage deve basarsi su un’architettura solida, altrimenti non sarà in grado di adattarsi rapidamente al business in crescita e il progetto si bloccherà.
Il nostro manager è stato molto utile in questo progetto complesso, difendendo l'avanzamento dei lavori, spiegando alla direzione cosa stavamo facendo, estraendo risorse e semplicemente difendendoci. Senza tale supporto, non sono sicuro che saremmo stati in grado di lanciare il progetto.
In queste storie, un ruolo importante è svolto dai cosiddetti early adopters – coloro che sono pronti a provare cose nuove – tra top manager, analisti e product manager. Perché un tema grezzo possa decollare, abbiamo bisogno di pionieri che confermino che tutto funziona ed è comodo da usare.
Se qualcuno vuole condividere la soluzione al terzo problema sopra descritto, benvenuto :)
Fonte: habr.com
