Votre équipe a-t-elle besoin d'un Data Engineer?

Nous trouvons souvent des articles sympas en anglais qui semblent utiles à notre équipe, et avons décidé qu'il serait formidable de partager leur traduction avec les lecteurs de Habra. Aujourd'hui, nous avons préparé la traduction d'un article de Tristan Handy, fondateur de Fishtown Analytics.

Le rôle d'un ingénieur de données dans les startups modernes évolue rapidement. Êtes-vous sûr de bien comprendre quand et pourquoi votre équipe pourrait avoir besoin d'un tel spécialiste?

Je communique souvent avec les principaux représentants du monde de l'analytique et je remarque que leur compréhension du rôle d'un ingénieur de données dans une équipe n'est pas vraie. Cela peut créer des difficultés pour toute l'équipe d'analyse des données, et j'aimerais que les entreprises apprennent comment éviter de tels problèmes.

Dans cet article, je veux partager mes idées sur quand, comment et pourquoi il vaut la peine d'embaucher un ingénieur de données. Mon raisonnement est basé sur mon expérience chez Fishtown Analytics , où j'ai travaillé avec plus d'une centaine de startups avec un soutien en capital-risque et les ai aidées à constituer des équipes d'analyse et de traitement des données, ainsi que les connaissances acquises grâce à la communication avec les représentants de diverses sociétés de traitement de données.

Si vous dirigez une équipe d'experts en données, ce message est pour vous.

Le rôle d'un ingénieur de données change

Un logiciel moderne permet d'automatiser des travaux plus ennuyeux liés à l'analyse et au traitement des données.

En 2012, au moins un ingénieur de données a été requis pour analyser l'ensemble de données dans une startup financée par une entreprise. Un tel spécialiste a dû extraire des données de différents systèmes afin que les analystes et les entreprises puissent continuer à travailler avec eux. Il était souvent nécessaire de transformer les données d'une manière ou d'une autre afin qu'elles soient plus faciles à analyser. Sans un ingénieur des données, les spécialistes de l'analyse et du traitement des données n'auraient tout simplement pas les données avec lesquelles ils pourraient travailler, si souvent c'est avec l'ingénieur des données que l'équipe a commencé à se former.

D'ici 2019, la plupart de cela peut être fait avec des solutions toutes faites. Dans la plupart des cas, vous et une équipe d'analystes pouvez créer vous-même un pipeline de traitement des données, sans l'aide d'une personne ayant une vaste expérience en science des données. Et ce pipeline ne sera pas mauvais du tout - des outils prêts à l'emploi modernes sont parfaits pour résoudre de tels problèmes.

Les analystes et les scientifiques des données ont récemment eu l'occasion de construire eux-mêmes des pipelines - il y a seulement 2-3 ans. Cela est dû principalement à trois produits: Stitch , Fivetran et dbt (il vaut la peine de dire que dbt est un produit de ma société, Fishtown Analytics). Ils ont été publiés presque immédiatement après Amazon Redshift, lorsque les équipes de démarrage ont réalisé qu'elles devaient créer des entrepôts de données. Il a fallu plusieurs années pour fabriquer ces produits de haute qualité - en 2016, nous étions encore des pionniers.

Désormais, un pipeline construit avec Stitch, Fivetran ou dbt est beaucoup plus fiable que ce qui est spécialement conçu avec Airflow. Je ne le sais pas par la théorie, mais par ma propre expérience. Je ne dis pas qu'il est impossible de construire une infrastructure fiable avec Airflow, la plupart des startups ne le font tout simplement pas. Dans Fishtown Analytics, nous avons travaillé avec plus d'une centaine d'équipes d'analyse dans différentes startups, et ce scénario a été répété plusieurs fois. Nous aidons constamment les gens à passer de leurs propres pipelines à des solutions clés en main, et chaque fois que l'effet est positif.

L'ingénieur de données ne doit pas écrire ETL

En 2016, Jeff Magnusson a écrit un article fondamental, Data Engineers Should Not Write ETL . Ce fut le premier message de ma mémoire qui appelait à un tel changement. Voici ma partie préférée à partir de là:

* «Au cours des 5 dernières années, les outils et technologies de traitement des données ont évolué. La plupart des technologies ont déjà tellement évolué qu'elles peuvent s'adapter à vos besoins, à moins, bien sûr, que vous n'ayez besoin de traiter des pétaoctets de données ou des milliards d'événements par jour.

Si vous n'avez pas besoin d'aller au-delà des capacités de ces technologies, vous n'avez probablement pas besoin d'une équipe de programmeurs hautement spécialisés pour développer des solutions supplémentaires.

