Przykład zastosowania: Migracja przepływów pracy Alteryx

To pełna historia tego, jak ręcznie zbudowany przez analityka Polkomtela przepływ pracy Alteryx — łańcuch kolorowych pudełek narzędzi, który przez lata żył na laptopie jednej osoby — staje się kontrolowanym, opartym na chmurze potokiem danych DataFlow AI. Śledzimy każdy ekran i każdą decyzję, wyjaśnione tak, by mogła to zrozumieć osoba, która nigdy nie napisała ani linijki kodu.

Poznaj ludzi i problem

Przedstawmy Joannę. Joanna pracuje w analityce marketingowej w Polkomtel Plus. Nie jest inżynierem oprogramowania; jest analitykiem, który musi łączyć dane z arkuszy kalkulacyjnych i baz danych, by odpowiadać na pytania biznesowe. Od lat jej ulubionym narzędziem jest Alteryx Designer — program, w którym buduje się proces danych, przeciągając małe kolorowe ikony narzędzi na płótno i łącząc je liniami. Bez kodu, tylko pudełka i strzałki.

Alteryx jest wspaniały dla jednej osoby eksperymentującej przy biurku. Ale przerodził się w cichy problem dla Polkomtela:

• Każdy przepływ pracy to plik .yxmd, który żyje na laptopie analityka lub na dysku współdzielonym. Nie ma centralnego repozytorium, kontroli wersji, pochodzenia danych — nie ma zapisu, kto co zmienił ani skąd pochodziły dane.
• Przepływów pracy nie da się awansować do produkcji. Działają, gdy Joanna otwiera Alteryx i klika Uruchom. Jeśli Joanna jest na urlopie, raport się nie pojawi.
• Polkomtel płaci około 200 000 dolarów rocznie za licencje Alteryx, na dodatek do znacznie większego rachunku za Informaticę.

Polkomtel ma 50 do 100 przepływów pracy Alteryx takich jak ten Joanny i chce je wszystkie przenieść na DataFlow AI — tę samą nowoczesną, kontrolowaną platformę chmurową, na którą migrują przepływy pracy Informatica. Tam stają się one zaplanowanymi, wersjonowanymi, monitorowanymi potokami danych, które działają samodzielnie. Centrum Migracji wewnątrz DataFlow AI wykonuje większość tej konwersji automatycznie.

Czym właściwie jest przepływ pracy Alteryx

Zanim Joanna będzie mogła przenieść przepływ pracy, warto wiedzieć, z czego jest on zbudowany. Przepływ pracy Alteryx jest znacznie płaszczy i prostszy niż ten Informatica — nie ma zagnieżdżonych sesji ani mapowań, jest tylko pojedyncze płótno.

A więc przepływ pracy Alteryx to po prostu płaski zestaw narzędzi połączonych przez połączenia. Plik .yxmd jest tak naprawdę pod spodem plikiem XML — ustrukturyzowanym tekstem, który Centrum Migracji potrafi odczytać. DataFlow AI używa tej samej idei, ale nazywa narzędzia węzłami, a połączenia krawędziami, złożonymi w potok danych.

Wewnątrz .yxmd Centrum Migracji spodziewa się tego kształtu:

