REX | Kafka - Replay

Dans le cadre d’un projet sourcé depuis l’open data, j’ai mis en place un système d’ingestion de donnée permettant de gérer les éventuels changement de schémas ou un breaking change de la source tierce qui est instable.

Architecture

Implémentation

Stockage brut et structuré

Le topic des events brut permet de garder la donnée chez nous, elle pourra ainsi être rejouée.

Le topic des events structurés pourra être consommé directement par les autres services.

Nous allons enrichir notre event avec des métadonnées pour tracer sa provenance, le type d’erreur, le type d’event, la date, et l’offset dans le topic structuré si le schéma est valide.

Voici un exemple de métadonnées pour un event brut :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

object ErrorType extends Enumeration {
  val Network, Schema = Value
}

object Source extends Enumeration {
  val ThirdParty, ReplayNetwork, ReplaySchema, ReplayOverwrite = Value
}

case class RawRecord(
	            source: Source,
	            event_type: EventType,
		    error_type: Option[ErrorType],
		    error_payload: Option[String],
		    event_timestamp: Long,
		    readable_date: String,
	            offset: Option[Long],
                    event_id: String,
	            value: String
                    ) {
  val key = RawRecord(event_timestamp, event_id)
  val value: RawRecord = this

  def toRecord[K](topic: String): ProducerRecord[GenericRecord, GenericRecord] =
    new ProducerRecord[GenericRecord, GenericRecord](topic, RawRecord.format.to(key), RawRecord.format.to(value))
}

Validation

• Le premier cas à gérer est celui ou le service tiers est indisponible
• Le second cas à gérer est celui ou le schéma est invalide

Il est important d’identifier les différents types d’erreurs possibles en séparant au minimum les erreurs nécessitant une intervention humaine (modification du schéma) ou un retry automatique :

• Service non disponible (retry)
• Erreur de schéma (nécessite une intervention humaine)

Service de Replay

Un service de replay nous permettra de rejouer nos events deux 2 façons :

• Service tiers indisponible : nous allons effectuer un appel à la source tierce pour récupérer les events manqués, et les rejouer avec la source : ReplayNetwork
• Schema invalide : nous allons adapter le schéma existant rejouer les events avec la source: ReplaySchema

Nous allons ainsi pouvoir rejouer les events depuis le topic raw pour de la donnée récente (en fonction de durée de rétention) ou depuis la base de donnée pour de la donnée plus ancienne.

Cas d’usage

Les données de l’application Realtime Bike étant basée sur de l’open data, le schéma change régulièrement sans avertissement.

Il est donc indispensable d’avoir un système limitant la perte de donnée et permettant le replay des events.