1.4. Представление модели

1.4. Представление модели¶

При эксплуатации TDG объекты могут поступить в систему постфактум, а запросы к системе могут быть сделаны по функциональному срезу для определенной бизнес-даты.

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

Avro схему модели (единый формат);
конвейеры обработки входящих объектов;
код Lua-функций, составляющих конвейеры и методы объектов модели;
(потенциально) фабрики объектов;
(потенциально) триггеры;
(потенциально) описание сервисов.

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

Чтобы версионировать собственную структуру, система использует следующие форматы конфигурации для разных целей:

Внутренний формат – для передачи конфигурации по сети.
Экспортный формат – для загрузки начальной модели при первичном старте системы, а также для загрузки конфигурации в тестах.
Экспортный формат бандла (комплекта) модели – для передачи разработчикам.

1.4.1. Внутренний формат конфигурации¶

Узлы кластера передают конфигурацию по сети и хранят ее в следующем формате:

{
    "functions": {
        "function_name": "function_code"
        ...
    },
    "pipelines": {
        "pipeline_name": ["function1_name", "function2_name", ...],
        ...
    },
    "classifiers": {
        "classifier_name": "pipeline_name/function_name",
        ...
    },
    "routing": {
        "routing_key": "pipeline_name/function_name",
        ...
    },
    "storage": {
        "routing_key": "type_name"
    },
    "schema": <avro_schema>
}

где:

functions – набор функций, которые используются в классификаторах, маршрутизаторах и объектах модели;
pipelines – конвейеры, в которых функции применяются к объекту по цепочке;
classifiers – позволяют получить ключ маршрутизации для объекта;
routing – функции, позволяющие менять ключ маршрутизации объекта;
storage – хранилище для объектов с соответствующими ключами маршрутизации;
function_name – имя (идентификатор) Lua-функции;
function_code – код Lua-функции (исполняемый в «песочнице»);
pipeline_name – имя конвейера;
classifier_name – имя классификатора;
routing_key – строковый ключ маршрутизации.

Также в формате присутствует поле schema, формат которого описан в разделе о доменной модели. В этом поле хранится структурное (а не строковое) ее представление.

1.4.2. Внешний (экспортный) формат¶

Экспортный формат используется для загрузки начальной модели при первичном старте системы, а также для загрузки конфигурации в тестах.

Экспортный формат соответствует внутреннему, за исключением следующих полей:

Вместо function_code – function_file_name, файл, в котором находится код Lua функции.
Вместо avro_schema – avro_file_name, файл, в котором сериализована Avro схема модели.

Корневой объект сохраняется в файле config.yml; код функций – в соответствующие файлы с расширением .lua, рядом; а схема – в файл schema.avsc.

1.4.3. Экспортный формат бандла моделей¶

Экспортный формат бандла (комплекта) может использоваться для удобной передачи разработчикам модели, загруженной в систему. Бандл – папка, содержащая в себе набор моделей, каждая в своей подпапке. Подпапки названы по бизнес-времени действия модели (а не по фактическому времени добавления).

Например:

bundle/
├── 2018-01-03T18:56:00Z
|   ├── config.yml
|   ├── schema.avsc
|   ├── function_1.lua
|   └── function_2.lua
└── 2018-03-05T00:41:00Z
    ├── config.yml
    ├── schema.avsc
    └── function_3.lua

Такой экспортный формат содержит только конфигурацию модели, но не содержит конфигурацию топологии системы или связи с внешними системами.