Einführung in Aufgaben

Derzeit kann eine Aufgabe verwendet werden, um eine einzelne SQL-Anweisung auszuführen oder auch eine gespeicherte Prozedur aufzurufen.

Aufgaben können mit Tabellenstreams für fortlaufende ELT-Workflows kombiniert werden, um kürzlich geänderte Tabellenzeilen zu verarbeiten. Streams stellen genau einmal die Semantik bei neuen oder geänderten Daten einer Tabelle sicher.

Aufgaben können auch unabhängig voneinander verwendet werden, um periodische Berichte zu generieren, indem Zeilen in eine Berichtstabelle eingefügt oder zusammengeführt werden oder andere periodische Arbeiten ausgeführt werden.

Unter diesem Thema:

Aufgabenplanung

Es gibt keine Ereignisquelle, die eine Aufgabe auslösen kann. Stattdessen wird eine Aufgabe nach einem Zeitplan ausgeführt, der beim Erstellen einer Aufgabe (mit CREATE TASK) oder später (mit ALTER TASK) definiert werden kann.

Snowflake stellt sicher, dass zu einem bestimmten Zeitpunkt immer nur eine Instanz einer Aufgabe mit einem Zeitplan (d. h. eine eigenständige Aufgabe oder die Stammaufgabe in einem Aufgabenstrukturbaum) ausgeführt wird. Wenn eine Aufgabe zum Zeitpunkt der nächsten geplanten Ausführung noch immer ausgeführt wird, wird diese geplante Zeit übersprungen.

Erstellen eines Warehouse

Vorgeschlagene Best Practices für die Konfiguration von Warehouses sind unter Hinweise zu Warehouses beschrieben. Wir empfehlen, dass Sie die durchschnittliche Ausführungszeit einer bestimmten Aufgabe oder eines bestimmten Aufgabenstrukturbaums anhand eines festgelegten Warehouse analysieren, basierend auf der Lagergröße und dem Clustering sowie der Frage, ob das Warehouse von mehreren Prozessen gemeinsam genutzt wird oder nur für die Ausführung dieser einen Aufgabe (oder dieses Aufgabenstrukturbaums) vorgesehen ist.

Fragen Sie im Information Schema die Tabellenfunktion TASK_HISTORY ab. Die durchschnittliche Differenz zwischen der geplanten und der tatsächlichen Ausführungszeit einer Aufgabe ist die erwartete durchschnittliche Ausführungszeit der Aufgabe, die auch die Wartezeit der Aufgabe in der Warteschlange einschließt. Eine Aufgabe wird in die Warteschlange gestellt, wenn im Moment alle Server im Warehouse von anderen Prozessen verwendet werden.

Sofern die für die Aufgaben definierten SQL-Anweisungen nicht optimiert werden können (entweder durch Umschreiben der Anweisungen oder mithilfe gespeicherter Prozeduren), ist dies die erwartete durchschnittliche Ausführungszeit für die Aufgabe (oder den Aufgabenstrukturbaum). Wählen Sie anhand Ihrer Analyse die richtige Größe für das Warehouse aus, um sicherzustellen, dass die Aufgabe (oder der Aufgabenstrukturbaum) in diesem Fenster ausgeführt wird.

Die folgende Abbildung zeigt ein Fenster von 1 Minute, in der eine einzelne Aufgabe 20 Sekunden lang in der Warteschlange steht und dann 40 Sekunden lang ausgeführt wird.

Example task batch window

Die folgende Abbildung zeigt einen Aufgabenstrukturbaum, für dessen Ausführung durchschnittlich 5 Minuten erforderlich sind. Die Abbildung zeigt das Fenster für 2 Ausführungen des zu bearbeitenden Aufgabenstrukturbaums. Die Berechnung dieses Fensters beginnt beim geplanten Startzeitpunkt der Stammaufgabe und endet, wenn die letzte untergeordnete Aufgabe im Strukturbaum vollständig ausgeführt wurde. In diesem Beispiel wird der Aufgabenstrukturbaum für andere gleichzeitige Operationen freigegeben, die sich in der Warteschlange befinden, während jede der 3 Aufgaben im Baum ausgeführt wird. Diese parallelen Operationen verbrauchen alle verfügbaren Ressourcen, wenn die Ausführung jeder Aufgabe im Strukturbaum beendet ist und bevor die nächste Aufgabe ausgeführt wird. Infolgedessen enthält das Fenster für jede Aufgabe etwas Warteschlangenzeit für das Warten darauf, das andere Operationen abgeschlossen und die Server freigegeben werden.

