2016-07-21 2 views
1

Эй, я хотел бы использовать схемы реестр Confluent с Avro сериализаторами: Документация сейчас в основном говорит: не использовать ту же схему для множества различных topicsСливной схема реестр Avro схема

Может кто-нибудь объяснить мне, почему? Я просматриваю исходный код и в основном хранит схему в теме kafka следующим образом (название темы, magicbytes, version-> key) (schema-> value)

Поэтому я не вижу проблемы с использованием схемы многократно ожидать избыточности?

+0

Насколько я понимаю документацию, это относится только к кафке <= 0.8.2. Вы должны подключить KafkaAvroEncoder к старому продюсеру. * BUT * вы можете использовать только KafkaAvroEncoder для сериализации значения сообщения (а не ключа) и только отправлять значение типа записи Avro. Поэтому схема Avro для значения будет зарегистрирована под объектом subjectName-value, где recordName - это имя записи Avro. – TobiSH

+0

Можете ли вы объяснить, почему вы заключили «Документация теперь в основном говорит: не используйте ту же схему для нескольких разных тем»? Я не вижу эту рекомендацию в связанной документации. –

ответ

0

Я думаю, что вы имеете в виду этот комментарий в документации:

Мы рекомендуем пользователям использовать новый производитель в org.apache.kafka.clients.producer.KafkaProducer. Если вы используете версию Kafka старше 0.8.2.0, вы можете подключить KafkaAvroEncoder к старому продюсеру в kafka.javaapi.producer. Однако будут некоторые ограничения. Вы можете использовать только KafkaAvroEncoder для сериализации значения сообщения и только отправки значения типа записи Avro. Схема Avro для значения будет зарегистрирована по предмету recordName-value, где recordName - это название записи Avro. Из-за этого один и тот же тип записи Avro не должен использоваться более чем в одной теме.

Во-первых, приведенный выше комментарий - это относится только к старым API-производителям до 0.8.2. Настоятельно рекомендуется, чтобы вы использовали нового производителя в любом случае, поскольку это намного лучшая реализация, не зависит от всей ядро ​​ядра и является клиентом, который будет поддерживаться в будущем (пока еще нет конкретной временной шкалы, но старый продюсер в конечном итоге будет устаревшим, а затем удалит).

Однако, если вы используете старый производитель, это ограничение требуется только в том случае, если схема для двух объектов может развиваться отдельно. Предположим, что вы пишете два приложения, написанные на разные темы, но используйте один и тот же тип записи Avro, назовем его record. Теперь оба приложения зарегистрируют его/просмотрят по предмету record-value и получат назначение version=1. Все это нормально, пока схема не изменяется. Но давайте скажем, что приложение A теперь должно добавить поле. Когда это произойдет, схема будет зарегистрирована по предмету record-value и получит назначение version=2. Это хорошо для приложения A, но приложение B либо не было обновлено, чтобы обрабатывать эту схему, либо, что еще хуже, схема не является даже действительной для приложения B. Однако вы теряете защиту, реестр которой обычно дает вам - теперь какое-то другое приложение может публиковать данные этого формата в теме, используемой приложением B (это выглядит нормально, потому что зарегистрировала эту схему). Теперь приложение B может видеть данные, которые он не знает, как обращаться, поскольку он не поддерживает схему.

Итак, короткая версия состоит в том, что, поскольку старый продюсер должен быть разделен, если вы также используете ту же схему, вы в конечном итоге связываете два приложения и схемы, которые они должны поддерживать. Вы можете использовать одну и ту же схему по темам, но мы предлагаем не делать этого, поскольку она соединяет ваши приложения (и их разработку, команды, разрабатывающие их и т. Д.).

Смежные вопросы