View
368
Download
14
Category
Preview:
Citation preview
Paris Apache Kafka Meetup
Hervé RIVIEREZenika
@_rv_
hriviere
Source : confluent.io
Ingestion … alimentation !
Script / application java “home made” avec des producers et/ou consumers
Avantage : flexibilité
Inconvénients : Pas toujours trivial, loadbalancing ?, fail over ?, standard de développement ?
Source : xkcd
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
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
Utiliser Kafka Connect !
Avantages :• Déjà inclus dans Kafka
• Connecteurs déjà implémentés ou possibilité d’écrire les siens
• Mutualisation configuration / runtimedes connecteurs
• Introduit des standard de développements / utilisation
• Profite de l’ensembles des fonctionnalités de Kafka (fail-over / loadbalancing…)
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
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
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
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 )
DEMO !
https://github.com/hriviere/demo-kafka-connect-streams
Transformer !
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)
• 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
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)
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
• 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
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
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
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
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
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 Ktablesynchronisée, consommation des messages de la partition 2
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
DEMO !
https://github.com/hriviere/demo-kafka-connect-streams
Source : confluent.io
Recommended