Комментарии 14
Добрый день, очень интересно. Можете рассказать насколько внедрение схем влияет на пропускную способность или насколько оно увеличивает накладные расходы на проверку? Также интересно схемы складываются прямо в кафку в отдельный топик или сервис со схемами является отдельным хранилищем в которое кафка по апи ходит или еще как-то? Если данные летят в старом deprecated формате, то подразумевается, что мы как-то записываем логи или метрики об этом? Чтобы понять уменьшается ли у нас объем таких сообщений и можем ли мы убивать обратную совместимость или как мониторинг осуществляется на соответствие схемам?
насколько внедрение схем влияет на пропускную способность или насколько оно увеличивает накладные расходы на проверку?
Мы наблюдали, но просадки в performance не заметили
сервис со схемами является отдельным хранилищем в которое кафка по апи ходит
именно так, но мысль про отдельный топик очень интересна!
Если данные летят в старом deprecated формате, то подразумевается, что мы как-то записываем логи или метрики об этом?
Логирование происходит в сервисе и в самих логах Kafka
Чтобы понять уменьшается ли у нас объем таких сообщений и можем ли мы убивать обратную совместимость или как мониторинг осуществляется на соответствие схемам?
Не уверен что до конца понял Ваш вопрос, есть топики с обязательным требованиям к обратной совместимости и если там что то Deprecated, происходил переезд в новый топик
Не уверен что до конца понял Ваш вопрос, есть топики с обязательным требованиям к обратной совместимости и если там что то Deprecated, происходил переезд в новый топик
Я вероятно не понял что есть режим совместимости. Есть v1 и v2 какой-то схемы. Совместимость обеспечивается тем, что kafka преобразует v1 в v2 каким-то внутренним механизмом, если ей на вход прийдет v1? А если в v1 данных в принципе для такого преобразования не хватает.
Поэтому я решил, что вряд ли это имеется ввиду. Наверное просто у нас две спеки v1 и v2 обе считаются валидными, а уметь работать с обеими версиями это уже вопрос консьюмеров. Тогда предполагаю, что v1 можно поставить deprecated и потихоньку его вымывать по мере того, как продьюсеры v1 перестают генерить и вместо него генерят v2. Тогда для v1 должна собираться метрика, которая показывает какой объем до сих пор данных в deprecated v1 схеме продолжает приходить. Чтобы отловить момент, когда их начнет приходить 0 и убрать вообще поддержку схемы v1. Какая-то такая мысль была, но не знаю поддерживает ли сам процесс верификации на схему отправку метрик. Наверное нет и это опять же вопрос консьюмеров.
Совместимость обеспечивается тем, что kafka преобразует v1 в v2 каким-то внутренним механизмом, если ей на вход прийдет v1?
Просто алерты которые через логи можно как то аггрегировать и анализировать в дальнейшем, но чтобы слету как-то преобразовать, такого не знаю и не встречал в своей практики =)
Я начал еще вокруг этой темы смотреть чего изучить и попал на курс Akka Classic Serialization. Там ребята нагнетают, что у Java сериализации какой-то ужасающий перфоманс, но вот вы говорите, что даже не заметили изменений, а плюсы проверки схемы уже получили. Но непонятно насколько в их утверждении есть рациональное зерно и при какой нагрузке это стрелять начинает. Но опять же, там Akka и Scala, непонятно насколько оно надо вообще.
Я немножко не из мира java, но, насколько я представляю, дело обстоит примерно так: клиент имеет свою схему, через registry (регистрируя) он может получить её id. Если id схемы в получаемом сообщении совпадает с клиентской, всё просто. Если нет, клиент запрашивает схему сообщения из registry и если она совместима должен построить конвертер, который декодирует сообщение по старой (или может быть новой) схеме и по правилам эволюции схемы преобразует его в объект текущей схемы.
Абсолютно никак не влияет. Брокеру без разницы что в него кладут, он ничего не проверяет. Schema registry это то, с чем работают клиенты через отдельный api. Оно может быть вообще в другой кафке если что, кафка для этого сервиса просто хранилище. Режимы совместимости в avro просто накладывают ограничения на возможности модификации схем, так чтобы клиент имея локально схему версии X мог декодировать сообщение закодированное со схемой версии Y. Соответственно schema registry при обновлении схемы может такие ограничения проверять и не даст изменить схему если совместимость нарушается.
А как быстро стартануть то? Какой-то есть материал, который вам сильно помог? В каком виде описываются схемы? Как их закидывать? UI или по API? Какой-нибудь толковый 101 очень бы не помешал, но возможно это идея для следующей статьи ))
Еще бы понять конкретно что avro решает. С моей точки зрения есть топики и в них можно писать произвольный JSON. Этот JSON можно валидировать, но почему тогда все время речь о сериализации и десериализации в статьях про avro. Он же уже лежит в json формате в топике =) Но возможно мне просто стоит подробнее почитать про эту технологию
Если у вас JSON, вам скорее всего не нужен schema registry. Это вообще штука заточенная чисто под avro. Дело в том что это формат сериализации, в котором отсутствуют метаданные. Там нет названий полей как в json или тегов как в protobuf. Это просто бинарно закодированные подряд все поля структуры. И не зная с какой схемой было закодировано сообщение, декодировать его невозможно. Поэтому avro без schema registry существовать практически не может. Выбирая avro надо всегда иметь в виду что все producers и consumers становятся зависимыми от schema registry. И сам он становится критичной частью всей инфраструктуры.
У меня действительно во все топики складывается JSON, но есть потребность проверять, что в определенные топики залетают только JSON определенного вида(содержащие определенные ключи, иногда надо проверить и value). Если есть какой-то механизм, который позволил бы проверять данные и писать ошибки в логи, если что-то не удовлетворяет условиям это было бы идеально. Еще идеальнее, если бы это все можно было хранить прямо по месту в kafka топиках и желательно без подключения внешнего хранилища спек. Но я не знаю существует ли для кафка что-то похожее на мое описание, но если вы знаете такое, то напишите, пожалуйста.
В каком виде описываются схемы?
{
"type" : "record",
"namespace" : "someSchema",
"name" : "Employee",
"fields" : [
{ "name" : "Name" , "type" : "string" },
{ "name" : "Age" , "type" : "int" }
]
}А как быстро стартануть то? Какой-то есть материал, который вам сильно помог?
Сейчас и не вспомню к сожалению) все через документацию
Как их закидывать? UI или по API?
API =) UI тулзы не смотрел
Сделать реестр схем первичным источником мне не удалось, так как из схемы автоматически вычищаются комментарии. А если одна и та же схема используется не только в Kafka, то это уже проблема. Например, эти комментарии нужны Swagger.
Странная статья. В самом начале приведен пример настройки поставщика, в котором почему-то задаются свойства получателя и десереализаторв используемых получателем. Дальше те-же непонятки... Ну и тема как реально реализуются декларируемые прелести использования avro как мне кажется совсем не раскрыта...
Управление схемами в Kafka с использованием Schema Registry