Ścieżka kariery data engineera Jak nie pomylić jej z data science i nie utknąć

Fundamenty wiedzy: bez czego nie ma sensu zaczynać data engineeringu

Pojawia się ogłoszenie: „Junior Data Engineer, wymagany SQL i Python”. Ktoś po kursie Pythona myśli: „To przecież ja”. Pierwszego dnia w pracy okazuje się, że problemem nie jest napisanie pętli, tylko zrozumienie, skąd w ogóle biorą się te dane, czemu raport pokazuje inne liczby niż system operacyjny i dlaczego zmiana jednej tabeli wywala 30 pipeline’ów.

Myślenie systemowe i modelowanie danych

Data engineer patrzy na dane jak na system naczyń połączonych. Zanim napisze pierwszego DAG-a w Airflow, musi wiedzieć:

• Jakie są główne systemy źródłowe (CRM, ERP, aplikacja mobilna, płatności) i jak ze sobą rozmawiają.
• Jakie zdarzenia są kluczowe dla biznesu (rejestracja, zakup, rezygnacja, ticket do supportu).
• Jak wygląda przepływ informacji – od kliknięcia użytkownika po fakturę w księgowości.

Do tego dochodzi klasyka: modelowanie relacyjne. Klucze główne i obce, normalizacja, typy relacji, schemat gwiazdy i płatka śniegu – to nie są akademickie ciekawostki, tylko codzienne narzędzia. Jeśli nie rozumiesz, czym się różni tabela faktów od tabeli wymiarów, prędzej czy później utkniesz na hurtowni pełnej duplikatów i dziwnych joinów.

SQL jako język pracy, nie „skill w CV”

SQL w data engineeringu to nie „SELECT * FROM tabela”, tylko:

• Składanie złożonych transformacji (CTE, okna analityczne, podzapytania) w sposób czytelny i testowalny.
• Rozumienie planów zapytań, indeksów, partitionów, clusterów.
• Pisanie kodu, który działa przewidywalnie na milionach wierszy, a nie tylko na sample z Excela.

Typowa ścieżka: na początku piszesz SQL „byle działało”, potem dochodzisz do momentu, w którym zapytanie idzie 40 minut, a ty musisz zrozumieć, dlaczego. Tam zaczyna się prawdziwa nauka SQL-a dla data engineera.

Podstawy programowania i inżynierii oprogramowania

Nawet jeśli większość logiki piszesz w SQL, bez sensownych podstaw programowania trudno wejść wyżej niż poziom „skryptora”. Potrzebne są:

• Struktury danych i algorytmy na poziomie praktycznym (listy, słowniki, sortowanie, złożoność „z grubsza”).
• Praktyka z Git-em: branchowanie, code review, pull requesty, rozwiązywanie konfliktów.
• Zasady pisania czytelnego kodu: modułowość, DRY, testy jednostkowe/integracyjne.

Data engineer, który nie umie pracować w repozytorium kodu z resztą zespołu, szybko staje się wąskim gardłem. Tu nie chodzi o „ładny kod”, tylko o możliwość utrzymania setek pipeline’ów przez kilka lat.

Relacyjne bazy danych i hurtownie

Nawet jeśli stack jest „chmurowy i nowoczesny”, fundamenty pozostają podobne:

• Różnice między OLTP (systemy transakcyjne) a OLAP (hurtownie, analityka).
• Mechanizmy transakcyjności, izolacji, blokad – przynajmniej na poziomie intuicji.
• Partycjonowanie i klastrowanie tabel, statystyki, cache – jak to przekłada się na wydajność.

Im wcześniej zrozumiesz, że „tabela” w BigQuery czy Snowflake to nie to samo co arkusz w Excelu, tym mniej bólu przy pierwszych dużych rachunkach za chmurę.

Podstawy systemów rozproszonych

Przy mniejszych projektach można przeżyć bez głębokiej wiedzy o systemach rozproszonych, ale już na poziomie mid-senior trzeba ogarniać kilka prostych faktów:

• Sieć jest zawodna i wolna – każde czytanie/zapisywanie w innej usłudze coś kosztuje.
• Stan systemu jest rozproszony – stąd opóźnienia, eventual consistency, dziwne „glitche” w danych.
• Granice systemów (API, kolejki, eventy) są miejscem, gdzie najczęściej pęka integracja.

Bez takiego „mindsetu rozproszonego” łatwo projektować rozwiązania, które wyglądają rozsądnie na diagramie, a potem rozjeżdżają się pod obciążeniem albo przy pierwszej awarii jednego z serwisów.

Komunikacja z biznesem i analitykami

Data engineer, który chowa się za JIRA-ą i Slackiem, szybko staje się „tym, co coś tam robi z danymi, ale nikt nie wie co”. Tymczasem praca wygląda często tak:

• Analityk mówi: „Potrzebuję raportu retencji”.
• Ty dopytujesz: „Jak definiujemy aktywnego użytkownika? Po logowaniu? Po użyciu kluczowej funkcji?”.
• Potem razem ustalacie definicję, która będzie spójna w całej firmie.

Ten etap „dogadywania definicji” bywa ciekawszy niż samo klepanie SQL-a. I często decyduje o tym, czy dane będą użyteczne, czy staną się kolejnym raportem, któremu nikt nie wierzy.

Narzędzia i technologie data engineera: co jest „must”, a co „nice to have”

Rekrutujesz się na pierwszą rolę data engineeringową, a w ogłoszeniu lista: Airflow, Kafka, dbt, Spark, Snowflake, Terraform, Docker, Kubernetes, trzy chmury i jeszcze „mile widziane doświadczenie z ML”. Łatwo pomylić roadmapę z katalogiem marzeń działu HR. Lepiej rozdzielić: co musisz naprawdę umieć, a czego możesz nauczyć się „po drodze”.

Absolutne podstawy stacku data engineera

Na większości stanowisk nie uciekniesz od kilku filarów.

SQL i relacyjna baza / hurtownia

To już było przy fundamentach, ale w praktyce oznacza to znajomość choć jednego konkretnego dialektu:

• PostgreSQL / MySQL – w wielu firmach jako system źródłowy.
• BigQuery / Snowflake / Redshift / Azure Synapse – w roli hurtowni danych.

Nie chodzi o „znałem kiedyś SELECT-a”, tylko o realne doświadczenie: zbudowałeś kilkanaście sensownych zapytań, zoptymalizowałeś kilka z nich, wiesz jak śledzić execution plan.

Python lub inny język do integracji

Python dominuje, ale w niektórych ekipach używa się też Scali, Javy czy nawet Go. Python jest jednak najbardziej uniwersalny:

• Łączenie się z API, pobieranie plików, przetwarzanie danych przed wrzuceniem do hurtowni.
• Skrypty narzędziowe: migracje, jednorazowe joby, wsparcie dla analityków.
• Testy integracyjne pipeline’ów (np. z Pytestem).

Na start nie trzeba znać całego ekosystemu, ale bezpiecznie jest czuć się swobodnie w pisaniu małych, czystych skryptów, pracy z wirtualnym środowiskiem i dependency managementem.

System kontroli wersji: Git

Bez Gita nie ma współczesnego data engineeringu. Typowe sytuacje:

• Review DAG-ów Airflow czy modeli dbt przez kolegów z zespołu.
• Rollback zmian, które zepsuły produkcję.
• Eksperymentowanie z nową architekturą w osobnym branchu.

Na poziomie juniora wystarczą: commit, push, pull, branch, pull request i proste konflikty. Na dalszych etapach przydają się strategie branchingowe, rebase, cherry-pick i cała kultura pracy z repozytorium.

Narzędzia orkiestracji i schedulingu

Kiedy pipeline’ów robi się więcej niż kilka, ręczne odpalanie skryptów przestaje mieć sens. Tu pojawiają się narzędzia orkiestracji.

Airflow i spółka

Airflow stał się de facto standardem, choć rosną alternatywy (Prefect, Dagster). Ważna jest nie tyle znajomość konkretnego narzędzia, co zrozumienie koncepcji:

• Definiowanie DAG-ów (zależności między zadaniami, retry, SLA).
• Rozdzielenie logiki transformacji od orkiestracji.
• Monitoring jobów: logi, alerty, metryki czasu wykonania.

W praktyce, jeśli nauczysz się solidnie jednego silnika orkiestracji, przejście na inny jest głównie kwestią syntaksu i kilku różnic projektowych.

Hurtownie danych, lakehouse, data lakes

Współczesny data engineer rzadko działa tylko na jednej bazie. Częściej ma do czynienia z mieszanką:

• Hurtowni (BigQuery, Snowflake, Redshift, Synapse).
• Data lake (S3, GCS, ADLS) z formatami Parquet/ORC i warstwami bronze/silver/gold.
• Rozwiązań lakehouse (Databricks, BigQuery z external tables, Delta Lake, Iceberg).

