Przewodnik inżyniera danych

Ten przewodnik śledzi Annę Kowalską, personę inżyniera danych, w każdej ścieżce, jaką przebywa w DataFlow AI — od jej pierwszego dnia na platformie po stały rytm budowania, planowania i debugowania ponad 500 potoków danych, które uruchamia zespół DWH. Każdy krok jest powiązany z konkretnym ekranem i trasą, aby można było śledzić go w produkcie.

Zanim zaczniesz

Inżynier danych jest zaawansowanym użytkownikiem platformy. Anna pracuje we wszystkich trzech trybach edycji — wizualnym, SQL i Python — i ma najszerszy zestaw uprawnień zaraz po administratorze. Jej rolą backendową jest ENGINEER (poziom 75); jej rolą realmu Keycloak jest developer; jej personą UX jest engineer.

Jej dozwolone prefiksy tras obejmują /, /design-studio, /monitor, /governance, /migration, /connections, /marketplace, /pipelines, /data-browser oraz /templates. Może tworzyć, edytować, uruchamiać, wdrażać, debugować i usuwać potoki danych oraz zarządzać połączeniami.

Ścieżka 1 — Pięciodniowe wdrożenie

Celem wdrożenia jest przeprowadzenie Anny od jej pierwszego logowania do produktywnego produkcyjnego potoku danych w ciągu pięciu dni.

Dzień 1 — Konfiguracja konta

1. Anna otwiera adres URL platformy. Ponieważ skonfigurowana jest federacja Active Directory, jej poświadczenia AD automatycznie udostępniają konto DataFlow na ekranie logowania Keycloak.
2. Po uwierzytelnieniu trafia na selektor obszaru roboczego w górnym pasku i wybiera swój obszar roboczy DWH.
3. Nakładka wycieczki wdrożeniowej przeprowadza ją przez Design Studio — płótno, paletę i tryby edycji.
4. Klonuje zestaw przykładowych potoków danych i uruchamia potok „Hello World”. Kończy się on w ciągu 15 minut.

Ekrany: logowanie Keycloak, selektor obszaru roboczego TopBar, nakładka wycieczki wdrożeniowej, Design Studio.

Dzień 2–3 — Konfiguracja narzędzi

1. Anna łączy swoje repozytorium Git (GitLab lub Stash), aby każda definicja potoku danych była wersjonowana jako YAML.
2. Konfiguruje swoje lokalne IDE — VS Code z SDK Pythona oraz CLI dataflow — i uwierzytelnia się za pomocą dataflow login.
3. Rejestruje połączenia do baz danych, z którymi pracuje: Teradata, Snowflake oraz Databricks.
4. Uruchamia testowy potok danych i potwierdza, że push-down SQL jest poprawny.

Ekrany: integracja Git, CLI, rejestracja połączeń, testowe uruchomienie w Design Studio.

Dzień 4–5 — Pierwszy prawdziwy potok danych

1. Anna otwiera Centrum Migracji i migruje potok danych z PowerCenter.
2. Dostosowuje przekonwertowany YAML w edytorze YAML Design Studio.
3. Zgłasza potok danych do przeglądu kodu poprzez pull request w Git.
4. Po zatwierdzeniu wdraża go do Dev.

Ekrany: Centrum Migracji, edytor YAML Design Studio, PR Git / przegląd kodu, promocja środowiska.

Ścieżka 2 — Codzienny przepływ pracy

Typowy dzień Anny przechodzi od porannej kontroli kondycji, przez naprawianie awarii, do prac rozwojowych, a kończy się przeglądem kodu i wdrożeniem.

09:00 — Poranna kontrola

1. Anna otwiera swój adaptacyjny względem roli Pulpit główny (/dashboard, wariant inżyniera).
2. Czyta PipelineStatusCard — w nocy 487 z 500 potoków danych jest sprawnych, 2 zawiodły, 11 jest w stanie ostrzeżenia.
3. Klika nieudane uruchomienie w RecentFailuresCard, co przenosi ją do /monitor/runs/{runId}.

09:30 — Naprawa awarii

1. Na stronie Szczegółów uruchomienia czyta ustrukturyzowany, oznaczony kolorami dziennik błędów z pełnym śladem stosu.
2. Panel diagnozy AI diagnozuje problem — na przykład „rywalizacja o blokady w Teradata” — i sugeruje poprawkę, taką jak „dodaj ponawianie z wykładniczym wycofywaniem”.
3. Anna stosuje poprawkę i używa ponownego uruchomienia z punktu kontrolnego jednym kliknięciem, dzięki czemu potok danych wznawia działanie, a nie zaczyna od zera.

10:00 — Tworzenie potoków danych

1. Anna otwiera Design Studio i tworzy nowy potok danych.
2. Korzysta z edycji trójtrybowej — Wizualnej, SQL i Python, które pozostają w synchronizacji, oparte na jednej kanonicznej definicji YAML.
3. Przy każdym węźle przegląda wbudowany podgląd i profilowanie danych (typy kolumn, procent wartości null, rozkład wartości) w karcie Podgląd w prawym panelu.

14:00 — Przegląd kodu i wdrożenie

1. Anna zatwierdza swoją pracę do Git, albo z poziomu UI CommitModal, albo z CLI.
2. Otwiera pull request zawierający wizualny diff potoku danych, dzięki czemu recenzenci widzą zmianę DAG, a nie tylko tekst YAML.
3. CI waliduje zmianę; gdy jest zielona i zatwierdzona, scala ją i promuje do staging.

