Streamingowe tabele

Tabela przesyłania strumieniowego to tabela delty z dodatkową obsługą przesyłania strumieniowego lub przyrostowego przetwarzania danych. Tabela przesyłania strumieniowego może być objęta co najmniej jednym przepływem w potoku.

Wskazówki dotyczące tego, kiedy używać tabel strumieniowych zamiast widoków materializowanych lub widoków, można znaleźć w artykule Czym są potoki?.

Tabele strumieniowe są dobrym wyborem do wprowadzania danych z następujących powodów:

• Każdy wiersz wejściowy jest obsługiwany tylko raz, co modeluje zdecydowaną większość obciążenia pozyskiwania danych (czyli przez dołączanie lub wstawianie bądź aktualizowanie wierszy do tabeli).
• Mogą obsługiwać duże ilości danych w trybie tylko do dołączania.

Tabele przesyłania strumieniowego są również dobrym wyborem w przypadku przekształceń przesyłania strumieniowego o małych opóźnieniach, ponieważ potrafią analizować wiersze i okna czasowe, obsługiwać duże ilości danych i zapewniać przetwarzanie o małych opóźnieniach.

Na poniższym diagramie pokazano, jak przepływy odczytują ze źródeł przesyłania strumieniowego i zapisują przyrostowo do tabeli przesyłania strumieniowego w potoku.

W każdej aktualizacji przepływy skojarzone z tabelą przesyłania strumieniowego odczytują zmienione informacje w źródle przesyłania strumieniowego i dołączają nowe informacje do tej tabeli.

Tabele przesyłania strumieniowego są własnością pojedynczego potoku i są aktualizowane przez niego. W kodzie źródłowym potoku jawnie definiujesz tabele przesyłania strumieniowego. Tabele zdefiniowane przez potok nie mogą być zmieniane ani aktualizowane przez żaden inny potok. Można zdefiniować wiele przepływów w celu dołączenia do pojedynczej tabeli przesyłania strumieniowego.

Azure Databricks tworzy tabele wewnętrzne do obsługi przetwarzania tabel strumieniowych. Te tabele pojawiają się w system.information_schema.tables, ale nie są widoczne w Eksploratorze katalogu ani w interfejsie użytkownika innych stron obszaru roboczego.

Aby uzyskać więcej informacji o przepływach, zobacz Przyrostowe ładowanie i przetwarzanie danych za pomocą przepływów potoku Lakeflow.

Tabele strumieniowe na potrzeby przetwarzania danych

Tabele przesyłania strumieniowego są przeznaczone tylko do dołączania źródeł danych i przetwarzają dane wejściowe tylko raz. Dzięki temu można je dobrze dopasować do obciążeń pozyskiwania, w których dane docierają stale i muszą być niezawodnie przechwytywane bez ponownego przetwarzania istniejących rekordów. Azure Databricks obsługuje pozyskiwanie danych do tabel strumieniowych z chmurowej pamięci obiektowej (przy użyciu funkcji Auto Loader) oraz ze strumieniowych magistral komunikatów, takich jak Apache Kafka, Azure Event Hubs i Google Pub/Sub. Aby uzyskać instrukcje dotyczące ładowania danych i przykłady kodu, zobacz Ładowanie danych w potokach.

Na poniższym diagramie przedstawiono sposób działania tabel strumieniowych umożliwiających tylko dołączanie.

Wiersz, który został już dołączony do tabeli przesyłania strumieniowego, nie zostanie ponownie przetworzony przy późniejszych aktualizacjach potoku danych. Jeśli zmodyfikujesz zapytanie (na przykład z SELECT LOWER (name) do SELECT UPPER (name)), istniejące wiersze nie zostaną zaktualizowane, aby były pisane wielkimi literami, ale nowe wiersze będą pisane wielkimi literami. Możesz wyzwolić pełne odświeżanie, aby ponownie wyświetlić wszystkie poprzednie dane z tabeli źródłowej, aby zaktualizować wszystkie wiersze w tabeli przesyłania strumieniowego.

Tabele przesyłania strumieniowego i przesyłanie strumieniowe o małych opóźnieniach

