Les systèmes de données tendent vers la production

Les dix dernières années ont vu un renouvellement quasi complet des outils à disposition d'un professionnel de la data. En regardant la pile de données moderne d'aujourd'hui, la majorité des outils (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) n'étaient pas disponibles dans le commerce en 2012. Des catégories entières (ELT, Reverse ETL, entrepôts cloud) et des cadres (activation de données, maillages de données , data fabrics, contrats de données) ont été créés. (Ou dans certains cas, des pratiques SWE vieilles de plusieurs décennies ont été redécouvertes par des équipes de données.) L'opportunité abonde.

La possibilité et la surface pour un professionnel des données d'influencer l'orientation d'une entreprise sont considérablement plus importantes qu'il y a dix ans. Malheureusement, la surface de ce qui peut mal tourner a augmenté tout aussi rapidement. Les défis vont des SLA techniques de bas niveau aux systèmes, à la culture, aux normes et à la conception organisationnelle de haut niveau. Les nouveaux outils sont incroyablement puissants. Les entreprises peuvent à la fois construire et casser des systèmes de données à une vitesse plus élevée que jamais.

J'ai observé trois tendances pour les systèmes de données au cours des cinq dernières années, allant des verticaux techniques au sein des équipes de données, ainsi que des verticaux commerciaux soutenus par les données. Je vais essayer de décrire ces tendances à l'aide d'exemples qui se généralisent à de nombreuses entreprises et, espérons-le, décrire les opportunités, les problèmes et les solutions de manière à se généraliser à votre équipe. Les tendances, les opportunités, les problèmes et les solutions :

Les systèmes tendent vers la production

• Résumé : le travail de données précieux et les résultats finissent par être consommés dans des cas d'utilisation de plus en plus importants / de qualité production.
• Opportunité : les résultats d'une équipe de données peuvent être répartis sur une surface beaucoup plus grande et plus percutante.
• Problème : les sorties de données étant consommées par des cas d'utilisation plus importants, il n'y a pas de « durcissement » correspondant des workflows, qui ont initialement été mis en place de manière très légère.
• Solution : Créez un chemin pour que les flux légers soient promus en « production », célébrez le temps passé à durcir les systèmes au fur et à mesure qu'ils évoluent vers le niveau de production.

• Résumé : les sorties de données initialement destinées à un objectif spécifique trouvent de plus en plus et sans le savoir l'adoption dans de nombreuses équipes et cas d'utilisation.
• Opportunité : les informations conçues pour un cas d'utilisation spécifique peuvent améliorer la prise de décision/les résultats dans un plus grand nombre d'équipes.
• Problème : deux équipes n'ont pas exactement les mêmes spécifications, les améliorations pour un cas d'utilisation ne sont pas consommées ailleurs.
• Solution : créer des engagements consommateurs/producteurs + visibilité sur les dépendances, centraliser la logique métier.

• Résumé : Les données peuvent être transformées à de nombreuses étapes tout au long de leur parcours, la logique métier vit dans une variété d'outils.
• Opportunité : les outils de données modernes permettent aux parties prenantes d'accéder aux données et d'effectuer des transformations du dernier kilomètre pour se déplacer plus rapidement et se débloquer.
• Problème : la logique métier à travers la pile rend la reproductibilité impossible, les transformations du dernier kilomètre ne profitent pas aux autres consommateurs de données.
• Solution : Réduisez les zones dans lesquelles la logique métier peut être injectée, créez des politiques de « durée de vie » sur les transformations du dernier kilomètre, construisez une culture de standardisation et de célébration de l'accès aux bases de code interfonctionnelles.

Été 2019 . La montée de l'eau de Seltz enrichie est imparable, mais il y a encore des propriétaires de magasins d'alcools mamans et pop qui ne le savent pas. Vous êtes ingénieur analytique sur un marché d'alcool B2C. Vos gestionnaires de compte (experts en consommation d'alcool) SAVENT que les Griffes s'envoleront des étagères, si seulement vous pouvez les obtenir dans les magasins. C'est le marché insaisissable de l'amélioration pareto gagnant/gagnant/gagnant, où un meilleur inventaire profite au client, au détaillant et à l'entreprise. Vous avez été chargé de déterminer les articles les plus vendus qu'un magasin d'alcools de votre réseau ne propose pas.

