Guide d'utilisation d'Apache Cassandra en tant que magasin de fonctionnalités en temps réel

Il s'agit d'un guide pratique pour utiliser Apache Cassandra en tant que magasin de fonctionnalités en temps réel. Nous explorons l'IA en temps réel et les performances uniques et les attributs de coût de Cassandra qui en font une excellente base de données pour un magasin de fonctionnalités, puis plongeons dans les bases des magasins de fonctionnalités et leur rôle dans les applications en temps réel. Cassandra est utilisée comme magasin de fonctionnalités par de grandes entreprises, notamment Uber et Netflix ; dans des conditions réelles, il peut servir des fonctionnalités pour l'inférence en temps réel avec un tp99 < 23 ms.

Le guide est divisé en plusieurs sections clés. Nous commençons par présenter Cassandra et ses fonctionnalités qui en font un choix idéal pour un magasin de fonctionnalités. Ensuite, nous expliquons les bases des magasins de fonctionnalités, y compris ce qu'ils sont et comment ils peuvent être utilisés dans des applications en temps réel. Après cela, nous explorons les détails de mise en œuvre de la création d'un magasin de fonctionnalités à l'aide de Cassandra. Cela inclut la modélisation des données, l'ingestion et la récupération des fonctionnalités, ainsi que la gestion des mises à jour des données. Enfin, nous proposons les meilleures pratiques et des conseils pour utiliser Cassandra en tant que magasin de fonctionnalités afin d'assurer des performances et une évolutivité optimales - des exigences de latence aux exigences de métriques de performances estimées en passant par les architectures de référence et la compatibilité de l'écosystème.

Ce guide ne traite pas deaspects de la science des données de l'apprentissage automatique en temps réel ou la aspects de gestion du cycle de vie des fonctionnalités dans un magasin de fonctionnalités . Les meilleures pratiques que nous couvrirons sont basées sur des conversations techniques avec des praticiens de grandes entreprises technologiques telles que Google, Facebook, Uber , AirBnB , et Netflix sur la façon dont ils offrent des expériences d'IA en temps réel à leurs clients sur leurs infrastructures cloud natives. Bien que nous nous concentrions spécifiquement sur la façon d'implémenter le stockage de fonctionnalités en temps réel avec Cassandra, les directives d'architecture s'appliquent vraiment à toute technologie de base de données, y compris Redis, MongoDB et Postgres.

Qu'est-ce que l'IA en temps réel ?

L'IA en temps réel fait des inférences ou des modèles de formation basés sur des événements récents . Traditionnellement, les modèles de formation et les inférences (prédictions) basées sur des modèles ont été effectuées par lots - généralement pendant la nuit ou périodiquement tout au long de la journée. Aujourd'hui, les systèmes d'apprentissage automatique modernes effectuent des inférences des données les plus récentes afin de fournir la prédiction la plus précise possible. Un petit groupe d'entreprises comme TikTok et Google a poussé plus loin le paradigme du temps réel en incluant une formation à la volée des modèles à mesure que de nouvelles données arrivent.

En raison de ces changements dans l'inférence et des changements qui se produiront probablement dans la formation du modèle, la persistance des données de caractéristiques (données utilisées pour former et effectuer des inférences pour un modèle ML) doit également s'adapter. Lorsque vous aurez fini de lire ce guide, vous aurez une idée plus claire de la façon dont Cassandra et DataStax Astra DB, un service géré basé sur Cassandra, répondent aux besoins d'IA en temps réel, et comment ils peuvent être utilisés conjointement avec d'autres technologies de base de données. pour l'inférence et la formation de modèles.

Qu'est-ce qu'un magasin de fonctionnalités ?

Un magasin de fonctionnalités est un système de données spécifique à l'apprentissage automatique (ML) qui :

• Exécute des pipelines de données qui transforment les données brutes en valeurs de caractéristiques
• Stocke et gère les données de caractéristiques elles-mêmes, et
• Diffuse les données de caractéristiques de manière cohérente à des fins de formation et d'inférence

