Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Fabric Runtime to platforma zintegrowana z Azure, oparta na Apache Spark, która umożliwia wykonywanie i zarządzanie doświadczeniami inżynierii danych i nauki o danych. Łączy kluczowe składniki zarówno ze źródeł wewnętrznych, jak i open source, zapewniając klientom kompleksowe rozwiązanie. Dla uproszczenia należy odnieść się do Fabric Runtime powered by Apache Spark jako Fabric Runtime.
Główne składniki środowiska uruchomieniowego Fabric:
Apache Spark — zaawansowana rozproszona biblioteka obliczeniowa typu open source, która umożliwia przetwarzanie i analizowanie danych na dużą skalę. Platforma Apache Spark udostępnia wszechstronną i wysokowydajną platformę do inżynierii danych i środowiska nauki o danych.
Delta Lake — warstwa magazynu typu open source, która zapewnia transakcje ACID i inne funkcje niezawodności danych na platformie Apache Spark. Zintegrowane w środowisku uruchomieniowym Fabric Runtime, Delta Lake zwiększa możliwości przetwarzania danych i zapewnia spójność danych w wielu współbieżnych operacjach.
The Native Execution Engine – transformacyjne ulepszenie dla obciążeń Apache Spark, oferujące znaczące poprawy wydajności poprzez bezpośrednie wykonywanie zapytań Spark na infrastrukturze lakehouse. Dzięki bezproblemowej integracji nie wymaga zmian w kodzie i pozwala uniknąć uzależnienia od jednego dostawcy. Obsługuje zarówno formaty Parquet, jak i Delta w API Apache Spark w Runtime 1.3 (Spark 3.5) oraz Runtime 2.0 (Spark 4.1).
Obsługiwane operatory są przeniesione z platformy Spark działającej na JVM do wektoryzowanej ścieżki wykonawczej C++ za pośrednictwem Apache Gluten i Velox, umożliwiając przetwarzanie kolumnowe przyspieszone przez SIMD z natywną obsługą formatów Parquet i Delta. Jeśli operator nie jest obsługiwany, wykonywanie automatycznie wraca do platformy Spark opartej na maszynie JVM. W reprezentatywnych testach porównawczych (TPC-DS o współczynniku skalowania 1000 z użyciem Delta), aparat osiągnął wydajność do sześciu razy szybszą w porównaniu z otwartoźródłowym Spark, co przekłada się na około 83% oszczędności kosztów obliczeń na klastrze Fabric o stałym rozmiarze.
Ścieżka natywna zachowuje optymalizacje zapytań platformy Fabric Spark, w tym wykonywanie zapytań adaptacyjnych, przekształcenia oparte na kosztach, przycinanie kolumn i przesuwanie predykatów. Możesz włączać lub wyłączać natywne wykonywanie dla każdej aplikacji za pomocą konfiguracji
spark.native.enabled. Podczas wykonywania komórek notesu usługa Fabric Spark Advisor powiadamia w czasie rzeczywistym, gdy wykonanie powraca do Spark działającego na JVM, co ułatwia diagnostykę, kiedy natywne przeniesienie nie zostało zastosowane.Pakiety na poziomie domyślnym dla języków Java/Scala, Python i R — pakiety obsługujące różne języki programowania i środowiska. Te pakiety są instalowane i konfigurowane automatycznie, dzięki czemu deweloperzy mogą stosować preferowane języki programowania do zadań przetwarzania danych.
Fabric Runtime opiera się na solidnym systemie operacyjnym open-source, zapewniającym kompatybilność z różnymi konfiguracjami sprzętowymi i wymaganiami systemowymi.
W poniższej tabeli znajdziesz kompleksowe porównanie kluczowych komponentów, w tym wersji Apache Spark, obsługiwanych systemów operacyjnych, Java, Scala, Python, Delta Lake i R, dla runtime'ów opartych na Apache Spark w ramach platformy Fabric.
Wskazówka
Zawsze używaj najnowszej, ogólnie dostępnej (GA) wersji wykonawczej dla swojego obciążenia produkcyjnego, czyli obecnie Runtime 2.0.
| Składnik | Środowisko uruchomieniowe 1.3 | Runtime 2.0 |
|---|---|---|
| Etap wydania | ogólna dostępność | ogólna dostępność |
| Wersja Apache Spark | 3.5.5 | 4.1 |
| System operacyjny | Mariner 2.0 | Mariner 3.0 |
| Wersja języka Java | 11 | dwadzieścia jeden |
| Wersja języka Scala | 2.12.17 | 2.13.16 |
| Wersja języka Python | 3.11 | 3.13 |
| Wersja usługi Delta Lake | 3.2 | 4.2 |
Odwiedź stronę Runtime 1.3 lub Runtime 2.0 , aby zapoznać się ze szczegółami, nowymi funkcjami, ulepszeniami i scenariuszami migracji dla określonej wersji środowiska uruchomieniowego.
Optymalizacje sieci szkieletowej
W Fabric zarówno silnik Spark, jak i implementacje Delta Lake zawierają optymalizacje i funkcje specyficzne dla platformy. Funkcje te wykorzystują natywne integracje w ramach platformy. Możesz wyłączyć wszystkie te funkcje, aby uzyskać standardową funkcjonalność Spark i Delta Lake. Środowiska uruchomieniowe Fabric dla Apache Spark obejmują:
- Kompletna wersja typu open source platformy Apache Spark.
- Kolekcja prawie 100 wbudowanych, unikatowych ulepszeń wydajności zapytań. Te ulepszenia obejmują funkcje, takie jak buforowanie partycji (umożliwiające pamięci podręcznej partycji w Systemie plików zmniejszenie liczby wywołań do magazynu metadanych) oraz operację Cross Join do projekcji podzapytania skalarnego.
- Wbudowana inteligentna pamięć podręczna.
W środowisku Fabric Runtime dla Apache Spark i Delta Lake natywne funkcje zapisu służą dwóm kluczowym celom:
- Oferują one zróżnicowaną wydajność dla obciążeń związanych z pisaniem, optymalizując proces tworzenia treści.
- Domyślnie stosują optymalizację V-order dla plików Delta Parquet. Optymalizacja Delta Lake V-order jest kluczowa dla zapewnienia najwyższej wydajności odczytu we wszystkich silnikach Fabric. Aby lepiej zrozumieć, jak działa i jak nim zarządzać, zobacz optymalizację tabel Delta Lake oraz V-order.
Obsługa wielu środowisk uruchomieniowych
Fabric obsługuje wiele runtime'ów, więc możesz między nimi przełączać się i zmniejszać ryzyko problemów z kompatybilnością lub zakłóceń.
Note
Środowisko uruchomieniowe Spark zawiera konkretną wersję Python jako część zestawu komponentów. Na przykład Runtime 1.3 zawiera Python 3.11. Ta wersja języka Python jest oddzielna od jądra notatnika języka Python, które wybierasz dla notatników wyłącznie w języku Python. Informacje na temat cyklu życia środowiska uruchomieniowego i jądra notesu Python można znaleźć w artykule Środowisko uruchomieniowe i cykl życia jądra notesu Python w usłudze Fabric.
Domyślnie wszystkie nowe przestrzenie robocze obecnie korzystają z Runtime 1.3.
Aby zmienić wersję środowiska uruchomieniowego na poziomie obszaru roboczego, przejdź do Ustawienia obszaru roboczego>Inżynieria danych/Nauka>Ustawienia platformy Spark. Na karcie środowiska
Po wprowadzeniu tej zmiany wszystkie elementy utworzone przez system w przestrzeni roboczej, w tym domy nad jeziorem, opisy zadań Spark i notatniki, korzystają z nowo wybranej wersji roboczej na poziomie przestrzeni roboczej począwszy od następnej sesji Spark. Jeśli obecnie używasz notatnika z istniejącą sesją na potrzeby zadania lub jakiejkolwiek aktywności związanej z lakehouse, ta sesja Spark pozostanie aktywna bez zmian. Jednak od następnej sesji lub następnego zadania zaczyna obowiązywać wybrana wersja środowiska uruchomieniowego.
Aby zmienić czas działania na poziomie przedmiotu Environment , stwórz nowy element środowiska lub otwórz istniejący. W rozwijanym menu Runtime wybierz wybraną wersję runtime spośród dostępnych opcji, wybierz Save, a następnie Publish zmiany. Następnie możesz użyć tego Environment elementu ze swoim elementem Notebook lub Spark Job Definition.
Konsekwencje zmian środowiska uruchomieniowego w ustawieniach platformy Spark
System migruje wszystkie ustawienia Spark. Jednak jeśli system wykryje, że ustawienie Spark nie jest kompatybilne z Runtime B, wyświetla komunikat ostrzegawczy i nie implementuje tego ustawienia.
Konsekwencje zmian środowiska uruchomieniowego w zarządzaniu bibliotekami
System zarządzania bibliotekami migruje wszystkie biblioteki z Runtime A do Runtime B, w tym zarówno publiczne, jak i niestandardowe runtime. Jeśli wersje Python i R pozostaną takie same, biblioteki działają poprawnie. Jednak w przypadku JAR-ów istnieje duże prawdopodobieństwo, że nie działają z powodu zmian w zależności i innych czynników, takich jak zmiany w Scala, Java, Spark i systemie operacyjnym.
Jesteś odpowiedzialny za aktualizację lub wymianę bibliotek, które nie działają z Runtime B. Jeśli wystąpi konflikt, co oznacza, że Runtime B zawiera bibliotekę pierwotnie zdefiniowaną w Runtime A, system zarządzania bibliotekami próbuje stworzyć niezbędną zależność dla Runtime B na podstawie Twoich ustawień. Jednak proces kompilacji kończy się niepowodzeniem, jeśli wystąpi konflikt. W dzienniku błędów możesz zobaczyć, które biblioteki powodują konflikty i wprowadzać zmiany w ich wersjach lub specyfikacjach.
Uaktualnianie protokołu usługi Delta Lake
Funkcje Delta Lake są zawsze kompatybilne wstecz, co gwarantuje, że tabele stworzone w niższej wersji Delta Lake mogą bezproblemowo współdziałać z wyższymi wersjami. Jednak włączając pewne funkcje (na przykład używając tej metody delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) ), możesz naruszyć kompatybilność przyszłościową z niższymi wersjami Delta Lake. W takich przypadkach trzeba zmodyfikować obciążenia odwołujące się do zaktualizowanych tabel, aby były zgodne z wersją Delta Lake, która zachowuje kompatybilność.
Każda tabela Delta jest powiązana ze specyfikacją protokołu, która definiuje funkcje, które obsługuje. Aplikacje, które wchodzą w interakcję z tabelą do odczytu lub zapisu, polegają na tej specyfikacji protokołu, aby określić, czy są one zgodne z zestawem funkcji tabeli. Jeśli aplikacja nie ma możliwości obsługi funkcji wymienionej jako wspierana w protokole tabeli, nie może odczytywać ani zapisywać do tej tabeli.
Specyfikacja protokołu jest podzielona na dwa odrębne składniki: protokół "read" i protokół "write". Więcej informacji znajdziesz w artykule Jak Delta Lake zarządza kompatybilnością funkcji?
Możesz uruchomić polecenie delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) w środowisku PySpark, a także w Spark SQL i Scala. To polecenie inicjuje aktualizację tabeli Delta.
Po wykonaniu tej aktualizacji otrzymujesz ostrzeżenie, że aktualizacja wersji protokołu Delta jest procesem nieodwracalnym. Ten proces oznacza, że po uruchomieniu aktualizacji nie można jej cofnąć.
Uaktualnienia wersji protokołu mogą potencjalnie mieć wpływ na zgodność istniejących czytników tabel Delta Lake, zapisujących lub obu tych typów. Dlatego należy zachować ostrożność i aktualizować wersję protokołu tylko wtedy, gdy jest to konieczne, na przykład przy wdrażaniu nowych funkcji w Delta Lake.
Ważne
Aby dowiedzieć się więcej o tym, które wersje i funkcje protokołu są kompatybilne we wszystkich doświadczeniach Fabric, zobacz interoperacyjność formatów tabel Delta Lake.
Dodatkowo sprawdź, czy wszystkie obecne i przyszłe obciążenia produkcyjne oraz procesy są kompatybilne z tabelami Delta Lake, korzystając z nowej wersji protokołu, aby zapewnić płynne przejście i zapobiec ewentualnym zakłóceniom.