Koszty i wydajność Dataflow Gen2: testy porównawcze możliwości i koszty CU

Microsoft Fabric Dataflow Gen2 oferuje wiele sposobów efektywnego pobierania, transformacji i ładowania danych. Te metody ułatwiają zrównoważenie wydajności, skalowalności i kosztów.

Ten artykuł jest odniesieniem wydajności i kosztów dla Dataflow Gen2. Porównuje cztery typowe obciążenia — kopiowanie zbiorcze, intensywne przekształcanie danych, zoptymalizowane zapisy do lakehouse oraz łączenie partycjonowanych plików — i raportuje czas wykonywania oraz jednostki pojemności (CU) zużyte przez każde z nich, mierzone na podstawie danych telemetrycznych pojemności. Użyj go do oszacowania kosztów własnych odświeżeń i wyboru funkcji dopasowanej do każdego obciążenia.

Na skalę Dataflow Gen2 znacznie przewyższa Dataflow Gen1 zarówno pod względem szybkości, jak i kosztów – a im większe obciążenie, tym większa różnica. Uruchamiając ten sam skrypt M na tych samych danych i przy tej samej pojemności usługi Fabric, Dataflow Gen2 zakończył wszystkie testy porównawcze opisane w tym artykule od 1,7× do 21× szybciej niż bazowy Dataflow Gen1. We wszystkich scenariuszach, gdzie mierzono zużycie mocy obu generacji, Dataflow Gen2 wykonywał tę pracę szybciej, zużywając 82% do 95% mniej jednostek – więc przyspieszenie nie odbywa się kosztem dodatkowej pojemności. Zyskujesz obie korzyści naraz, bez konieczności przepisywania choćby jednego zapytania.

To, ile zyskasz, zależy od twojego obciążenia, a najważniejszym czynnikiem jest długość trwania zapytań. Standard Compute rozlicza pierwsze 10 minut każdego zapytania z 12 CU za każdą sekundę, a następnie tylko 1,5 CU za każdą kolejną sekundę, więc im dłużej zapytanie trwa, tym niższy jest jego średni koszt na sekundę. Krótki przepływ danych kończy się w tym pierwszym poziomie i nigdy nie osiąga tańszej prędkości, więc różnica między tymi generacjami jest niewielka. Zyski rosną wraz z ilością danych i czasem działania, dlatego benchmarki w tym artykule wykorzystują duże, wysokowolumenowe zbiory danych i długotrwałe odświeżenia.

Dataflow Gen2 również stale staje się tańszy na własnych warunkach: obecne ceny i możliwości zmniejszają zużycie CU o szacunkowo 14% do 84%, w zależności od obciążenia, w porównaniu do tego, ile to samo obciążenie zużywałoby przed 2026 rokiem.

Note

W niniejszym artykule koszty i wydajność są wyrażane w jednostkach pojemności Fabric (CU). Aby dowiedzieć się, jak Dataflow Gen2 konsumuje CU i jak to przekłada się na rozliczenia, zobacz ceny Dataflow Gen2. Te benchmarki i wartości CU odzwierciedlają obecny model cenowy i możliwości rozwiązania Dataflow Gen2, w tym wielopoziomowe ceny usługi Standard Compute, Fast Copy oraz Modern Evaluator. Ponieważ wydajność Dataflow Gen2 i efektywność kosztowa poprawiły się z czasem, dane opublikowane przed 2026 rokiem mogą nie odzwierciedlać obecnych zachowań.

Następujące możliwości ułatwiają optymalizowanie przepływów danych:

Ten artykuł obejmuje typowe przypadki użycia, przykłady z rzeczywistego życia oraz wyniki benchmarkingu, które pomogą Ci wybrać odpowiednią funkcję dla Twojego obciążenia.

Dataflow Gen2 rozlicza każdy silnik osobno według następujących aktualnych stawek:

  • Standardowe obliczenia (zapytania silnika mashup) – 12 CU na każdą sekundę do 10 minut każdego zapytania, a następnie 1,5 CU na każdą dodatkową sekundę.
  • Szybkie kopiowanie (ruch danych) – 1,5 CU na każdą sekundę aktywności kopiowania, mierzone we wszystkich użytych rdzeniach.

Pełny model stawek można znaleźć tutaj: Cennik usługi Dataflow Gen2.

Szybki przewodnik

Dopasuj obciążenie do odpowiedniej możliwości przepływu danych Gen2. Aby zapoznać się z przykładem testu porównawczego każdego z nich, zobacz połączony scenariusz.

Zdolność Użyj go, gdy... Kluczowa korzyść Test porównawczy
Szybkie kopiowanie Potrzebujesz bezpośredniej kopii o wysokiej przepływności z obsługiwanego źródła bez przekształceń. Szybsze wczytywanie przy niższym koszcie przetwarzania. Scenariusz 1. Kopiowanie danych
Nowoczesny ewaluator Kształtujesz dane z niezginalnych lub częściowo składanych łączników (filtry, wyprowadzenia, czyszczenie). Szybsze wykonywanie bez zmieniania logiki. Scenariusz 2. Intensywne kształtowanie danych
Zoptymalizowana kopia do Lakehouse Włączyłeś etapowanie zapytania, które zapisuje się do miejsca docelowego przy jeziorze. Maksymalizuje przepustowość podczas zapisu danych etapowanych do domku nad jeziorem. Scenariusz 3: Zoptymalizowane kopiowanie do Lakehouse
Partycjonowane obliczenia (Wersja zapoznawcza) Przekształcasz duże, podzielone na partycje lub wiele plików zestawy danych, które mogą być uruchamiane równolegle. Połącz z nowoczesnym ewaluatorem, jeśli jest obsługiwany. Równoległe wykonywanie w poprzek partycji. Scenariusz 4: Połączenie plików

Note

Aby uzyskać informacje na temat oceny zapytań i składania zapytań, zobacz Podstawy składania zapytań.

Podsumowanie wyników testu porównawczego

