Porady, zalecenia i funkcje służące do tworzenia i testowania potoków tabel na żywo usługi Delta

W tym artykule opisano wzorce, których można użyć do tworzenia i testowania potoków tabel na żywo delty. Za pomocą ustawień potoku funkcja Delta Live Tables umożliwia określenie konfiguracji w celu izolowania potoków w środowiskach programistycznych, testowych i produkcyjnych. Zalecenia tego artykułu dotyczą programowania kodu w języku SQL i Python.

Usługa Databricks zaleca używanie parametrów do pisania rozszerzalnego kodu delta Live Tables. Jest to szczególnie przydatne w przypadku pisania przenośnego kodu między środowiskami deweloperskimi, testowymi i prod. Możesz na przykład wskazać potoki na danych testowych ze znanymi problemami, aby przetestować odporność kodu. Zobacz Kontrolowanie źródeł danych przy użyciu parametrów.

Uruchamianie aktualizacji potoku przy użyciu trybu programowania

Funkcja Delta Live Tables ma przełącznik interfejsu użytkownika umożliwiający kontrolowanie, czy aktualizacje potoku są uruchamiane w trybie programowania, czy produkcyjnym. Ten tryb kontroluje sposób przetwarzania aktualizacji potoku, w tym:

• Tryb programowania nie powoduje natychmiastowego zakończenia zasobów obliczeniowych po pomyślnym zakończeniu aktualizacji lub jej awarii. Możesz ponownie użyć tych samych zasobów obliczeniowych, aby uruchomić wiele aktualizacji potoku bez oczekiwania na uruchomienie klastra.
• Tryb programowania nie ponawia próby automatycznie po awarii zadania, co umożliwia natychmiastowe wykrywanie i naprawianie błędów logicznych lub składniowych w potoku.

Usługa Databricks zaleca używanie trybu programowania podczas programowania i testowania. Jednak podczas wdrażania w środowisku produkcyjnym zawsze przełączaj się do trybu produkcyjnego.

Zobacz Tryby programowania i produkcji.

Testowanie kodu źródłowego potoku bez oczekiwania na zaktualizowanie tabel

Aby sprawdzić problemy z kodem źródłowym potoku, takie jak błędy składni i analizy, podczas programowania i testowania, można uruchomić aktualizację Weryfikuj. Validate Ponieważ aktualizacja weryfikuje tylko poprawność kodu źródłowego potoku bez uruchamiania rzeczywistej aktualizacji w dowolnych tabelach, można szybciej identyfikować i rozwiązywać problemy przed uruchomieniem rzeczywistej aktualizacji potoku.

Określanie schematu docelowego we wszystkich fazach cyklu życia programowania

Wszystkie zestawy danych w potoku delta Live Tables odwołują się do LIVE schematu wirtualnego, który jest niedostępny poza potokiem. Jeśli zostanie określony schemat docelowy, LIVE wirtualny schemat wskazuje schemat docelowy. Należy określić schemat docelowy, aby przejrzeć wyniki zapisane w każdej tabeli podczas aktualizacji.

Należy określić schemat docelowy, który jest unikatowy dla danego środowiska. Każda tabela w danym schemacie może być aktualizowana tylko przez jeden potok.

Te środowiska można odizolować, tworząc oddzielne potoki na potrzeby programowania, testowania i produkcji z różnymi celami. Użycie docelowego parametru schematu umożliwia usunięcie logiki, która używa interpolacji ciągów lub innych widżetów lub parametrów do kontrolowania źródeł danych i obiektów docelowych.

Zobacz Używanie wykazu aparatu Unity z potokami delta Live Tables i Używanie potoków delta Live Tables ze starszym magazynem metadanych Hive.

Zarządzanie potokami delty tabel na żywo za pomocą folderów Git usługi Databricks

Usługa Databricks zaleca używanie folderów Git podczas tworzenia, testowania i wdrażania potoku delta Live Tables w środowisku produkcyjnym. Foldery Git umożliwiają wykonywanie następujących czynności:

• Śledzenie zmian kodu w czasie.
• Scalanie zmian, które wprowadza wielu deweloperów.
• Praktyki programistyczne, takie jak przeglądy kodu.

Usługa Databricks zaleca skonfigurowanie pojedynczego repozytorium Git dla całego kodu związanego z potokiem.

