Sergey Nivens - Fotolia
Neha Narkhede, CTO de Confluent : « Kafka est une plateforme complète pour le streaming de données »
Cela a démarré par un bus de messages pour gérer les données en volume chez LinkedIn. Aujourd’hui, Kafka, et ses capacités de streaming, soutiennent nombre de projets dans l’industrie. Entretien avec Neha Narkhede, qui faisait partie de l’équipe de développement chez LinkedIn, aujourd’hui CTO de Confluent.
En tant que membre de l’équipe dédiée aux données chez LinkedIn, Neha Narkhede a joué un rôle clé dans la création du système de messages distribué Kafka. Celui-ci est aujourd’hui un projet Open Source Apache et s’est enrichi de capacités de traitement de données en streaming. Il se positionne comme l’un des frameworks les plus utilisés du moment lorsqu’on évoque le traitement de données.
Avec Jay Krebs, qui était architecture logiciel chez LinkedIn, Neha Narkhede a depuis créé la société Confluent, justement spécialisée dans les développements sur Kafka. Nous nous sommes entretenus avec elle, aujourd’hui CTO de Confluent, alors que la société prépare actuellement le Kafka Summit qui se tiendra le mois prochain à San Francisco.
Pouvez-vous nous raconter la genèse de Kafka et de Kafka Streaming ?
Neha Narkhede : lorsque j’ai rejoint LinkedIn, nous étions en phase de croissance. L’infrastructure avait du mal à tenir, elle n’était pas dimensionnée pour les millions d’utilisateurs du service.
L’autre point à noter est que LinkedIn est une société très portée sur la donnée. Exploiter nos données en temps réel était fréquent chez nous. Le problème : nous avions beaucoup de données générés par nos utilisateurs et nous souhaitions les traiter rapidement pour alimenter ensuite les systèmes en aval.
Comme les autres entreprises, nous avions mis en place Hadoop et toutes ces bases distribuées. Le problème était alors de comment s’y prendre pour avoir un unique système qui livre une « seule vision de la vérité » et d’être capable de traiter des données en temps réel. A l’époque, il n’y avait pas beaucoup de solutions.
Il existait certes des systèmes de messaging temps réel, mais ils ne pouvaient pas être dimensionnés. Il existait des ETL qui pouvaient passer à l’échelle, mais pas de temps réel au programme. Un problème compliqué que finalement personne ne voulait vraiment résoudre. C’est pourquoi nous avons développé Kafka. Nous pensions que cela pouvait répondre à nos questions chez LinkedIn mais aussi être utile à d’autres entreprises.
Quels étaient les premiers principes de Kafka ?
Neha Narkhede : si vous regardez de près Kafka, cela ressemble beaucoup à un système de log distribué à grande échelle, très similaire à un back-end de base de données, mais également construit comme un système distribué pratique.
Avant Kafka, il y avait une limite : seules les informations créées par des humains pouvaient être traitées en temps réel car la fréquence avec laquelle les humains créent de l’information est bien moins élevée que celle des machines.
Cela était également lié aux transformations importantes mises en place par les entreprises, et leur volonté d’embrasser davantage le numérique – comme collecter l’information de l’IoT ou des machines pour contrôler l’IT par exemple. Le volume de données n’était largement plus élevé que celui provenant des humains. Il s’agit d’appréhender des données qui vous arrivent à un rythme difficilement imaginable – et Kafka est fait pour ce genre de traitement.
Nous avons commencé avec des personnes qui avaient de l’expérience dans les systèmes distribués et les bases de données. Cela comprenait des personnes qui avaient gouté les anciens systèmes de traitement en streaming et connaissaient bien leurs défauts. Nous nous sommes alors interrogés sur ce que pourrait être les fondations de ce système, à quoi il devait ressembler. Il s’est avéré que de nombreuses réponses partaient de principes du monde des bases de données appliqués aux systèmes distribués.
L’Open Source est une façon d’avoir l’attention des développeurs. Que se passe-t-il ensuite pour une entreprise qui décide de monter un modèle sur la technologie ?
Neha Narkhede : lorsque nous avons monté Confluent, les deux premiers domaines auxquels nous nous sommes attelés étaient le stream processing et les pipelines de données en streaming. Avec l’API Kafka Streams, nous avons travaillé à créer un moteur de stream processing qui fait désormais partie du projet Apache. Les pipelines permettent de connecter des systèmes à Kafka ; nous avons donc investi dans KafKa Connect API. Si aujourd’hui, vous regardez Kafka, vous vous rendrez compte qu’il a évolué vers une plateforme complète de streaming.
Avec l’Open Source, les développeurs peuvent décider de tester Kafka. Cela n’est pas difficile. Puis, lorsqu’ils entrent en production, ils peuvent utiliser des éléments qui se trouvent dans notre édition entreprise. Ils ont besoin d’outils de gestion et de monitoring. Ils ont également besoin d’une interface utilisateur pour visualiser les millions de messages qui passent par le système. Ils doivent également connaître l’état de santé de leur implémentation de Kafka.
L’autre point est que toutes les entreprises sont aujourd’hui « étendues », qu’elles soient distribuées géographiquement sur plusieurs datacenters, ou via en associant applications sur site et implémentations Cloud. Dans ce cas, Kafka est utilisé comme un bus de données en temps réel ou comme une passerelle vers le Cloud. L’édition Confluent Enterprise contient Replicator, qui permet de créer ce pont entre datacenters. Nous proposons également un service à l’abonnement qui comprend du support et de la formation, ainsi que des possibilités d’hébergement pour les entreprises qui veulent tout dans le Cloud.