Einführung in Aufgaben¶

Serverlose Aufgaben¶

Das serverlose Computemodell für Aufgaben ermöglicht es Ihnen, sich auf Snowflake-verwaltete Computeressourcen zu verlassen, anstatt auf benutzerverwaltete virtuelle Warehouses. Serverlose Computeressourcen werden von Snowflake je nach Workload automatisch in der Größe angepasst und skaliert. Snowflake bestimmt die ideale Größe der serverlosen Computeressourcen für eine bestimmte Ausführung auf der Grundlage einer dynamischen Analyse der Statistiken für die letzten Ausführungen derselben Aufgabe. Die maximale Computegröße für eine serverlose Aufgabe entspricht einem benutzerverwalteten virtuellen Warehouse der Größe XXLARGE. Mehrere Workloads in Ihrem Konto teilen sich einen gemeinsamen Satz von Computeressourcen.

Um das serverlose Computemodell zu aktivieren, müssen Sie beim Erstellen einer Aufgabe mit CREATE TASK den Parameter WAREHOUSE weglassen. Beachten Sie, dass die Rolle, die den Befehl CREATE TASK ausführt, über die globale Berechtigung EXECUTE MANAGED TASK verfügen muss. Weitere Informationen zu den Anforderungen an die Zugriffssteuerung von Aufgaben finden Sie unter Aufgabensicherheit.

Die Abrechnung für die Ausführung von serverlosen Aufgaben unterscheidet sich von dem Standardmodell für den Credit-Verbrauch bei Aufgaben, für die virtuelle Warehouses als Computeressourcen eingesetzt werden. Weitere Informationen dazu finden Sie unter Kosten für Aufgaben.

Benutzerverwaltete Aufgaben¶

Bei Bedarf können Sie alternativ die Computeressourcen für einzelne Aufgaben verwalten, indem Sie bei der Erstellung der Aufgabe ein bestehendes virtuelles Warehouse angeben. Diese Option erfordert, dass Sie ein Warehouse wählen, das für die SQL-Aktionen, die von der Aufgabe ausgeführt werden, angemessen dimensioniert ist.

Auswählen einer Warehouse-Größe¶

Wenn Sie sich dafür entscheiden, bestehende Warehouses für die Bereitstellung von Computeressourcen für einzelne Aufgaben zu verwenden, empfehlen wir Ihnen, die unter Hinweise zu Warehouses beschriebenen bewährten Verfahren zu befolgen. Wir schlagen vor, dass Sie die durchschnittliche Ausführungszeit einer einzelnen Aufgabe oder eines Task-Graphen für ein bestimmtes Warehouse analysieren, basierend auf der Warehouse-Größ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 bzw. dieses Task-Graphen vorgesehen ist.

Fragen Sie die Account Usage-Ansicht TASK_HISTORY ab (in der freigegebenen SNOWFLAKE-Datenbank). 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 Computeressourcen 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 Task-Graphen. Wählen Sie anhand Ihrer Analyse die richtige Größe für das Warehouse aus, um sicherzustellen, dass die Aufgabe oder der Task-Graph innerhalb dieses Zeitfensters 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.

Die folgende Abbildung zeigt einen Task-Graphen, für dessen Ausführung durchschnittlich 5 Minuten erforderlich sind. Die Abbildung zeigt das Fenster für 2 Ausführungen des zu bearbeitenden Task-Graphen. Die Berechnung dieses Fensters beginnt beim geplanten Startzeitpunkt der Stammaufgabe und endet, wenn die letzte untergeordnete Aufgabe im Task-Graphen vollständig ausgeführt wurde. In diesem Beispiel wird der Task-Graph für andere gleichzeitige Operationen freigegeben, die sich in der Warteschlange befinden, während jede der 3 Aufgaben im Task-Graphen ausgeführt wird. Diese parallelen Operationen verbrauchen alle verfügbaren Ressourcen, wenn die Ausführung jeder Aufgabe im Task-Graphen 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 Computeressourcen freigegeben werden.

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

Empfehlungen zur Auswahl des Computemodells¶

In der folgenden Tabelle werden verschiedene Faktoren beschrieben, die Ihnen bei der Entscheidung helfen können, ob Sie serverlose Aufgaben oder benutzerverwaltete Aufgaben verwenden sollten:

Beachten Sie, dass die maximale Größe einer serverlosen Aufgabenausführung einem XXLARGE-Warehouse entspricht. Wenn der Workload einer Aufgabe ein größeres Warehouse erfordert, erstellen Sie eine benutzerverwaltete Aufgabe, die auf ein Warehouse der erforderlichen Größe verweist.

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, verwenden Sie eine der folgenden Optionen:

• Planen Sie keine Aufgabenaussführungen zu einem bestimmten Zeitpunkt zwischen 13:00 und 15:00 Uhr (täglich oder an Wochentagen, zu denen auch Sonntage gehören).

• 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.

• Verwenden Sie ein Zeitformat, das keine Sommerzeit anwendet, z. B. UTC.

Eigentümerschaft der Aufgabe¶

Alle Aufgaben eines einfachen Task-Graphen müssen denselben Aufgabeneigentümer haben (d. h. genau eine Rolle muss über die Berechtigung OWNERSHIP für alle Aufgaben verfügen) und in derselben Datenbank und in demselben Schema gespeichert sein.

Durch das Übertragen der Eigentümerschaft an einer Aufgabe wird die Abhängigkeit zwischen dieser Aufgabe und allen Vorgängeraufgaben und untergeordneten Aufgaben aufgehoben. Weitere Informationen dazu finden Sie unter Verknüpfung zwischen Vorgänger- und untergeordneten Aufgaben auflösen (unter diesem Thema).

Wenn die Eigentümerschaft aller Aufgaben in einem Task-Graphen durch eine der folgenden Aktivitäten gleichzeitig übertragen wird, bleiben die Beziehungen zwischen allen Aufgaben im Task-Graphen erhalten:

• Der aktuelle Eigentümer aller Aufgaben, die den Task-Graphen umfassen, 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 Task-Graph zusammensetzt, wird explizit auf eine andere Rolle übertragen (z. B. durch Ausführen von GRANT OWNERSHIP für alle Aufgaben in einem Schema).

Überlappende Task-Graph-Ausführung¶

Snowflake stellt standardmäßig sicher, dass jeweils nur eine Instanz eines bestimmten Task-Graphen ausgeführt wird. Die nächste Ausführung einer Stammaufgabe wird erst geplant, wenn die Ausführung aller Aufgaben im Task-Graphen beendet wurde. Das heißt, wenn die kumulierte Zeit, die für die Ausführung aller Aufgaben im Task-Graphen benötigt wird, die in der Definition der Stammaufgabe festgelegte explizit geplante Zeit überschreitet, wird mindestens eine Ausführung des Task-Graphen übersprungen. Das Verhalten wird durch den Parameter ALLOW_OVERLAPPING_EXECUTION der Stammaufgabe gesteuert. Der Standardwert ist FALSE. Wird der Parameterwert auf TRUE gesetzt, können sich Task-Graph-Ausführungen überschneiden.

Außerdem beginnt die Ausführung einer untergeordneten Aufgabe erst dann, wenn alle Vorgängeraufgaben der untergeordneten Aufgabe ihre eigenen Ausführungen erfolgreich abgeschlossen haben. Eine Aufgabe, die zeitintensive SQL-Operationen ausführt, verzögert den Start jeder nachfolgenden Aufgabe, die die Aufgabe als Vorgänger identifiziert.

Im folgenden Beispiel wird eine Task-Graph-Ausführung so geplant, dass die Ausführung gestartet wird, wenn eine vorherige Ausführung noch nicht abgeschlossen ist. Der Zeitraum der Überlappung bzw. Gleichzeitigkeit ist rot gekennzeichnet. Die Abbildung zeigt auch die Zeitspanne an, in der sich jede Aufgabe in der Warteschlange befindet, bevor sie im benutzerverwalteten Warehouse ausgeführt wird: Beachten Sie, dass es bei der Verwendung von serverlosen Computeressourcen keine Wartezeit gibt:

Überlappende Ausführungen können toleriert werden (oder sind sogar erwünscht), wenn SQL-Lese-/Schreiboperationen, die durch überlappende Ausführungen eines Task-Graphen ausgeführt werden, keine falschen oder duplizierten Daten erzeugen. Für andere Task-Graphen sollten Aufgabeneigentümer (die Rolle mit OWNERSHIP-Berechtigung für alle Aufgaben im Task-Graphen) einen geeigneten Zeitplan für die Stammaufgabe festlegen und eine geeignete Warehouse-Größe auswählen (oder serverlose Computeressourcen verwenden), um sicherzustellen, dass eine Instanz des Task-Graphen bis zum Ende ausgeführt wird, bevor die nächste Ausführung der Stammaufgabe geplant wird.