„Must have” to rozumienie, gdzie i po co trzymamy surowe dane, gdzie dane przetworzone, a gdzie „gotowe do czytania” przez analityków. Konkretne platformy zmieniają się co kilka lat, ale koncepcje pozostają podobne.

Przetwarzanie wsadowe i rozproszone

Przy większej skali pojawia się Spark lub podobne narzędzie. Nie każdy data engineer spędza z nim większość dnia, ale dobrze jest:

• Umieć napisać prosty job w Spark SQL/DataFrame API.
• Rozumieć różnicę między przetwarzaniem in-memory a spill to disk, shuffle, partitioningiem.
• Wiedzieć, jak debugować podstawowe problemy wydajności.

Jeśli projekt nie wymaga Big Data, bardziej przyda się solidny SQL w hurtowni chmurowej niż Spark „na siłę”. To dobry przykład „nice to have”, który robi się „must have” dopiero przy odpowiedniej skali.

ELT, dbt i warstwy modelowania

W stackach analitycznych szybko pojawia się dbt lub podobne rozwiązania. To narzędzie, które uczy myślenia o SQL-u jak o kodzie aplikacji:

• Modułowe modele, dziedziczenie, ref-y zamiast twardych nazw tabel.
• Testy danych (unikalność kluczy, not null, relacje między tabelami).
• Dokumentacja generowana automatycznie, lineage, wersjonowanie.

Na wczesnym etapie kariery wystarczy umieć pisać czytelne modele SQL i proste testy. Z czasem dochodzi architektura całego „model layer” i ustalanie standardów w zespole.

Monitoring, jakość danych i observability

Data engineer bez narzędzi do obserwowania stanu danych działa na ślepo. Różne firmy używają różnych rozwiązań, ale kluczowe jest kilka elementów:

• Monitorowanie pipeline’ów: czy się wykonały, jak długo trwały, czy rośnie czas wykonania.
• Monitoring jakości danych: zakresy wartości, null-e, duże odchylenia dzień do dnia.
• Alertowanie: kiedy wysłać maila/Slacka, kiedy blokować dalsze przetwarzanie.

Część zespołów używa dedykowanych narzędzi (Great Expectations, dbt tests, Monte Carlo, Bigeye), inne budują własne mechanizmy. Niezależnie od stacku, „instynkt do stawiania czujek” na krytycznych tabelach szybko odróżnia juniora od kogoś, kto przeszedł choć jedną większą awarię.

Chmura: AWS, GCP, Azure – jak głęboko schodzić

Większość projektów data engineeringowych działa dziś w chmurze. Na poziomie data engineera zwykle wystarcza:

• Rozumienie podstawowych usług: storage (S3/GCS/Blob), compute (EC2/GCE), managed databases.
• Praca z konsolą, IAM-ami, rolami serwisowymi, sekretami.
• Udział w projektowaniu architektury danych razem z cloud inżynierami.

Głębokie wejście w temat (Terraform, sieci VPC, Kubernetes na produkcji) to raczej „nice to have” i osobna ścieżka w stronę platform / cloud inżyniera. Dla wielu data engineerów wystarcza porządna znajomość usług danych i współpraca z zespołem platformowym.

Co naprawdę odróżnia mocnego data engineera od „osoby od ETL-i”

Dwóch ludzi może znać ten sam zestaw narzędzi, a ich efekty pracy będą zupełnie inne. Różnica często tkwi nie w kolejnej technologii, tylko w sposobie podejścia:

• Pierwszy zawsze zaczyna od zrozumienia procesu biznesowego i źródeł danych, dopiero potem wybiera narzędzia.
• Drugi zaczyna od narzędzia („tu zrobimy Sparka, tu Kafkę, tu dbt”), a dopiero potem próbuje do tego dopasować rzeczywistość.

Sprzęt, chmura i frameworki będą się zmieniać. Świadomość, jak dane powstają, jak przez nie płynie biznes i co musi zadziałać codziennie o 6:00 rano, żeby zarząd dostał sensowny raport – to zostanie i to najbardziej buduje długoterminową ścieżkę kariery data engineera zamiast przypadkowej roli „od pipeline’ów”.

Jak się rozwijać, żeby nie utknąć w roli „od rur”

Przychodzisz rano do pracy, wszystko się świeci na zielono, pipeline’y chodzą, alertów brak. Z jednej strony ulga, z drugiej – czujesz, że od pół roku robisz w kółko te same rzeczy: kolejny import, kolejna poprawka schematu, kolejny hotfix. To dobry moment, żeby świadomie zaplanować, w którą stronę chcesz pójść jako data engineer – zanim ktoś na stałe przypnie ci łatkę „tego od ETL-i”.

