Introduction

Pour ceux qui ne connaissent pas du tout Apache Kafka, voici d’abord une présentation :

Apache Kafka – Genèse, Concepts et Fonctionnement du message-broker du Big Data

Au-delà de l’ETL et du Bus d’Entreprise

Initialement, Kafka n’est donc pas une plateforme, mais un « simple » système de messagerie distribué (un broker).
Mais depuis que cet outil (né dans les locaux de LinkedIn) a été repris par la fondation Apache, un certain nombre d’outils sont venus ajouter de nouvelles fonctionnalités pour en faire aujourd’hui une véritable plateforme.

Architecture

Au-delà de Kafka broker, Kafka Connect et Kafka Streams viennent compléter l’offre pour en faire une plateforme d’intégration complète :

L’entreprise Confluent (créée par des anciens employés de LinkedIn, et dont les solutions sont basées sur Kafka) propose un large panel technologique de connecteurs certifiés (voir https://www.confluent.io/product/connectors/) :

Unification des flux par les logs

Le log est la structure de données qui est au cœur du concept de Kafka.
Pour le décrire, on pourrait le comparer à une file/queue de messages.
Mais la différence est que pour un log, un message lu n’est pas automatiquement dépilé de la structure de données dès lors qu’il est consommé.

Un offset accompagne chaque message, faisant office de curseur pour chaque consommateur de message.
D’une manière générale, on ne parle ni de flux ETL (Extract Tranform Load), ni de flux batch, mais de « Stream ».
Le « Stream » est une notion unifiée des flux batchs et temps réel.
On peut consommer les logs en batch en augmentant la « fenêtre » de consommation grâce à l’offset.

Repenser l’ETL

Prenons l’exemple d’un flux ETL qui extrait des données d’une base Oracle.
Dans ce cas, nous utiliserons le connecteur Oracle GoldenGate grâce à Kafka Connect :

Ainsi, les données vont transiter sous forme de flux continu.
Le traitement batch devient donc obsolète, laissant sa place à un flux « fil de l’eau ».
L’intérêt est donc de rendre disponibles les données sur l’environnement cible dans un délai de quasi temps réel, tant les outils intermédiaires sont performants.
Cela n’empêche pas pour autant de traiter les données de manière ensembliste, c’est au niveau de Kafka Streams que les transformations seront réalisées.
Par ailleurs, les traitements batchs sont souvent privilégiés dans le but de mettre en place des traitements de masse qui sont programmés en heures creuses, afin de ne pas créer d’overhead sur les environnements de Production.
Donc, on peut se poser la question de savoir si le fait de transformer ces flux batchs en flux temps réel ne va pas nuire aux performances de l’activité de Production.
La réponse est non, puisque les connecteurs proposés par Kafka Connect sont étudiés pour ne pas solliciter directement les ressources de Production, à l’image d’Oracle GoldenGate par exemple (schéma ci-dessus) qui exploite les transactions DML des Archive Logs.

Une alternative au Bus d’Entreprise

Le Bus d’Entreprise est généralement mis en place dans les entreprises lorsque le besoin est de router des messages d’un flux temps réel, sans intelligence/complexité de traitement.
Ces flux sont généralement Stateless, avec pas ou peu d’emprunte d’exécution, ce qui explique leur hautes performances.
L’avantage de Kafka est qu’il offre des performances du même niveau que le bus (haute performance donc), mais avec une persistance des messages sur disque, offrant ainsi la possibilité de rejouer les flux à l’infini (selon le paramétrage du niveau de rétention de l’historique conservé dans le log).
Les performances extrêmement élevées de Kafka représentent une prouesse technologique au vu des débits mesurés par rapport aux autres solutions connues (RabbitMQ par exemple).

Les outils de Design

Contrairement aux suites logicielles historiques de l’univers middleware, les solutions s’appuyant sur Kafka ne proposent pas encore d’interface de développement user-friendly telle que le proposent les ETL d’aujourd’hui (Oracle Data Integrator, Talend, Stambia, etc.) ou les suites SOA/ESB (Oracle Fusion Middleware, etc.).
Pour l’instant, tout travail est réalisé à base de lignes de commandes et lignes de code, mais les outils graphiques manquent encore à l’appel.

Coût

Kafka, Streams et Connect appartiennent désormais à la fondation Apache et sont des produits gratuits et open source.
Néanmoins, des offres commerciales existent (intégrant notamment un support 24/7), afin de s’adapter au monde de l’entreprise.
Le coût de ces offres commerciales sont difficiles à trouver publiquement.
Il faut généralement demander des devis personnalisés.
La version 100% gratuite et open source permet dans tous les cas d’expérimenter la solution avec toutes ses fonctionnalités.
Le côté open source permet même de personnaliser la solution par rapport à nos besoins.

Conclusion

Une plateforme middleware basée sur Apache Kafka permet donc à priori de pouvoir répondre à tous les besoins.
Néanmoins, pour se développer encore auprès des moyennes entreprises, les solutions proposées autour de cette technologie devront fournir des outils graphiques pour permettre à des non-développeurs de concevoir des flux inter-applicatifs facilement.
Car pour l’instant, cette solution nécessite de disposer de développeurs techniquement pointus, ce qui ajoute une barrière intermédiaire entre le produit et les équipes métiers.