25 najczęściej zadawanych pytań na rozmowie z Data Engineeringu w 2026

Pytania rekrutacyjne z data engineeringu w 2026 roku wykraczają daleko poza podstawy SQL. Zespoły rekrutacyjne sprawdzają obecnie projektowanie systemów, architektury czasu rzeczywistego, optymalizację kosztów oraz gotowość do pracy z AI. Niniejszy przewodnik obejmuje 25 pytań, które najczęściej pojawiają się na rozmowach kwalifikacyjnych na stanowisko data engineer w firmach od startupów po FAANG, wraz z odpowiedziami napisanymi z myślą o praktykach.

SQL i optymalizacja zapytań

SQL pozostaje fundamentem każdej rozmowy kwalifikacyjnej z data engineeringu. Nawet starsi kandydaci mierzą się z pytaniami SQL, zazwyczaj skupionymi na wydajności, a nie na składni.

1. Jaka jest różnica między funkcją okna (window function) a GROUP BY?

GROUP BY redukuje wiersze do zagregowanych wyników, zmniejszając liczbę wierszy. Funkcje okna obliczają wartości na zbiorze wierszy powiązanych z bieżącym wierszem bez ich zwijania. Wynik zachowuje każdy oryginalny wiersz.

-- GROUP BY: jeden wiersz na dział
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: każdy wiersz zachowany, średnia dodana
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Wersja z funkcją okna jest niezbędna, gdy zapytanie wymaga jednocześnie szczegółów na poziomie wiersza i kontekstu agregacji - jest to powszechne wymaganie w procesach kontroli jakości danych i pipeline'ach raportowych.

2. Jak zoptymalizować wolne zapytanie na tabeli faktów z 500 milionami wierszy?

Najlepiej sprawdza się ustrukturyzowane podejście:

1. Sprawdzenie planu wykonania (EXPLAIN ANALYZE) w celu identyfikacji pełnych skanów tabeli, złączeń hash na nieindeksowanych kolumnach lub zrzutów na dysk.
2. Partycjonowanie tabeli według daty lub innej kolumny o wysokiej kardynalności, która odpowiada filtrom zapytań.
3. Dodanie ukierunkowanych indeksów na często filtrowanych kolumnach, ale unikanie nadmiernego indeksowania (każdy indeks zwiększa narzut operacji zapisu).
4. Materializacja wyników pośrednich, jeśli to samo podzapytanie jest uruchamiane wielokrotnie w różnych dashboardach.
5. Przesunięcie predykatów w dół w celu wczesnego filtrowania, co zmniejsza ilość danych przesyłanych między etapami.

Kluczowy sygnał, którego szukają rekruterzy: zrozumienie, że optymalizacja jest iteracyjna i zależna od kontekstu, a nie jest listą kontrolną.

3. Wyjaśnij CTE, podzapytania i tabele tymczasowe. Kiedy stosować każde z nich?

CTE (Common Table Expressions) poprawiają czytelność i umożliwiają zapytania rekurencyjne. Większość silników zapytań inline'uje je, więc wydajność odpowiada podzapytaniom. Tabele tymczasowe fizycznie materializują dane, co pomaga, gdy ten sam wynik pośredni zasila wiele zapytań downstream w sesji. Podzapytania sprawdzają się w prostych, jednorazowych transformacjach.

Zasada: CTE dla czytelności, tabela tymczasowa do wielokrotnego użycia, podzapytanie dla trywialnych filtrów inline.

Więcej o zaawansowanych wzorcach SQL w artykule SQL dla analityków danych: Window Functions, CTE i zaawansowane zapytania.

ETL vs ELT i architektura pipeline'ów danych

Pytania o projektowanie pipeline'ów testują myślenie architektoniczne. Rekruterzy chcą zobaczyć analizę kompromisów, a nie promowanie konkretnych narzędzi.

4. ETL vs ELT: kiedy wybrać jedno, a kiedy drugie?

