Mise en œuvre d’un pipeline de données en continu

Trustly a connu beaucoup de croissance au cours des dernières années et cela a affecté la façon dont nous faisons des données et des analyses. Nos défis ne sont probablement pas uniques et nous ne savons pas encore si les choix que nous avons faits étaient les bons. Seul l’heure nous le dira. Je travaille pour l’entreprise depuis près de six ans et j’ai vu nos ressources de données et d’analyse dédiées passer de zéro à peut-être 40 personnes, selon la façon dont vous nous comptez. Dans un an, ce nombre aura encore augmenté.

Historique

À l’origine, je voulais que cet article de blog soit assez technique et ne se concentre que sur quelques défis d’ingénierie explicites auxquels nous avons été confrontés et sur la façon dont nous les avons résolus. Mais je me suis vite rendu compte que cela n’aurait pas beaucoup de sens si je ne décrivais pas un peu plus le contexte. Une chose que j’ai remarquée en faisant partie d’une plus grande organisation, c’est qu’il devient encore plus important de rester concentré sur les problèmes que vous essayez de résoudre. En tant qu’ingénieur, je me sens mieux quand je peux passer une journée entière à essayer de résoudre un problème technique intéressant (et je ne suis probablement pas le seul). En tant qu’être humain, j’ai tendance à graviter vers faire des choses qui me font me sentir bien (n’est-ce pas nous tous?). Malheureusement, ce qui me fait me sentir bien n’est pas toujours ce qui est le plus précieux pour mon employeur. Dans une petite organisation où tout le monde connaît tout le monde et tous les employés déjeunent ensemble le lundi, ce désalignement devient rapidement évident et peut être résolu, mais plus l’organisation devient grande, plus je peux continuer à résoudre des problèmes qui n’étaient peut-être pas si importants au départ. Il est plus difficile - pour moi comme pour les autres - de falsifier ma conviction que je travaille sur quelque chose de vraiment important. Surtout quand cela ressemble à quelque chose qu’un ingénieur de données devrait faire, comme la construction d’un pipeline de données en streaming.

Jetons d’abord un coup d’œil à l’une de nos plates-formes de données par lots existantes, qui utilise Google Cloud Platform. Nous disposons d’un certain nombre de sources de données, dont la plus importante est notre produit de paiement, mais aussi des systèmes CRM, des systèmes financiers, Jira, etc. Les données sont principalement extraites de ces systèmes à l’aide de travaux écrits en Python et déclenchés par Airflow. Nous ingérons toutes ces données et les mettons dans un format assez brut dans BigQuery, notre lac de données si vous voulez. Les transformations en aval de là sont écrites en SQL et exécutées par dbt. Nous avons commencé il y a quelques années à orchestrer toutes ces transformations SQL avec les opérateurs Airflow, mais nous avons tout déplacé vers dbt il y a environ un an et nous n’avons pas regretté cela depuis une minute. Dbt fonctionne très bien et nous permet de découpler la transformation des données de l’ingestion.

Lorsque vous passez d’une petite à une plus grande organisation, vous devez commencer à penser aux processus de découplage et à la façon de faire évoluer vos équipes. Lorsque toute l’organisation des données ne compte que trois personnes, tout le monde saura un peu de tout - et ce n’est pas grave. Si vous souhaitez mettre cela à l’échelle 10 fois, la meilleure façon de le faire n’est probablement pas d’exiger que chaque nouveau membre de l’équipe connaisse l’architecture Java, Python, SQL et cloud ainsi que d’avoir une compréhension détaillée de ce que les métriques de produits comptent, dans quel système source trouver les données brutes, comment les définir et comment travailler avec les parties prenantes de l’entreprise. Les gens qui savent tout cela (ou peuvent même l’apprendre) sont une ressource rare. Au lieu de cela, permettre aux analystes et aux ingénieurs d’analyse de développer et de maintenir des pipelines dans SQL, sans avoir à se soucier de la façon dont les données brutes entrent dans la plate-forme en premier lieu - un travail qu’il vaut mieux laisser aux ingénieurs de données - est quelque chose que nous avons trouvé nous permet de supprimer les goulots d’étranglement et de répartir les charges de travail sur de nombreuses équipes.