1. Usage interne (outil BI / Looker)

La requête initiale est facile à écrire. Il existe un tableau des magasins (avec market_id, les SKU les plus vendus par marché et un flux d'inventaire quotidien pour chaque magasin). Chaque magasin dispose d'un flux d'inventaire quotidien. Quelque chose comme ça obtient les articles les plus vendus que chaque magasin ne propose pas :

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

… le gestionnaire de compte initial donne son avis sur le tableau de bord tout au long du processus.

Remarque : L'outil BI est une infrastructure d'équipe de données. Aucun aperçu/cas d'utilisation/produit n'a quitté le domaine de l'équipe de données. Une erreur a peu de conséquences, les retours sont probables + immédiats.

2. Usage interne (Outils internes / Salesforce)

Cependant, une équipe de vente / réussite client / gestion de compte ne passe pas toute la journée dans Looker - elle passe toute la journée dans Salesforce. Avoir deux navigateurs ouverts est pénible. Il s'agit d'un cas d'utilisation ETL inversé manuel. Placez les données là où elles seront utilisées . C'était difficile il y a des années, maintenant c'est trivial - signez un fournisseur ETL inversé, déplacez vos points de données de A à B en moins d'une journée.

Les articles les plus vendus qu'un magasin ne propose pas sont désormais dans Salesforce. L'équipe des données a ajouté du contexte pour une autre équipe de manière peu contraignante. C'est à cela que sert l'activation des données : donner aux autres équipes les moyens de mieux faire leur travail avec les outils qu'ils connaissent. Plus de gestionnaires de compte examinent plus d'articles manquants dans les stocks, appellent plus de magasins, plus de SKU haut de gamme se retrouvent dans les magasins d'alcools, plus de ventes se produisent. Tout le monde gagne.

… un responsable de compte remarque qu'un magasin de bière et de vin a des articles d'alcool sur sa liste d'articles les plus vendus. L'AM utilise son contexte commercial et omet de recommander des articles qu'il sait que le magasin ne peut pas vendre légalement. Une logique métier supplémentaire a été ajoutée via une couche de décision humaine.

Remarque : Salesforce n'est PAS une infrastructure d'équipe de données. Les informations et les cas d'utilisation ont quitté le domaine de l'équipe de données, mais pas de l'entreprise. Rien n'est face au client. Une erreur a peu de conséquences, mais la rétroaction n'est pas garantie. Une logique supplémentaire a été ajoutée (via le jugement humain).

3. Utilisation externe (Marketing Automation)

La mise en œuvre de Salesforce est utile, mais reste de nature assez manuelle. Les gestionnaires de compte et les propriétaires de magasins d'alcools passent trop de temps au téléphone. La plupart des magasins d'alcools passent des commandes d'inventaire une fois par semaine. L'AM fait appel à l'aide des opérations de données et de marketing pour rationaliser la communication via des e-mails automatisés sur une cadence hebdomadaire.

Quelques colonnes supplémentaires sont nécessaires, puis la table brute est inversée ETL dans Hubspot / Iterable / Braze. Un associé CRM met la touche finale à la campagne par e-mail, et une campagne par e-mail intitulée "Top Items You Don't Carry" est mise en ligne.

… l'associé du CRM en charge de l'e-mail remarque que certains des articles les plus vendus (en nombre) sont des pincées d'alcool. Cela ne correspond pas à la vision de la marque de l'entreprise / au cas d'utilisation souhaité par le client. La plupart des systèmes de messagerie permettent une couche supplémentaire de logique - l'associé CRM utilise son jugement pour filtrer tous les éléments avec un volume de 50 ml ou moins.

Remarque : les informations et les cas d'utilisation ont quitté le domaine de l'équipe de données et de l'entreprise. Les résultats de l'équipe de données sont désormais accessibles aux clients. Une erreur a des conséquences plus importantes, les commentaires sont moins susceptibles d'être transmis correctement à la bonne partie prenante. Une logique métier supplémentaire a été ajoutée (via la transformation du dernier kilomètre dans la couche CRM).

4. Usage externe (Application Production)

L'équipe des données entend l'équipe AM et CRM - certains magasins d'alcools sont assez anciens et ils ne vérifient pas les e-mails. D'autres magasins d'alcools sont de la nouvelle école et ils ne veulent pas attendre une semaine entière pour recevoir un e-mail sur les tendances de leur marché. Le groupe décide de faire appel à l'équipe de l'application de vente au détail pour mettre « les meilleurs articles que vous ne transportez pas » dans l'application de production sur laquelle tous les détaillants s'exécutent. L'équipe de données déplace sa sortie dans un compartiment AWS S3, où elle est récupérée par l'ingénierie de production. Les employés des magasins d'alcools peuvent désormais voir cette liste tous les jours, sans avoir besoin d'un gestionnaire de compte ou de friction par e-mail. White Claw et Whispering Angel se retrouvent dans tous les magasins en Amérique.

… un détaillant dépose une plainte auprès du détaillant CX - ils ont délibérément cessé de stocker la vodka à la menthe poivrée Smirnoff après les vacances. Il s'agit peut-être littéralement d'un article L90 le plus vendu, mais il est extrêmement saisonnier et ils ne veulent pas le voir dans leur liste recommandée. Cette rétroaction est transmise à l'équipe d'ingénierie de production, cette équipe effectue un ajustement logique dans la couche d'application pour identifier et supprimer les éléments saisonniers passés.

Remarque : les informations et les cas d'utilisation ont quitté le domaine de l'équipe de données et de l'entreprise. Les sorties de l'équipe de données sont orientées vers le client. Une erreur a des conséquences plus importantes, les commentaires sont moins susceptibles d'être transmis à la bonne partie prenante. Une logique supplémentaire a été ajoutée (via la logique métier dans la couche d'application de production).