Rozwój poziomy vs pionowy: szerzej czy głębiej

Ścieżkę można rozrysować na dwie podstawowe osie. Po pierwsze, głębokość techniczna: od osoby, która „zna narzędzia”, do tej, która projektuje architekturę danych i rozwiązuje najtrudniejsze problemy wydajnościowe. Po drugie, szerokość biznesowa: od kogoś, kto realizuje ticket, do partnera dla product ownerów i stakeholderów.

W praktyce wygląda to mniej więcej tak:

• Rozwój w głąb: coraz lepsze rozumienie jednej dziedziny – np. Spark i rozproszone przetwarzanie, streaming, architektury lakehouse, optymalizacja kosztów w chmurze.
• Rozwój wszerz: znajomość całego łańcucha – od eventów w aplikacji, przez pipeline’y, po dashboardy i decyzje zarządu.

Osoby, które nie chcą utknąć, zwykle łączą oba kierunki: mają „swoje” mocne techniczne podwórko, ale potrafią też wyjść poza własne repozytorium i porozmawiać o tym, po co w ogóle te dane są zbierane.

Typowe „pułapki kariery” data engineera

Najłatwiej utknąć w miejscach, gdzie rola jest skrojona bardzo wąsko. Scenariusz powtarza się w wielu firmach:

• Jesteś przypięty do jednego systemu źródłowego („ten człowiek od CRM-a”) i nikt nie chce cię wypuścić, bo „działa, więc nie ruszajmy”.
• Jesteś jedyną osobą od Airflow i kończysz jako pełnoetatowy „admin DAG-ów” zamiast inżyniera danych.
• Twoja praca to głównie gaszenie pożarów i ręczne poprawki danych, bo nikt nie ma czasu na porządne rozwiązania systemowe.

Wyjście zwykle nie polega na czekaniu na cud, tylko na umówieniu się z przełożonym, że w kolejnym kwartale bierzesz na siebie 1–2 zadania wykraczające poza bieżące „utrzymanie”: redesign kawałka architektury, proof-of-concept nowego narzędzia, automatyzację najbardziej upierdliwego ręcznego procesu.

Od „ticket factory” do partnera dla biznesu

Punkt zwrotny przychodzi często wtedy, kiedy zamiast ślepo robić taski, zaczynasz zadawać pytania: „Po co to robimy?”, „Kto będzie z tego korzystał?”, „Jaka decyzja zależy od tej tabeli?”. To moment, w którym przestajesz być podwykonawcą, a zaczynasz wyglądać jak ktoś, z kim opłaca się rozmawiać na etapie planowania.

Przykład z codzienności: product manager prosi cię o nową tabelę z metrykami funkcji, którą dopiero chce wypuścić. Zamiast tylko dopytać o schemat, możesz:

• Pomóc zaplanować eventy po stronie aplikacji, żeby były spójne z istniejącym trackingiem.
• Ustalić, których metryk nie da się policzyć bez zmian w logice biznesowej.
• Zaproponować, jak zorganizować warstwy danych (surowe, agregaty, widoki dla analityków), żeby uniknąć duplikacji logiki.

Takie rozmowy wymagają, żebyś był na bieżąco z tym, czym żyje produkt i dział analityki. Często wystarczy raz w tygodniu wpaść na ich status, poczytać kilka ticketów, których nie realizujesz, i pogadać z analitykiem, co mu realnie przeszkadza w pracy.

Data engineer a ścieżka w stronę architektury danych

Jeśli ciągnie cię do „większego obrazka”, naturalnym kierunkiem bywa rola architekta danych czy „senior data engineer / tech lead” z elementami architektury. Różnica nie polega na tym, że nagle przestajesz pisać kod, tylko że coraz częściej decydujesz, jaki kod w ogóle powstanie.

Na tym etapie:

• Projektujesz standardy: naming, warstwy danych, strategię partycjonowania, zasady retencji.
• Decydujesz, kiedy kupić gotowy produkt (np. narzędzie do jakości danych), a kiedy napisać coś własnego.
• Analizujesz koszty: jak zmiana architektury wpłynie na rachunek za chmurę i czas pracy zespołu.