Ekrany: HomeDashboard (inżynier), PipelineStatusCard, RecentFailuresCard, Szczegóły uruchomienia w Centrum Monitorowania, AiDiagnosisPanel, płótno i edytory Design Studio, NodePreviewTab, CommitModal, DeployModal.

Ścieżka 3 — Zbuduj i zaplanuj potok danych

To główna ścieżka twórcza. Anna buduje potok danych ETL od zera w Design Studio i ustawia go w harmonogramie.

1. Nowy potok danych. W Design Studio Anna tworzy nowy potok danych i nadaje mu nazwę oraz typ — Wsadowy lub Strumieniowy (potok strumieniowy działa na Kafce + Flink).
2. Przeciągnij komponenty. Z Palety komponentów w lewym panelu przeciąga węzły na płótno. Paleta ma pięć kategorii — Źródła (14 konektorów), Transformacje (12), Cele (14), Jakość (5) oraz AI (3). Łączy port wyjściowy każdego węzła z portem wejściowym następnego.
3. Skonfiguruj źródło i cel. Wybranie węzła otwiera Inspektor właściwości po prawej stronie. Dla źródła ustawia połączenie, tabelę lub zapytanie, kolumnę partycjonowania, rozmiar pobierania oraz kolumnę przyrostową. Dla celu dodatkowo ustawia tryb zapisu (Append / Overwrite / Upsert / Merge / Delete-Insert), klucze upsert oraz SQL przed/po.
4. Dodaj transformacje. Wrzuca transformacje — SQL, Filter, Aggregate, Join, Deduplicate i tak dalej — i podłącza je między źródłem a celem.
5. Podejrzyj dane. Przy dowolnym węźle otwiera Podgląd danych, aby zobaczyć do 100 prawdziwych wierszy pobranych ze źródła z LIMIT.
6. Przełącz na YAML. Opcjonalnie otwiera edytor YAML, który pozostaje w dwukierunkowej synchronizacji z płótnem i oferuje autouzupełnianie oraz walidację.
7. Uruchom lub zaplanuj. Klika Uruchom, aby wykonać ręcznie, lub Zaplanuj, aby ustawić wyrażenie cron ze strefą czasową, filtrem dni roboczych oraz strategią nakładania.
8. Monitoruj na żywo. Uruchomienie strumieniuje status poszczególnych kroków przez WebSocket; ogląda je na żywo i przegląda historię w karcie Uruchomienia.
9. Backfill. Dla dat historycznych otwiera Backfill i ustawia zakres dat, granularność, współbieżność oraz opcjonalny przełącznik suchego uruchomienia.

Ścieżka 4 — Debugowanie awarii

Przebieg prawdziwego incydentu: potok danych wf_E112 zgłosił FAILED o 03:47.

Krok 1 — Triaż

1. Anna otrzymuje powiadomienie (PagerDuty, e-mail lub Slack).
2. Otwiera stronę Szczegółów uruchomienia potoku danych. Nieudany węzeł jest podświetlony na czerwono na wizualnym DAG, z czerwonym poświatą oraz dymkiem podpowiedzi błędu.

Krok 2 — Badanie

1. Czyta ustrukturyzowany dziennik błędów oraz ślad stosu w lewym panelu.
2. Panel diagnozy AI (po prawej, 40% ekranu) podaje kartę w fioletowym gradiencie z Podsumowaniem, Przyczyną źródłową — na przykład „Źródło Sybase przekroczyło limit czasu z powodu rywalizacji o blokady” — oraz ponumerowanymi Sugerowanymi działaniami, takimi jak „ponów z read-uncommitted”, każde z procentem pewności.
3. Podąża za odnośnikami pochodzenia danych, aby zobaczyć, które systemy zależne są dotknięte.

Krok 3 — Naprawa i weryfikacja

1. Anna stosuje sugerowaną poprawkę w YAML potoku danych.
2. Klika Uruchom ponownie z punktu kontrolnego, dzięki czemu potok danych wznawia działanie od nieudanego kroku, a nie zaczyna od początku.
3. Weryfikuje kompletność danych w tabeli docelowej.

Ekrany: panel powiadomień, PipelineRunDetail Monitora + RunDagViewer + AiDiagnosisPanel, Eksplorator pochodzenia danych (wpływ), RunDetailActions.

Ścieżka 5 — Budowanie własnego konektora

Inżynierowie mogą rozszerzać samą platformę o nowe konektory i dialekty SQL. To ścieżka skierowana do deweloperów.

Dodawanie konektora

1. Zaimplementuj JDBCConnectorBase albo NativeConnectorBase, dostarczając wymagane metody: connect, disconnect, testConnection, doDiscoverSchema, doExtractData oraz doLoadData.
2. Zarejestruj nowy konektor w ConnectorRegistry.
3. Dodaj odpowiednią wartość do enuma ConnectionType.
4. Napisz testy dla konektora.

Dodawanie dialektu push-down SQL

1. Utwórz klasę SqlDialect dla nowej bazy danych.
2. Zarejestruj ją w SparkSqlBridge.kt.
3. Napisz testy dialektu.

Przepływ wnoszenia wkładu

Po scaleniu nowy konektor pojawia się w Marketplace konektorów (/marketplace) oraz jako węzeł w Palecie komponentów Design Studio.

Ścieżka → odsyłacze do ekranów

Dokąd dalej

• Ścieżki użytkownika — pełny indeks ścieżek z mapami ASCII.
• Przewodnik analityka i stewarda — ścieżki dla person, którym Anna przekazuje pracę.
• Przewodnik administratora — operacje platformy oraz migracja starszych rozwiązań.
• Persony i role — jak persona inżyniera odwzorowuje się na role backendu i Keycloak.