Une dernière hypothèse : l'équipe d'ingénierie en charge de la consommation des flux d'inventaire (différente de l'équipe en charge de l'application marchand) migre vers un nouveau schéma d'inventaire. Ils ne sont pas au courant d'une seule étape du projet "Top Items You Don't Carry", des dépendances que l'équipe de données a construites en silence sur leur travail, ou des dépendances que d'autres ont construites sur le travail de l'équipe de données. Ils suppriment la table initiale. NULLs flux vers Looker, Salesforce, Hubspot et l'application de production du détaillant. L'équipe data a cassé la prod.

Récapitulons ce qui s'est passé, en bien comme en mal :

Du point de vue d'un professionnel des données qui a commencé sa carrière avant "l'activation des données", tout ce qui vient de se passer (sauf la fin) est incroyable ! Ce qui a commencé comme un tableau de bord Looker s'est rapidement transformé en une application de production, avec une valeur commerciale démontrée à chaque étape. Aucune ressource SWE n'a été nécessaire jusqu'à la toute fin, lorsque le produit proposé avait déjà été validé par les utilisateurs.

L'impact et la trajectoire de carrière d'un professionnel des données sont limités par la surface qu'il peut influencer. L'analyste décisionnel de 2012 a été plafonné à Tableau + présentations internes. Le professionnel des données d'aujourd'hui PEUT insérer des lignes dans Salesforce, déclencher des e-mails marketing et créer des produits de données à utiliser dans les services et applications de production. C'est une super nouvelle !

Du mauvais côté : le professionnel des données d'il y a dix ans était habitué aux messages "Hé, les données ont l'air fausses". Le pire scénario consistait à mettre de mauvaises métriques dans un jeu de cartes. Aujourd'hui, l'équipe de données peut se réveiller avec les notifications de Pagerduty indiquant qu'elle a cassé Salesforce, Hubspot et l'application de production, si Pagerduty est même configuré . L'activation des données a soulevé les enjeux de ce qu'une équipe de données peut briser.

