Na początku grudnia popełniłem fatalny błąd i dokonałem przełomu w swoim życiu jako programisty i przeniosłem się do zespołu Data Engineering (DE) w firmie. W tym artykule podzielę się kilkoma spostrzeżeniami, które poczyniłem podczas dwóch miesięcy pracy w zespole DE.
Dlaczego inżynieria danych?
Moja podróż do DE rozpoczęła się latem 2019 roku, kiedy to chodźmy do i tam osiągnąłem oświecenie. Zacząłem interesować się tematem, studiować algorytmy, a nawet o nich , a potem zastanowiłem się nad zakresem zastosowania i szybko przekonałem się, że praktycznym zastosowaniem w naszej firmie są rozproszone bazy danych.
Czym dokładnie zajmuje się nasz zespół? Podobnie jak wszyscy modni chłopcy i dziewczęta, chcemy stać się firmą opartą na danych. A żeby to było możliwe, musimy przynajmniej zbudować niezawodny magazyn, na którym będzie można budować dowolne raporty potrzebne firmie. Ale najważniejsze jest to, że dane znajdujące się w tym magazynie muszą być zaufane. Co więcej, korzystając z tych danych, trzeba mieć możliwość przywrócenia stanu systemu w chwili t. Wszystko to komplikuje fakt, że żyjemy w nowym, wspaniałym świecie mikrousług i z tej ideologii wynika, że każda usługa implementuje swoją małą funkcjonalność, jej baza danych to jej własny biznes i może ją usuwać przynajmniej codziennie, ale co jednocześnie musimy być w stanie odebrać i przetworzyć stan usługi.
Jeśli chcesz kierować się danymi, najpierw stań się sterowany zdarzeniami
Nie takie proste. Zdarzenia są różne, a programista i inżynier danych patrzą na nie inaczej. Opowiadanie o wydarzeniach to temat na osobny artykuł, więc nie będę się nim tutaj zajmować. Poza tym taki artykuł już był niejaki Martin Fowler, nie będę mu zabierał laurów, niech też stanie się sławny.
Generalnie jest nad czym myśleć i dlatego ten rejon jest tak atrakcyjny. Tak się składa, że w naszej firmie Inżynier Danych to znacznie szerszy obszar odpowiedzialności niż tylko osoba pisząca potoki ETL/ELT (jeśli nie wiesz, co oznaczają te skróty, przyjdź na . Jako reklama kontekstowa).
Zajmujemy się architekturą pamięci masowej, modelowaniem danych, zagadnieniami związanymi z bezpieczeństwem danych i oczywiście samymi potokami. Musimy także zadbać o to, aby z jednej strony nasza obecność nie była bardzo uciążliwa dla twórców produktów i aby w jak najmniejszym stopniu rozpraszali ich nasze wymagania podczas wprowadzania nowych funkcji do systemu, a z drugiej strony trzeba zapewnić im wygodne rozmieszczenie danych w magazynie dla analityków i zespołu BI. Tak żyjemy.
Trudności w przejściu od etapu rozwoju
Pierwszego dnia pracy napotkałem szereg trudności, którymi chcę się z Wami podzielić.
1. Pierwszą rzeczą, którą zauważyłem, był brak tulingu i niektórych praktyk. Weźmy na przykład pokrycie kodu testami. Mamy setki frameworków testowych w fazie rozwoju. Podczas pracy z danymi wszystko jest bardziej skomplikowane. Tak, możemy testować potoki ETL na danych testowych, ale musimy to wszystko zrobić ręcznie i szukać rozwiązań dla każdego konkretnego przypadku. W rezultacie zasięg testów jest znacznie gorszy. Na szczęście istnieje jeszcze jeden poziom informacji zwrotnej w postaci monitorowania i dzienników, ale to już wymaga od nas reagowania, a nie proaktywnego, co jest irytujące i wytrącające z równowagi.
2. Świat z perspektywy DE wcale nie jest tym, czym wydaje się zwykłemu twórcy produktu (no cóż, oczywiście czytelnik taki nie jest i on już wszystko wie, ale ja nie wiedziałem i teraz pierdolę to w górę). Jako programista tworzę własny mikroserwis, umieszczam dane w [wybranej bazie danych], zapisuję tam mój stan, pobieram coś po ID i jest OK. Usługa jest powolna, zamówienia są mylące, to wszystko. Proszą mnie, żebym poszukał mojego stanu w innym serwisie, więc wrzucę wydarzenie do jakiegoś RabbitMQ i tyle. I tu znowu powróciliśmy do kwestii opisanych powyżej wydarzeń.
To, czego potrzebuje usługa do pracy operacyjnej, nie odpowiada nam na danych historycznych, więc zaczyna się kwestia przerobienia umów serwisowych i ścisłej współpracy z zespołami programistycznymi. Nawet nie możesz sobie wyobrazić, ile godzin zajęło nam uzgodnienie: jakim typem Event Drivena jest w naszej firmie.
3. Trzeba myśleć głową. Nie, nie mam na myśli tego, że programiści nie myślą (choć kim jestem, żeby mówić w imieniu wszystkich), po prostu w rozwoju produktu bardzo często masz już jakąś architekturę i wycinasz różne tasowania z backlogu. Wymaga to oczywiście planowania i przemyślenia, jednak jest to praca strumieniowa, gdzie głównym problemem jest po prostu wykonanie tego dobrze i efektywnie.
Dla nas nie jest to takie proste, bo przeniesienie różnych elementów systemu z ciepłego i przytulnego monolitu do świata dzikiej dżungli mikroserwisów nie jest takie proste. Gdy usługa zacznie wyrzucać zdarzenia, należy ponownie rozważyć logikę zapełniania pamięci, ponieważ dane wyglądają teraz inaczej. Tutaj trzeba dużo i dokładnie myśleć, już nie jako programista, ale jako inżynier danych. To normalna historia, gdy spędzasz dni z notatnikiem i długopisem lub z markerem na tablicy. To bardzo trudne, nie lubię myśleć, też kocham produkcję.
4. Być może najważniejsza jest informacja. Co zrobić, gdy brakuje nam wiedzy? Kto powiedział, że stackoverflow? Wyprowadź tę osobę z pokoju. Czytamy dokumenty, książki na ten temat, istnieje też społeczność, która organizuje fora, spotkania i konferencje. Dokumentacja jest świetna, ale niestety może być niekompletna. Używamy Cosmos DB w wielu projektach. Życzę powodzenia w czytaniu dokumentacji tego produktu. Książki są jedynym ratunkiem, na szczęście istnieją i można je znaleźć, zawierają mnóstwo podstawowej wiedzy i trzeba czytać dużo i stale. Ale problem leży po stronie społeczności.
Teraz trudno znaleźć przynajmniej jedną odpowiednią konferencję czy spotkanie w naszej okolicy. Nie, oczywiście, spotyka się bardzo dużo ze słowem Dane, ale obok tego słowa zwykle pojawiają się dziwne skróty typu ML czy AI. Więc to nie jest dla nas, mówimy o tym, jak budować magazyny, a nie o tym, jak smarować się neuronami. Ci hipsterzy przejęli wszystko. W rezultacie jesteśmy bez wspólnoty. Przy okazji, jeśli jesteś Inżynierem Danych i znasz dobre społeczności, napisz proszę w komentarzach.
Wnioski i ogłoszenie spotkania
Z czym skończymy? Moje pierwsze doświadczenia podpowiadają mi, że wczucie się w rolę inżyniera danych przyda się każdemu programiście. To po prostu pozwala nam spojrzeć na sprawy inaczej i nie zdziwić się, gdy oczy nam się przekrwią, gdy zobaczymy, jak programiści traktują swoje dane. Jeśli więc w Twojej firmie jest DE, po prostu porozmawiaj z tymi facetami, dowiesz się wielu nowych rzeczy (o sobie).
I na koniec ogłoszenie. Ponieważ w ciągu dnia trudno jest znaleźć spotkania na nasz temat, postanowiliśmy zorganizować własne. Dlaczego jesteśmy gorsi? Na szczęście mamy coś niesamowitego i nasi przyjaciele z , którzy podobnie jak my uważają, że inżynierowie danych są niesprawiedliwie pozbawieni uwagi.
Korzystając z okazji, zapraszam wszystkich zainteresowanych na nasze pierwsze spotkanie społecznościowe pod obiecującym tytułem „DE or DIE”, które odbędzie się 27.02.2020 lutego XNUMX r. w biurze Dodo Pizza. Szczegóły pod adresem .
Jeśli coś się stanie, będę tam i możesz mi osobiście powiedzieć w twarz, jak bardzo się mylę co do twórców.
Źródło: www.habr.com