Basierend auf Avro-Schema habe ich eine Klasse (Data) erzeugt, um mit der Klasse für das Schema zu arbeiten Danach kodiere ich die Daten und sende in andere Anwendung "A" mit kafkaAvro mit Kafka - Deserialisieren mit wechselndem Schema
Data data; // <- The object was initialized before . Here it is only the declaration "for example"
EncoderFactory encoderFactory = EncoderFactory.get();
ByteArrayOutputStream out = new ByteArrayOutputStream();
BinaryEncoder encoder = encoderFactory. directBinaryEncoder(out, null);
DatumWriter<Tloog> writer;
writer = new SpecificDatumWriter<Data>(Data.class);
writer.write(data, encoder);
byte[] avroByteMessage = out.toByteArray();
auf der anderen Seite (in der Anwendung „A“) habe ich die Daten deserilize von Deserializer Umsetzung
class DataDeserializer implements Deserializer<Data> {
private String encoding = "UTF8";
@Override
public void configure(Map<String, ?> configs, boolean isKey) {
// nothing to do
}
@Override
public Tloog deserialize(String topic, byte[] data) {
try {
if (data == null)
{
return null;
}
else
{
DatumReader<Tloog> reader = new SpecificDatumReader<Data>(Data.class);
DecoderFactory decoderFactory = DecoderFactory.get();
BinaryDecoder decoder = decoderFactory.binaryDecoder(data, null);
Data decoded = reader.read(null, decoder);
return decoded;
}
} catch (Exception e) {
throw new SerializationException("Error when deserializing byte[] to string due to unsupported encoding " + encoding);
}
}
Das Problem ist, dass dieser Ansatz die Verwendung von SpecificDatumReader erfordert, sollte Iethe Datenklasse mit dem integriert werden Anwendungscode ... Diese problematisch sein könnte - Schema ändern könnte und sollte daher Datenklasse wird neu generiert und integrierte nochmals 2 Fragen:
- Soll ich GenericDatumReader in der Anwendung verwenden? Wie man das richtig macht. (Ich kann das Schema einfach in der Anwendung speichern)
- Gibt es eine einfache Möglichkeit, mit SpecificDatumReader zu arbeiten, wenn sich Daten ändern? Wie könnte es ohne viel Ärger integriert werden?
Dank
Nur um dies hier [Confluent Schema Registry] (http://docs.confluent.io/1.0.1/schema-registry/docs/index.html). – vlahmot
Ich schaute auf Schema Registry - es scheint sehr merkwürdig, dass Sie eine RESTful-Schnittstelle auf eine Kafka-Back-End-Architektur zerschlagen würden. Warum lassen Sie Ihre Kunden nicht einfach direkt mit Ihrem Schema-Stream interagieren? Es ist, als würde man mit einem Pferdegespann ein Autofahrgestell ziehen. Für einen Anwendungsfall wie diesen, in dem wir bereits Kafka-Streams konsumieren, möchten Sie jetzt keine RESTful-Aufrufe durchführen, um Ihre Schemas abzuholen. –
Ich mochte es für die automatische Schema-Evolution und den Schutz vor Datenkorruption. Die Tatsache, dass nur ein Verweis auf das Schema und nicht das vollständige Schema mit jedem Datenpunkt gespeichert wird, ist ebenfalls gut. Das Hinzufügen eines Webaufrufs zum Abrufen der Schemas war für uns kein Problem. – vlahmot