Beachten Sie, dass selbst bei Ausführung dieses Aufgabenstrukturbaums in einem dedizierten Warehouse eine kurze Verzögerung zwischen dem Ende der Ausführung einer übergeordneten Aufgabe und dem Start einer untergeordneten Aufgabe auftritt. Allerdings wäre kein Warten in der Warteschlange für Ressourcen erforderlich, die gemeinsam mit anderen Operationen genutzt werden. Die von Ihnen gewählte Warehouse-Größe sollte groß genug sein, um mehrere untergeordnete Aufgaben zu bedienen, die gleichzeitig von übergeordneten Aufgaben ausgelöst werden.

Example tree of tasks batch window

Aufgabenplanung und Sommerzeit

Der Cron-Ausdruck in einer Aufgabendefinition unterstützt die Angabe einer Zeitzone. Eine geplante Aufgabe wird gemäß dem angegebenen Cron-Ausdruck in der Ortszeit für eine bestimmte Zeitzone ausgeführt. Bei der Planung von Aufgaben für Zeitzonen, die die Sommerzeit berücksichtigen, ist besondere Vorsicht geboten. Aufgaben, die zu bestimmten Zeiten an Tagen geplant sind, an denen der Übergang von der Standardzeit zur Sommerzeit (oder umgekehrt) erfolgt, können ein unerwartetes Verhalten aufweisen.

Beispiel:

  • Beim Wechsel von der Sommerzeit zur Standardzeit im Herbst wird eine Aufgabe, die um 1 AM in der Zeitzone Amerika/Los Angeles (d. h. 0 1 * * * America/Los_Angeles) beginnen soll, zweimal ausgeführt: einmal um 1 AM und noch einmal, wenn 1:59:59 AM auf 1:00:00 AM Ortszeit wechselt. Das heißt, es gibt zwei Zeitpunkte, an denen die Ortszeit 1 AM ist.

  • Beim Wechsel von der Standardzeit zur Sommerzeit im Frühling wird eine Aufgabe, die um 2 AM in der Zeitzone Amerika/Los Angeles (d. h. 0 2 * * * America/Los_Angeles) beginnen soll, überhaupt nicht ausgeführt, da die lokale Zeit von 1:59:59 AM auf 3:00:00 AM wechselt. Das heißt, es gibt an diesem Tag keinen Zeitpunkt, an dem die Ortszeit 2 AM ist.

Um unerwartete Aufgabenausführungen aufgrund der Sommerzeit zu vermeiden, planen Sie entweder:

  • keine Ausführung von Aufgaben zu einer bestimmten Zeit zwischen 1 AM und 3 AM (täglich oder an Wochentagen, zu denen auch Sonntage gehören) oder

  • passen Sie den Cron-Ausdruck für Aufgaben, die während dieser Zeiten zweimal im Jahr geplant sind, manuell an, um die Zeitverschiebung wegen der Sommerzeit auszugleichen.

Einfache Baumstruktur aus Aufgaben

Benutzer können eine einfache baumartige Struktur von Aufgaben definieren, die mit einer Stammaufgabe beginnt und durch Aufgabenabhängigkeiten miteinander verbunden ist. Die aktuelle Implementierung unterstützt einen einzelnen Pfad zwischen zwei beliebigen Knoten, d. h. eine einzelne Aufgabe kann nur eine einzige Vorgängeraufgabe (d. h. übergeordnete Aufgabe) haben. Dies unterscheidet sich von einer Struktur vom Typ Directed Acyclic Graph (DAG), bei der ein einzelner Knoten mehrere übergeordnete Knoten haben kann.

Tree of tasks

Eine Vorgängeraufgabe kann beim Erstellen einer Aufgabe definiert werden (mit CREATE TASK … AFTER) oder später (mit ALTER TASK … ADD AFTER). Die Stammaufgabe in der Baumstruktur sollte einen definierten Zeitplan haben. Jede der anderen Aufgaben in der Baumstruktur hat eine definierte Vorgängeraufgabe, um sie miteinander zu verknüpfen. Wenn die Ausführung einer Vorgängeraufgabe erfolgreich abgeschlossen wurde, wird die Ausführung aller untergeordneten Aufgaben ausgelöst, die diese Aufgabe in ihrer Definition als Vorgänger identifizieren.

