КАРКАС СЕРИАЛИЗАЦИИ APACHE THRIFT

Каркас сериализации Apache Thrift

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

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

В основу Thrift положены определения типов struct и union. Они, в свою очередь, состоят из полей других типов, включая следующие.

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

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

Узлы

В узлах пользователей граф-схемы приложения отдельный пользователь обозначается своим идентификатором или cookie-файлом из браузера, но не тем и другим вместе. Такой шаблон является типичным для узлов и точно соответствует типу данных union с единственным значением, которое может иметь самые разные представления.

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

union PersonID {

    1: string cookie;

    2: i64 user_id;

}

union Page ID {

    1: string url;

}

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

Ребра

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

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

struct EquivEdge {

    1: required PersonID id1;

    2: required PersonID id2;

}

struct PageViewEdge {

    1: required PersonID person;

    2: required Page ID page;

    3: required i64 nonce;

}

Поля структуры в Thrift могут быть обозначены как required или optional. Если поле определяется как required, то для него требуется предоставить значение, иначе Thrift выдаст ошибку по завершении сериализации или десериализации. Каждое ребро в граф-схеме должно соединять два узла и поэтому в данном примере они представлены обязательными полями.

Свойства

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

Итак, начнем с определения осуществимой схемы для свойств страницы. Для страниц имеется только одно свойство, и поэтому его схема определяется очень просто:

union PagePropertyValue {

    1: i32 page_views;

}

struct PageProperty {

    1: required PagelD id;

    2: required PagePropertyValue property;

}

Далее определим свойства для людей. Как показано ниже, свойство места жительства оказывается более сложным и требует определения другой структуры.

struct Location {

    1: optional string city;

    2: optional string state;

    3: optional string country;

}

enum GenderType {

    MALE - 1,

    FEMALE = 2

}

union PersonPropertyValue {

    1: string full_name;

    2: GenderType gender;

    3: Location location;

}

Struct PersonProperty {

    1: required PersonID id;

    2: required PersonPropertyValue property;

}

Структура места жительства Location интересна тем, что поля city, state и country могут быть сохранены в виде отдельных фрагментов данных. В данном случае они настолько тесно связаны, что их имеет смысл разместить в одной структуре в виде необязательных нолей типа optional. Все эти поля практически всегда требуются для потребления информации о месте жительства

Связывание всего вместе в объекты данных

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

С этой целью тип каждого свойства и ребра заключается в оболочку объединения DataUnit, как демонстрируется в приведенном ниже листинге.

union DataUnit {

    1: PersonProperty person_property;

    2: PageProperty page_property;

    3: EquivEdge equiv;

    4: PageViewEdge page_view;

}

struct Pedigree {

    1: required i32 true_as_of_secs;

}

struct Data {

    1: required Pedigree pedigree;

    2: required DataUnit dataunit;

}

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

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

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