L'IA en temps réel impose des exigences spécifiques à un magasin de fonctionnalités que Cassandra est particulièrement qualifiée pour remplir, en particulier en ce qui concerne le stockage et la diffusion de fonctionnalités pour la diffusion de modèles et la formation de modèles.

Les meilleures pratiques

** Mettre en œuvre des requêtes à faible latence pour la diffusion de fonctionnalités

Pour l'inférence en temps réel, les fonctionnalités doivent être renvoyées aux applications avec une faible latence à grande échelle. Les modèles typiques impliquent environ 200 fonctionnalités réparties sur environ 10 entités. Les inférences en temps réel nécessitent du temps à budgétiser pour collecter des fonctionnalités, des transformations de données légères et effectuer une inférence. Selon l' enquête suivante (également confirmée par nos conversations avec des praticiens), les magasins de fonctionnalités doivent renvoyer les fonctionnalités à une application effectuant une inférence en moins de 50 ms.

En règle générale, les modèles nécessitent des "jointures internes" sur plusieurs entités logiques - combinant des valeurs de lignes de plusieurs tables partageant une valeur commune ; cela représente un défi important pour le service de fonctionnalités à faible latence. Prenons le cas d'Uber Eats, qui prédit le temps de livraison d'un repas. Les données doivent être jointes à partir des informations de commande, qui sont jointes aux informations sur le restaurant, qui sont en outre jointes par des informations sur le trafic dans la région du restaurant. Dans ce cas, deux joints intérieurs sont nécessaires (voir l'illustration ci-dessous).

Pour réaliser une jointure interne dans Cassandra, on peut soit dénormaliser les données lors de l'insertion, soit faire deux requêtes séquentielles à Cassandra + effectuer la jointure côté client. Bien qu'il soit possible d'effectuer toutes les jointures internes lors de l'insertion de données dans la base de données via la dénormalisation, il n'est pas pratique d'avoir un rapport 1:1 entre le modèle et la table, car cela signifie maintenir un nombre excessif de tables dénormalisées. Les meilleures pratiques suggèrent que le magasin de fonctionnalités doit autoriser 1 à 2 requêtes séquentielles pour les jointures internes, combinées à la dénormalisation.

Voici un résumé des métriques de performances qui peuvent être utilisées pour estimer les besoins des pipelines de ML en temps réel :

Conditions de test :

• fonctionnalités = 200

• nombre de tables (entités) = 3

• nombre de jointures internes = 2

• Requête TPS : 5000 requêtes / seconde

• Ecriture TPS : 500 enregistrements/seconde

• Taille du cluster : 3 nœuds sur AstraDB*

  
  

Résumé des performances de latence (les incertitudes sont ici des écarts-types) :

• tp95 = 13,2(+/-0,6) ms

• tp99 = 23,0(+/-3,5) ms

• tp99.9 = 63(+/- 5) ms

  
  

Effet du compactage :

• tp95 = négligeable
• tp99, tp999 = négligeable, capturé par les sigmas cités ci-dessus

Capture de données sur l'effet du changement (CDC) :

• tp50, tp95 ~ 3-5 ms

• tp99 ~ 3 ms

• tp999 ~ négligeable

  
  

*Les tests suivants ont été effectués sur le niveau gratuit d'Astra DB de DataStax, qui est un environnement sans serveur pour Cassandra. Les utilisateurs doivent s'attendre à des performances de latence similaires lorsqu'ils sont déployés sur trois notes en utilisant les paramètres recommandés suivants .

L'impact le plus important sur la latence est le nombre de jointures internes. Si une seule table est interrogée au lieu de trois, le tp99 chute de 58 % ; pour deux tables, c'est 29% de moins. Le TP95 baisse respectivement de 56% et 21%. Étant donné que Cassandra est évolutive horizontalement, l'interrogation de davantage de fonctionnalités n'augmente pas non plus de manière significative la latence moyenne.

Enfin, si les exigences de latence ne peuvent pas être satisfaites dès le départ, Cassandra dispose de deux fonctionnalités supplémentaires : la capacité à prendre en charge les données dénormalisées (et donc à réduire les jointures internes) grâce à des capacités de débit d'écriture élevées et la possibilité de répliquer sélectivement les données vers caches mémoire (par exemple Redis) via Change Data Capture. Vous pouvez trouver plus de conseils pour réduire la latence ici.

Mettre en œuvre des écritures tolérantes aux pannes et à faible latence pour les transformations de fonctionnalités

Un élément clé de l'IA en temps réel est la possibilité d'utiliser les données les plus récentes pour effectuer une inférence de modèle. Il est donc important que de nouvelles données soient disponibles pour l'inférence dès que possible. Dans le même temps, pour les cas d'utilisation en entreprise, il est important que les écritures soient durables, car la perte de données peut entraîner des problèmes de production importants.

*Les magasins d'objets (par exemple, S3 ou HIVE) peuvent être remplacés par d'autres types de systèmes orientés batch, tels que les entrepôts de données.

Il existe un compromis entre les écritures durables à faible latence et la diffusion de fonctionnalités à faible latence. Par exemple, il est possible de stocker uniquement les données dans un emplacement non durable (par exemple, Redis), mais les échecs de production peuvent rendre difficile la récupération des fonctionnalités les plus à jour car cela nécessiterait un recalcul important à partir d'événements bruts. .

Une architecture courante suggère d'écrire des fonctionnalités dans un magasin hors ligne (par exemple, Hive / S3) et de répliquer les fonctionnalités dans un magasin en ligne (par exemple, un cache en mémoire). Même si cela offre une durabilité et une faible latence pour le service des fonctionnalités, cela se fait au prix de l'introduction d'une latence pour les écritures de fonctionnalités, ce qui entraîne invariablement de moins bonnes performances de prédiction.

Cassandra offre un bon compromis entre le service de fonctionnalités à faible latence et les écritures de fonctionnalités « durables » à faible latence. Les données écrites sur Cassandra ont généralement été répliquées au moins trois fois et prennent en charge la réplication multirégionale. La latence entre l'écriture et la disponibilité en lecture est généralement inférieure à la milliseconde. Par conséquent, en conservant les fonctionnalités directement dans la boutique en ligne (Cassandra) et en contournant la boutique hors ligne, l'application a un accès plus rapide aux données récentes pour faire des prédictions plus précises. Dans le même temps, CDC, de la boutique en ligne à la boutique hors ligne, permet la formation par lots ou l'exploration de données avec des outils existants.

Mettre en œuvre une faible latence et des écritures pour la mise en cache des prédictions et la surveillance des performances

Outre le stockage de la transformation des fonctionnalités, il est également nécessaire de stocker des prédictions et d'autres données de suivi pour la surveillance des performances.

Il existe plusieurs cas d'utilisation pour le stockage des prédictions :

1. Magasin de prédictions – Dans ce scénario, une base de données utilisée pour mettre en cache les prédictions effectuées par un système de traitement par lots ou un système de diffusion en continu . L'architecture de flux est particulièrement utile lorsque le temps nécessaire à l'inférence dépasse ce qui est acceptable dans un système de requête-réponse.
2. Surveillance des performances de prédiction Il est souvent nécessaire de surveiller la sortie de prédiction d'une inférence en temps réel et de la comparer aux résultats finaux. Cela signifie avoir une base de données pour enregistrer les résultats de la prédiction et le résultat final.

Cassandra est un magasin adapté aux deux cas d'utilisation en raison de ses capacités de débit d'écriture élevé.

Planifier des charges de travail de lecture et d'écriture élastiques

Le niveau des requêtes et des transactions d'écriture par seconde dépend généralement du nombre d'utilisateurs utilisant simultanément le système. Par conséquent, les charges de travail peuvent changer en fonction de l'heure de la journée ou de la période de l'année. Il est important de pouvoir augmenter et réduire rapidement le cluster pour prendre en charge des charges de travail accrues. Cassandra et Astra DB ont des fonctionnalités qui permettent une mise à l'échelle dynamique du cluster.

Le deuxième aspect qui pourrait affecter les charges de travail d'écriture est s'il y a des changements dans la logique de transformation des fonctionnalités. Avec un pic important de charges de travail d'écriture, Cassandra donne automatiquement la priorité au maintien des requêtes à faible latence et à l'écriture de TPS plutôt qu'à la cohérence des données, ce qui est généralement acceptable pour effectuer une inférence en temps réel.

Mettre en œuvre une prise en charge multirégionale à faible latence

Alors que l'IA en temps réel devient omniprésente dans toutes les applications, il est important de s'assurer que les données de caractéristiques sont disponibles aussi près que possible de l'endroit où l'inférence se produit. Cela signifie que le magasin de fonctionnalités se trouve dans la même région que l'application effectuant l'inférence. La réplication des données dans le magasin de fonctionnalités dans toutes les régions permet de garantir cette fonctionnalité. De plus, répliquer uniquement les fonctionnalités plutôt que les données brutes utilisées pour générer les fonctionnalités réduit considérablement les frais de sortie du cloud.

Astra DB prend en charge la réplication multi-régions prête à l'emploi, avec une latence de réplication en millisecondes. Notre recommandation est de diffuser toutes les données d'événement brutes dans une seule région, d'effectuer la génération de fonctionnalités, de stocker et de répliquer les fonctionnalités dans toutes les autres régions.

Bien que théoriquement, on puisse obtenir un certain avantage de latence en générant des caractéristiques dans chaque région, les données d'événement doivent souvent être associées à des données d'événement brutes d'autres régions. du point de vue de l'exactitude et de l'efficacité, il est plus facile d'expédier tous les événements vers une région pour traitement dans la plupart des cas d'utilisation. D'autre part, si l'utilisation du modèle est la plus logique dans un contexte régional et que la plupart des événements sont associés à des entités spécifiques à la région, il est logique de traiter les entités comme spécifiques à la région. Tous les événements qui doivent être répliqués dans toutes les régions peuvent être placés dans des espaces clés avec des stratégies de réplication globales, mais idéalement, cela devrait être un petit sous-ensemble d'événements. À un certain point, la réplication globale des tables d'événements sera moins efficace que la simple expédition de tous les événements vers une seule région pour les calculs de caractéristiques.

Planifiez une prise en charge multicloud économique et à faible latence

La prise en charge multi-cloud augmente la résilience des applications et permet aux clients de négocier des prix plus bas. Les magasins en ligne à cloud unique tels que DynamoDB entraînent à la fois une latence accrue pour la récupération des fonctionnalités et des coûts de sortie de données importants, mais créent également un verrouillage sur un seul fournisseur de cloud.

Les bases de données open source qui prennent en charge la réplication dans les clouds offrent le meilleur équilibre entre le coût des performances. Pour minimiser le coût de la sortie, les événements et la génération de fonctionnalités doivent être consolidés dans un seul cloud, et les données de fonctionnalités doivent être répliquées dans des bases de données open source sur les autres clouds. Cela minimise les coûts de sortie.

Planifier la formation par lots et en temps réel des modèles de production

L'infrastructure de traitement par lots pour la création de modèles est utilisée pour deux cas d'utilisation : la création et le test de nouveaux modèles, et la création de modèles pour la production. Par conséquent, il suffisait généralement que les données d'entité soient stockées dans des magasins d'objets plus lents à des fins de formation. Cependant, les nouveaux paradigmes de formation de modèles incluent la mise à jour des modèles en temps réel ou quasi réel (formation en temps réel); c'est ce qu'on appelle « l'apprentissage en ligne » (par exemple, Monolith de TikTok ). Le modèle d'accès pour la formation en temps réel se situe quelque part entre l'inférence et la formation par lots traditionnelle. Les exigences de données de débit sont plus élevées que l'inférence (car il n'accède généralement pas à une recherche sur une seule ligne), mais pas aussi élevées que le traitement par lots qui impliquerait des analyses de table complètes.

Cassandra peut prendre en charge une évaluation TPS de centaines de milliers par seconde (avec un modèle de données approprié), ce qui peut fournir un débit suffisant pour la plupart des cas d'utilisation de formation en temps réel. Cependant, dans le cas où l'utilisateur souhaite conserver la formation en temps réel à partir d'un magasin d'objets, Cassandra y parvient via CDC vers le stockage d'objets. Pour la formation par lots, CDC doit répliquer les données vers le stockage d'objets. Il convient de noter que les frameworks d'apprentissage automatique tels que Tensorflow et PyTorch sont particulièrement optimisés pour la formation parallèle de modèles ML à partir d'un stockage d'objets.

Pour une explication plus détaillée de "l'apprentissage en ligne", voir l'explication de Chip Huyuen surl'apprentissage continu ou cet article technique de Gomes et. al .

Prise en charge de l'architecture Kappa

L'architecture Kappa remplace progressivement l'architecture Lambda en raison des coûts et des problèmes de qualité des données dus au décalage en ligne/hors ligne. Bien que de nombreux articles discutent des avantages du passage de couches de calcul par lot et en temps réel distinctes à une seule couche en temps réel, les articles ne décrivent pas souvent comment concevoir la couche de service.

L'utilisation de l'architecture Kappa pour générer des fonctionnalités soulève de nouvelles considérations :

• Les fonctionnalités de mise à jour sont mises à jour en masse et peuvent entraîner un nombre important d'écritures dans la base de données. Il est important de s'assurer que la latence des requêtes ne souffre pas lors de ces mises à jour importantes.
• La couche de service doit toujours prendre en charge différents types de requêtes, y compris les requêtes à faible latence pour l'inférence et les requêtes highTPS pour la formation par lots des modèles.

Cassandra prend en charge l'architecture Kappa des manières suivantes :

• Cassandra est conçue pour les écritures ; un afflux accru d'écritures ne réduit pas de manière significative la latence des requêtes. Cassandra opte pour le traitement des écritures avec une cohérence éventuelle au lieu d'une cohérence forte, ce qui est généralement acceptable pour faire des prédictions.
• À l'aide de CDC, les données peuvent être répliquées sur le stockage d'objets pour la formation et le stockage en mémoire pour l'inférence. CDC a peu d'impact sur la latence des requêtes adressées à Cassandra.

Prise en charge de l'architecture Lambda

La plupart des entreprises ont une architecture Lambda, avec un pipeline de couche batch distinct du pipeline en temps réel. Il existe plusieurs catégories de fonctionnalités dans ce scénario :

1. Fonctionnalités calculées uniquement en temps réel et répliquées dans le magasin de fonctionnalités par lots pour la formation
2. Fonctionnalités calculées uniquement par lots et répliquées dans le magasin de fonctionnalités en temps réel
3. Les caractéristiques sont d'abord calculées en temps réel, puis recalculées dans le lot. Les écarts sont ensuite mis à jour à la fois dans le magasin d'objets et en temps réel.

Dans ce scénario, toutefois, DataStax recommande l'architecture décrite dans cette illustration :

Les raisons sont les suivantes :

1. Cassandra est conçu pour effectuer des téléchargements par lots de données avec peu d'impact sur la latence de lecture
2. En ayant un seul système d'enregistrement, la gestion des données devient beaucoup plus facile que si les données étaient réparties entre le magasin de fonctionnalités et le magasin d'objets. Ceci est particulièrement important pour les fonctionnalités qui sont d'abord calculées en temps réel, puis recalculées par lots.
3. Lors de l'exportation de données de Cassandra via CDC vers le magasin de fonctionnalités d'objets, l'exportation de données peut être optimisée pour la formation par lots (un modèle courant utilisé dans des entreprises comme Facebook ), ce qui réduit considérablement les coûts d'infrastructure de formation.

S'il n'est pas possible de mettre à jour les pipelines existants, ou s'il existe des raisons spécifiques pour lesquelles les fonctionnalités doivent d'abord se trouver dans le magasin d'objets, notre recommandation est d'utiliser un chemin CDC bidirectionnel entre le magasin de fonctionnalités Cassandra et le magasin d'objets, comme illustré ci-dessous.

Assurer la compatibilité avec l'écosystème logiciel ML existant

Pour utiliser Cassandra en tant que magasin de fonctionnalités, il doit être intégré à deux parties de l'écosystème : les bibliothèques d'apprentissage automatique qui effectuent l'inférence et la formation, et les bibliothèques de traitement de données qui effectuent la transformation des fonctionnalités.

Les deux frameworks les plus populaires pour l'apprentissage automatique sont TensorFlow et PyTorch. Cassandra dispose de pilotes Python qui permettent de récupérer facilement les fonctionnalités de la base de données Cassandra ; en d'autres termes, plusieurs fonctionnalités peuvent être récupérées en parallèle ( voir cet exemple de code ). Les deux frameworks les plus populaires pour effectuer la transformation de fonctionnalités sont Flink et Spark Structured Streaming . Des connecteurs pour Flink et Spark sont disponibles pour Cassandra. Les praticiens peuvent utiliser des didacticiels pour Flink et Spark Structured Streaming et Cassandra.

Les magasins de fonctionnalités Open Source tels que FEAST ont également un connecteur et un didacticiel pour Cassandra.

Comprendre les modèles de requête et le débit pour déterminer les coûts

Le nombre de requêtes de lecture pour Cassandra en tant que magasin de fonctionnalités dépend du nombre de demandes d'inférence entrantes. En supposant que les données d'entités sont réparties sur plusieurs tables, ou si les données peuvent être chargées en parallèle, cela devrait donner une estimation de la diffusion entre l'inférence en temps réel qui peut être effectuée. Par exemple, 200 fonctionnalités réparties sur 10 entités dans 10 tables distinctes vous donnent un rapport d'environ 1:10 entre l'inférence en temps réel et les requêtes adressées à Cassandra.

Le calcul du nombre d'inférences effectuées dépendra du modèle de trafic d'inférence. Par exemple, dans le cas de "l'inférence en continu", une inférence sera effectuée chaque fois qu'une caractéristique pertinente change, de sorte que le nombre total d'inférences dépend de la fréquence à laquelle les données de caractéristique changent. Lorsque l'inférence est effectuée dans un paramètre "demande-réponse", elle n'est effectuée que lorsqu'un utilisateur la demande.

Comprendre les modèles d'écriture par lots et en temps réel pour déterminer les coûts

Le débit d'écriture est principalement dominé par la fréquence à laquelle les fonctionnalités changent. Si une dénormalisation se produit, cela peut également avoir un impact sur le nombre de fonctionnalités écrites. D'autres considérations relatives au débit d'écriture incluent la mise en cache des inférences pour les scénarios d'inférence par lots ou par flux.

Conclusion

Lors de la conception d'un pipeline ML en temps réel, une attention particulière doit être accordée aux performances et à l'évolutivité du magasin de fonctionnalités. Les exigences sont particulièrement bien satisfaites par les bases de données NoSQL telles que Cassandra. Créez votre propre magasin de fonctionnalités avec Cassandra ou AstraDB et essayez le Feast.dev avec le connecteur Cassandra .