| Kryterium | ETL | ELT | |-----------|-----|-----| | Miejsce transformacji | Przed załadowaniem (zewnętrzne obliczenia) | Po załadowaniu (obliczenia w hurtowni) | | Najlepsze dla | Starsze systemy, ścisłe schematy | Hurtownie chmurowe (BigQuery, Snowflake) | | Elastyczność schematu | Niska (transformacja blokuje schemat wcześnie) | Wysoka (surowe dane dostępne do retransformacji) | | Model kosztowy | Obliczenia poza hurtownią | Koszty obliczeń hurtowni rosną z transformacjami | | Świeżość danych | Wyższe opóźnienie (krok transformacji) | Niższe opóźnienie (najpierw załaduj, transformuj na żądanie) |

ELT dominuje we współczesnych stosach cloud-native, ponieważ magazynowanie jest tanie, moc obliczeniowa skaluje się elastycznie, a zachowanie surowych danych umożliwia ewolucję schematu. ETL pozostaje istotne, gdy wymagania regulacyjne nakazują transformację danych przed wejściem do hurtowni (na przykład usuwanie danych osobowych).

5. Zaprojektuj idempotentny pipeline danych. Dlaczego idempotentność ma znaczenie?

Idempotentność gwarantuje, że wielokrotne uruchomienie pipeline'u z tymi samymi danymi wejściowymi daje ten sam wynik bez duplikowania danych. Ma to znaczenie, ponieważ pipeline'y ulegają awariom i są ponawiane.

Strategie implementacji:

• Wzorce upsert (MERGE lub INSERT ... ON CONFLICT) oparte na kluczach naturalnych lub złożonych
• Nadpisywanie partycji: zastąpienie całych partycji dziennych zamiast dodawania
• Deduplikacja przy zapisie: przypisywanie deterministycznych identyfikatorów (hash klucza biznesowego + znacznik czasu zdarzenia)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

To podejście zapewnia, że ponowne uruchomienie zadania z 11 kwietnia zastąpi partycję z 11 kwietnia, zamiast dodawać zduplikowane wiersze.

6. Czym jest lineage danych i dlaczego jest krytyczny w pipeline'ach produkcyjnych?

Lineage danych śledzi pochodzenie, przepływ i transformację danych w pipeline'ie. Odpowiada na pytania: skąd pochodzi ta liczba, jakie transformacje zostały zastosowane i jakie systemy downstream od niej zależą.

Praktyczna wartość: gdy dashboard pokazuje nieoczekiwane wartości, lineage umożliwia analizę przyczyn źródłowych w minuty zamiast godzin. Narzędzia takie jak OpenLineage, dbt docs i natywny lineage chmurowy (lineage na poziomie kolumn w BigQuery) automatyzują ten proces.

Przetwarzanie strumieniowe i danych w czasie rzeczywistym

Pytania o streaming przesunęły się od "czym jest Kafka" do decyzji architektonicznych o tym, kiedy i jak stosować przetwarzanie strumieniowe.

7. Batch vs streaming: jak podjąć decyzję?

Decyzja zależy od wymagań dotyczących opóźnień, a nie preferencji technologicznych:

• Batch: akceptowalne, gdy konsumenci danych tolerują opóźnienia rzędu minut do godzin. Prostsze w budowie, testowaniu i debugowaniu. Niższy koszt operacyjny dla większości obciążeń.
• Streaming: wymagane, gdy logika biznesowa zależy od świeżości poniżej minuty: wykrywanie oszustw, wycena w czasie rzeczywistym, dashboardy na żywo.
• Micro-batch: pragmatyczny kompromis (na przykład Spark Structured Streaming), zapewniający przetwarzanie zbliżone do czasu rzeczywistego z prostotą batch.

Najlepsza odpowiedź uwzględnia fakt, że większość pipeline'ów powinna zaczynać jako batch i przechodzić na streaming tylko wtedy, gdy konkretne SLA dotyczące opóźnień tego wymaga.

8. Wyjaśnij architekturę Kafki: tematy, partycje, grupy konsumentów