So stimmen Sie einen Task-Graphen besser mit dem in der Stammaufgabe definierten Zeitplan ab:

1. Erhöhen Sie, falls möglich, die Planungszeit zwischen den Ausführungen der Stammaufgabe.

2. Erwägen Sie, rechenintensive Aufgaben so zu ändern, dass sie serverlose Computeressourcen nutzen. Wenn die Aufgabe auf benutzerverwaltete Computeressourcen angewiesen ist, sollten Sie die Größe für das Warehouse erhöhen, das umfangreiche oder komplexe SQL-Anweisungen oder gespeicherte Prozeduren im Task-Graphen ausführt.

3. Analysieren Sie die SQL-Anweisungen oder gespeicherten Prozeduren, die von jeder Aufgabe ausgeführt werden. Stellen Sie fest, ob sich der Code umschreiben lässt, um die Parallelverarbeitung nutzen zu können.

Wenn keine der obigen Lösungen hilft, überlegen Sie, ob es notwendig ist, gleichzeitige Ausführungen des Task-Graphen durch Festlegen von ALLOW_OVERLAPPING_EXECUTION = TRUE für die Stammaufgabe zuzulassen. Dieser Parameter kann beim Erstellen einer Aufgabe definiert werden (mit CREATE TASK) oder später (mit ALTER TASK).

Anzeigen abhängiger Aufgaben eines Task-Graphen¶

So zeigen Sie die direkten untergeordneten Aufgaben einer Stammaufgabe oder alle Aufgaben in einem Task-Graphen an:

SQL:

Fragen Sie die Tabellenfunktion TASK_DEPENDENTS ab (im Snowflake Information Schema). Um alle Aufgaben in einem Task-Graphen abzurufen, müssen Sie beim Aufrufen der Funktion die Stammaufgabe angeben. Wenn Sie eine untergeordnete Aufgabe eingeben, gibt die Funktion die untergeordneten Aufgaben (und die untergeordneten Aufgaben dieser untergeordneten Aufgaben usw.) der angegebenen Aufgabe zurück.

Task-Graph-Ausführungen mit angehaltenen untergeordneten Aufgaben¶

Wenn die Stammaufgabe angehalten wurde, können Sie alle untergeordneten Aufgaben mit ALTER TASK … RESUME | SUSPEND fortsetzen oder anhalten. Es ist nicht erforderlich, angehaltene untergeordnete Aufgaben fortzusetzen, bevor Sie die Stammaufgabe fortsetzen.

Wenn ein Task-Graph mit einer oder mehreren angehaltenen untergeordneten Aufgaben ausgeführt wird, wird die Ausführung dieser Aufgaben ignoriert. Eine untergeordnete Aufgabe mit mehreren Vorgängern wird solange ausgeführt, bis sich mindestens einer der Vorgänger im Zustand „Fortgesetzt“ befindet und alle fortgesetzten Vorgänger erfolgreich zu Ende geführt werden.

Fortsetzen angehaltener Aufgaben in einem Task-Graphen¶

Um alle Aufgaben in einem Task-Graphen rekursiv fortzusetzen, fragen Sie die Funktion SYSTEM$TASK_DEPENDENTS_ENABLE ab, anstatt jede Aufgabe einzeln fortzusetzen (mit ALTER TASK … RESUME).

Verknüpfung zwischen Vorgänger- und untergeordneten Aufgaben auflösen¶

Abhängigkeiten zwischen Aufgaben in einem Task-Graphen können durch eine der folgenden Aktionen aufgelöst werden:

• Mit ALTER TASK … REMOVE AFTER und ALTER TASK … UNSET FINALIZE kann die Verknüpfung zwischen der Zielaufgabe und den angegebenen Vorgängeraufgaben oder der abgeschlossenen Stammaufgabe entfernt werden.

• DROP TASK und GRANT OWNERSHIP trennen alle Verknüpfungen der Zielaufgabe. Beispiel: Stammaufgabe A hat eine untergeordnete Aufgabe B, und Aufgabe B hat eine untergeordnete Aufgabe C. Wenn Sie Aufgabe B löschen, wird die Verknüpfung zwischen Aufgabe A und Aufgabe B unterbrochen und damit auch die Verknüpfung zwischen Aufgabe B und Aufgabe C.

Wenn eine beliebige Kombination der oben genannten Aktionen die Beziehung zwischen der untergeordneten Aufgabe und allen Vorgängeraufgaben aufhebt, dann wird die bisherige untergeordnete Aufgabe entweder eine eigenständige Aufgabe oder eine Stammaufgabe, je nachdem, ob andere Aufgaben die Aufgabe als ihren Vorgänger identifizieren.

