РАЗВИТИЕ ОСУЩЕСТВИМОЙ СХЕМЫ APACHE THRIFT

Многие разработчики идут по пути представления необработанных данных в таком бессхемном формате, как JSON. Этот пусть привлекателен той простотой, с которой он начинается, но очень быстро он приводит к серьезным затруднениям. Искажение данных неизбежно происходит или по причине недоразумений между разными разработчиками, или из-за программных ошибок. Как показывает наш опыт, ошибки, приводящие к искажению данных, отнимают больше всего времени на их исправление.

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

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

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

Развитие осуществимой схемы Apache Thrift

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

• Поля могут быть переименованы. Дело в том, что для распознавания полей в сериализированной форме объекта используются идентификаторы полей, а не имена.
• Поле может быть удалено, но идентификатор этого поля нельзя употреблять снова. При десериализации существующих данных Thrift проигнорирует все поля с идентификаторами, не включенными в схему. Если попытаться воспользоваться идентификатором удаленного ранее поля, Thrift попробует десериализировать эти прежние данные в новом поле, что сделает данные недостоверными или неверными.
• В существующие структуры могут быть введены только необязательные поля. Вводить обязательные поля нельзя, поскольку существующие данные не будут содержать эти поля, а, следовательно, они не подлежат десериализации. (Следует, однако, иметь в виду, что данное правило не распространяется на объединения, поскольку в них вообще отсутствует понятие обязательных и необязательных полей.)

Ограничения, присущие каркасам сериализации

Каркасы сериализации лишь проверяют наличие в осуществимой схеме всех обязательных полей и их соответствие предполагаемым типам. Они неспособны производить более сложные проверки свойств вроде “неотрицательных величин возраста" или “употребления в будущем отметок времени об истинности данных” в настоящем. Данные, не соответствующие этим свойствам, могут указывать на затруднение в системах, и вряд ли их стоит записывать в главный массив данных.

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

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

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

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

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

Резюме

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

Список литературы:

1. Марц, Натан, Уорен, Джеймс. Большие данные: принципы и практика построения масштабируемых систем обработки данных в реальном времени.: Пер. с англ. — М.: ООО “И.Д.Вильямс”, 2016 – 368 с.: ил. — Парал. Тит. Англ.