Kafka organizuje dane w tematy (kanały logiczne). Każdy temat dzieli się na partycje (uporządkowane, niezmienne logi) rozproszone między brokerami. Producenci zapisują rekordy do partycji (round-robin lub na podstawie klucza). Grupy konsumentów równoległościują odczyty: każda partycja jest przypisana dokładnie jednemu konsumentowi w grupie, co umożliwia skalowanie horyzontalne.

Kluczowy kompromis: więcej partycji zwiększa równoległość, ale dodaje narzut brokerowi (uchwyty plików, replikacja). Typowy punkt startowy to 6-12 partycji na temat, skalowanych w zależności od wymagań przepustowości.

9. Jak obsługiwać dane przychodzące z opóźnieniem w pipeline'ie strumieniowym?

Opóźnione dane są nieuniknione w systemach rozproszonych. Trzy podejścia:

1. Znaki wodne (watermarks): definiowanie progu (np. 10 minut), po którym spóźnione dane są odrzucane. Apache Flink i Spark Structured Streaming wspierają to natywnie.
2. Okna ponownego przetwarzania: okresowe ponowne uruchamianie agregacji dla ostatnich okien czasowych w celu przechwycenia spóźnionych danych.
3. Ujścia typu delta/upsert: zapis do mutowalnego magazynu (Delta Lake, Apache Iceberg), który obsługuje aktualizacje, pozwalając spóźnionym rekordom korygować poprzednie wyniki.

Właściwe podejście zależy od tego, czy konsumenci downstream potrzebują semantyki exactly-once, czy tolerują eventual consistency.

Modelowanie danych i projektowanie schematów

Pytania o modelowanie danych ujawniają, czy kandydat myśli o tym, jak dane będą konsumowane, a nie tylko jak są przechowywane.

10. Schemat gwiazdy vs schemat płatka śniegu: kompromisy?

Schemat gwiazdy denormalizuje tabele wymiarów do płaskich, szerokich tabel połączonych z centralną tabelą faktów. Schemat płatka śniegu normalizuje wymiary do podwymiarów.

| Aspekt | Gwiazda | Płatek śniegu | |--------|---------|---------------| | Wydajność zapytań | Szybsza (mniej złączeń) | Wolniejsza (więcej złączeń) | | Magazynowanie | Wyższe (nadmiarowe dane) | Niższe (znormalizowane) | | Złożoność | Prosta do zrozumienia | Bardziej złożone relacje | | Utrzymanie | Trudniejsza aktualizacja wymiarów | Łatwiejsza aktualizacja podwymiarów | | Najlepsza dla | BI/raportowanie (dużo odczytów) | Sytuacje wymagające ścisłej normalizacji |

W praktyce schematy gwiazdy dominują w hurtowniach analitycznych (BigQuery, Snowflake, Redshift), ponieważ wydajność zapytań i prostota przeważają nad oszczędnościami na magazynowaniu. Więcej w module modelowania danych.

11. Czym jest wymiar wolnozmienialny (SCD)? Wyjaśnij Typ 1, 2 i 3.

Wymiary wolnozmienialny (SCD - Slowly Changing Dimension) śledzą, jak atrybuty wymiarów zmieniają się w czasie:

• Typ 1: Nadpisanie starej wartości. Brak historii. Proste, ale z utratą danych.
• Typ 2: Dodanie nowego wiersza ze śledzeniem wersji (valid_from, valid_to, is_current). Pełna historia zachowana. Najczęściej stosowany w produkcyjnych hurtowniach.
• Typ 3: Dodanie kolumny dla poprzedniej wartości (current_city, previous_city). Ograniczona historia (tylko jedna zmiana śledzona).

Typ 2 jest domyślnym wyborem dla większości wymiarów biznesowych (adres klienta, kategoria produktu, dział pracownika), ponieważ ścieżki audytu i raportowanie historyczne tego wymagają.

12. Jak zamodelować dane zdarzeń zarówno dla analityki czasu rzeczywistego, jak i długoterminowego przechowywania?

Podejście dwuwarstwowe:

1. Warstwa gorąca: strumieniowanie zdarzeń do magazynu czasu rzeczywistego (Apache Druid, ClickHouse lub Materialized Views w hurtowni) zoptymalizowanego pod kątem agregacji o niskim opóźnieniu na najnowszych danych.
2. Warstwa zimna: lądowanie surowych zdarzeń w lakehouse (Delta Lake, Iceberg) partycjonowanym według daty, przechowywanym bezterminowo do analiz ad-hoc i inżynierii cech ML.

Warstwa gorąca wykorzystuje wstępnie zagregowane lub zdenormalizowane schematy dla szybkości. Warstwa zimna zachowuje pełną granularność. Zadanie uzgadniające okresowo sprawdza, czy obie warstwy się zgadzają.

Apache Spark i przetwarzanie rozproszone

Pytania o Spark skupiają się na zrozumieniu równoległości i wydajności, a nie tylko na wywołaniach API.

13. Co powoduje nierównomierność danych (data skew) w Spark i jak to naprawić?

Nierównomierność danych występuje, gdy jedna partycja zawiera nieproporcjonalnie więcej danych niż inne, powodując, że pojedyncze zadanie staje się wąskim gardłem całego etapu.

Najczęstsze przyczyny: złączenie na kluczu z kilkoma dominującymi wartościami (klucze null, pojedynczy popularny identyfikator produktu) lub partycjonowanie według kolumny o niskiej kardynalności.

Rozwiązania:

• Solenie (salting): dodanie losowego sufiksu do skośnego klucza, złączenie na solonym kluczu, następnie agregacja w celu usunięcia soli.
• Broadcast join: jeśli jedna strona jest wystarczająco mała (<200MB typowo), rozgłoszenie jej w celu uniknięcia shuffle.
• AQE (Adaptive Query Execution): Spark 3.x+ potrafi automatycznie wykrywać i dzielić skośne partycje w czasie wykonywania.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

To podejście równomiernie rozdziela obciążenie między executory, eliminując wąskie gardło.

14. Wyjaśnij różnicę między transformacjami a akcjami w Spark.

Transformacje (map, filter, select, join) są leniwe: budują plan logiczny, ale nic nie wykonują. Akcje (count, collect, write) uruchamiają faktyczne obliczenia, przesyłając plan do klastra.

Ta leniwa ewaluacja umożliwia optymalizatorowi Catalyst w Spark zmianę kolejności operacji, przesuwanie predykatów w dół i eliminację niepotrzebnych operacji shuffle przed jakimkolwiek przesłaniem danych. Zrozumienie tego rozróżnienia jest kluczowe dla debugowania: transformacja, która wydaje się wolna, w rzeczywistości jest w porządku - wąskim gardłem jest akcja, która ją uruchamia.

15. Jaka jest różnica między repartition() a coalesce()?

repartition(n) wykonuje pełny shuffle w celu utworzenia dokładnie n partycji, równomiernie dystrybuując dane. Stosuje się go do zwiększenia równoległości lub zrównoważenia skośnych partycji.

coalesce(n) redukuje partycje bez shuffle poprzez scalanie sąsiednich partycji. Stosuje się go do zmniejszenia liczby partycji przed zapisem (unikanie wielu małych plików).

Zasada: coalesce do zmniejszania, repartition do zwiększania lub równoważenia.

Orkiestracja i zarządzanie pipeline'ami

Pytania o orkiestrację testują dojrzałość operacyjną: jak pipeline'y działają, ulegają awariom i odzyskują się w produkcji.

16. Porównaj Airflow, Dagster i Prefect. Kiedy wybrać każde z nich?

| Cecha | Airflow | Dagster | Prefect | |-------|---------|---------|--------| | Dojrzałość | Najbardziej dojrzały, największa społeczność | Rosnący, silny w zespołach ML/data | Cloud-first, silny DX | | Główna abstrakcja | DAGi zadań | Assety (zorientowane na dane) | Przepływy i zadania | | Testowanie | Trudniejsze (na poziomie DAG) | Wbudowane testowanie assetów | Dobre testowanie na poziomie zadań | | Lokalne dev | Wymaga Docker/kontenerów | Natywne lokalne wykonanie | Natywne lokalne wykonanie | | Najlepszy dla | Złożone, długotrwałe ETL | Data mesh / zespoły zorientowane na assety | Zespoły chcące minimalnej infrastruktury |

