Au cours des dernières années, j’ai eu de nombreuses conversations avec des amis et des collègues frustrés par la complexité impénétrable de l’écosystème de l’infrastructure de données. Bien que pas aussi mauvais que le monde frontal, les choses changent assez vite pour créer une soupe de mots à la mode.

En tant que débutant, il est très difficile de décider quels outils vous conviennent. La Fondation Apache répertorie 38 projets dans la section « Big Data », et ces outils ont des tonnes de chevauchements sur les problèmes qu’ils prétendent résoudre. Par exemple, Flink, Samza, Storm et Spark Streaming sont des « moteurs de traitement de flux distribués », Apex et Beam « unifient le traitement de flux et de lots ».

Dans cet article, j’espère vous aider à naviguer dans les options que vous avez définies pour créer une infrastructure de données. Ce sont en gros les étapes que je suivrais aujourd’hui, sur la base de mes expériences au cours de la dernière décennie et des conversations avec des collègues travaillant dans cet espace.

Au début de votre projet, vous vous lancez probablement avec rien de plus qu’un objectif: « obtenir des informations à partir de mes données ». Cartographier cela à un ensemble spécifique de technologies est extrêmement intimidant. Vous ne savez probablement pas très bien quels outils sont populaires, ce que signifie « flux » ou « lot », ou si vous avez même besoin d’une infrastructure de données.

Dans cet article, j’espère vous fournir quelques conseils pour vous aider à démarrer rapidement et à extraire de la valeur de vos données. Je crois fermement qu’il faut garder les choses simples le plus longtemps possible, en introduisant la complexité uniquement lorsque cela est nécessaire pour l’évolutivité. Cet article suit cet arc en trois étapes. À bien des égards, il retrace les étapes de la construction d’une infrastructure de données que j’ai suivies au cours des dernières années.

Notez qu’il n’y a pas une seule bonne façon d’architecturer l’infrastructure de données. Pour les experts qui lisent ceci, vous avez peut-être préféré des alternatives aux solutions suggérées ici. C’est fantastique et met en évidence la diversité des outils incroyables dont nous disposons de nos jours. Nous avons parcouru un très long chemin depuis l’époque où Hadoop MapReduce était tout ce que nous avions.

Voici donc la chose: vous n’avez probablement pas encore de « big data ». Presque 4 ans plus tard, l’article de Chris Stucchio de 2013 Don’t use Hadoop est toujours au point. Si vous avez moins de 5 To de données, commencez petit. Cela vous évitera des maux de tête opérationnels liés à la maintenance de systèmes dont vous n’avez pas encore besoin. Mais bon, si vous aimez les exercices d’incendie à 3 heures du matin des échecs d’emploi, n’hésitez pas à sauter cette section

Sinon, restez à l’écart de toutes les technologies à la mode au début et concentrez-vous sur deux choses: (1) rendre vos données interrogeables en SQL et (2) choisir un outil de BI. Ce sera l’épine dorsale « Bonjour, monde » pour l’ensemble de votre future infrastructure de données.

Tout en SQL

C’est vraiment important, car cela déverrouille les données pour l’ensemble de l’organisation. À de rares exceptions près pour les spécialistes du marketing les plus intrépides, vous ne convaincrez jamais vos collègues non techniques d’apprendre Kibana, de grep certains journaux ou d’utiliser la syntaxe obscure de votre banque de données NoSQL.

Fournir un accès SQL permet à toute l’entreprise de devenir des analystes en libre-service, ce qui permet à votre équipe d’ingénierie déjà sollicitée de sortir du chemin critique. Il transforme également tout le monde en une équipe d’assurance qualité gratuite pour vos données. Le « hé, ces chiffres ont l’air un peu bizarres… » est inestimable pour trouver des bugs dans vos données et même dans votre produit.

Si votre banque de données principale est une base de données relationnelle telle que PostgreSQL ou MySQL, c’est vraiment simple. Vous pouvez simplement configurer une réplique en lecture, provisionner l’accès, et tout est prêt.

Avec une base de données NoSQL comme ElasticSearch, MongoDB ou DynamoDB, vous devrez faire plus de travail pour convertir vos données et les placer dans une base de données SQL. Si vous débutez dans le monde des données, nous appelons cela un pipeline ETL. Évitez de construire cela vous-même si possible, car le câblage d’une solution prête à l’emploi sera beaucoup moins coûteux avec de petits volumes de données. Selon votre infrastructure existante, il peut y avoir un segment de type fournisseur ETL cloud que vous pouvez exploiter.

Si vous constatez que vous devez créer vos propres pipelines de données, gardez-les extrêmement simples au début. Écrivez un script pour vider périodiquement les mises à jour de votre base de données et écrivez-les dans un endroit interrogeable avec SQL.

