Ciao, Habr! In Dodo Pizza Engineering amiamo molto i dati (e chi non li ama oggi?). Ora vi racconteremo come raccogliere tutti i dati del mondo Dodo Pizza e fornire a qualsiasi dipendente dell'azienda un accesso conveniente a questo vasto insieme di dati. L'obiettivo è: mantenere i nervi saldi per il team di Data Engineering.
Proprio come dei veri collezionisti, accumuliamo ogni tipo di informazione sul funzionamento delle nostre pizzerie:
- ricordiamo tutti gli ordini degli utenti;
- sappiamo quanto tempo ci è voluto per preparare la prima pizza a Syktyvkar;
- vediamo quanto tempo una pizza sta raffreddando su un ripiano riscaldato a Voronezh in questo momento;
- conserviamo i dati sulle scorte di prodotti;
- e molto, molto altro.
Attualmente, diversi team si occupano della gestione dei dati in Dodo Pizza, uno dei quali è il team di Data Engineering. Ora, abbiamo il compito di fornire a qualsiasi dipendente dell'azienda un accesso comodo a questo ampio insieme di dati.
Quando abbiamo iniziato a pensare a come realizzarlo e abbiamo cominciato a discutere il compito, abbiamo trovato un approccio molto interessante alla gestione dei dati - (nel link troverete un enorme e splendido articolo). Le sue idee si sono incastrate molto bene nella nostra visione di come vogliamo costruire il nostro sistema. Più avanti nell'articolo troverete la nostra reinterpretazione dell'approccio e come lo vediamo implementato in Dodo Pizza Engineering.
Cosa intendiamo per 'dati'
Per iniziare, definiamo cosa intendiamo per dati in Dodo Pizza Engineering:
- Eventi inviati dai servizi (abbiamo un bus aziendale costruito con RabbitMQ);
- Registrazioni all'interno del database (per noi si tratta di MySQL e CosmosDB);
- Clickstream dall'app mobile e dal sito web.
Affinché il business di Dodo Pizza possa utilizzare questi dati e fare affidamento su di essi, è importante che vengano rispettate le seguenti condizioni:
- Devono essere integri. Dobbiamo essere certi di non alterare i dati durante il loro trattamento, conservazione e visualizzazione. Se il business non può fidarsi dei nostri dati, non saranno di alcuna utilità.
- Devono avere un timestamp e non possono essere sovrascritti. Questo significa che in qualsiasi momento vogliamo avere la possibilità di tornare indietro e vedere i dati di quel periodo. Ad esempio, sapere quante pizze sono state vendute l'8 luglio 2018.
- Devono essere affidabili. Durante la raccolta e la conservazione dei dati non dobbiamo perdere solo l'integrità, ma anche l'affidabilità. Non possiamo permetterci di perdere dati, intervalli di tempo, perché così facendo perdiamo la fiducia dei nostri clienti (sia esterni che interni).
- Devono avere uno schema stabile – scriviamo query su questi dati. Non ci piacerebbe affatto che con le modifiche al codice dell'applicazione, con il refactoring, cambiassero al punto da far smettere di funzionare le nostre query. Chi scrive le query non saprà mai che hai fatto un refactoring finché tutto non va in frantumi. Non ci piacerebbe saperlo dai clienti.
Tenendo conto di tutti questi requisiti, siamo giunti alla conclusione che i dati in Dodo sono un prodotto. Proprio come un'API pubblica del servizio. Di conseguenza, il team che possiede i dati deve essere lo stesso che possiede il servizio. Inoltre, le modifiche allo schema dei dati devono essere sempre retrocompatibili.
Approccio tradizionale – Data Lake
Per affrontare le necessità di un'archiviazione e un trattamento affidabile dei big data, esiste un approccio tradizionale adottato in molte aziende che lavorano con questo insieme di informazioni: Data Lake. In questo approccio, gli ingegneri dei dati raccolgono informazioni da tutti i componenti del sistema e le accumulano in un grande magazzino (può essere, ad esempio, Hadoop, Azure Kusto, Apache Cassandra o persino una replica MySQL, se i dati ci stanno).
Successivamente, questi stessi ingegneri scrivono query su questo magazzino. L'implementazione di questo approccio in Dodo Pizza Engineering implica che il team di Data Engineering possederà lo schema dei dati all'interno del magazzino analitico.
Con questo sviluppo della situazione, il team diventa un po’ triste e ecco perché:
- Deve tenere traccia delle modifiche in TUTTI i servizi all'interno dell'azienda. E ce ne sono molti e le modifiche sono tante (in media mergiamo circa 100 pull request a settimana, mentre molti servizi non fanno affatto pull request).
- Al momento della modifica dello schema dei dati, il product owner e il team che modifica lo schema dei dati devono attendere che il Data Engineering scriva il codice necessario per supportare le modifiche. Già da tempo, stiamo affrontando situazioni in cui un team aspetta un altro – molto rare. E non vogliamo che questo diventi una parte 'normale' del processo di sviluppo.
- Deve essere coinvolta in TUTTO il business dell'azienda. La rete di pizzerie sembra un business semplice, ma è solo un'apparenza. È molto difficile raccogliere in un solo team competenze sufficienti per costruire un modello di dati adeguato per tutta l'azienda.
- È un punto unico di fallimento. Ogni volta che è necessario modificare i dati restituiti dal servizio o scrivere una richiesta, tutte queste attività ricadono sul team Data Engineering. Di conseguenza, il team ha un backlog sovraccarico.
Così, il team si trova all'incrocio di un'infinità di esigenze e difficilmente riuscirà a soddisfarle. Inoltre, sarà in uno stato di costante fretta e stress. Non vogliamo che sia così. Dobbiamo quindi pensare a come risolvere questi problemi e al contempo avere la possibilità di analizzare i dati.
Passando da Data Lake a Data Mesh
Fortunatamente, non siamo stati gli unici a porci questa domanda. Infatti, un problema simile è già stato affrontato nel settore (alelujah!). Solo in un'altra area: il deployment delle applicazioni. Sì, parlo dell'approccio DevOps, in cui il team definisce come deve essere distribuito il prodotto che stanno creando.
Un approccio simile per risolvere i problemi del Data Lake è stato proposto da Zhamak Dehghani, consulente di ThoughtWorks. Osservando come Netflix e Spotify affrontano tali sfide, ha scritto un articolo straordinario (il link era all'inizio dell'articolo). Le idee principali che abbiamo ricavato sono:
- Dividere un grande Data Lake in domini di dati, che sono molto simili ai domini del domain-driven design. Ogni dominio è un piccolo bounded context.
- Le Feature Team, responsabili dei domini DDD, sono anche responsabili dei relativi domini di dati. Gestiscono lo schema, apportano modifiche e caricano i dati. E sanno come modificare il caricamento dei dati senza rompere nulla quando l'applicazione cambia. Le conoscenze non vanno perse. Per accedere ai dati non devono andare da nessuna parte. Il team gestisce l'intero ciclo di sviluppo, dalla modifica dei dati operativi alla fornitura di dati analitici a terzi. Un team possiede tutto ciò che è collegato al dominio (sia il dominio aziendale che quello dei dati).
- Il Data Engineer è un ruolo all'interno della Feature Team. Non deve per forza essere una persona separata, ma è essenziale che il team possieda questa competenza.
E nel frattempo, il team di Data Engineering…
Se immaginiamo che tutto ciò venga realizzato con un semplice clic, rimangono da rispondere a due domande:
Di cosa si occuperà ora il team Data Engineering? In Dodo Pizza Engineering c'è già un team piattaforma/SRE. Il suo compito è fornire agli sviluppatori gli strumenti per un semplice deployment dei servizi. Il team Data Engineering avrà un ruolo simile, ma per i dati.
Trasformare i dati operativi in dati analitici è un processo complesso. Rendere i dati analitici accessibili a tutta l'azienda è ancora più difficile. Sarà proprio questo il compito del team Data Engineering.
Intendiamo fornire alle Feature Team un insieme di strumenti e pratiche che consentano loro di pubblicare i dati dal loro servizio per il resto dell'azienda. Sarà inoltre nostra responsabilità gestire le parti infrastrutturali comuni del data pipeline (code, archiviazione sicura, cluster per l'esecuzione delle trasformazioni sui dati).
Come acquisiranno le competenze di Data Engineer all'interno della Feature Team? La situazione è più complicata con le Feature Team. Certamente, potremmo provare a assumere un Data Engineer in ciascuno dei nostri team. Ma è molto difficile. Trovare una persona con una buona esperienza nell'elaborazione dei dati e convincerla a lavorare all'interno di un team di prodotto è complicato.
Un grande vantaggio di Dodo è che amiamo la formazione interna. Pertanto, il nostro piano attuale è questo: il team Data Engineering inizia a pubblicare i dati di alcuni servizi, piange, si fa male, ma continua a mangiare il cactus. Non appena capiremo di avere un processo pronto per la pubblicazione, iniziamo a parlarne alla Feature Team.
Abbiamo diversi modi per farlo:
- un incontro in cui parleremo di come appare il processo che abbiamo creato, quali strumenti ci sono e come utilizzarli nel modo più efficace.
- Una presentazione al DevForum ci aiuterà a raccogliere feedback dagli sviluppatori di prodotto. Dopo, saremo in grado di unirci ai team di prodotto e aiutarli a risolvere le questioni relative alla pubblicazione dei dati, organizzando formazioni per i team.
Consumo dei dati
Finora ho parlato molto della pubblicazione dei dati. Ma c'è anche il consumo. Cosa possiamo dire al riguardo?
Abbiamo un fantastico team BI che redige report molto complessi per la società di gestione. All'interno di Dodo IS ci sono molti report per i nostri partner, che li aiutano a gestire le pizzerie. Nella nostra nuova modello, li consideriamo come consumatori di dati, ognuno con i propri domini di dati. Saranno proprio i consumatori a gestire i propri domini. A volte, il dominio del consumatore può essere descritto da una singola query nel data warehouse – e questo va bene. Ma comprendiamo che non funzionerà sempre. Per questo motivo vogliamo che la piattaforma che costruiremo per i team di prodotto possa essere utilizzata anche dai consumatori di dati (infatti, nel caso dei report all'interno di Dodo IS – saranno gli stessi team).
Ecco come vediamo il lavoro con i dati in Dodo Pizza Engineering. Saremmo felici di leggere le vostre opinioni a riguardo nei commenti.
Fonte: habr.com
