Uruchom update w potoku Delta Live Tables

W tym artykule opisano aktualizacje potoku i dostarcza szczegółowe informacje na temat uruchamiania update.

Co to jest potok update?

Po utworzeniu potoku i przygotowaniu go do uruchomienia, rozpoczynacie uruchamianie update. Rurociąg update wykonuje następujące czynności:

• Uruchamia klaster z poprawną konfiguracją.
• Odnajduje wszystkie zdefiniowane tables i views oraz sprawdza błędy analizy, takie jak nieprawidłowe nazwy column, brakujące zależności i błędy składni.
• Tworzy lub aktualizuje tables i views z najnowszymi dostępnymi danymi.

Korzystając z sprawdzania poprawności update, możesz sprawdzić, czy występują problemy w kodzie źródłowym potoku bez oczekiwania na utworzenie lub zaktualizowanie tables. Ta funkcja jest przydatna podczas opracowywania lub testowania kanałów, ponieważ umożliwia szybkie znajdowanie i naprawianie błędów w kanale, takich jak niepoprawne nazwy table lub column.

Jak są wyzwalane aktualizacje przepływu?

Użyj jednej z następujących opcji, aby uruchomić aktualizacje potoku:

Wyzwalacz Update	Szczegóły
Instrukcja	Aktualizacje potoków można wyzwalać ręcznie z interfejsu użytkownika potoku, potoków oznaczonych jako listlub notatnika dołączonego do potoku. Zobacz Ręczne uruchamianie potoku update i Tworzenie i debugowanie potoków usługi Delta Live Tables w notatnikach.
Zaplanowane	Można zaplanować aktualizacje potoków za pomocą zadań. Zobacz zadanie potoku Delta Live Tables dotyczące zadań.
Programatyczny	Aktualizacje można wyzwalać programowo przy użyciu narzędzi innych firm, interfejsów API i wiersza poleceń. Zobacz Uruchom potok Delta Live Tables w przepływie pracy oraz API potoku.

ręczne uruchomienie potoku update

Użyj jednej z następujących opcji, aby ręcznie wyzwolić pipeline update:

• Kliknij przycisk na stronie szczegółów potoku.
• W potokach listkliknij w akcjach column.

Uwaga

Domyślnym zachowaniem ręcznie wyzwalanych aktualizacji potoku jest refresh wszystkich zestawów danych zdefiniowanych w potoku.

semantyka potoku refresh

W poniższej table opisano zachowania zmaterializowanego views i strumieniowania tables dla domyślnego refresh i pełnego refresh:

typ Update	Semantyka zmaterializowanego widoku	Semantyka przesyłania strumieniowego table
Refresh (ustawienie domyślne)	Aktualizuje wyniki odzwierciedlające bieżące wyniki dla zapytania definiującego.	Przetwarza nowe rekordy za pomocą logiki zdefiniowanej w przesyłaniu strumieniowym tables i przepływach.
Pełna refresh	Aktualizuje wyniki odzwierciedlające bieżące wyniki dla zapytania definiującego.	Czyści dane strumieniowania z tables, usuwa informacje o stanie (punkty kontrolne) z przepływów i ponownie przetwarza wszystkie zapisy ze źródła danych.

Domyślnie wszystkie views są zmaterializowane i tables są przesyłane strumieniowo w potoku refresh z każdym update. Można opcjonalnie pominąć tables z aktualizacji, korzystając z następujących funkcji:

• Select tables dla refresh: użyj tego interfejsu użytkownika, aby dodać lub remove zmaterializowane views i przesyłać strumieniowo tables przed uruchomieniem update. Zobacz Rozpocznij potok update dla wybranego tables.
• Refresh nie powiodło się tables: Uruchom update dla niepowodzenia zmaterializowanego views i przesyłania strumieniowego tables, w tym zależności wychodzących. Zobacz Uruchom update potok tablesdla niepowodzenia.