Ein einfacher Aufgabenstrukturbaum ist auf maximal 1.000 Aufgaben insgesamt (einschließlich der Stammaufgabe) im Status „Fortgesetzt“ beschränkt. Eine einzelne Aufgabe im Strukturbaum kann nur eine Vorgängeraufgabe haben. Eine Aufgabe kann jedoch bis zu 100 untergeordnete Aufgaben aufweisen (d. h. andere Aufgaben, die die Aufgabe als Vorgänger identifizieren).

Derzeit können wir nicht garantieren, dass zu einem bestimmten Zeitpunkt nur eine Instanz einer Aufgabe mit einer definierten Vorgängeraufgabe ausgeführt wird.

Bemerkung

Eine kurze Verzögerung tritt auf, nachdem eine übergeordnete Aufgabe beendet und eine untergeordnete Aufgabe ausgeführt wird.

Um alle abhängigen Aufgaben, die an eine Stammaufgabe gebunden sind, rekursiv fortzusetzen, fragen Sie die Funktion SYSTEM$TASK_DEPENDENTS_ENABLE ab, anstatt jede Aufgabe einzeln fortzusetzen (mit ALTER TASK … RESUME).

Einfacher Aufgabenstrukturbaum und Aufgabeneigentümerschaft

Alle Aufgaben einer einfachen Baumstruktur müssen denselben Aufgabeneigentümer haben (d. h. eine einzelne Rolle muss über die Berechtigung OWNERSHIP für alle Aufgaben in der Baumstruktur verfügen) und in derselben Datenbank und in demselben Schema gespeichert sein.

Wenn die Eigentümerschaft aller Aufgaben in einem Aufgabenstrukturbaum durch eine der folgenden Aktivitäten gleichzeitig übertragen wird, bleiben die Verknüpfungen zwischen allen Aufgaben im Strukturbaum erhalten:

  • Der aktuelle Eigentümer aller Aufgaben, aus denen der Aufgabenstrukturbaum besteht, wird gelöscht (mit DROP ROLE). Die Eigentümerschaft an allen Objekten, die der gelöschten Rolle gehören, wird auf die Rolle übertragen, die den Befehl DROP ROLE ausführt.

  • Die Eigentümerschaft aller Aufgaben, aus denen sich der Aufgabenstrukturbaum zusammensetzt, wird explizit auf eine andere Rolle übertragen (z. B. durch Ausführen von GRANT OWNERSHIP für alle Aufgaben in einem Schema).

Versionierung der Ausführungen von Aufgabenstrukturbäumen

Wenn die Stammaufgabe eine geplante Aufführung startet, wird eine Version des gesamten Aufgabenstrukturbaums erstellt. Alle Eigenschaften aller Aufgaben im Strukturbaum werden festgelegt. Für den gesamten Aufgabenstrukturbaum erfolgt die aktuelle Ausführung mit den Eigenschaften der festgelegten Version.

Bevor eine DDL-Anweisung für eine Aufgabe in einem Aufgabenstrukturbaum ausgeführt werden kann, muss die Stammaufgabe angehalten werden (mit ALTER TASK … SUSPEND). Wenn die Stammaufgabe angehalten wird, werden alle zukünftigen geplanten Ausführungen der Stammaufgabe abgebrochen. Wenn sich Aufgaben jedoch gerade in Ausführung befinden (d. h. die Aufgaben haben den Status EXECUTING), werden diese Aufgaben und alle nachfolgenden Aufgaben weiterhin ausgeführt.

Nach Änderung der Aufgabeneigenschaften im Strukturbaum und Fortsetzung der Stammaufgabe werden diese Änderungen erst bei der nächsten geplanten Ausführung angewendet. Zu diesem Zeitpunkt wird eine neue Version des Aufgabenstrukturbaums festgelegt.

Bemerkung

Wenn sich die Definition einer von einer Aufgabe aufgerufenen gespeicherten Prozedur während der Ausführung des Aufgabenstrukturbaums ändert, kann die neue Programmierung bei Aufruf der gespeicherten Prozedur durch die Aufgabe bereits in der aktuellen Ausführung zur Anwendung kommen.

Angenommen, der Eigentümer des folgenden Aufgabenstrukturbaums oder eine andere Rolle mit den entsprechenden Berechtigungen hat die Stammaufgabe (Aufgabe A) angehalten, aber eine geplante Ausführung der Aufgabe wurde bereits gestartet. Der Eigentümer des Strukturbaums ändert die von Aufgabe B (einer untergeordneten Aufgabe) aufgerufene SQL-Anweisung, während die Stammaufgabe noch ausgeführt wird. Bei Start der aktuellen Ausführung der Stammaufgabe wird eine Version für den gesamten Strukturbaum festgelegt. Wenn Aufgabe B nun die SQL-Anweisung ausführt (oder die gespeicherte Prozedur aufruft), erfolgt dies mit der Definition, die der Version des Aufgabenstrukturbaums entspricht, die bei Start der Stammaufgabe festgelegt wurde.

