Analytics Engineer: modele, testy i utrzymanie danych

Analytics Engineer zajmuje się tym, żeby przygotowane dane nadawały się do wielokrotnego użycia. Kiedy kilka raportów korzysta z zamówień, ktoś musi zadbać o wspólne definicje, poprawne połączenia, testy i sposób wprowadzania zmian. Właśnie ten fragment pracy chcę tutaj pokazać. Najłatwiej zrozumieć go na przykładzie modelu, za który trzeba odpowiadać również po pierwszym uruchomieniu.

W ogłoszeniach spotkasz nazwę Analytics Engineer i Data Analytics Engineer. Patrzę przede wszystkim na obowiązki. Jedna firma połączy je z analizą i dashboardami, inna wydzieli osobny zespół. Granice między analitykiem, inżynierem danych i osobą rozwijającą modele zależą od organizacji. Sama nazwa stanowiska nie mówi jeszcze, jak będzie wyglądał zwykły wtorek.

Co jest rezultatem pracy Analytics Engineera

Dobrym rezultatem jest zbiór danych, który inna osoba potrafi znaleźć, zrozumieć i wykorzystać w określonym celu. Ma opisany poziom szczegółowości, reguły jakości oraz właściciela. Wiadomo, skąd pochodzi, jak często się odświeża i jakie ma ograniczenia. Kod transformacji stanowi część tego rozwiązania, obok dokumentacji i sposobu utrzymania.

dbt Labs opisuje analytics engineering przez transformowanie, testowanie, wdrażanie i dokumentowanie danych oraz praktyki takie jak kontrola wersji. To użyteczny opis obszaru pracy, choć pochodzi od dostawcy narzędzia i nie ustanawia jednolitej granicy wszystkich stanowisk. Zobacz wyjaśnienie roli w dbt Labs.

Nie zakładam, że Analytics Engineer nigdy nie buduje hurtowni albo dashboardu. W małym zespole jedna osoba może realizować kilka takich zadań. W większym ważniejsze staje się uzgodnienie odpowiedzialności między zespołami. Osoba odpowiedzialna za pobieranie danych również potrzebuje kontekstu biznesowego, a analityk może pisać solidne testy i utrzymywać modele.

Żeby rozpoznać tę pracę, pytam, kto odpowiada za wspólną tabelę zamówień, kto zatwierdza zmianę definicji i kto reaguje na opóźnione dane. Odpowiedzi pokazują realny zakres lepiej niż długa lista technologii. Jeśli chcesz porównać sąsiednie obowiązki, zajrzyj też do tekstu o analityku danych, analityku biznesowym i BI Developerze.

Przykład: wspólny model zamówień

Wyobraźmy sobie syntetyczny projekt sklepu. Zespół sprzedaży chce liczyć zamówienia według kraju, marketing analizuje kanały pozyskania, a obsługa klienta sprawdza zwroty. Każdy dotąd sam łączył eksport zamówień z klientami. Powstawały różne filtry statusów i różne sposoby traktowania brakujących danych. Projekt ma przygotować uzgodniony model wejściowy do tych analiz.

Zaczynam od pytania, które elementy naprawdę są wspólne. Identyfikator zamówienia i data utworzenia mogą trafić do podstawowego modelu. Przypisanie kanału marketingowego wymaga osobnej reguły, a zwrot może być oddzielnym zdarzeniem z własną datą. Wspólna tabela nie musi od razu zawierać każdej miary, jaką ktokolwiek zechce kiedyś pokazać na wykresie.

Ustalmy jeden wiersz na zamówienie oraz osobny model pozycji. To pozwala uniknąć sumowania kwoty zamówienia po dołączeniu kilku produktów. Kraj klienta wymaga decyzji: bieżący czy historyczny z chwili zakupu? Oba warianty mogą być potrzebne, ale powinny mieć czytelnie różne nazwy. Nie zostawiam tego wyboru przypadkowemu JOIN-owi w kolejnym raporcie.

Ten opis jest projektem ćwiczeniowym, a nie relacją z wdrożenia. Nie mierzyłem tu przyspieszenia systemu ani oszczędności firmy. Chodzi o prześledzenie decyzji, które można następnie sprawdzić we własnym środowisku. Dzięki temu łatwiej odróżnić sensowną praktykę projektową od obietnicy, że samo narzędzie automatycznie uporządkuje dane.

Zacznij od umowy o znaczeniu danych

Przed kodowaniem zapisuję, co oznacza wiersz, które rekordy należą do zakresu i kto korzysta z wyniku. W modelu zamówień potrzebuję klucza, reguły statusów, jednostki kwoty oraz sposobu obsługi braków. Jeżeli zamówienie bez klienta ma pozostać widoczne, zapisuję to wprost. Taka decyzja musi przeżyć zmianę osoby piszącej zapytanie.