Dans ce cas hypothétique, les responsables des magasins et des comptes seront ennuyés pendant un jour ou deux jusqu'à ce que l'erreur soit corrigée. Tout bien considéré, cette erreur est relativement gratuite.

Cela ne veut pas dire que cela ne peut pas être coûteux! Imaginez une sortie de science des données qui prédit le taux de désabonnement des clients et un code promotionnel de 5 $ est envoyé lorsque cette probabilité franchit un certain seuil. Maintenant, imaginez que le modèle est mal recyclé, ou recalibré, ou vraiment n'importe quoi. Les mêmes canaux d'activation de données peuvent être utilisés pour envoyer par inadvertance des millions de dollars de codes promotionnels.

La pile de données moderne facilite incroyablement la production des sorties de données, qu'elles doivent être produites ou que l'équipe qui a créé les entrées sache comment les sorties sont consommées. Ces outils ne nécessitent pas de durcissement de la requête ou du pipeline initial car ils sont élevés à des cas d'utilisation plus importants. Ils ne nécessitent pas le consentement ou la visibilité de ceux qui ont construit la sortie initiale.

Si vous vous souvenez de la logique métier supplémentaire :

• Le gestionnaire de compte a utilisé son jugement et a omis de recommander des SKU d'alcool aux magasins de bière/vin
• L'associé CRM a supprimé les SKU <= 50 ml en raison de considérations liées à la marque
• L'équipe d'application du détaillant a supprimé les SKU hautement saisonniers en raison des commentaires des clients

Alors, que pouvons-nous faire pour résoudre ces problèmes ?

Les systèmes tendent vers la production

Les histoires d'horreur, les problèmes généralisés et les solutions techniques pour les systèmes de production ont été écrits avec éloquence à travers les données twitter et substack. Les solutions sont, en grande partie, les meilleures pratiques que les SWE connaissent depuis des décennies (ou, comme Zach Kanter l' a dit d'une autre manière , l'ingénierie des données en statu quo n'est que du génie logiciel sans les meilleures pratiques ). Quelques-uns des éléments/principes qui m'ont le plus marqué pour les équipes de données :

Les équipes de données ne contrôlent pas leurs entrées (h/t Nick Schrock )

Les sorties de données sont à la base de nombreuses décisions dans les organisations, peu importe si un humain ou un algorithme en est responsable. Cependant, les équipes de données ne contrôlent pas leurs entrées comme le font les ingénieurs logiciels. Les équipes de données doivent être défensives dans leurs calculs en investissant dans l'AQ ; pour les problèmes passés ainsi que pour les problèmes qui ne se sont pas encore produits. Ce test devrait inclure :