Si vous parvenez à les embaucher, ils s'ennuieront bientôt. S'ils s'ennuient, ils vous laisseront sur Google, Facebook, LinkedIn, Twitter - les endroits où leur expérience est vraiment nécessaire. S'ils ne s'ennuient pas, ils sont probablement plutôt médiocres. Et les programmeurs médiocres ont vraiment réussi à créer une quantité énorme de bêtises compliquées et inadaptées au travail normal, qu'ils appellent des «solutions». »*

J'aime vraiment cette citation car elle souligne non seulement qu'aujourd'hui vous n'avez pas besoin d'ingénieurs de données pour résoudre la plupart des problèmes ETL, mais explique également pourquoi il vaut mieux ne pas leur demander de résoudre ces problèmes du tout .

Si vous embauchez des ingénieurs de données et leur demandez de construire un pipeline, ils penseront que leur tâche est de construire un pipeline. Cela signifie que des outils comme Stitch, Fivetran et dbt seront une menace pour eux, pas une puissante source de force. Ils trouveront les raisons pour lesquelles les pipelines finis ne répondent pas à vos besoins de données individuels et pourquoi les analystes ne devraient pas s'engager indépendamment dans la conversion de données. Ils écriront du code qui sera fragile, difficile à maintenir et inefficace. Et vous vous ferez à ce code car il sous-tend tout ce que fait votre équipe.

Fuyez des spécialistes comme la peste. Le taux de croissance de votre équipe d'analystes chutera fortement et vous passerez tout votre temps à résoudre les problèmes d'infrastructure, et ce n'est pas du tout ce qui apporte des revenus à votre entreprise.

Sinon ETL, alors quoi?

Votre équipe a-t-elle vraiment besoin d'un ingénieur de données? Oui

Même avec de nouveaux outils qui permettent aux analystes de données et aux experts en science des données de créer eux-mêmes des pipelines, les ingénieurs de données restent une partie importante de toute équipe de données professionnelle. Cependant, les tâches sur lesquelles ils doivent travailler ont changé et la séquence dans laquelle il vaut la peine d'embaucher des employés pour travailler avec des données. Ci-dessous, je parlerai du moment de le faire, et maintenant, parlons des responsabilités des ingénieurs de données dans les startups modernes.

Les ingénieurs de données sont toujours une partie importante de toute équipe de données professionnelle.

Vos ingénieurs de données ne doivent pas créer de pipelines pour lesquels il existe déjà des solutions prêtes à l'emploi et écrire des transformations de données SQL. Voici sur quoi ils devraient se concentrer:

• organisation et optimisation de l'infrastructure de données sous-jacente,
• la construction et le support de pipelines personnalisés,
• l'accompagnement d'une équipe de spécialistes des données en améliorant la conception et les performances des pipelines et des requêtes,
• construction de transformations de données non SQL.

Organisation et optimisation de l'infrastructure de données sous-jacente

Bien que les ingénieurs de données des startups n'aient plus besoin de gérer les clusters Hadoop ou de configurer l'équipement pour Vertica, des travaux sont encore nécessaires dans ce domaine. Après vous être assuré que votre technologie de collecte, de transmission et de traitement des données est à son apogée, vous obtenez une amélioration significative des performances, des coûts ou des deux. Cela implique généralement les tâches suivantes:

• création d'une infrastructure de surveillance pour suivre l'état des pipelines,
• surveillance de toutes les tâches affectant les performances du cluster,
• entretien régulier
• optimisation des schémas de table (partitionnement, compression, distribution) pour minimiser les coûts et augmenter la productivité,
• développement d'une infrastructure de données personnalisée lorsqu'il n'y a pas de solutions toutes faites.

Ces tâches sont souvent négligées dans les premiers stades de développement, mais elles deviennent essentielles à mesure que l'équipe grandit et la quantité de données. Dans un projet, nous avons pu réduire progressivement le coût de construction d'une table dans BigQuery de 500 $ à 1 $ par jour en optimisant les partitions de table. C'est vraiment important.

Uber est un bon exemple d'une entreprise qui a réussi. Les spécialistes du traitement des données chez Uber ont créé un outil appelé Queryparser qui suit automatiquement toutes les demandes à leur infrastructure de données et recueille des statistiques sur les ressources utilisées et les modèles d'utilisation. Les ingénieurs Uber Data peuvent utiliser des métadonnées pour personnaliser l'infrastructure.

Les ingénieurs de données sont également souvent responsables de la création et de la maintenance du pipeline CI / CD qui gère l'infrastructure de données. En 2012, de nombreuses entreprises avaient une infrastructure très faible pour le contrôle de version, la gestion et les tests, mais maintenant tout change, et c'est ce que les ingénieurs de données sont derrière.