Do takiej roli przybliża cię każda sytuacja, w której zamiast „łatamy dziurę”, projektujesz zmianę przyczyny problemu. Zamiast dorzucić kolejny job naprawczy, zastanawiasz się, jak zbudować schemat, kontrolę jakości i kontrakt danych tak, żeby ta klasa błędu w ogóle się nie pojawiała.

Ścieżka menedżerska: lider zespołu data engineering

Nie wszyscy chcą iść w głąb technologii. Część osób po kilku latach pracy stwierdza, że bardziej kręci ich organizowanie pracy zespołu, rozwój ludzi i rozmowy z biznesem niż debugowanie kolejnego joba w Sparku o 2 w nocy.

Lider zespołu data engineering zwykle:

• Spędza mniej czasu w edytorze kodu, a więcej w kalendarzu i na Slacku.
• Ustala priorytety między „nowymi featurami danych” a „porządkami technicznymi”, których nikt poza zespołem nie widzi.
• Pomaga data engineerom rozwijać się – i technicznie, i biznesowo – przez code review, pair programming, wspólne rozkminy architektoniczne.

Jeśli ciągle łapiesz się na tym, że bardziej interesuje cię, jak zespół pracuje (procesy, komunikacja, priorytety), niż pojedynczy ticket, może to być kierunek dla ciebie. Dobrze jest wtedy i tak zachować kontakt z kodem – choćby przez okresowe przejmowanie trudniejszych zadań czy udział w design review.

Gdzie kończy się data engineering, a zaczyna data platform

W wielu firmach wyodrębnia się dziś osobne zespoły „data platform” albo „analytics platform”. To ekipy, które nie robią konkretnych pipeline’ów pod potrzeby działu marketingu czy produktu, tylko budują samą platformę: standardy, tooling, szablony, CI/CD, zarządzanie uprawnieniami, obciążeniem i kosztami.

Przykładowe zadania takiej roli:

• Przygotowanie boilerplate’u pod nowy projekt danych: repozytorium, pipeline, monitoring, standardowe testy.
• Budowanie bibliotek wewnętrznych, które upraszczają typowe operacje (np. ujednolicony klient do pobierania danych z zewnętrznych API).
• Współpraca z zespołem infrastruktury / cloud, żeby data engineer nie musiał ręcznie ogarniać sieci, kubeclustera i Terraformów.

Ta ścieżka przyciąga ludzi, którzy lubią automatyzować i ujednolicać – zamiast pisać dziesiąty podobny pipeline, wolą zbudować framework, który przyspieszy pracę całej organizacji.

Data engineering a praca blisko machine learningu

Jest też kierunek „w stronę ML”, który bywa szczególnie kuszący dla osób, które pierwotnie myślały o data science. Główna różnica polega na tym, że zamiast samemu trenować modele, budujesz fundamenty pod nie: featury, feature store, pipeline’y uczenia i odświeżania, monitoring predykcji.

W praktyce może to oznaczać:

• Projektowanie schematów danych pod potrzeby modeli (stabilne ID, wersjonowane featury, spójność definicji między treningiem a inferencją).
• Budowę pipeline’ów, które łączą dane transakcyjne, eventowe i zewnętrzne w jedną strukturę zasilającą modele.
• Współpracę z ML engineerami przy wdrażaniu modeli na produkcję i monitorowaniu ich jakości oraz driftu danych.

Nie wymaga to od razu znajomości najnowszych architektur sieci neuronowych. Znacznie ważniejsze jest porządne ogarnięcie wersjonowania danych, powtarzalności eksperymentów i odporności pipeline’ów na zmiany w źródłach.

Jak nie pomylić ścieżki data engineering z data science

Kiedy rekrutujesz się na „data cośtam”, ogłoszenia potrafią wyglądać jak miks trzech różnych ról. W jednym akapicie: budowanie modeli ML, w drugim: projektowanie hurtowni, w trzecim: tworzenie dashboardów dla zarządu. Jeśli na początku kariery nie złapiesz różnicy, możesz obudzić się po dwóch latach w pracy, która w ogóle nie przypomina tego, co sobie wyobrażałeś.

Jak czytać ogłoszenia, żeby odróżnić role

Najprostsze narzędzie to filtr na słowa kluczowe i proporcje zadań. Kilka sygnałów z ogłoszeń:

• Data engineer: dużo o pipeline’ach, przetwarzaniu danych, chmurze, narzędziach typu Airflow, dbt, Spark, Kafka, hurtowniach i lake’ach. Mało albo wcale o trenowaniu modeli, sporo o integracjach i jakości danych.
• Data scientist: nacisk na modelowanie statystyczne, eksperymenty A/B, regresje, klasyfikacje, znajomość bibliotek ML (scikit-learn, TensorFlow, PyTorch), analizy ad hoc. O pipeline’ach pojawia się góra jeden akapit.
• Analityk danych / BI: dominują dashboardy (Tableau, Power BI, Looker), SQL, praca z biznesem, przygotowywanie raportów i insightów. Technologie przetwarzania rozproszonego są „mile widziane”, ale nie kluczowe.

Dobry test przy rozmowie rekrutacyjnej: poproś o przykładowy tydzień pracy dla tej roli. Jeśli przy „data engineerze” słyszysz głównie o budowaniu modeli albo eksperymentach produktowych, to jest to raczej data scientist z elementami inżynierii niż klasyczny inżynier danych.

Kiedy data engineer „zrobi trochę data science” – i czy to źle

W mniejszych firmach granice są naturalnie rozmyte. Możesz mieć tytuł data engineera, a realnie:

• Przygotowywać dane, a przy okazji analizować je razem z produktem i marketingiem.
• Budować proste modele scoringowe w scikit-learn, bo jeszcze nikogo od ML nie zatrudniono.
• Tworzyć dashboardy, bo analitycy są przeciążeni.

Samo w sobie to nie jest problem – pod warunkiem, że wiesz, co jest twoim głównym kierunkiem rozwoju. Jeśli chcesz być data engineerem, pilnuj, żeby trzonem twojej pracy było projektowanie i budowa systemów danych, a nie tylko pojedyncze analizy. Jeśli marzysz o data science, dopilnuj, żebyś regularnie miał czas na modelowanie, eksperymenty i pogłębianie wiedzy statystycznej, zamiast kończyć przy CI/CD dla DAG-ów.

Sygnalizowanie swojej ścieżki w projektach i CV

O tym, jaką rolę rynek w tobie „zobaczy”, często decyduje to, jak opisujesz swoje projekty. Dwie osoby mogły robić podobne rzeczy, a w CV jedna wygląda jak data scientist, druga jak data engineer.

Jeśli celujesz w data engineering, w opisach projektów podkreślaj:

• Skalę i charakter danych: przybliżone wolumeny, częstotliwość, rodzaj źródeł.
• Architekturę: jakie narzędzia, w jakich rolach, jakie warstwy danych zaprojektowałeś.
• Aspekty niezawodności i jakości: testy, monitoring, SLA, odporność na błędy.

Jeśli bardziej interesuje cię data science, na pierwszy plan wysuń:

• Rodzaj problemu (np. klasyfikacja churnu, rekomendacje, prognozowanie popytu).
• Metody i modele: jakich technik używałeś, jak oceniałeś jakość, jak prowadziłeś eksperymenty.
• Wpływ biznesowy: co się zmieniło dzięki modelowi (nawet jakościowo, bez dokładnych liczb).

Te akcenty sprawiają, że rekruter od razu wie, do którego „koszyka” cię przypisać, zamiast traktować cię jako kolejną „osobę od danych do wszystkiego”.

Czy można zacząć od data engineeringu i przejść do data science (i odwrotnie)

Zmiana kierunku jest możliwa, ale wymaga świadomego planu. Z inżynierii danych do data science masz już sporą przewagę: rozumiesz, jak powstają dane, jakie mają ograniczenia, gdzie są pułapki jakości. Brakuje ci głównie solidnych podstaw statystycznych, metod modelowania i doświadczenia w prowadzeniu eksperymentów.

Praktyczna ścieżka przejścia z data engineeringu w stronę data science może wyglądać tak:

• Zacznij od prostych analiz i eksploracji danych w swoim projekcie, we współpracy z analitykiem lub data scientistą.
• Weź na siebie 1–2 małe projekty z prostymi modelami (np. scoring leadów, segmentacja klientów) i poprowadź je od pomysłu do wdrożenia.
• Uzupełnij teorię: statystyka, wnioskowanie, metody uczenia maszynowego – kursy, książki, praca „po godzinach” na prawdziwych datasetach.

W drugą stronę – z data science do engineeringu – wyzwaniem bywa porzucenie komfortu notatnika Jupyter i wejście w „world of pain” systemów produkcyjnych: deploy, monitoring, uprawnienia, błędy o trzeciej nad ranem. Tu dużo daje udział w projektach, gdzie data scientist sam odpowiada za wdrożenie modelu albo bliska współpraca z data engineerami przy budowie pipeline’ów pod własne modele.

Świadome budowanie portfolio data engineera