Dagster : un nouvel orchestrateur de données pour rapprocher les données de la valeur métier

Dans cet article, nous allons analyser un nouvel orchestrateur de données : Dagster. À notre avis, il s’agit de la première génération d’orchestrateurs de données qui rapprochent les pipelines de données des processus métier critiques qui seraient en réalité des processus de données métier pour des solutions critiques. Pour décrire les capacités et les cas d’utilisation de Dagster, nous allons fournir un contexte sur les modèles et des informations historiques nécessaires pour comprendre la valeur commerciale qu’il apporte.

Au cours de la dernière décennie, de nombreuses tendances ont porté sur les modèles d’orchestration et de chorégraphie. Nous allons fournir une description simple de ces modèles :

• Orchestration: C’est un workflow bien défini orchestré et centralisé by un système d’orchestration. Un système d’orchestration est comme un orchestre musical où il y a un chef d’orchestre qui dirige les musiciens pour définir le tempo et assurer des entrées correctes. Il existe trois caractéristiques principales de l’orchestration :
  1. Fournissez un flux de travail centralisé qui permet de visualiser facilement le processus métier ou de données.
  2. Le flux de travail est géré par une seule couche qui est le composant le plus critique. Si le système d’orchestration est en panne, il n’y a pas de service commercial, sans chef d’orchestre, il n’y a pas de concert choral.
  3. Ils sont très flexibles pour être intégrés dans différents modèles d’architecture tels que les API, les événements, les RPC ou les processus de données.

• Chorégraphie: Il est basé sur une architecture pilotée par les événements ou en continu, l’objectif est que chaque composant de l’architecture fonctionne, et a sa propre responsabilité de prendre des décisions sur les actions qu’il doit entreprendre. Il existe trois caractéristiques principales de la chorégraphie :
  1. Il doit être basé sur un modèle événementiel ou en continu.
  2. Il n’y a pas de couche unique et centralisée, il n’y a donc pas de point de défaillance unique à moins que vous n’ayez un seul courtier de messages.
  3. Fournir plus d’évolutivité, de flexibilité et également plus de complexité pour comprendre le processus.

Les orchestrateurs et les logiciels de gestion des processus métier ont toujours été proches de la couche métier, ce qui a accru leur popularité dans la feuille de route technologique stratégique de l’entreprise. La première génération de BPM a commencé vers l’an 2000 et était une technologie pour les ingénieurs en logiciel.

Quelques années plus tard, entre 2014 et 2018, les modèles événementiels et chorégraphiques ont commencé à gagner en popularité, d’abord avec Netflix, puis avec l’apparition de plateformes de streaming telles qu’Apache Kafka.

Le monde des données reste toujours un peu en retard par rapport au monde du logiciel. Bien qu’à mon avis, nous nous dirigeons vers un scénario où les mondes opérationnel et analytique ne seront pas isolés. Les architectures et les topologies d’équipe où la couche analytique et opérationnelle fonctionnent comme deux esprits différents ne fonctionnent pas lorsque les entreprises doivent appliquer une approche axée sur les données où les données font partie du cœur du processus de prise de décision.

Qu’est-il arrivé au monde des données

Lorsque le concept de big data a commencé à devenir populaire, les premiers orchestrateurs de données sont apparus, comme Apache Ozzie (2010 par Yahoo), basés sur des configurations DAG XML, un workflow planifié, et très centrés sur l’écosystème Hadoop. Un peu plus tard, Apache Airflow (2015 par Airbnb) est apparu basé sur Python. Il a fourni plus de fonctionnalités telles que le passage de la configuration DAG XML à la configuration programmatique, et plus d’intégrations en dehors des écosystèmes Hadoop, mais il s’agit également d’un système de workflows planifiés. Au milieu des deux est apparu Luigi (2012 par Spotify) : basé sur Python, mais orienté pipeline au lieu de DAG, mais incluant des bonnes pratiques logicielles intéressantes telles que les tests A/B.

<workflow-app name="useooziewf" xmlns="uri:oozie:workflow:0.1">
    ...
    <decision name="mydecision">
        <switch>
            <case to="reconsolidatejob">
              ${fs:fileSize(secondjobOutputDir) gt 10 * GB}
            </case> <case to="rexpandjob">
              ${fs:fileSize(secondjobOutputDir) lt 100 * MB}
            </case>
            <case to="recomputejob">
              ${ hadoop:counters('secondjob')[RECORDS][REDUCE_OUT] lt 1000000 }
            </case>
            <default to="end"/>
        </switch>
    </decision>
    ...
</workflow-app>

Flux d’air Apache était la première véritable évolution de l’orchestrateur de données, mais à notre avis, il a quelques points d’amélioration qui en font un produit très axé sur le monde traditionnel des données et non sur la nouvelle réalité dans laquelle les données deviennent le centre de la prise de décision dans entreprises.

• Il a une interface utilisateur médiocre, totalement orientée vers les ingénieurs de données.
• Il est principalement orienté vers l’exécution de tâches, sans savoir ce que font ces tâches.
• Tout est une tâche, augmentant la complexité en termes de maintenabilité et de compréhension.
• Fin 2021 a introduit le concept de capteurs qui sont un type particulier d’opérateur conçu pour attendre un événement externe tel qu’un événement Kafka, un message JMS ou basé sur le temps.

import requests
from airflow.decorators import dag, task