Airflow pozostaje standardem branżowym dla dojrzałych platform danych. Dagster pasuje do zespołów, które myślą w kategoriach assetów danych, a nie sekwencji zadań. Prefect przemawia do zespołów, które chcą orkiestracji w stylu Airflow z mniejszym narzutem operacyjnym. Przygotowanie do pytań o Airflow jest dostępne w module podstaw Airflow.

17. Jak obsługiwać awarie pipeline'ów i alerty w produkcji?

Produkcyjna strategia obsługi awarii obejmuje:

1. Ponowienia z backoffem: przejściowe awarie (timeouty sieciowe, limity szybkości API) rozwiązują się przy wykładniczych ponowieniach.
2. Kolejki martwych wiadomości (dead-letter queues): trujące wiadomości trafiają do oddzielnej kolejki do ręcznej inspekcji bez blokowania pipeline'u.
3. Bezpieczniki (circuit breakers): po N kolejnych awariach pipeline jest wstrzymywany i generowany jest alert, zamiast zalewania systemów downstream złymi danymi.
4. Obserwowalność: ustrukturyzowane logi, metryki (czas trwania zadań, liczba wierszy, wskaźniki błędów) i kontrole jakości danych (Great Expectations, testy dbt) na każdym etapie pipeline'u.
5. Poziomy alertów: P1 (pipeline nie działa, brak danych) powiadamia dyżurnego. P2 (dryf jakości danych) wysyła powiadomienie na Slack do obsługi w następnym dniu roboczym.

18. Co sprawia, że pipeline jest "gotowy do produkcji" w porównaniu z prototypem?

Gotowość produkcyjna oznacza: idempotentne uruchomienia, automatyczne ponowienia, monitoring i alerty, walidację danych na etapach ingestion i transformacji, dokumentację kontraktów danych, wersjonowane definicje pipeline'ów oraz przetestowaną ścieżkę rollback. Prototyp nie ma żadnej z tych rzeczy. Różnica między nimi to miejsce, w którym gromadzi się większość długu technicznego pipeline'ów.

Platformy chmurowe i architektura lakehouse

Pytania o platformy chmurowe sprawdzają, czy kandydaci rozumieją kompromisy dotyczące kosztów, skali i architektury wykraczające poza składnię konkretnego dostawcy.

19. Czym jest lakehouse i dlaczego stał się dominującą architekturą?

Lakehouse łączy elastyczność data lake (schema-on-read, przechowywanie surowych danych, różne formaty plików) z niezawodnością hurtowni danych (transakcje ACID, wymuszanie schematu, optymalizacja zapytań). Technologie takie jak Delta Lake, Apache Iceberg i Apache Hudi umożliwiają to, dodając warstwę metadanych/transakcji na obiektowyemu magazynowi (S3, GCS, ADLS).

Lakehouse wygrywa, ponieważ eliminuje kosztowną warstwę ETL między jeziorem a hurtownią, obsługuje zarówno zapytania BI, jak i obciążenia ML na tych samych danych oraz wykorzystuje tanie obiektowe magazynowanie.

20. Jak optymalizować koszty hurtowni chmurowej (BigQuery, Snowflake, Redshift)?

Strategie optymalizacji kosztów:

• Partycjonowanie i klastrowanie tabel w celu zmniejszenia liczby skanowanych bajtów na zapytanie
• Ustawianie odpowiednich rozmiarów warehouse (Snowflake) lub rezerwacji slotów (BigQuery) w zależności od wzorców obciążenia
• Automatyczne zawieszanie nieaktywnych zasobów: warehouse'y Snowflake powinny się automatycznie zawieszać po 1-5 minutach bezczynności
• Monitorowanie kosztów poszczególnych zapytań: widok INFORMATION_SCHEMA.JOBS w BigQuery ujawnia kosztowne zapytania
• Stosowanie widoków zmaterializowanych dla powtarzalnie obliczanych agregacji
• Archiwizacja zimnych danych do tańszych warstw magazynowania z politykami cyklu życia

