Praca z przyłączeniami w usłudze Azure Databricks

Usługa Databricks obsługuje standardową składnię join ANSI. W tym artykule opisano różnice między łączeniem danych w przetwarzaniu wsadowym i strumieniowym oraz przedstawiono kilka zaleceń dotyczących optymalizacji wydajności join.

Różnice między sprzężeniami strumieniowymi i wsadowymi

Sprzężenia w usłudze Azure Databricks są stanowe lub bezstanowe.

Wszystkie sprzężenia wsadowe to sprzężenia bezstanowe. Wyniki są przetwarzane natychmiast i odzwierciedlają dane w momencie uruchomienia zapytania. Za każdym razem, gdy zapytanie jest wykonywane, nowe wyniki są obliczane na podstawie określonych danych źródłowych. Zobacz Batch joins (Sprzężenia wsadowe).

Sprzężenia między dwoma źródłami danych przesyłania strumieniowego są stanowe. W stanowych sprzężeniach usługa Azure Databricks śledzi informacje o źródłach danych, a wyniki i iteracyjnie aktualizują wyniki. Sprzężenia stanowe mogą zapewnić zaawansowane rozwiązania do przetwarzania danych online, ale może być trudne do skutecznego wdrożenia. Mają złożoną semantykę operacyjną w zależności od trybu wyjściowego, częstotliwości wyzwalania i watermark. Zobacz Stream-stream joins (Sprzężenia strumienia strumienia).

Sprzężenia strumieniowo-statyczne są bezstanowe, ale zapewniają dobrą opcję łączenia przyrostowego źródła danych (na przykład faktów table) ze statycznym źródłem danych (takim jak wolno zmieniające się wymiarowe table). Zamiast dołączać wszystkie rekordy z obu stron za każdym razem, gdy zapytanie jest wykonywane, tylko nowo odebrane rekordy ze źródła przesyłania strumieniowego są przyłączone do bieżącej wersji statycznej table. Zobacz Stream-static joins (Sprzężenia statyczne w usłudze Stream).

Sprzężenia wsadowe

Usługa Azure Databricks obsługuje standardową składnię join SQL, w tym połączenia wewnętrzne, zewnętrzne, półpołączenia, anty i poprzeczne. Zobacz JOIN.

Sprzężenia strumienia

Łączenie dwóch źródeł danych przesyłanych strumieniowo może stanowić znaczące wyzwania związane z zarządzaniem informacjami o stanie i rozumowaniem wyników obliczeń i danych wyjściowych. Przed zaimplementowaniem joinstrumienia usługa Databricks zaleca opracowanie silnej wiedzy na temat semantyki operacyjnej na potrzeby przesyłania strumieniowego stanowego, w tym sposobu wpływu znaków wodnych na zarządzanie stanem. Odwiedź następujące artykuły:

• Co to jest przesyłanie strumieniowe stanowe?
• Stosowanie znaków wodnych w celu kontrolowania progów przetwarzania danych
• Sprzężenia strumień-strumień

Usługa Databricks zaleca określenie znaków wodnych dla obu stron wszystkich sprzężeń strumieniowo-parowych. Obsługiwane są następujące typy join:

• Sprzężenia wewnętrzne
• Lewe sprzężenia zewnętrzne
• Prawe sprzężenia zewnętrzne
• Pełne sprzężenia zewnętrzne
• Lewe sprzężenia częściowe

Zobacz dokumentację przesyłania strumieniowego ze strukturą platformy Apache Spark na sprzężeniach strumieniowo-steam.

Sprzężenia statyczne strumienia

Strumień statyczny join łączy najnowszą prawidłową wersję table delty (danych statycznych) ze strumieniem danych przy użyciu bezstanowego join.

Gdy usługa Azure Databricks przetwarza mikropartię danych w statycznym join, najnowsza prawidłowa wersja danych z Delta table łączy się z rekordami obecnymi w bieżącej mikropartii. Ponieważ join jest bezstanowa, nie trzeba konfigurować znakowania wodnego i może przetwarzać wyniki z małym opóźnieniem. Dane w statycznej Delcie table używanej w join powinny być powolnie zmieniającymi się.

W poniższym przykładzie pokazano ten wzorzec:

streamingDF = spark.readStream.table("orders")
staticDF = spark.read.table("customers")

query = (streamingDF
  .join(staticDF, streamingDF.customer_id==staticDF.id, "inner")
  .writeStream
  .option("checkpointLocation", checkpoint_path)
  .table("orders_with_customer_info")
)

wydajność Optimizejoin

Obliczenia z włączoną funkcją Photon zawsze wybierają najlepszy typ join. Zobacz Co to jest Photon?.

Użycie najnowszej wersji środowiska Databricks Runtime z włączoną funkcją Photon ogólnie zapewnia dobrą wydajność join, ale należy również wziąć pod uwagę następujące zalecenia:

• Sprzężenia krzyżowe są bardzo drogie. Remove sprzężenia krzyżowe z obciążeń i zapytań, które wymagają małych opóźnień lub częstej ponownej kompilacji.

• Join Porządek ma znaczenie. Podczas wykonywania wielu sprzężeń zawsze najpierw join najmniejsze tables, a następnie join wynik z większym tables.

• Optymalizator może zmagać się z zapytaniami z wieloma sprzężeniami i agregacjami. Zapisywanie wyników pośrednich może przyspieszyć planowanie zapytań i wyniki obliczeń.

• Zachowaj świeże statystyki, aby zwiększyć wydajność. Optymalizacja predykcyjna za pomocą ANALYZE (publiczna wersja zapoznawcza) może automatycznie update i utrzymywać statystyki. Możesz również uruchomić zapytanie ANALYZE TABLE table_name COMPUTE STATISTICS do statystyk update w planie zapytań.

wskazówki Join dotyczące usługi Azure Databricks

Platforma Apache Spark obsługuje określanie wskazówek join dla sprzężeń zakresu i sprzężeń niesymetrycznych. Wskazówki dotyczące niesymetrycznych sprzężeń nie są konieczne, ponieważ usługa Azure Databricks automatycznie optymalizuje te sprzężenia. Zobacz wskazówki

Wskazówki dotyczące łączeń zakresowych mogą być przydatne, jeśli wydajność join jest niska i wykonujesz złączenia nierówności. Przykłady obejmują dołączanie do zakresów sygnatur czasowych lub zakres identyfikatorów klastrowania. Zobacz optymalizację zakresu join.