Dodaj warunki SQL do wyzwalaczy zadań

Użyj warunku SQL, aby sprawdzić dane przed rozpoczęciem uruchomienia zadania wyzwalanego. Gdy wyzwalacz się uruchamia, Azure Databricks uruchamia zapisane zapytanie SQL w wybranym przez Ciebie magazynie danych SQL. Uruchomienie rozpoczyna się tylko wtedy, gdy wynik zapytania spełnia warunek. Na przykład uruchom zadanie tylko wtedy, gdy tabela upstream zakończy ładowanie lub sprawdzenie jakości danych przejdzie, bez dodawania osobnego zadania checkera do zadania.

Requirements

• Musisz mieć uprawnienie CAN MANAGE dla zadania, aby skonfigurować jego wyzwalacze.
• Potrzebujesz zapisanego zapytania , które nie używa parametrów zapytania. Musisz mieć dostęp do zapytania i móc je uruchomić w wybranym przez siebie magazynie SQL.
• Tożsamość Run as zadania musi być w stanie otworzyć zapisane zapytanie, mieć uprawnienie CAN USE w SQL warehouse oraz mieć dostęp do odczytu do każdej tabeli, którą zapytanie odczytuje. Zapytanie warunkowe wykonuje się przy użyciu tej tożsamości.

Jak działają warunki SQL

Wyzwalacz decyduje, kiedy przeprowadzić sprawdzanie. Warunek SQL decyduje, czy uruchomić przebieg. Po uruchomieniu wyzwalacza Azure Databricks uruchamia zapytanie w trybie tylko do odczytu. Uruchomienie rozpoczyna się dopiero wtedy, gdy spełnione są zarówno wyzwalacz, jak i warunek SQL.

Możesz dodać jeden warunek SQL do wyzwalacza zaplanowanejaktualizacji tabeli, przybycia pliku, aktualizacji modelu lub zakończenia zadania. Ciągłe wyzwalacze nie wspierają warunków SQL.

Wybierz sposób, w jaki Azure Databricks ocenia wynik zapytania:

W przypadku zmian wartości wyniku, Azure Databricks uruchamia zapytanie w tle zaraz po zapisaniu wyzwalacza i przechowuje wynik jako punkt odniesienia. To sprawdzenie nie uruchamia przebiegu. Późniejsze sprawdzenia rozpoczynają przebieg, gdy wynik różni się od zapisanej wartości. Zmiana zapytania, magazynu danych SQL lub typu warunku na wyzwalaczu resetuje linię bazową, a Azure Databricks przechowuje nową w ten sam sposób. Wstrzymanie wyzwalacza lub zmiana innych ustawień wyzwalacza również może go zresetować. Edycja tekstu zapisanego zapytania nie resetuje go.

Każdy test działa następująco:

• Kontrola, w tym uruchomienie SQL warehouse, przekracza limit czasu po 5 minutach. Jeśli sprawdzanie przekroczy limit czasu, nie rozpocznie się żadne uruchomienie, a wyzwalacz sprawdzi ponownie przy kolejnej ocenie.
• Trigger uruchamia co najwyżej jedno sprawdzenie naraz. Jeśli wyzwalacz ma zostać uruchomiony, gdy kontrola nadal trwa, Azure Databricks pomija tę ocenę zamiast ją kolejkować.
• Jeśli zapytanie zawiera więcej niż jedną instrukcję, używany jest tylko wynik ostatniej instrukcji.
• Warunki SQL dotyczą tylko uruchomień uruchamianych przez wyzwalacz. Uruchom teraz , a inne ręczne uruchomienia nie sprawdzają warunków SQL.

SELECT 1
FROM main.sales.orders
WHERE order_date = current_date()
HAVING count(*) > 100

Dodaj warunek SQL do wyzwalacza

1. W pasku bocznym przestrzeni roboczej kliknij Jobs & Pipelines, a następnie otwórz job.
2. W Harmonogramach i Wyzwalaczach, kliknij Dodaj wyzwalacz lub edytuj istniejący wyzwalacz.
3. Wybierz typ wyzwalacza i skonfiguruj wyzwalacz.
4. Rozwiń Zaawansowane, a następnie kliknij Dodaj warunek SQL.
5. Wybierz zapytanie SQL i hurtownię SQL.
6. W sekcji Wyzwalacz kiedy wybierz Zapytanie zwraca wiersze lub Wartość wyniku zmienia się.
7. Kliknij Zapisz.

Wyzwalacz testowy sprawdza, czy zadanie może korzystać z zapisanego zapytania. Potwierdza, że zapytanie istnieje, nie jest w koszu i nie ma żadnych parametrów, ale nie uruchamia zapytania. Aby zobaczyć wynik zapytania, uruchom je w edytorze SQL.

Aby usunąć warunek, edytuj wyzwalacz, rozwiń Zaawansowane i kliknij Usuń warunek SQL.

Konfiguruj za pomocą API, CLI lub pakietów