Obie te funkcje obsługują domyślną semantykę refresh lub pełne refresh. Opcjonalnie możesz użyć Selecttables dla okna dialogowego refresh, aby wykluczyć dodatkowe tables podczas uruchamiania refresh dla błędów tables.

Czy należy używać pełnej refresh?

Usługa Databricks zaleca uruchamianie pełnych odświeżeń tylko wtedy, gdy jest to konieczne. Pełne refresh zawsze ponownie przetwarza wszystkie rekordy pochodzące z określonych źródeł danych, korzystając z logiki definiującej zbiór danych. Czas i zasoby potrzebne do ukończenia pełnego refresh są skorelowane z rozmiarem danych źródłowych.

Zmaterializowane views zwracają te same wyniki, niezależnie od tego, czy jest używana domyślna czy pełna refresh. Użycie pełnej refresh z przesyłaniem strumieniowym tables resetuje wszystkie informacje o stanie przetwarzania i punktach kontrolnych oraz może spowodować utratę rekordów, jeśli dane wejściowe nie będą już dostępne.

Usługa Databricks zaleca tylko pełne refresh, gdy wejściowe źródła danych zawierają dane potrzebne do odtworzenia żądanego stanu table lub widoku. Rozważmy następujące scenariusze: dane źródłowe wejściowe where nie są już dostępne, a wynik uruchomienia całkowitego refresh:

Źródło danych	Brak danych wejściowych dotyczących przyczyny	Wynik pełnej kalkulacji refresh
Kafka	Próg krótkiego przechowywania	Rekordy, które nie są już obecne w źródle platformy Kafka, są usuwane z docelowego table.
Pliki w przechowywaniu obiektowym	Zasady cyklu życia	Pliki danych, które nie są już obecne w katalogu źródłowym, są usuwane z docelowego table.
Rekordy w table	Usunięto pod kątem zgodności	Przetwarzane są tylko rekordy obecne w źródle table.

Aby zapobiec uruchamianiu pełnych odświeżeń w table lub widoku, set właściwości tablepipelines.reset.allowed w celu false. Zobacz właściwości Delta Live Tablestable. Możesz również użyć przepływu dołączania , aby dołączyć dane do istniejącego przesyłania strumieniowego bez konieczności pełnego .

Rozpocznij update pipeline dla wybranej tables

Można ponownie przetwarzać dane tylko dla wybranych tables w ciągach przetwarzania. Na przykład podczas rozwoju zmienia się tylko jeden table i chcesz skrócić czas testowania, lub gdy potok update zawodzi i chcesz refresh tylko nieudane tables.

Uwaga

Można używać selektywnych refresh tylko z wyzwalanymi potokami.

Aby uruchomić update, który odświeża tylko wybrane tables, na stronie szczegółów potoku :

1. Kliknij Selecttables, aby refresh. Zostanie wyświetlone okno dialogowe Selecttables dla refresh.

   Jeśli nie widzisz przycisku Selecttables dla refresh, upewnij się, że strona szczegółów potoku wyświetla najnowszą update i że update została ukończona. Jeśli DAG nie jest wyświetlany dla najnowszego update, na przykład dlatego, że update się nie udało, przycisk Selecttables dla refresh nie jest wyświetlany.

2. Aby selecttables do refresh, kliknij na każdy table. Wybrane tables są wyróżnione i oznaczone etykietami. Aby removetable z update, ponownie kliknij table.

3. Kliknij opcje Refresh wyboru.

   Uwaga

   Przycisk wyboru Refresh wyświetla liczbę wybranych tables w nawiasach.

Aby ponownie przetworzyć dane już pozyskane dla wybranego tables, kliknij obok przycisku wyboru Refresh i kliknij przycisk wyboru Pełnego Refresh.

Rozpocznij potok update w przypadku tables niepowodzenia

Jeśli update przepływu zakończy się niepowodzeniem z powodu błędów w co najmniej jednej tables na wykresie przepływu, możesz uruchomić update tylko dla tables, które zakończyły się niepowodzeniem, oraz wszelkie zależności podrzędne.

