Confluent Piattaforma: Soggetti schema Registro

Question

Lavorare con Confluent Platform, la piattaforma offerta dai creatori di Apache Kafka, e ho una domanda:

Nella documentazione del Schema Registry API Reference, accennano l'astrazione di un "Oggetto" . Si registra uno schema sotto un "oggetto" che è del tipo topicName- o topicName-valore, ma non vi è alcuna spiegazione sul motivo per cui è necessario (come esso implica) uno schema separato per e valore dei messaggi su un determinato argomento. Né vi è alcuna affermazione diretta secondo cui la registrazione con un "soggetto" necessariamente associa lo schema a quell'argomento, a parte mnemonicamente.

questioni

Ulteriori confuse, gli esempi successivi ("get versione dello schema per soggetto" e "registrare nuovo schema in oggetto") in quella pagina non farlo uso che formato per il nome del soggetto, e di utilizzare invece solo un nome argomento per il valore "soggetto". Se qualcuno ha qualche idea su a) perché ci sono questi due "argomenti" per argomento, e b) quale sia l'uso corretto, sarebbe molto apprezzato.

Answer 1

Confluent Schema del Registro di sistema è in realtà un po 'incoerente con i nomi di soggetti :)

In effetti, il KafkaAvroSerializer (utilizzato per la nuova Kafka 0.8.2 produttore) utilizza topic-key|value modello per i soggetti (link), mentre KafkaAvroEncoder (per il vecchio produttore) utilizza il modello schema.getName()-value (link).

Il motivo per cui si dovrebbe avere 2 diversi soggetti per ogni argomento (uno per la chiave, uno per il valore) è piuttosto semplice:

dire che ho uno schema Avro che rappresenta una voce di registro, e ogni voce di registro ha una fonte informazioni ad esso collegato:

{ 
    "type":"record", 
    "name":"LogEntry", 
    "fields":[ 
     { 
     "name":"line", 
     "type":"string" 
     }, 
     { 
     "name":"source", 
     "type":{ 
      "type":"record", 
      "name":"SourceInfo", 
      "fields":[ 
       { 
        "name":"host", 
        "type":"string" 
       }, 
       { 
        "name":"...", 
        "type":"string" 
       } 
      ] 
     } 
     } 
    ] 
} 

Un caso d'uso comune sarebbe che voglio dividere le entrate per fonte, quindi vorrebbe avere due soggetti associati per argomento (e soggetti sono fondamentalmente le revisioni degli schemi Avro) - uno per chiave (che è SourceInfo) e una per il valore (LogEntry).

Avere questi due soggetti sarebbe il partizionamento e la memorizzazione dei dati finché ho un registro dello schema in esecuzione e i miei produttori/consumatori possono parlare con esso. Qualsiasi modifica a questi schemi si rifletterà nel registro dello schema e fintanto che soddisferanno le impostazioni di compatibilità tutto dovrebbe essere serializzato/deserializzato senza che ci si debba preoccupare di questo.

Nota: qualsiasi ulteriore informazione è solo il mio pensiero personale e forse sono io che ancora non comprendere appieno come questo dovrebbe funzionare in modo potrei sbagliarmi.

In realtà mi piace più come lo KafkaAvroEncoder è implementato piuttosto che lo KafkaAvroSerializer. KafkaAvroEncoder non impone in alcun modo l'utilizzo di UNO schema per argomento chiave \ valore mentre lo fa KafkaAvroSerializer. Questo potrebbe essere un problema quando si pianifica di produrre dati per più schemi Avro in un argomento. In questo caso, KafkaAvroSerializer tenterebbe di aggiornare i soggetti topic-key e topic-value e il 99% si interromperà se la compatibilità viene violata (e se si dispone di più schemi Avro sono quasi sempre diversi e incompatibili tra loro).

Dall'altra parte, KafkaAvroEncoder si preoccupa solo di nomi di schemi e si può tranquillamente produrre dati per più schemi Avro in un unico argomento e tutto dovrebbe funzionare bene (si avranno tanti soggetti come schemi).

Questa incongruenza non è ancora chiara per me e spero che i confluenti possano spiegarlo se vedono questa domanda/risposta.

auguriamo che