Przykład zastosowania: SAP HANA do raportowania BI

Ta strona śledzi krok po kroku jedną konkretną osobę, gdy buduje prawdziwy potok danych w DataFlow AI — od pustego płótna po gotowy codzienny raport, który analitycy biznesowi otwierają w swoim narzędziu pulpitowym każdego ranka. Jest napisana dla czytelników, którzy nigdy wcześniej nie zbudowali potoku ETL, więc każdy termin jest wyjaśniany prostymi słowami w momencie, gdy się pojawia.

Poznaj ludzi w tej historii

Zanim dotkniemy choćby jednego ekranu, warto wiedzieć, kto jest zaangażowany. Prawdziwa praca ETL rzadko jest wykonywana przez jedną osobę samodzielnie — to mały wyścig sztafetowy.

Historia jest opowiedziana głównie z punktu widzenia Anny, ponieważ to ona wykonuje budowanie. Ale zobaczysz dokładnie, gdzie wkraczają pozostała trójka.

Potrzeba biznesowa, w jednym zdaniu

Każdego ranka o 08:00 Marek potrzebuje świeżego raportu pokazującego wczorajsze wyniki sprzedaży według regionu i kategorii produktu — a te dane mieszkają wewnątrz SAP HANA, systemu, którego Marek sam nie potrafi odpytać.

Rozpakujmy to zdanie, ponieważ zawiera cały problem.

• SAP HANA to duża, szybka baza danych, której Biuro Sprzedaży (BIURO_SPRZEDAZY) w Polkomtelu używa do rejestrowania każdej sprzedaży. Jest potężna, ale nie jest przyjaznym miejscem, w którym analityk mógłby grzebać — mówi technicznym „językiem", jest chroniona, a uruchamianie ciężkich zapytań na niej mogłoby spowolnić działający system sprzedaży.
• Narzędzie BI (Business Intelligence) to oprogramowanie pulpitowe, którego Marek już używa — wyobraź sobie ekran pełen wykresów i tabel, który odświeża jednym kliknięciem. Narzędzia BI najlepiej czują się, czytając z hurtowni danych: bazy danych zbudowanej specjalnie do analizy i raportowania, trzymanej oddzielnie od działających systemów operacyjnych.
• A więc luka jest taka: dane rodzą się w SAP HANA, ale muszą żyć w hurtowni, by Marek mógł ich używać. Coś musi je kopiować co noc, czyścić i podsumowywać.

Tym „czymś" jest potok danych, który Anna zaraz zbuduje.

Kształt potoku danych, zanim zaczniemy

Warto wyobrazić sobie gotowy potok danych przed jego zbudowaniem, tak jak rzuciłbyś okiem na zdjęcie potrawy przed gotowaniem. Potok danych Anny będzie miał siedem etapów, a mapują się one dokładnie na klasyczną ideę Extract, Transform, Load:

   SAP HANA            DataFlow AI Design Studio                  Warehouse
 +-----------+   E   +------------------------------------+   L   +-----------+
 | SALES     |------>| Filter -> Join -> Aggregate ->     |------>| DAILY_    |
 | tables    |       | Quality checks                     |       | SALES_RPT |
 +-----------+       +------------------------------------+       +-----------+
       Extract                  Transform                            Load

• Extract — kopiuje wczorajsze wiersze z SAP HANA.
• Transform — odrzuca testowe wiersze, łączy tabelę sprzedaży z tabelami referencyjnymi regionu/produktu i podsumowuje w sumy na region i na kategorię.
• Load — zapisuje gotowe podsumowanie do tabeli hurtowni, którą odczytuje narzędzie BI.

Wokół tych trzech kroków stoją trzy kolejne zagadnienia: jakość danych (czy liczby są wiarygodne?), harmonogramowanie (uruchamiaj to automatycznie każdej nocy) i publikowanie (uczyń wynik widocznym dla narzędzia BI). Omówimy je wszystkie.

Krok 1 — Upewnij się, że połączenia istnieją

Połączenie w DataFlow AI to zapisana, nazwana, zabezpieczona furtka do zewnętrznego systemu. Przechowuje adres, dane logowania i ustawienia bezpieczeństwa dla jednej bazy danych — tak by budowniczowie potoków danych nigdy nie musieli wpisywać haseł ani pamiętać nazw serwerów.