Rozdzielam też status bieżący od historii zdarzeń. Jeżeli źródło nadpisuje status zamówienia, późniejszy eksport może zmienić odpowiedź za poprzedni miesiąc. Nie da się odtworzyć pełnej historii samą sprytną nazwą kolumny. Trzeba mieć odpowiednie dane źródłowe albo świadomie zaakceptować, że raport pokazuje stan znany w momencie odświeżenia.

Dobry opis ogranicza również użycie modelu. Tabela zamówień ze sklepu może wspierać analizę operacyjną, ale nie musi wystarczać do raportowania finansowego. Brak zwrotów czy podatków to istotna informacja dla odbiorcy. Wolę ją umieścić przy modelu, zanim ktoś nada sumie kwot nazwę sugerującą szersze znaczenie.

Do takiej umowy wracam podczas przeglądu zmian. Jeśli nowe wymaganie zmienia ziarno danych, nie traktuję go jak drobnej korekty kolumny. Użytkownicy mogą mieć już własne połączenia i liczniki oparte na wcześniejszym założeniu. Warto wskazać im skutek zmiany, sposób przejścia i okres dostępności poprzedniej wersji.

Podziel transformacje według odpowiedzialności

W naszym projekcie warstwa blisko źródła porządkuje nazwy, typy i oczywiste konwencje. Kolejny etap łączy dane zgodnie z uzgodnionymi kluczami. Model udostępniany odbiorcom ma już określone ziarno oraz opis. Ten podział pomaga ustalić, gdzie naprawić problem, bez przeszukiwania kilkunastu raportów wykonujących tę samą operację.

Nie tworzę osobnego modelu dla każdej linijki SQL. Rozdzielenie powinno pomagać w rozumieniu lub ponownym użyciu logiki. Jeżeli dwa etapy zawsze zmieniają się razem i nie mają niezależnego znaczenia, dodatkowa warstwa może tylko utrudniać czytanie. Nazwy plików powinny odpowiadać temu, co model robi, zamiast wymagać poznania prywatnych skrótów autora.

Zależności są ważne również przy zmianie źródła. Gdy znika kolumna kraju, chcę wiedzieć, jakie modele i raporty od niej zależą. W dbt deklarowane źródła i odwołania pozwalają opisać te powiązania; szczegóły znajdziesz w dokumentacji źródeł. Sam wykres zależności nadal wymaga sensownych nazw i aktualnych opisów.

Jeśli dopiero uczysz się łączenia tabel, najpierw przećwicz mały zbiór. W artykule o SQL od pytania do sprawdzonego wyniku pokazuję, jak połączenie z pozycjami zamówienia zmienia sumę. Narzędzie do zarządzania modelami nie usuwa tego problemu. Trzeba rozumieć, co dzieje się z każdym rekordem.

Dobieraj testy do możliwej pomyłki

W modelu zamówień sprawdzam unikalność klucza oraz jego kompletność. Kontroluję dozwolone statusy i relację z klientami, uwzględniając świadomie dopuszczone wyjątki. Zapisuję też test konkretnej reguły biznesowej, jeżeli podstawowe kontrole jej nie obejmują. Każdy test powinien odpowiadać na pytanie, jaki błąd wykryje i co oznacza jego porażka.

dbt udostępnia testy danych między innymi dla unikalności, braków, dozwolonych wartości i powiązań. Testy mogą wskazywać rekordy naruszające założenie. To mechanizm opisany w dokumentacji data tests. Nie oznacza on, że komplet zielonych wyników potwierdza wszystkie możliwe własności modelu. Sprawdziliśmy wyłącznie reguły, które zapisaliśmy i uruchomiliśmy.

Przykładowy scenariusz kontrolny zawiera dwa zamówienia tego samego klienta, zamówienie bez klienta oraz zamówienie z brakującą kwotą. Osobno dokładam duplikat klucza. Zanim wykonam transformację, zapisuję oczekiwany rezultat i oczekiwany błąd. Dzięki temu test nie sprowadza się do potwierdzenia, że kod zwrócił cokolwiek i nie przerwał działania.

Ustalam też reakcję. Duplikat klucza w modelu o ziarnie zamówienia może blokować publikację. Niewielka liczba dopuszczonych braków może wymagać informacji dla odbiorcy i osobnego zgłoszenia. Progi muszą wynikać z zastosowania danych. Kopiowanie ich z innego projektu bez rozmowy z użytkownikiem łatwo produkuje alarmy, których nikt nie rozumie.

