Éviter le goulot d’étranglement des données — maillage de données à Starship | par Taavi Pungas | Technologies des vaisseaux spatiaux | Mai 2021


Taavi Pungas

Un gigaoctet de données pour un sac d’épicerie. C’est ce que vous obtenez lorsque vous effectuez une livraison robotique. Cela fait beaucoup de données, surtout si vous le répétez plus d’un million de fois comme nous l’avons fait.

Mais le terrier du lapin va plus loin. Les données sont également incroyablement diverses : données d’images et de capteurs de robots, interactions des utilisateurs avec nos applications, données transactionnelles des commandes et bien plus encore. Et tout aussi divers sont les cas d’utilisation, allant de la formation de réseaux de neurones profonds à la création de visualisations soignées pour nos partenaires marchands, et tout le reste.

Jusqu’à présent, nous avons été en mesure de gérer toute cette complexité avec notre équipe de données centralisée. À l’heure actuelle, la croissance exponentielle continue nous a amenés à rechercher de nouvelles méthodes de travail pour maintenir le rythme.

Nous avons trouvé que le paradigme du maillage de données était la meilleure voie à suivre. Je vais décrire ci-dessous le point de vue de Starship sur le maillage de données, mais d’abord, passons en revue brièvement l’approche et pourquoi nous avons décidé de l’utiliser.

Qu’est-ce qu’un maillage de données ?

Le cadre de maillage de données a été décrit pour la première fois par Zhamak Dehghani. Le paradigme repose sur ce qui suit concepts de base: produits de données, domaines de données, plateforme de données et gouvernance des données.

L’objectif principal du cadre de maillage de données a été d’aider les grandes organisations à éliminer les goulots d’étranglement de l’ingénierie des données et à gérer la complexité. Par conséquent, il aborde de nombreux détails pertinents dans un environnement d’entreprise, allant de la qualité des données, de l’architecture et de la sécurité à la gouvernance et à la structure organisationnelle. En l’état, seulement quelques entreprises ont publiquement annoncé leur adhésion au paradigme du maillage de données — toutes les grandes entreprises de plusieurs milliards de dollars. Malgré cela, nous pensons qu’il peut également être appliqué avec succès dans les petites entreprises.

Maillage de données dans Starship

Les données fonctionnent-elles à proximité des personnes produisant ou consommant l’information

Pour gérer des marchés de livraison robotique hyperlocaux à travers le monde, nous devons transformer une grande variété de données en produits de valeur. Les données proviennent de robots (par exemple, télémétrie, décisions de routage, ETA), de commerçants et de clients (avec leurs applications, commandes, offres, etc.) et de tous les aspects opérationnels de l’entreprise (des brèves tâches d’opérateur à distance à la logistique globale des pièces de rechange pièces détachées et robots).

La diversité des cas d’utilisation est la principale raison qui nous a attirés vers l’approche du maillage de données – nous voulons effectuer le travail sur les données très près des personnes produisant ou consommant l’information. En suivant les principes du maillage de données, nous espérons répondre aux divers besoins en données de nos équipes tout en maintenant une supervision centrale raisonnablement légère.

Comme Starship n’est pas encore à l’échelle de l’entreprise, il n’est pas pratique pour nous de mettre en œuvre tous les aspects d’un maillage de données. Au lieu de cela, nous avons opté pour une approche simplifiée qui a du sens pour nous maintenant et nous met sur la bonne voie pour l’avenir.

Produits de données

Définissez ce que sont vos produits de données — chacun avec un propriétaire, une interface et des utilisateurs

L’application de la pensée produit à nos données est le fondement de toute l’approche. Nous considérons tout ce qui expose des données pour d’autres utilisateurs ou processus comme un produit de données. Il peut exposer ses données sous n’importe quelle forme : en tant que tableau de bord BI, sujet Kafka, vue d’entrepôt de données, réponse d’un microservice prédictif, etc.