@dag(
    dag_id="example_complex",
    schedule_interval="0 0 * * *",
    start_date=pendulum.datetime(2022, 1, 1, tz="UTC"),
    catchup=False,
    dagrun_timeout=datetime.timedelta(minutes=60),
)
def ExampleComplex():
    ...
    @task
    def get_data():
        ...
    @task
    def merge_data():
        ...
dag = ProcessEmployees()

Toutes ces évolutions des solutions d’orchestration ont un point commun : les défis auxquels sont confrontées ces entreprises (Yahoo, Airbnb ou Spotify) pour gérer la complexité de leurs pipelines de données.

Data-Driven : la nouvelle ère des données

Cette première version des outils d’orchestrateur était très axée sur l’expérience des ingénieurs de données et basée sur l’architecture de plates-formes analytiques et opérationnelles traditionnelles telles que les lacs de données, les hubs de données ou les espaces de travail de science des données expérimentales.

David et moi (Miguel) avons commencé notre voyage dans le monde des données autour de l’année 2017. Avant cela, nous avions travaillé sur des solutions critiques opérationnelles proches des processus métier et basées sur des solutions événementielles. À ce moment-là, nous avons découvert certains des outils tels que Oozie ou flux d’air qui étaient des outils ETL axés sur des tâches/flux de travail planifiés sans offre de solution cloud, une mise en œuvre et une maintenance complexes pour l’entreprise, une évolutivité médiocre et une expérience utilisateur médiocre.

Notre première pensée à ce moment-là était que ce sont les outils dont nous devrions nous contenter maintenant mais que nous n’utiliserions pas dans les années à venir. Aujourd’hui l’approche data-driven a tout changé, chaque jour la frontière entre les charges de travail analytiques et opérationnelles est plus diffuse que jamais. Il existe de nombreux processus critiques basés sur des charges de travail analytiques et opérationnelles. Beaucoup de ces processus critiques seraient probablement très similaires au pipeline de données non critiques d’il y a quelques années. En 2020, Zhamak Dehghani a publié un article sur les principes du maillage de données, dont certains sont assez connus. Elle a écrit une phrase particulièrement significative pour nous concernant les avions opérationnels et analytiques : « Je crois qu’à un moment donné dans le futur, nos technologies évolueront pour rapprocher encore ces deux avions, mais pour l’instant, je suggère que nous gardions leurs préoccupations séparées. . »

Notre opinion est que ces avions sont plus proches que nous ne le pensons et en termes de valeur commerciale, ils sont plus réalisables à petite échelle que la logique architecture de maillage de données lui-même. Par exemple, considérez le secteur de la vente au détail de mode et les processus critiques tels que l’allocation, le commerce électronique ou les solutions logistiques. Tous ces processus qui étaient opérationnels il y a des années et dont beaucoup utilisaient des applications traditionnelles telles que SAP ou Oracle, aujourd’hui, ils ont besoin de processus de données sophistiqués qui incluent l’ingestion, la transformation, l’analyse et le modèle d’apprentissage automatique de données volumineuses pour fournir des recommandations en temps réel et des prévisions de la demande. pour permettre une prise de décision basée sur les données.

Bien sûr, les pipelines de données/flux de travail traditionnels sont nécessaires et les solutions traditionnelles basées sur des plates-formes opérationnelles et analytiques isolées continueront de fournir de la valeur pour certains rapports, processus analytiques par lots, expériences et autres innovations analytiques. Mais aujourd’hui, il existe d’autres types de processus de données ; des processus de données d’entreprise qui ont des besoins différents et offrent plus de valeur commerciale. Nous avons besoin de solutions de données offrant les fonctionnalités suivantes :

• Meilleure expérience de développement logiciel et gestion des données sous forme de code appliquer toutes les meilleures pratiques telles que les environnements isolés, les tests unitaires, l’A/B, les contrats de données, etc.
• Écosystème d’intégration convivial et riche non seulement avec le monde du big data mais avec le monde des données en général.
• Solutions basées sur le cloud qui offrent une évolutivité facile, une faible maintenance et une intégration facile avec les solutions IAM.
• Bien meilleure expérience utilisateur non seulement pour les développeurs, mais aussi pour les scientifiques des données, les analystes de données, les analystes commerciaux et les équipes opérationnelles

Présentation de Dagster

Dagster est une plate-forme d’orchestration de flux de données qui va au-delà de ce que nous comprenons comme un orchestrateur de données traditionnel. Le projet a été lancé en 2018 par Nick Shrock et a été conçu à la suite d’un besoin identifié par lui alors qu’il travaillait chez Facebook. L’un des objectifs de Dagster a été de fournir un outil qui supprime la barrière entre le développement du pipeline et l’exploitation du pipeline, mais au cours de ce voyage, il en est venu à relier le monde du traitement des données aux processus métier.

Dagster apporte des améliorations significatives par rapport aux solutions précédentes.

• Orienté vers les ingénieurs de données, les développeurs et les ingénieurs des opérations de données/d’entreprise : sa polyvalence et son abstraction nous permettent de concevoir des pipelines d’une manière plus orientée vers les développeurs, en appliquant les meilleures pratiques logicielles et en gérant les données, et les pipelines de données sous forme de code.
• Conforme à l’approche des premiers principes de l’ingénierie des données, le cycle de vie complet du développement : développement, déploiement, surveillance et observabilité
• Il comprend un concept nouveau et différent, qui est un actif défini par logiciel. Un actif est un objet de données ou d’apprentissage automatique…