Wprowadzenie
Ponieważ ekosystemy danych stale rosną pod względem wielkości i złożoności, coraz ważniejsza staje się zapotrzebowanie na niezawodne rurociągi danych z szybkim czasem wprowadzenia na rynek. Zachęca to firmy do sięgania po nowe metodologie dla ich procesów ETL, takie jak deklaratywne rurociągi, które pozwalają programistom skupić się na określeniu, jak powinien wyglądać pożądany stan danych bez martwienia się o kolejność wykonania zadania.
Wraz z wydaniem Delta Live Tables, Databricks zamierza zastosować to podejście na swojej platformie i zapewnić rozwiązanie do przetwarzania danych, które obsługuje logikę transformacji wraz z innymi przydatnymi funkcjami, takimi jak zautomatyzowane kontrole jakości danych, monitorowanie i obserwowalność.
Deklaratywne podejście do rurociągów danych
Zastosowanie podejścia deklaratywnego nie jest unikalne dla inżynierii danych. W DevOps narzędzia takie jak Kubernetes i Terraform zrewolucjonizowały praktyki wdrażania, wprowadzając koncepcję infrastruktury jako kodu, która pozwala inżynierom definiować pożądany stan infrastruktury i środowisk, zamiast określać każdy etap operacyjny. Podobnie, deklaratywne rurociągi pozwalają inżynierom zdefiniować ostateczny stan bazy danych, pozostawiając działania operacyjne podstawowemu systemowi.
Tradycyjnie rurociągi ETL są tworzone poprzez wyraźne określenie kolejności wykonywania zadań, koncentrując się na relacjach między zadaniami, aby upewnić się, że wyniki są spójne, bez pominięcia wymaganych danych i uniknięcia duplikatów.
Typowy proces można zdefiniować w następujących krokach:
- Pobierz pliki z pamięci masowej.
- Załaduj dane do tabel etapów.
- Wykonuj transformacje danych, łącząc dane z różnych źródeł.
- Załaduj do końcowego miejsca docelowego i przeprowadź kontrole jakości danych.
Chociaż to konieczne podejście jest elastyczne i dobrze znane, skalowanie i utrzymanie może stać się trudne w miarę wzrostu złożoności rurociągu, ponieważ gdy kroki są wyraźnie zdefiniowane, programista musi ręcznie odzwierciedlać linię danych w rurociągu, dlatego zapewnienie najlepszej wydajności z równoległością, skalowaniem i przy minimalnych kosztach może być trudne.
Z drugiej strony deklaratywne rurociągi nie wymagają wyraźnego określenia kolejności etapów transformacji. Autor potoku określa, jak powinien wyglądać ostateczny stan danych, pozostawiając silnik rurociągu, aby automatycznie określał rzeczywiste kroki do jego osiągnięcia, tj. kolejność przekształceń, planowanie zadań, obsługę zależności, alokację zasobów i optymalizację. Teoretycznie takie podejście wydaje się świetną opcją, ponieważ zapewnia skalowalność i prostotę coraz bardziej złożonym rozwiązaniom danych.
Ta metoda może być świetną opcją w wielu przypadkach użycia, ale decydując, czy powinniśmy korzystać z ram deklaratywnych, musimy wziąć pod uwagę względny brak elastyczności, ponieważ rozwiązania te abstrahują szczegóły operacyjne, co może utrudniać debugowanie i rozwiązywanie problemów. Również blokowanie dostawcy może być problemem z powodu zastrzeżonej składni lub integracji specyficznych dla platformy.
Przedstawiamy Delta Live Tables
Delta Live Tables (DLT) to deklaratywny framework ETL do budowania skalowalnych i niezawodnych pociągów przetwarzania danych. Pozwala użytkownikom skupić się na transformacjach i pożądanych strukturach danych, jednocześnie automatycznie zarządzając orkiestracją, infrastrukturą obliczeniową, jakością danych i obsługą błędów.
Jaka jest różnica między tabelami Delta Live a tabelami Delta? Tabela Delta jest domyślnym formatem tabeli danych w Databricks, który zasadniczo rozszerza format pliku parquet umożliwiając wykonywanie transakcji ACID. Delta Live Tables pozwala jednak opisać przepływ danych między tymi tabelami, tworząc je i zarządzając aktualizacjami.
DLT wykorzystuje następujące zbiory danych do zachowania wyników zapytań deklaratywnych:
- Tabela strumieniowa - Tabela Delta z obsługą przesyłania strumieniowego i przyrostowego przetwarzania danych. Jest zawsze definiowany na podstawie źródła danych, które stale lub stopniowo rośnie. Tabele te są przeznaczone dla źródeł danych tylko dla załączników i natywnie obsługują Databricks Autoloader, co umożliwia wydajne pobieranie plików w chmurze.
- Widok - logiczny zestaw danych, który jest obliczany za każdym razem, gdy jest zapytany. Jest przydatny do dzielenia dużych instrukcji na łatwiejsze w zarządzaniu zapytania. Tabele Delta Live nie publikują widoków poza rurociągiem, więc mogą być przydatne jako zapytania pośrednie, które nie powinny być udostępniane użytkownikom.
- Widok zmaterializowany - widok z wynikami obliczonymi wcześniej. Te zbiory danych są odświeżane za każdym razem, gdy rurociąg aktualizuje się, aby odzwierciedlić zmiany w poprzednich zbiorach danych, które mogły zostać zmienione. Zmaterializowane widoki są przydatne, gdy używa ich wielu kolejnych zapytań, ponieważ nie muszą być obliczane za każdym razem, gdy są pytane, w przeciwieństwie do widoków zwykłych.
Delta Live Tables używają tych zestawów danych do definiowania potoku, który jest główną jednostką do uruchamiania przepływów pracy przetwarzania danych. Rurociąg jest ogólnie zdefiniowany w pliku źródłowym (notatniku lub pliku python), który zawiera wszystkie definicje tabel strumieniowych i zmaterializowanych widoków, które są zadeklarowane w SQL lub w Pythonie. Po utworzeniu kodu rurociągu z jego logiką musimy stworzyć sam rurociąg, podając jego konfigurację. Chociaż większość ustawień jest opcjonalna, a platforma może kontynuować ustawienia domyślne, musimy wziąć pod uwagę schemat docelowy jeśli chcemy opublikować dane, ponieważ w domyślnych pociągach DTL nie są wyświetlane żadne tabele do Hive metastore ani Unity Catalog.
Poniżej wymieniono niektóre kluczowe funkcje frameworka Delta Live Tables:
- Zautomatyzowane zarządzanie zależnościami i wizualizacja pociągu - DLT określa zależności w całym pociągu i renderuje wykres przepływu danych w celu wizualizacji linii danych przy jednoczesnym sprawdzaniu błędów składniowych.
- Egzekwowanie jakości danych - możemy określić oczekiwania dotyczące kontroli dokładności danych, zapewniając jednocześnie elastyczność w sposobie przetwarzania nieprawidłowych zapisów. DLT może zawiesić cały potok, pominąć błędne wiersze lub zapisać nieprawidłowe rekordy podczas zgłaszania awarii w metrykach zestawu danych.
- Przetwarzanie danych przyrostowych i strumieniowych - DLT obsługuje Autoloader, który pozwala na przesyłanie strumieniowo plików w chmurze w czasie rzeczywistym bez określania dodatkowych usług w chmurze i zmniejszania ilości przetwarzanych danych w porównaniu z przeładowaniami danych wsadowych.
- Wbudowane monitorowanie i obserwowalność - zapewnia możliwości monitorowania i rejestrowania. Możemy śledzić statystyki środowiska wykonawczego, takie jak przetwarzane rekordy, używany czas wykonawczy, obserwować kondycję rurociągu i monitorować trendy w jakości danych.
Przykład rurociągów DLT
Opis rurociągów
W tym rozdziale zostanie utworzony przykładowy potok Delta Live Tables, aby zademonstrować możliwości frameworka. W tym przykładzie przedstawiono rurociąg wykorzystujący dane dostarczone przez Databricks dostępne w zestawach danych /databricks-datasets na DBFS, w szczególności w zestawie danych retail-org.
Proces odczytuje dane zamówień sprzedaży, połączy się z tabelą zawierającą informacje o produkcie i pobierze listę najlepiej sprzedających się kategorii produktów. Pokażemy, jak odczytywać dane CSV i JSON do tabeli warstwy brązu, odczytywać surowe dane i używać oczekiwań DLT do zapisywania oczyszczonych danych na warstwie srebra i wreszcie zapisać zagregowane dane do tabeli warstwy złotej.
Wymagania dotyczące uruchomienia przepływu pracy w obszarze roboczym Databricks:
- uprawnienia do tworzenia klastra - środowisko wykonawcze DLT tworzy klaster przed uruchomieniem potoku, więc ten potok nie powiedzie się, jeśli nie masz takich uprawnień w obszarze roboczym
- dostęp do danych odczytu/zapisu w przerzutach ula - rurociąg wyprowadzi dane jako tabele w przerzutach ula
- upewnij się, że w obszarze roboczym włączono Delta Live Tables, ponieważ niektóre starsze obszary robocze bez poziomu cenowego premium mogą nie mieć tej funkcji
Kroki tworzenia rurociągu
Najpierw utwórz notatnik Databricks SQL i dołącz następujący kod dodając każdy fragment SQL do oddzielnej komórki notatnika.
Tutaj określamy warstwę brązu odpowiadającą pobieraniu danych, która wykorzystuje funkcje Autoloader do przyrostowego ładowania nowych danych w miarę ich przybycia. Tworzy to tabele przesyłania strumieniowego dla zamówień sprzedaży i produktów. Dane są odczytywane bezpośrednio z plików csv/json i są udostępniane jako tabele dla innych etapów potoku.
UTWÓRZ LUB ODŚWIEŻ TABELĘ STRUMIENIOWĄ sales_orders
KOMENTARZ „Lista sprzedaży, pobrana z /databricks-datasets.”
TBLPROPERTIES („DataLayer” = „brąz”)
JAKO
WYBIERZ* Z plików odczytu („/databricks-datasets/retail-org/sales_orders/”, „json”, mapa („CloudFiles.inferColumnTypes”, „true”));
TWORZENIE LUB ODŚWIEŻANIE produktów STREAMING TABLE
KOMENTARZ „Lista produktów spożywanych z /databricks-datasets.”
TBLPROPERTIES („DataLayer” = „brąz”)
AS SELECT* Z plików odczytu („/databricks-datasets/retail-org/products/”, „csv”, mapa („sep”, „;”))
W tym kroku łączymy dane sprzedaży z produktami, tworząc tabelę sprzedaży z dodaną kolumną kategorii produktów. Zwróć uwagę na przedrostek LIVE. przed każdym odwołaniem do tabeli DLT, ta składnia wskazuje odniesienie do innych tabel DLT dostępnych w pociągu. Zastosowaliśmy również kontrolę jakości danych, która zatrzyma wykonywanie rurociągu, jeśli istnieje identyfikator produktu, który istnieje w tabeli sales_orders, ale nie w produktach.
UTWÓRZ LUB ODŚWIEŻ TABELĘ PRZESYŁANIA STRUMIENIOWEGO product_sales_categorised (
OGRANICZENIE valid_products OCZEKUJ (mapping_product_id NIE JEST NULL) W PRZYPADKU NIEPOWODZENIA AKTUALIZACJI NARUSZENIA
)
PODZIELONE WEDŁUG (product_category)
KOMENTARZ „Sprzedaż produktów z kategorią produktu”
TBLPROPERTIES („DataLayer” = „srebrny”)
JAKO
WYBIERZ
product_details.id jako identyfikator produktu,
product_details.curr Waluta AS,
product_details.name jako nazwa produktu,
product_details.price jako cena produktu,
ilość product_details.qty AS,
product_details.unit jako jednostka produktu,
kategoria_produktu,
ID produktu jako identyfikator mapowania_produktu
OD (
WYBIERZ rozbij (zamówione produkty) JAKO szczegóły produktu ZE STRUMIENIA (Live.sales_orders)
) s
LEWO DOŁĄCZ DO LIVE.Products p
NA s.product_details.id = p.product_id
Na koniec tworzymy tabelę złota, która agreguje dane produktów według kategorii i filtruje tylko walutę USD.
UTWÓRZ LUB ODŚWIEŻ ZMATERIALIZOWANY WIDOK top_products
KOMENTARZ „Lista najlepiej sprzedających się produktów w USD”
TBLPROPERTIES („DataLayer” = „złoto”)
JAKO
WYBIERZ kategorię_produktu, numer formatu (SUMA (sprzedaży_produktu), 'USD, ###') jako całkowitą sprzedaż
OD
(
WYBIERZ kategorię_produktu, cenę_produktu* ilość JAKO produktu_sprzedaż
Z LIVE.PRODUCT_SALES_CATEGORISED
WHERE waluta = „USD”
)
GRUPUJ WEDŁUG kategorii_produktu
ZAMÓWIENIE WEDŁUG SUMY (product_sales) DESC
Uwaga: Tabele Delta Live nie są przeznaczone do interaktywnego działania w notebookach. Wykonanie komórki za pomocą poleceń DLT może sprawdzać tylko błędy składniowe. Aby uruchomić zapytania, należy skonfigurować notatnik jako część pociągu.
Teraz, gdy mamy gotowy notatnik, możemy iść dalej i stworzyć rurociąg:
- Idź do Stoły na żywo Delta na pasku bocznym i kliknij Utwórz rurociąg.
- Podaj szczegóły rurociągu:
- Nazwa
- Edycja produktu: Zaawansowana, potrzebna do jakości danych
- Ścieżka do nowo utworzonego notatnika
- Schemat docelowy - umieść dowolny schemat, do którego masz dostęp, tutaj używamy domyślnego na metastore Hive
- (opcjonalnie) obliczyć szczegóły.
- Kliknij przycisk Utwórz.
- Uruchom rurociąg, klikając przycisk Start w górnym panelu.
Wykonanie rurociągu i wyniki
Po uruchomieniu rurociągu możemy zobaczyć wykres wykonania ze wszystkimi zdefiniowanymi zestawami danych. Tutaj widzimy zaletę podejścia deklaratywnego, ponieważ nie powiedzieliśmy wprost, że product_sales_category powinna działać przed produktami i sprzedaż_zamówieniami, ale silnik wykonawczy wymyślił to za nas.
Po kliknięciu jednego z etapów rurociągu możemy zobaczyć szczegóły zbioru danych. Stąd możemy przejść bezpośrednio do katalogu danych, aby zobaczyć, jak wyglądają dane, co nie byłoby opcją, gdybyśmy nie określili schematu docelowego podczas definiowania rurociągu.
Możemy również sprawdzić nasze oczekiwania DQ zdefiniowane w tabeli product_sales_categorised. Nie ma awarii, ponieważ wszystkie identyfikatory produktów z sales_orders były dostępne w tabeli produktów.
Możemy również wrócić do naszego notebooka i uruchomić rurociąg stamtąd, gdy zostanie połączony z rurociągiem. Umożliwia łatwiejsze modyfikacje rurociągów i debugowanie, ponieważ nie musimy przechodzić tam iw tył między notebookiem a rurociągiem DLT.
Wniosek
Deklaratywne pociągi danych upraszczają tworzenie i utrzymywanie złożonych przepływów pracy, umożliwiając zespołom danych skupienie się na spostrzeżeniach dotyczących infrastruktury. Chociaż istnieją kompromisy w zakresie elastyczności i możliwego blokowania dostawców, korzyści płynące z szybszego wdrażania, łatwiejszej konserwacji i skupienia się na ostatecznym stanie bazy danych sprawiają, że deklaratywne rurociągi są potężnym narzędziem dla nowoczesnych rozwiązań danych.
Delta Live Tables jest przykładem podejścia deklaratywnego. Pozwala użytkownikom tworzyć niezawodne rurociągi przetwarzania danych za pomocą Pythona lub SQL. Oprócz automatycznej orkiestracji zadań zapewnia kilka innych przydatnych funkcji, takich jak kontrola jakości danych, przyrostowe przetwarzanie danych i obserwowalność oraz pozwala wykorzystać zalety platformy Databricks