Un exemple simple de produit de données dans Starship pourrait être un tableau de bord BI pour les prospects de site afin de suivre le volume d’affaires de leur site. Un exemple plus élaboré serait un pipeline en libre-service pour les ingénieurs en logiciels de robots pour envoyer tout type d’informations de conduite des robots dans notre lac de données.

Dans tous les cas, nous ne traitons pas notre entrepôt de données (en réalité un lac Databricks) comme un seul produit, mais comme une plate-forme prenant en charge un certain nombre de produits interconnectés. Ces produits granulaires appartiennent généralement aux data scientists/ingénieurs qui les créent et les entretiennent, et non aux chefs de produits dédiés.

Le propriétaire du produit doit savoir qui sont ses utilisateurs et quels besoins ils résolvent avec le produit – et sur cette base, définir et répondre aux attentes de qualité pour le produit. Peut-être en conséquence, nous avons commencé à accorder plus d’attention aux interfaces, des composants cruciaux pour la convivialité mais laborieux à modifier.

Plus important encore, comprendre les utilisateurs et la valeur que chaque produit crée pour eux facilite grandement la hiérarchisation des idées. Ceci est essentiel dans un contexte de démarrage où vous devez vous déplacer rapidement et n’avez pas le temps de tout rendre parfait.

Domaines de données

Regroupez vos produits de données en domaines reflétant la structure organisationnelle de l’entreprise

Avant de prendre connaissance du modèle de maillage de données, nous avions utilisé avec succès le format de data scientists légèrement embarqués pendant un certain temps dans Starship. En effet, certaines équipes clés avaient un membre de l’équipe de données qui travaillait avec elles à temps partiel, peu importe ce que cela signifiait dans une équipe en particulier.

Nous avons procédé à la définition de domaines de données en adéquation avec notre structure organisationnelle, en veillant cette fois à couvrir toutes les parties de l’entreprise. Après avoir mappé les produits de données sur les domaines, nous avons affecté un membre de l’équipe de données pour organiser chaque domaine. Cette personne est chargée de s’occuper de l’ensemble des produits de données dans le domaine – dont certains appartiennent à la même personne, d’autres à d’autres ingénieurs de l’équipe du domaine, ou même à d’autres membres de l’équipe de données (par exemple pour des raisons de ressources) .

Il y a un certain nombre de choses que nous aimons dans la configuration de notre domaine. D’abord et avant tout, chaque domaine de l’entreprise a désormais une personne qui s’occupe de son architecture de données. Compte tenu des subtilités inhérentes à chaque domaine, cela n’est possible que parce que nous avons divisé le travail.

La création d’une structure dans nos produits de données et nos interfaces nous a également aidés à mieux comprendre notre monde des données. Par exemple, dans une situation avec plus de domaines que de membres de l’équipe de données (actuellement 19 contre 7), nous faisons maintenant un meilleur travail pour nous assurer que chacun d’entre nous travaille sur un ensemble de sujets interdépendants. Et nous comprenons maintenant que pour atténuer les douleurs de croissance, nous devons minimiser le nombre d’interfaces utilisées au-delà des limites de domaine.

Enfin, un bonus plus subtil dans l’utilisation des domaines de données : on sent désormais que l’on dispose d’une recette pour faire face à toutes sortes de situations nouvelles. Chaque fois qu’une nouvelle initiative est lancée, il est beaucoup plus clair pour tout le monde à qui elle appartient et qui devrait s’en occuper.

Il y a aussi des questions ouvertes. Alors que certains domaines penchent naturellement vers l’exposition des données sources et d’autres vers leur consommation et leur transformation, certains ont une bonne quantité des deux. Devrions-nous les séparer lorsqu’ils deviennent trop gros ? Ou devrions-nous avoir des sous-domaines au sein de plus grands ? Nous devrons prendre ces décisions plus tard.

Plateforme de données

Autonomisez les personnes qui créent vos produits de données en standardisant sans centraliser

L’objectif de la plate-forme de données dans Starship est simple : permettre à une seule personne responsable des données (généralement un scientifique des données) de s’occuper d’un domaine de bout en bout, c’est-à-dire de garder l’équipe centrale de la plate-forme de données hors de la journée travail d’aujourd’hui. Cela nécessite de fournir aux ingénieurs du domaine et aux scientifiques des données de bons outils et des blocs de construction standard pour leurs produits de données.

