SlideShare une entreprise Scribd logo
1  sur  40
Télécharger pour lire hors ligne
Paris Apache Kafka
Meetup
Florian HUSSONNOIS
Zenika
@fhussonnois
Qu’est-ce que Kafka ?
Les concepts et l’architecture
Structure et distribution des messages
La tolérance à la panne
La consommation des messages
Les nouvelles APIs
Kafka Connect et Kafka Streams
(PIZZAS)
Comment développer avec les APIs Clients ?
API Producer
API Consumer
A high-throughput distributed messaging
system
Kafka est un projet créé à l’origine chez
Open-source en 2011
Broker
Broker
Broker
Producer
Producer
Producer
Consumer
Consumer
Consumer
Publish Subscribe
Cluster
Distribué
Hautement scalable
Durable
Tolérant à la panne
Un simple système de messages
Spécification
3 machines : « commodity hardware »
Intel Xeon 2.5 GHz processor with six cores
Six 7200 RPM SATA drives (JBOD)
32GB of RAM
1Gb Ethernet
Scenario (message = 100 octets)
Three producers, 3x async replication
2,024,032 records/sec (193.0 MB/sec)
O(1)
Fast Writes
Toutes les écritures sont mises dans le page-cache (c.à.d RAM)
Zero-Copy
Evite les copies redondantes de données entre des buffers intermédiaires
Réduit les context-swithes entre Kernel et Application.
API Java NIO (java.nio.channels.FileChannel)
transferTo() transfert des données depuis un fichier vers une socket
Unix – sendfile()
Construction de data pipelines à très faible latence
Log delivery, collection processing
Data integration
Activity stream, Data pipeline
Real-Time monitoring / Event Tracking
Kafka Core
Le système de messagerie distribué
Kafka Client
API Clients pour publier / consommer des messages (Java, C++, Go, etc)
Kafka Connect
API pour connecter des systèmes à Kafka en tant que Source ou Sink
Kafka Stream
Framework pour développer des applications data-driven / realtime stream processing
Topic, Partition, Stockage et Rétention
Clé  Valeur
Optionnelle (Primary Key)
Bytes
(Texte, JSON, XML, Images, etc)
• Un Producer produit des messages vers un Topic
• Un ou plusieurs Consumers s’abonnent à un topic pour lire les messages
Nouveaux messagesAnciens messages Temps
Producer
Consumer Consumer
Append-Only
K1
V1
K2
V2
null
V4
K1
V5
null
V7
K5
V8
K2
V10
Clé
Valeur
K2
V10
K1
V3
K5
V9
Write-ahead Log
• Clé
• Round-Robin
• Implémentation Custom
Messages partitionnés par :
Topic : User_Activity
Partition 0
Partition 1
Partition 2
Producer Consumer
Broker 2
Broker 3
Broker 1
Partition
Segment
1
Segment
2
Segment
N
File Segments (défaut 1Go)
Active
Temps
Une partition est :
• Immuable
• Stockée sur un disque
• Divisée en segments
Configuration
• log.segment.bytes
• log.roll.hours
Partition
Segment
1
Segment
2
Segment
N
File Segments (défaut 1Go)
Actif
Temps
• Temps – 7 jours
• Taille maximum d’un log
• Clé - Compaction
Les anciens messages sont
automatiquement supprimés
Permet la suppression des messages avec un payload à null.
K1 K2 K1 K1 K3 K2 K4 K5 K5 K2 K6
V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11
K1 K3 K4 K5 K2 K6
V4 V5 V7 V9 V10 V11
Log après compaction
Clé
Valeur
Clé
Valeur
Log avant compaction
Cas d’utilisation
K1 K2 K1 K1 K3 K2 K4 K5 K5 K2 K6
V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11
K1 K3 K4 K5 K2 K6
V4 V5 V7 V9 V10 V11
Log après compaction
Clé
Valeur
Clé
Valeur
Log avant compaction
• Distribuer les changements d’états d’une base de données
• Event-sourcing
• Cache distribué clé / valeur
• State journaling (Hight Availability)
Application
(Producer)
Application
(Consumer)
Topic avec compaction
Application
(Consumer)
Application
(Consumer)
Embedded
Database
Embedded
Database
Embedded
Database
Application
(Producer)
Application
(Producer)
Application Servers Application Servers
Réplication, Disponibilité et Consistance
Topic : User_Activity
Broker 2
Broker 3
Broker 1
Partition Leader 0
Partition Follower 2
Partition Leader 1
Partition Follower 0
Partition Leader 2
Partition Follower 1
Producer Consumer
Kafka accepte (#réplicas - 1) broker down avant de perdre des données
Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
1
2
Acknowledgment
(Optionnel)
3
Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2]
Producer
1
2
Acknowledgment
(Optionnel) Out-of-Sync
Down
replica.lag.time.max.ms (10secondes)
3
Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
Acknowledgment
request.required.acks
0 : Le Producer n’attend aucun acquittement
de la part du leader.
? ? ?
Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
Acknowledgment
request.required.acks
1 : Le leader garantit avoir écrit le message
? ?
Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2]
Producer
Acknowledgment
request.required.acks
all : Le leader attend d’avoir reçu un acquittement
de la part de tous les in-sync réplicas.
1
2
3 Out-of-Sync
Down
?
min.insync.replicas
Nombre minimum de réplicas qui doivent acquitter un message lorsque
request.required.acks = -1 (all)
Compromis entre
Disponibilité et Consistance
Configuration possible
replication_factor = 3; request.required.acks = all; min.insync.replicas=2
Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2]
Producer
1
2
Consumer
3
Acknowledgment
(Optionnel) committed Out-of-Sync
Down
replica.lag.time.max.ms (10secondes)
Apache ZooKeeper
Métadonnées sur les Leaders et réplicas
In-sync replicas: réplicas éligiblent à devenir leader
Controller
Détecte les erreurs au niveau broker
Sélectionne les leaders pour toutes les partitions
Offsets, Consumer Groups et Auto-
rebalancing
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3 4
5 6
5
Consumer 1
Consumer 2
2
3
1
• Un offset est un identifiant unique et incrémental par partition
• Un message est identifié par le triplet : Topic / Partition / Offset
• Les offsets des consumers sont stockés dans un topic système
• Si aucune position, 2 stratégies possibles : Earliest ou Latest
0 1 2 3 4 42 44 45 4643
Current Position
Last Committed Offset High Watermark
Log End Offset
Producer
Append-Only
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer 3
Consumer 1
Consumer 2
Consumer Group Vert
Consumer Group Bleu
• Une partition est assignée automatiquement à un unique consumer au sein d’un groupe
• Plusieurs groupes peuvent souscrire à un même topic
4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
• Les consumers se coordonnent automatiquement pour se distribuer les partitions.
• Le nombre de partitions définit le niveau de parallélisme maximum pour consommer un topic
• Il n’est pas possible de définir plus de consumers que de partitions
4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
Crash ou arrêt d’un consumer
4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
La partition est automatiquement
réassignée à l’un des consumers4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
Partition 3 0 2 3 4 51
• La nouvelle partition est assignée à un
des consumers
4
• Les messages sont stockés dans l’ordre dans lequel ils sont produits
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou
consommés plusieurs fois (At-Least Once)
0 2 3 4
Consumer v1
Last Committed Offset
Consomme et commit le message à l’Offset 1
1
• Les messages sont stockés dans l’ordre dans lequel ils sont produits
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou
consommés plusieurs fois (At-Least Once)
0 1 3 4
Consumer v1
Last Committed Offset
Se déplace à l’offset 2
2
• Les messages sont stockés dans l’ordre dans lequel ils sont produits
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou
consommés plusieurs fois (At-Least Once)
0 1 3 4
Consumer v1
Last Committed Offset
Crash
2
• Les messages sont stockés dans l’ordre dans lequel ils sont produit
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou
consommés plusieurs fois (At-Least Once)
0 3 4
Consumer v2
Last Committed Offset
21
Re-consomme le message à l’Offset 2 (doublon)
KEEP
CALM
AND
STREAM
YOUR DATA

