BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Les Défis du Stream Processing et de l’Architecture Lambda

Les Défis du Stream Processing et de l’Architecture Lambda

Favoris

Kartik Paramasivam, qui travaille sur l'infrastructure des flux à LinkedIn, a écrit deux articles durant l'été sur pourquoi et comment son entreprise tente d'éviter l'architecture Lambda en utilisant Apache Samza pour le traitement des données.

Les technologies de traitements de flux sont utiles quand il est question d’obtenir des résultats rapides sur des flux de données, mais qui risquent de s'effondrer rapidement pour des cas d'utilisation qui exigent une grande cohérence et des besoins en robustesse.

L'architecture Lambda a été une solution populaire qui combine les batchs et les traitements de flux. L'idée fondamentale est d'avoir deux voies de données séparées : une couche de traitement rapide pour fournir des résultats à faible latence en utilisant des technologies de traitements de flux et une couche de traitement par batch pour exécuter les tâches lourdes et fournir des résultats précis sur les données en vrac. L'architecture Lambda est complexe à mettre en œuvre car elle repose sur de multiples technologies et implique la fusion des résultats des deux voies de données.

À LinkedIn, Samza est utilisé pour effectuer le traitement des données reçus à partir d’Apache Kafka. Un des problèmes décrits dans l'article est l'arrivée tardive des événements. La base clé/valeur, RocksDB, a été ajouté à Samza pour garder plus de temps les événements en entrée. Sur une arrivée tardive, le framework va réémettre n’importe quel résultat relatif sur la base de la fenêtre de calcul, étant donné qu'il y a assez d'informations au niveau local pour les recalculer. Une solution basée sur RocksDB a été jugée préférable, étant donnée que compter sur une base externe (NoSQL par exemple) signifierait une surcharge du réseau et du CPU pour la communication et la sérialisation.

Apache Flink, un autre framework de traitement de flux, est capable de calculer sur des fenêtres temporelles basées sur les timestamps, et qui peuvent être des événements spécifiques ou un timestamp d’ingestion, et de fournir des résultats cohérents pour les flux out-of-order. Il détient les données en mémoire et déclenche la fenêtre de calcul à la réception d'un événement watermark. Watermarks représentent un coup d'horloge et fournit à Flink une notion de temps (qui peut être un événement spécifique).

D'autres problèmes, tels que le traitement des messages dupliqués en raison d'au moins une fois la livraison des garanties, ont été prises en compte par la plupart des frameworks avec des mécanismes de point de contrôle interne.

La dernière série de problèmes de traitement de flux est la capacité d'expérimenter avec des données vu qu'ils circulent à travers le système d’une manière interactive. L'expérimentation agile est généralement réalisée sur les systèmes de traitement par lots en utilisant des langages de haut niveau tels que le SQL, disponibles sur des produits commerciaux comme Azure Stream Analytics.

Samza SQL est décrit par Julian Hyde comme un effort qui applique Apache Calcite au processeur de flux Samza. Samza SQL n’est pas encore prêt pour la mise en production. Au lieu de cela, LinkedIn utilise Hadoop batch nature pour effectuer des expérimentations itératives avec des jeux de données en mode offline, certains copiés à partir des mêmes services de bases de données actives que les processeurs de flux basés Samza requêtent lors de la manipulation d'un flux.

Flink travaille également pour un support robuste des flux SQL. La 1.1 de Flink, sortie en août 2016, prend en charge les filtres et les unions sur des flux de données. Flink prend également en charge le traitement des événements complexes comme une description de haut niveau sur la manière de réagir suite à des séquences d'événements.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT