Helló, Habr! A Dodo Pizza Engineering csapatnál nagyon szeretjük az adatokat (ki nem szereti azokat manapság?). Most egy olyan történetet mesélünk el, amely arról szól, hogyan gyűjtsük össze a Dodo Pizza világának összes adatát, és hogyan tegyük ezeket kényelmesen elérhetővé bármely cég munkatársa számára. A feladat csillaggal: megőrizni a Data Engineering csapat idegeit.
Igazi gyűjtögetőkként mindenféle információt összegyűjtünk a pizzériáink működéséről:
- jegyezzük az összes felhasználói rendelést;
- tudjuk, mennyi időbe telt az első pizza elkészítése Sziktivkárban;
- látjuk, mennyi idő alatt hűl ki a pizza a hőgondozó polcon Vornyében éppen most;
- tároljuk az alapanyagok leírását;
- és még sok minden mást.
Az adatokkal való munkát a Dodo Pizza-nál jelenleg több csapat végzi, az egyik pedig a Data Engineering csapat. Jelenleg előttük (vagyis előttünk) áll a feladat: a cég bármely munkatársa számára kényelmes hozzáférést biztosítani ehhez az adathalmoz.
Amikor elkezdtük gondolkodni azon, hogyan lehetne ezt megvalósítani, és elkezdtük megvitatni a feladatot, egy nagyon érdekes adatkezelési megközelítésre bukkantunk - (a hivatkozás alatt egy hatalmas, csodás cikket találsz). Az elképzelései nagyon jól illeszkednek abba, ahogyan mi szeretnénk felépíteni a rendszerünket. A cikk további részében bemutatjuk a megközelítés újragondolását és azt, hogyan látjuk annak bevezetését a Dodo Pizza Engineeringben.
Mit értünk „adatok” alatt
Először is határozzuk meg, mit értünk adat alatt a Dodo Pizza Engineeringnél:
- Az események, amelyeket a szolgáltatások küldenek (van egy közös buszunk, amelyet RabbitMQ segítségével építettünk);
- Adatbázison belüli rekordok (számunkra ez MySQL és CosmosDB);
- Kattintási adatfolyam a mobilalkalmazásból és a weboldalról.
Ahhoz, hogy a Dodo Pizza üzlete fel tudja használni ezeket az adatokat és megbízhasson bennük, fontos, hogy az alábbi feltételek teljesüljenek:
- Azoknak teljeseknek kell lenniük. Biztosnak kell lennünk abban, hogy az adatokat nem módosítjuk a feldolgozás, tárolás és megjelenítés során. Ha az üzlet nem bízhat az adatainkban, akkor semmiféle haszna nem lesz belőlük.
- Időbélyeggel kell rendelkezniük, és nem szabad őket felülírni. Ez azt jelenti, hogy bármikor lehetőségünk van visszalépni, és megnézni az adatokat abban az időszakban. Például megtudni, hány pizzát adtak el 2018. július 8-án.
- Megbízhatóknak kell lenniük. Az adatok gyűjtése és tárolása során nemcsak az integritást, hanem a megbízhatóságot is meg kell őriznünk. Nem veszhetnek el az adatok és az időtartományok, mert ezekkel együtt a külső és belső ügyfeleink bizalmát is elveszítjük.
- Stabil séma szerint kell működniük – kérdéseket írunk ezekhez az adatokhoz. Nagyon nem szeretnénk, ha az alkalmazás kódjának megváltoztatásával, a refaktorálással olyan mértékben változnának, hogy a kérdéseink működésképtelenné válnának. Aki a kérdéseket írja, soha nem értesül arról, hogy refaktoráltatok, amíg minden tönkre nem megy. Nem szeretnénk ezt az ügyfelektől megtudni.
Figyelembe véve ezeket a követelményeket, arra a következtetésre jutottunk, hogy a Dodo adatai egy termék. Olyan, mint a szolgáltatás nyilvános API-ja. Ennek megfelelően az adatok tulajdonosának annak a csapatnak kell lennie, amely a szolgáltatást is birtokolja. Emellett az adatséma módosításának mindig hátrafelé kompatibilisnek kell lennie.
Hagyományos megközelítés – Adat-tó
A nagy adatok megbízható tárolásának és feldolgozásának feladatainak megoldására a sok vállalatnál alkalmazott hagyományos megközelítés a Data Lake. Ennek keretében az adatfeldolgozó mérnökök az összes rendszerkomponenstől gyűjtik az adatokat, és összegyűjtik egy nagy tárolóba (például Hadoop, Azure Kusto, Apache Cassandra vagy akár MySQL replikáció, ha az adatok beleférnek).
Azután ugyanezek a mérnökök kérdéseket írnak a tárolóhoz. A Dodo Pizza Engineeringben ennek a megközelítésnek a megvalósítása azt jelenti, hogy az Adatmérnöki csapatnak kell birtokolnia az analitikai tároló adatsémáját.
Ezekben az eseményekben a csapat nagyon szomorú macskákká válik, és ennek az oka a következő:
- Figyelemmel kell kísérniük a változásokat az ÖSSZES vállalati szolgáltatásban. És sok van belőlük, a változások száma is jelentős (átlagosan ~100 pull requestet olvasztunk össze hetente, miközben sok szolgáltatás egyáltalán nem csinál pull requestet).
- Az adatséma megváltozása esetén a terméktulajdonosnak és a séma módosításán dolgozó csapatnak várnia kell, amíg az Adatmérnöki csapat be nem fejezi a szükséges kódot, hogy a változások támogathatók legyenek. Ezen kívül már régóta elkészült funkcióink vannak, és az a helyzet, amikor az egyik csapat vár egy másikra – nagyon ritka. Nem szeretnénk, ha ez "normális" részévé válna a fejlesztési folyamatnak.
- Teljesen el kell mélyedniük a MINDEN A vállalat üzlete. A pizzéria hálózat egyszerű vállalkozásnak tűnik, de ez csak látszat. Nagyon nehéz egy csapatba elegendő kompetenciát összegyűjteni a vállalat számára megfelelő adatminta felépítéséhez.
- Ez egyetlen hibalehetőség. Minden alkalommal, amikor módosítani kell az adatokat, amelyeket a szolgáltatás visszaad, vagy írni kell egy lekérdezést, ezek a feladatok mind a Data Engineering csapatra hárulnak. Ennek eredményeként a csapat túlterhelt hátralékban találja magát.
Tehát a csapat egy hatalmas igények kereszteződésében van, és valószínűleg nem tudja ezeket kielégíteni. Eközben folyamatosan időhiányban és stresszben lesz. Ilyet nagyon nem szeretnénk. Ezért kell gondolkodnunk a problémák megoldásán, miközben lehetőséget szeretnénk kapni az adatok elemzésére.
A Data Lake-től a Data Mesh-ig
Szerencsére ezt a kérdést nem csak mi tettük fel. Valójában hasonló problémát már megoldottak az iparban (halleluja!). Csak egy másik területen: az alkalmazások telepítése. Igen, a DevOps megközelítésről beszélek, ahol a csapat meghatározza, hogyan kell telepíteni a terméket, amelyet létrehoznak.
Hasonló megközelítést javasolt a Data Lake problémájának megoldására Zhamak Dehghani, a ThoughtWorks tanácsadója. Figyelve, hogyan oldják meg az ilyen feladatokat a Netflixnél és a Spotifynál, írt egy lenyűgöző cikket (a cikk hivatkozása az írás elején található). Azok a főbb ötletek, amelyeket belőle levontunk:
- Osszuk fel a nagy Data Lake-et adományi domainokra, amelyek nagyon hasonlítanak a domain-driven design domainekre. Minden domain – kis bounded context.
- A Feature Team, akik a DDD domainekért felelnek, felelnek a megfelelő adományi domainekért is. Ők tárolják a sémát, változtatnak rajta, adatokat töltenek be. Eközben mindent tudnak arról, hogyan módosítsák az adatbetöltést és semmit ne törjenek el, amikor az alkalmazás változik. A tudás nem vész el. Az adatok megnyitásához nem kell sehova menniük. A csapat maga vezeti a fejlesztési ciklust a működési adatok módosításától kezdve a harmadik felek számára történő analitikai adatok biztosításáig. Egy csapat birtokol mindent, ami a domainhez kapcsolódik (mind a vállalati domain, mind az adományi domain esetében).
- Data Engineer – szerep a Feature Team-en belül. Nem szükséges, hogy külön személy legyen, de fontos, hogy a csapat rendelkezzen ezzel a kompetenciával.
És eközben a Data Engineering csapat...
Ha elképzeljük, hogy mindez egy csapásra megvalósul, akkor két kérdést kell még megválaszolni:
Mivel fog most foglalkozni a Data Engineering csapata? A Dodo Pizza Engineering már rendelkezik egy platform/SRE csapattal. Az ő feladatuk, hogy az fejlesztők számára eszközöket biztosítsanak a szolgáltatások egyszerű telepítéséhez. A Data Engineering csapat ugyanazt a szerepet fogja betölteni, csak adatok esetében.
Az operatív adatok analitikai adatokká alakítása nehéz folyamat. Az analitikai adatok elérhetővé tétele az egész cég számára még nehezebb. A Data Engineering csapat pontosan ezeknek a problémáknak a megoldásával foglalkozik.
Tervezzük, hogy a Feature Team számára egy kényelmes eszköz- és gyakorlatcsomagot biztosítunk, amellyel a saját szolgáltatásuk adatait közzétehetik a vállalat többi része számára. Emellett felelősek leszünk a data pipeline közös infrastruktúra-szolgáltatásaiért (sorok, megbízható tárolás, klaszterek az adatok átalakításához).
Hogyan fognak a Data Engineer készségek megjelenni a Feature Team-en belül? A Feature Team esetében minden bonyolultabb. Természetesen megpróbálhatnánk egy-egy Data Engineer-t felvenni minden csapatunkhoz. De ez nagyon nehéz. Nehéz olyan embert találni, aki jó háttérrel rendelkezik az adatok feldolgozásában, és meg tudjuk győzni őt, hogy a termékcsapatban dolgozzon.
A Dodo nagy előnye, hogy szeretjük a belső képzéseket. Szóval a tervünk most az, hogy a Data Engineering csapat elkezdi bizonyos szolgáltatások adatait közzétenni, sír, megégeti magát, de továbbra is eszi a kaktuszt. Amint megértjük, hogy van egy kész folyamatunk a közzétételhez, elkezdjük megosztani ezt az információt a Feature Team-el.
Több módja is van annak, hogyan tegyük ezt:
- , ahol bemutatjuk, hogyan néz ki a folyamat, amit létrehoztunk, milyen eszközök állnak rendelkezésre, és hogyan lehet ezeket leghatékonyabban használni.
- A DevForum-ra tett előadás segít abban, hogy visszajelzést gyűjtsünk a termékfejlesztőktől. Ezt követően csatlakozhatunk a termékcsapatokhoz, hogy segítsünk nekik az adatok közzétételével kapcsolatos feladatokban, és tréningeket szervezhetünk a csapatok számára.
Adatok fogyasztása
Most sokat beszéltem az adatok közzétételéről. De az adatok fogyasztása is fontos. Mi a helyzet ezzel kapcsolatban?
Van egy nagyszerű BI csapatunk, amely nagyon összetett jelentéseket készít a menedzsment számára. A Dodo IS-en belül sok jelentés található, amelyek segítik partnereinket a pizzériák irányításában. Az új modellünkben úgy tekintünk rájuk, mint adatfogyasztókra, akiknek saját adatdomainjeik vannak. Pontosan az adatfogyasztók felelnek majd a saját domainjeikért. Néha az adatfogyasztó domainje egyetlen lekérdezéssel leírható az analitikai tárolóban – és ez rendben van. De tisztában vagyunk azzal, hogy ez nem mindig fog működni. Ezért szeretnénk, ha az a platform, amelyet a termékcsapatok számára létrehozunk, adatfogyasztók által is használható lenne (hiszen a Dodo IS-en belüli jelentések esetében egy és ugyanazon csapatok lesznek).
Így látjuk az adatokkal való munkát a Dodo Pizza Engineering csapatában. Örömmel várjuk gondolatait a téma kapcsán a megjegyzések között.
Forrás: habr.com
