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

Question

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

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

В двух первых в моем списке находятся Gson и Avro.

Насколько я понимаю, Avro = Gson + Schema-In-JSON

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

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

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

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

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

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

Я действительно смущен этим!

Answer 1

1: Эволюция схемы

Предположим intially вы разработали схему, как это для вашего класса Employee

{ { "имя": "emp_name", "типа": "строка"}, { «название»: «д.р.», «тип»: «строка»}, { «имя»: «возраст», «тип»: «ИНТ»} }

Позже вы поняли, что возраст является излишним и удалить это из схемы.

{ { "имя": "emp_name", "тип": "строка"}, { "имя": "д.р.", "тип": "строка"} }

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

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

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

В данном случае это не пропустить действие, т.е. он выходит из чтения «возраста».Он может также обрабатывать случаи, как поле изменяется от ИНТ до тех пор и т.д ..

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

2: Схема хранится только один раз для нескольких записей в одном файле.

3: Размер, закодированный в очень немногих байтах.

Answer 2

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

Пример разъяснит это:

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

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

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

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