Wenn die Stammaufgabe fortgesetzt wird und eine neue Ausführung startet, wird auch eine neue Version für den Aufgabenstrukturbaum festgelegt. Diese neue Version berücksichtigt dann die an Aufgabe B vorgenommene Änderung.

Festlegen von Sitzungsparametern für Aufgaben

Sie können Sitzungsparameter für die Sitzung festlegen, in der eine Aufgabe ausgeführt wird. Ändern Sie dazu eine vorhandene Aufgabe, und legen Sie die gewünschten Parameterwerte fest (mit ALTER TASKSET Sitzungsparameter = Wert[, Sitzungsparameter = Wert ... ]).

Eine Aufgabe unterstützt alle Sitzungsparameter. Die vollständige Liste finden Sie unter Parameter.

Beachten Sie, dass eine Aufgabe keine Konto- oder Benutzerparameter unterstützt.

Anzeigen des Aufgabenverlaufs für Ihr Konto

Die folgenden Rollen (oder Rollen mit den angegebenen Berechtigungen) können SQL verwenden, um den Aufgabenverlauf innerhalb eines angegebenen Datumsbereichs anzuzeigen:

  • Kontoadministratoren (d. h. Benutzer mit der Rolle ACCOUNTADMIN)

  • Aufgabeneigentümer (d. h. Rolle mit der Berechtigung OWNERSHIP für eine Aufgabe)

  • Jede Rolle mit der globalen Berechtigung MONITOR EXECUTION

So zeigen Sie den Aufgabenverlauf an:

SQL

Fragen Sie die Tabellenfunktion TASK_HISTORY ab (im Information Schema).

Grundlegendes zum Systemdienst

Snowflake führt Aufgaben mit den Berechtigungen des Aufgabeneigentümer aus (d. h. der Rolle, die die Berechtigung OWNERSHIP für die Aufgabe besitzt), die Aufgabenausführung ist jedoch keinem Benutzer zugeordnet. Stattdessen wird jede Ausführung von einem Systemdienst ausgeführt. Aufgaben werden von bestimmten Benutzern entkoppelt, um Komplikationen zu vermeiden, die auftreten können, wenn Benutzer gelöscht oder aufgrund von Authentifizierungsproblemen gesperrt werden oder wenn Rollen entfernt werden.

Da Aufgabenausführungen von einem Benutzer entkoppelt sind, wird der Abfrageverlauf von Aufgabenausführungen dem Systemdienst zugeordnet. SYSTEM ist kein Benutzer im Konto, sondern ein Hintergrunddienst. Daher gibt es keine Benutzeranmeldeinformationen für diesen Dienst, und keine Person (von Snowflake oder in Ihrem Konto) kann seine Identität übernehmen. Die Aktivität für den Systemdienst ist auf Ihr Konto beschränkt. Der Dienst bietet dieselben Verschlüsselungsschutz- und weitere Sicherheitsprotokolle, wie sie auch für andere Operationen erzwungen werden.

Aufgaben-DDL

Um das Erstellen und Verwalten von Aufgaben zu unterstützen, bietet Snowflake den folgenden Satz von speziellen DDL-Befehlen:

Darüber hinaus können Anbieter den Zugriff auf die für ELT erforderlichen Datenbankobjekte mit der folgenden DDL-Standardzugriffssteuerung anzeigen, gewähren oder widerrufen:

Aufgabenfunktionen

Um das Abrufen von Informationen über Aufgaben zu unterstützen, bietet Snowflake die folgenden SQL-Funktionen:

Aufgabensicherheit

Erforderliche Zugriffsrechte

Das Erstellen, Verwalten und Ausführen von Aufgaben erfordert eine Rolle mit mindestens den folgenden Rollenberechtigungen:

Objekt

Berechtigung

Anmerkungen

Konto

EXECUTE TASK

Erforderlich, um jegliche Aufgaben auszuführen, die der Rolle gehören. Durch das Widerrufen der Berechtigung EXECUTE TASK für eine Rolle wird verhindert, dass alle nachfolgenden Aufgaben unter dieser Rolle gestartet werden.

Datenbank