Anna nie tworzy połączeń sama. Ze względów bezpieczeństwa połączenia są konfigurowane raz przez Administratora Platformy — Katarzynę — a hasła są przechowywane zaszyfrowane w Google Secret Manager, nigdy więcej nie pokazywane na ekranie.

Więc zanim Anna zacznie, sprawdza z Katarzyną, że dwa połączenia są gotowe w przestrzeni roboczej:

1. Połączenie SAP HANA — źródło. Konektor DataFlow AI dla SAP HANA nazywa się sap-hana. Łączy się z SAP HANA przez sterownik o nazwie ODBC i potrafi odczytywać specjalne widoki analityczne SAP ze schematu _SYS_BIC (są to wbudowane obliczenia, które SAP HANA udostępnia). Został przetestowany na prawdziwych widokach BIURO_SPRZEDAZY Polkomtela.
2. **Połączenie z hurtownią** — cel. Polkomtel używa trzech hurtowni w zależności od zespołu: **Teradata** (długoletnia hurtownia DWH-MONA), **Snowflake** i **BigQuery**. Dla tego raportu Anna załaduje dane do hurtowni, której używa jej zespół analityczny. Poniższy przewodnik używa **Snowflake** jako przykładu, a

   dalej pokazuje, co zmienia się dla Teradata lub BigQuery.

Jak powstaje połączenie (strona Katarzyny)

Abyś mógł zobaczyć, na czym Anna polega, oto ścieżka kliknięć, którą Katarzyna podążyła wcześniej:

1. W lewym panelu bocznym, Admin → Połączenia → „+ Nowe Połączenie".
2. Wybierz typ konektora z siatki — dla źródła kafelek SAP HANA.
3. Wypełnij formularz: nazwa hosta, port (SAP HANA używa portu 30015 dla bazy danych dzierżawcy), nazwa bazy danych, nazwa użytkownika i hasło. Uwierzytelnianie jest ustawione na PASSWORD.
4. Kliknij „Testuj Połączenie". DataFlow AI nawiązuje połączenie na żywo i pokazuje opóźnienie podróży w obie strony plus mały podgląd schematu. Zielony wynik oznacza, że furtka działa.
5. Kliknij „Zapisz". Połączenie pojawia się teraz w zestawie narzędzi Studio Projektowego dla każdego inżyniera w przestrzeni roboczej.

Uważaj

Tworzenie lub edytowanie połączenia wymaga co najmniej roli Inżyniera Danych, a leżące u podstaw dane uwierzytelniające nigdy nie są ponownie wyświetlane po zapisaniu. Jeśli „Testuj Połączenie" się nie powiedzie, jest to niemal zawsze problem sieciowy lub zapory między platformą a SAP HANA — nie coś, co Anna może naprawić z ekranu potoku danych. Zgłasza to Katarzynie.

---

Krok 2 — Utwórz potok danych i otwórz Studio Projektowe

Studio Projektowe to wizualny warsztat, w którym budowane są potoki danych. To płótno typu przeciągnij i upuść: umieszczasz „węzły" (pudełka, z których każde wykonuje jedno zadanie) i łączysz je liniami, które przenoszą dane z pudełka do pudełka.

Anna tworzy potok danych:

1. Lewy panel boczny → Potoki danych → „+ Nowy Potok danych" (skrót klawiszowy Alt+N robi to samo z dowolnego miejsca).
2. Wpisuje nazwę: daily_sap_sales_report. Nazwy mają znaczenie — pojawiają się na ekranach monitorowania i w historii Git, więc utrzymuje ją opisową.
3. Dodaje krótki opis: „Codzienne podsumowanie sprzedaży SAP HANA według regionu i kategorii produktu dla BI."
4. Dla trybu wybiera Batch. Batch oznacza, że potok danych działa według harmonogramu, przetwarza jeden duży ładunek danych i zatrzymuje się — co jest dokładnie odpowiednie dla raportu raz na noc. (Drugi tryb, Streaming, działa nieprzerwanie 24/7 i jest używany do pracy w czasie rzeczywistym; nie jest to to, czego tu chcemy.)
5. Klika „Utwórz". Otwiera się płótno.