Większość scenariuszy opisanych w tym artykule korzysta z danych Trip Data Komisji Taksówek i Limuzyn Nowego Jorku (TLC) – TLC Trip Record Data : miliardy rekordów przejazdów taksówek przechowywanych jako pliki Parquet w ADLS Gen2, obejmujące lata 2021–2025 (do sierpnia). Scenariusz 3 wykorzystuje tabelę lakehouse w usłudze Fabric zawierającą około 113 milionów rekordów przejazdów taksówkami w Nowym Jorku, obejmujących okres od 2017 roku do połowy 2018 roku. Miejsce docelowe to Fabric lakehouse lub magazyn, w zależności od scenariusza.

Poniższa tabela zawiera podsumowanie wyników testu porównawczego we wszystkich scenariuszach. Każdy scenariusz zawiera również punkt odniesienia przepływu danych Gen1 do porównania.

Scenario Do czego służy Włączono funkcję Czas wykonania Gen2 Przyspieszenie względem bazowego poziomu 1. generacji Gen1 CU Gen2 CU Redukcja CU w Gen2
Scenariusz 1. Kopiowanie danych Ładowanie masowo pięciu skonsolidowanych plików Parquet z ADLS Gen2 do jeziornego domu bez transformacji. Szybkie kopiowanie 00:09:08 11× szybciej 84,411 14,593 83%
Scenariusz 2. Intensywne kształtowanie danych Zastosuj niezmienne przekształcenia (filtry, pochodne, czyszczenie) do pojedynczego dużego pliku Parquet załadowanego do lakehouse. Nowoczesny ewaluator 00:46:29 1,7× szybciej 56,855 10,485 82%
Scenariusz 3: Zoptymalizowane kopiowanie do Lakehouse Przekształć tabelę danych taksówek NYC zawierającą 113 mln wierszy z lakehouse w usłudze Fabric i zapisz wynik w tabeli lakehouse przy użyciu przyspieszonej ścieżki kopiowania. Ten benchmark wykorzystuje funkcje Optimized copy to Lakehouse i V-Order. Zoptymalizowana kopia do Lakehouse 00:03:34 15× szybciej 50,788 2,391 95%
Scenariusz 4: Połączenie plików Połącz i przekształć 56 partycjonowanych plików Parquet równolegle i załaduj je do magazynu. Partycjonowane obliczenia (Podgląd) 00:04:48 21× szybciej Nie zmierzono Nie zmierzono Nie zmierzono

Wykres porównawczy przedstawiający czas wykonywania i względną szybkość dla czterech scenariuszy porównawczych w tabeli podsumowania.

Poniższy wykres porównuje te same scenariusze pod względem zużycia pojemności, a nie czasu realizacji.

Wykres porównawczy przedstawiający zużycie sekund CU przez wersję bazową Dataflow Gen1 w porównaniu z najlepszą konfiguracją Dataflow Gen2 dla każdego scenariusza testowego.

Aby uzyskać szczegółowe informacje, konfiguracje zestawów danych i wzorce projektowe dla każdej możliwości, zobacz poniższe sekcje scenariuszy.

Note

Wszystkie scenariusze w tym artykule mają włączony Modern Evaluator i wyłączony V-Order , chyba że wyraźnie zaznaczono inaczej. Kolumny Gen1 CU i Gen2 CU podają wartości w sekundach jednostki pojemności. Redukcja CU w kolumnie Gen2 to spadek w sekundach CU od bazowej konfiguracji Dataflow Gen1 do najlepszej konfiguracji Dataflow Gen2, obliczanej jako (Gen1 CU − Gen2 CU) ÷ Gen1 CU.

Jak mierzyliśmy te punkty odniesienia

Każdy scenariusz uruchamia ten sam skrypt M dwukrotnie: raz na Dataflow Gen1, aby ustanowić bazę, oraz raz na Dataflow Gen2 z włączoną możliwością testowaną.

Każdy przebieg opisany w tym artykule ma te same warunki testowe:

  • Wszystkie scenariusze i obie generacje działały na tej samej pojemności Fabric, więc żaden wynik nie odzwierciedla innego rozmiaru pojemności ani SKU.
  • Nie było żadnej bramy danych. Każde połączenie przechodziło bezpośrednio z usługi Fabric do chmurowego źródła danych.
  • Każdy scenariusz używał tych samych danych źródłowych i tego samego skryptu M zarówno w uruchomieniach Dataflow Gen1, jak i Dataflow Gen2.

Zgłoszone dane oznaczają następujące:

  • Czas trwania to całkowity czas odświeżania zgłaszany dla uruchomienia przepływu danych.
  • Zużycie CU to liczba sekund jednostek pojemności naliczonych dla tego uruchomienia, odczytana z aplikacji Microsoft Fabric Capacity Metrics. Ponieważ Dataflow Gen2 rozlicza każdy silnik osobno, suma scenariusza to suma wszystkich silników uruchomionych podczas odświeżania, a wartości CU są zaokrąglane do najbliższej całej sekundy CU. Pełny model stawek można znaleźć tutaj: Cennik usługi Dataflow Gen2.

Porównując te dwa pokolenia, miej na uwadze te różnice architektoniczne:

  • Dataflow Gen1 wykorzystuje zasadniczo inną architekturę niż Dataflow Gen2 i nie obsługuje funkcji takich jak Fast Copy, Modern Evaluator, Optimized copy to Lakehouse czy Partitioned Compute.
  • Dataflow Gen1 może ładować dane tylko jako pliki CSV, podczas gdy Dataflow Gen2 ładuje dane jako pliki Parquet w takich sytuacjach.

Note

Te wartości zostały zarejestrowane w naszym własnym środowisku testowym w sierpniu 2026 roku i dotyczą tylko tych konkretnych przebiegów. Twoje wyniki różnią się w zależności od ilości danych, wielkości pojemności i konfiguracji. Aby zmierzyć własne obciążenia, zobacz Obliczanie szacunkowych kosztów z wykorzystaniem aplikacji Fabric Metrics oraz historię odświeżania przepływu danych.

Scenariusz 1. Kopiowanie danych

Zespół analityki taksówek w Nowym Jorku musi załadować miliony surowych zapisów podróży Parquet z ADLS Gen2 do domku nad jeziorem Fabric. Zespół nie potrzebuje żadnych przekształceń, tylko bezpośredniej kopii do obsługi analizy podrzędnej.

Challenges

  • Przenieś duże ilości danych Parquet szybko do domku nad jeziorem.
  • Zmniejsz czas przetwarzania dla codziennych odświeżeń.
  • Minimalizuj koszt obliczeń dla prostych obciążeń wyodrębniania (EL).

