A bas Cron ! Vive Oozie !
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,929 views
Présentation aux Journées Perl 2015. Oozie est le moteur de workflow de la pile Hadoop, et l'un de ses composants les plus méconnus.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
A bas Cron ! Vive Oozie !
- 1. A BAS CRON ! VIVE OOZIE ! “possibly the most underrated component of the Hadoop stack” david.morel@booking.com
- 2. Fast forward • Problèmes de cron • Rappel archi Hadoop/YARN • Archi oozie • Workflow • Coordinator • Exécution • Contrôle, SLA, etc • Perl ?
- 3. Crond • Adapté aux tâches locales • Mal à l’aise pour le reste • Scalabilité horizontale ? • Dépendances ? • Contrôle, reruns, etc • Que des soucis !
- 5. Oozie • 1 serveur (ou 2, pour HA) • 1 backend DB (agnostique) • 1 cluster Hadoop (HDFS + YARN) • C’est tout !
- 6. Workflow intro • L’unité de base • Définition en XML • + job.properties • + options (jars, lib, etc) • Upload sur HDFS • oozie job -run -config job.properties • Done !
- 8. Workflow guts • “ligne de commande de cron” • DAG • Actions externes / internes • Decision nodes • Forks • Communication entre étapes • Exécution distribuée, tolérance aux pannes
- 9. Coordinator secrets • “spécification de fréquence de cron” • Parent du workflow • Le maître du temps • Abstraction : “nominal time” • Du workflow aux “coordinator actions” • Le maître des dépendances • UTC !
- 10. Exécution • Fire and forget • Worker map + child • Worker call home • Callbacks optionnels • Flags sur HDFS
- 11. Pros & C(r)ons • C’est nul comme jeu de mots • Parallélisme, retries • La précieuse abstraction du temps • Contrainte : idempotency • SLA • UTC • => WTH ?
- 12. Perl & Oozie • REST : listen, parse, introspect • Monitor, submit, start, stop, query • Shell action hors JVM • STDIN/OUT/ERR capturés • Use WebHDFS • TRANSFORM dans Hive
- 13. Perl & Oozie • @booking.com
- 14. Merci ! • Questions ?
Hinweis der Redaktion
- premier cronmaster à booking.com Crond pas seulement problematique hors big data - scalabilité horizontale (que faire quand un serveur ne suffit plus?) - dépendances entre scripts (pipelines) - reruns difficiles - nécessité d'avoir des wrappers pour exécution, monitoring, etc
- - job.properties (uniquement local) - workflow.xml (sur HDFS) - autres fichiers si nécessaire (jars, etc) - pousser workflow.xml vers HDFS - oozie job -run -config job.properties - c'est tout
- - Le workflow est un DAG - actions externes, comme Hive, sqoop, mapreduce (java) - actions internes (opérations sur le système de fichiers, ssh, etc) - decision nodes - fork / join - error / end - une action externe particulière : shell action - passage d'arguments et de données d'un step à l'autre (capture output) basé sur hadoop/hdfs -> les steps ne s'exécutent pas sur une seule machine tolérance aux pannes (retries max, etc), écriture des données intermédiaires sur le FS distribué
- - le maître du temps, et l'abstraction du nominal time - quand on lance un coordinateur, il calcule à l'avance quand il doit tourner en fonction de la fréquence indiquée - start et end times, fréquence > déduit les nominal times - génère des "coordinator actions", c.à.d des instances; attention à la terminologie, "action" est ambigu. - permet de passer des variables aux workflows qu'il lance, en particulier basées sur le temps (nominal) - EL (expression language = jsp) fonctions pour manipuler le temps - support des timezones, mais attention aux migraines -> tout faire en GMT, y compris la BDD (compliqué et en plus il y a des bugs)
- - Fire and forget Oozie - le serveur oozie n'est qu'un backend DB, les jobs sont auto-gérés - lancement d'une tâche controleur (map), dans certains cas execute l'action directement, sinon lance une autre application YARN; double niveau de délégation d'exécution - transmet son état régulièrement au serveur, si pas de signe de vie le serveur fait du polling - aussi possible de donner un callback HTTP pour monitoring externe - flags pour déclenchement des workflows dépendants: écrits dans HDFS et utilisés comme input datasets (on pourrait utiliser zookeeper aussi) - forcer une éxécution séquentielle : conditionner à la sortie de l'instance précédente
- - Fire and forget Oozie - le serveur oozie n'est qu'un backend DB, les jobs sont auto-gérés - lancement d'une tâche controleur (map), dans certains cas execute l'action directement, sinon lance une autre application YARN; double niveau de délégation d'exécution - transmet son état régulièrement au serveur, si pas de signe de vie le serveur fait du polling - aussi possible de donner un callback HTTP pour monitoring externe - flags pour déclenchement des workflows dépendants: écrits dans HDFS et utilisés comme input datasets (on pourrait utiliser zookeeper aussi) forcer une éxécution séquentielle : conditionner à la sortie de l'instance précédente - possible par coordinateur, par workflow de spécifier les dates de début, de fin, la durée attendue - email ou autres moyens (SMS?) - en particulier, la map controleur est toujours SUCCEEDED, ce qui confuse les débutants - la map controleur récupère, dans le cas de hive, le log renvoyé par l'enfant - la map controleur, dans le cas d'un shell, est aussi l'exécuteur, donc logs directs
- Tout ça c’est joli, mais et perl? - tout le dialogue entre serveur et jobs se fait via REST (mais des fois obligé de lire la BDD directement) - interface accessible aux clients pour soumettre des jobs, lister, etc - ligne de commande est un wrapper autour d'appels HTTP - tourne comme une shell action - possible de passer des options possible de paralléliser
- - tout le dialogue entre serveur et jobs se fait via REST - interface accessible aux clients pour soumettre des jobs, lister, etc - ligne de commande est un wrapper autour d'appels HTTP - tourne comme une shell action - possible de passer des options possible de paralléliser