Pourquoi le streaming?

Alors, revenons au streaming - pourquoi avons-nous besoin de cela? La réponse évidente serait que nous avons besoin de données en temps réel et bien que ce soit certainement quelque chose à viser, je ne dirais pas que c’est ce qui compte le plus pour nous en ce moment. Tout le reste étant égal - avoir des données, c’est-à-dire savoir quelque chose, plus tôt est mieux que plus tard. Mais tout le reste n’est pas égal quand il s’agit de lot par rapport au streaming. Je préférerais évaluer nos priorités actuelles comme suit :

1. Capturer le changement
2. Réduire les temps de chargement
3. Diminuer la latence

Ici, je pense à réduire la latence d’un jour à une heure (plutôt que d’une seconde à une milliseconde). Jetons un coup d’œil à chacun d’entre eux à tour de rôle.

Capturer le changement

Dans une large mesure, l’analyse consiste à trouver des modèles sous-jacents qui vous aideront à comprendre le monde. Comprendre le monde qui vous entoure vous aide à prendre des décisions - espérons-le, des décisions qui aideront votre entreprise à se développer. Il y a beaucoup à dire sur la façon (et comment ne pas) transformer les données en informations (ou même mieux - décisions) et je laisse volontiers ces défis à nos analystes et scientifiques des données. Cela dit, je pense qu’il est tout à fait incontestable de dire que le temps est une dimension importante dans de nombreux travaux d’analyse. Temps comme dans: « Hier, nous avons vendu pour 5 SEK, aujourd’hui nous avons vendu pour 10 SEK, combien allons-nous vendre pour demain? » 

Jay Kreps a écrit un article de blog classique avec le titre « The Log: Ce que chaque ingénieur logiciel devrait savoir sur l’abstraction unificatrice des données en temps réel » qui fait un bien meilleur travail que moi expliquant les avantages de capturer le changement au fil du temps dans le format d’un journal des événements. L’essentiel de notre cas d’utilisation est que notre système de paiement stocke généralement des informations sur le monde tel qu’il est maintenant, et seulement dans une mesure limitée à quoi il ressemblait hier. Ou il y a une demi-seconde. Il ne serait pas pratique d’utiliser une base de données OLTP pour persister tous les changements pendant de longues périodes, mais si le système de paiement peut simplement déclencher des événements au fur et à mesure qu’ils se produisent et que quelqu’un les collecte à l’autre extrémité d’un courtier de messages, ils peuvent être utilisés pour « rejouer » et reconstruire l’état du monde à tout moment, vous voudrez peut-être étudier rétrospectivement.

Réduire les temps de chargement

Malheureusement, la base de données de notre produit de paiement n’a pas d’horodatage « dernière modification » pour toutes les tables. Cela signifie qu’il n’y a aucun moyen de dire laquelle des lignes d’un tableau a changé entre hier et aujourd’hui - ou entre une seconde et maintenant. Afin d’avoir des données cohérentes sur la plate-forme de données, nous devons donc exporter des tables entières du système de production tous les soirs. Et comme Trustlyont explosé, tout comme nos exportations de données nocturnes. Vous pourriez faire valoir que la base de données aurait dû être conçue d’une meilleure manière pour commencer, mais lorsque le système a été construit il y a de nombreuses années, l’accent était mis sur l’obtention d’un produit fonctionnel de la porte que nous pourrions vendre, pas sur l’adaptation à une plate-forme d’analyse que nous pourrions construire plusieurs années dans le futur (si nous étions encore en affaires d’ici là).

Obtenir un flux d’événements, c’est-à-dire juste les nouvelles choses, réduit considérablement le calcul et la bande passante dépensés pour mettre à jour les données de notre plate-forme vers le dernier état.

Diminuer la latence