Dataset

Zroczne scalone pliki Parquet NYC Yellow Taxi, pięć skonsolidowanych partycji (2021–sierpień 2025).

Rozwiązanie

Zespół umożliwia szybkie kopiowanie w Dataflow Gen2. Funkcja Fast Copy optymalizuje ścieżki przesyłania danych i pisanie równoległe dla obsługiwanych łączników.

Design

Zrzut ekranu przedstawiający projekt przepływu danych na potrzeby szybkiego kopiowania przedstawiający ustawienia zapytania.

To zapytanie łączy pliki Parquet z pięciu lat z podziałem na lata i ładuje wynik do lakehouse.

Rozważania dotyczące szybkiego kopiowania

  • Obsługuje formaty plików.csv i parquet .
  • Obsługuje maksymalnie 1 mln wierszy na tabelę na każde uruchomienie dla usługi Azure SQL Database.
  • Najlepiej nadaje się do workflowów extract-load (EL) przed transformacjami.

Results

Wykres porównujący bazowy poziom Dataflow Gen1 z najlepszą konfiguracją Dataflow Gen2 dla Scenariusza 1, pokazując czas działania i zużycie CU jako procent poziomu wyjściowego Gen1.

Po włączeniu Fast Copy, Dataflow Gen2 pobiera ten zbiór danych około 11× szybciej niż bazowy zbiór Dataflow Gen1 (00:09:08 vs. 01:38:59), jednocześnie zmniejszając zużycie danych. Bez Fast Copy Dataflow Gen2 jest już około 2,8× szybszy niż Gen1 przy tym samym obciążeniu.

Konfiguracja Czas wykonywania (hh:mm:ss) Porównanie z gen1 Wykorzystane CU
Punkt odniesienia przepływu danych Gen1 01:38:59 — 84,411
Przepływ danych Gen2 bez szybkiego kopiowania 00:35:25 2,8× szybciej Nie zmierzono
Przepływ danych Gen2 z szybkim kopiowaniem 00:09:08 11× szybciej 14,593

Po włączeniu Fast Copy – najbardziej optymalnej konfiguracji Dataflow Gen2 dla tego scenariusza – szybkie kopiowanie pięciu skonsolidowanych plików Parquet do lakehouse w Scenariuszu 1 zużywa 14 593 sekund cu. Poniższa tabela rozkłada tę sumę według operacji:

Operation Silnik (metr) Sekundy CU
Przenoszenie danych Szybkie kopiowanie 8,280
Uruchamianie zapytań Standardowe obliczenia 6,313
Łącznie 14,593

Ruch danych Fast Copy jest rozliczany w wysokości 1,5 CU za każdą sekundę aktywności kopiowania, mierzony jako łączny czas na wszystkich rdzeniach, na których kopia działa. Dataflow Gen2 automatycznie dostosowuje liczbę rdzeni używanych w każdym scenariuszu Fast Copy, więc kopiowanie, które kończy się szybko w czasie rzeczywistym, może nadal obejmować wiele sekund pracy rdzeni. Pozostały czas zapytania jest rozliczany w Standard Compute (12 CU na sekundę do 10 minut, a następnie 1,5 CU na każdą kolejną sekundę). Pełny model stawek można znaleźć w artykule Cennik Dataflow Gen2.

Podjąć klucza

  • Włączenie funkcji Fast Copy skróciło 99-minutowe pozyskiwanie danych do około dziewięciu minut, co oznacza dziesięciokrotną poprawę w przypadku tego samego zbioru danych i skryptu M.
  • Dataflow Gen2 również zużywał 83% mniejszą pojemność niż Dataflow Gen1 do tej samej pracy (14 593 wobec 84 411 sekund cu), więc przyspieszenie nie wiązało się z dodatkowym obciążeniem obliczeniowym.
  • Przyspieszenie pochodzi z natywnego, równoległego ruchu danych, który omija silnik mashup, więc dotyczy tylko kroków ekstrakcji-ładowania spełniających wymagania Fast Copy. Każda transformacja, która łamie optymalizację składania, wraca do standardowego mechanizmu i traci zyski.
  • W przypadku obsługiwanych źródeł należy traktować funkcję szybkiej kopii jako domyślną dla pozyskiwania i rezerwując mocniejsze aparaty przekształcania (omówione w następnych scenariuszach) w celu wykonania kroków, które faktycznie przekształcają dane.

Scenariusz 2: Intensywne przekształcanie danych

Po pobraniu danych zespół stosuje filtrowanie, zastępowanie wartości null oraz mapowanie kodów przed załadowaniem danych do lakehouse. Te przekształcenia nie są w pełni przekształcone z powrotem do formatu Parquet i działają wolno w pamięci.

Challenges

  • Zwiększ szybkość transformacji dla zapytań półskładanych lub nieskładanych.
  • Utrzymanie tworzenia Power Query bez potrzeby kodowania.
  • Zmniejsz całkowity czas odświeżania i koszt.

Dataset

Wszystkie pliki Parquet za lata 2021–sierpień 2025 zostały połączone w jeden skonsolidowany plik.

Rozwiązanie

Zespół uruchamia Modern Evaluator, silnik wykonawczy o wysokiej wydajności, zaprojektowany do wydajnej transformacji, szczególnie w przypadku łączników, takich jak ADLS Gen2 i SharePoint.

Design

Zrzut ekranu przedstawiający projekt przepływu danych dla nowoczesnego ewaluatora przedstawiający ustawienia zapytania.

To zapytanie pozyskuje dane ze skonsolidowanego pliku Parquet, filtruje kolumny trip_distance i fare_amount w celu zachowania wartości powyżej 0, w kolumnie passenger_count zastępuje wartości null wartością 1, oraz tworzy nową kolumnę payment_method poprzez mapowanie typów płatności przed załadowaniem danych do lakehouse.

Współczesne rozważania dotyczące ewaluatorów

  • Oczekiwane czasy odświeżania mogą być znacznie szybsze (różnią się w zależności od zestawu danych i przekształceń).
  • Zoptymalizowane pod kątem dużych woluminów (miliony wierszy).
  • Korzystne w przypadku zapytań nie-składanych.
  • Faster zapisuje do miejsc takich jak domek nad jeziorem.