USAGE

Schema

USAGE, CREATE TASK

Warehouse

USAGE

Darüber hinaus muss die Rolle über die erforderlichen Berechtigungen verfügen, um die von der Aufgabe ausgeführte SQL-Anweisung auszuführen.

Erstellen einer Aufgabenadministratorrolle

Zur Vereinfachung der Verwendung empfehlen wir das Erstellen einer benutzerdefinierten Rolle (z. B. TASKADMIN) und das Zuweisen der Berechtigung EXECUTE TASK an diese Rolle. Jede Rolle, die Berechtigungen erteilen kann (z. B. SECURITYADMIN oder jede Rolle mit der Berechtigung MANAGE GRANTS) kann diese benutzerdefinierte Rolle dann jeder Aufgabeneigentümerrolle zuweisen, um eine Änderung ihrer eigenen Aufgaben zu ermöglichen. Um zu verhindern, dass die Aufgabeneigentümerrolle die Aufgabe ausführt, muss der Aufgabeneigentümerrolle nur diese benutzerdefinierte Rolle entzogen werden. Beachten Sie, dass ein Kontoadministrator die Berechtigung EXECUTE TASK für die Rolle des Aufgabeneigentümers widerrufen muss, wenn Sie diese benutzerdefinierte Rolle nicht erstellen möchten.

Erstellen Sie beispielsweise einen benutzerdefinierten Rollennamen TASKADMIN, und erteilen Sie dieser Rolle die Berechtigung EXECUTE TASK. Weisen Sie die Rolle TASKADMIN einer Aufgabeneigentümerrolle mit dem Namen MYROLEzu:

USE ROLE securityadmin;

CREATE ROLE taskadmin;

-- set the active role to ACCOUNTADMIN before granting the EXECUTE TASK privilege to the new role
USE ROLE accountadmin;

GRANT EXECUTE TASK ON ACCOUNT TO ROLE taskadmin;

-- set the active role to SECURITYADMIN to show that this role can grant a role to another role
USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;

Weitere Informationen zum Erstellen von benutzerdefinierten Rollen und Rollenhierarchien finden Sie unter Konfigurieren der Zugriffssteuerung.

Löschen einer Aufgabeneigentümerrolle

Wenn die Eigentümerrolle einer bestimmten Aufgabe (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Aufgabe) gelöscht wird, geht die Eigentümerschaft der Aufgabe wieder an die Rolle zurück, die die Eigentümerrolle gelöscht hat. Dadurch wird sichergestellt, dass die Eigentümerschaft auf eine Rolle übertragen wird, die in der Rollenhierarchie näher an der Stammrolle liegt. Wenn eine Aufgabe wieder in Besitz genommen wird, wird sie automatisch angehalten, d. h. alle Ausführungen, die sich derzeit in Verarbeitung befinden, werden abgeschlossen, während neue Ausführungen erst wieder geplant werden, wenn die Aufgabe vom neuen Eigentümer explizit wieder aufgenommen wird. Dadurch soll verhindert werden, dass ein Benutzer mit Zugriff auf eine bestimmte Rolle Aufgaben zurücklässt, die plötzlich mit höheren Berechtigungen ausgeführt werden, wenn die Rolle entfernt wird.

Wenn die Rolle, unter der eine ausgeführte Aufgabe ausgeführt wird, gelöscht wird, während die Aufgabe ausgeführt wird, schließt die Aufgabe die Verarbeitung unter der gelöschten Rolle ab.

Workflow

Dieser Abschnitt bietet einen allgemeinen Überblick über den Workflow zum Einrichten von Aufgaben.

  1. Führen Sie die Schritte in Erstellen einer Aufgabenadministratorrolle (unter diesem Thema) aus, um eine Rolle zu erstellen, mit der die Befehle in den folgenden Schritten ausgeführt werden können.

  2. Erstellen Sie mit CREATE TASK eine Aufgabe. Die Aufgabe ist standardmäßig angehalten.

    Bemerkung

    Überprüfen Sie, ob die SQL-Anweisung, auf die Sie in einer Aufgabe verweisen, wie erwartet ausgeführt wird, bevor Sie die Aufgabe erstellen. Aufgaben dienen dazu, SQL-Anweisungen oder gespeicherte Prozeduren zu automatisieren, die bereits gründlich getestet wurden.

  3. Führen Sie ALTER TASK … RESUME aus, damit die Aufgabe auf Grundlage der in der Aufgabendefinition angegebenen Parameter ausgeführt werden kann.