Paris Kafka Meetup - Concepts & Architecture

Post on 11-Apr-2017

450 views 1 download

Transcript of Paris Kafka Meetup - Concepts & Architecture

Paris Apache Kafka Meetup

Florian HUSSONNOISZenika

@fhussonnois

Qu’est-ce que Kafka ?

Les concepts et l’architectureStructure et distribution des messagesLa tolérance à la panneLa consommation des messages

Les nouvelles APIsKafka Connect et Kafka Streams

(PIZZAS)

Comment développer avec les APIs Clients ?API ProducerAPI 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

ClusterDistribué

Hautement scalable

Durable

Tolérant à la panne

Un simple système de messages

Spécification3 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 StreamFramework 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

K1V1

K2V2

nullV4

K1V5

nullV7

K5V8

K2V10

Clé

Valeur

K2V10

K1V3

K5V9

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)

ActiveTemps

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)

ActifTemps

• 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 V11Log 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 V11Log 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

P0R1

P0R2

P0R3

ISR (in-sync replicas) = [1, 2, 3]

Producer

1

2

Acknowledgment(Optionnel)

3

Broker 1 Broker 2 Broker 3

P0R1

P0R2

P0R3

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

P0R1

P0R2

P0R3

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

P0R1

P0R2

P0R3

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

P0R1

P0R2

P0R3

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-SyncDown

?

min.insync.replicasNombre 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

P0R1

P0R2

P0R3

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 ZooKeeperMétadonnées sur les Leaders et réplicas

In-sync replicas: réplicas éligiblent à devenir leader

ControllerDé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

ProducerAppend-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 consumer4

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

CALMAND

STREAM

YOUR DATA