Pourquoi les flux dans Orleans ?

Il existe déjà un large éventail de technologies pour la création de systèmes de traitement de flux. Il s’agit notamment de systèmes permettant de stocker durablement des données de flux (par exemple, Event Hubs et Kafka) et des systèmes pour exprimer des opérations de calcul sur des données de flux (par exemple, Azure Stream Analytics, Apache Storm et Apache Spark Streaming). Il s’agit d’excellents systèmes qui vous permettent de créer des pipelines de traitement de flux de données efficaces.

Limitations des systèmes existants

Toutefois, ces systèmes ne conviennent pas au calcul de forme libre fine sur les données de flux. Les systèmes de calcul de streaming mentionnés ci-dessus vous permettent de spécifier un graphique unifié de flux de données des opérations appliquées de la même façon à tous les éléments de flux. Il s’agit d’un modèle puissant lorsque les données sont uniformes et que vous souhaitez exprimer le même ensemble de transformation, de filtrage ou d’opérations d’agrégation sur ces données. Toutefois, d’autres cas d’usage nécessitent l’expression d’opérations fondamentalement différentes sur différents éléments de données. Dans certains de ces cas, dans le cadre du traitement, vous devrez peut-être parfois effectuer un appel externe, par exemple appeler une API REST arbitraire. Les moteurs de traitement de flux de données unifiés ne prennent pas en charge ces scénarios, les prennent en charge de manière limitée et limitée, ou sont inefficaces pour les prendre en charge. Cela est dû au fait qu’ils sont intrinsèquement optimisés pour un grand volume d’éléments similaires et sont généralement limités en termes d’expressivité et de traitement. Orleans Les flux ciblent ces autres scénarios.

Motivation

Tout a commencé avec les demandes des Orleans utilisateurs pour prendre en charge le renvoi d’une séquence d’éléments à partir d’un appel de méthode grain. Comme vous pouvez l’imaginer, ce n’était que l’extrémité de l’iceberg ; ils avaient beaucoup plus besoin.

Un scénario classique pour Orleans les flux est lorsque vous avez des flux par utilisateur et que vous souhaitez effectuer un traitement différent pour chaque utilisateur dans le contexte de cet utilisateur individuel. Vous pouvez avoir des millions d’utilisateurs, mais certains s’intéressent à la météo et s’abonnent à des alertes météorologiques pour un emplacement particulier, tandis que d’autres sont intéressés par les événements sportifs ; quelqu’un d’autre peut suivre l’état d’un vol particulier. Le traitement de ces événements nécessite une logique différente, mais vous ne souhaitez pas exécuter deux instances indépendantes de traitement de flux. Certains utilisateurs peuvent s’intéresser uniquement à un stock particulier et uniquement si une condition externe s’applique, une condition qui peut ne pas nécessairement faire partie des données de flux (et nécessite donc de vérifier dynamiquement au moment de l’exécution dans le cadre du traitement).

Les utilisateurs modifient leurs intérêts tout le temps, de sorte que leurs abonnements à des flux d’événements spécifiques viennent et passent dynamiquement. Ainsi, la topologie de diffusion en continu change dynamiquement et rapidement. En outre, la logique de traitement par utilisateur évolue et change dynamiquement en fonction de l’état utilisateur et des événements externes. Les événements externes peuvent modifier la logique de traitement d’un utilisateur particulier. Par exemple, dans un système de détection de tricherie d’un jeu, lorsqu’une nouvelle méthode de tricherie est découverte, la logique de traitement doit être mise à jour avec la nouvelle règle pour détecter cette violation. Cela doit être fait, bien sûr, sans perturber le pipeline de traitement en cours. Les moteurs de traitement de flux de données en bloc n’ont pas été conçus pour prendre en charge ces scénarios.

Cela va presque sans dire qu’un tel système doit s’exécuter sur plusieurs machines connectées au réseau, pas seulement un seul nœud. Par conséquent, la logique de traitement doit être distribuée de manière scalaire et élastique sur un cluster de serveurs.

Nouvelles exigences

Quatre exigences de base ont été identifiées pour qu’un système de traitement de flux cible les scénarios ci-dessus :

1. Logique de traitement de flux flexible
2. Prise en charge des topologies hautement dynamiques
3. Granularité de flux affinée
4. Répartition

Logique de traitement de flux flexible

Le système doit prendre en charge différentes façons d’exprimer la logique de traitement de flux. Les systèmes existants mentionnés ci-dessus nécessitent que les développeurs écrivent un graphique de calcul de flux de données déclaratif, généralement en suivant un style de programmation fonctionnel. Cela limite l’expressivité et la flexibilité de la logique de traitement. Orleans les flux sont indifférents à la façon dont la logique de traitement est exprimée. Il peut être exprimé sous la forme d’un flux de données (par exemple, à l’aide d’extensions réactives (Rx) dans .NET), d’un programme fonctionnel, d’une requête déclarative ou d’une logique impérative générale. La logique peut être avec état ou sans état, peut ou non avoir des effets secondaires et déclencher des actions externes. Tout le pouvoir va au développeur.

Prise en charge des topologies dynamiques

Le système doit permettre l’évolution dynamique des topologies. Les systèmes existants mentionnés ci-dessus sont généralement limités aux topologies statiques fixes au moment du déploiement qui ne peuvent pas évoluer au moment de l’exécution. Dans l’exemple suivant d’une expression de flux de données, tout est agréable et simple jusqu’à ce que vous deviez le modifier :

Stream.GroupBy(x=> x.key).Extract(x=>x.field).Select(x=>x+2).AverageWindow(x, 5sec).Where(x=>x > 0.8) *

Modifiez la condition de seuil dans le Where filtre, ajoutez une Select instruction ou ajoutez une autre branche dans le graphique de flux de données et produisez un nouveau flux de sortie. Dans les systèmes existants, cela n’est pas possible sans détruire la topologie entière et redémarrer le flux de données à partir de zéro. En pratique, ces systèmes réalisent un point de contrôle du calcul existant et peuvent redémarrer à partir du dernier point de contrôle. Toutefois, un tel redémarrage est perturbant et coûteux pour un service en ligne produisant des résultats en temps réel. Un tel redémarrage devient particulièrement impraticable lorsqu’il s’agit d’un grand nombre d’expressions exécutées avec des paramètres similaires mais différents (par utilisateur, par appareil, etc.) qui changent continuellement.

Le système doit autoriser l’évolution du graphique de traitement de flux au moment de l’exécution en ajoutant de nouveaux liens ou nœuds au graphique de calcul ou en modifiant la logique de traitement au sein des nœuds de calcul.

Granularité de flux affinée

Dans les systèmes existants, la plus petite unité d’abstraction est généralement l’ensemble du flux (topologie). Toutefois, de nombreux scénarios cibles nécessitent un nœud/lien individuel dans la topologie pour être une entité logique elle-même. De cette façon, chaque entité peut potentiellement être gérée indépendamment. Par exemple, dans une topologie de flux volumineux comprenant plusieurs liens, différents liens peuvent avoir différentes caractéristiques et être implémentés sur différents transports physiques. Certains liens peuvent passer par des sockets TCP, tandis que d’autres utilisent des files d’attente fiables. Différents liens peuvent avoir des garanties de livraison différentes. Différents nœuds peuvent avoir différentes stratégies de point de contrôle, et leur logique de traitement peut être exprimée dans différents modèles ou même dans différents langages. Cette flexibilité n’est généralement pas possible dans les systèmes existants.

L’unité d’abstraction et d’argument de flexibilité est similaire à la comparaison de SoA (Architectures orientées services) par rapport aux acteurs. Les systèmes d’acteur permettent une plus grande flexibilité, car chaque acteur est essentiellement un « service minuscule » géré indépendamment. De même, le système de flux doit permettre un tel contrôle affiné.

Répartition

Et bien sûr, le système doit avoir toutes les propriétés d’un « bon système distribué ». Cela inclut :

1. Scalabilité : prend en charge un grand nombre de flux et d’éléments de calcul.
2. Élasticité : permet d’ajouter/de supprimer des ressources pour augmenter/réduire en fonction de la charge.
3. Fiabilité : résilient aux défaillances.
4. Efficacité : utilise efficacement les ressources sous-jacentes.
5. Réactivité : active des scénarios quasiment en temps réel.

Il s’agissait des exigences de configuration pour la mise en place Orleans du streaming.

Clarification : Orleans actuellement, ne prend pas directement en charge l’écriture d’expressions de flux de données déclaratives comme dans l’exemple ci-dessus. Les API de streaming actuelles Orleans sont des blocs de construction de bas niveau, comme décrit dans Orleans les API de streaming.

Voir aussi

Orleans API de programmation de flux