Contenu connexe

Tendances

BigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopBigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopLilia Sfaxi
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingLilia Sfaxi
 
TP2 Big Data HBase
TP2 Big Data HBaseTP2 Big Data HBase
TP2 Big Data HBaseAmal Abid
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataLilia Sfaxi
 
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDIPrésentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDIHaShem Selmi
 
Fundamentals of Apache Kafka
Fundamentals of Apache KafkaFundamentals of Apache Kafka
Fundamentals of Apache KafkaChhavi Parasher
 
Grokking Techtalk #40: Consistency and Availability tradeoff in database cluster
Grokking Techtalk #40: Consistency and Availability tradeoff in database clusterGrokking Techtalk #40: Consistency and Availability tradeoff in database cluster
Grokking Techtalk #40: Consistency and Availability tradeoff in database clusterGrokking VN
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartisHeithem Abbes
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveurAmeni Ouertani
 
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQLLilia Sfaxi
 
BigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-ReduceBigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-ReduceLilia Sfaxi
 
Réplication des bases de données
Réplication des bases de donnéesRéplication des bases de données
Réplication des bases de donnéessie92
 
Concepts de sauvegarde et de récupération
Concepts de sauvegarde et de récupérationConcepts de sauvegarde et de récupération
Concepts de sauvegarde et de récupérationSoukaina Boujadi
 