Kontrakt techniczny ma określony zakres

Opis biznesowy modelu jest szerszy niż mechanizm kontraktu w konkretnym narzędziu. Kontrakt dbt może kontrolować kształt modelu, w tym nazwy kolumn i typy. Obsługa oraz egzekwowanie ograniczeń zależą od platformy i sposobu materializacji. Sprawdź opis ograniczeń w dbt dla własnego środowiska.

Kolumna z poprawnym typem liczbowym może nadal zawierać kwotę w niewłaściwej jednostce. Poprawna data może oznaczać datę płatności, choć odbiorca spodziewał się daty zamówienia. Dlatego obok kontroli schematu potrzebne są definicje i przykłady. Nazwanie mechanizmu kontraktem nie sprawia, że narzędzie rozumie intencję każdego użytkownika.

Zwracam szczególną uwagę na klucze. Sam zapis deklaracji nie zawsze oznacza, że silnik odrzuci duplikat. Trzeba sprawdzić zachowanie używanej bazy i konfiguracji. Jeżeli unikalność jest założeniem potrzebnym do bezpiecznego JOIN-a, chcę mieć kontrolę, która faktycznie wykryje jej naruszenie w naszym procesie.

Świeżość i kompletność to osobne pytania

Załóżmy, że raport ma wspierać poranne spotkanie. Uzgadniam, kiedy dane powinny być dostępne, jakiego okresu dotyczą i kto zauważy opóźnienie. Sam zielony status wykonania transformacji nie wystarcza. Model mógł poprawnie przeliczyć wczorajszy niepełny eksport, ponieważ nowsze dane jeszcze nie dotarły ze źródła.

Niedawny znacznik załadowania również nie dowodzi kompletności. Jedna nowa paczka może być świeża, a drugi region nadal nieprzesłany. Dlatego oprócz czasu sprawdzam oczekiwane części dostawy i uzgodnione liczniki. Mechanizm progów świeżości opisuje dokumentacja freshness; konfigurację i polecenia dobierz do wersji dbt używanej w projekcie.

Alert powinien podawać model, problem, zakres wpływu i osobę lub zespół odpowiedzialny za reakcję. Informacja o niedostępnych danych z konkretnego źródła jest bardziej pomocna niż kilkanaście identycznych powiadomień z raportów zależnych. Do tego potrzebna jest instrukcja: kiedy ponowić proces, kiedy zatrzymać publikację i jak poinformować odbiorców o niepełnym wyniku.

Przegląd i wdrożenie są częścią pracy

Zmianę modelu przygotowuję w osobnej gałęzi repozytorium. W opisie pokazuję problem, wynik po zmianie oraz sposób sprawdzenia. Recenzent powinien móc prześledzić logikę bez odtwarzania całej rozmowy projektowej. Przykład jednego zamówienia przed i po zmianie bywa bardziej użyteczny niż długa lista nazw poprawionych plików.

Przed publikacją sprawdzam wpływ na zależne raporty. Zmiana nazwy kolumny może od razu przerwać odświeżanie. Zmiana znaczenia przy tej samej nazwie jest trudniejsza do zauważenia, bo wykres nadal się wyświetla. W obu przypadkach trzeba zaplanować przejście użytkowników i sprawdzić, czy wynik odpowiada nowej uzgodnionej definicji.

Cofnięcie commita nie zawsze cofa dane, które zostały już przeliczone lub nadpisane. Plan powrotu powinien uwzględniać sposób odbudowania poprzedniego wyniku i dostępność źródeł. W ćwiczeniu możesz przećwiczyć to na lokalnej kopii. W realnym środowisku procedura zależy od narzędzi, uprawnień i odpowiedzialności zespołu za udostępniany zbiór.

Wydajność oceniaj razem z kosztem utrzymania

Gdy model działa wolno, zaczynam od pomiaru i planu wykonania w konkretnej platformie. Sprawdzam, ile danych czyta, gdzie mnożą się wiersze i czy ten sam kosztowny etap jest wykonywany wielokrotnie. Nie obiecuję przyspieszenia z kilkudziesięciu minut do sekund bez wykonania porównania na rzeczywistym zakresie.

Widok, tabela i model przyrostowy mają różne konsekwencje. Zapisany wynik może przyspieszyć odczyt, ale potrzebuje odświeżania. Przetwarzanie przyrostowe musi uwzględniać poprawki historyczne, spóźnione rekordy i usunięcia. Jeżeli uwzględniasz tylko nowe identyfikatory, zmieniony status starego zamówienia może nigdy nie dotrzeć do wyniku. Najpierw zaprojektuj regułę aktualizacji, potem oceniaj oszczędność pracy silnika.

Koszt to także czas ludzi. Model, którego nikt poza autorem nie rozumie, bywa drogi w utrzymaniu mimo szybkiego wykonania. Dokumentacja, stabilne nazwy i małe przeglądalne zmiany pomagają ograniczyć ten problem. Rozwiązanie powinno pasować do potrzeb zespołu i częstotliwości użycia, zamiast realizować największą możliwą architekturę dla pojedynczego raportu.

Dokumentacja zaczyna się od pytań odbiorcy

Przy modelu zamówień opisuję najpierw zastosowanie i ziarno, a dopiero potem poszczególne kolumny. Czytelnik powinien wiedzieć, czy może bezpiecznie policzyć wiersze i z czym może połączyć tabelę. Dodaję przykład oczekiwanego połączenia oraz ostrzeżenie o znanej relacji jeden do wielu. To pomaga osobie, która zna SQL, ale nie zna jeszcze naszego systemu sprzedaży ani wszystkich wyjątków w jego danych.

Opis kolumny powinien wyjaśniać więcej niż jej nazwa. Przy dacie wskazuję zdarzenie i strefę czasową. Przy kwocie jednostkę oraz zakres składników. Przy statusie regułę interpretacji i źródło wartości. Jeśli coś pozostaje nierozstrzygnięte, zapisuję ograniczenie i kontakt do właściciela definicji. Nie zastępuję takiej informacji słowem standardowy, bo dla dwóch zespołów standard może oznaczać zupełnie różne zachowanie systemu.

Przyda się także przykład pytania, którego model nie obsłuży. Jeżeli przechowujemy bieżący kraj klienta, dokumentacja powinna jasno wykluczać odtwarzanie jego historii na tej podstawie. Taka uwaga ogranicza ryzyko późniejszego, pozornie poprawnego raportu. W praktyce pomaga też ustalić kolejne wymaganie: czy potrzebujemy nowego źródła, osobnego modelu historycznego, czy jedynie zmiany opisu istniejącej analizy i sposobu jej używania.

Dokumentację przeglądam razem z kodem, kiedy zmienia się znaczenie danych. Osobny plik aktualizowany kilka tygodni później szybko traci wartość. W ćwiczeniu sprawdź to prosto: przekaż komuś sam opis i mały wynik, bez ustnego wprowadzenia. Poproś o interpretację brakującej kwoty oraz nieznanego kraju. Jeżeli odpowiedź odbiega od twoich założeń, masz konkretny fragment do poprawienia przed udostępnieniem modelu szerszej grupie.

Jak sprawdzić, czy ten kierunek ci odpowiada

Zacznij od projektu, który już potrafisz policzyć w SQL. Wyodrębnij model zamówień, opisz jego ziarno i zapisz oczekiwane zachowanie kilku wyjątków. Dodaj kontrolę wersji, testy oraz instrukcję uruchomienia. Poproś kogoś, żeby na podstawie dokumentacji odpowiedział na własne pytanie. Miejsca, w których potrzebuje dodatkowych wyjaśnień, pokazują kolejne zadania do wykonania.

Następnie zasymuluj zmianę. Dodaj nowy status, brakującą relację albo spóźnioną poprawkę starego rekordu. Sprawdź, czy kontrola wykrywa problem i czy potrafisz wyjaśnić jego wpływ na raport. Taki projekt pokazuje myślenie o utrzymaniu lepiej niż sam zrzut ekranu z działającym harmonogramem. W portfolio opisz również ograniczenia ćwiczenia i rzeczywiście wykonane testy.

Przy czytaniu ogłoszenia szukaj konkretów: kto utrzymuje integracje, jakie modele są rozwijane, kto reaguje na awarie i ile pracy dotyczy analiz. Zapytaj o przeglądy kodu, dostępne środowisko testowe oraz właścicieli definicji biznesowych. Lista narzędzi pomoże dobrać naukę, lecz te odpowiedzi powiedzą więcej o codziennym sposobie pracy i oczekiwanej samodzielności.

Ten kierunek może odpowiadać osobie, która lubi porządkować powtarzalne rozwiązania, sprawdzać założenia i ułatwiać pracę innym analitykom. Nie ma obowiązku przechodzenia przez tak nazwane stanowisko ani gwarancji zatrudnienia po poznaniu jednego narzędzia. Najlepszym kolejnym krokiem będzie mały utrzymywany model, którego znaczenie potrafisz jasno obronić przed drugim człowiekiem.

Materiał wideo

W filmie omawiam obszary pracy Data Analytics Engineera. Do własnego ćwiczenia wykorzystaj opisany wyżej projekt modelu i pytania o odpowiedzialność, jakość oraz utrzymanie danych.