Multimodales Gestion des Données Frugales – POLYFLOW

Le besoin d'adresser la variété des données a ouvert la voie à la conception des bases de données multiples. Les multi-bases de données incluent les multistores, qui exposent une interface de requête déclarative unifiées sur des données hétérogènes, ainsi que les polystores qui combinent les avantages des multistores avec l'interrogation polyglotte, c'est-à-dire ils exposent plusieurs interfaces de requête sur des modèles de données hétérogènes. Les deux types de bases de données visent à avoir une vue uniforme sur des données hétérogènes en réduisant les tâches ETL demandées.

La disponibilité croissante des réseaux de capteurs et des microservices a récemment poussé à la montée en puissance des données en continu en tant qu'abstraction commune. Pour les multi-bases de données, les flux de données représentent un moyen d'ingestion rapide qui permet d'exécuter des analyses à faible latence avec un moteur spécialisé, c'est-à-dire le Data Stream Management System (DSMS). Cependant, "une taille unique ne convient pas à tous" pour les DSMS également. Le traitement de flux de données hétérogènes en temps réel est possible, mais il nécessite des efforts de programmation importants pour adresser le problème d'intégration des données. Même lorsque des langages déclaratifs existent, l'absence d'une théorie d'intégration de données en continu impose des hypothèses fortes pour fusionner des différentes sources.

Les progrès de la gestion des données multi-modèles et l'apparition des données en streaming suggèrent que les temps sont mûrs pour un changement de paradigme qui permette une gestion des données en streaming multi-modèles et polyglottes (ci-après polystreaming). En particulier, nous observons que:

O1) Les flux de données émergent comme une abstraction naturelle pour unifier des systèmes de données spécialisés. Les systèmes d'ingestion de streaming comme Kafka sont indépendants du modèle de données, c'est-à-dire qu'ils garantissent une latence de bout en bout indépendamment du mécanisme de sérialisation. A l'inverse, les DSMS dépendent toujours du modèle de données. En effet, les flux de données ont des caractéristiques différentes, et ainsi, le choix du modèle de données peut simplifier l'analyse. Par exemple, un flux relationnel suggère la présence de clés et de dépendances fonctionnelles, tandis que les flux de graphes conseillent une plus grande flexibilité du schéma.

O2) À mesure que les données en continu deviennent de plus en plus sophistiquées, les DSMS évoluent pour faire face à la variété des données. Par exemple, des systèmes comme Flink et Spark sont polyglottes. Ils exposent une hiérarchie d'API progressivement plus flexibles mais plus complexes.

O3) Les capacités des DSMS vont au-delà de l'analyse traditionnelle. Certains DSMS offrent de solides garanties de cohérence qui peuvent conduire à la prise en charge de transactions, d'états interrogeables et même de fonctions avec état. Par exemple, Apache Flink et Kafka Streams prennent en charge Exactly-Once-Semantics, ce qui signifie que même si un événement peut être envoyé plus d'une fois à la vue du récepteur, les effets seront les mêmes que s'il avait été traité précisément une fois. Certains DSMS prennent en charge des calculs itératifs avancés que les utilisateurs peuvent exploiter pour l'analyse de graphes en continu ou l'apprentissage automatique.

Enfin, O4) les initiatives émergentes industrielles et académiques pour une interface DSMS unifiée comme Calcite, Beam et RSP4J signalent le besoin d'une solution intégrée.

PolyFlow vise à exploiter ces opportunités pour construire une nouvelle génération de systèmes de données, à savoir les systèmes de polystreaming, qui élisent les DSMS pour le traitement runtime. PolyFlow appelle des objectifs de recherche à la fois fondamentaux et empiriques : OB1) l'intégration de langages déclaratifs pour l'interrogation continue ainsi que OB2) la conception et la gestion efficace des systèmes de polystreamin