Cours Big Data Chap5
Cours Big Data Chap5Cours Big Data Chap5
Cours Big Data Chap5Amal Abid
 

Tendances (20)

Base des données réparties
Base des données répartiesBase des données réparties
Base des données réparties
 
BigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopBigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans Hadoop
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
 
TP2 Big Data HBase
TP2 Big Data HBaseTP2 Big Data HBase
TP2 Big Data HBase
 
Chapitre 2 hadoop
Chapitre 2 hadoopChapitre 2 hadoop
Chapitre 2 hadoop
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big Data
 
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDIPrésentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDI
 
Fundamentals of Apache Kafka
Fundamentals of Apache KafkaFundamentals of Apache Kafka
Fundamentals of Apache Kafka
 
Grokking Techtalk #40: Consistency and Availability tradeoff in database cluster
Grokking Techtalk #40: Consistency and Availability tradeoff in database clusterGrokking Techtalk #40: Consistency and Availability tradeoff in database cluster
Grokking Techtalk #40: Consistency and Availability tradeoff in database cluster
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartis
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveur
 
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
 
kafka
kafkakafka
kafka
 
Chapitre 3 spark
Chapitre 3 sparkChapitre 3 spark
Chapitre 3 spark
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQL
 
BigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-ReduceBigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-Reduce
 
Réplication des bases de données
Réplication des bases de donnéesRéplication des bases de données
Réplication des bases de données
 
Concepts de sauvegarde et de récupération
Concepts de sauvegarde et de récupérationConcepts de sauvegarde et de récupération
Concepts de sauvegarde et de récupération
 
Cours Big Data Chap5
Cours Big Data Chap5Cours Big Data Chap5
Cours Big Data Chap5
 
Kafka presentation
Kafka presentationKafka presentation
Kafka presentation
 

Similaire à Paris Kafka Meetup - Concepts & Architecture

Stream processing avec Apache Pulsar
Stream processing avec Apache PulsarStream processing avec Apache Pulsar
Stream processing avec Apache PulsarBruno Bonnin
 
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesBreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesXavier MARIN
 
Présentation de Apache Zookeeper
Présentation de Apache ZookeeperPrésentation de Apache Zookeeper
Présentation de Apache ZookeeperMichaël Morello
 
DataStax et Cassandra dans Azure au Microsoft Techdays
DataStax et Cassandra dans Azure au Microsoft TechdaysDataStax et Cassandra dans Azure au Microsoft Techdays
DataStax et Cassandra dans Azure au Microsoft TechdaysVictor Coustenoble
 
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...Groupe D.FI
 
[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014
[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014
[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014Groupe D.FI
 
[Café Techno] Spectrum protect - Présentation des fonctionnalités
[Café Techno] Spectrum protect - Présentation des fonctionnalités[Café Techno] Spectrum protect - Présentation des fonctionnalités
[Café Techno] Spectrum protect - Présentation des fonctionnalitésGroupe D.FI
 
LPIC1 10 01 logs
LPIC1 10 01 logsLPIC1 10 01 logs
LPIC1 10 01 logsNoël
 
IBM FlashSystem : Les bonnes raisons de passer au Flash
IBM FlashSystem : Les bonnes raisons de passer au Flash IBM FlashSystem : Les bonnes raisons de passer au Flash
IBM FlashSystem : Les bonnes raisons de passer au Flash Solutions IT et Business
 
Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)
Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)
Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)Publicis Sapient Engineering
 
