Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Kafka Connect & Kafka Streams - Paris Kafka User Group

521 views

Published on

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

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

Kafka Connect & Kafka Streams - Paris Kafka User Group

  1. 1. Paris Apache Kafka Meetup Hervé RIVIERE Zenika @_rv_ hriviere
  2. 2. Source : confluent.io
  3. 3. Ingestion … alimentation !
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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…)
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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  )
  12. 12. DEMO ! https://github.com/hriviere/demo-kafka-connect-streams
  13. 13. Transformer !
  14. 14. 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)
  15. 15. • 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 
  16. 16. 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)
  17. 17. 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
  18. 18. • 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 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 Une fois la Ktable synchronisée, consommation des messages de la partition 2
  24. 24. 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
  25. 25. DEMO ! https://github.com/hriviere/demo-kafka-connect-streams
  26. 26. Source : confluent.io

×