Mówiąc prościej

Batch kontra Streaming to po prostu dwie prędkości ETL. Batch to mleczarz: jedna dostawa, ta sama godzina każdego dnia. Streaming to kran: woda płynie w momencie, gdy go odkręcasz, i nigdy się nie zatrzymuje. Poranny raport sprzedaży to zadanie dla mleczarza.

Ekran Studio Projektowego

Płótno ma cztery główne obszary. Anna użyje ich wszystkich:

Obszar	Gdzie	Do czego służy
Paleta Komponentów	Po lewej	Zestaw narzędzi typów węzłów, pogrupowanych w Źródła, Transformacje, Cele, Jakość i AI. Przeszukiwalna za pomocą Ctrl+K.
Płótno	Pośrodku	Powierzchnia robocza, na której węzły są umieszczane i łączone.
Inspektor Właściwości	Po prawej	Panel ustawień dla węzła, który jest aktualnie zaznaczony.
Panel Dolny	Na dole	Podgląd Danych, Konsola (logi) i Wyniki Testów. Przełączaj go za pomocą Ctrl+J.

Studio automatycznie zapisuje co 30 sekund, więc Anna nigdy nie traci pracy.



---

Krok 3 — Extract: odczytanie danych sprzedaży z SAP HANA

Pierwszym węzłem, którego potrzebuje każdy potok danych, jest Źródło — pudełko, które kopiuje dane z systemu.

Anna przeciąga kafelek SAP HANA z grupy Źródła w palecie na płótno. Pojawia się niebieski węzeł źródłowy. Klika go, a Inspektor Właściwości po prawej wypełnia się ustawieniami.

Konfiguruje trzy rzeczy w zakładce Ogólne:

1. Połączenie — wybiera połączenie sap-hana, które przygotowała Katarzyna.
2. Tabela lub Zapytanie — mogłaby wybrać pojedynczą tabelę z przeglądarki schematów, ale ten raport potrzebuje wierszy z jednej głównej tabeli faktów, więc pisze małe zapytanie. Zapytanie to wpisana instrukcja mówiąca bazie danych dokładnie, które wiersze zwrócić.
3. Kolumna przyrostowa — to jest sprytna część. Anna nie chce kopiować całej historii sprzedaży każdej nocy; byłoby to powolne i bezcelowe. Chce tylko wczorajszych wierszy. Ustawia kolumnę przyrostową na datę sprzedaży i używa filtra daty, by każde uruchomienie pobierało jeden dzień.

Jej zapytanie źródłowe wygląda tak:

SELECT
  sale_id,
  sale_date,
  region_id,
  product_id,
  channel_code,
  net_amount,
  quantity
FROM "_SYS_BIC"."biuro.sprzedazy/SALES_FACT"
WHERE sale_date = '{{yesterday}}'

Część {{yesterday}} to funkcja szablonu — symbol zastępczy, który DataFlow AI wypełnia automatycznie, gdy potok danych działa. Rankiem 21 maja staje się 2026-05-20; następnego dnia staje się 2026-05-21. Anna pisze przepis raz, a zawsze prosi o „wczoraj", niezależnie od tego, jaki jest dziś dzień.

Mówiąc prościej

Ładowanie przyrostowe to różnica między ponownym czytaniem całej książki każdej nocy a czytaniem tylko strony, która została dodana dzisiaj. Książka (cała historia sprzedaży) może być ogromna; wczorajsza strona jest maleńka. Ładowania przyrostowe utrzymują potok danych szybkim i obciążają SAP HANA delikatnie.

Zanim ruszy dalej, Anna klika Podgląd na węźle źródłowym. Panel dolny pokazuje do 100 przykładowych wierszy pobranych na żywo z SAP HANA. Może zobaczyć prawdziwe rekordy sprzedaży — dowód, że furtka działa, a kolumny są nazwane tak, jak się spodziewa.

---

Krok 4 — Transform: filtruj, łącz i agreguj

