Jak tworzyć proste, wydajne i niskoopóźnieniowe potoki danych

Dzisiejsze firmy oparte na danych stale tworzą dane, co wymaga potoków danych inżynieryjnych, które stale pozyskiwają i przekształcają te dane. Te rurociągi powinny być w stanie przetwarzać i dostarczać dane dokładnie raz, produkować wyniki z opóźnieniem mniejszym niż 200 milisekund i zawsze starać się minimalizować koszty.

W tym artykule opisano metody przetwarzania wsadowego i przetwarzania strumieniowego przyrostowego dla potoków danych inżynieryjnych, dlaczego przetwarzanie strumieniowe przyrostowe jest lepszą opcją, a następnie kolejne kroki, aby rozpocząć korzystanie z ofert przetwarzania strumieniowego przyrostowego w usłudze Databricks, streamingu w usłudze Azure Databricks i Co to jest DLT?. Te funkcje umożliwiają szybkie zapisywanie i realizację potoków, które gwarantują semantykę dostarczania, opóźnienia, koszty oraz więcej.

Pułapki zadań wsadowych wykonywanych wielokrotnie

Podczas konfigurowania potoku danych możesz na początku pisać powtarzalne zadania wsadowe do pobierania danych. Na przykład co godzinę można uruchomić zadanie platformy Spark, które odczytuje ze źródła i zapisuje dane w odbiorniku, takim jak Delta Lake. Wyzwanie związane z tym podejściem polega na przyrostowym przetwarzaniu źródła, ponieważ zadanie platformy Spark uruchamiane co godzinę musi rozpocząć, gdzie zakończyło się ostatnie. Możesz zarejestrować najnowszy znacznik czasu przetworzonych danych, a następnie wybrać wszystkie wiersze ze znacznikami czasu nowszymi niż ten znacznik czasu, ale istnieją pułapki:

Aby uruchomić ciągły potok danych, możesz spróbować zaplanować zadanie przetwarzania wsadowego co godzinę, które przyrostowo odczytuje ze źródła, wykonuje przekształcenia i zapisuje wynik do miejsca docelowego, takiego jak usługa Delta Lake. Takie podejście może mieć pułapki:

• Zadanie Spark wykonujące zapytania o wszystkie nowe dane po znaczniku czasu może pominąć opóźnione dane.
• Zadanie platformy Spark, które kończy się niepowodzeniem, może prowadzić do naruszenia gwarancji dokładnego jednokrotnego przetwarzania, jeśli nie zostanie właściwie zarządzane.
• Zadanie platformy Spark zawierające listę zawartości lokalizacji magazynu w chmurze w celu znalezienia nowych plików stanie się kosztowne.

Następnie nadal trzeba wielokrotnie przekształcać te dane. Możesz napisać powtarzające się zadania wsadowe, które następnie agregują dane lub stosują inne operacje, co jeszcze bardziej komplikuje i zmniejsza wydajność potoku.

Przykład wsadowy

Aby w pełni zrozumieć pułapki przetwarzania i przekształcania partii w kontekście potoku danych, rozważ następujące przykłady.

Nieodebrane dane

Biorąc pod uwagę temat Kafka z danymi użycia, który określa, ile należy pobierać od klientów, a dane są przetwarzane w partiach, sekwencja zdarzeń może wyglądać następująco:

1. Pierwsza partia ma dwa rekordy o godzinie 8:30 i 8:30.
2. Zaktualizowałeś najnowszy znacznik czasu na 8:30.
3. Otrzymasz kolejny rekord o godzinie 8:15.
4. Druga seria zapytań dotyczy wszystkiego po 8:30, więc pomijasz rekord o 8:15.

Ponadto nie chcesz ani przepłacić, ani za mało obciążyć swoich użytkowników, więc musisz upewnić się, że wczytujesz każdy rekord dokładnie raz.

Przetwarzanie nadmiarowe

Następnie załóżmy, że dane zawierają rekordy zakupów użytkowników i chcesz sumować sprzedaż na godzinę, aby poznać najbardziej popularne godziny w sklepie. Jeśli zakupy na tę samą godzinę przychodzą w różnych partiach, będziesz mieć wiele partii, które produkują wyniki dla tej samej godziny.

Czy okno od 8:00 do 9:00 ma dwa elementy (wynik partii 1), jeden element (wynik partii 2) czy trzy elementy (wynik żadnej z partii)? Dane wymagane do utworzenia danego przedziału czasu pojawiają się w wielu etapach transformacji. Aby rozwiązać ten problem, możesz podzielić dane na partycje według dnia i ponownie przetworzyć całą partycję, gdy trzeba obliczyć wynik. Następnie możesz nadpisać wyniki w miejscu docelowym:

Jednak wiąże się to z kosztem opóźnień i kosztów, ponieważ druga partia musi wykonać niepotrzebną pracę nad przetwarzaniem danych, które mogły już zostać przetworzone.

Brak pułapek przy przetwarzaniu strumienia przyrostowego

Przetwarzanie strumieni przyrostowych ułatwia uniknięcie wszystkich pułapek powtarzających się zadań wsadowych w celu pozyskiwania i przekształcania danych. Narzędzia Databricks Structured Streaming i DLT zarządzają złożonościami implementacji przesyłania strumieniowego, aby umożliwić skupienie się wyłącznie na logice biznesowej. Wystarczy określić źródło, z którym ma się połączyć, jakie przekształcenia należy wykonać z danymi oraz gdzie zapisać wynik.

Pozyskiwanie przyrostowe

Pozyskiwanie przyrostowe w usłudze Databricks jest wspierane przez strukturalne przesyłanie strumieniowe Apache Spark, które może przyrostowo wykorzystywać źródło danych i zapisywać je do docelowej bazy danych. Silnik przesyłania strumieniowego może przetwarzać dane dokładnie raz, a silnik może obsługiwać dane w nieprawidłowej kolejności. Silnik można uruchomić w notatnikach lub przy użyciu tabel przesyłu strumieniowego w technologii DLT.

Silnik strukturalnego przesyłania strumieniowego na platformie Databricks udostępnia zastrzeżone źródła przesyłania strumieniowego, takie jak AutoLoader, które mogą przyrostowo przetwarzać pliki w chmurze w sposób kosztowo efektywny. Usługa Databricks udostępnia również łączniki dla innych popularnych magistrali komunikatów, takich jak Apache Kafka, Amazon Kinesis, Apache Pulsari Google Pub/Sub.

Przyrostowe przekształcanie

Przekształcenia przyrostowe w Databricks z użyciem Strukturalnego Przesyłania Strumieniowego pozwalają na specyfikację przekształceń w ramkach danych przy użyciu tego samego interfejsu API co zapytanie wsadowe, ale śledzi dane w partiach i zagregowane wartości w czasie, dzięki czemu nie musisz tego robić. Nigdy nie musi ponownie przetwarzać danych, więc jest szybsze i bardziej ekonomiczne niż powtarzające się zadania wsadowe. Przesyłanie strumieniowe Structured Streaming tworzy strumień danych, które mogą być dołączane do wybranego odbiornika, takiego jak Delta Lake, Kafka lub dowolny inny obsługiwany łącznik.

Materializowane Widoki w DLT są zasilane przez silnik Enzyme. Enzym nadal przyrostowo przetwarza źródło, ale zamiast produkować strumień, tworzy zmaterializowany widok, który jest wstępnie obliczoną tabelą, która przechowuje wyniki danego zapytania. Enzym jest w stanie efektywnie określić, w jaki sposób nowe dane wpływają na wyniki zapytania, i utrzymuje wstępnie obliczoną tabelę up-to-date.

Zmaterializowane widoki tworzą widok na agregację, która zawsze jest wydajnie aktualizowana tak, aby na przykład w scenariuszu opisanym powyżej wiesz, że okno od 8:00 do 9:00 ma trzy elementy.

Przesyłanie strumieniowe ze strukturą lub DLT?

Znaczącą różnicą między strumieniowaniem strukturalnym a DLT jest sposób, w jaki wdrażasz zapytania strumieniowe. W przypadku przesyłania strumieniowego ze strukturą ręcznie określasz wiele konfiguracji i musisz ręcznie łączyć zapytania. Musisz jawnie uruchomić zapytania, poczekać na ich zakończenie, anulować je po niepowodzeniu i inne akcje. W technologii DLT deklaratywnie przekazujesz swoje potoki do uruchomienia, a DLT utrzymuje je uruchomione.

Biblioteka DLT ma również funkcje, takie jak zmaterializowane widoki, które wydajnie i przyrostowo wstępnie obliczają przekształcenia twoich danych.

Aby uzyskać więcej informacji na temat tych funkcji, zobacz Streaming w usłudze Azure Databricks i Co to jest DLT?.

Następne kroki

• Utwórz pierwszy potok przy użyciu DLT. Zobacz : Samouczek: Uruchom swój pierwszy potok DLT.
• Uruchom swoje pierwsze zapytanie Structured Streaming na platformie Databricks. Zobacz Uruchom swoje pierwsze zadanie przesyłania strumieniowego w trybie strukturalnym.

• Użyj zmaterializowanego widoku. Zobacz Użyj zmaterializowanych widoków w Databricks SQL.