• Validité des lignes simples ( intlorsque vous attendez un int, <50 lorsque vous attendez <50)
• Validité des lignes agrégées (hypothèses de granularité, contexte métier autour du nombre de lignes, nombre de lignes par rapport à hier, distributions d'agrégations telles que sommes, moyennes, p90, médianes)
• Existence / obsolescence des données (les dernières tables de temps ont été mises à jour)

Le coût d'une erreur est exponentiellement plus élevé dans un système de production qu'il ne l'est dans la mise en scène. Créez des pipelines de test de données et des modèles de développement et de déploiement qui détectent les erreurs et testent les hypothèses le plus tôt possible.

Ce sont des solutions qui peuvent être mises en œuvre par des équipes de données qui choisissent les bons outils (nous aimons Great Expectations ) et mettent l'effort. C'est 20% du problème. Les 80 % de défis organisationnels et de communication restants sont à l'origine de la défaillance des systèmes. Voici les solutions à l'échelle de l'entreprise :

Créer des échappements de données de qualité production

Ou créer délibérément des données . Les entreprises qui croient que la science des données est puissante devraient également croire en la création délibérée de données de production pour alimenter l'apprentissage automatique et les cas d'utilisation d'analyse avancée (h/t Yali Sasoon). Cela nécessite un partenariat avec des ingénieurs et un alignement à l'échelle de l'entreprise sur le fait que les données peuvent être délibérément créées, et non péniblement extraites.

Créer et célébrer un chemin vers la production

Les entreprises célèbrent trop souvent les itérations rapides dans un environnement de développement sans se tailler les conseils ou le temps de se durcir pour atteindre le niveau de production. Célébrez ce travail et réservez un temps et une propriété interfonctionnels explicites pour le renforcement des systèmes.

Les systèmes tendent vers une fédération aveugle

Encore une fois, célébrons ce problème ! Si de nombreuses personnes trouvent différents cas d'utilisation commerciale pour les sorties de l'équipe de données, vous faites quelque chose de bien. Mais, de la même manière qu'un tableau de bord ad hoc pouvait en faire un tableau de bord il y a 10 ans, cette requête ad hoc peut en faire une application de production sans que vous le sachiez.

Tirez parti d'un plan de contrôle unique pour l'orchestration pilotée par les événements

Fivetran, dbt et Hightouch ont tous la possibilité de planifier des tâches via les horaires cron et l'interface utilisateur. Cela permet à l'orchestration d'être construite de manière à ne pas faire apparaître la visibilité dans les dépendances implicites. Imaginez que Hightouch doit se déplacer exp_fb_click_idstous les jours à 8h du matin via l'interface utilisateur. Fivetran et dbt n'ont aucune visibilité sur cette dépendance, pas plus que ceux qui contribuent aux bases de code en amont de Hightouch.

Utilisez plutôt un outil d'orchestration (Dagster/Prefect/Airflow) comme plan de contrôle unique. Fusionnez les dépendances entre les outils et créez un DAG holistique qui s'exécute en fonction des succès des étapes précédentes au lieu d'espérer que les tâches en amont réussissent à une certaine heure de la journée. Regroupement .

Créer des mappages individuels des exportations de l'équipe de données vers les cas d'utilisation en aval

Les équipes de données doivent être familiarisées avec la manière dont dbt suggère de structurer les projets . En règle générale, la couche intermédiaire est organisée et nommée de manière à rendre extrêmement claire une relation un à un avec les entrées source. Utilisez un modèle similaire pour les sorties. Dans la même mesure, il devrait être évident que l'objet Salesforce Opportunity and Account représente une table dbt dans le staging, il devrait être évident que les exportations de données sont utilisées pour un et un seul cas d'utilisation.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

Au lieu de résumer la stratification, je vous renvoie à nouveau au merveilleux fil conducteur et à la définition de Jean-Michel Lemieux. Le conseil général est le sien, avec quelques données spécifiques qui ont fonctionné pour moi.

La définition technique de la couche inite est que les équipes placent le code là où elles sont le plus à l'aise tout en optimisant la vitesse par rapport à mettre le code là où il appartient lorsqu'on envisage une perspective à plus long terme sur le système logiciel global.

Réduisez les zones où la logique métier peut être injectée dans le dernier kilomètre :

Hightouch et Census autorisent les transformations SQL. Fivetran utilisé pour . La plupart des consommateurs d'activation de données (Sales/CX CRM, CDP) autorisent une couche de logique métier SQL ou peu/pas de code. Dans la mesure du possible, n'écrivez pas de logique métier dans ces outils. Si vous suivez le mappage un à un des exportations de l'équipe de données vers les cas d'utilisation en aval, votre ETL inverse peut toujours être :

select * from exp_table_for_single_use_case;

Les modifications de la logique métier doivent être appliquées à ce modèle dbt, plutôt qu'au dernier kilomètre.

Créez des politiques "Time To Live" sur les transformations du dernier kilomètre :

Une équipe de données ne peut pas se débarrasser entièrement des transformations du dernier kilomètre. Vous ne voulez pas que vos parties prenantes aient l'impression d'être bloquées par l'équipe des données. Il sera toujours nécessaire d'introduire des correctifs ou d'itérer sur une logique métier plus rapide qu'une actualisation dbt PR + Snowflake.

Plus généralement, les parties prenantes de votre entreprise ont un contexte que vous n'avez pas. Vous voulez voir comment ils modifient vos données. Repensez au SKU saisonnier, au volume, à la logique de catégorisation des magasins que l'ingénieur analytique a manqué. Créez un monde où les parties prenantes de votre entreprise peuvent améliorer votre travail !

Une politique « Time To Live » est un retour gravitationnel vers la centralisation. Autorisez les transformations du dernier kilomètre, mais examinez-les et ramenez la logique métier dans une couche centrale de base de données / science des données à une cadence qui convient à votre équipe de données et aux parties prenantes de l'entreprise

Construire une culture de normalisation + célébrer l'accès aux bases de code interfonctionnelles

Les gens écrivent par défaut la logique métier dans l'outil avec lequel ils sont le plus à l'aise. Pour un associé CRM, cela pourrait être Hubspot / Iterable / Braze. La meilleure façon pour les équipes de données d'empêcher l'étalement de la logique métier n'est pas seulement de limiter les transformations du dernier kilomètre dans d'autres outils, mais aussi d'inviter d'autres personnes dans leurs outils.

Cela peut être une ️️️ prise. Il existe de nombreuses raisons de s'inquiéter du fait que des membres de l'équipe non chargés des données écrivent de la logique en SQL et créent des relations publiques dbt. Ce que je peux garantir - cette logique sera écrite, et si l'équipe des données garde le contrôle, elle sera écrite en dehors de leur visibilité. Si une équipe de données peut éduquer et encourager les contributions à sa base de code, elle invite le code à être écrit là où il appartient le plus.

Faire atterrir l'avion :

C'est le moment idéal pour être un leader des données. La dernière décennie de développement de l'écosystème de données a banalisé le mouvement et la manipulation des données entre les outils propriétaires et tiers. Un professionnel de l'analyse talentueux avec un rêve et une carte de crédit peut alimenter les rapports internes, les outils internes, les automatisations marketing et les applications de production. C'est une nouvelle objectivement incroyable pour les entreprises et les professionnels de la donnée.

• La pile de données moderne permet à une équipe de données de tout produire, qu'elle le soit ou non, et sans autorisation ni visibilité de l'ingénierie de production.
• La pile de données moderne permet à une partie prenante de l'entreprise d'ajouter une logique métier du dernier kilomètre pour alimenter les workflows de production, qu'ils le soient ou non, et sans l'autorisation ou la visibilité de l'équipe de données.

À un moment donné, vos produits de données vont casser l'application de production. Des e-mails marketing seront envoyés qui n'auraient pas dû l'être. L'équipe CRM blâmera l'équipe data, l'équipe data blâmera l'équipe d'ingénierie prod. L'une des leçons les plus importantes que j'ai apprises, mais avec laquelle j'ai encore du mal au quotidien : la capacité d'entrer dans une pièce tendue/Zoom et de rappeler à tout le monde que nous sommes tous dans la même équipe est un super pouvoir. C'est le vrai résumé de la façon de mettre les systèmes de données en production.

Si vous pouvez créer une culture où :

• Les ingénieurs de production créent un épuisement des données avec intention et enthousiasme pour la façon dont les données seront utilisées
• Les membres de l'équipe de données recherchent des cas d'utilisation, demandent des commentaires et demandent à leurs parties prenantes : "Hé, que faites-vous réellement des données que je vous envoie ?"
• Les SWE peuvent encadrer et mettre à niveau les meilleures pratiques et normes de l'équipe de données pour élever les flux de données ad hoc au niveau de la production
• Les membres de l'équipe de données peuvent encadrer et mettre à niveau les parties prenantes de l'entreprise sur la façon d'ajouter une logique métier, des cadres pour l'endroit où la logique appartient
• Chaque équipe invite les autres dans ses bases de code et encourage une perspective à long terme sur l'architecture globale de l'entreprise

Ian Macomber est responsable de la science des données et de l'ingénierie analytique chez Ramp, la première et la seule carte d'entreprise qui aide les entreprises à dépenser moins. Auparavant, il était vice-président de l'analyse et de l'ingénierie des données chez Drizly.

Il y a aussi une quatrième tendance ! Restez à l'écoute pour Data Systems Tend Towards Calculation , qui était un peu trop pour tenir dans un seul article.