Surowe dane niemal nigdy nie są gotowe do raportu. Anna dodaje teraz trzy węzły transformacji jeden za drugim. Każdy wykonuje jedno zadanie.

4a. Filter — odrzuć testowe wiersze

Biuro Sprzedaży czasami rejestruje fikcyjne sprzedaże do testowania systemu, oznaczone kodem kanału TEST. Te nigdy nie mogą dotrzeć do raportu biznesowego.

Anna przeciąga węzeł Filter na płótno i podłącza wyjście węzła źródłowego do niego. (Łączy węzły, najeżdżając na węzeł źródłowy, aż na jego krawędzi pojawi się małe kółko — port wyjściowy — a następnie przeciągając linię z tego kółka do portu wejściowego następnego węzła.)

W węźle Filter ustawia warunek:

channel_code != 'TEST'

Każdy wiersz, w którym kod kanału to TEST, jest odrzucany; wszystko inne przechodzi dalej.

4b. Join — wprowadź czytelne dla człowieka nazwy

Tabela sprzedaży przechowuje region_id i product_id — liczby, nie nazwy. Raport Marka musi mówić „Mazowsze" i „Plany Mobilne", a nie „7" i „412". Przyjazne nazwy mieszkają w dwóch małych tabelach referencyjnych.

Węzeł Join łączy dwa zbiory danych, dopasowując wspólną kolumnę — jak ułożenie dwóch list obok siebie i wyrównanie wierszy, które dzielą identyfikator.

Anna dodaje jeszcze dwa węzły źródłowe SAP HANA (jeden odczytujący tabelę referencyjną regionu, jeden tabelę referencyjną produktu), a następnie przeciąga dwa węzły Join:

• Pierwszy Join dopasowuje przefiltrowane wiersze sprzedaży do tabeli regionu po region_id, dodając kolumnę region_name.
• Drugi Join dopasowuje ten wynik do tabeli produktu po product_id, dodając product_category.

Dla obu używa złączenia LEFT. Złączenie LEFT zachowuje każdy wiersz sprzedaży, nawet jeśli pasujący wiersz referencyjny jest jakimś sposobem brakujący — więc sprzedaż nigdy nie jest po cichu zgubiona tylko dlatego, że kodu regionu jeszcze nie było w tabeli referencyjnej.

4c. Aggregate — podsumuj do kształtu raportu

Marek nie chce jednego wiersza na pojedynczą sprzedaż — chce sum. Węzeł Aggregator robi to: grupuje wiersze razem i oblicza liczbę podsumowującą dla każdej grupy, dokładnie jak tabela przestawna w arkuszu kalkulacyjnym.

Anna przeciąga węzeł Aggregator i konfiguruje go:

• Grupuj według: region_name, product_category
• Agregacje:
  • total_revenue = SUMA z net_amount
  • units_sold = SUMA z quantity
  • transaction_count = LICZBA z sale_id

Po tym węźle dzień z 90 000 pojedynczych sprzedaży może zwinąć się do zaledwie 60 wierszy podsumowujących — jeden na kombinację region-i-kategoria. To jest raport.

Mówiąc prościej

Pomyśl o trzech transformacjach jak o trzech kuchennych czynnościach. Filter wyrzuca zepsute składniki. Join stawia oznaczone słoiki obok nieoznaczonych, byś wiedział, co jest co. Aggregate to ostateczne nakładanie na talerz — zamiana stosu składników w niewielką liczbę gotowych porcji.

Zrobienie tego w SQL zamiast — ten sam potok danych, dwa widoki

Wszystko powyżej zostało zbudowane przez przeciąganie pudełek. Ale Studio Projektowe ma tryb SQL: przycisk na górze przełącza płótno na edytor kodu pokazujący ten sam potok danych jako SQL. Niektórzy inżynierowie wolą wyrażać złączenia i agregacje jako pojedyncze polecenie SQL. Anna zerka na widok SQL, by jeszcze raz sprawdzić logikę:

SELECT
  r.region_name,
  p.product_category,
  SUM(s.net_amount)  AS total_revenue,
  SUM(s.quantity)    AS units_sold,
  COUNT(s.sale_id)   AS transaction_count
FROM sales_fact s
LEFT JOIN dim_region  r ON s.region_id  = r.region_id
LEFT JOIN dim_product p ON s.product_id = p.product_id
WHERE s.channel_code != 'TEST'
GROUP BY r.region_name, p.product_category

Wizualne płótno i edytor SQL to dwa okna na jedną definicję potoku danych — zmień jedno, a drugie się zaktualizuje. Anna może pracować w dowolny sposób, który pasuje do zadania.

Mówiąc prościej

DataFlow AI ma Silnik SQL Push-Down. Gdy źródło i cel potrafią mówić w SQL, platforma jest na tyle sprytna, by wysłać instrukcję do bazy danych zamiast przeciągać wszystkie dane przez sieć, by je tutaj przetwarzać. SAP HANA ma szybki silnik w pamięci; pozwolenie mu na filtrowanie i grupowanie na miejscu jest szybsze i tańsze. Platforma twierdzi, że potrafi w ten sposób przenieść na poziom źródła około 90% standardowej pracy analitycznej — a Anna nie musi robić niczego specjalnego, by to uzyskać.

---

Krok 5 — Jakość danych: uczyń liczby wiarygodnymi

Piękny raport zbudowany na złych danych jest gorszy niż brak raportu. Zanim dane zostaną dopuszczone do wylądowania w hurtowni, Anna dodaje węzły Jakości — automatyczne kontrole, które badają dane i mogą zatrzymać potok danych, jeśli coś wygląda nie tak.

DataFlow AI oferuje dziesięć rodzajów reguł jakości. Anna wybiera cztery, które mają znaczenie dla tego raportu:

Kontrola jakości	Typ reguły	Co wyłapuje
Nazwa regionu jest zawsze obecna	NOT_NULL	Złączenie, które nie znalazło regionu
Przychód nigdy nie jest ujemny	RANGE (min 0)	Błąd wprowadzania danych lub błędnie zarejestrowany zwrot
Podsumowanie ma sensowną liczbę wierszy	ROW_COUNT	Puste lub zdublowane ładowanie
Wczorajsze dane są faktycznie świeże	FRESHNESS	Źródło nie zaktualizowało się w nocy

Przeciąga węzeł Jakości na płótno za węzłem Aggregator i konfiguruje te reguły w jego ustawieniach. Dla każdej reguły ustawia dotkliwość — Critical, Warning lub Info — oraz to, czy niepowodzenie powinno zablokować potok danych.

Anna ustawia kontrole NOT_NULL i RANGE na Critical / blokuj: jeśli brakuje nazw regionów lub przychód jest ujemny, potok danych zatrzymuje się i nic nie dociera do hurtowni — lepiej brak raportu niż błędny. Ustawia kontrolę ROW_COUNT na Warning: podnosi alert, ale pozwala uruchomieniu kontynuować.

Uważaj

Reguły jakości działają przy każdym pojedynczym wykonaniu, nie tylko raz. Jest to celowe. Systemy źródłowe zmieniają się bez ostrzeżenia — kolumna zostaje przemianowana, kanał danych dociera z opóźnieniem, błąd po stronie nadrzędnej podwaja każdy wiersz. Węzeł jakości to pas bezpieczeństwa, który wyłapuje te problemy zanim staną się błędną liczbą na ekranie kierownictwa. Tomasz, Opiekun Danych, również monitoruje te wyniki z Centrum Zarządzania.

Gdzie maskowane są dane osobowe

Ten konkretny raport sprzedaży zajmuje się regionami i kategoriami produktów, a nie klientami, więc nie zawiera żadnych danych osobowych. Ale gdyby potok danych jednak pobierał PESEL klienta (polski krajowy numer identyfikacyjny) lub numer telefonu, Anna dodałaby węzeł Expression, by zamaskować te kolumny — zaszyfrować lub ukryć wrażliwą część — tak by szczegół osobowy nigdy nie dotarł do końcowego raportu. Skaner PII DataFlow AI również automatycznie oznaczyłby takie kolumny do przeglądu przez Tomasza. Maskowanie odbywa się podczas kroku Transform, celowo, więc wrażliwe dane są obsługiwane wcześnie.

---

Krok 6 — Load: zapisanie wyniku do hurtowni

