Découvrez pourquoi Ricardo a choisi d'associer Bigtable à BigQuery

Avec plus de 3,7 millions de membres, Ricardo est le plus grand fiable et important marché en ligne suisse. En 2019, nous avons procédé à la migration de notre infrastructure sur site vers Google Cloud. Ce faisant, nous avons rencontré de nouveaux cas d'utilisation, que nous souhaitions absolument résoudre. Avec la fermeture de notre centre de données sur site, nous devions rapidement trouver une solution pour ces cas d'utilisation, en commençant par notre traitement de flux de données. Nous avons décidé d'utiliser les services Cloud Bigtable et Dataflow de Google Cloud. 

Analyse de nos cas d'utilisation de données 

Avant de passer à BigQuery, l'entrepôt de données de Google Cloud pour les entreprises, nous utilisions Microsoft SQL afin d’effectuer les analyses. Nous devions donc migrer toutes nos charges de travail vers la nouvelle plate-forme. Nous avons alors décidé d'exécuter les importations et les chargements par lot de Kafka vers BigQuery via Apache Beam.

Nous souhaitions également que nos équipes internes puissent effectuer des détections de fraudes via notre portail d'informations client, afin de protéger notre clientèle contre la vente de produits frauduleux ou les usurpations d'identité. 

Nos ingénieurs ont également dû rapidement trouver comment déporter nos deux principaux flux de données, ces dernières étant stockées dans des systèmes distincts. L'un est principalement destiné aux articles mis en vente sur notre plate-forme. L'autre regroupe les éléments qui contiennent les différentes descriptions des articles. Avant, nous insérions les flux dans BigQuery, puis nous procédions à une jointure. Or, cela fait maintenant un certain temps que Ricardo est présent sur le marché. Il arrive donc parfois qu'un article n'ait pas été stocké depuis 2006 ou soit répertorié à nouveau, ce qui peut entraîner l'absence de certaines informations dans le flux des éléments. 

Quelle solution pour résoudre ce problème ?

Alors que je cherchais à résoudre notre problème de flux de données, je suis tombé sur le blog Google Cloud. J'y ai trouvé un guide sur les modèles d'utilisation courants pour Dataflow, le service de traitement par lot et par flux unifié de Google Cloud, avec une section sur les grandes tables de correspondance en mode flux". En plus de notre flux d'articles, nous disposons d'une table de correspondance de 400 Go regroupant nos éléments. Cependant, nous voulions être en mesure de rechercher l'élément associé à un article donné. Ce guide suggérait qu'un système orienté colonnes pourrait exécuter ce type de requête en quelques millisecondes, et pourrait être utilisé dans un pipeline Dataflow pour effectuer la recherche et mettre à jour le tableau. 

Nous avons donc examiné deux options pour résoudre le cas d'utilisation. Nous avons essayé un prototype avec Apache Cassandra, le système de gestion de base de données NoSQL, Open Source et orienté colonnes, que nous pouvons insérer en flux continu depuis BigQuery en préchargeant les données de l'historique à l'aide d'Apache Beam. 

Nous avons développé un cluster Cassandra sur Google Kubernetes Engine (GKE) à l'aide de CASS Operator, publié en Open Source par Datastax. Nous avons créé une structure d'index, optimisé l'ensemble et effectué des benchmarks, et nous nous sommes rendu compte que tout fonctionnait correctement. Nous disposions donc du nouveau cluster, le pipeline consommait des éléments et des articles, et la recherche des éléments était effectuée depuis Cassandra, où ils étaient également stockés. 

Concernant les tâches routinières et les problèmes liés aux opérations, notre équipe d'intelligence des données doit être entièrement autonome. Nous sommes une petite entreprise, alors nous devons évoluer rapidement. Cependant, nous ne voulons pas créer un système qui pourrait être rapidement dépassé. 

Nous étions déjà satisfaits des services gérés de BigQuery. C'est pourquoi Bigtable, un service de base de données NoSQL orienté colonnes, à faible latence et entièrement géré, s'est naturellement imposé à nous. 

Des économies nettes de 13 % avec Bigtable

Le point faible de Cassandra par rapport à Bigtable résidait dans son coût. Cassandra avait besoin de trois nœuds pour assurer les garanties de disponibilité. Avec Bigtable, nous pouvions bénéficier d'un pipeline de données tolérant aux pannes et d'un pipeline Apache Beam s'exécutant sur Apache Flink. Nous pouvions également profiter d'une tolérance aux pannes en cas de faible disponibilité. Il n'était donc pas nécessaire d'exécuter les trois nœuds. Nous pouvions bénéficier de 18 nœuds lors de l'ingestion de l'historique de BigQuery dans Bigtable pour la table de correspondance. Ensuite, une fois l'ingestion terminée, nous pouvions passer à un ou deux nœuds, chaque nœud étant capable de lire jusqu'à 10 000 lignes par seconde. Bigtable se charge de la disponibilité et de la durabilité en arrière-plan, et offre ainsi des garanties même avec un seul nœud.