L’histoire de l’ETLing des données provenant de sources tierces est similaire à celle des bases de données NoSQL. Utilisez un fournisseur ETL-as-a-service ou écrivez un script simple et déposez simplement vos données dans une base de données interrogeable SQL.

Configurez une machine pour exécuter vos scripts ETL en tant que cron quotidien, et vous êtes parti pour les courses.

Outil de BI

Un bon outil de BI est une partie importante de la compréhension de vos données. Les données Chartio, Mode Analytics et Periscope sont d’excellents outils à prendre en compte — l’un d’entre eux devrait très bien fonctionner pour faire décoller vos analyses. Dans la plupart des cas, vous pouvez pointer ces outils directement sur votre base de données SQL avec une configuration rapide et plonger directement dans la création de tableaux de bord.

En rassemblant tout cela, voici le « Bonjour, monde » de l’infrastructure de données:

Étape 1: Le petit pipeline de données « Bonjour, monde »

Étape 2: Appelons-le des données « moyennes »

À ce stade, vous avez plus de quelques téraoctets qui flottent, et votre script cron + ETL ne suit pas tout à fait. Peut-être avez-vous proliféré des banques de données et avez un mélange hétérogène de backends SQL et NoSQL. Vous pouvez également compter sur une poignée de tiers auprès desquels vous collectez des données. Enfin, vous commencez peut-être à avoir plusieurs étapes dans vos pipelines ETL avec certaines dépendances entre les étapes.

Gestion du flux de travail & Automatisation

Votre première étape dans cette phase devrait être la configuration de Flux d’air pour gérer vos pipelines ETL. Airflow vous permettra de planifier des tâches à intervalles réguliers et d’exprimer des dépendances temporelles et logiques entre les tâches. C’est également un excellent endroit dans votre infrastructure pour ajouter des tentatives de travail, en surveillant les alertes & en cas d’échec des tâches. C’est une blague courante que chaque démarrage au-dessus d’une certaine taille écrit son propre gestionnaire de flux de travail / planificateur de tâches. Entre autres, Spotify a écrit Luigi et Pinterest a écrit Pinball. Cependant, ceux-ci ont moins d’élan dans la communauté et manquent de certaines caractéristiques en ce qui concerne le flux d’air.

Construction de pipelines ETL

Au fur et à mesure de la croissance de votre entreprise, vos exigences en matière de pipelines ETL changeront considérablement. Vous devrez commencer à construire une infrastructure plus évolutive car un seul script ne la coupera plus. Vos objectifs sont également susceptibles de passer de la simple activation de l’accès SQL à la prise en charge d’autres tâches en aval qui traitent les mêmes données.

finalement, les pipelines simples ne mettront pas à l’échelle

Pour répondre à ces exigences changeantes, vous voudrez convertir vos scripts ETL pour qu’ils s’exécutent en tant que tâche distribuée sur un cluster. Le nombre de solutions possibles ici est absolument écrasant. Je recommande fortement de commencer par Apache Spark. Spark a une communauté énorme et très active, évolue bien et est assez facile à démarrer rapidement. Sur AWS, vous pouvez exécuter Spark à l’aide d’EMR ; pour GCP, à l’aide de Cloud Dataproc. Si vous ingérez des données à partir d’une base de données relationnelle, Apache Sqoop est à peu près la norme.

À ce stade, votre infrastructure ETL commencera à ressembler à des étapes pipelinées de tâches qui implémentent les trois verbes ETL : extraire les données des sources, transformer ces données en formats standardisés sur le stockage persistant et les charger dans une banque de données interrogeable SQL.

Entrepôt de données

À ce stade, l’intégration de toutes vos données dans SQL restera une priorité, mais c’est le moment où vous voudrez commencer à créer un « vrai » entrepôt de données.

Pour ceux qui débutent, je recommande d’utiliser BigQuery. BigQuery est facile à configurer (vous pouvez simplement charger des enregistrements au format JSON), prend en charge les types de données imbriqués / complexes et est entièrement géré / sans serveur, vous n’avez donc pas plus d’infrastructure à gérer. Comme pour beaucoup de recommandations ici, des alternatives à BigQuery sont disponibles : sur AWS, Redshift et sur site, Presto. J’ai une forte préférence pour BigQuery par rapport à Redshift en raison de sa conception sans serveur, de la simplicité de configuration de la sécurité / de l’audit appropriés et de la prise en charge des types complexes. Presto vaut la peine d’être considéré si vous avez une exigence difficile pour le sur site.

Lorsque vous envisagez de configurer votre entrepôt de données, un modèle pratique consiste à adopter un modèle en 2 étapes, dans lequel les données non traitées sont directement stockées dans un ensemble de tables, et un deuxième poste traite ces données en tables « plus propres ».