C’est probablement ce à quoi vous pensez pour la première fois lorsque vous entendez le mot « streaming » et bien sûr, c’est quelque chose qui compte pour nous aussi. Le fait de ne pas être limité par le fait d’avoir de nouvelles données seulement une fois par jour permet de nouvelles utilisations des données. Ce que vous devez garder à l’esprit cependant, c’est que le streaming est difficile. Une comparaison dans le monde réel pourrait faire la différence entre faire des travaux de plomberie sur vos conduites d’approvisionnement en eau (streaming) et arroser vos plantes (lot). Les conséquences d’une erreur dans le premier sont beaucoup plus graves (maison inondée) que dans le second (rebord de fenêtre humide). Si vous avez une serre, les travaux de plomberie pour y installer de l’eau pourraient en valoir la peine, mais si vous n’avez que cinq plantes dans votre appartement, vous voudrez peut-être limiter vos ambitions d’être à l’avant-garde technologique. Je dirais qu’il en va de même pour les plateformes de données.

Notre solution

Avec ce qui précède à l’esprit, nous avons entrepris il y a environ un an de construire un cadre qui améliorerait l’ingestion de données dans notre plate-forme de données. Le travail n’est en aucun cas terminé (il ne le sera probablement jamais), mais c’est ce que nous avons trouvé jusqu’à présent.

Producteurs -> Pub/Sub -> Beam (Dataflow) -> Google Cloud Storage -> Airflow (Cloud Composer) -> BigQuery -> dbt -> BigQuery -> Consommateurs

Cette solution est en cours de production pour quelques sous-composantes de notre système de paiement depuis la fin août, et nous évaluons toujours comment l’améliorer. Nous avons fait quelques observations jusqu’à présent.

Les schémas stricts sont essentiels pour les données structurées

Nous avons opté pour Avro pour l’encodage des messages envoyés par les producteurs. Après avoir expérimenté les fonctionnalités de détection automatique de BigQuery de JSON pur l’année dernière, nous savions que nous avions besoin de quelque chose de plus strict pour ne pas nous retrouver avec un enfer de crash / maintenance pour l’équipe de données. Avec l’une des équipes de développement de produits (et les producteurs éventuels de données), nous avons examiné Protobuf et JSON avec des schémas, mais Avro semblait être le choix avec le moins d’inconvénients. 

Bien qu’il existe un support rudimentaire pour les schémas sur GCP, par exemple, vous pouvez attribuer des schémas Avro à des sujets Pub / Sub, notre expérience a été que c’est beaucoup plus immature que ce que, par exemple, Kafka a à offrir. Les BPC s’améliorent tout le temps, alors peut-être que dans un an, les choses seront différentes. Pour l’instant, nous avons un magasin de schémas dans un seau GCS où les producteurs placent leurs schémas et d’où le travail d’ingestion de faisceau peut les lire.

Utilisez les services cloud lorsque cela est possible

À moins que vous n’ayez des besoins très spécifiques ou que vous n’ayez déjà beaucoup de compétences dans un domaine, nous avons constaté que l’utilisation des services cloud est un moyen facile d’obtenir quelque chose d’évolutif dans la production en moins de temps. Nous avons en fait commencé à construire le pipeline basé sur Kafka, mais nous sommes ensuite passés à Pub / Sub lorsqu’il est devenu évident que l’équipe des services de données devrait faire une part équitable de l’exploitation et de la maintenance de la composante de livraison d’événements (Kafka ou Pub / Sub). Une raison de ne pas opter pour un service cloud est le risque de verrouillage, mais si vous faites preuve de prudence lors de la mise en œuvre, par exemple, n’utilisez le framework que pour son objectif principal de manière découplée et ne commencez pas à l’utiliser pour toutes sortes de choses, il devrait être remplaçable. Mieux encore, bien sûr, si le service cloud est basé sur un framework open source où la logique peut être déplacée vers la solution hébergée d’un autre fournisseur de cloud, par exemple Airflow (Cloud Composer) ou Beam (Dataflow), si le besoin s’en fait sentir.

L’API Python de Beam est immature par rapport à Java

