A BAS CRON !
VIVE OOZIE !
“possibly the most underrated
component of the Hadoop stack”
david.morel@booking.com
Fast forward
• Problèmes de cron
• Rappel archi Hadoop/YARN
• Archi oozie
• Workflow
• Coordinator
• Exécution
• Contrôle,...
Crond
• Adapté aux tâches locales
• Mal à l’aise pour le reste
• Scalabilité horizontale ?
• Dépendances ?
• Contrôle, rer...
Hadoop : YARN
Oozie
• 1 serveur (ou 2, pour HA)
• 1 backend DB (agnostique)
• 1 cluster Hadoop (HDFS + YARN)
• C’est tout !
Workflow intro
• L’unité de base
• Définition en XML
• + job.properties
• + options (jars, lib, etc)
• Upload sur HDFS
• o...
Workflows, DAG
Workflow guts
• “ligne de commande de cron”
• DAG
• Actions externes / internes
• Decision nodes
• Forks
• Communication e...
Coordinator secrets
• “spécification de fréquence de cron”
• Parent du workflow
• Le maître du temps
• Abstraction : “nomi...
Exécution
• Fire and forget
• Worker map + child
• Worker call home
• Callbacks optionnels
• Flags sur HDFS
Pros & C(r)ons
• C’est nul comme jeu de mots
• Parallélisme, retries
• La précieuse abstraction du temps
• Contrainte : id...
Perl & Oozie
• REST : listen, parse, introspect
• Monitor, submit, start, stop, query
• Shell action hors JVM
• STDIN/OUT/...
Perl & Oozie
• @booking.com
Merci !
• Questions ?
Prochain SlideShare
Chargement dans…5
×

A bas Cron ! Vive Oozie !

1 230 vues

Publié le

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.

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 230
Sur SlideShare
0
Issues des intégrations
0
Intégrations
289
Actions
Partages
0
Téléchargements
5
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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
  • A bas Cron ! Vive Oozie !

    1. 1. A BAS CRON ! VIVE OOZIE ! “possibly the most underrated component of the Hadoop stack” david.morel@booking.com
    2. 2. Fast forward • Problèmes de cron • Rappel archi Hadoop/YARN • Archi oozie • Workflow • Coordinator • Exécution • Contrôle, SLA, etc • Perl ?
    3. 3. Crond • Adapté aux tâches locales • Mal à l’aise pour le reste • Scalabilité horizontale ? • Dépendances ? • Contrôle, reruns, etc • Que des soucis !
    4. 4. Hadoop : YARN
    5. 5. Oozie • 1 serveur (ou 2, pour HA) • 1 backend DB (agnostique) • 1 cluster Hadoop (HDFS + YARN) • C’est tout !
    6. 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 !
    7. 7. Workflows, DAG
    8. 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. 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. 10. Exécution • Fire and forget • Worker map + child • Worker call home • Callbacks optionnels • Flags sur HDFS
    11. 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. 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. 13. Perl & Oozie • @booking.com
    14. 14. Merci ! • Questions ?

    ×