05 02 surveillance et analyse de traffic tcpip
05 02 surveillance et analyse de traffic tcpip05 02 surveillance et analyse de traffic tcpip
05 02 surveillance et analyse de traffic tcpipNoël
 
Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture
Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architectureTartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture
Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architectureconfluent
 
Rex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantesRex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantesChristophe Furmaniak
 
Zimbra Forum France 2016 - Beezim and Ceph
Zimbra Forum France 2016 - Beezim and CephZimbra Forum France 2016 - Beezim and Ceph
Zimbra Forum France 2016 - Beezim and CephZimbra
 

Similaire à Paris Kafka Meetup - Concepts & Architecture (20)

Stream processing avec Apache Pulsar
Stream processing avec Apache PulsarStream processing avec Apache Pulsar
Stream processing avec Apache Pulsar
 
Apache kafka big data track
Apache kafka   big data trackApache kafka   big data track
Apache kafka big data track
 
Introduction à Apache Pulsar
 Introduction à Apache Pulsar Introduction à Apache Pulsar
Introduction à Apache Pulsar
 
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesBreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
 
Présentation de Apache Zookeeper
Présentation de Apache ZookeeperPrésentation de Apache Zookeeper
Présentation de Apache Zookeeper
 
Exchange 2013 Bonnes pratiques
Exchange 2013 Bonnes pratiques Exchange 2013 Bonnes pratiques
Exchange 2013 Bonnes pratiques
 
DataStax et Cassandra dans Azure au Microsoft Techdays
DataStax et Cassandra dans Azure au Microsoft TechdaysDataStax et Cassandra dans Azure au Microsoft Techdays
DataStax et Cassandra dans Azure au Microsoft Techdays
 
Ejb 3
Ejb 3Ejb 3
Ejb 3
 
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...
 
[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014
[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014
[Café Techno] Les concepts de base de TSM 7.1.1 - 11/2014
 
[Café Techno] Spectrum protect - Présentation des fonctionnalités
[Café Techno] Spectrum protect - Présentation des fonctionnalités[Café Techno] Spectrum protect - Présentation des fonctionnalités
[Café Techno] Spectrum protect - Présentation des fonctionnalités
 
LPIC1 10 01 logs
LPIC1 10 01 logsLPIC1 10 01 logs
LPIC1 10 01 logs
 
Docker
DockerDocker
Docker
 
IBM FlashSystem : Les bonnes raisons de passer au Flash
IBM FlashSystem : Les bonnes raisons de passer au Flash IBM FlashSystem : Les bonnes raisons de passer au Flash
IBM FlashSystem : Les bonnes raisons de passer au Flash
 
Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)
Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)
Paris Container Day 2016 : Les nouveaux défis du déploiement (Xebia Labs)
 
05 02 surveillance et analyse de traffic tcpip
05 02 surveillance et analyse de traffic tcpip05 02 surveillance et analyse de traffic tcpip
05 02 surveillance et analyse de traffic tcpip
 
Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture
Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architectureTartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture
Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture
 
Rex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantesRex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantes
 
Zimbra Forum France 2016 - Beezim and Ceph
Zimbra Forum France 2016 - Beezim and CephZimbra Forum France 2016 - Beezim and Ceph
Zimbra Forum France 2016 - Beezim and Ceph
 
SVN
SVN SVN
SVN
 

