В чем преимущество хранения схемы в avro?

Нам нужно сериализовать некоторые данные для ввода в solr, а также в hadoop.

Я оцениваю инструменты сериализации для того же самого.

Если это правильно, я не понимаю, почему Avro настолько популярен для Solr/Hadoop?

Я много искал в Интернете, но не могу найти для этого ни одного правильного ответа.

Всюду, где говорится, Avro хорошо, потому что хранит схему. Мой вопрос в том, что делать с этой схемой?

Это может быть полезно для очень больших объектов в Hadoop, где один объект хранится в нескольких файловых блоках, так что хранение схемы с каждой частью помогает лучше ее анализировать. Но даже в этом случае схема может храниться отдельно, и просто ссылки на нее достаточно для описания схемы. Я не вижу причин, почему схема должна быть частью каждой части.

Если кто-то может дать мне хороший пример использования, как Авро помог им, а Гссона/Джексона было недостаточно для этой цели, это было бы очень полезно.

Кроме того, официальная документация на сайте Avro говорит, что нам нужно предоставить схему Avro, чтобы помочь ей создать Schema + Data. Мой вопрос заключается в том, что если схема введена и она отправляется на вывод вместе с представлением данных JSON, то что же еще делает Avro? Могу ли я сделать это сам, сериализуя объект с помощью JSON, добавив мою схему ввода и назвав ее Avro?

Ответы

Ответ 1

Развивающиеся схемы

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

{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"},
{"name":"age", "type":"int"}
}

Позже вы поняли, что age избыточен, и удалили его из схемы.

{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"}
}

Как насчет записей, которые были сериализованы и сохранены до изменения этой схемы. Как вы будете читать эти записи?

Поэтому avro reader/deserializer запрашивает схему чтения и записи. Внутренне это делает разрешение схемы т.е. он пытается адаптировать старую схему к новой схеме.

Перейдите по этой ссылке - http://avro.apache.org/docs/1.7.2/api/java/org/apache/avro/io/parsing/doc-files/parsing.html - раздел "Разрешение с использованием символов действий".

В этом случае он пропускает действие, то есть пропускает чтение "возраст". Он также может обрабатывать такие случаи, как изменение поля с int на long и т.д.

Это очень хорошая статья, объясняющая эволюцию схемы - http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html

Схема сохраняется только один раз для нескольких записей в одном файле.
Размер, закодированный в очень немногих байтах.

Ответ 2

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

Пример пояснит это:

Скажем, банк хранит журнал аудита всех своих транзакций. Журналы имеют особый формат и должны храниться не менее 10 лет. Также очень желательно, чтобы система, содержащая эти журналы, должна адаптироваться к формату, развивающемуся за все эти 10 лет.

Схема для таких записей не будет меняться слишком часто, скажем, дважды в год в среднем, но каждая схема будет иметь большое количество записей. Если мы не будем отслеживать схемы, то через некоторое время нам нужно будет проконсультироваться с очень старым кодом, чтобы выяснить, какие поля присутствуют на тот момент, и продолжать добавлять инструкции if-else для обработки разных форматов. Благодаря хранилищу схем всех этих форматов мы можем использовать функцию эволюции схемы, чтобы автоматически преобразовывать один вид формата в другой (Avro делает это автоматически, если вы предоставляете ему более старые и новые схемы). Это позволяет сэкономить приложения, добавляя в их код множество инструкций if-else, а также делает его более управляемым, поскольку мы с готовностью знаем, какие все форматы мы имеем, просматривая набор сохраненных схем (схемы обычно хранятся в отдельном хранилище и данные имеют только идентификатор, указывающий на его схему).

Еще одно преимущество эволюции схемы заключается в том, что производители нового формата могут безопасно создавать объекты с новой схемой, не дожидаясь, когда последующие пользователи сначала изменятся. Потребители в нисходящем потоке могут иметь встроенную логику, чтобы просто приостановить обработку, если у них нет видимости новой схемы, связанной с новым форматом. Эта автоматическая подвеска отлично подходит для онлайн-системы и адаптирует логику обработки для новой схемы.

Итак, вкратце, эволюция схемы помогает новым клиентам читать старые форматы, используя автоматическое преобразование формата, а также помогает старым клиентам приостанавливать обработку изящным образом, пока они не смогут понять новые форматы.