Tabele przesyłania strumieniowego są zaprojektowane do niskoopóźnieniowego przesyłania danych w środowisku z ograniczonym stanem. Tabele przesyłania strumieniowego używają zarządzania punktami kontrolnymi, co sprawia, że są one odpowiednie do przesyłania strumieniowego o niskim opóźnieniu. Jednak oczekują strumieni, które są naturalnie ograniczone lub powiązane ze znakiem wodnym.

Naturalnie ograniczony strumień jest generowany przez źródło danych strumieniowych, które ma dobrze zdefiniowany początek i koniec. Przykładem naturalnie ograniczonego strumienia jest odczytywanie danych z katalogu plików, w którym nie są dodawane żadne nowe pliki po umieszczeniu początkowej partii plików. Strumień jest uznawany za ograniczony, ponieważ liczba plików jest skończona, a strumień kończy się po przetworzeniu wszystkich plików.

Możesz również użyć znaku wodnego, aby ustanowić granicę strumienia. Znak wodny w Structured Streaming to mechanizm, który pomaga obsługiwać opóźnione dane, określając, jak długo system powinien czekać na opóźnione zdarzenia, zanim uzna okno czasowe za zakończone. Nieograniczony strumień, który nie ma znaku wodnego, może doprowadzić do awarii potoku z powodu przeciążenia pamięci.

W przypadku obciążeń operacyjnych, które wymagają jak najniższego opóźnienia, możesz uruchomić potok przetwarzania w trybie czasu rzeczywistego, aby przetwarzać rekordy z całkowitym opóźnieniem poniżej jednej sekundy.

Aby uzyskać więcej informacji, zobacz:

• Korzystanie z trybu czasu rzeczywistego w potokach Lakeflow
• Optymalizowanie przetwarzania stanowego przy użyciu znaków wodnych

Ograniczenia tabel strumieniowania

Tabele przesyłania strumieniowego mają następujące ograniczenia:

• Ograniczona ewolucja: możesz zmienić zapytanie bez ponownego skompilowania całego zestawu danych. Bez pełnego odświeżania tabela przesyłania strumieniowego widzi każdy wiersz tylko raz, więc różne zapytania przetwarzają różne wiersze. Jeśli na przykład dodasz UPPER() do pola w zapytaniu, tylko wiersze przetwarzane po zmianie będą zawierać wielkie litery. Oznacza to, że musisz pamiętać o wszystkich poprzednich wersjach zapytania, które jest uruchomione w zestawie danych. Aby ponownie przetworzyć istniejące wiersze, które zostały przetworzone przed zmianą, wymagane jest pełne odświeżenie.
• Zarządzanie stanem: Tabele przesyłania strumieniowego mają małe opóźnienia i wymagają strumieni, które są naturalnie ograniczone lub ograniczone przy użyciu znaku wodnego. Aby uzyskać więcej informacji, zobacz Optymalizowanie przetwarzania stanowego z użyciem znaków wodnych.
• Złączenia nie przeliczają się: Złączenia w tabelach przesyłania strumieniowego nie przeliczają się po zmianie wymiarów. Ta cecha może być dobra dla scenariuszy „szybko-ale-niepoprawnie”. Jeśli chcesz, aby widok był zawsze poprawny, możesz użyć zmaterializowanego widoku. Zmaterializowane widoki są zawsze poprawne, ponieważ automatycznie ponownie skompilują sprzężenia po zmianie wymiarów. Aby uzyskać więcej informacji, zobacz Zmaterializowane Widoki. Aby zapoznać się z przykładem łączenia strumienia ze statyczną tabelą wymiarów, zobacz Stream-static joins (Sprzężenia statyczne strumienia).
• Brak CLONE obsługi: tabele strumieniowe nie mogą służyć jako źródło ani cel głębokiego lub płytkiego klonowania. W przypadku innych nieobsługiwanych poleceń zobacz Ograniczenia.
• REFRESH Uprawnienie wymagane do wyświetlenia potoku: Aby wyświetlić potok obsługujący tabelę strumieniową, użytkownik niebędący administratorem potrzebuje uprawnienia REFRESH na tabeli strumieniowej, oprócz uprawnień do potoku. Zobacz Kto może wyświetlać potok i jego dane wyjściowe?.

Dodatkowe zasoby

• Ładowanie danych w potokach
• Pełne odświeżanie tabel przesyłania strumieniowego