Konfiguration des Celery Kubernetes Executor für Airflow 2.0
Haben Sie ein Dilemma, weil Sie nicht wissen, welchen Executor Sie für Ihr nächstes Airflow-Projekt wählen sollen? Der Celery Executor und der Kubernetes Executor bilden eine ziemliche Kombination — der Celery Kubernetes Executor bietet Benutzern die Vorteile beider Lösungen. Möchten Sie lernen, wie man es konfiguriert? Lesen Sie unseren Artikel, um es herauszufinden.
Der Airflow Kubernetes Executor gegen The Celery Executor — ein erster Blick
Airflow verfügt über zwei Executoren in seinen Ressourcen, die den parallelen Betrieb vieler Aufgaben ermöglichen. Der erste ist der Celery Executor, mit dem Sie Aufgaben auf viele Mitarbeiter verteilen können. Die Anzahl der Arbeiter und ihre Ressourcen können im Voraus definiert werden. Diese Aufgaben können für jeden Worker parallel ausgeführt werden, und die maximale Anzahl von Aufgaben, die ein Worker ausführen kann, wird durch die Variable worker_concurency definiert. Die Einschränkung besteht darin, dass die Anzahl der Mitarbeiter und ihre Ressourcen im Voraus definiert werden müssen und dass sie ständig ausgeführt werden. Das bedeutet, dass die Ressourcenkosten konstant berechnet werden, auch wenn keine Aufgabe ausgeführt wird. Damit der Celery Executor ordnungsgemäß funktioniert, muss ein Message Broker (RabbitMQ/Redis) implementiert werden, was die Konfiguration kompliziert macht.
Ein weiterer Executor, der die Arbeit mit einer großen Anzahl von Aufgaben unterstützt, ist der Kubernetes Executor, der jede Instanz der Aufgabe in einem eigenen Kubernetes-Pod ausführt. Dies hat den Vorteil, dass für jede Aufgabe ein eigener, dedizierter Ressourcenbereich zur Verfügung steht. Ein Fehler in einer Aufgabe wirkt sich nicht auf die anderen Aufgaben aus. Bei der Konfiguration des Airflow Kubernetes Executors muss das „Template“ verwendet werden, das verwendet wird, um neue Pods für nachfolgende Bänder zu erstellen.
Lesen Sie auch: So verbessern Sie die Airflow 2.0-Leistung mit intelligenten Sensoren
Beide Lösungen haben ihre Vor- und Nachteile, aber bei größeren Projekten kann das Problem darin bestehen, eine geeignete Lösung zu wählen. Hier sind die neuesten Lösung in Airflow 2.0 — der Celery Kubernetes Executor — kommt zu Hilfe. In dieser Übung haben wir Teile unseres neuesten Produkts verwendet, das auf dem Airflow 2.0-Dienst basiert, der aktiv von DS Stream entwickelt wird (daher können wir nicht den vollständigen Code zur Neuerstellung des Jobs bereitstellen). Wenn Sie an Einzelheiten interessiert sind, bitte Vertrieb kontaktieren. In Kürze werden weitere Informationen zu diesem Projekt auch unter verfügbar sein unsere Website.
Celery Kubernetes Executor, Konfiguration von Celery Kubernetes
Dies ist eine Kombination der beiden oben genannten Lösungen in der Konfiguration von Celery Kubernetes. Es ermöglicht Ihnen, sowohl den Celery- als auch den Kubernetes-Executor gleichzeitig zu verwenden. Diese Kombination bietet mehr Möglichkeiten, erfordert aber auch mehr Arbeit, da beide Executoren konfiguriert werden müssen. Diese Kombination ist in erster Linie ideal für Prozesse, bei denen es viele anspruchslose Aufgaben gibt, die mit Celery ausgeführt werden können, aber auch ressourcenintensive Aufgaben oder Laufzeitisolierung beinhalten.
Konfiguration des Celery Kubernetes Executor
Um das Airflow-Setup für die Verwendung des Celery Kubernetes Executor zu konfigurieren, benötigen Sie:
- Externe Datenbank
- Nachrichtenbroker (RabbitMQ/Redis)
- pod-template.yaml — Pod-Vorlage, die Kubernetes Executor benötigt, um neue Pods zu erstellen
In der Konfigurationsdatei airflow.cfg ist es wichtig, executor=celeryKubernetesExecutor und kubernetes_queue = kubernetes zu setzen. In diesem Fall wird Celery Executor zum Standard-Executor. Der Wunsch, den Executor auf Kubernetes Executor umzustellen, sollte in einer DAG-Datei in Operatorvariablen ausgedrückt und der Variablen queue='kubernetes' hinzugefügt werden:
Wir werden unser System auf dem Kubernetes Service in Microsoft Azure ausführen. Konfigurieren Sie dazu das Docker-Image, das im Airflow-Setup verwendet wird. Bei der Erstellung verwende ich das Apache Airflow-Image in Version 2.1.4, verfügbar unter https://hub.docker.com. Dockerfile-Code unten:
Es ist wichtig, die Datei pod-template.yaml zu erstellen, die der Kubernetes Executor beim Erstellen neuer Pods verwendet. Dort können Sie definieren, welche Ressourcen für jeden Pod benötigt werden und welche Grenzen sie haben. Denken Sie daran, diese Datei in das Bild hochzuladen, das in der Datei verwendet werden soll
Konfiguration des Luftstroms zum Pfad
$ {AIRFLOW_HOME}/.
Der Pfad zu dieser Datei muss in einer pod_template_file in der Datei airflow.cfg gespeichert werden (pod_template_file = /opt/airflow/pod-template.yaml).
Die Konfiguration von Celery mit dem Message Broker ist identisch mit der von Celery Executor. Wir haben diese Aktion in einer anderen beschrieben Artikel.
Testen
Auf diese Weise konfiguriert, ermöglicht Ihnen das Airflow-Setup, beide Executors je nach den Anforderungen des Projekts zu verwenden. Um dies zu testen, habe ich das Airflow-Setup wie oben beschrieben konfiguriert und geprüft, ob es wirklich von beiden Executors verwendet werden kann. Zwei DAGs wurden erstellt:
- test_10_task_celery — Celery Executor (10 parallele Aufgaben)
- test_10_task_kubernetes — zum Testen des Airflow Kubernetes Executor (10 parallele Aufgaben).
Der einzige Unterschied zwischen ihnen ist der Parameter queue=“ kubernetes“ in test_10_task_kubernetes.
Es gibt 10 Worker (worker-deployment%) für den Celery Executor und 10 neue Zeitarbeiter (test10taskkubernetestask#.%) für den Kubernetes Executor:
Wenn test_10_task_kubernetes fertig ist, werden Zeitarbeiter gelöscht, aber die Mitarbeiter von Celery sind noch am Leben:
Der auf diese Weise konfigurierte Celery Kubernetes Executor ebenfalls ermöglicht es Ihnen, 1000 parallele Aufgaben auszuführen, beide mit Hilfe des Celery Executor (Lösung hier) und mit Hilfe des Kubernetes Executors. Zu diesem Zweck wurden die Parameter wie folgt gesetzt:
- scheduler_heartbeat_sec = 1
- worker_pods_creation_batch_size = 16
- worker_pods_pending_timeout = 600
- worker_pods_queued_check_interval = 10
Der Vorteil der Verwendung des Airflow Kubernetes Executor besteht darin, dass die Ressourcen nicht ständig genutzt werden. Sellerie verbraucht ständig einige Ressourcen, da die Mitarbeiter rund um die Uhr arbeiten, während Kubernetes Ressourcen nur benötigt, wenn es Aufgaben ausführen muss. Die Frage, die sich jetzt stellt, lautet: Welche dieser Lösungen ist finanziell vorteilhafter? Wir haben einen kleinen Vergleich mit dem Azure-Preisrechner durchgeführt. In unserem Vergleich gingen wir davon aus, dass der Kubernetes Executor 1 Stunde am Tag (13 Knoten) arbeiten würde; außerdem bräuchte ich 2 Knoten, die für die Arbeit des Webservers oder des Schedulers verantwortlich sein werden.
Lesen Sie auch: Ein effizienterer Scheduler zur Leistungssteigerung in Airflow 2.0
Für den Celery Executor sind 6 Knoten für den gesamten Monat erforderlich. Die Ergebnisse dieses Vergleichs sind im Folgenden dargestellt:
Der Unterschied liegt bei über 1000$ zugunsten des Kubernetes Executors! Die Kosten sind sehr unterschiedlich, aber es sollte beachtet werden, dass jeder Fall anders ist und einzeln analysiert werden muss. Wenn die Ressourcen nicht für 1 Stunde, sondern für 5 Stunden benötigt würden, wären die Kosten für beide Lösungen gleich.
Fazit
Sowohl der Celery als auch der Kubernetes Executor haben ihre eigenen Vor- und Nachteile. Beides ist nicht perfekt für jeden Job. Der Celery Executor ist eine ideale Lösung für eine Vielzahl von Aufgaben, für die nicht viele Ressourcen erforderlich sind. Mit dem Kubernetes Executor können Sie wiederum für jede der Aufgaben eine separate Umgebung erstellen, was sich in der Möglichkeit niederschlägt, anspruchsvollere Aufgaben zu erledigen. Darüber hinaus speichert der Kubernetes Executor keine unnötigen, ungenutzten Pods, wenn keine Aufgaben vorhanden sind, während der Celery Executor über eine fest definierte Anzahl von arbeitenden Mitarbeitern verfügt — unabhängig von deren Verbrauch. Ihre Kombination, die mit Airflow 2.0 — dem Celery Kubernetes Executor — möglich ist, ermöglicht ein noch besseres und effektiveres Arbeiten ohne die Kompromisse, die bei der Auswahl eines der beiden Executors notwendig sind. Wie kann Luftstrom Ihrem Unternehmen helfen? Besuchen Sie unsere Automatisierung der Datenpipeline Besuchen Sie uns und finden Sie eine Lösung, die Ihren Bedürfnissen entspricht. Der gesamte Airflow-Startvorgang wird durch unsere Anwendung automatisiert, sodass Sie die gesamte Infrastruktur mit einem Klick einrichten können. Während des Baus werden moderne Konzepte und Technologien wie CI/CD, Terraform oder Kubernetes verwendet. Für weitere Informationen wenden Sie sich bitte an Umsatz.
Erfahre mehr über Airflow 2.0:
- Ein effizienterer Scheduler zur Leistungssteigerung in Airflow 2.0
- Leistungsstarke REST-API in Airflow 2.0 — was müssen Sie wissen?
- So vereinfachen Sie das Airflow 2.0-Setup mit der DAG-Versionierung und -Serialisierung
- Konfiguration von Celery Kubernetes