Uwaga

Wykluczone tables nie są odświeżane, nawet jeśli zależą one od niepowodzenia table.

Aby updatetableszakończyło się niepowodzeniem, na stronie Szczegóły potoku kliknij przycisk Refreshtableszakończyło się niepowodzeniem.

Aby update tylko wybrana tableszakończyła się niepowodzeniem:

1. Kliknij przycisk obok przycisku Refreshtables, a następnie kliknij przycisk Selecttables dla refresh. Zostanie wyświetlone okno dialogowe Selecttables dla refresh.

2. Aby selecttables do refresh, kliknij każdy table. Wybrane tables są wyróżnione i oznaczone etykietami. Aby removetable z update, kliknij ponownie table.

3. Kliknij zaznaczenie Refresh.

   Uwaga

   Przycisk wyboru Refresh wyświetla liczbę wybranych tables w nawiasach.

Aby ponownie przetworzyć dane już pozyskane dla wybranej tables, kliknij przycisk obok przycisku wyboru Refresh i kliknij przycisk Pełny wybór Refresh.

Sprawdź potok pod kątem błędów bez oczekiwania na tables do update

Ważne

Funkcja Delta Live TablesValidateupdate jest dostępna w publicznej wersji beta.

Aby sprawdzić, czy kod źródłowy potoku jest prawidłowy bez pełnego update, użyj Validate. Validate update rozwiązuje definicje zestawów danych i przepływów zdefiniowanych w potoku, ale nie materializuje ani nie publikuje żadnych zestawów danych. Błędy występujące podczas walidacji, takie jak niepoprawne nazwy table lub column, są zgłaszane w interfejsie użytkownika.

Aby uruchomić Validateupdate, kliknij na stronie szczegółów potoku obok przycisku Start, a następnie kliknij Weryfikuj.

Po zakończeniu Validateupdate dziennik zdarzeń pokazuje zdarzenia związane wyłącznie z Validateupdate, a w DAG nie są wyświetlane żadne metryki. Jeśli zostaną znalezione błędy, szczegółowe informacje są dostępne w dzienniku zdarzeń.

Wyniki są widoczne tylko dla najnowszych Validateupdate. Jeśli Validateupdate był ostatnio uruchomiony update, możesz zobaczyć wyniki, wybierając je w historii update. Jeśli po Validateupdatezostanie uruchomiony inny update, wyniki nie będą już dostępne w interfejsie użytkownika.

Tryby programowania i produkcji

Wykonywanie potoku można optimize, przełączając się między trybami programowania i produkcji. Aby przełączać się między tymi dwoma trybami w interfejsie użytkownika Pipelines, użyj przycisków ikon przełącznika środowiska . Domyślnie potoki są uruchamiane w trybie programowania.

Po uruchomieniu potoku w trybie programowania system delta Live Tables wykonuje następujące czynności:

• Ponownie używa klastra, aby uniknąć obciążenia związanego z ponownym uruchamianiem. Domyślnie klastry działają przez dwie godziny, gdy tryb programowania jest włączony. Możesz to zmienić za pomocą ustawienia pipelines.clusterShutdown.delay w Konfiguracja obliczeń dla potoku Delta Live Tables.
• Wyłącza ponawianie prób potoku, dzięki czemu można natychmiast wykrywać i naprawiać błędy.

W trybie produkcyjnym system delta live Tables wykonuje następujące czynności:

• Uruchamia ponownie klaster w przypadku określonych błędów, które mogą być naprawione, w tym przecieków pamięci i przestarzałego credentials.
• Ponawia próbę wykonania w przypadku określonych błędów, takich jak niepowodzenie uruchomienia klastra.

Uwaga

Przełączanie między trybami programowania i produkcji steruje tylko zachowaniem wykonywania klastra i potoku. Miejsca przechowywania i schematy docelowe w catalog do publikowania tables powinny być skonfigurowane jako część ustawień potoku i nie ulegają zmianie przy przełączaniu między trybami.