Ustaw sql_condition z sql_query_id, warehouse_id, oraz trigger_mode. Dla zaplanowanego wyzwalacza, który używa wyrażenia crona, ustaw go w schedule. W przypadku innych typów wyzwalaczy ustaw to w trigger, obok ustawień typu wyzwalacza. W wersji beta Multiple Triggers Beta ustaw to dla każdego wpisu w triggers.

interfejs API REST

Zapisz to żądanie jako update-job.json i wyślij je do POST /api/2.2/jobs/update w interfejsie API Jobs. Zastąp identyfikatory identyfikatorami zadania, zapisanego zapytania i magazynu SQL.

{
  "job_id": 9001,
  "new_settings": {
    "trigger": {
      "pause_status": "UNPAUSED",
      "table_update": {
        "table_names": ["main.sales.orders"],
        "condition": "ANY_UPDATED"
      },
      "sql_condition": {
        "sql_query_id": "fe25e731-92f2-4838-9fb2-1ca364320a3d",
        "warehouse_id": "5d409943fcd32c6f",
        "trigger_mode": "QUERY_RETURNS_ROWS"
      }
    }
  }
}

CLI

Zapisz ciało żądania z zakładki REST API jako update-job.json, a następnie uruchom:

databricks api post /api/2.2/jobs/update --json @update-job.json

Bundles

W przypadku pakietów automatyzacji deklaratywnej dodaj następujące ustawienia do istniejącego zasobu zadania, obok jego zadań:

resources:
  jobs:
    orders_report:
      trigger:
        pause_status: UNPAUSED
        periodic:
          interval: 1
          unit: DAYS
        sql_condition:
          sql_query_id: fe25e731-92f2-4838-9fb2-1ca364320a3d
          warehouse_id: 5d409943fcd32c6f
          trigger_mode: RESULT_VALUE_CHANGES

Pakiety nie obsługują tworzenia zapisanych zapytań. Najpierw utwórz zapytanie w workspace, a następnie odwołaj się do jego ID.

Całość jobs/update, którą wysyłasz do sql_condition, zastępuje obecną jako całość, więc uwzględnij wszystkie jej pola. Jeśli pominiesz sql_condition, obecny stan pozostaje. Aby zaktualizować wiele wyzwalaczy, zobacz Dodawanie wielu wyzwalaczy do zadania.

Monitorowanie sprawdzania warunków SQL

• Dla zaplanowanych wyzwalaczy status wyzwalacza na stronie zadania pokazuje, czy ostatni warunek SQL został spełniony. Kliknij Szczegóły wykonania zapytania, aby otworzyć instrukcję w historii zapytań.
• Aby odczytać ostatnie sprawdzenie, które zakończyło się bez błędu, wywołaj API Get job z include_trigger_state=true i odczytaj trigger_state.sql_condition. Pole latest_condition_evaluation_satisfied pokazuje, czy dane sprawdzenie spełniało warunek, a latest_condition_evaluation_sql_statement_id identyfikuje jego wpis w historii zapytań. Nieudane sprawdzenie nie zmienia tych pól. W przypadku wielu wyzwalaczy przeczytaj trigger_details[].state.sql_condition.
• Dla każdego uruchomienia uruchomionego przez warunek SQL pole Launched na liście runów oraz na stronie szczegółów uruchomienia pokazuje tag SQL. Kliknij go, a następnie kliknij Szczegóły wykonania zapytania, aby otworzyć wpis tego uruchomienia w historii zapytań.
• Jeśli sprawdzenie nie uda się z powodu, który możesz naprawić, błąd pojawia się w statusie wyzwalacza na stronie zadania. Azure Databricks wysyła również ten błąd do powiadomień o awarii zadania, w tym do odbiorców e-mail i miejsc docelowych webhooków. Dostajesz jedno powiadomienie, gdy warunek roboczy zaczyna zawodzić, a nie jedno za każdą nieudaną kontrolę. Błąd pozostaje do następnego skutecznego sprawdzenia. Zobacz Dodawanie powiadomień dotyczących zadania.

Każde sprawdzenie działa jako instrukcja SQL w twoim magazynie SQL. Aby przeglądać kontrole w czasie, zapytaj tabelę systemu historii zapytań dla hurtowni.

Troubleshooting

Limitations

• Każdy wyzwalacz obsługuje jeden warunek SQL.
• Ciągłe wyzwalacze nie wspierają warunków SQL.
• Zapytania warunkowe działają tylko w hurtowniach SQL, w trybie tylko do odczytu.
• Kontrola, w tym uruchomienie SQL warehouse, przekracza limit czasu po 5 minutach.
• Wyzwalacz przechowuje tylko swoje ostatnie sprawdzenie, a nie pełną historię każdego sprawdzenia. Aby zobaczyć wcześniejsze kontrole, użyj tagu SQL w uruchomieniach, w których warunek został uruchomiony, lub historii zapytań.
• Kontrole są wykonywane w twojej hurtowni SQL i są rozliczane jako użycie hurtowni SQL. Kontrola może uruchomić zatrzymany magazyn.
• Wyzwalacze z warunkami SQL liczą się do limitu 12 000 aktywnych wyzwalaczy w obszarze roboczym.