Traitez ces tableaux plus propres comme une opportunité de créer une vue organisée de votre entreprise. Pour chacune des entités clés de votre entreprise, vous devez créer et organiser une table avec toutes les métriques/indicateurs de performance clés et les dimensions que vous utilisez fréquemment pour analyser cette entité. Par exemple, une table  » utilisateurs  » peut contenir des mesures telles que l’heure d’inscription, le nombre d’achats et des dimensions telles que l’emplacement géographique ou le canal d’acquisition.

À la fin de tout cela, votre infrastructure devrait ressembler à ceci:

Étape 2 : le pipeline de données  » moyen « 

🚀 Étape 3: Devenir grand

Avec les bonnes fondations, la croissance ultérieure n’a pas besoin d’être douloureuse. Vous pouvez souvent vous débrouiller simplement en jetant du matériel sur le problème de la gestion de volumes de données accrus.

Les problèmes les plus difficiles de cette période ne sont souvent pas seulement une échelle brute, mais des exigences en expansion. Par exemple, vous avez peut-être besoin de prendre en charge les tests A/B, de former des modèles d’apprentissage automatique ou de transformer des données en un cluster ElasticSearch.

Certaines choses que vous voudrez peut-être considérer dans cette phase:

  • Temps Quasi Réel: Vous n’aurez probablement pas besoin d’une file d’attente distribuée ou d’une infrastructure en temps quasi réel avant beaucoup plus tard que vous ne le pensez. Il est livré avec beaucoup de complexité supplémentaire pour gérer tous les modes d’échec possibles, ce qui n’en vaut pas la peine dès le début. Une fois que le calcul du ROI a du sens, essayez Kafka ou Cloud Pub/ Sub.
  • Évolutivité : Avec un seul cluster Spark monolithique, vous rencontrerez presque certainement des problèmes de conflit de ressources. Lorsque vous le faites, les clusters Spark entièrement élastiques à portée de travail méritent d’être explorés.
  • Sécurité & Audit: À un moment donné, vous souhaiterez peut-être appliquer des contrôles d’accès plus granulaires aux données de votre entrepôt de données. Si vous utilisez BigQuery, vous pouvez provisionner l’accès à l’ensemble de données à Google Groups et gérer cet accès par programme à l’aide de Deployment Manager. BigQuery fournit également des journaux d’audit pour comprendre les requêtes des utilisateurs. D’autres outils comme Apache Knox et Apache Sentry sont disponibles pour les solutions de sécurité sur site.
  • Tests A / B: Pour construire des tests A / B internes et soutenir l’expérimentation, il n’existe malheureusement pas beaucoup de solutions prêtes à l’emploi. La création d’un pipeline de tâches Spark qui remplissent des tables dans votre entrepôt de données est probablement votre meilleur choix.
  • Apprentissage automatique : Pour l’extraction de fonctionnalités, vous pouvez créer des pipelines de données supplémentaires dans Spark. Pour les modèles eux-mêmes, vous devriez à nouveau commencer petit. Vos fonctionnalités traitées sont probablement suffisamment petites pour tenir sur une seule machine, vous pouvez donc entraîner des modèles à l’aide de scikit-learn ou de TensorFlow. Lorsqu’une seule machine ne suffit plus, vous pouvez utiliser Spark MLlib ou distributed TensorFlow.

L’avenir

Il est passionnant de voir à quel point l’écosystème de l’infrastructure de données s’est amélioré au cours de la dernière décennie. Nous avons parcouru un long chemin depuis le babysitting des clusters Hadoop et la gymnastique pour contraindre notre logique de traitement des données à des cartes et réduire en Java gênant. À l’époque, construire une infrastructure de données ressemblait à essayer de construire un gratte-ciel à l’aide d’un marteau jouet.

Aujourd’hui, nous disposons d’une incroyable diversité d’outils. Spark a clairement dominé en tant que remplaçant polyvalent de Hadoop MapReduce; la même chose commence à se produire avec TensorFlow en tant que plate-forme d’apprentissage automatique. À de très rares exceptions près, vous n’avez pas besoin de créer une infrastructure ou des outils à partir de zéro en interne de nos jours, et vous n’avez probablement pas besoin de gérer des serveurs physiques. Le gratte-ciel est déjà là, il vous suffit de choisir vos couleurs de peinture.

l’avenir sans serveur – ce sera totalement comme ça

À l’avenir, je m’attends à ce que l’infrastructure et les outils de données continuent à évoluer vers des plates—formes entièrement sans serveur – DataBricks vient d’annoncer une telle offre pour Spark. L’infrastructure sans serveur permet une séparation élégante des préoccupations : les fournisseurs de cloud peuvent s’inquiéter du matériel, du devops et de l’outillage, ce qui permet aux ingénieurs de se concentrer sur les problèmes propres à (et alignés sur) leurs activités. L’avenir en est un sans pannes matérielles, monstres de ZooKeeper ou problèmes de conflit de ressources YARN, et c’est vraiment cool.

Edit: ajout de liens vers certains articles précédents que j’ai écrits sur l’infrastructure de données de Thumbtack:

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

lg