Results

Wykres porównujący bazowy poziom Dataflow Gen1 z najlepszą konfiguracją Dataflow Gen2 dla Scenariusza 2, pokazując czas wykonania i zużycie CU jako procent poziomu wyjściowego Gen1.

Po włączeniu Modern Evaluator, Dataflow Gen2 wykonuje to zadanie shaping około 1,7× szybciej niż bazowy system Dataflow Gen1 (00:46:29 vs. 01:19:56), zachowując jednocześnie doświadczenie Power Query no-code. Bez Modern Evaluator ten sam zakres obciążenia jest tylko około 1,2× szybszy niż w Gen1 (01:08:37 vs. 01:19:56).

Konfiguracja Czas wykonywania (hh:mm:ss) Porównanie z gen1 Wykorzystane CU
Punkt odniesienia przepływu danych Gen1 01:19:56 — 56,855
Przepływ danych Gen2 bez nowoczesnego ewaluatora 01:08:37 1.2× szybciej Nie zmierzono
Przepływ danych Gen2 z nowoczesnym ewaluatorem 00:46:29 1,7× szybciej 10,485

Po włączeniu Modern Evaluator — najbardziej optymalnej konfiguracji Dataflow Gen2 dla tego scenariusza — przekształcenie pojedynczego dużego pliku Parquet do lakehouse przez Modern Evaluator w scenariuszu 2 zużywa 10 485 sekund CU. Poniższa tabela rozkłada tę sumę według operacji:

Operation Silnik (metr) Sekundy CU
Uruchamianie zapytań Standardowe obliczenia 10,485
Łącznie 10,485

Praca jest w całości realizowana na standardowym komputerze, który jest rozliczany na dwóch poziomach: 12 CU za każdą sekundę do 10 minut, a następnie 1,5 CU za każdą dodatkową sekundę. Poniższa tabela pokazuje, jak rozliczony czas trwania i całkowita suma CU dzielą się między te poziomy:

Poziom rozliczeniowy Rozliczany czas trwania Rate Sekundy CU
Pierwsze 10 minut 00:10:00 (600 sekund) 12 CU na sekundę 7 200
Ponad 10 minut 00:36:29 (2 189,8 sekundy) 1,5 CU za każdą sekundę 3,284.7
Łącznie 00:46:29 (2 789,8 sekundy) 10,484.7

Ta tabela pokazuje zmierzoną wartość całkowitą z dokładnością do jednego miejsca po przecinku, dzięki czemu progi sumują się dokładnie; w pozostałej części artykułu wartość ta jest zaokrąglana do 10 485 sekund CU.

Podział pokazuje, jak bardzo pierwszy poziom dominuje w kosztach: pierwsze 10 minut to tylko około 22% całkowitego czasu trwania, ale odpowiada za około 69% sekund CU, ponieważ każda z tych sekund kosztuje osiem razy więcej niż sekunda na drugim poziomie. Wszystko, co przekroczy 10 minut – czyli większość długiego cyklu kształtowania – jest rozliczane po znacznie niższym kursie 1,5 cu. Modern Evaluator obniża rachunek jeszcze bardziej, skracając sam czas trwania rozliczenia, a nie zmieniając stawkę. Pełny model stawek można znaleźć w artykule Cennik Dataflow Gen2.

Podjąć klucza

  • Bez Modern Evaluator, Dataflow Gen2 był tylko około 1,2× szybszy niż bazowy poziom Dataflow Gen1 dla tego kształtującego obciążenia. Włączenie Modern Evaluator poprawiło wydajność do około 1,7× szybciej niż Gen1, na identycznym skripcie M i zbiorze danych.
  • Oszczędność mocy obliczeniowej jest większa niż oszczędność czasu: Dataflow Gen2 zakończył działanie 1,7 raza szybciej, zużywając o 82% mniej mocy obliczeniowej niż Dataflow Gen1 (10 485 wobec 56 855 sekund CU).
  • Ten wzrost wydajności wynika z bardziej efektywnej ścieżki wykonania zapytań nieskładanych i półskładanych. Power Query tradycyjnie poświęca najwięcej czasu tym zapytaniam, zwłaszcza gdy używasz konektorów takich jak ADLS Gen2 i SharePoint. Zwiększanie skali przy użyciu woluminu wiersza i kształtowania złożoności.
  • Użyj Modern Evaluator jako domyślnego dla przepływów wymagających intensywnego kształtowania, gdzie zapytania nie wracają całkowicie do źródła. Im większy zbiór danych i im więcej transformacji zastosujesz w silniku, tym większy wpływ powinieneś się spodziewać.

Scenariusz 3: Zoptymalizowane kopiowanie do Lakehouse

Zespół analityki taksówek w Nowym Jorku przekształca dużą tabelę i zapisuje wynik do domku nad jeziorem Fabric. Zapisywanie tego woluminu do miejsca docelowego to najwolniejsza część odświeżania, więc zespół chce przyspieszyć zapis bez zmiany logiki transformacji.

Challenges

  • Napisz duży, przekształcony wynik do miejsca przy domku nad jeziorem szybko.
  • Zapobiegaj temu, by zapis docelowy stał się wąskim gardłem odświeżania.
  • Zachowaj doświadczenie Power Query bez kodu oraz istniejącą logikę transformacji.

Dataset

Tabela lakehouse w usłudze Fabric zawierająca około 113 milionów rekordów przejazdów taksówkami w Nowym Jorku z okresu od 2017 roku do połowy 2018 roku.

Rozwiązanie

Zespół włącza Włącz staging i Zoptymalizowane kopiowanie do Lakehouse dla pojedynczego zapytania, które zapisuje dane w obiekcie docelowym Lakehouse. Zoptymalizowana kopia do Lakehouse przenosi etapowany wynik do domku nad jeziorem na przyspieszonej ścieżce.

Design

Testowy przepływ danych wykorzystuje pojedyncze zapytanie z włączoną opcją Enable staging oraz z miejscem docelowym typu lakehouse, które korzysta z V-Order. Zapytanie odczytuje około 113 milionów wierszy tabeli taksówek w Nowej Jorce z domku nad jeziorem Fabric, sortuje wiersze według daty i godziny odbioru oraz dodaje dwie kolumny pochodne – początek miesiąca odbioru oraz sumę podatku MTA i dodatku za poprawę. Ponieważ włączono staging, Zoptymalizowana kopia do Lakehouse zapisuje przekształcony wynik w lokalizacji docelowej Lakehouse przy użyciu przyspieszonej ścieżki, co przekłada się na krótki czas wykonywania.