Cela signifie-t-il que vous avez besoin d’une équipe complète de plateforme de données pour l’approche de maillage de données ? Pas vraiment. Notre équipe de plate-forme de données se compose d’un seul ingénieur de plate-forme de données, qui passe en parallèle la moitié de son temps à être intégré dans un domaine. La principale raison pour laquelle nous pouvons être si légers dans l’ingénierie des plateformes de données est le choix de Spark+Databricks comme cœur de notre plateforme de données. Notre ancienne architecture d’entrepôt de données, plus traditionnelle, nous imposait une surcharge d’ingénierie des données en raison de la diversité de nos domaines de données.

Nous avons trouvé utile de faire une distinction claire dans la pile de données entre les composants qui font partie de la plate-forme et tout le reste. Quelques exemples de ce que nous fournissons aux équipes de domaine dans le cadre de notre plateforme de données :

  • Databricks+Spark en tant qu’environnement de travail et plate-forme de calcul polyvalente ;

De manière générale, notre objectif est de standardiser autant que cela a du sens dans notre contexte actuel – même des bits dont nous savons qu’ils ne resteront pas standardisés pour toujours. Tant que cela aide la productivité en ce moment et ne centralise aucune partie du processus, nous sommes heureux. Et bien sûr, certains éléments sont totalement absents de la plateforme actuellement. Par exemple, les outils pour l’assurance qualité des données, la découverte des données et le lignage des données sont des choses qu’il nous reste pour l’avenir.

Gouvernance des données

Forte appropriation personnelle soutenue par des boucles de rétroaction

Avoir moins de personnes et d’équipes est en fait un atout dans certains aspects de la gouvernance, par exemple, il est beaucoup plus facile de prendre des décisions. D’autre part, notre question clé de gouvernance est aussi une conséquence directe de notre taille. S’il n’y a qu’un seul responsable des données par domaine, on ne peut pas s’attendre à ce qu’il soit un expert dans tous les aspects techniques potentiels. Cependant, ils sont la seule personne à avoir une compréhension détaillée de leur domaine. Comment maximiser les chances qu’ils fassent les bons choix dans leur domaine ?

Notre réponse : via une culture d’appropriation, de discussion et de feedback au sein de l’équipe. Nous avons largement emprunté à la philosophie de gestion dans Netflix et a cultivé ce qui suit :

  • responsabilité personnelle pour le résultat (de ses produits et domaines);

Nous avons également conclu quelques accords spécifiques sur notre approche de la qualité, rédigé nos meilleures pratiques (y compris les conventions de dénomination), etc. Mais nous pensons que de bonnes boucles de rétroaction sont l’ingrédient clé pour transformer les directives en réalité.

Ces principes s’appliquent également en dehors du travail de « construction » de notre équipe de données – ce qui a été l’objet de cet article de blog. Évidemment, il y a bien plus que de fournir des produits de données sur la façon dont nos scientifiques des données créent de la valeur dans l’entreprise.

Une dernière réflexion sur la gouvernance — nous continuerons à répéter nos méthodes de travail. Il n’y aura jamais une seule « meilleure » façon de faire les choses et nous savons que nous devons nous adapter au fil du temps.

Derniers mots

Ça y est …! Ce sont les 4 concepts de base de maillage de données appliqués dans Starship. Comme vous pouvez le voir, nous avons trouvé une approche du maillage de données qui nous convient en tant qu’entreprise agile en phase de croissance. Si cela semble attrayant dans votre contexte, j’espère que la lecture de notre expérience a été utile.

Si vous souhaitez participer à notre travail, consultez notre page carrière pour une liste des postes ouverts. Ou consultez notre chaîne Youtube pour en savoir plus sur notre service de livraison robotique de premier plan.

Contactez-moi si vous avez des questions ou des idées et apprenons les uns des autres !



Source Link

Please follow and like us: