Nowa pozycja w świecie danych – Analytics Engineer

Wpis zawiera sekcje:

• Dlaczego analityk danych tworzy tabele?
• O co chodzi z pozycją Analytics Engineer?
• Kim jest Analytics Engineer?
• ETL czy ELT?
• Jak wygląda praca Analytics Engineera?
• dbt

Dlaczego analityk danych tworzy tabele?

Kiedy pracowałam jako analityk danych częstym zadaniem w mojej pracy było zrobienie tabeli w bazie danych. Pamiętam, że gdy opowiadałam o tym znajomym, to w kółko słyszałam to samo pytanie: „Ale dlaczego robisz tabele w pracy, czy to nie jest zadanie dla inżyniera danych (data engineer)? Zaczynałam wtedy tłumaczenie, że chodzi o trochę inny typ tabel, bardziej tabele analityczne, nie produkcyjne, że te informacje już są w DB, ale w nieprzystępnej formie i że inżynierzy nie są w stanie stworzyć takiej tabeli jaką ja potrzebuję.

Aby zobrazować o czym piszę posłużmy się przykładem.

Załóżmy, że często zestawiamy ze sobą dwie kolumny znajdujące się w dwóch różnych tabelach, do których połączenia musimy użyć jeszcze dodatkowo tabele pośrednie:

SELECT a.col1
     , d.col2
FROM tabel_a AS a
JOIN tabel_b AS b ON b.id = a.b_id
JOIN tabel_c AS c ON c.id = b.c_id
JOIN tabel_d AS d ON d.id = c.d_id

Aby wyciągnąć te 2 kolumny za każdym razem musielibyśmy robić 4 JOINy. Trochę utrudnia nam to pracę, ale załóżmy, że sytuacja jeszcze nie jest tragiczna, gorzej byłoby, gdyby dochodziły do tego bardziej skomplikowane obliczenia, które też musielibyśmy powtarzać. Dlatego załóżmy, że pracujemy w firmie, który ma dział obsługi klienta i bardzo ważną metryką w całej firmie jest mierzenie jak szybko odpisujemy na maile. Informacje o mailach są przechowywane w tzw. tabeli eventowej, która przechowuje każdą aktywność na poziomie emaila:

Obliczenie ile czasu zajmuje odpowiedzenie na maila wymaga napisania 3 osobnych CTE (jeżeli nie wiesz co to jest CTE to zapraszam do tego posta):

WITH email_start AS (
SELECT id
     , min(timestamp) AS started_at
FROM emails
)
, email_response AS (
SELECT id
     , min(timestamp) AS responded_at
FROM emails
WHERE event_type = 'responded'
)
SELECT es.id
     , er.responded_at - es.started_at AS first_response_time
FROM email_start AS es
JOIN email_response AS er ON es.id = er.id

Musisz mi uwierzyć na słowo, że gdybyśmy musieli policzyć taką metrykę w prawdziwej pracy, to na tych 3 prostych CTE by się nie skończyło. Nagle by się okazało, że w tej tabeli są też maile z kampanii marketingowych, które to my wysyłamy klientom, dlatego trzeba je wyeliminować, a w dodatku odpowiedzi (WHERE event_type = 'responded') nie zawierają tylko odpowiedzi pracowników, ale też automatyczne odpowiedzi, które także należy wykluczyć. Logika obliczeń by się rozrosła i pewnie by zajęła kilka kolejnych CTE. Wiem o czym piszę, bo wybrałam praktycznie przypadek nad którym sama musiałam pracować w jednej firmie i wiem na jak długim kodzie się skończyło.

Wracając do tego, że czas odpowiedzi jest bardzo istotną metryką w firmie, powyższa query będzie używana w wielu różnych miejscach w tym w licznych dashboardoach, wewnętrznych programach do mierzenia KPI itd. Czy jest sens, aby powielać powyższy kod i pisać ją w każdym z tych miejsc od nowa? Oczywiście, że nie. Powielanie kodu jest bardzo złą praktyką, prowadzi do błędów i trudności w wprowadzaniu zmian. Logika liczenia, w szczególności tak ważnej metryki, powinna być w jednym miejscu, dobrze przetestowana i pod ciągłym nadzorem analityków. Żeby to uzyskać dochodzimy w końcu do momentu, w którym warto byłoby utworzyć nową tabelę zawierającą całą logikę obliczeń w SQL za pomocą komendy CREATE TABLE, która będzie gromadziła informacje o czasie odpowiedzi na każdy mail:

Każda kolejna osoba potrzebująca informacje o czasie odpowiedzi może po prostu wyciągnąć tą informacje z powyższej tabeli, nie musi powielać całego kodu SQL od nowa.

O co chodzi z pozycją Analytics Engineer?

Bardzo długi wstęp, ale przechodzimy do meritum. Odpowiedzmy sobie na pytanie – czy utworzenie powyższej tabeli to rola inżyniera danych? Raczej nie, ponieważ najtrudniejszą częścią powyższego zadania nie jest wrzucenie danych do tabeli, ale wymyślenie i dogadanie z ludźmi biznesu definicji czasu odpowiedzi, przeanalizowanie przypadków brzegowych czy zaprojektowanie takiej postaci tabeli, z której łatwo wyciąga się dane. Czy jest to zatem zadanie dla analityka danych? Przy tworzeniu tabeli dochodzi wiele aspektów takich jak: Jak stworzyć tę tabelę? Jak ją odświeżać? Jak często ją odświeżać? Jak ją zoptymalizować, aby szybko wyciągać z niej potrzebne informacje? Co jeżeli dane w tabelach źródłowych się zmieniają? Czy przy odświeżaniu tabeli liczyć wartości dla wszystkich maili od początku, czy tylko dodawać wiersze dla nowych maili? Jak widzimy dochodzimy do zagadnień technicznych, które niekoniecznie są umiejętnościami potrzebnymi typowej pracy analityka danych.

