Witaj, Habro! W Dodo Pizza Engineering kochamy dane (a kto ich obecnie nie kocha?). Teraz będzie opowieść o tym, jak zgromadzić wszystkie dane w świecie Dodo Pizza i zapewnić każdemu pracownikowi firmy wygodny dostęp do tego zbioru danych. Zadanie pod gwiazdką: utrzymać nerwy zespołu Data Engineering.
Podobnie jak prawdziwi Plyushkins, gromadzimy wszelkiego rodzaju informacje o pracy naszych pizzerii:
- zapamiętuj wszystkie zamówienia użytkowników;
- wiemy, ile czasu zajęło zrobienie pierwszej pizzy w Syktywkarze;
- widzimy teraz, ile czasu zajmuje pizza stygnięcie na półce grzewczej w Woroneżu;
- Przechowujemy dane o odpisach produktowych;
- i wiele innych.
Za pracę z danymi w Dodo Pizza odpowiada teraz kilka zespołów, jednym z nich jest zespół Data Engineering. Teraz oni (czyli my) stoją przed zadaniem zapewnienia każdemu pracownikowi firmy wygodnego dostępu do tego szeregu danych.
Kiedy zaczęliśmy myśleć o tym, jak to zrobić i zaczęliśmy omawiać problem, znaleźliśmy bardzo interesujące podejście do zarządzania danymi - (kliknij link, znajdziesz ogromny, niesamowity artykuł). Jej pomysły bardzo dobrze wpisują się w naszą koncepcję tego, jak chcemy zbudować nasz system. W dalszej części artykułu omówimy nasze przemyślenia na temat tego podejścia i tego, jak widzimy jego wdrożenie w Dodo Pizza Engineering.
Co rozumiemy przez „dane”
Na początek zdefiniujmy co rozumiemy pod pojęciem danych w Dodo Pizza Engineering:
- Zdarzenia wysyłane przez usługi (posiadamy wspólną magistralę zbudowaną przy użyciu RabbitMQ);
- Rekordy wewnątrz bazy danych (u nas jest to MySQL i CosmosDB);
- Clickstream z aplikacji mobilnej i strony internetowej.
Aby firma Dodo Pizza mogła korzystać z tych danych i na nich polegać, ważne jest, aby zostały spełnione następujące warunki:
- Muszą być kompletne. Musimy mieć pewność, że nie zmieniamy danych w trakcie ich przetwarzania, przechowywania i wyświetlania. Jeśli firmy nie będą mogły ufać naszym danym, nie będą one przydatne.
- Muszą mieć znacznik czasu i nie mogą być nadpisywane. Oznacza to, że w dowolnym momencie chcemy mieć możliwość cofnięcia się i przejrzenia danych z tamtego okresu. Dowiedz się na przykład, ile pizzy sprzedano 8 lipca 2018 r.
- Muszą być niezawodne. W procesie gromadzenia i przechowywania danych nie możemy stracić nie tylko integralności, ale i wiarygodności. Nie możemy stracić danych, odcinków czasu, bo wraz z nimi tracimy zaufanie naszych klientów (zarówno zewnętrznych, jak i wewnętrznych).
- Muszą być ze stabilnym obwodem - piszemy prośby o te dane. Bardzo nie chcielibyśmy, żeby wraz ze zmianami w kodzie aplikacji, refaktoryzacją zmieniało się tak bardzo, że nasze zapytania przestaną działać. Osoba pisząca zapytania nigdy nie będzie wiedzieć, że dokonałeś refaktoryzacji, dopóki wszystko się nie zepsuje. Nie chciałbym słyszeć o tym od klientów.
Biorąc pod uwagę wszystkie te wymagania, doszliśmy do wniosku, że dane w Dodo są produktem. Taki sam jak publiczny interfejs API usługi. W związku z tym ten sam zespół, który jest właścicielem usługi, powinien być właścicielem danych. Ponadto zmiany w schemacie danych muszą zawsze być kompatybilne wstecz.
Podejście tradycyjne – jezioro danych
Aby rozwiązać problemy niezawodnego przechowywania i przetwarzania dużych zbiorów danych, w wielu firmach pracujących z taką pulą informacji stosuje się tradycyjne podejście - Data Lake. W ramach tego podejścia inżynierowie danych zbierają informacje ze wszystkich komponentów systemu i umieszczają je w jednym dużym repozytorium (może to być np. Hadoop, Azure Kusto, Apache Cassandra, czy nawet replika MySQL, jeśli dane mieszczą się w To).
Następnie ci sami inżynierowie zapisują żądania do takiego magazynu. Wdrożenie tego podejścia w Dodo Pizza Engineering oznacza, że zespół Data Engineering będzie właścicielem schematu danych w hurtowni analitycznej.
W tym scenariuszu zespół staje się bardzo smutny i oto dlaczego:
- Musi monitorować zmiany w WSZYSTKO usług w firmie. A jest ich mnóstwo i mnóstwo zmian (średnio łączymy ~100 pull requestów tygodniowo, podczas gdy wiele serwisów w ogóle nie wykonuje pull requestów).
- Zmieniając schemat danych, właściciel produktu i zespół zmieniający schemat danych muszą poczekać, aż Data Engineering doda kod niezbędny do obsługi zmian. Jednocześnie od dawna jesteśmy bogaci w funkcje i sytuacja, w której jedna drużyna czeka na drugą, jest bardzo rzadka. Nie chcemy, aby stało się to „normalną” częścią procesu rozwoju.
- Trzeba się w tym zanurzyć WSZYSTKO biznes firmy. Sieć pizzerii wygląda na prosty biznes, ale tylko tak się wydaje. Bardzo trudno jest zgromadzić w jednym zespole wystarczającą ilość kompetencji, aby zbudować odpowiedni model danych dla całej firmy.
- To pojedynczy punkt awarii. Za każdym razem, gdy zachodzi potrzeba zmiany danych zwracanych przez usługę lub napisania wniosku, wszystkie te zadania spadają na zespół Data Engineering. W rezultacie zespół ma przeciążone zaległości.
Okazuje się, że zespół znajduje się na skrzyżowaniu ogromnej liczby potrzeb i raczej nie będzie w stanie ich zaspokoić. Jednocześnie będziesz pod ciągłą presją czasu i stresem. Naprawdę tego nie chcemy. Dlatego musimy pomyśleć o tym, jak rozwiązać te problemy, a jednocześnie umieć analizować dane.
Przejście z Data Lake do Data Mesh
Na szczęście nie tylko my zadawaliśmy sobie to pytanie. Tak naprawdę podobny problem został już w branży rozwiązany (alleluja!). Tylko w innym obszarze: wdrażanie aplikacji. Tak, mówię o podejściu DevOps, gdzie zespół określa sposób wdrożenia stworzonego przez siebie produktu.
Podobne podejście do rozwiązywania problemów Data Lake zaproponował Zhamak Dehghani, konsultant ThinkWorks. Obserwując, jak Netflix i Spotify rozwiązują podobne problemy, napisała niesamowity artykuł (link do niego był na początku artykułu). Główne idee, które z niego zaczerpnęliśmy:
- Podziel duże jezioro danych na domeny danych, które są bardzo podobne do domen projektowych opartych na domenach. Każda domena jest małym, ograniczonym kontekstem.
- Zespoły funkcyjne odpowiedzialne za domeny DDD są również odpowiedzialne za odpowiadające im domeny danych. Przechowują schemat, wprowadzają w nim zmiany i ładują do niego dane. Jednocześnie sami wiedzą wszystko: jak zmienić ładowanie danych i niczego nie zepsuć przy zmianie aplikacji. Wiedza nie znika. Nie muszą nigdzie iść, aby otworzyć dane. Zespół sam prowadzi pełny cykl rozwoju od zmiany danych operacyjnych po udostępnienie danych analitycznych podmiotom trzecim. Jeden zespół jest właścicielem wszystkiego, co jest powiązane z domeną (zarówno domeną biznesową, jak i domeną danych).
- Inżynier Danych – rola w Zespole Feature. Nie musi to być pojedyncza osoba, konieczne jest jednak, aby zespół posiadał takie kompetencje.
Tymczasem zespół Data Engineering...
Jeśli wyobrażasz sobie, że wszystko to można zrealizować na pstryknięcie palców, wystarczy odpowiedzieć tylko na dwa pytania:
Co teraz zrobi zespół Data Engineering? Dodo Pizza Engineering ma już zespół ds. platformy/SRE. Jego celem jest zapewnienie programistom narzędzi do łatwego wdrażania usług. Zespół inżynierii danych będzie pełnił tę samą rolę tylko w przypadku danych.
Przekształcanie danych operacyjnych w dane analityczne to złożony proces. Jeszcze trudniejsze jest udostępnienie danych analitycznych całej firmie. To właśnie tymi problemami zajmie się zespół Data Engineering.
Zamierzamy zapewnić zespołowi ds. funkcji wygodny zestaw narzędzi i praktyk, dzięki którym będzie mógł publikować dane ze swoich usług reszcie firmy. Będziemy również odpowiedzialni za ogólną infrastrukturę potoku danych (kolejki, niezawodne magazyny, klastry do wykonywania transformacji danych).
W jaki sposób umiejętności inżyniera danych będą widoczne w zespole ds. funkcji? W przypadku Feature Team jest to bardziej skomplikowane. Oczywiście moglibyśmy spróbować zatrudnić jednego Inżyniera Danych do każdego z naszych zespołów. Ale to takie trudne. Znalezienie kogoś z dobrą znajomością data science i przekonanie go do pracy w zespole produktowym jest trudne.
Dużym plusem Dodo jest to, że uwielbiamy szkolenia wewnętrzne. Więc teraz nasz plan jest taki: zespół Data Engineering zaczyna publikować dane z niektórych serwisów, płacze, wstrzykuje sobie, ale nadal zjada kaktusa. Kiedy już wiemy, że mamy wdrożony proces wydawniczy, zaczynamy komunikować go zespołowi ds. funkcji.
Mamy na to kilka sposobów:
- , gdzie przeprowadzimy Cię przez to, jak wygląda stworzony przez nas proces, jakie narzędzia są dostępne i jak najefektywniej z nich korzystać.
- Wystąpienia na DevForum pomogą nam zebrać opinie od twórców produktów. Po tym będziemy mogli dołączyć do zespołów produktowych i pomóc im w rozwiązywaniu problemów z publikowaniem danych oraz organizować szkolenia dla zespołów.
Zużycie danych
Teraz dużo mówiłem o publikowaniu danych. Ale jest też konsumpcja. A co z tą kwestią?
Mamy niesamowity zespół BI, który pisze bardzo złożone raporty dla firmy zarządzającej. Wewnątrz Dodo IS znajduje się wiele raportów dla naszych partnerów, które pomagają im zarządzać pizzeriami. W naszym nowym modelu myślimy o nich jak o konsumentach danych, którzy mają własne domeny danych. I to konsumenci będą odpowiedzialni za własne domeny. Czasami domenę konsumenta można opisać jednym zapytaniem do hurtowni analitycznej – i to jest dobre. Rozumiemy jednak, że nie zawsze to będzie działać. Dlatego chcemy, aby z platformy, którą stworzymy dla zespołów produktowych, mogli korzystać także konsumenci danych (w końcu w przypadku raportów w ramach Dodo IS będą to te same zespoły).
Tak widzimy pracę z danymi w Dodo Pizza Engineering. Chętnie przeczytamy Wasze przemyślenia na ten temat w komentarzach.
Źródło: www.habr.com
