Ciao, Habr! Noi di Dodo Pizza Engineering amiamo molto i dati (e chi non li ama oggigiorno?). Ora vi racconterò una storia su come raccogliere tutti i dati del mondo Dodo Pizza e dare a qualsiasi dipendente dell'azienda un facile accesso a questo immenso insieme di dati. La missione da affrontare: mantenere calma la squadra Data Engineering.
Come veri e propri accumulators, raccogliamo informazioni di ogni tipo sul lavoro delle nostre pizzerie:
- ricordiamo tutti gli ordini degli utenti;
- sappiamo quanto tempo ci è voluto per preparare la prima pizza a Syktyvkar;
- vediamo quanto tempo impiega la pizza a raffreddarsi sullo scaffale termico a Voronezh in questo momento;
- conserviamo dati sugli sprechi di prodotti;
- e molto, molto altro.
Attualmente, diversi team si occupano dei dati in Dodo Pizza, uno dei quali è il team Data Engineering. Attualmente abbiamo il compito di fornire a qualsiasi dipendente dell'azienda un facile accesso a questo insieme di dati.
Quando abbiamo iniziato a pensare a come farlo e a discutere della missione, abbiamo trovato un approccio molto interessante alla gestione dei dati – (nel link troverete un articolo enorme e fantastico). Le sue idee si sono perfettamente integrate con la nostra visione su come vogliamo costruire il nostro sistema. Più avanti nell'articolo troverete la nostra reinterpretazione dell'approccio e come vediamo la sua implementazione 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 comune, costruito con RabbitMQ);
- Registrazioni all'interno del database (per noi sono 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 siano soddisfatti i seguenti requisiti:
- Devono essere integri. Dobbiamo essere certi di non modificare i dati durante il loro processo di elaborazione, archiviazione e visualizzazione. Se il business non può fidarsi dei nostri dati, non avranno alcun valore.
- Devono avere un timestamp e non devono essere sovrascritti. Ciò significa che vogliamo avere la possibilità di tornare indietro in qualsiasi momento e guardare i dati di quel periodo di tempo. Ad esempio, scoprire quante pizze sono state vendute l'8 luglio 2018.
- Devono essere affidabili. Nel processo di raccolta e archiviazione dei dati, dobbiamo garantire non solo l'integrità, ma anche l'affidabilità. Non possiamo perdere dati, fette temporali, perché con essi perdiamo la fiducia dei nostri clienti (sia esterni che interni).
- Devono seguire uno schema stabile: scriviamo richieste per questi dati. Non ci piacerebbe affatto che con la modifica del codice dell'applicazione, con il refactoring, questi cambiassero tanto da far smettere di funzionare le nostre richieste. Colui che scrive le richieste non scoprirà mai che avete fatto il refactoring finché tutto non si romperà. Non vorremmo saperlo dai clienti.
Tenendo conto di tutti questi requisiti, siamo giunti alla conclusione che i dati in Dodo sono un prodotto. Proprio come l'API pubblica del servizio. Di conseguenza, i dati devono essere di proprietà dello stesso team che possiede il servizio. Inoltre, le modifiche allo schema dei dati devono essere sempre retrocompatibili.
L'approccio tradizionale è il Data Lake
Per affrontare le sfide della memorizzazione e dell'elaborazione affidabile dei big data, esiste un approccio tradizionale adottato da molte aziende che lavorano con questo insieme di informazioni: il Data Lake. Nell'ambito di questo approccio, gli ingegneri dei dati raccolgono informazioni da tutti i componenti del sistema e le archivia in un grande deposito (che può essere, ad esempio, Hadoop, Azure Kusto, Apache Cassandra o anche una replica MySQL, se i dati vi possono entrare).
Successivamente, gli stessi ingegneri scrivono richieste a tale deposito. L'implementazione di questo approccio in Dodo Pizza Engineering implica che il team di Data Engineering possieda lo schema dei dati nel deposito analitico.
In questo scenario, il team diventa molto triste ecco perché:
- Deve monitorare le modifiche in TUTTI i servizi all'interno dell'azienda. Ce ne sono molti e ci sono molte modifiche (in media uniamo circa 100 pull request a settimana, mentre molti servizi non fanno affatto pull request).
- Con la modifica dello schema dei dati, il product owner e il team che modifica lo schema dei dati devono aspettare che il Data Engineering scriva il codice necessario affinché le modifiche siano supportate. Inoltre, è ormai da tempo che gestiamo situazioni in cui un team aspetta un altro: è molto raro. E non vogliamo che questo diventi una parte «normale» del processo di sviluppo.
- Deve essere immerso in TUTTO business dell'azienda. La rete di pizzerie sembra un'attività semplice, ma è solo un'illusione. È molto difficile raccogliere in un unico team abbastanza competenze per costruire un modello dati adeguato per tutta l'azienda.
- Costituisce un punto di fallimento unico. Ogni volta che è necessario modificare i dati che il servizio restituisce o scrivere una query, tutte queste attività ricadono sul team Data Engineering. Alla fine, il team ha un backlog sovraccarico.
Di conseguenza, il team si trova all'incrocio di un'enorme quantità di richieste e con poche possibilità di soddisfarle. Inoltre, sarà in costante fretta e stress. Non vogliamo assolutamente questo. Pertanto, dobbiamo pensare a come risolvere questi problemi e, nel contempo, ottenere la possibilità di analizzare i dati.
Passando dal Data Lake al Data Mesh
Fortunatamente, questa domanda non l'abbiamo fatta solo noi. In realtà, questo problema è già stato risolto nell'industria (aleluia!). Solo in un altro ambito: il deployment delle applicazioni. Sì, parlo dell'approccio DevOps, dove il team decide come implementare il prodotto che stanno creando.
Un approccio simile alla risoluzione dei problemi del Data Lake è stato proposto da Zhamak Dehghani, consulente di ThoughtWorks. Osservando come Netflix e Spotify affrontano simili sfide, ha scritto un articolo straordinario (il link per accedervi era all'inizio dell'articolo). Le idee principali che ne abbiamo estratte sono:
- Suddividere un grande Data Lake in domini di dati, che sono molto simili ai domini del domain-driven design. Ogni dominio è un piccolo bounded context.
- I Feature Team, che sono responsabili dei domini DDD, sono anche responsabili dei relativi domini di dati. Possono gestire lo schema, modificarlo e caricare i dati. A questo punto, sanno tutto: come cambiare il caricamento dei dati senza rompere nulla quando l'applicazione cambia. Le conoscenze non vanno mai 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 è correlato al dominio (sia per quanto riguarda il dominio aziendale che quello dei dati).
- Data Engineer – un ruolo all'interno del Feature Team. Non deve necessariamente essere una persona separata, ma è fondamentale che il team abbia questa competenza.
E nel frattempo, il team Data Engineering...
Se immaginiamo che tutto questo possa realizzarsi con uno schiocco di dita, rimangono due domande a cui rispondere:
Cosa farà 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'implementazione semplice dei servizi. Il team Data Engineering avrà un ruolo analogo, ma esclusivamente per i dati.
Trasformare i dati operativi in analitici è un processo complesso. Rendere i dati analitici accessibili a tutta l'azienda è ancora più difficile. Il team Data Engineering si occuperà di risolvere questi problemi.
Abbiamo intenzione di fornire al Feature Team un insieme di strumenti e pratiche convenienti, grazie ai quali potranno pubblicare i dati dal loro servizio per il resto dell'azienda. Inoltre, ci occuperemo delle parti infrastrutturali comuni del data pipeline (code, archiviazione sicura, cluster per effettuare trasformazioni sui dati).
Come acquisiranno competenze di Data Engineering gli appartenenti al Feature Team? Con il Feature Team è più complicato. Certamente, potremmo provare a reclutare un Data Engineer per ciascuna delle nostre squadre. Ma è molto difficile. Trovare una persona con una buona esperienza nella lavorazione dei dati e convincerla a lavorare all'interno di un team di prodotto è complicato.
Un grande vantaggio di Dodo è che amiamo la formazione interna. Perciò, al momento, il nostro piano è il seguente: il team Data Engineering inizierà a pubblicare i dati di alcuni servizi, piangerà, si punterà, ma continuerà a mangiare il cactus. Non appena capiremo di avere un processo pronto per la pubblicazione, inizieremo a parlarne al Feature Team.
Abbiamo diversi modi per farlo:
- , in cui racconteremo come appare il processo che abbiamo creato, quali strumenti esistono e come utilizzarli nel modo più efficace.
- Una presentazione al DevForum ci aiuterà a raccogliere feedback dagli sviluppatori di prodotto. Dopo di che, potremo unirci ai team di prodotto e aiutarli a risolvere i problemi legati alla pubblicazione dei dati, organizzando corsi di formazione per i team.
Consumo dei dati
Ora ho parlato molto della pubblicazione dei dati. Ma c'è anche il consumo. Cosa si può dire al riguardo?
Abbiamo un fantastico team BI che scrive 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 modella, li vediamo come consumatori di dati, ciascuno con i propri domini di dati. E sono proprio i consumatori a dover gestire i propri domini. A volte, il dominio del consumatore può essere descritto con una sola query nel data warehouse analitico, e questo è positivo. Ma sappiamo che non sempre funzionerà. Ecco perché vogliamo che la piattaforma che creeremo per i team di prodotto possa essere utilizzata anche dai consumatori di dati (dopotutto, nei report all'interno di Dodo IS, saranno gli stessi team).
Ecco come vediamo il lavoro con i dati in Dodo Pizza Engineering. Saremmo lieti di leggere i vostri pensieri al riguardo nei commenti.
Fonte: habr.com
