Au cours de la dernière décennie, la croissance et le succès de l'apprentissage automatique ont été phénoménaux, principalement grâce à la disponibilité de grandes quantités de données et à une puissance de calcul avancée. Cette poussée a été provoquée par la numérisation de divers secteurs, entraînant une explosion des données numériques, des publications sur les réseaux sociaux aux transactions en ligne et aux données des capteurs.
Les progrès des techniques d'apprentissage automatique, en particulier dans l'apprentissage en profondeur, ont facilité le développement de modèles plus complexes et polyvalents. Par conséquent, les applications d'apprentissage automatique sont devenues omniprésentes, contribuant à améliorer l'efficacité et les capacités dans de nombreux secteurs, notamment la santé, la finance et les transports.
Travailler avec ces quantités massives de données basées sur des événements et tirer de la valeur des événements eux-mêmes et de leur contexte dans le temps - d'autres événements se produisant à proximité - est toujours difficile. Le faire en temps réel ou en streaming est encore plus difficile. Vous devez souvent utiliser des API complexes de bas niveau ou contourner les limites d'un langage de requête de niveau supérieur conçu pour résoudre des problèmes très différents, comme SQL.
Pour relever ces défis, nous introduisons une nouvelle abstraction pour les données temporelles, appelées chronologies. Les chronologies organisent les données par heure et par entité, offrant une structure idéale pour les données basées sur les événements avec un modèle mental graphique intuitif. Les chronologies simplifient le raisonnement sur le temps en alignant votre modèle mental sur le domaine du problème, vous permettant de vous concentrer sur ce qu'il faut calculer, plutôt que sur la façon de l'exprimer.
Dans cet article, nous présentons les chronologies comme un moyen naturel d'organiser des données basées sur des événements et d'en extraire de la valeur - directement, et comme entrées pour l'apprentissage automatique et l'ingénierie rapide. Nous nous penchons sur le concept de chronologie, son interaction avec les magasins de données externes (entrées et sorties) et le cycle de vie des requêtes utilisant des chronologies.
Cet article est le premier d'une série sur Kaskada , un moteur de traitement d'événements open source conçu autour de l'abstraction de la chronologie. Nous poursuivrons avec une explication de la façon dont Kaskada construit un langage de requête temporelle expressif sur l'abstraction de la chronologie, comment le modèle de données de la chronologie permet à Kaskada d'exécuter efficacement des requêtes temporelles et, enfin, comment les chronologies permettent à Kaskada de s'exécuter de manière incrémentielle sur les flux d'événements.
Il est difficile de traiter une grande variété d'événements lorsque chaque type d'événement est traité comme une table de données distincte et non ordonnée - la façon dont SQL voit le monde. Il est difficile de comprendre ce qui a motivé Carla à faire des achats ou ce qui a poussé Aaron à dialoguer avec d'autres utilisateurs via des messages.
En organisant les données - par heure et par utilisateur - il devient beaucoup plus facile de repérer les modèles. Aaron envoie des messages après avoir gagné. Carla fait des achats lorsqu'elle est frustrée par une série de pertes. Nous voyons également que Brad a peut-être arrêté de jouer.
En organisant les données - par heure et par utilisateur - il devient beaucoup plus facile de repérer les modèles. Aaron envoie des messages après avoir gagné. Carla fait des achats lorsqu'elle est frustrée par une série de pertes. On voit aussi que Brad a peut-être arrêté de jouer.
En organisant les événements de manière naturelle – par heure et par utilisateur – nous avons pu identifier des modèles. Cette même organisation nous permet d'exprimer des valeurs de caractéristiques calculées à partir des événements et de les utiliser pour former et appliquer des modèles d'apprentissage automatique ou calculer des valeurs à utiliser dans une invite.
Raisonner sur le temps - par exemple, la cause et l'effet entre les événements - nécessite plus qu'un simple ensemble non ordonné de données d'événement. Pour les requêtes temporelles, nous devons inclure le temps comme une partie de première classe de l'abstraction. Cela permet de raisonner sur le moment où un événement s'est produit et sur l'ordre - et le temps - entre les événements.
Kaskada est construit sur l'abstraction temporelle : un multiset ordonné par temps et regroupé par entité. Les chronologies ont une visualisation naturelle, illustrée ci-dessous. Le temps est indiqué sur l'axe des x et les valeurs correspondantes sur l'axe des y. Envisagez d'acheter des événements auprès de deux personnes : Ben et Davor. Ceux-ci sont affichés sous forme de points discrets reflétant le moment et le montant de l'achat. Nous appelons ces chronologies discrètes car elles représentent des points discrets.
L'axe temporel d'une chronologie reflète l'heure du résultat d'un calcul. Par exemple, à tout moment, nous pourrions demander "quelle est la somme de tous les achats ?" Les agrégations sur des échéanciers sont cumulatives – au fur et à mesure que des événements sont observés, la réponse à la question change. Nous appelons ces chronologies continues car chaque valeur continue jusqu'au prochain changement.
Par rapport à SQL, les chronologies introduisent deux exigences : le tri par heure et le regroupement par entité. Alors que la relation SQL - un multiset ou un sac non ordonné - est utile pour les données non ordonnées, les exigences supplémentaires des chronologies les rendent idéales pour raisonner sur les causes et les effets. Les chronologies sont aux données temporelles ce que les relations sont aux données statiques.
L'ajout de ces exigences signifie que les délais ne conviennent pas à toutes les tâches de traitement de données. Au lieu de cela, ils permettent aux chronologies de mieux s'adapter aux tâches de traitement de données qui fonctionnent avec des événements et du temps. En fait, la plupart des flux d'événements (par exemple, Apache Kafka, Apache Pulsar, AWS Kinesis, etc.) proposent un classement et un partitionnement par clé.
Lorsque vous pensez aux événements et au temps, vous imaginez probablement déjà quelque chose comme une chronologie. En faisant correspondre la façon dont vous pensez déjà au temps, les chronologies simplifient le raisonnement sur les événements et le temps. En intégrant le temps et les exigences de commande, l'abstraction de la chronologie permet aux requêtes temporelles d'exprimer intuitivement la cause et l'effet.
Les chronologies sont l'abstraction utilisée dans Kaskada pour créer des requêtes temporelles, mais les données commencent et se terminent en dehors de Kaskada. Il est important de comprendre le flux de données depuis l'entrée, jusqu'aux délais et enfin jusqu'à la sortie.
Chaque requête démarre à partir d'une ou plusieurs sources de données d'entrée. Chaque entrée - qu'il s'agisse d'événements arrivant dans un flux ou stockés dans une table, ou de faits stockés dans une table - peut être convertie en une chronologie sans perdre de contexte important tel que l'heure de chaque événement.
La requête elle-même est exprimée sous la forme d'une séquence d'opérations. Chaque opération crée une chronologie à partir de chronologies. Le résultat de l'opération finale est utilisé comme résultat de la requête. Ainsi, la requête produit une chronologie qui peut être discrète ou continue.
Le résultat d'une requête est une chronologie, qui peut être envoyée à un récepteur. Les lignes écrites dans le récepteur peuvent être un historique reflétant les modifications dans une chronologie ou un instantané reflétant les valeurs à un moment précis.
Avant l'exécution d'une requête, chaque entrée est mappée sur une chronologie. Chaque entrée - qu'il s'agisse d'événements d'un flux ou d'une table ou de faits dans une table - peut être mappée à une chronologie sans perdre les informations temporelles importantes, telles que le moment où les événements se sont produits. Les événements deviennent des chronologies discrètes, avec la ou les valeurs de chaque événement se produisant au moment de l'événement. Les faits deviennent des chronologies continues, reflétant le temps pendant lequel chaque fait s'est appliqué. En représentant sans perte toutes sortes d'entrées temporelles, les chronologies permettent aux requêtes de se concentrer sur le calcul plutôt que sur le type d'entrée.
Après l'exécution d'une requête, la chronologie résultante doit être sortie vers un système externe pour être consommée. Le récepteur de chaque destination permet de configurer l'écriture des données, avec des spécificités selon le récepteur et la destination (voir
Il existe plusieurs options pour convertir la chronologie en lignes de données, affectant le nombre de lignes produites :
Un historique complet des modifications permet de visualiser ou d'identifier des tendances dans les valeurs utilisateur au fil du temps. En revanche, un instantané à un moment précis est utile pour les tableaux de bord en ligne ou la classification d'utilisateurs similaires.
L'inclusion d'événements après un certain temps réduit la taille de sortie lorsque la destination contient déjà des données jusqu'à ce moment ou lorsque des points antérieurs ne sont pas pertinents. Ceci est particulièrement utile lors de la réexécution d'une requête pour la matérialiser dans un magasin de données.
L'inclusion d'événements jusqu'à une heure spécifique limite également la taille de la sortie et permet de choisir un instantané à un instant donné. Avec l'exécution incrémentielle, la sélection d'une heure légèrement antérieure à l'heure actuelle réduit le traitement tardif des données.
Les options "changé depuis" et "jusqu'à" sont particulièrement utiles avec l'exécution incrémentielle, dont nous parlerons dans un prochain article.
L'historique - l'ensemble de tous les points de la chronologie - est utile lorsque vous vous souciez des points passés. Par exemple, cela peut être nécessaire pour visualiser ou identifier des modèles dans la façon dont les valeurs de chaque utilisateur changent au fil du temps. L'historique est particulièrement utile pour produire des exemples de formation à utiliser pour créer un modèle.
Toute chronologie peut être sortie sous forme d'historique. Pour une chronologie discrète, l'historique est l'ensemble des événements de la chronologie. Pour une chronologie continue, l'historique contient les points auxquels une valeur change - il s'agit en fait d'un journal des modifications.
Un instantané - la valeur de chaque entité à un moment précis - est utile lorsque vous ne vous souciez que des dernières valeurs. Par exemple, lors de la mise à jour d'un tableau de bord ou du remplissage d'un magasin de fonctionnalités pour se connecter à la diffusion de modèles.
Toute chronologie peut être sortie sous forme d'instantané. Pour une chronologie discrète, l'instantané inclut des lignes pour chaque événement qui se produit à ce moment-là. Pour une chronologie continue, l'instantané inclut une ligne pour chaque entité avec la valeur de cette entité à ce moment-là.
Ce billet de blog a souligné l'importance des caractéristiques temporelles lors de la création de modèles ML à partir de données basées sur des événements. Le contexte temporel et temporel des événements est essentiel pour voir les modèles d'activité. Ce billet a introduit l'abstraction de la chronologie, qui permet de travailler avec les événements et le contexte temporel. Les chronologies organisent les données par heure et par entité, offrant une structure plus adaptée aux données basées sur les événements par rapport aux multisets.
L'abstraction de la chronologie est une progression naturelle dans le traitement des flux, vous permettant de raisonner plus efficacement sur le temps et les relations de cause à effet. Nous avons également exploré le flux de données dans une requête temporelle, de l'entrée à la sortie, et discuté des différentes options de sortie des chronologies vers des systèmes externes.
Plutôt que d'appliquer une requête tabulaire (statique) à une séquence d'instantanés, Kaskada opère sur l'historique (le flux de modifications). Cela rend naturel d'opérer sur le temps entre les instantanés, plutôt que seulement sur les données contenues dans l'instantané. L'utilisation de chronologies comme abstraction principale simplifie le travail avec des données basées sur des événements et permet des transitions transparentes entre les flux et les tables.
Tu peux
Par Ben Chambers et Therapon Skoteiniotis, DataStax