La compétence de notre équipe est principalement au sein de Python et SQL, donc un choix naturel pour nous était de développer le code Beam qui fait l’ingestion de Pub / Sub à BigQuery en Python. Cependant, après avoir passé beaucoup de temps, nous avons commencé à réaliser que l’utilisation de Java nous aurait donné un meilleur support et plus d’options. Pour être juste, la documentation beam ne cache pas ce fait, mais nous, peut-être un peu naïvement, n’y avons pas mis beaucoup de considération au préalable. Par exemple, l’absence d’un système de frappe strict par Python peut rendre plus rapide la prise en main de quelque chose, mais lorsque vous souhaitez vous assurer que vous pouvez gérer toutes les conversions de type entre un schéma Avro et une table BigQuery, Java est plus fiable.

Il est également vrai que les sources et les récepteurs Java fournissent plus de fonctionnalités disponibles, par exemple, vous pouvez fournir au connecteur BigQueryIO en Java un nom de table sur lequel écrire en fonction d’une fonction que vous définissez pour être évaluée au moment de l’exécution. Pour Python, le nom de la table doit être basé sur un champ de l’événement entrant. Conclusion: si vous choisissez d’opter pour Python, vous aurez plus de restrictions sur la façon dont vous pouvez construire votre pipeline et certaines des fonctionnalités qu’il offre semblent plus ou moins expérimentales. Vous devez généralement examiner le code source pour comprendre ce qu’il fait réellement et quelles sont les limites.

Envisagez la micro-mise en lots pour les problèmes où vous n’avez pas besoin de temps réel

À l' Trustly, nous avons des cas d’utilisation qui nécessitent des données de streaming en temps quasi réel pour le pipeline, mais aucun d’entre eux n’est encore entièrement mis en œuvre sur la plate-forme. L’une des raisons pour lesquelles nous choisissons Beam pour l’ingestion est qu’il nous permettrait de combiner le streaming et les flux de lots et - dans une certaine mesure - de basculer entre les deux. En fonction des besoins du consommateur de données, nous pourrions offrir un « produit de données » qui n’est pas plus complexe que nécessaire. Dans notre cas, le micro-traitement par lots signifie stocker des données sous forme de fichiers Avro sur GCS toutes les 10 minutes. Une fois par jour, nous chargeons ces fichiers dans des tables partitionnées dans BigQuery. Pendant la journée, les données sont interrogeables (avec une latence allant jusqu’à 10 minutes) à partir d’une table externe BigQuery pointant vers le dossier sur GCS où les fichiers d’aujourd’hui sont placés; très semblable aux couches de lot et de vitesse d’une architecture lambda.

L’avantage de cela est que nous avons plus de liberté dans la façon dont nous structurons finalement les données dans BigQuery. Si les données sont constamment diffusées dans des tables, il est difficile de changer les choses, par exemple d’ajouter le partitionnement à une table. (Si nous revenons à l’analogie de la plomberie, c’est comme essayer de remplacer le tuyau au lave-vaisselle lorsqu’il est en marche et qu’il n’y a aucun moyen d’éteindre l’approvisionnement en eau). De plus, comme nous ingérions des journées complètes dans des tables cloisonnées par jour, nous obtenons des emplois idempotents et dans le cas d’une défaillance quelque part dans le pipeline, il est beaucoup plus facile de régler les choses et de revenir à un état connu.

Conclusion

Vous méritez un certain crédit si vous l’avez fait jusqu’ici, mais j’ai l’impression que je viens d’effleurer la surface de (un composant de) notre configuration de données. Il y a d’autres choses que j’aimerais partager. Par exemple, notre parcours avec Airflow / Cloud Composer et la façon dont nous avons mis à l’échelle l’utilisation de la dbt dans l’organisation. Cependant, j’espère que cela a au moins donné un aperçu de ce sur quoi nous travaillons et des raisons pour lesquelles nous avons choisi notre solution particulière. Si vous pensez qu’il existe de meilleures façons de le faire ou si vous pensez simplement que ces tâches semblent être un défi intéressant - pourquoi ne pas venir nous rejoindre? Nous sommes constamment à la recherche d’ingénieurs de données qualifiés pour développer l’équipe et améliorer notre pratique au sein de l’entreprise.

Par Isacson
Responsable de l’ingénierie des données