I tutaj właśnie naturalnie z potrzeb biznesowych wyłania się nowa pozycja w świecie danych: Analytics Engineer – połączenie analityka danych i data engineera. 

Kim jest Analytics Engineer?

Inżynierowie danych mają głównie za zadanie wrzucanie danych do bazy i zazwyczaj mają gdzieś, czy te dane później można w prosty sposób wyciągnąć do wszelkich analiz. Rolą analityka za to jest wyciąganie danych z bazy i ich analiza. Gdzieś pomiędzy tymi dwoma pozycjami powstała luka, którą nie mógł wypełnić ani inżynier danych, ani analityk. Brakowało osoby, która połączy te dwa światy i przerobi dane w taki sposób, aby były one łatwo dostępne do analizy. 

ETL czy ELT?

Powstanie stanowiska Analytics Engineer łączy się także z kolejnym zagadnieniem. Pewnie obił wam się o uszy termin ETL, czyli 3-częściowy proces wyodrębniania danych, ich przekształcania i ładowania (Extract – Transform – Load), którego celem jest posiadanie wszystkich danych w jednym wiarygodnym źródle. Ale czy kroki opisujące ten proces odzwierciedlają rzeczywistą pracę w firmach? Okazuje się, że nie do końca, ponieważ dość często proces Transform i Load odbywają się w odwrotnej kolejności niż wskazuje na to ten słynny skrót – najpierw inżynierowie ładują dane do bazy danych (Load), a dopiero później kolejne osoby przetwarzają je w sposób, aby można było łatwo je wykorzystać (Transform). Okazuje się zatem, że proces wykonywany w wielu firmach to nie ETL, a ELT: Extract – Load – Transform.

Zmiana z ETL na ELT łączy się z wykorzystywaniem w biznesie tzw. analitycznych baz danych, które są zoptymalizowane do szybkiego wyciągania z nich danych w celu analizy (w odróżnieniu od operacyjnych baz danych, dla których ważna jest modyfikacja wartości rekordów). Bazy danych tego typu, np. Snowflake czy Exasol, charakteryzują się niskim kosztem składowania danych, przez co można tworzyć tabele na pęczki i organizować dane tak, aby finalne wyciąganie z nich informacji było banalnie proste.

Jak wygląda praca Analytics Engineera?

Jeżeli czujesz się dobrze w zadaniach pomiędzy DA a DE, to ta pozycja jest dla Ciebie 🙂

Czym się charakteryzuje ta rola:

• Zajmujesz się przede wszystkim modelowaniem danych i budowaniem pipeline’ów danych.
• W porównaniu do DA nie jesteś „na froncie”, czyli w ciągłym kontakcie z ludźmi biznesu. Nie musisz tworzyć końcowego produktu w postaci dashboardów czy analiz. Przez to naturalnie mniej istotna jest twoja umiejętność komunikacji z ludźmi nietechnicznymi.
• Pozycja jest bardziej techniczna, a zadania bardziej deterministyczne niż DA. Wymagana jest większa znajomość z zakresu tworzenia tabel i ich optymalizacji, większy nacisk jest kładziony na dobre praktyki programistyczne jak praca z kontrolą wersji, testowanie czy praktyki CI/CD.
• W porównaniu do DE nie musisz się aż tak znać na infrastrukturze baz danych, raczej twoją rolą nie jest wrzucanie danych do DB, utrzymywanie dostępów czy zapewnienie bezpieczeństwa.
• Musisz mieć lepsze myślenie analityczne niż typowy DE. Rozumieć czego potrzebują analitycy, z jakimi problemami się mierzą na codzień i jak wyciągają dane. Mimo iż nie zajmujesz się samą analizą danych, to musisz rozumieć na czym polega jej proces.

dbt

Jednym z programów używanych przez Analytics Engineer jest dbt, czyli narzędzie do łatwej transformacji danych w obrębie jednej bazy, które umożliwia właśnie tworzenie tabel, pipeline’ów i modeli danych. Podstawowa obsługa dbt jest prosta do nauki, działa głównie na kodzie SQL i plikach do konfiguracji YAML, w dodatku dbt umożliwia kontrolę wersji, automatyzację, testowanie, czy automatyczne tworzenie dokumentacji. Zapoznam zaznajomić się z darmowymi kursami dbt, które wprowadzają do używania tego narzędzia, przede wszystkim dbt Fundamentals, który podobnie jak ten post wprowadza do świata Analytics Engineer.

Podsumowanie

• Analytics engineer to nowa rola, która wypełniła naturalną lukę między inżynierem a analitykiem danych.
• Powstanie pozycji Analytics Engineer łączy się z zamianą kroków z ETL na ELT oraz wykorzystywaniem analitycznych baz danych.
• Jednym z narzędzi pracy Analytics Engineer jest program dbt.

keywords: analytics engineer, analytics engineer kto to, kim jest analytics engineer, czym się zajmuje analytics engineer, analityk danych a inżynier danych, analytics engineer jak zacząć, analytics engineer jak zaczac, jak zostać analytics engineer, jak zostac analytics engineer, analytics engineer programy, analytics engineer co trzeba umieć, analytics engineer co trzeba umiec, dbt, etl, elt, etl co to, etl skrót, etl skrot, etl skrót, etl co to znaczy, analityk danych, analityk biznesowy, inżynier danych, data engineer.