Paris Kafka Meetup - Concepts & Architecture

  • 1. Paris Apache Kafka Meetup Florian HUSSONNOIS Zenika @fhussonnois
  • 2. Qu’est-ce que Kafka ? Les concepts et l’architecture Structure et distribution des messages La tolérance à la panne La consommation des messages Les nouvelles APIs Kafka Connect et Kafka Streams (PIZZAS) Comment développer avec les APIs Clients ? API Producer API Consumer
  • 3. A high-throughput distributed messaging system
  • 4. Kafka est un projet créé à l’origine chez Open-source en 2011 Broker Broker Broker Producer Producer Producer Consumer Consumer Consumer Publish Subscribe Cluster Distribué Hautement scalable Durable Tolérant à la panne Un simple système de messages
  • 5. Spécification 3 machines : « commodity hardware » Intel Xeon 2.5 GHz processor with six cores Six 7200 RPM SATA drives (JBOD) 32GB of RAM 1Gb Ethernet Scenario (message = 100 octets) Three producers, 3x async replication 2,024,032 records/sec (193.0 MB/sec) O(1)
  • 6. Fast Writes Toutes les écritures sont mises dans le page-cache (c.à.d RAM) Zero-Copy Evite les copies redondantes de données entre des buffers intermédiaires Réduit les context-swithes entre Kernel et Application. API Java NIO (java.nio.channels.FileChannel) transferTo() transfert des données depuis un fichier vers une socket Unix – sendfile()
  • 7. Construction de data pipelines à très faible latence Log delivery, collection processing Data integration Activity stream, Data pipeline Real-Time monitoring / Event Tracking
  • 8. Kafka Core Le système de messagerie distribué Kafka Client API Clients pour publier / consommer des messages (Java, C++, Go, etc) Kafka Connect API pour connecter des systèmes à Kafka en tant que Source ou Sink Kafka Stream Framework pour développer des applications data-driven / realtime stream processing
  • 10. Clé  Valeur Optionnelle (Primary Key) Bytes (Texte, JSON, XML, Images, etc)
  • 11. • Un Producer produit des messages vers un Topic • Un ou plusieurs Consumers s’abonnent à un topic pour lire les messages Nouveaux messagesAnciens messages Temps Producer Consumer Consumer Append-Only K1 V1 K2 V2 null V4 K1 V5 null V7 K5 V8 K2 V10 Clé Valeur K2 V10 K1 V3 K5 V9 Write-ahead Log
  • 12. • Clé • Round-Robin • Implémentation Custom Messages partitionnés par : Topic : User_Activity Partition 0 Partition 1 Partition 2 Producer Consumer Broker 2 Broker 3 Broker 1
  • 13. Partition Segment 1 Segment 2 Segment N File Segments (défaut 1Go) Active Temps Une partition est : • Immuable • Stockée sur un disque • Divisée en segments Configuration • log.segment.bytes • log.roll.hours
  • 14. Partition Segment 1 Segment 2 Segment N File Segments (défaut 1Go) Actif Temps • Temps – 7 jours • Taille maximum d’un log • Clé - Compaction Les anciens messages sont automatiquement supprimés
  • 15. Permet la suppression des messages avec un payload à null. K1 K2 K1 K1 K3 K2 K4 K5 K5 K2 K6 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 K1 K3 K4 K5 K2 K6 V4 V5 V7 V9 V10 V11 Log après compaction Clé Valeur Clé Valeur Log avant compaction
  • 16. Cas d’utilisation K1 K2 K1 K1 K3 K2 K4 K5 K5 K2 K6 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 K1 K3 K4 K5 K2 K6 V4 V5 V7 V9 V10 V11 Log après compaction Clé Valeur Clé Valeur Log avant compaction • Distribuer les changements d’états d’une base de données • Event-sourcing • Cache distribué clé / valeur • State journaling (Hight Availability)
  • 19. Topic : User_Activity Broker 2 Broker 3 Broker 1 Partition Leader 0 Partition Follower 2 Partition Leader 1 Partition Follower 0 Partition Leader 2 Partition Follower 1 Producer Consumer Kafka accepte (#réplicas - 1) broker down avant de perdre des données
  • 20. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2, 3] Producer 1 2 Acknowledgment (Optionnel) 3
  • 21. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2] Producer 1 2 Acknowledgment (Optionnel) Out-of-Sync Down replica.lag.time.max.ms (10secondes) 3
  • 22. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2, 3] Producer Acknowledgment request.required.acks 0 : Le Producer n’attend aucun acquittement de la part du leader. ? ? ?
  • 23. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2, 3] Producer Acknowledgment request.required.acks 1 : Le leader garantit avoir écrit le message ? ?
  • 24. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2] Producer Acknowledgment request.required.acks all : Le leader attend d’avoir reçu un acquittement de la part de tous les in-sync réplicas. 1 2 3 Out-of-Sync Down ?
  • 25. min.insync.replicas Nombre minimum de réplicas qui doivent acquitter un message lorsque request.required.acks = -1 (all) Compromis entre Disponibilité et Consistance Configuration possible replication_factor = 3; request.required.acks = all; min.insync.replicas=2
  • 26. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2] Producer 1 2 Consumer 3 Acknowledgment (Optionnel) committed Out-of-Sync Down replica.lag.time.max.ms (10secondes)
  • 27. Apache ZooKeeper Métadonnées sur les Leaders et réplicas In-sync replicas: réplicas éligiblent à devenir leader Controller Détecte les erreurs au niveau broker Sélectionne les leaders pour toutes les partitions
  • 28. Offsets, Consumer Groups et Auto- rebalancing
  • 29. Topic : User_Activity Partition 0 Partition 1 Partition 2 0 1 3 4 Consumer 10 1 2 4 0 2 3 4 5 6 5 Consumer 1 Consumer 2 2 3 1 • Un offset est un identifiant unique et incrémental par partition • Un message est identifié par le triplet : Topic / Partition / Offset
  • 30. • Les offsets des consumers sont stockés dans un topic système • Si aucune position, 2 stratégies possibles : Earliest ou Latest 0 1 2 3 4 42 44 45 4643 Current Position Last Committed Offset High Watermark Log End Offset Producer Append-Only
  • 31. Topic : User_Activity Partition 0 Partition 1 Partition 2 0 1 3 4 Consumer 10 1 2 4 0 2 3 5 6 5 2 3 1 Consumer 1 Consumer 2 Consumer 3 Consumer 1 Consumer 2 Consumer Group Vert Consumer Group Bleu • Une partition est assignée automatiquement à un unique consumer au sein d’un groupe • Plusieurs groupes peuvent souscrire à un même topic 4
  • 32. Topic : User_Activity Partition 0 Partition 1 Partition 2 0 1 3 4 Consumer 10 1 2 4 0 2 3 5 6 5 2 3 1 Consumer 1 Consumer 2 Consumer Group Vert Consumer 3 • Les consumers se coordonnent automatiquement pour se distribuer les partitions. • Le nombre de partitions définit le niveau de parallélisme maximum pour consommer un topic • Il n’est pas possible de définir plus de consumers que de partitions 4
  • 33. Topic : User_Activity Partition 0 Partition 1 Partition 2 0 1 3 4 Consumer 10 1 2 4 0 2 3 5 6 5 2 3 1 Consumer 1 Consumer 2 Consumer Group Vert Consumer 3 Crash ou arrêt d’un consumer 4
  • 34. Topic : User_Activity Partition 0 Partition 1 Partition 2 0 1 3 4 Consumer 10 1 2 4 0 2 3 5 6 5 2 3 1 Consumer 1 Consumer 2 Consumer Group Vert Consumer 3 La partition est automatiquement réassignée à l’un des consumers4
  • 35. Topic : User_Activity Partition 0 Partition 1 Partition 2 0 1 3 4 Consumer 10 1 2 4 0 2 3 5 6 5 2 3 1 Consumer 1 Consumer 2 Consumer Group Vert Consumer 3 Partition 3 0 2 3 4 51 • La nouvelle partition est assignée à un des consumers 4
  • 36. • Les messages sont stockés dans l’ordre dans lequel ils sont produits • L’ordre de lecture des messages est garanti uniquement par partition • En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once) 0 2 3 4 Consumer v1 Last Committed Offset Consomme et commit le message à l’Offset 1 1
  • 37. • Les messages sont stockés dans l’ordre dans lequel ils sont produits • L’ordre de lecture des messages est garanti uniquement par partition • En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once) 0 1 3 4 Consumer v1 Last Committed Offset Se déplace à l’offset 2 2
  • 38. • Les messages sont stockés dans l’ordre dans lequel ils sont produits • L’ordre de lecture des messages est garanti uniquement par partition • En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once) 0 1 3 4 Consumer v1 Last Committed Offset Crash 2
  • 39. • Les messages sont stockés dans l’ordre dans lequel ils sont produit • L’ordre de lecture des messages est garanti uniquement par partition • En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once) 0 3 4 Consumer v2 Last Committed Offset 21 Re-consomme le message à l’Offset 2 (doublon)