Enfin, les ingénieurs de données des grandes entreprises participent souvent à la création d'outils qui n'existent pas prêts à l'emploi. Par exemple, les ingénieurs d'Airbnb ont créé Airflow car ils n'avaient aucun moyen de générer efficacement des digraphes de traitement des données . Et les ingénieurs de Netflix sont chargés de créer et de maintenir une infrastructure sophistiquée pour développer et exploiter des dizaines de milliers de portables Jupyter .

Vous pouvez simplement acheter la plupart de votre infrastructure de base, mais quelqu'un doit toujours la réparer. Et si vous êtes une entreprise vraiment progressiste, vous souhaiterez probablement étendre les capacités des outils existants. Les ingénieurs de données peuvent vous aider avec les deux.

Construction et maintenance de pipelines personnalisés

Bien que les ingénieurs de données n'aient plus besoin de transférer manuellement les données vers Postgres ou Salesforce, les fournisseurs n'ont «que» environ 100 options d'intégration. La plupart de nos clients peuvent atteindre immédiatement 75 à 90% des sources de données avec lesquelles ils travaillent.

En pratique, l'intégration se fait par vagues. En règle générale, la première étape comprend la base de données principale des applications et le suivi des événements, et la deuxième étape comprend les systèmes de marketing tels que l'ESP et les plateformes publicitaires. Aujourd'hui, des solutions clé en main pour les deux phases sont déjà disponibles à la vente. Lorsque vous approfondirez votre travail avec les données des fournisseurs SaaS dans votre domaine, vous aurez besoin d'ingénieurs de données pour créer et maintenir ces pipelines de traitement de données de niche.

Par exemple, les entreprises engagées dans la vente via Internet interagissent avec une multitude de produits différents dans le domaine de l'ERP, de la logistique et de la livraison. Beaucoup de ces produits sont très spécifiques et presque aucun d'entre eux n'est disponible dans le commerce. Attendez-vous à ce que vos ingénieurs de données créent des produits similaires dans un avenir prévisible.

Construire et maintenir des pipelines de traitement de données fiables est une tâche difficile. Si vous décidez d'investir vos ressources dans leur création, préparez-vous à ce que cela nécessite plus de fonds que prévu initialement dans le budget, et l'entretien nécessitera également plus d'efforts que prévu. La première version du pipeline peut être construite simplement, mais il est difficile de lui faire maintenir la cohérence des données dans votre stockage. Ne vous engagez pas à maintenir votre propre pipeline de traitement des données tant que vous n'êtes pas sûr que votre entreprise fonctionne. Une fois que vous l'avez fait, prenez le temps de le rendre fiable. Pensez à utiliser Singer, le framework open-source des créateurs de Stitch, nous avons construit une vingtaine d'intégrations en l'utilisant.

Prise en charge d'une équipe de spécialistes des données en améliorant la conception et les performances des pipelines et des requêtes

L'un des changements que nous avons vus dans le domaine de l'ingénierie des données au cours des cinq dernières années est l'émergence d'ELT - une nouvelle version d'ETL, qui convertit les données après leur chargement dans le stockage, et pas avant. L'essence et les causes d'un tel changement sont déjà bien couvertes dans d'autres sources. Je tiens à souligner que ce changement a un impact énorme sur qui construit ces pipelines.

Si vous écrivez du code sur Scalding pour analyser des téraoctets de données d'événement dans S3, puis les téléchargez sur Vertica, vous aurez probablement besoin d'un ingénieur de données. Mais si vos données d'événement (exportées de Google Analytics 360) sont déjà dans BigQuery, elles sont déjà entièrement disponibles dans un environnement évolutif hautes performances. La différence est que cet environnement parle SQL. Cela signifie que les analystes peuvent désormais créer leurs propres pipelines de transformation de données.

Cette tendance s'est développée en 2014 lorsque Looker a publié l'outil PDT . La tendance s'est intensifiée lorsque des équipes entières d'experts en données ont commencé à construire des digraphes de traitement de données à partir de plus de 500 nœuds et à traiter de grands ensembles de données à l'aide de dbt au cours des deux dernières années. À ce stade, le modèle est profondément enraciné dans les équipes modernes et a donné aux analystes autant d'indépendance que jamais.

Le passage à ELT signifie que les ingénieurs de données n'ont plus besoin d'effectuer la plupart des tâches de conversion de données . Cela signifie également que les équipes sans ingénieurs peuvent aller loin en utilisant des outils de transformation de données conçus pour les analystes. Cependant, les ingénieurs de données jouent toujours un rôle important dans la création de pipelines de conversion de données. Il y a deux situations où leur participation est extrêmement importante:

1. Lorsque vous devez augmenter votre productivité

Parfois, la logique d'un processus métier nécessite une transformation particulièrement complexe, et il est utile d'impliquer un ingénieur de données pour évaluer comment une approche particulière de la création d'une table affecte les performances. De nombreux analystes n'ont pas beaucoup d'expérience dans l'optimisation des performances dans les entrepôts de données analytiques, et c'est une excellente raison de commencer à travailler avec un spécialiste plus étroit.

2. Quand le code devient trop compliqué

Les analystes savent très bien résoudre les problèmes commerciaux à l'aide de données, mais ne réfléchissent souvent pas à la façon d'écrire du code extensible. À première vue, il est facile de commencer à créer des tables dans la base de données, mais tout peut rapidement devenir incontrôlable. Engagez un ingénieur de données qui peut réfléchir à l'architecture générale de votre stockage et développer des transformations particulièrement complexes, sinon vous risquez d'être laissé seul avec un enchevêtrement qui sera presque impossible à démêler.

Création de transformations de données non SQL

SQL peut initialement satisfaire la plupart des besoins de conversion de données, mais il ne peut pas résoudre tous les problèmes. Par exemple, il est souvent nécessaire d'ajouter des géodonnées à la base de données en prenant la latitude et la longitude et en les reliant à une région spécifique. De nombreux référentiels analytiques modernes ne peuvent pas encore résoudre un tel problème (bien que cela commence à changer! ), La meilleure solution serait donc de construire une ligne de départ en Python, qui complétera les données de votre référentiel avec des informations sur la région.

Un autre cas d'utilisation évident pour Python (ou d'autres langages autres que SQL) concerne l'apprentissage automatique. Si vous avez des recommandations de produits personnalisées, un modèle de prévision de la demande ou un algorithme de prévision des sorties qui prend les données de votre stockage et organise les pondérations, vous pouvez les ajouter en tant que nœuds d'extrémité de votre digraphe de traitement des données SQL.

La plupart des entreprises modernes qui résolvent de tels problèmes en utilisant non-SQL utilisent Airflow. dbt est utilisé pour la partie SQL du digraphe de données et les nœuds non SQL sont ajoutés en tant que feuilles. Cette approche prend le meilleur des deux approches - les analystes de données peuvent toujours être principalement responsables des conversions basées sur SQL, et les ingénieurs de données peuvent être responsables du code ML à usage industriel.

Quand votre équipe a-t-elle besoin d'un ingénieur de données?

Changer le rôle d'un ingénieur de données implique également de repenser la séquence d'embauche des employés. On pensait auparavant que vous avez principalement besoin d'ingénieurs de données, car les analystes et les spécialistes des sciences des données n'ont rien à travailler sans une plate-forme prête à l'emploi de traitement et d'analyse des données. Aujourd'hui, les spécialistes de l'analyse et du traitement des données peuvent travailler de manière indépendante et créer la première version de l'infrastructure de données à l'aide d'outils prêts à l'emploi. Pensez à embaucher un ingénieur de données lorsque votre startup présente l'un des 4 signes d'échelle:

1. il y a 3 analystes / spécialistes en science des données dans votre équipe,
2. votre plateforme de BI compte 50 utilisateurs actifs,
3. la plus grande table de votre stockage atteint 1 milliard de lignes,
4. Vous savez que vous devez créer au moins trois pipelines de traitement des données personnalisés au cours des prochains trimestres, et ils sont tous essentiels.

Si vous n'avez encore rencontré aucune de ces situations, votre équipe d'experts en données peut probablement travailler seule, en utilisant des technologies toutes faites, le soutien de consultants externes et les conseils de collègues (par exemple, dans les communautés localement optimistes ou dbt à Slack).

La principale chose à comprendre est qu'un ingénieur de données en lui-même n'a aucune valeur pour l'entreprise, son travail principal est d'augmenter la productivité de vos analystes. , KPI – . - , : , -, 33 %, , , .

, data scientist- .

, , – 5 1: / data science -. , , , .

?

- . , :

« , , - . . , - ( ) .
, – -, / data science. -, , , , . -, : “, , , ”».

. - – , , . .

, , :) . , , , , – - .

, - , – , . , , , !

, Skyeng :

Skyeng 30+ - -. , , . Amazon Redshift , Stitch Matillion ETL 40+ -, Segment , Redash Tableau , Amazon SageMaker ML.

— - . , MVP- , , . , , , Tableau .

, , , - . , , : , .

- -, , , , . 90% , . , Skyeng.