Finalizer-Aufgabe¶

Eine Finalizer-Aufgabe verarbeitet die Freigabe und Bereinigung der von einem Task-Graphen verwendeten Ressourcen. Die Finalizer-Aufgabe wird garantiert ausgeführt, wenn der Task-Graphen ausgeführt wird, und sie stellt die ordnungsgemäße Bereinigung der Ressourcen und den Abschluss der erforderlichen Schritte in allen Szenarios sicher. Wenn beispielsweise eine Task-Graph-Ausführung Zwischentabellen verwendet, um Daten für die Verarbeitung zu verfolgen, und die Ausführung fehlschlägt, bevor alle Tabellenzeilen verarbeitet wurden, würde die nächste Ausführung auf doppelte Zeilen stoßen und müsste die Daten erneut verarbeiten, was zu einer längeren Ausführungszeit oder einer Verschwendung von Computeressourcen führt. Die Finalizer-Aufgabe kann dieses Problem lösen, indem sie die Zeilen löscht oder die Tabelle falls erforderlich abschneidet.

Die Finalizer-Aufgabe funktioniert wie jede andere Aufgabe in einem Task-Graphen, mit den folgenden Unterschieden:

• Eine Finalizer-Aufgabe ist immer mit einer Stammaufgabe (root task) verbunden. Jede Stammaufgabe kann nur eine Finalizer-Aufgabe haben, und eine Finalizer-Aufgabe kann nur mit einer Stammaufgabe verbunden sein.

• Eine Finalizer-Aufgabe wird nur geplant, wenn in der aktuellen Task-Graph-Ausführung keine anderen Aufgaben ausgeführt werden oder sich in der Warteschlange befinden und wenn mindestens eine Aufgabe im Task-Graphen mit der Ausführung begonnen hat. Wird ein Task-Graph übersprungen (z. B. die Stammaufgabe wird übersprungen), wird die Finalizer-Aufgabe nicht ausgeführt. Wenn ALLOW_OVERLAPPING_EXECUTION den Wert „true“ hat, verhält sich die Finalizer-Aufgabe wie die anderen Aufgaben und wird auch dann geplant, wenn noch andere Task-Graph-Ausführungen aktiv sind.

• Eine Finalizer-Aufgabe kann keine untergeordneten Aufgaben haben. Jeder Befehl, der versucht, die Finalizer-Aufgabe zu einem Vorgänger zu machen, schlägt fehl. Das Erstellen einer Finalizer-Aufgabe muss das Schlüsselwort FINALIZE enthalten, das mit den Schlüsselwörtern SCHEDULE und AFTER nicht kompatibel ist.

Um eine Finalizer-Aufgabe zu erstellen, erstellen Sie eine Aufgabe mit dem Schlüsselwort FINALIZE, und erstellen Sie dann eine Beziehung zur Stammaufgabe:

CREATE TASK <TASK_NAME> ...
... FINALIZE = <ROOT_TASK_NAME>

Weitere Informationen dazu finden Sie unter CREATE TASK.

Zugriffssteuerungsrechte¶

Erstellen einer Aufgabenadministratorrolle¶

Zur Vereinfachung der Verwendung empfehlen wir das Erstellen einer kundenspezifischen Rolle (z. B. taskadmin) und das Zuweisen der Berechtigung EXECUTE TASK zu dieser Rolle. Jede Rolle, die Berechtigungen erteilen kann (z. B. SECURITYADMIN oder jede Rolle mit der Berechtigung MANAGE GRANTS) kann diese kundenspezifische 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 kundenspezifische Rolle entzogen werden. Beachten Sie, dass ein Kontoadministrator die Berechtigung EXECUTE TASK für die Rolle des Aufgabeneigentümers widerrufen muss, wenn Sie diese kundenspezifische Rolle nicht erstellen möchten.

Erstellen Sie beispielsweise eine kundenspezifische Rolle mit dem Namen taskadmin, und erteilen Sie dieser Rolle die Berechtigung EXECUTE TASK. Weisen Sie die Rolle taskadmin einer Aufgabeneigentümerrolle mit dem Namen myrole zu:

USE ROLE securityadmin;

CREATE ROLE taskadmin;

-- set the active role to ACCOUNTADMIN before granting the account-level privileges to the new role
USE ROLE accountadmin;

GRANT EXECUTE TASK, EXECUTE MANAGED 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 kundenspezifischen 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.