Zoptymalizowane kopiowanie do Lakehouse – rozważania

  • Wymaga włączenia opcji Enable staging dla zapytania oraz miejsca docelowego Lakehouse. Aby uzyskać więcej informacji, zobacz Opcje danych etapowych dla usługi Dataflow Gen2.
  • Przyspiesza zapis do domku nad jeziorem bez zmiany logiki transformacji.
  • Połącz go z V-Order na miejscu docelowym, aby zoptymalizować wyniki do dalszej analizy.

Results

Wykres porównujący bazowy poziom Dataflow Gen1 z najlepszą konfiguracją Dataflow Gen2 dla Scenariusza 3, pokazując czas działania i zużycie CU jako procent poziomu wyjściowego Gen1.

Gdy włączysz zoptymalizowaną kopię do Lakehouse, Dataflow Gen2 kończy to odświeżanie około 15× szybciej niż bazowy poziom Dataflow Gen1 (00:03:34 vs. 00:53:20) bez zmiany logiki transformacji. Bez niej ten sam etapowy przepływ danych jest około 3,6× szybszy niż Gen1.

Konfiguracja Czas wykonywania (hh:mm:ss) Porównanie z gen1 Wykorzystane CU
Punkt odniesienia przepływu danych Gen1 00:53:20 — 50,788
Dataflow Gen2 z przemieszczaniem etapowym + V-Order (bez zoptymalizowanego kopiowania do Lakehouse) 00:14:45 3,6× szybciej Nie zmierzono
Dataflow Gen2 z obszarem przejściowym + Zoptymalizowane kopiowanie do Lakehouse + V-Order 00:03:34 15× szybciej 2,391

Po włączeniu obszaru przejściowego, opcji Zoptymalizowane kopiowanie do usługi Lakehouse oraz V-Order — optymalnej konfiguracji Dataflow Gen2 dla tego scenariusza — odświeżenie 113‑milionowej tabeli taksówek NYC do tabeli w usłudze Lakehouse w scenariuszu 3 kończy się w czasie 00:03:34 i zużywa 2 391 CU seconds. Poniższa tabela rozkłada tę sumę według operacji:

Operation Silnik (metr) Sekundy CU
Uruchamianie zapytań Standardowe obliczenia 2,391
Łącznie 2,391

Praca jest rozliczana w całości na standardowym komputerze (12 CU za każdą sekundę do 10 minut, a następnie 1,5 CU za każdą dodatkową sekundę). Zoptymalizowana kopia domku nad jeziorem działa przez silnik mashup, więc nie ma osobnego miernika. Pełny model stawek można znaleźć w artykule Cennik Dataflow Gen2.

Podjąć klucza

  • Zoptymalizowane kopiowanie do usługi Lakehouse przyspiesza zapisywanie przekształconego wyniku do docelowej usługi Lakehouse, skracając czas odświeżania z 00:14:45 (bez tej funkcji) do 00:03:34 — czyli około 4 razy szybciej niż ten sam przepływ danych bez tej funkcji i około 15 razy szybciej niż punkt odniesienia Dataflow Gen1 (00:53:20).
  • Ten scenariusz przyniósł największą oszczędność pojemności w porównaniu z Dataflow Gen1 w tym artykule: Dataflow Gen2 zużywał 95% mniej niż Dataflow Gen1 (2 391 wobec 50 788 sekund cu).
  • Wymaga włączenia opcji Enable staging w zapytaniu oraz miejsca docelowego typu Lakehouse i nie zmienia logiki transformacji.
  • Ten scenariusz jawnie wykorzystuje V-Order w wyjściu docelowym.
  • Używaj funkcji Zoptymalizowane kopiowanie do usługi Lakehouse za każdym razem, gdy zapisujesz dane przejściowe w lokalizacji docelowej usługi Lakehouse, a czas zapisu stanowi największą część czasu odświeżania.

Scenariusz 4: Połączenie plików

Note

Partitioned Compute jest obecnie w wersji podglądowej i dostępny tylko w Dataflow Gen2 z CI/CD. Funkcja ta nadal jest ulepszana, więc jej zachowanie, wspierane transformacje i wydajność mogą się zmieniać przed ogólną dostępnością. Traktuj wyniki w tym scenariuszu jako odzwierciedlenie stanu wersji zapoznawczej na dany moment.

Zespół musi teraz agregować i wzbogacać dane podróży w setkach plików Parquet (partycje miesięczne). Przekształcenia obejmują obliczanie procentów napiwków w zestawie danych.

Challenges

  • Należy przetworzyć setki dużych plików.
  • Przekształcenia wymagają grupowania, agregacji i wzbogacania w poprzek partycji.
  • Wykonywanie sekwencyjne staje się wąskim gardłem.

Dataset

Pięćdziesiąt sześć akt Parquet (2021–sierpień 2025).

Rozwiązanie

Zespół udostępnia funkcję Partitioned Compute (wersja zapoznawcza), umożliwiającą równoległe przetwarzanie w partycjach i wydajne scalanie wyników.

Design

Zrzut ekranu przedstawiający projekt przepływu danych dla partycjonowanego obliczenia z ustawieniami zapytania.

To zapytanie łączy 56 plików Parquet i tworzy nową, niestandardową kolumnę dla procentu napiwków "Tip Pctg" na pliku Transform Sample przed załadowaniem danych do magazynu.

Zagadnienia dotyczące partycjonowanych zasobów obliczeniowych

  • Obecnie w wersji zapoznawczej i dostępna tylko w Dataflow Gen2 z CI/CD; ta funkcja jest nadal rozwijana.
  • Użyj go, gdy źródło nie obsługuje składania.
  • Zapewnia najlepszą wydajność podczas ładowania danych do przechowalni lub magazynu.
  • Użyj pliku Sample transform z plików Combine , aby zapewnić spójną logikę transformacji.
  • Obsługuje podzbiór przekształceń; wydajność różni się.

Results