AlteryxDocument
 ├─ Properties → MetaInfo → Name        (the workflow name, optional)
 ├─ Nodes
 │   └─ Node  (each has a ToolID)
 │        ├─ GuiSettings  (Plugin="…Filter.Filter" — tells us the tool type)
 │        └─ Properties
 │             ├─ Configuration         (the tool's settings)
 │             └─ Annotation → Name      (the friendly label)
 └─ Connections
      └─ Connection → Origin / Destination

Centrum Migracji ustala, jakiego rodzaju narzędziem jest każdy węzeł, odczytując jego atrybut Plugin i biorąc ostatnie słowo: AlteryxBasePluginsGui.Filter.Filter oznacza po prostu narzędzie Filter.

Przykład, który będziemy śledzić: EksportujDoBazyWsparcia.yxmd

Pierwsza migracja Joanny to prawdziwy przepływ pracy Polkomtela: EksportujDoBazyWsparcia.yxmd, zbudowany w Alteryx 2022.3.

Mówiąc prosto, ten przepływ pracy obsługuje kuriera i logistykę (dane przesyłek „BDL"). Odczytuje z arkusza kalkulacyjnego Excel i bazy danych Teradata, przepuszcza dane przez około 50 narzędzi ułożonych w 4 równoległe strumienie, usuwa duplikaty pomiędzy różnymi źródłami, kieruje wiersze w zależności od środowiska i zapisuje wyniki do MSSQL i Teradata.

Jest oceniany jako złożoność średnio-wysoka, a Centrum Migracji spodziewa się mniej więcej 78%–82% automatycznej konwersji. Pozostałe około 18% to głównie niestandardowe makra — pliki .yxmc takie jak CountRecords.yxmc, Log_BDL_LH.yxmc i IdImportu.yxmc — plus jedna procedura składowana. Zobaczymy dokładnie, jak są one obsługiwane.

Krok 1 — Zlokalizuj i przygotuj plik .yxmd

Joanna nie musi niczego „eksportować" — plik .yxmd jest przepływem pracy. Po prostu znajduje EksportujDoBazyWsparcia.yxmd na dysku współdzielonym, na którym żyje.

Dwie praktyczne kwestie:

• Plik musi mieć rozszerzenie .yxmd — tak Centrum Migracji rozpoznaje przepływ pracy Alteryx. (Makra Alteryx są zapisywane jako pliki .yxmc; nie można ich przesyłać bezpośrednio i są obsługiwane inaczej — zobacz Krok 7.)
• Plik musi mieć 50 MB lub mniej. Definicje przepływów pracy to małe pliki tekstowe, więc rzadko jest to problemem.

Jeśli przepływ pracy opiera się na makrach parametryzujących środowisko — małych makrach, które tylko podają rzeczy takie jak nazwa bazy danych czy data — plan Polkomtela polega na wykluczeniu ich z automatycznej migracji i obsłużeniu parametrów natywnie w DataFlow AI.

Krok 2 — Prześlij plik do Centrum Migracji

Przesłanie wykonuje kolega Joanny z zespołu inżynieryjnego, Marek (tworzenie potoków danych wymaga roli Inżyniera Danych). Loguje się do DataFlow AI pod adresem https://dataflow.polkomtel.internal swoim zwykłym pojedynczym logowaniem Polkomtela, klika Migracja w lewym panelu bocznym i ląduje na Kreatorze Importu.

Przeciąga EksportujDoBazyWsparcia.yxmd na strefę upuszczania. Centrum Migracji natychmiast uruchamia kilka kontroli bezpieczeństwa:

1. Czy nazwa pliku jest obecna, a rozszerzenie dozwolone? Musi to być .xml, .yxmd lub .dtsx. .yxmd jest na liście, więc plik przechodzi pomyślnie.
2. Czy plik ma mniej niż 50 MB? Tak.
3. Tworzy śledzone zadanie migracji, oznacza je jako UPLOADED, bezpiecznie zapisuje surowy plik i zapisuje rekord zadania na dysku, więc nic nie ginie.

Od tego jednego przesłania Centrum Migracji uruchamia cały potok konwersji automatycznie. Marek po prostu obserwuje zmianę statusu zadania przez te etapy:

UPLOADED → PARSING → PARSED → CONVERTING → VALIDATING → VALIDATED
         → COMPLETED  |  COMPLETED_WITH_WARNINGS  |  FAILED

Kolejne sekcje wyjaśniają, co robi każdy etap.

Krok 3 — Parsowanie: odczytanie płótna na wspólny język

Status zadania zmienia się na PARSING. Centrum Migracji wybiera Parser Alteryx i odczytuje plik .yxmd.

Parser przechodzi przez każdy Node w pliku i sortuje każde narzędzie do jednego z trzech koszyków:

• Narzędzia wejściowe (takie jak AlteryxInput, DbFileInput, FileInput) stają się źródłami — pobierają ścieżkę pliku, połączenie i tabelę.
• Narzędzia wyjściowe (takie jak AlteryxOutput, DbFileOutput, FileOutput) stają się celami.
• Wszystko inne staje się transformacją — krokiem przetwarzania.

Dla każdego narzędzia odczytuje również odpowiednie szczegóły w zależności od typu narzędzia:

• Wiersze obliczeń narzędzia Formula (każdy: pole, wyrażenie, typ).
• Wiersze podsumowania narzędzia Summarize (każdy: pole, akcja).
• Tekst warunku zachowania narzędzia Filter.
• Wybrane pola narzędzia Select.

Na koniec odczytuje każde Connection i zapisuje je jako krawędź — strzałkę — łączącą odpowiednie narzędzia po ich Tool ID.

Wynikiem jest neutralny wobec narzędzi wewnętrzny opis przepływu pracy. To jest sprytna część: PowerCenter, Alteryx, SSIS i DataStage są wszystkie tłumaczone na ten sam wewnętrzny kształt, więc DataFlow AI potrzebuje potem tylko jednego silnika konwersji.

Jeśli plik .yxmd jest wadliwy, zadanie zatrzymuje się tutaj jako FAILED z jasnym komunikatem. Dla prawidłowego pliku Joanny parsowanie kończy się sukcesem, a status zmienia się na PARSED.

Krok 4 — Konwersja: zamiana każdego narzędzia Alteryx w węzeł DataFlow

Status zadania zmienia się na CONVERTING, a Silnik Reguł tworzy teraz równoważny potok danych DataFlow AI. Próbuje trzech warstw, po kolei:

1. Precyzyjna reguła. Większość powszechnych narzędzi Alteryx ma dedykowaną, napisaną ręcznie konwersję. Są przewidywalne i godne zaufania — węzeł jest oznaczony źródłem konwersji rule_engine.
2. Mapowanie ogólne. Niektóre narzędzia otrzymują poprawny typ DataFlow, ale jeśli ich pewność jest wystarczająco wysoka, są przenoszone z ogólną konfiguracją, a nie pełnym tłumaczeniem.
3. Asystent AI (LLM). Tylko naprawdę nietypowe narzędzia — pewność poniżej 0,60 — są przekazywane do faktycznego modelu AI (Claude od Anthropic). Te węzły są oznaczone jako llm.

To oznaczenie natychmiast mówi recenzentowi, jak powstał każdy węzeł.

Tabela mapowania narzędzie po narzędziu

Oto serce konwersji — jak każde narzędzie Alteryx staje się węzłem DataFlow. Niemal każda konwersja zamienia wizualne narzędzie w kawałek SQL, standardowego języka, którym mówią bazy danych, co sprawia, że wynik jest szybki i gotowy na chmurę.

Co konwertuje się automatycznie, a co wymaga przeglądu

Dla EksportujDoBazyWsparcia.yxmd obraz wygląda tak:

Konwertuje się automatycznie (te ~80%) — cztery równoległe strumienie są zbudowane głównie z narzędzi Input, Select, Filter, Formula, Join, Summarize, Sort i Union. Każde z nich ma precyzyjną regułę, konwertuje się jako rule_engine i osiąga 0,80 lub wyżej. Wejścia Excel i Teradata stają się węzłami źródłowymi; wyjścia MSSQL i Teradata stają się węzłami docelowymi (oba ze stałą pewnością 0,95).

Wymaga człowieka (te ~20%) — przepływ pracy używa niestandardowych makr, które muszą zostać zbadane i przepisane ręcznie, ponieważ logika makra żyje wewnątrz jego własnego pliku .yxmc, którego silnik nie widzi z samego .yxmd:

• Sześć kopii CountRecords.yxmc — makro liczące wiersze.
• Sześć kopii Log_BDL_LH.yxmc — makro logujące.
• Jedna kopia IdImportu.yxmc — makro identyfikatora importu.
• Jedna procedura składowana plkPrzesylki_Aktualizacja_BDL, która działa jako krok Post-SQL w bazie danych.

Każde narzędzie makra jest konwertowane na symbol zastępczy custom_transform z pewnością 0,40 i kierowane do asystenta AI, który tworzy początkowy szkielet. Ale człowiek musi otworzyć oryginalne pliki .yxmc, zrozumieć, co robią, i właściwie dokończyć konwersję.

Krok 5 — Punktacja pewności i bramka wydania 0,85

Każdy przekonwertowany węzeł otrzymuje wskaźnik pewności między 0 a 1 — uczciwą ocenę silnika, jak bardzo jest pewien. Sort osiąga 0,98; Macro osiąga 0,40. Ogólna pewność to średnia wszystkich wyników węzłów.

Pewność kontroluje, czy migracja może zakończyć się samodzielnie. To jest bramka wydania, ustawiona na 0,85. Po konwersji Centrum Migracji zbiera listę problemów blokujących. Zadanie jest zablokowane, jeśli prawdziwe jest którekolwiek z poniższych:

• Ogólna pewność jest poniżej 0,85.
• Jakikolwiek pojedynczy obiekt przekonwertował się poniżej 0,80 pewności.
• Jakikolwiek obiekt ma typ custom_transform lub niesie nierozwiązane issues.
• Walidacja znalazła problem.

Jeśli lista blokująca jest pusta, zadanie zostaje oznaczone jako COMPLETED. Jeśli ma choć jedną pozycję, zadanie zostaje oznaczone jako FAILED — a komunikat błędu wymienia dokładnie, która bramka zadziałała.

Dla EksportujDoBazyWsparcia.yxmd ponad siedem węzłów makr to wszystko custom_transform. To samo w sobie blokuje wydanie bez nadzoru, więc to zadanie jest FAILED przez bramkę. Nie jest to problem — to system działający poprawnie. Oznacza „inżynier musi dokończyć pracę nad makrami, zanim to trafi dalej". Marek spodziewa się tego dla przepływu pracy o złożoności średnio-wysokiej; tylko najprostsze przepływy pracy przechodzą prosto do COMPLETED.

Przepływy pracy Alteryx jako grupa konwertują się w zakresie 75%–82%. EksportujDoBazyWsparcia.yxmd ląduje na 78–82% automatycznie, z mniej więcej jednym dniem pracy manualnej nad makrami i procedurą składowaną.

Krok 6 — Walidacja: sześć niezależnych kontroli bezpieczeństwa

Gdy zadanie było w stanie VALIDATING, uruchomiły się dwie warstwy kontroli.

Kontrole strukturalne (Walidator Potoku) potwierdzają, że wygenerowany plik potoku danych jest poprawnie sformułowany:

1. Składnia YAML — plik się parsuje, a jego najwyższy poziom jest właściwą strukturą.
2. Wymagane klucze — potok danych ma name i listę nodes.
3. Schemat węzła — każdy węzeł ma unikatowe id i prawidłowy type (source, transform, sink lub quality).
4. Odwołania krawędzi — każda strzałka wskazuje na węzły, które istnieją.
5. Skanowanie bezpieczeństwa SQL — każdy fragment SQL jest skanowany pod kątem niebezpiecznych poleceń (DROP TABLE, TRUNCATE TABLE, ALTER TABLE i podobnych).
6. Nazwy konektorów — każdy konektor jest rozpoznawanym typem.

Kontrole biznesowe (zestaw sześciu kontroli) uruchamiają się, gdy Marek otwiera ekran Zestawu Walidacji:

Dla EksportujDoBazyWsparcia.yxmd kontrole strukturalne przechodzą i większość kontroli biznesowych przechodzi — ale kontrola 6 (problemy mapowania) oznaczy nierozwiązane węzły makr. To ten sam komunikat, który dała bramka wydania, przedstawiony ponownie jako wynik walidacji: dokończ makra.

Krok 7 — Przegląd przekonwertowanego potoku danych i dokończenie makr

Marek otwiera raport migracji na ekranie Konwersja AI. Układa on:

• Łączną liczbę obiektów, podzieloną na automatycznie przekonwertowane (pewność ≥ 0,8), wymagające przeglądu (0,5–0,8) i wymagające pracy ręcznej (poniżej 0,5).
• Rozkład pewności w przedziałach od „wysoki (90–100%)" w dół do „krytyczny (0–39%)".
• Pełną listę mapowań obiektów — każdy typ narzędzia Alteryx, jego nowy typ DataFlow, jego pewność i jego źródło konwersji (rule_engine lub llm).
• Problemy walidacji i ostrzeżenia.
• Szacunek nakładu pracy: około 0,25 godziny na węzeł automatyczny, 1 godzina na przegląd każdego węzła wspomaganego przez AI, 2 godziny na węzeł w pełni ręczny, plus testowanie i stałe 4 godziny testów integracyjnych.
• Pozycje do ręcznego przeglądu z dostosowanymi wskazówkami — dla makra wskazówka brzmi: ponownie zaimplementuj je jako funkcję zdefiniowaną przez użytkownika w Pythonie lub jako wbudowany SQL.

Dla EksportujDoBazyWsparcia.yxmd raport pokazuje cztery równoległe strumienie czysto automatycznie przekonwertowane, a makra i procedurę składowaną oznaczone jako praca manualna. Marek wykonuje teraz tę pracę:

• Dla każdego makra CountRecords.yxmc i Log_BDL_LH.yxmc otwiera oryginalny plik .yxmc w Alteryx, widzi, co robi (liczenie wierszy, zapisywanie wpisu do logu) i ponownie buduje tę małą porcję logiki natywnie w DataFlow AI — jako kontrolę jakości, mały SQL transform lub Python UDF.
• Dla IdImportu.yxmc robi to samo — odtwarza logikę identyfikatora importu.
• Dla procedury składowanej plkPrzesylki_Aktualizacja_BDL zachowuje procedurę w bazie danych i konfiguruje potok danych DataFlow, by wywołać ją jako krok Post-SQL, lub przepisuje ją jako wbudowany SQL.
• Mapuje kierowanie świadome środowiska (przepływ pracy zachowywał się inaczej w teście niż na produkcji) na natywne funkcje parametrów i środowiska DataFlow AI, a nie na makro.

Krok 8 — Wdrożenie przekonwertowanego potoku danych

Gdy makra są dokończone, a raport jest czysty, Marek pobiera wynik. Na ekranie raportu klika Pobierz, wybiera format YAML i otrzymuje plik o nazwie EksportujDoBazyWsparcia_converted.yaml.

Ten plik YAML jest nowym potokiem danych — czystym, czytelnym dla człowieka opisem każdego źródła, transformacji i celu:

pipeline:
  name: EksportujDoBazyWsparcia
  description: Converted from Alteryx Designer
  schedule: manual
  sources:
    - id: src_excel_bdl
      type: source
      connector: generic
    - id: src_teradata_bdl
      type: source
      connector: teradata
  transformations:
    - id: filter_active_shipments
      type: transform
      depends_on: [src_teradata_bdl]
    - id: join_bdl_streams
      type: transform
      depends_on: [filter_active_shipments, src_excel_bdl]
  targets:
    - id: sink_mssql_wsparcie
      type: sink
      connector: mssql
      depends_on: [join_bdl_streams]
  quality_checks:
    - type: row_count_check
    - type: null_check
    - type: duplicate_check
    - type: schema_validation

Zauważ kontrole jakości na dole — kontrola liczby wierszy, kontrola wartości pustych, kontrola duplikatów i kontrola schematu — dodane automatycznie jako zabezpieczenia. (Ponieważ niektóre węzły przekonwertowały się poniżej 0,80, dodana jest również kontrola data_reconciliation, wymieniająca oznaczone transformacje, by poddać je dodatkowej kontroli.)

Marek importuje YAML do przestrzeni roboczej DataFlow AI. Potok danych pojawia się w Studio Projektowym jako wizualny diagram — pudełka i strzałki, podobnie jak oryginalne płótno Alteryx, które zna Joanna. Tam ustawia jego prawdziwy harmonogram (raport był kiedyś uruchamiany na żądanie, więc zespół uzgadnia dzienny harmonogram cron), wypełnia połączenia i parametry oraz zapisuje. Zapisanie zatwierdza potok danych w Git — więc po raz pierwszy w historii przepływ pracy Joanny jest kontrolowany wersjami, centralnie przechowywany i działa samodzielnie bez otwierania Alteryx przez kogokolwiek.

Krok 9 — Weryfikacja wyników za pomocą uruchomienia równoległego

Marek nie wyłącza po prostu starego przepływu pracy Alteryx. Program migracji Polkomtela wymaga uruchomienia równoległego.

Przez co najmniej dwa tygodnie obie wersje działają na tych samych danych wejściowych: oryginalny .yxmd Joanny w Alteryx i nowy potok danych DataFlow AI. Uruchomienie Równoległe i Walidacja Parzystości Danych DataFlow AI porównuje oba wyniki w pięciu wymiarach:

1. Dokładna liczba wierszy — ta sama liczba wierszy na wyjściu?
2. Suma kontrolna — odcisk palca MD5/SHA-256 wszystkich danych.
3. Próbkowanie kolumn — losowe 1000 wierszy porównanych kolumna po kolumnie.
4. Liczby wartości pustych — liczby pustych wartości na kolumnę muszą się zgadzać.
5. Czas wykonania — nowy potok danych musi zakończyć się w czasie 2× dłuższym niż stary.

Narzędzie tworzy jasny raport zaliczenia/niezaliczenia. Gdy EksportujDoBazyWsparcia przekroczy próg parzystości wyjścia Polkomtela przez pełne okno, zespół zatwierdza, całkowicie przełącza się na DataFlow AI, a licencja Alteryx dla tego przepływu pracy może w końcu zostać wycofana. Jeśli kiedykolwiek coś wygląda nie tak, powrót to jedna zmiana konfiguracji.

Cała podróż w skrócie

Oto kompletna wyprawa przepływu pracy Alteryx Joanny:

1. Zlokalizuj EksportujDoBazyWsparcia.yxmd — plik .yxmd jest przepływem pracy.
2. Prześlij go do Kreatora Importu Centrum Migracji.
3. Centrum Migracji parsuje plik .yxmd na neutralny wobec narzędzi opis.
4. Silnik Reguł konwertuje każde narzędzie na węzeł DataFlow — przez precyzyjną regułę, mapowanie ogólne lub asystenta AI.
5. Każdy węzeł otrzymuje wskaźnik pewności; bramka wydania 0,85 decyduje o COMPLETED kontra FAILED.
6. Walidacja uruchamia sześć niezależnych kontroli bezpieczeństwa.
7. Marek przegląda raport i dokańcza makra ręcznie, ponownie implementując każde jako Python UDF lub wbudowany SQL.
8. Pobiera przekonwertowany YAML, importuje go do przestrzeni roboczej, ustawia harmonogram i połączenia oraz wdraża go.
9. Dwutygodniowe uruchomienie równoległe dowodzi, że nowy potok danych dopasowuje się do starego wiersz po wierszu, po czym przepływ pracy Alteryx zostaje wycofany.

Pomnóż to przez 50–100 przepływów pracy Alteryx Polkomtela, a firma zamienia rozproszoną kolekcję plików .yxmd uwięzionych na laptopach w kontrolowany, zaplanowany, wersjonowany zestaw potoków danych w chmurze — i wycofuje przy okazji licencję kosztującą 200 000 dolarów rocznie.

Najczęściej zadawane pytania

Dlaczego makr nie można migrować automatycznie? Logika makra żyje wewnątrz jego własnego osobnego pliku .yxmc. Centrum Migracji odczytuje przepływ pracy .yxmd, który tylko odwołuje się do makra po nazwie — nie może zajrzeć do jego wnętrza. Więc makra są flagowane jako praca manualna; inżynier otwiera .yxmc, rozumie je i odbudowuje logikę natywnie.

Moje zadanie pokazało FAILED, ale strumienie przekonwertowały się dobrze — co się stało? FAILED oznacza, że bramka wydania zadziałała — wymaga człowieka. Dla przepływu pracy Alteryx z makrami węzły symboli zastępczych custom_transform automatycznie blokują wydanie bez nadzoru. Dokończ makra, a bramka zostanie zaliczona.

Czy dane przemieszczają się podczas migracji? Nie. Tylko instrukcje przenoszą się z Alteryx do DataFlow AI. Pliki Excel, bazy danych Teradata i MSSQL — wszystkie pozostają dokładnie tam, gdzie były.

Co się dzieje z narzędziami Python lub R w przepływie pracy? Podobnie jak makra, są konwertowane na symbole zastępcze custom_transform i wysyłane do asystenta AI po początkowy szkielet. Inżynier następnie je przegląda i dokańcza — zazwyczaj jako Python UDF w DataFlow AI.

Czy nowy potok danych będzie wyglądał znajomo dla analityka? Tak. W Studio Projektowym przekonwertowany potok danych jest pokazany jako wizualne płótno pudełek i strzałek — ta sama idea przeciągnij-i-połącz, której Joanna używała w Alteryx — ale teraz jest zaplanowany, monitorowany, kontrolowany i wersjonowany.