Ostatnim węzłem jest Sink (zwany również Celem) — pudełko, które zapisuje dane do systemu docelowego.

Anna przeciąga kafelek Snowflake z grupy Cele i podłącza wyjście węzła Jakości do niego. W Inspektorze Właściwości ustawia:

1. Połączenie — połączenie z hurtownią Snowflake.
2. Tabela — ANALYTICS.REPORTING.DAILY_SALES_RPT, tabela hurtowni, którą odczyta narzędzie BI.
3. Tryb zapisu — to decyduje, jak nowe dane spotykają się ze starymi. Opcje to:

Tryb zapisu	Co robi	Dobry dla
Append	Dodaje nowe wiersze obok istniejących	Logi, historia, która tylko rośnie
Overwrite	Usuwa wszystko, zapisuje od nowa	Małe tabele wyszukiwania
Upsert / Merge	Aktualizuje wiersze, które już istnieją, wstawia wiersze, które są nowe	Większość codziennych ładowań
Delete-Insert	Usuwa jeden wycinek danych, a następnie wstawia go ponownie	Ponowne ładowanie pojedynczego dnia

Anna wybiera Delete-Insert, kluczowany według daty raportu. Dlaczego? Ponieważ jeśli wczorajsze uruchomienie kiedykolwiek zostanie uruchomione ponownie (by naprawić problem), chce, by czysto zastąpiło wczorajszy wycinek — a nie nakładało drugą kopię na wierzch. Delete-Insert usuwa stary dzień i zapisuje poprawiony dzień.

Klika Waliduj na pasku narzędzi. Walidacja sprawdza, czy każdy węzeł jest połączony, każde wymagane pole wypełnione, czy nie ma pętli w DAG-u i czy schematy się zgadzają. Zielony wynik oznacza, że potok danych jest gotowy do uruchomienia.

Następnie klika Uruchom → Uruchom Teraz dla pierwszego testu ręcznego. Węzły rozświetlają się jeden po drugim, gdy dane przepływają; zakładka Konsola streamuje logi; kilka sekund później uruchomienie kończy się na zielono. Anna otwiera hurtownię i widzi DAILY_SALES_RPT wypełnioną wczorajszymi 60 wierszami podsumowującymi. Potok danych działa.

---

Krok 7 — Potok danych jako YAML

Wszystko, co Anna zbudowała przez przeciąganie pudełek, jest przechowywane, za kulisami, jako pojedynczy czytelny dla człowieka plik tekstowy w formacie zwanym YAML. Każdy zapis jest automatycznie zatwierdzany do Git, więc potok danych ma pełną historię wersji. Anna może przeglądać i edytować ten YAML bezpośrednio za pomocą zakładki YAML — wizualne płótno i YAML pozostają zsynchronizowane.

Oto gotowy potok danych:

apiVersion: dataflow.polkomtel.com/v1
kind: Pipeline
metadata:
  name: daily-sap-sales-report
  namespace: revenue-assurance
  labels:
    domain: sales
    report: bi-daily
  annotations:
    description: Daily SAP HANA sales summary by region and product category
    owner: anna.kowalska@plk.pl
    sla: "08:00 Europe/Warsaw"