Wykres porównujący bazowy poziom Dataflow Gen1 z najlepszą konfiguracją Dataflow Gen2 dla Scenariusza 4, pokazując czas wykonania jako procent poziomu wyjściowego Gen1.

Partitioned Compute zapewnia około 21× szybszą wydajność niż bazowy Dataflow Gen1 (00:04:48 vs. 01:40:57) na dużych, partycjonowanych, wieloplikowych zbiorach danych.

Konfiguracja Czas wykonywania (hh:mm:ss) Porównanie z gen1 Wykorzystane CU
Punkt odniesienia przepływu danych Gen1 01:40:57 — Nie zmierzono
Przepływ danych Gen2 z partycjonowaną usługą obliczeniową 00:04:48 21× szybciej Nie zmierzono

Partitioned Compute celuje w czas zegara ściennego, a nie koszt. Uruchamia partycje równolegle, więc odświeżanie kończy się szybciej, ale ta równoległość rozkłada pracę na większą liczbę zasobów obliczeniowych, zamiast ograniczać ich wykorzystanie, więc koszt jest zazwyczaj podobny do kosztu tego samego obciążenia bez tej funkcji lub wyższy. Zużycie CU nie zostało zmierzone w tym scenariuszu, więc ten artykuł podaje jedynie czas działania.

Podjąć klucza

  • Środowisko obliczeniowe z partycjonowaniem dostarczyło 21× przyspieszenia w odniesieniu do Dataflow Gen1 i zakończyło się w mniej niż pięć minut. Ponieważ funkcja jest w wersji podglądowej i nadal jest ulepszana, można się spodziewać, że te liczby będą się rozwijać.
  • Traktuj Partitioned Compute jako sposób na szybsze zakończenie, a nie na mniejsze wydatki. Równoległość skraca czas zegara ściennego poprzez jednoczesne uruchamianie partycji, więc koszt jest zazwyczaj podobny lub wyższy niż przy tym samym obciążeniu bez niego.
  • Zysk pochodzi z równoległego przetwarzania każdej partycji i scalania wyników, co jest najefektywniejsze w przypadku źródeł wieloplikowych lub partycjonowanych, gdzie funkcja składania jest niedostępna, a ewaluacja sekwencyjna stanowi wąskie gardło.
  • Użyj wzorca pliku Sample transform z plików Combine, aby logika transformacji była konsekwentnie stosowana na każdą partycję. Partitioned Compute obecnie obsługuje tylko część transformacji, więc zanim zaczniesz na nim polegać, upewnij się, że kroki przekształcania danych są z nim zgodne, i sprawdzaj to ponownie w miarę rozwoju wersji zapoznawczej.
  • W przypadku dużego wolumenu partycjonowanego pozyskiwania danych do etapu przejściowego lub magazynu, ustaw Partitioned Compute jako wartość domyślną i połącz je z Modern Evaluator, jeśli to możliwe. Ponieważ jest to nadal wersja zapoznawcza, przed zastosowaniem go do odświeżeń produkcyjnych zweryfikuj je w odniesieniu do własnego obciążenia roboczego.

Koszty w czasie (wtedy vs. teraz)

Dataflow Gen2 stał się z czasem bardziej opłacalny w uruchamianiu. Ta sama logika, na tych samych danych, zużywa dziś mniej CU niż kiedyś, bez potrzeby wprowadzania jakichkolwiek zmian w zapytaniach.

W tym porównaniu oznacza to takie samo obciążenie pracą przy cenach i możliwościach dostępnych przed 2026 rokiem. Teraz oznacza to samo obciążenie uruchamiane dzisiaj z najlepszymi dostępnymi ustawieniami (takimi jak Modern Evaluator i Fast Copy). Obie kolumny korzystają z najlepszej ogólnie dostępnej konfiguracji z danego okresu. Obecne wartości są mierzone na podstawie telemetrii przepustowości. Te dane to szacunki tego, ile obciążenie pochłonęłoby w tamtym czasie, ponieważ wcześniejszych warunków obsługi nie da się dziś odtworzyć.

Scenario Zdolność Szacowany CU przed 2026 rokiem (najlepszy GA) CU teraz (najlepsza GA) Szacowana redukcja
Scenariusz 1. Kopiowanie danych Szybkie kopiowanie 17,055 14,593 14%
Scenariusz 2. Intensywne kształtowanie danych Nowoczesny ewaluator 66,164 10,485 84%
Scenariusz 3: Zoptymalizowane kopiowanie do Lakehouse Zoptymalizowana kopia do Lakehouse 14,173 2,391 83%

Wykres porównawczy pokazujący szacowane sekundy CU przed 2026 rokiem w porównaniu z zmierzonymi sekundami CU obecnymi dla każdego scenariusza w tabeli ówczesnych i obecnych.

Na przykład zadanie z intensywnym kształtowaniem w scenariuszu 2 zużyłoby szacunkowo 66 164 sekund CU przed rokiem 2026, a obecnie zużywa 10 485 sekund CU. Ta zmiana to redukcja o 84%, z identyczną logiką i bez konieczności wprowadzania zmian. Dwie ulepszenia kumulują się, tworząc ten efekt. Po pierwsze, ceny Standard Compute zostały podzielone na progi: zamiast stałej stawki 16 CU za każdą sekundę całego przebiegu, tylko za pierwsze 10 minut naliczane jest 12 CU za każdą sekundę, a za każdą kolejną sekundę — tylko 1,5 CU, więc długi ogon obciążenia związanego z przekształcaniem danych kosztuje teraz ułamek tego, co wcześniej. Po drugie, Modern Evaluator – dostępny od kwietnia 2026 – skraca sam czas rozliczania, więc na każdym poziomie jest mniej sekund na rozliczenie. To, że krótszy przebieg jest rozliczany według znacznie niższej stawki długiego ogona, sprawia, że zużycie CU spada tak gwałtownie, i dlatego zestawienie Modern Evaluator z obecnym warstwowym modelem cenowym ma tak duże znaczenie w przypadku przepływów danych z intensywnym przekształcaniem danych.