Sygnał na rozmowie: kandydaci, którzy traktują koszty jako pierwszoplanowe ograniczenie inżynieryjne, a nie dodatek.

Jakość danych i governance

Pytania o jakość danych oddzielają inżynierów, którzy dostarczają pipeline'y, od tych, którzy utrzymują zaufane platformy danych.

21. Jak wdrożyć kontrole jakości danych w pipeline'ie?

Kontrole jakości danych należą na trzech etapach:

1. Ingestion: walidacja zgodności schematu, sprawdzanie kluczy głównych na wartości null, weryfikacja progów liczby wierszy względem źródła.
2. Transformacja: asercje reguł biznesowych (np. przychód > 0, daty w prawidłowym zakresie), sprawdzanie integralności referencyjnej między tabelami.
3. Serwowanie: monitorowanie dryfu metryk (nagły spadek dziennych aktywnych użytkowników o 50% prawdopodobnie wskazuje na problem z pipeline'em, a nie zmianę biznesową).

Narzędzia: testy dbt (schematu i niestandardowe), Great Expectations, Soda Core, Monte Carlo (obserwowalność danych). Najlepsze podejście integruje kontrole bezpośrednio w DAG pipeline'u, tak aby awarie blokowały przetwarzanie downstream.

22. Czym jest kontrakt danych i jak zapobiega awariom pipeline'ów?

Kontrakt danych to formalna umowa między producentem danych a jego konsumentami, określająca: schemat (nazwy kolumn, typy, dopuszczalność null), SLA świeżości (dane dostępne do 6:00 UTC), oczekiwania wolumenowe (między 1M a 10M wierszy dziennie) oraz reguły semantyczne (pole status zawiera tylko ACTIVE, INACTIVE, SUSPENDED).

Gdy producenci zmieniają schemat bez aktualizacji kontraktu, automatyczna walidacja wykrywa niezgodność, zanim się ona rozprzestrzeni dalej. To przesuwa awarie pipeline'ów z cichego uszkodzenia danych na jawne, możliwe do obsłużenia błędy.

Projektowanie systemów i architektura

Rundy projektowania systemów są standardem dla stanowisk data engineering na poziomie mid i senior. Testują myślenie end-to-end.

23. Zaprojektuj pipeline analityki czasu rzeczywistego dla platformy e-commerce.

Solidny projekt obejmuje:

Ingestion: zdarzenia clickstream i zdarzenia transakcyjne trafiają do tematów Kafka, partycjonowanych według user_id dla gwarancji kolejności w ramach sesji użytkownika.

Przetwarzanie: zadanie Flink lub Spark Structured Streaming konsumuje z Kafki, wzbogaca zdarzenia danymi katalogu produktów (broadcast join z tabeli wymiarów), oblicza agregacje na poziomie sesji i 5-minutowe.

Serwowanie: zagregowane metryki trafiają do magazynu OLAP czasu rzeczywistego (ClickHouse lub Apache Druid) dla zapytań dashboardowych z opóźnieniem poniżej sekundy. Surowe zdarzenia lądują w Delta Lake/Iceberg do analizy historycznej.

Jakość danych: rejestr schematów (Confluent lub AWS Glue) waliduje schematy zdarzeń przy ingestion. Kontrole jakości danych strumieniowych sygnalizują anomalie (nagły spadek wolumenu zdarzeń) i przekierowują do tematu martwych wiadomości.

Obsługa awarii: offsety konsumentów Kafki umożliwiają przetwarzanie exactly-once z checkpointingiem. Zadanie strumieniowe automatycznie restartuje się z ostatniego checkpointu w przypadku awarii.

24. Jak przeprowadzić migrację starszego pipeline'u ETL do nowoczesnego stosu?

Migracja przebiega według wzorca strangler fig:

1. Audyt: katalogowanie wszystkich istniejących pipeline'ów, ich źródeł, transformacji i konsumentów. Identyfikacja zależności i SLA.
2. Równoległe uruchomienie: budowa nowego pipeline'u obok starego. Oba konsumują te same źródła i zapisują do oddzielnych celów.
3. Walidacja: porównanie wyników między starym i nowym pipeline'em. Automatyczne zapytania uzgadniające sygnalizują rozbieżności.
4. Przełączenie: gdy wyniki zgadzają się w granicach tolerancji przez ponad 2 tygodnie, przełączenie konsumentów na nowy cel. Zachowanie starego pipeline'u w trybie tylko do odczytu dla rollbacku.
5. Wycofanie: po okresie stabilności wyłączenie starszego pipeline'u.

Kluczowy wniosek: nigdy nie przeprowadzać migracji typu big-bang. Oba systemy działają równolegle do momentu uzyskania pewności.

25. Krytyczny dashboard pokazuje nieprawidłowe liczby. Opisz proces debugowania.

Systematyczne podejście:

1. Określenie zakresu problemu: które metryki są błędne? Od kiedy? Wszystkie wymiary czy konkretne filtry?
2. Sprawdzenie warstwy serwowania: bezpośrednie zapytanie hurtowni w celu potwierdzenia, czy problem jest w narzędziu dashboardowym (cache, logika filtrów) czy w samych danych.
3. Śledzenie lineage upstream: podążanie za danymi od tabeli dashboardu wstecz przez każdy krok transformacji. Sprawdzanie liczby wierszy i kluczowych metryk na każdym etapie.
4. Identyfikacja punktu awarii: etap, w którym oczekiwane wartości rozbiegają się z rzeczywistymi, jest lokalizacją przyczyny źródłowej.
5. Sprawdzenie typowych winowajców: zmiany schematu w systemach źródłowych, nieudane uruchomienia pipeline'u, które pozostały bez alertu, opóźnione dane, które nie zdążyły na okno przetwarzania, lub wdrożenie, które zmieniło logikę transformacji.
6. Naprawa i zapobieganie: łatanie natychmiastowego problemu, dodanie kontroli jakości danych, która by go wykryła, oraz aktualizacja runbooka.

To pytanie testuje dojrzałość w reagowaniu na incydenty. Rekruterzy chcą zobaczyć ustrukturyzowane myślenie, a nie losowe zgadywanie.

Przygotowanie do rozmowy kwalifikacyjnej z data engineeringu

Ścieżka przygotowań do rozmowy z data engineeringu na SharpSkill obejmuje te tematy z interaktywną praktyką obejmującą wzorce ETL/ELT, modelowanie danych, Airflow, BigQuery i inne.

Podsumowanie

• Funkcje okna SQL, CTE i optymalizacja zapytań pozostają fundamentalne niezależnie od poziomu doświadczenia
• Decyzje ETL vs ELT powinny być podejmowane na podstawie wymagań dotyczących opóźnień, potrzeb governance danych i kosztów infrastruktury, a nie podążania za trendami
• Idempotentność, kontrakty danych i kontrole jakości danych oddzielają pipeline'y klasy produkcyjnej od prototypów
• Pytania o architekturę strumieniową skupiają się na kompromisach (batch vs streaming vs micro-batch), a nie na wiedzy o konkretnych narzędziach
• Wybory w modelowaniu danych (gwiazda vs płatek śniegu, typy SCD) powinny być zgodne ze wzorcami konsumpcji, a nie z teoretycznymi najlepszymi praktykami
• Odpowiedzi dotyczące projektowania systemów powinny uwzględniać obsługę awarii, optymalizację kosztów i obserwowalność oprócz scenariusza pozytywnego
• Najsilniejsi kandydaci wykazują ustrukturyzowane rozwiązywanie problemów i uczciwe rozumowanie o kompromisach