Cet aspect nous a fait prendre conscience que la solution Bigtable était plus économique et facile à gérer que la solution basée sur Cassandra. En tenant compte des coûts d'opérations, du temps d'arrêt et de l'assistance technique inhérents à la solution Cassandra sur GKE, il convenait plus à notre petite équipe de commencer par utiliser un To dans une instance Bigtable. Bigtable était l'option la plus simple, rapide et économique. En transférant de telles requêtes de recherche vers Bigtable, nous avons réduit nos coûts BigQuery de 13 %. Il est important de garder à l'esprit qu'il s'agit d'économies nettes, les coûts supplémentaires liés à l'exécution de Bigtable sont déjà comptabilisés.

Une fois cette nouvelle solution en place, nous avons migré une autre charge de travail vers Bigtable, où nous avons intégré les informations liées aux tickets de Zendesk pour notre service client. Les rendant accessibles dans Bigtable pour associer la recherche de clé de production aux données Zendesk. Ainsi, nos agents peuvent immédiatement accéder à ces informations. 

Profiter de l'intégration des outils Google Cloud 

Si, comme nous, vous êtes une petite entreprise, créer une infrastructure de données où les données sont facilement accessibles est d'une importance cruciale. Bigtable est l’endroit où nous avons traité les données prêtes à être utilisées par des services. Grâce à l'intégration des services entre Bigtable, BigQuery et Dataflow, nous pouvons faciliter l'accès à ces données. 

L'un des atouts majeurs de la plate-forme Google Cloud, c'est également la possibilité d'apporter rapidement des ajustements avec Dataflow et BigQuery. Ce matin, par exemple, alors que je réfléchissais à un projet en cours, je me suis rendu compte que nous aurions dû inverser l'ID d'article de sorte que la chaîne soit inversée pour empêcher le hotspotting. Pour ceci nous avons pu augmenter le nombre de noeuds à 20 pour Bigtable ainsi que le nombre de noeuds de calcul à 50 pour Dataflow. Les tâches par lot ont ensuite procédé à la lecture dans BigQuery et à l'écriture dans le nouveau schéma avec Bigtable. L'opération n'a duré que 25 minutes. Avant l'adoption de la solution Bigtable, ce genre d'ajustement aurait duré des jours.

De nouvelles opportunités grâce à l'outil Key Visualizer de Bigtable

J'ai eu l'idée d'inverser l'ID d'article alors que je pensais à Key Visualizer de Bigtable, qui est pratique et facile à utiliser par rapport à notre ancienne configuration. Cet outil offre une intégration étroite, mais il est facile d'expliquer son fonctionnement. 

Mis à part le nombre de nœuds et le choix d'obtenir ou non une réplication, nous n'avons pas à nous soucier de la configuration avec les nœuds SSD. C'est aussi facile que de tourner le bouton de volume sur une chaîne hi-fi, ce qui nous a vraiment impressionnés. L'extensibilité à la hausse ou à la baisse se fait très rapidement, et, avec Dataflow, vous ne subissez aucune perte. Ainsi, vous n'avez pas à instancier quoi que ce soit, vous pouvez simplement effectuer la programmation et le partage lors de l'exécution. Nous n'avions encore jamais vu une telle capacité d'extensibilité.

Envisager de futurs cas d'utilisation pour Bigtable

Pour les cas futurs, nous utilisons le machine learning pour améliorer notre projet de détection des fraudes, que nous espérons déplacer vers Bigtable. Actuellement, nous disposons d'un processus qui est déclenché toutes les heures par Airflow dans Cloud Composer. Celui-ci extrait les données de BigQuery de l'heure précédente, puis il les passe en revue pendant que le conteneur Python s'exécute avec le modèle qui fait l'objet d'un chargement et qui reçoit les données en entrée. Si l'algorithme est sûr à 100 % que l'article est frauduleux, il bloque le produit qui pourra uniquement être libéré via une demande manuelle émise par le service client. Si l'algorithme n'est pas aussi catégorique, le produit est signalé et envoyé au service client à des fins de vérification.

Il manque actuellement une boucle de rétroaction automatisée au sein du processus, un ajustement au cas où l'agent chargé de la vérification indique que l'article n'est pas frauduleux. Nous pourrions écrire du code pour exécuter cette action, mais il nous faut une solution plus rapide. Il serait plus judicieux de le faire directement depuis Bigtable.

À l'avenir, nous aimerions également que le pipeline Dataflow procède à l'écriture dans BigQuery et Bigtable de manière simultanée pour tous les points importants. Nous pourrions alors résoudre ce genre de cas d'utilisation et les diffuser directement et quasiment en temps réel à partir de Bigtable plutôt que BigQuery. 

Grâce à la diminution des coûts BigQuery de 13 % et à l'intégration étroite de tous les services gérés Google Cloud comme Bigtable, notre équipe d'intelligence des données, petite mais tenace, ne rencontre plus de problèmes avec les opérations sur notre plate-forme de données. Nous pouvons, entre autres, consacrer le temps gagné au développement de solutions pour ces cas d'utilisation futurs. 

Allez faire un tour sur Ricardo.ch, puis visitez notre site Web pour en savoir plus sur le stockage cloud natif des valeurs/clés avec Bigtable.