Pozyskiwanie danych przez funkcję Fast Copy w scenariuszu 1 zużyłoby szacunkowo 17 055 sekund CU przed 2026 r., a obecnie zużywa 14 593 sekundy CU. Ta zmiana oznacza obniżkę o 14%, wynikającą ze spadku stawki Standard Compute z jednolitej stawki 16 CU za każdą sekundę do 12 CU za każdą sekundę przez okres do 10 minut; składnik Fast Copy związany z przenoszeniem danych pozostaje bez zmian. Odświeżenie zoptymalizowanego kopiowania do usługi Lakehouse w scenariuszu 3 pochłonęłoby szacunkowo 14 173 sekund CU przed rokiem 2026, a obecnie pochłania 2 391 sekund CU. Ta zmiana to redukcja o 83%. Każde porównanie wykorzystuje ten sam zakres pracy z najlepszymi dostępnymi ustawieniami w danym okresie.

Note

To porównanie stanu wcześniejszego z obecnym nie obejmuje funkcjonalności Partitioned Compute, ponieważ zużycie CU nie było mierzone w tym scenariuszu, a ta funkcjonalność jest nadal w fazie wersji zapoznawczej.

Często zadawane pytania

Jak rozlicza się Dataflow Gen2?

Dataflow Gen2 rozlicza każdy silnik osobno w jednostkach pojemności Fabric (CU). Standard Compute (silnik Mashup) nalicza opłatę w wysokości 12 CU za każdą sekundę przez pierwsze 10 minut każdego zapytania, a następnie 1,5 CU za każdą dodatkową sekundę. Fast Copy (przesyłanie danych) nalicza 1,5 CU za każdą sekundę operacji kopiowania, mierzonej łącznie dla wszystkich rdzeni, na których działa operacja kopiowania. Płacisz tylko za moc obliczeniową, którą rzeczywiście wykorzystuje dane zapytanie, bez stałej opłaty za każde odświeżenie i bez opłat za czas bezczynności. Pełny model stawek można znaleźć tutaj: Cennik usługi Dataflow Gen2.

Czy cenowanie Dataflow Gen2 jest elastyczne?

Yes. W przypadku Dataflow Gen2 opłaty są naliczane wyłącznie za moc obliczeniową rzeczywiście wykorzystywaną przez każde zapytanie, mierzoną w jednostkach Fabric Capacity Units (CU). Nie ma stałej opłaty za każde odświeżenie, nie ma opłat za czas bezczynności ani bezpośrednich opłat w czasie tworzenia za funkcjonalność natywną. W testach referencyjnych przedstawionych w tym artykule pełne odświeżenie zużyło 14 593 sekund CU na potrzeby pozyskiwania danych metodą Fast Copy oraz 10 485 sekund CU w przypadku dużego obciążenia związanego z przekształcaniem danych.

Jak mogę oszacować koszt Dataflow Gen2 przed uruchomieniem pełnego obciążenia?

Uruchom małe, reprezentatywne odświeżenie i zmierz, ile zużywa, zamiast budować pełne rozwiązanie i dopiero potem odkrywać koszty. Aby oszacować koszt w ten sposób:

  • Buduj przepływ danych na przykładzie próbki lub pojedynczej partycji źródła zamiast całego zbioru danych.
  • Odśwież go raz, a następnie odczytaj w aplikacji Microsoft Fabric Capacity Metrics liczbę sekund CU, które zużył.
  • Sprawdź historię odświeżania przepływu danych, aby zobaczyć, które silniki były używane, ponieważ Standard Compute i Fast Copy są rozliczane osobno.
  • Podziel zmierzone sekundy CU przez przetworzone wiersze lub GB, aby uzyskać szybkość na jednostkę, a następnie pomnóż przez cały wolumen danych.

Note

Dataflow Gen2 jest zoptymalizowany pod kątem obciążeń na dużą skalę, więc jego korzyści wydajnościowe i efektywne są najbardziej widoczne na dużych, rzeczywistych zbiorach danych. Mała lub syntetyczna próbka może nie odzwierciedlać w pełni korzyści, a stawka jednostkowa ekstrapolowana na podstawie bardzo małej próbki może zawyżać koszt pełnego uruchomienia. Waliduj z użyciem reprezentatywnej ilości danych, zawsze gdy to możliwe.

Pełną metodę można znaleźć w artykule Obliczanie szacowanych kosztów z użyciem aplikacji Fabric Metrics oraz historii odświeżania przepływu danych.

Jak długo trwa odświeżanie Dataflow Gen2?

To zależy od ilości danych i od zastosowanych transformacji. W testach porównawczych opisanych w tym artykule czasy odświeżania Dataflow Gen2 wynosiły od 00:03:34 dla zoptymalizowanej kopii tabeli liczącej 113 milionów wierszy do magazynu lakehouse do 00:46:29 dla intensywnego obciążenia związanego z przekształcaniem danych na dużym skonsolidowanym pliku Parquet. Masowa kopia pięciu skonsolidowanych plików Parquet zakończyła się w 00:09:08 za pomocą Fast Copy, a połączenie 56 plików podzielonych na particje zakończyło się w 00:04:48 w trybie Partitioned Compute (Podgląd). Pełne czasy dla poszczególnych scenariuszy można znaleźć w podsumowaniu wyników benchmarków.

Która funkcja Dataflow Gen2 najbardziej zmniejsza koszty?

To zależy od obciążenia, ponieważ każda funkcja celuje w inne wąskie gardło: Fast Copy do pobierania danych bez transformacji, Modern Evaluator do nieskładanego kształtowania danych, Optimized copy do Lakehouse do przyspieszania zapisów do miejsca docelowego Lakehouse oraz Partitioned Compute (Preview) dla dużych zbiorów danych z wieloma plikami. W porównaniu z wartością bazową Dataflow Gen1 zoptymalizowane kopiowanie do Lakehouse przyniosło w tych testach porównawczych największe oszczędności, pozwalając ograniczyć liczbę sekund CU o 95%. W porównaniu z równoważnymi uruchomieniami Dataflow Gen2 sprzed 2026 roku Modern Evaluator zapewnił największą szacowaną redukcję — o 84% mniej sekund CU w przypadku obciążenia z intensywnym przekształcaniem danych. Aby dopasować daną możliwość do obciążenia roboczego, zobacz krótki przewodnik.

Jak mogę przyspieszyć odświeżanie Dataflow Gen2?

