Cześć, Habr! W Dodo Pizza Engineering uwielbiamy dane (a kto ich teraz nie kocha?). Teraz opowiemy historię o tym, jak zgromadzić wszystkie dane świata Dodo Pizza i umożliwić każdemu pracownikowi firmy wygodny dostęp do tego zbioru danych. Zadanie z gwiazdką: zachować nerwy zespołu Data Engineering.
Jak prawdziwi chciwcy, zbieramy wszelkie informacje o działalności naszych pizzerii:
- pamiętamy wszystkie zamówienia użytkowników;
- wiemy, ile czasu zajęło przygotowanie pierwszej pizzy w Syktywkarze;
- widzimy, ile czasu pizza stygnie na półce grzewczej w Woroneżu w tej chwili;
- przechowujemy dane dotyczące ubytków produktów;
- i wiele, wiele innych.
Za obsługę danych w Dodo Pizza odpowiada obecnie kilka zespołów, a jednym z nich jest zespół Data Engineering. Teraz przed nami (czyli nami) stoi zadanie: umożliwić każdemu pracownikowi firmy wygodny dostęp do tego zbioru danych.
Kiedy zaczęliśmy myśleć, jak to zrobić i zaczęliśmy omawiać to zadanie, znaleźliśmy bardzo interesujące podejście do zarządzania danymi – (w linku znajdziesz ogromny, wspaniały artykuł). Jej pomysły bardzo dobrze wpisują się w nasze wyobrażenie o tym, jak chcemy zbudować nasz system. W dalszej części artykułu przedstawimy nasze przemyślenia na temat tego podejścia i to, jak widzimy jego wdrożenie w Dodo Pizza Engineering.
Co mamy na myśli mówiąc o «danych»
Na początek określmy, co rozumiemy przez dane w Dodo Pizza Engineering:
- Zdarzenia, które wysyłają serwisy (mamy wspólną szynę zbudowaną z pomocą RabbitMQ);
- Rekordy w bazie danych (dla nas to MySQL i CosmosDB);
- Clickstream z aplikacji mobilnej i strony internetowej.
Aby biznes Dodo Pizza mógł korzystać z tych danych i polegać na nich, ważne jest, aby spełnione były następujące warunki:
- Muszą być integralne. Musimy mieć pewność, że nie zmieniamy danych w procesie ich przetwarzania, przechowywania i wyświetlania. Jeśli biznes nie będzie mógł ufać naszym danym, nie będą one miały żadnej wartości.
- Muszą mieć znacznik czasowy i nie mogą być nadpisywane. Oznacza to, że w każdej chwili chcemy mieć możliwość powrotu do przodu i spojrzenia na dane z danego okresu czasu. Na przykład, sprawdzić, ile pizz sprzedano 8 lipca 2018 roku.
- Muszą być niezawodne. W procesie zbierania i przechowywania danych musimy dbać nie tylko o integralność, ale również o niezawodność. Nie możemy tracić danych, ani fragmentów czasowych, ponieważ tracimy wtedy zaufanie naszych klientów (zarówno zewnętrznych, jak i wewnętrznych).
- Musi być stabilna struktura – piszemy zapytania do tych danych. Chcielibyśmy uniknąć sytuacji, w której zmiany w kodzie aplikacji, refaktoryzacja, spowodują, że nasze zapytania przestaną działać. Osoba pisząca zapytania nigdy nie dowie się, że przeprowadzono refaktoryzację, aż wszystko się całkowicie rozpadnie. Nie chcielibyśmy się o tym dowiedzieć od klientów.
Biorąc pod uwagę wszystkie te wymagania, doszliśmy do wniosku, że dane w Dodo to produkt. Taki sam, jak publiczne API usługi. Z tego wynika, że zespół, który zarządza danymi, powinien być tym samym zespołem, który zarządza usługą. Zmiany w schemacie danych zawsze powinny być również wstecznie zgodne.
Tradycyjne podejście – Data Lake
W celu niezawodnego przechowywania i przetwarzania dużych danych istnieje tradycyjne podejście, przyjęte w wielu firmach, które pracują z tak dużymi zbiorami informacji – Data Lake. W ramach tego podejścia inżynierowie danych zbierają informacje ze wszystkich komponentów systemu i przechowują je w jednym dużym magazynie (może to być na przykład Hadoop, Azure Kusto, Apache Cassandra czy nawet replikacja MySQL, jeśli dane się w niej zmieszczą).
Następnie ci sami inżynierowie piszą zapytania do tego magazynu. Implementacja tego podejścia w Dodo Pizza Engineering zakłada, że zespół Data Engineering będzie zarządzał schematem danych w hurtowni analitycznej.
Przy tym scenariuszu zespół staje się bardzo smutnymi kotami i oto dlaczego:
- Musi śledzić zmiany w WSZYSTKICH usługach w firmie. A jest ich wiele i zmian jest bardzo dużo (średnio scalamy ~100 pull requestów w tygodniu, podczas gdy wiele usług w ogóle nie korzysta z pull requestów).
- Przy zmianie schematu danych właściciel produktu i zespół zmieniający schemat danych muszą czekać, aż Data Engineering napisze kod potrzebny do wsparcia tych zmian. Przy tym sytuacja, w której jeden zespół czeka na drugi, jest już od dawna rzadkością. I nie chcemy, aby to stało się 'normalną' częścią procesu rozwoju.
- Musi być zaangażowany w CAŁOŚĆ biznes firmy. Sieć pizzerii wydaje się prostym biznesem, ale to tylko pozory. Bardzo trudno zebrać w jednym zespole wystarczająco kompetencji do stworzenia odpowiedniego modelu danych dla całej firmy.
- Jest to jedyny punkt awarii. Za każdym razem, gdy trzeba zmienić dane, które zwraca serwis lub napisać zapytanie – wszystkie te zadania trafiają do zespołu Data Engineering. W efekcie zespół ma przeciążony backlog.
Okazuje się, że zespół znajduje się w punkcie przecięcia ogromnej liczby potrzeb i raczej nie jest w stanie ich zaspokoić. Przy tym będzie znajdować się w ciągłym pośpiechu i stresie. Tego bardzo nie chcemy. Dlatego musimy myśleć, jak rozwiązać te problemy i jednocześnie uzyskać możliwość analizy danych.
Przechodząc od Data Lake do Data Mesh
Na szczęście to pytanie zadawali sobie nie tylko my. W rzeczywistości podobny problem został już rozwiązany w branży (alleluja!). Tylko w innej dziedzinie: wdrożenie aplikacji. Tak, mówię o podejściu DevOps, gdzie zespół określa, jak należy wdrażać produkt, który tworzą.
Podobne podejście do rozwiązywania problemów Data Lake zaproponowała Zhamak Dehghani, konsultantka w ThoughtWorks. Obserwując, jak podobne zadania rozwiązują Netflix i Spotify, napisała zdumiewający artykuł (link do niego był na początku artykułu). Główne idee, które z niej wyciągnęliśmy:
- Podzielić duży Data Lake na domeny danych, które bardzo przypominają domeny w projektowaniu sterowanym domeną (domain-driven design). Każda domena to mały bounded context.
- Zespoły Feature, które odpowiadają za domeny DDD, odpowiadają także za odpowiednie domeny danych. Przechowują schemat, wprowadzają w nim zmiany, ładują do niego dane. Przy tym wszystko wiedzą: jak zmienić ładowanie danych i nie zepsuć nic, gdy aplikacja się zmienia. Wiedza nie znika. Aby udostępnić dane, nie muszą nigdzie iść. Sam zespół prowadzi pełen cykl rozwoju od zmiany danych operacyjnych po dostarczenie danych analitycznych osobom trzecim. Jeden zespół zarządza wszystkim związanym z domeną (zarówno domeną biznesową, jak i domeną danych).
- Data Engineer – rola w zespole Feature. To nie musi być koniecznie osobny człowiek, ale zespół musi dysponować tymi kompetencjami.
A w tym czasie zespół Data Engineering...
Jeśli wyobrazimy sobie, że wszystko odbywa się za jednym kliknięciem, pozostaje odpowiedzieć na dwa pytania:
Czym teraz zajmie się zespół Data Engineering? W Dodo Pizza Engineering już istnieje zespół platformy/SRE. Jego zadaniem jest dostarczenie programistom narzędzi do łatwego wdrażania usług. Zespół Data Engineering będzie pełnił taką samą rolę, ale dla danych.
Przekształcenie danych operacyjnych w analityczne to skomplikowany proces. Uczynienie danych analitycznych dostępnymi dla całej firmy jest jeszcze trudniejsze. To właśnie tymi problemami zajmie się zespół Data Engineering.
Zamierzamy dostarczyć zespołowi Feature Team wygodny zestaw narzędzi i praktyk, za pomocą których będą mogli publikować dane ze swojego serwisu dla reszty firmy. Będziemy również odpowiedzialni za ogólne części infrastruktury data pipeline (kolejki, niezawodne przechowywanie, klastry do przeprowadzania transformacji danych).
Jak umiejętności Data Engineer pojawią się w zespole Feature Team? W przypadku zespołu Feature Team sprawa jest bardziej skomplikowana. Oczywiście moglibyśmy spróbować zatrudnić jednego Data Engineera do każdej z naszych drużyn. Ale to bardzo trudne. Znalezienie osoby z dobrym doświadczeniem w przetwarzaniu danych i przekonanie jej do pracy w zespole produktowym jest wyzwaniem.
Dużym plusem Dodo jest to, że lubimy wewnętrzne szkolenia. Tak więc nasz plan na teraz jest taki: zespół Data Engineering zaczyna publikować dane z niektórych serwisów, płacze, kolce, ale nadal je zjada kaktusa. Gdy tylko zrozumiemy, że mamy gotowy proces publikacji, zaczniemy o nim opowiadać w Feature Team.
Mamy kilka sposobów, jak to zrobić:
- , na którym opowiemy, jak wygląda proces, który stworzyliśmy, jakie są narzędzia i jak ich najskuteczniej używać.
- Wystąpienie na DevForum pomoże nam zebrać opinię zwrotną od programistów produktów. Po tym będziemy mogli dołączyć do zespołów produktowych i pomagać im w rozwiązywaniu problemów związanych z publikowaniem danych, organizować szkolenia dla zespołów.
Konsumpcja danych
Teraz dużo mówiłem o publikowaniu danych. Ale jest jeszcze konsumpcja. Co w tej kwestii?
Mamy wspaniały zespół BI, który tworzy bardzo kompleksowe raporty dla firmy zarządzającej. W Dodo IS znajduje się wiele raportów dla naszych partnerów, które pomagają im w zarządzaniu pizzeriami. W naszym nowym modelu myślimy o nich jako o konsumentach danych, którzy mają swoje własne obszary danych. To właśnie ci konsumenci będą odpowiedzialni za swoje własne obszary. Czasami obszar konsumenta można opisać jednym zapytaniem do hurtowni danych – i to jest w porządku. Jednak zdajemy sobie sprawę, że nie zawsze to zadziała. Dlatego chcemy, aby platforma, którą stworzymy dla zespołów produktowych, mogła być również wykorzystywana przez konsumentów danych (w przypadku raportów wewnątrz Dodo IS będą to te same zespoły).
Tak widzimy pracę z danymi w Dodo Pizza Engineering. Z przyjemnością poznamy Wasze myśli na ten temat w komentarzach.
Źródło: habr.com
