Construire et gérer vous-même l’infrastructure vous donne plus de contrôle, mais l’effort pour tout garder sous contrôle peut détourner des ressources de l’innovation dans d’autres domaines. Matt Doka, CTO de FiveStars, une plateforme de marketing pour les petites entreprises, n’aime pas ce compromis et fait tout son possible pour externaliser tout ce qu’il peut.
Cela se voit dans sa réticence à gérer ses propres serveurs, mais c’est peut-être plus évident dans son attitude envers l’ingénierie des données, où il approche de la fin d’un voyage de cinq ans pour automatiser ou externaliser une grande partie des travaux de maintenance banals et concentrer les ressources internes sur l’analyse des données. .
FiveStars propose aux petites entreprises un service de carte de fidélité en ligne – l’équivalent numérique des cartes de fidélité « achetez-en neuf, obtenez-en une gratuite » – qu’elles peuvent associer aux numéros de téléphone et aux cartes de paiement de leurs clients. Plus de 10 000 petites entreprises utilisent ses services et Doka estime qu’environ 70 millions d’Américains ont opté pour les programmes de fidélité qu’elle gère. Plus récemment, il s’est lancé dans le traitement des paiements, une option adoptée par environ 20% de ses clients, et propose ses propres terminaux de paiement conformes PCI.
L’enregistrement de toutes ces interactions génère une quantité prodigieuse de données, mais ce n’est pas la moitié. Pour renforcer les processeurs de paiement hérités qui déposent simplement un terminal et laissent les clients appeler l’assistance s’il cesse de fonctionner, FiveStars intègre des systèmes de télémétrie dans ses terminaux, qui signalent régulièrement leur état de connexion, le niveau de la batterie et les informations sur les performances des applications.
« Le gros de notre charge n’est même pas les transactions, les points ou les cartes de crédit elles-mêmes », dit-il. « Ce sont les énormes quantités de données de télémétrie de l’appareil pour s’assurer que lorsque quelqu’un veut effectuer un paiement ou gagner des points, c’est la meilleure expérience de sa catégorie. »
Comprendre cela à partir des données demande beaucoup d’analyses – un travail pour lequel l’équipe de données de 10 personnes avait moins de temps, car la simple maintenance de leur infrastructure de données engloutissait tout.
L’équipe de données qui a construit la première version de l’infrastructure de données de FiveStars a commencé du côté des ventes et du marketing de l’entreprise, pas de l’informatique. Cet accident historique signifiait que même s’ils connaissaient vraiment bien les données, ils avaient peu d’expérience en gestion d’infrastructure, explique Doka.
Lorsque Doka a repris l’équipe, il a découvert qu’ils avaient tout écrit à la main : le code d’automatisation du serveur, les requêtes de base de données, les analyses — tout. « Ils ont écrit des scripts bash ! » dit Doka. « Même il y a 10 ans, vous disposiez de systèmes capables d’abstraire les scripts bash. »
Le système était fragile, très manuel et basé sur de nombreuses connaissances tribales. L’effet net était que les analystes de données passaient la plupart de leur temps à faire fonctionner le système. « Ils ont eu du mal à obtenir de nouvelles informations sur les données développées dans des analyses », dit-il.
En 2019, ajoute-t-il, la réponse de chacun à un problème comme celui-là était d’utiliser Apache Airflow, une plate-forme open source pour gérer les workflows d’ingénierie de données écrits et contrôlés avec Python. Il a été développé à l’origine chez AirBnB pour effectuer exactement le genre de choses que l’équipe de Doka faisait encore à la main.
Doka a opté pour une version hébergée d’Airflow pour remplacer le système homebrew gourmand en ressources de FiveStars. « Je voulais nous sortir de l’activité d’hébergement de notre propre infrastructure car ce sont des analystes de données ou même des ingénieurs de données, pas des SRE expérimentés », dit-il. « Ce n’est pas une bonne utilisation de notre temps non plus. »
L’adoption d’Airflow signifiait que Doka ne pouvait plus se soucier d’autres choses que les serveurs. « Il y a eu une énorme amélioration dans la normalisation et les bases de la gestion des choses », dit-il. « Vous venez d’hériter de toutes ces meilleures pratiques que nous inventions ou réinventions nous-mêmes. »
Mais, déplore-t-il, « la façon dont vous travaillez réellement dans Airflow dépend entièrement de l’équipe de développement, vous passez donc encore beaucoup de cycles d’esprit à structurer chaque nouveau projet. » Et un de ses reproches particuliers était que vous deviez créer vos propres meilleures pratiques en matière de documentation.
Ainsi, à peine un an après le début de la migration vers Airflow, Doka s’est retrouvé à la recherche de quelque chose de mieux pour l’aider à automatiser davantage ses processus d’ingénierie de données et à normaliser certaines des décisions les moins critiques pour l’entreprise qui prenaient tant de temps.
Il a élargi son réseau, mais bon nombre des outils qu’il a trouvés n’ont résolu qu’une partie du problème.
« DBT s’est concentré sur la façon de modifier les données dans une seule instance Snowflake, par exemple », dit-il. « Cela fait du très bon travail, mais comment obtenez-vous des données dans Snowflake à partir de toutes vos sources? » Pour cela, ajoute-t-il, « il y avait des plates-formes qui pouvaient résumer tous les mouvements de données de manière standardisée, comme Fivetran, mais elles ne vous donnaient pas vraiment un langage à traiter ».
Après avoir vérifié plusieurs autres options, Doka a finalement opté pour Ascend.io. « J’ai adoré le fait qu’il existe un moyen standard d’écrire une requête SQL ou du code Python, et qu’il génère une lignée et une topologie », dit-il. « Le système peut savoir automatiquement d’où proviennent toutes les données ; comment il a fait son chemin jusqu’à cette analyse finale.
Cela élimine non seulement le défi de faire fonctionner des serveurs, mais aussi de décider comment vous travaillez, dit-il.
« Cela permet d’économiser une tonne de charge mentale pour les ingénieurs de données et les analystes de données », dit-il. « Ils peuvent se concentrer entièrement sur la question à laquelle ils essaient de répondre et sur l’analyse qu’ils essaient de faire. »
Non seulement il est plus facile pour les analystes de se concentrer sur leur propre travail, mais il leur est également plus facile de se suivre les uns les autres, ajoute-t-il.
« Il y a toute cette documentation qui a été intégrée par conception où, sans y penser, chaque analyste a laissé une trace claire de miettes sur la façon dont il est arrivé là où il se trouve », dit-il. « Donc, si de nouvelles personnes rejoignent le projet, il est plus facile de voir ce qui se passe. »
Ascend utilise un autre projet Apache, Étincelleen tant que moteur d’analyse, et il possède sa propre API Python, PySpark.
La migration des premiers cas d’utilisation principaux depuis Airflow a pris moins d’un mois. « Il a fallu une heure pour s’allumer et deux minutes pour connecter Postgres et certaines de nos sources de données », explique Doka. « C’était très rapide. »
Répliquer certains des flux de travail était aussi simple que de copier le SQL sous-jacent d’Airflow vers Ascend. « Une fois que nous l’avons fait fonctionner à parité, nous tournions simplement le [old] couler et mettre le [new] connecteur de sortie là où il fallait aller », dit-il.
La chose la plus utile à propos d’Ascend était qu’il exécutait les changements de code si rapidement afin que l’équipe puisse développer et réparer les choses en temps réel. « Le système peut savoir où les éléments du flux de travail ont changé ou non, et il ne réexécute pas tout si rien n’a changé, vous ne gaspillez donc pas de calcul », dit-il. « C’était une très belle accélération. »
Cependant, certaines choses impliquaient toujours une attente d’une nuit. « Il existe un service en amont que vous ne pouvez télécharger qu’entre 2h du matin et 5h du matin, donc obtenir ce code juste, pour s’assurer qu’il était téléchargé au bon moment de la journée, était pénible mais ce n’était pas nécessairement la faute d’Ascend », il dit.
Mobiliser un changement de culture
Le passage à Ascend n’a pas non plus entraîné de besoins majeurs de recyclage ou d’embauche. « La construction est pratiquement nulle maintenant que nous avons tout résumé », déclare Doka, et il y a maintenant trois personnes qui exécutent des tâches sur les nouveaux systèmes, et environ six analystes qui font des rapports et génèrent des informations à partir des données.
« La plupart des travaux d’infrastructure ont disparu », ajoute-t-il. « Il y a encore du travail ETL, la transformation et le nettoyage qui ne disparaissent jamais, mais maintenant c’est fait de manière standardisée. Une chose qui a pris du temps à digérer, cependant, était ce passage de ce que j’appelle la vanille Python utilisé avec Airflow à Spark Python. C’est différent de la simple écriture d’un code procédural. Ce n’est pas une connaissance ésotérique, juste quelque chose que l’équipe FiveStars n’avait pas utilisée auparavant et avec laquelle elle devait se familiariser.
Un thème récurrent dans le parcours d’ingénierie des données de Doka a été la recherche de nouvelles choses qu’il peut arrêter de construire et acheter à la place.
«Lorsque vous construisez, possédez et gérez une infrastructure en interne, vous disposez d’un niveau de contrôle et de connaissances supérieur», déclare-t-il. « Mais souvent, vous sacrifiez une tonne de temps pour cela et, dans de nombreux cas, vous n’avez pas la meilleure expertise pour le développer. »
Convaincre ses collègues des avantages d’en faire moins n’a pas été facile. « J’ai eu du mal avec l’équipe aux deux époques », dit-il. « Cela fait toujours partie d’une transition vers un système plus abstrait. »
Doka dit qu’il a travaillé avec plusieurs startups en tant qu’investisseur ou conseiller, et dit toujours aux fondateurs à l’esprit technique d’éviter de gérer eux-mêmes l’infrastructure et de choisir un fournisseur de premier ordre pour héberger les choses pour eux – et pas seulement parce que cela leur fait gagner du temps. « Vous allez également apprendre les meilleures pratiques en travaillant beaucoup mieux avec eux », dit-il. Il offre aux responsables informatiques des entreprises les mêmes conseils lorsqu’ils traitent avec des équipes internes. « La chose la plus constante que j’ai vue au cours de mes 11 années en tant que CTO est que la gravité pousse simplement les gens à » le construire ici « pour une raison quelconque », dit-il. « Je ne l’ai jamais compris. » C’est quelque chose auquel il faut continuellement résister ou qui finit par perdre du temps à entretenir des choses qui ne font pas partie de l’activité principale.
janvier 17, 2023
Comment FiveStars a repensé sa pile d’ingénierie de données
Construire et gérer vous-même l’infrastructure vous donne plus de contrôle, mais l’effort pour tout garder sous contrôle peut détourner des ressources de l’innovation dans d’autres domaines. Matt Doka, CTO de FiveStars, une plateforme de marketing pour les petites entreprises, n’aime pas ce compromis et fait tout son possible pour externaliser tout ce qu’il peut.
Cela se voit dans sa réticence à gérer ses propres serveurs, mais c’est peut-être plus évident dans son attitude envers l’ingénierie des données, où il approche de la fin d’un voyage de cinq ans pour automatiser ou externaliser une grande partie des travaux de maintenance banals et concentrer les ressources internes sur l’analyse des données. .
FiveStars propose aux petites entreprises un service de carte de fidélité en ligne – l’équivalent numérique des cartes de fidélité « achetez-en neuf, obtenez-en une gratuite » – qu’elles peuvent associer aux numéros de téléphone et aux cartes de paiement de leurs clients. Plus de 10 000 petites entreprises utilisent ses services et Doka estime qu’environ 70 millions d’Américains ont opté pour les programmes de fidélité qu’elle gère. Plus récemment, il s’est lancé dans le traitement des paiements, une option adoptée par environ 20% de ses clients, et propose ses propres terminaux de paiement conformes PCI.
L’enregistrement de toutes ces interactions génère une quantité prodigieuse de données, mais ce n’est pas la moitié. Pour renforcer les processeurs de paiement hérités qui déposent simplement un terminal et laissent les clients appeler l’assistance s’il cesse de fonctionner, FiveStars intègre des systèmes de télémétrie dans ses terminaux, qui signalent régulièrement leur état de connexion, le niveau de la batterie et les informations sur les performances des applications.
« Le gros de notre charge n’est même pas les transactions, les points ou les cartes de crédit elles-mêmes », dit-il. « Ce sont les énormes quantités de données de télémétrie de l’appareil pour s’assurer que lorsque quelqu’un veut effectuer un paiement ou gagner des points, c’est la meilleure expérience de sa catégorie. »
Comprendre cela à partir des données demande beaucoup d’analyses – un travail pour lequel l’équipe de données de 10 personnes avait moins de temps, car la simple maintenance de leur infrastructure de données engloutissait tout.
L’équipe de données qui a construit la première version de l’infrastructure de données de FiveStars a commencé du côté des ventes et du marketing de l’entreprise, pas de l’informatique. Cet accident historique signifiait que même s’ils connaissaient vraiment bien les données, ils avaient peu d’expérience en gestion d’infrastructure, explique Doka.
Lorsque Doka a repris l’équipe, il a découvert qu’ils avaient tout écrit à la main : le code d’automatisation du serveur, les requêtes de base de données, les analyses — tout. « Ils ont écrit des scripts bash ! » dit Doka. « Même il y a 10 ans, vous disposiez de systèmes capables d’abstraire les scripts bash. »
Le système était fragile, très manuel et basé sur de nombreuses connaissances tribales. L’effet net était que les analystes de données passaient la plupart de leur temps à faire fonctionner le système. « Ils ont eu du mal à obtenir de nouvelles informations sur les données développées dans des analyses », dit-il.
En 2019, ajoute-t-il, la réponse de chacun à un problème comme celui-là était d’utiliser Apache Airflow, une plate-forme open source pour gérer les workflows d’ingénierie de données écrits et contrôlés avec Python. Il a été développé à l’origine chez AirBnB pour effectuer exactement le genre de choses que l’équipe de Doka faisait encore à la main.
Doka a opté pour une version hébergée d’Airflow pour remplacer le système homebrew gourmand en ressources de FiveStars. « Je voulais nous sortir de l’activité d’hébergement de notre propre infrastructure car ce sont des analystes de données ou même des ingénieurs de données, pas des SRE expérimentés », dit-il. « Ce n’est pas une bonne utilisation de notre temps non plus. »
L’adoption d’Airflow signifiait que Doka ne pouvait plus se soucier d’autres choses que les serveurs. « Il y a eu une énorme amélioration dans la normalisation et les bases de la gestion des choses », dit-il. « Vous venez d’hériter de toutes ces meilleures pratiques que nous inventions ou réinventions nous-mêmes. »
Mais, déplore-t-il, « la façon dont vous travaillez réellement dans Airflow dépend entièrement de l’équipe de développement, vous passez donc encore beaucoup de cycles d’esprit à structurer chaque nouveau projet. » Et un de ses reproches particuliers était que vous deviez créer vos propres meilleures pratiques en matière de documentation.
Ainsi, à peine un an après le début de la migration vers Airflow, Doka s’est retrouvé à la recherche de quelque chose de mieux pour l’aider à automatiser davantage ses processus d’ingénierie de données et à normaliser certaines des décisions les moins critiques pour l’entreprise qui prenaient tant de temps.
Il a élargi son réseau, mais bon nombre des outils qu’il a trouvés n’ont résolu qu’une partie du problème.
« DBT s’est concentré sur la façon de modifier les données dans une seule instance Snowflake, par exemple », dit-il. « Cela fait du très bon travail, mais comment obtenez-vous des données dans Snowflake à partir de toutes vos sources? » Pour cela, ajoute-t-il, « il y avait des plates-formes qui pouvaient résumer tous les mouvements de données de manière standardisée, comme Fivetran, mais elles ne vous donnaient pas vraiment un langage à traiter ».
Après avoir vérifié plusieurs autres options, Doka a finalement opté pour Ascend.io. « J’ai adoré le fait qu’il existe un moyen standard d’écrire une requête SQL ou du code Python, et qu’il génère une lignée et une topologie », dit-il. « Le système peut savoir automatiquement d’où proviennent toutes les données ; comment il a fait son chemin jusqu’à cette analyse finale.
Cela élimine non seulement le défi de faire fonctionner des serveurs, mais aussi de décider comment vous travaillez, dit-il.
« Cela permet d’économiser une tonne de charge mentale pour les ingénieurs de données et les analystes de données », dit-il. « Ils peuvent se concentrer entièrement sur la question à laquelle ils essaient de répondre et sur l’analyse qu’ils essaient de faire. »
Non seulement il est plus facile pour les analystes de se concentrer sur leur propre travail, mais il leur est également plus facile de se suivre les uns les autres, ajoute-t-il.
« Il y a toute cette documentation qui a été intégrée par conception où, sans y penser, chaque analyste a laissé une trace claire de miettes sur la façon dont il est arrivé là où il se trouve », dit-il. « Donc, si de nouvelles personnes rejoignent le projet, il est plus facile de voir ce qui se passe. »
Ascend utilise un autre projet Apache, Étincelleen tant que moteur d’analyse, et il possède sa propre API Python, PySpark.
La migration des premiers cas d’utilisation principaux depuis Airflow a pris moins d’un mois. « Il a fallu une heure pour s’allumer et deux minutes pour connecter Postgres et certaines de nos sources de données », explique Doka. « C’était très rapide. »
Répliquer certains des flux de travail était aussi simple que de copier le SQL sous-jacent d’Airflow vers Ascend. « Une fois que nous l’avons fait fonctionner à parité, nous tournions simplement le [old] couler et mettre le [new] connecteur de sortie là où il fallait aller », dit-il.
La chose la plus utile à propos d’Ascend était qu’il exécutait les changements de code si rapidement afin que l’équipe puisse développer et réparer les choses en temps réel. « Le système peut savoir où les éléments du flux de travail ont changé ou non, et il ne réexécute pas tout si rien n’a changé, vous ne gaspillez donc pas de calcul », dit-il. « C’était une très belle accélération. »
Cependant, certaines choses impliquaient toujours une attente d’une nuit. « Il existe un service en amont que vous ne pouvez télécharger qu’entre 2h du matin et 5h du matin, donc obtenir ce code juste, pour s’assurer qu’il était téléchargé au bon moment de la journée, était pénible mais ce n’était pas nécessairement la faute d’Ascend », il dit.
Mobiliser un changement de culture
Le passage à Ascend n’a pas non plus entraîné de besoins majeurs de recyclage ou d’embauche. « La construction est pratiquement nulle maintenant que nous avons tout résumé », déclare Doka, et il y a maintenant trois personnes qui exécutent des tâches sur les nouveaux systèmes, et environ six analystes qui font des rapports et génèrent des informations à partir des données.
« La plupart des travaux d’infrastructure ont disparu », ajoute-t-il. « Il y a encore du travail ETL, la transformation et le nettoyage qui ne disparaissent jamais, mais maintenant c’est fait de manière standardisée. Une chose qui a pris du temps à digérer, cependant, était ce passage de ce que j’appelle la vanille Python utilisé avec Airflow à Spark Python. C’est différent de la simple écriture d’un code procédural. Ce n’est pas une connaissance ésotérique, juste quelque chose que l’équipe FiveStars n’avait pas utilisée auparavant et avec laquelle elle devait se familiariser.
Un thème récurrent dans le parcours d’ingénierie des données de Doka a été la recherche de nouvelles choses qu’il peut arrêter de construire et acheter à la place.
«Lorsque vous construisez, possédez et gérez une infrastructure en interne, vous disposez d’un niveau de contrôle et de connaissances supérieur», déclare-t-il. « Mais souvent, vous sacrifiez une tonne de temps pour cela et, dans de nombreux cas, vous n’avez pas la meilleure expertise pour le développer. »
Convaincre ses collègues des avantages d’en faire moins n’a pas été facile. « J’ai eu du mal avec l’équipe aux deux époques », dit-il. « Cela fait toujours partie d’une transition vers un système plus abstrait. »
Doka dit qu’il a travaillé avec plusieurs startups en tant qu’investisseur ou conseiller, et dit toujours aux fondateurs à l’esprit technique d’éviter de gérer eux-mêmes l’infrastructure et de choisir un fournisseur de premier ordre pour héberger les choses pour eux – et pas seulement parce que cela leur fait gagner du temps. « Vous allez également apprendre les meilleures pratiques en travaillant beaucoup mieux avec eux », dit-il. Il offre aux responsables informatiques des entreprises les mêmes conseils lorsqu’ils traitent avec des équipes internes. « La chose la plus constante que j’ai vue au cours de mes 11 années en tant que CTO est que la gravité pousse simplement les gens à » le construire ici « pour une raison quelconque », dit-il. « Je ne l’ai jamais compris. » C’est quelque chose auquel il faut continuellement résister ou qui finit par perdre du temps à entretenir des choses qui ne font pas partie de l’activité principale.
Source link
Partager :
Articles similaires