Dopasuj możliwości do wąskiego gardła: włącz Fast Copy dla obsługiwanych źródeł wyodrębniania i ładowania, włącz Modern Evaluator dla transformacji, których nie można złożyć, włącz Optimized copy to Lakehouse podczas zapisywania danych przejściowych w docelowym magazynie Lakehouse oraz stosuj Partitioned Compute (Preview) w przypadku dużych partycjonowanych zbiorów danych lub zbiorów danych składających się z wielu plików. Każda z tych możliwości została w tym artykule porównana pod kątem wydajności z uwzględnieniem konkretnego przyspieszenia, jakie zapewniła względem bazowego poziomu odniesienia Dataflow Gen1.

Czy muszę zmienić zapytania, aby uzyskać te ulepszenia?

No. Każdy benchmark w tym artykule uruchamiał ten sam skrypt M na obu generacjach i w każdej konfiguracji. Fast Copy, Modern Evaluator i Optimized copy to Lakehouse to ustawienia, które włączasz i zmieniają sposób, w jaki silnik wykonuje twoje zapytania, a nie same zapytania. Jedno zastrzeżenie: Fast Copy ma zastosowanie tylko do kroków spełniających jego warunki wstępne, więc transformacja, która powoduje przerwanie składania zapytań, przełącza się z powrotem na standardowy silnik i powoduje utratę tych korzyści. W przypadku tych wymagań zobacz Szybka kopia w Dataflow Gen2.

Czy Dataflow Gen2 jest szybszy i tańszy niż Dataflow Gen1?

W przypadku dużych obciążeń, takich jak te opisane w tym artykule, tak w obu kwestiach. Dataflow Gen2 działał od 1,7× do 21× szybciej niż bazowy poziom Dataflow Gen1 na tych samych danych i tym samym skrypcie M, a w scenariuszach, gdzie mierzono obie generacje, zużywał od 82% do 95% mniej jednostek przepustowości. Na przykład kopia masowa, która trwała 01:38:59 w Dataflow Gen1, kończyła się w 00:09:08 w Dataflow Gen2 z Fast Copy – około 11× szybciej. Różnica jest mniejsza przy krótkotrwałych przepływach danych, ponieważ zapytanie zakończone w ciągu pierwszych 10 minut nigdy nie osiąga tańszego poziomu 1.5 CU, więc zyski rosną wraz z ilością danych i czasem działania. Pełne porównanie dla poszczególnych scenariuszy można znaleźć w podsumowaniu wyników benchmarków.

Ile pojemności zużywa Dataflow Gen1 w porównaniu do Dataflow Gen2?

W scenariuszach, w których mierzono obie generacje, Dataflow Gen1 zużywał wielokrotnie więcej pojemności niż Dataflow Gen2 przy tej samej pracy o dużym wolumenie. Pozyskiwanie danych za pomocą funkcji Fast Copy zużyło 84 411 sekund CU w Dataflow Gen1 w porównaniu z 14 593 sekundami CU w Dataflow Gen2, co stanowi redukcję o 83%. Intensywne obciążenie związane z przekształcaniem danych pochłonęło 56 855 sekund CU w Dataflow Gen1 w porównaniu z 10 485 sekundami CU w Dataflow Gen2, co oznacza redukcję o 82%. Zoptymalizowane obciążenie kopiowania do usługi Lakehouse zużyło 50 788 sekund CU w usłudze Dataflow Gen1 w porównaniu z 2 391 sekundami CU w usłudze Dataflow Gen2, co oznacza spadek o 95%. Wszystkie trzy odświeżenia trwają znacznie dłużej niż 10 minut, więc większość czasu ich działania w Dataflow Gen2 jest rozliczana według niższej stawki 1,5 CU. Dane dla poszczególnych scenariuszy można znaleźć w podsumowaniu wyników benchmarków.

Czy powinienem przenieść moje przepływy danych Dataflow Gen1 do Dataflow Gen2?

Yes. Dataflow Gen2 to obecna generacja przepływów danych w Microsoft Fabric, więc planuję przenieść na niego wszystkie przepływy danych z Dataflow Gen1. W porównaniu z benchmarkami opisanymi w tym artykule, Dataflow Gen2 ukończył ten sam skrypt M o 1,7× do 21× szybciej, zużywając 82% do 95% mniej jednostek pojemności niż Dataflow Gen1 – ta sama logika, działając szybciej i zużywając mniejszą pojemność. Możliwości, które zapewniają te zyski – Fast Copy, Modern Evaluator, Optimized copy to Lakehouse oraz Partitioned Compute – są dostępne tylko w Dataflow Gen2, więc luka ta się powiększa wraz z poprawą tych możliwości. Największych korzyści należy oczekiwać przy dużych wolumenach danych i długotrwałych odświeżeniach. Podczas migracji testuj reprezentatywne obciążenie, aby potwierdzić wzrost na własnych danych i możliwościach. Aby zacząć, zobacz przegląd Dataflow Gen2.

Czy Dataflow Gen2 stał się z czasem bardziej opłacalny?

Yes. Obciążenie związane z intensywnym kształtowaniem w Scenariuszu 2 zużywałoby szacunkowo 66 164 sekund CU przed rokiem 2026, a obecnie zużywa 10 485 sekund CU dzięki obecnie ogólnie dostępnym funkcjom, co oznacza szacunkową redukcję o 84% przy identycznej logice i bez potrzeby wprowadzania zmian. Dla danych dla konkretnych scenariuszy zobacz Koszt w czasie (wtedy vs. teraz).

Czy starsze dane dotyczące kosztów i wydajności Dataflow Gen2 są nadal dokładne?

Niekoniecznie. Dane zawarte w tym artykule odzwierciedlają obecny model cenowy Dataflow Gen2 – 12 CU na każdą sekundę do 10 minut standardowego obliczenia, następnie 1,5 CU na każdą dodatkową sekundę – wraz z obecnymi funkcjami takimi jak Fast Copy i Modern Evaluator. Ponieważ Dataflow Gen2 stał się z czasem szybszy i bardziej opłacalny, liczby referencyjne lub szacunki kosztów opublikowane przed 2026 rokiem mogą zawyżać obecne koszty lub zaniżać obecne wyniki. Zweryfikuj własne obciążenia w aplikacji Microsoft Fabric Capacity Metrics.