spec:
  schedule: "0 5 * * 1-5 !PL_HOLIDAY"
  timezone: Europe/Warsaw
  enabled: true
  timeout: 1800
  retries: 3
  retryDelay: 300
  parameters:
    - name: report_date
      type: date
      default: "{{yesterday}}"
      description: The sales day to summarise

  nodes:
    - id: src_sales
      type: connector_source
      label: SAP HANA - sales fact
      config:
        connector: sap-hana
        query: >
          SELECT sale_id, sale_date, region_id, product_id,
                 channel_code, net_amount, quantity
          FROM "_SYS_BIC"."biuro.sprzedazy/SALES_FACT"
          WHERE sale_date = '{{parameters.report_date}}'
        incrementalColumn: sale_date
        fetchSize: 5000

    - id: src_region
      type: connector_source
      label: SAP HANA - region reference
      config:
        connector: sap-hana
        table: '"_SYS_BIC"."biuro.sprzedazy/DIM_REGION"'

    - id: src_product
      type: connector_source
      label: SAP HANA - product reference
      config:
        connector: sap-hana
        table: '"_SYS_BIC"."biuro.sprzedazy/DIM_PRODUCT"'

    - id: drop_test_rows
      type: filter
      label: Remove test transactions
      config:
        condition: "channel_code != 'TEST'"

    - id: join_region
      type: joiner
      label: Add region name
      config:
        leftInput: drop_test_rows
        rightInput: src_region
        joinType: LEFT
        on: "region_id"

    - id: join_product
      type: joiner
      label: Add product category
      config:
        leftInput: join_region
        rightInput: src_product
        joinType: LEFT
        on: "product_id"

    - id: summarise
      type: aggregator
      label: Totals by region and category
      config:
        groupBy: [region_name, product_category]
        aggregations:
          - { column: net_amount, function: SUM,   alias: total_revenue }
          - { column: quantity,   function: SUM,   alias: units_sold }
          - { column: sale_id,    function: COUNT, alias: transaction_count }

    - id: quality_gate
      type: quality
      label: Trust checks
      config:
        rules:
          - { type: NOT_NULL, column: region_name, severity: CRITICAL, blockPipeline: true }
          - { type: RANGE,    column: total_revenue, min: 0, severity: CRITICAL, blockPipeline: true }
          - { type: ROW_COUNT, min: 1, severity: WARNING, blockPipeline: false }

    - id: load_warehouse
      type: connector_sink
      label: Snowflake - DAILY_SALES_RPT
      config:
        connector: snowflake
        table: ANALYTICS.REPORTING.DAILY_SALES_RPT
        writeMode: DELETE_INSERT
        upsertKeys: [report_date, region_name, product_category]
        batchSize: 10000

  edges:
    - { from: src_sales,      to: drop_test_rows }
    - { from: drop_test_rows, to: join_region }
    - { from: src_region,     to: join_region }
    - { from: join_region,    to: join_product }
    - { from: src_product,    to: join_product }
    - { from: join_product,   to: summarise }
    - { from: summarise,      to: quality_gate }
    - { from: quality_gate,   to: load_warehouse }

  notifications:
    onSuccess:
      - channel: email
        message: "Daily SAP sales report loaded for {{parameters.report_date}}"
    onFailure:
      - channel: slack
        message: "FAILED: daily SAP sales report for {{parameters.report_date}}"

Nie musisz tego zapamiętywać — Studio Projektowe pisze to za Ciebie. Ale warto wiedzieć, że to istnieje, ponieważ sprawia, że potok danych jest możliwy do przeglądu, porównywania różnic i odzyskiwania jak każdy inny fragment kodu.

---

Krok 8 — Zaplanuj codzienne uruchomienie

Potok danych, który trzeba uruchamiać ręcznie każdego ranka, nie jest zbyt wielką automatyzacją. Anna ustawia harmonogram, by DataFlow AI uruchamiał go samodzielnie.

W Ustawieniach Potoku Danych (ikona koła zębatego) ustawia harmonogram. Możesz zbudować go za pomocą wizualnego selektora lub wpisać wyrażenie cron — zwięzły kod, który oznacza „uruchom o tych godzinach". Anna używa:

0 5 * * 1-5 !PL_HOLIDAY

Czytając to od lewej do prawej: minuta 0, godzina 5, każdy dzień miesiąca, każdy miesiąc, dni 1-5 (od poniedziałku do piątku). A więc: 05:00 każdego dnia roboczego. To daje potokowi danych trzy godziny zapasu przed terminem Marka o 08:00.

Część !PL_HOLIDAY to rozszerzenie DataFlow AI. Oznacza: pomiń polskie święta państwowe. Platforma ma wbudowany polski kalendarz świąt (Nowy Rok, Trzech Króli, Poniedziałek Wielkanocny, Święto Konstytucji i resztę), więc raport nie uruchamia się bez sensu w dniu, gdy Biuro Sprzedaży jest zamknięte.

Mówiąc prościej

Wyrażenie cron to po prostu pięciopolowy wzorzec czasu: minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia. Wygląda zagadkowo, ale zawsze odpowiada tylko na jedno pytanie — „kiedy to powinno się uruchomić?". 0 5 * * 1-5 oznacza piątą rano, od poniedziałku do piątku.

Jeśli coś pójdzie nie tak w nocy, potok danych ponawia próbę do trzech razy z rosnącymi opóźnieniami, a powiadomienie onFailure wysyła wiadomość na Slacku — więc Anna dowiaduje się o problemie, zanim Marek.

---

Krok 9 — Udostępnij wynik narzędziu BI

Potok danych zrzuca teraz czyste, wiarygodne podsumowanie do ANALYTICS.REPORTING.DAILY_SALES_RPT w hurtowni każdego ranka dnia roboczego. Ostatnia mila to podłączenie pulpitu Marka do niego.

Ta część dzieje się w narzędziu BI, a nie w DataFlow AI — ale jest prosta, ponieważ ciężka praca jest wykonana:

1. W narzędziu BI Marek (lub administrator BI) tworzy źródło danych wskazujące na hurtownię Snowflake.
2. Wybiera tabelę DAILY_SALES_RPT — małą, czystą, wstępnie podsumowaną tabelę. Ponieważ potok danych już przefiltrował, połączył i zagregował dane, narzędzie BI musi je tylko wyświetlić. Żadna ciężka praca nie odbywa się w chwili otwarcia pulpitu.
3. Buduje wykresy raz: przychód według regionu, jednostki według kategorii produktu, trend liczby transakcji.
4. Ustawia pulpit, by odświeżał się każdego ranka po 05:30.

Od tej pory Marek otwiera swój pulpit o 08:00 i widzi wczorajsze liczby — świeże, poprawne i szybkie — nigdy nie dotykając SAP HANA.

Mówiąc prościej

Powodem, dla którego narzędzie BI wydaje się natychmiastowe, jest to, że potok danych przeniósł całą powolną pracę na poprzednią noc. Pulpit Marka odczytuje maleńką gotową tabelę, a nie miliony surowych wierszy sprzedaży. Dobry projekt ETL polega głównie na wykonaniu kosztownej pracy raz, z wyprzedzeniem, tam gdzie nikt nie czeka.

---

Przełączanie hurtowni docelowej

Przewodnik używał Snowflake, ale Polkomtel prowadzi trzy hurtownie. Wymiana celu to mała zmiana — różni się tylko węzeł Sink.

Hurtownia	Konektor	Godna uwagi szczegół
Snowflake	snowflake	Masowe ładowanie przez COPY INTO; obsługuje MERGE dla upsertów
Teradata (DWH-MONA)	teradata	Używa szybkiego Teradata Parallel Transporter; wybierz tryb multiload dla upsertów
BigQuery	bigquery	Ładuje przez wsadowe zadania ładowania; dane pozostają we własnym projekcie GCP klienta w Warszawie

By przełączyć, Anna usuwa sink Snowflake, przeciąga w jego miejsce kafelek nowej hurtowni, wskazuje go na właściwe połączenie i tabelę oraz ponownie waliduje. Siedmioetapowy kształt potoku danych — extract, filter, join, aggregate, quality, load — w ogóle się nie zmienia.

---

Co Anna zbudowała, w skrócie

Etap	Typ węzła	Cel
1	connector_source (sap-hana)	Extract wczorajszej sprzedaży z SAP HANA
2	filter	Odrzuć testowe transakcje
3	joiner ×2	Dodaj nazwy regionów i kategorie produktów
4	aggregator	Podsumuj w sumy na region i na kategorię
5	quality	Zablokuj uruchomienie, jeśli liczby wyglądają błędnie
6	connector_sink (hurtownia)	Załaduj podsumowanie do hurtowni
7	harmonogram + powiadomienia	Uruchamiaj każdego dnia roboczego o 05:00, alarmuj przy niepowodzeniu

Jeden przepis, napisany raz przez Annę, teraz zasila poranny pulpit Marka każdego dnia roboczego — a Tomasz może w dowolnym momencie zobaczyć, że dane są maskowane tam, gdzie trzeba, a kontrole jakości przechodzą pomyślnie. To kompletny przykład zastosowania ETL, od początku do końca.