Każdy deweloper powinien mieć własny folder Git usługi Databricks skonfigurowany do programowania. Podczas programowania użytkownik konfiguruje własny potok z folderu Git usługi Databricks i testuje nową logikę przy użyciu zestawów danych programistycznych i izolowanych schematów i lokalizacji. Po zakończeniu prac programistycznych użytkownik zatwierdza i wypycha zmiany do swojej gałęzi w centralnym repozytorium Git i otwiera żądanie ściągnięcia względem gałęzi testowej lub QA.

Gałąź wynikowa powinna być wyewidencjonowana w folderze Git usługi Databricks, a potok powinien być skonfigurowany przy użyciu testowych zestawów danych i schematu programowania. Przy założeniu, że logika jest uruchamiana zgodnie z oczekiwaniami, żądanie ściągnięcia lub gałąź wydania powinna być przygotowana do wypychania zmian do środowiska produkcyjnego.

Foldery Git mogą służyć do synchronizowania kodu między środowiskami, ale ustawienia potoku muszą być aktualizowane ręcznie lub za pomocą narzędzi takich jak Terraform.

Ten przepływ pracy jest podobny do używania folderów Git dla ciągłej integracji/ciągłego wdrażania we wszystkich zadaniach usługi Databricks. Zobacz Techniki ciągłej integracji/ciągłego wdrażania za pomocą folderów Git i Databricks Git (Repos).

Segmentowanie kodu źródłowego na potrzeby kroków pozyskiwania i przekształcania

Usługa Databricks zaleca izolowanie zapytań, które pozyskują dane z logiki przekształcania, która wzbogaca i weryfikuje dane. Jeśli organizujesz kod źródłowy na potrzeby pozyskiwania danych z programowania lub testowania źródeł danych w katalogu niezależnie od logiki pozyskiwania danych produkcyjnych, możesz skonfigurować potoki dla różnych środowisk z zestawami danych specyficznymi dla tych środowisk. Można na przykład przyspieszyć programowanie przy użyciu mniejszych zestawów danych na potrzeby testowania. Zobacz Tworzenie przykładowych zestawów danych na potrzeby programowania i testowania.

Można również użyć parametrów do kontrolowania źródeł danych na potrzeby programowania, testowania i produkcji. Zobacz Use parameters with Delta Live Tables pipelines (Używanie parametrów z potokami delta live tables).

Ponieważ potoki delta Live Tables używają schematu wirtualnego LIVE do zarządzania wszystkimi relacjami zestawu danych, konfigurując potoki programowania i testowania przy użyciu kodu źródłowego pozyskiwania, które ładuje przykładowe dane, możesz zastąpić przykładowe zestawy danych przy użyciu nazw tabel produkcyjnych do testowania kodu. Tej samej logiki przekształcania można używać we wszystkich środowiskach.

Tworzenie przykładowych zestawów danych na potrzeby programowania i testowania

Usługa Databricks zaleca tworzenie i testowanie zestawów danych do testowania logiki potoku z oczekiwanymi danymi i potencjalnie nieprawidłowo sformułowanymi lub uszkodzonymi rekordami. Istnieje wiele sposobów tworzenia zestawów danych, które mogą być przydatne do programowania i testowania, w tym:

• Wybierz podzbiór danych z produkcyjnego zestawu danych.
• Użyj anonimowych lub sztucznie wygenerowanych danych dla źródeł zawierających dane osobowe.
• Tworzenie danych testowych z dobrze zdefiniowanymi wynikami na podstawie logiki transformacji podrzędnej.
• Przewidywanie potencjalnych uszkodzeń danych, nieprawidłowo sformułowanych rekordów i zmian danych nadrzędnych przez utworzenie rekordów, które przerywają oczekiwania schematu danych.

Jeśli na przykład masz notes, który definiuje zestaw danych przy użyciu następującego kodu:

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")

Możesz utworzyć przykładowy zestaw danych zawierający określone rekordy przy użyciu zapytania, takiego jak następujące:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

W poniższym przykładzie pokazano filtrowanie opublikowanych danych w celu utworzenia podzestawu danych produkcyjnych na potrzeby programowania lub testowania:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

Aby użyć tych różnych zestawów danych, utwórz wiele potoków za pomocą notesów implementowania logiki przekształcania. Każdy potok może odczytywać dane z LIVE.input_data zestawu danych, ale jest skonfigurowany tak, aby zawierał notes, który tworzy zestaw danych specyficzny dla środowiska.