Kafka Connect & Kafka Streams - Paris Kafka User Group 05/18/2016 http://www.meetup.com/fr-FR/Paris-Apache-Kafka-Meetup/events/230324870/ Code : https://github.com/hriviere/demo-kafka-connect-streams

1. Paris Apache Kafka
Meetup
Hervé RIVIERE
Zenika
@_rv_
hriviere

2. Source : confluent.io

3. Ingestion … alimentation !

5. Script / application java “home made” avec
des producers et/ou consumers
Avantage : flexibilité
Inconvénients : Pas toujours trivial, load
balancing ?, fail over ?, standard de
développement ?
Source : xkcd

6. Utiliser un connecteur spécifique déjà
existant (connecteur Elastic, Camus….)
ou un ETL (Talend…)
Avantage : plug & play !
Inconvénients : Pas de standard,
chaque connecteur doit être installé /
configuré / monitoré spécifiquement
Source : xkcd

7. Utiliser Spark (streaming), Storm,
Samza…
Avantages : Fail over, load balancing
Inconvénients : Un nouveau cluster à
installer, connaissance du framework,
luxueux pour de l’ingestion de données
?
Source : made-in-bed-productions.tumblr.com

8. Utiliser Kafka Connect !
Avantages :
• Déjà inclus dans Kafka
• Connecteurs déjà implémentés ou
possibilité d’écrire les siens
• Mutualisation configuration / runtime
des connecteurs
• Introduit des standard de
développements / utilisation
• Profite de l’ensembles des
fonctionnalités de Kafka (fail-over / load
balancing…)

9. Depuis Kafka 0.9+ (déjà inclus dans la distribution)
Comprend :
• Des API (interfaces Java)
• Moteurs d’exécution (standalone ou cluster)
• Service REST de monitoring

10. 2x2 interfaces Java : SourceConnector, SourceTask / SinkConnector, SinkTask
Créer un connecteur : implémenter le couple interface Source et /
ou Sink
Load balancing, failover, offset déjà partiellement implémentés (on
indique le comportement)
Pas envie de coder ? : utiliser une implémentation « officielle »
http://www.confluent.io/developers/connectors

11. Standalone : une instance du connecteur (java –cp …)
Usage : test, lecture / et ou écriture d’un fichier sur un nœud spécifique
Cluster : N instances du connecteur sur N nœuds
Usage : Fail-over / load balancing
Exemple : Ecriture d’un topic vers HDFS en HA
Prérequis : Démarrer des workers Kafka Connect pour constituer le cluster

12. En mode cluster :
Pas de maitre-esclave
Déploiement des connecteurs sur les workers via service REST
• Indication nom de la classe
• Nombre d’instance voulue
• Configuration
Utilisation en arrière-plan des consumer groups (cf. présentation
précédente  )

13. DEMO !
https://github.com/hriviere/demo-kafka-connect-streams

14. Transformer !

16. Kafka Streams Spark streaming, Flink , Storm ...
Outils nécessaires Kafla uniquement Kafka + cluster Spark ou Flink ou Storm ou
….
Connaissances requise Kafka + API Kafka Streams Kafka + API framework + comportement
framework (config., HA….)
Gestionnaire de ressource NON OUI
Déploiement Une ou plusieurs application java (java -jar….)
Uniquement Java est requis
Via le cluster du framework
Usage de Kafka • Source / cible / données intermédiaires /
metadata
• Topics « classiques », topics compactés et topic
avec une unique partition
• Source et cible uniquement
• Généralement des topics « classiques »
partitionnés
Et Samza ? : Kafka Streams ≈ Samza sans gestionnaire de ressource (même philosophie)

17. • Même projet que Kafka
• A partir de Kafka 0.10 (release prévue pour dans quelques
semaines). Directement dans distribution Kafka
• Tech preview disponible sur http://www.confluent.io/developer#streamspreview
Kafka 0.10 actuellement en release candidate
A utiliser à vos risques et périls 

18. Clé Valeur
Lundi 1
Jeudi 4
Lundi 2
Vendredi 3
Lundi 2
• Kstreams : Transformation map ou filter sur un flux
de données
• Pas d’agrégation
• Pas d’état conservé
KStream<String, Long> stream = builder.stream(new StringDeserializer(), new LongDeserializer(), "semaine"):
KStream<String, Long> lundiStream = stream.filter((k, v) -> k.equals("lundi"));
lundiStream.to("lundi-stream");
Topic lundi-stream : (lundi,1), (lundi,2), (lundi,2)

19. Clé Valeur
Lundi 1
Jeudi 4
Lundi 2
Vendredi 3
Lundi 2
• KTables :
• Transformation d’agrégation sur un KStream
• Conservation d’un état
• Possibilité de réaliser des fenêtre glissante
KTable<String, Long> tableJour = stream.countByKey(new DeSererializer(), "table-jours");
tableJour.to("comptage-jours");
Topic comptage-jour : (Lundi, 1))
Clé Value
Lundi
Jeudi
Vendredi
(Jeudi, 1) (Lundi, 2) (Vendredi, 1) (Lundi, 3)
1
1
3

20. • Pour permettre parallélisme : autant de KTables que de partitions du topic
source !
• Persistance des KTables via des Stores
• In-Memory
• RocksDB (runtime) + topic compacté  Par défaut
• Sa propre implémentation
• Au démarrage de l’application, les stores retrouvent leurs états via le topic de
sauvegarde
• Si fenêtre glissante : uniquement les données nécessaires conservées

21. Topic source
Partition 1
Partition 2
Nœud 1
Nœud 2
Topic Cible
Partition 1
Partition 2
Partition 3
Partition 1
Partition 2
Topic de sauvegarde des KTables

22. Topic source
Partition 1
Partition 2
Nœud 1
Nœud 2
Topic Cible
Partition 1
Partition 2
Partition 3
Partition 1
Partition 2
Topic de sauvegarde des KTables

23. Topic source
Partition 1
Partition 2
Nœud 1
Topic Cible
Partition 1
Partition 2
Partition 3
Partition 1
Partition 2
Topic de sauvegarde des KTables
Instanciation du KTable du
nœud 2 sur le nœud 1

24. Topic source
Partition 1
Partition 2
Nœud 1
Topic Cible
Partition 1
Partition 2
Partition 3
Partition 1
Partition 2
Topic de sauvegarde des KTables
Le KTable recharge son
état grâce à la partition du
topic de sauvegarde

25. Topic source
Partition 1
Partition 2
Nœud 1
Topic Cible
Partition 1
Partition 2
Partition 3
Partition 1
Partition 2
Topic de sauvegarde des KTables
Une fois la Ktable
synchronisée,
consommation des
messages de la partition 2

26. Topic source
Partition 1
Partition 2
Nœud 1
Nœud 2
Topic Cible
Partition 1
Partition 2
Partition 3
Partition 1
Partition 2
Topic de sauvegarde des KTables

27. DEMO !
https://github.com/hriviere/demo-kafka-connect-streams

28. Source : confluent.io