Лучше сделать авро десериализацию в DeserializationSchema коннектора kafka или после в процессе функции - PullRequest
1 голос
/ 28 июня 2019

Итак, у меня есть случай использования, когда у меня есть соединитель kafka, который использует массив байтов avro из раздела kafka и преобразует его в объект Avro. Это кажется достаточно простым, но я понял, что если десериализация не удалась по какой-то причине, например, не соответствует схеме или чему-то другому, то единственные варианты обработки, которые либо регистрируют ошибку и выводят пустой байтовый массив, либо выдают ошибку (что я и делаю не вижу хорошей идеи для длительной работы).

Но если десериализатор коннектора kafka просто принимает байтовый массив, выводит его, а функция процесса нисходящего потока выполняет проверку и преобразование, то, если происходит ошибка, она может записать ошибку как «сообщение об ошибке», pojo, на боковой вывод чтобы потом быть записанным в тему ошибки kafka, которая бы упростила отслеживание того, какие сообщения потерпели неудачу, и соответствующие данные намного легче.

Есть ли способ сделать это уже в логике сериализации коннектора kafka или это может иметь серьезные проблемы с производительностью (например, оптимизирована ли логика сериализации коннектора kafka для того, чтобы эти величины преобразования выполнялись быстрее, чем просто в нисходящей функции)?

Спасибо за любой вклад заранее!

1 Ответ

2 голосов
/ 30 июня 2019

Нет, не должно быть существенной разницы в производительности, и последовательная сериализация, безусловно, более гибкая. Например, вы также можете запустить сериализацию с более высоким параллелизмом, чем у источника, что может иметь смысл, если сериализация в вашем случае довольно дорогая.

Единственный недостаток, который я вижу сейчас, это то, что вы не можете использовать водяные знаки для каждого раздела [1]. В списке рассылки dev недавно также обсуждалась эта тема [2].

Надеюсь, это поможет.

[1] https://ci.apache.org/projects/flink/flink-docs-release-1.8/dev/connectors/kafka.html#kafka-consumers-and-timestamp-extractionwatermark-emission [2] http://apache -flink-mailing-list-archive.1008284.n3.nabble.com / DISCUSS-Connectors-and-NULL-processing-td29695.html

...