Hej, Habr! På Dodo Pizza Engineering älskar vi data (och vem älskar inte det nuförtiden?). Nu kommer det att finnas en berättelse om hur man samlar all data i Dodo Pizza-världen och ger alla anställda på företaget bekväm tillgång till denna datamatris. Uppgiften under asterisken: att behålla nerverna hos Data Engineering-teamet.
Liksom riktiga Plyushkins samlar vi all slags information om våra pizzeriors arbete:
- kom ihåg alla användarordrar;
- vi vet hur lång tid det tog att göra den allra första pizzan i Syktyvkar;
- vi ser hur lång tid det tar för pizza att svalna på en värmehylla i Voronezh just nu;
- Vi lagrar data om produktavskrivningar;
- och många många andra.
Flera team är nu ansvariga för arbetet med data på Dodo Pizza, ett av dem är Data Engineering-teamet. Nu står de (det vill säga vi) inför uppgiften att ge alla anställda i företaget bekväm tillgång till denna mängd data.
När vi började fundera på hur vi skulle göra detta och började diskutera problemet hittade vi ett mycket intressant tillvägagångssätt för datahantering - (följ länken så hittar du en enorm, fantastisk artikel). Hennes idéer passar väldigt bra in i vår idé om hur vi vill bygga vårt system. Längre fram i artikeln kommer vi att tänka om tillvägagångssättet och hur vi ser på dess implementering i Dodo Pizza Engineering.
Vad menar vi med "data"
Låt oss först definiera vad vi menar med data i Dodo Pizza Engineering:
- Händelser skickade av tjänster (vi har en gemensam buss byggd med RabbitMQ);
- Poster i databasen (för oss är detta MySQL och CosmosDB);
- Clickstream från mobilapplikation och webbplats.
För att Dodo Pizza-verksamheten ska kunna använda och förlita sig på denna data är det viktigt att följande villkor är uppfyllda:
- De måste vara kompletta. Vi måste vara säkra på att vi inte ändrar uppgifterna medan de bearbetas, lagras och visas. Om företag inte kan lita på vår data kommer det inte att vara till någon nytta.
- De ska ha en tidsstämpel och inte skrivas över. Det betyder att vi när som helst vill kunna rulla tillbaka och titta på data från den tidsperioden. Ta till exempel reda på hur många pizzor som såldes den 8 juli 2018.
- De måste vara pålitliga. I processen att samla in och lagra data får vi inte förlora inte bara integritet utan också tillförlitlighet. Vi kan inte förlora data, tidssegment, eftersom vi tillsammans med dem förlorar förtroendet hos våra kunder (både externa och interna).
- De måste ha en stabil krets - vi skriver förfrågningar om dessa data. Vi skulle verkligen inte vilja att det förändrades så mycket med ändringar i applikationskoden, med refactorings, att våra frågor slutar fungera. Personen som skriver frågorna kommer aldrig att veta att du gjorde en refaktorering förrän allt går sönder. Jag skulle inte vilja höra om detta från kunder.
Med tanke på alla dessa krav kom vi fram till att uppgifterna i Dodo är en produkt. Samma som tjänstens offentliga API. Följaktligen bör samma team som äger tjänsten äga data. Dessutom måste ändringar av dataschemat alltid vara bakåtkompatibla.
Traditionell metod – Data Lake
För att lösa problem med tillförlitlig lagring och bearbetning av big data finns det ett traditionellt tillvägagångssätt i många företag som arbetar med en sådan informationspool - Data Lake. Som en del av detta tillvägagångssätt samlar dataingenjörer in information från alla komponenter i systemet och placerar dem i ett stort arkiv (detta kan till exempel vara Hadoop, Azure Kusto, Apache Cassandra eller till och med en MySQL-replik, om data passar in i Det).
Sedan skriver samma ingenjörer förfrågningar till ett sådant lager. Att implementera detta tillvägagångssätt i Dodo Pizza Engineering innebär att Data Engineering-teamet kommer att äga dataschemat i det analytiska lagret.
I det här scenariot blir teamet väldigt ledsna katter och här är anledningen:
- Hon måste övervaka förändringar i ALLT tjänster inom företaget. Och det finns många av dem och många ändringar (i genomsnitt slår vi samman ~100 pull-förfrågningar per vecka, medan många tjänster inte gör pull-förfrågningar alls).
- När du ändrar dataschemat måste produktägaren och teamet som ändrar dataschemat vänta på att Data Engineering lägger till den kod som krävs för att stödja ändringarna. Samtidigt har vi varit funktionsrika länge och situationen när ett lag väntar på ett annat är väldigt sällsynt. Och vi vill inte att detta ska bli en "normal" del av utvecklingsprocessen.
- Den måste fördjupas i ALLT företagsverksamhet. Pizzeriakedjan ser ut som en enkel affär, men det verkar bara så. Det är mycket svårt att samla tillräckligt med kompetens i ett team för att bygga en adekvat datamodell för hela företaget.
- Det är en enda punkt av misslyckande. Varje gång du behöver ändra data som returneras av tjänsten eller skriva en förfrågan faller alla dessa uppgifter på Data Engineering-teamet. Som ett resultat har laget en överbelastad eftersläpning.
Det visar sig att teamet befinner sig i skärningspunkten mellan ett stort antal behov och sannolikt inte kommer att kunna tillfredsställa dem. Samtidigt kommer du att vara under konstant tidspress och stress. Vi vill verkligen inte ha det här. Därför måste vi tänka på hur vi ska lösa dessa problem och samtidigt kunna analysera datan.
Flytta från Data Lake till Data Mesh
Lyckligtvis var vi inte de enda som ställde oss denna fråga. Faktum är att ett liknande problem redan är löst i branschen (halleluja!). Bara inom ett annat område: applikationsdistribution. Ja, jag pratar om DevOps-metoden, där teamet bestämmer hur de ska distribuera produkten de skapar.
Ett liknande tillvägagångssätt för att lösa Data Lake-problem föreslogs av Zhamak Dehghani, en ThoughtWorks-konsult. När hon såg hur Netflix och Spotify löser liknande problem skrev hon en fantastisk artikel (länken till den fanns i början av artikeln). De viktigaste idéerna som vi tog bort från det:
- Dela upp en stor Data Lake i datadomäner, som är mycket lika domändrivna designdomäner. Varje domän är ett litet avgränsat sammanhang.
- Feature Teams som är ansvariga för DDD-domäner är också ansvariga för motsvarande datadomäner. De lagrar schemat, gör ändringar i det och laddar in data i det. Samtidigt vet de själva allt: hur man ändrar dataladdningen och inte bryter något när applikationen ändras. Kunskap går ingenstans. De behöver inte gå någonstans för att öppna data. Teamet leder själva hela utvecklingscykeln från att ändra driftsdata till att tillhandahålla analytisk data till tredje part. Ett team äger allt som är associerat med domänen (både affärs- och datadomäner).
- Dataingenjör – roll inom Feature Team. Detta behöver inte vara en individ, men det är absolut nödvändigt att laget har denna kompetens.
Samtidigt har Data Engineering-teamet...
Om du föreställer dig att allt detta förverkligas med ett knäpp med fingrarna, behöver du bara svara på två frågor:
Vad kommer Data Engineering-teamet att göra nu? Dodo Pizza Engineering har redan ett plattform/SRE-team. Dess mål är att ge utvecklare verktygen för att enkelt distribuera tjänster. Datateknikteamet kommer att utföra samma roll endast för data.
Att förvandla operativ data till analytisk data är en komplex process. Att göra analytisk data tillgänglig för hela företaget är ännu svårare. Det är dessa problem som Data Engineering-teamet kommer att ta itu med.
Vi kommer att förse Feature Team med en praktisk uppsättning verktyg och metoder så att de kan publicera data från sin tjänst till resten av företaget. Vi kommer också att ansvara för de allmänna infrastrukturdelarna av datapipelinen (köer, tillförlitlig lagring, kluster för att utföra transformationer på data).
Hur kommer dataingenjörskompetensen att visas inom Feature Team? Med Feature Team är det mer komplicerat. Naturligtvis kan vi försöka anställa en dataingenjör för vart och ett av våra team. Men det är så svårt. Att hitta någon med en bra datavetenskaplig bakgrund och övertyga honom om att arbeta inom ett produktteam är svårt.
Det stora pluset med Dodo är att vi älskar intern utbildning. Så nu är vår plan denna: Data Engineering-teamet börjar publicera data från vissa tjänster, gråter, injicerar sig själv, men fortsätter att äta kaktus. När vi vet att vi har en publiceringsprocess på plats börjar vi kommunicera den till Feature Team.
Vi har flera sätt att göra detta:
- , där vi går igenom hur processen vi har skapat ser ut, vilka verktyg som finns tillgängliga och hur du använder dem mest effektivt.
- Att tala på DevForum kommer att hjälpa oss att samla in feedback från produktutvecklare. Efter detta kommer vi att kunna gå med i produktteam och hjälpa dem att lösa problem med publicering av data och organisera utbildningar för team.
Dataförbrukning
Nu har jag pratat mycket om att publicera data. Men det finns också konsumtion. Hur är det med den här frågan?
Vi har ett fantastiskt BI-team som skriver mycket komplexa rapporter för förvaltningsbolaget. Inuti Dodo IS finns det många rapporter för våra partners som hjälper dem att hantera sina pizzerior. I vår nya modell tänker vi på dem som datakonsumenter som har sina egna datadomäner. Och det är konsumenterna som kommer att ansvara för sina egna domäner. Ibland kan en konsuments domän beskrivas i en fråga till det analytiska lagret – och det är bra. Men vi förstår att detta inte alltid kommer att fungera. Det är därför vi vill att plattformen som vi ska skapa för produktteam ska kunna användas även av datakonsumenter (trots allt när det gäller rapporter inom Dodo IS kommer det att vara samma team).
Så ser vi på att arbeta med data i Dodo Pizza Engineering. Vi kommer gärna att läsa dina tankar om denna fråga i kommentarerna.
Källa: will.com
