Архитектура и възможности на Tarantool Data Grid

През 2017 г. спечелихме конкурс за разработване на транзакционното ядро ​​на инвестиционния бизнес на Alfa-Bank и започнахме работа (на HighLoad++ 2018 с доклад за същността на инвестиционния бизнес говореше Владимир Дринкин, ръководител на транзакционното ядро ​​на инвестиционния бизнес на Алфа Банк). Тази система трябваше да събира данни за транзакции от различни източници в различни формати, да привежда данните в унифицирана форма, да ги съхранява и да осигурява достъп до тях.

В процеса на разработка системата се разви и придоби функционалност и в един момент осъзнахме, че изкристализираме нещо много повече от просто приложен софтуер, създаден за решаване на строго определен набор от задачи: успяхме система за изграждане на разпределени приложения с постоянно съхранение. Натрупаният опит е в основата на нов продукт - Tarantool Data Grid (TDG).

Искам да говоря за TDG архитектурата и решенията, до които стигнахме по време на процеса на разработка, да ви запозная с основната функционалност и да покажа как нашият продукт може да стане основа за изграждане на цялостни решения.

Архитектурно разделихме системата на отделни роля, всеки от които отговаря за решаването на определен кръг от проблеми. Едно работещо приложение изпълнява един или повече типове роли. В клъстер може да има няколко роли от един и същи тип:

Съединител

Конекторът отговаря за комуникацията с външния свят; неговата задача е да приеме заявката, да я анализира и ако това успее, да изпрати данните за обработка на входния процесор. Ние поддържаме HTTP, SOAP, Kafka, FIX формати. Архитектурата ви позволява просто да добавите поддръжка за нови формати, като скоро ще има поддръжка за IBM MQ. Ако анализирането на заявката е неуспешно, конекторът ще върне грешка; в противен случай той ще отговори, че заявката е обработена успешно, дори ако е възникнала грешка по време на по-нататъшната й обработка. Това беше направено специално, за да се работи със системи, които не знаят как да повтарят заявки - или, напротив, правят го твърде упорито. За да не се губят данни, се използва опашка за поправка: обектът първо влиза в нея и едва след успешна обработка се премахва от нея. Администраторът може да получава предупреждения за обекти, останали в опашката за поправка, и след отстраняване на софтуерна грешка или хардуерен срив, опитайте отново.

Входящ процесор

Входният процесор класифицира получените данни според характерни признаци и извиква подходящи процесори. Манипулаторите са Lua код, който се изпълнява в пясъчна среда, така че не могат да повлияят на функционирането на системата. На този етап данните могат да бъдат редуцирани до необходимата форма и, ако е необходимо, могат да бъдат стартирани произволен брой задачи, които могат да реализират необходимата логика. Например, в продукта MDM (Master Data Management), изграден върху Tarantool Data Grid, при добавяне на нов потребител, за да не забавяме обработката на заявката, стартираме създаването на златен запис като отделна задача. Пясъчникът поддържа заявки за четене, промяна и добавяне на данни, позволява ви да изпълнявате някои функции за всички роли на типа съхранение и агрегиране на резултата (карта/намаляване).

Манипулаторите могат да бъдат описани във файлове:

sum.lua

local x, y = unpack(...)
return x + y

И след това, декларирано в конфигурацията:

functions:
  sum: { __file: sum.lua }

Защо Lua? Lua е много прост език. Въз основа на нашия опит, няколко часа след като се запознаят с него, хората започват да пишат код, който решава проблема им. И това не са само професионални разработчици, но, например, анализатори. Освен това, благодарение на jit компилатора, Lua работи много бързо.

Съхранение

Съхранението съхранява постоянни данни. Преди записване данните се валидират спрямо схемата на данните. За да опишем веригата, използваме разширен формат Apache Avro, Пример:

{
    "name": "User",
    "type": "record",
    "logicalType": "Aggregate",
    "fields": [ 
        { "name": "id", "type": "string"}, 
        {"name": "first_name", "type": "string"}, 
        {"name": "last_name", "type": "string"} 
    ], 
    "indexes": ["id"] 
}

Въз основа на това описание автоматично се генерира DDL (Език за дефиниране на данни) за СУБД на Tarantula и GraphQL схема за достъп до данни.

Поддържа се асинхронна репликация на данни (има планове за добавяне на синхронна).

Изходен процесор

Понякога е необходимо да се уведомят външни потребители за пристигането на нови данни, за тази цел има ролята на изходен процесор. След запазване на данните, те могат да бъдат предадени на съответния манипулатор (например, за да бъдат приведени във формата, изисквана от потребителя) - и след това предадени на конектора за изпращане. Тук също се използва опашка за поправка: ако никой не е приел обекта, администраторът може да опита отново по-късно.

мащабиране

Ролите на конектора, входния процесор и изходния процесор са без състояние, което ни позволява да мащабираме системата хоризонтално чрез просто добавяне на нови екземпляри на приложение с разрешен желания тип роля. Съхранението се използва за хоризонтално мащабиране подход за организиране на клъстер с помощта на виртуални кофи. След добавяне на нов сървър, някои от кофите от старите сървъри се преместват на новия сървър във фонов режим; това се случва прозрачно за потребителите и не засяга работата на цялата система.

Свойства на данните

Обектите могат да бъдат много големи и да съдържат други обекти. Ние гарантираме атомарност на добавянето и актуализирането на данни, като съхраняваме обект с всички зависимости в една виртуална кофа. Това предотвратява „разпръскването“ на обекта в няколко физически сървъра.

Поддържа се версия: всяка актуализация на обект създава нова версия и винаги можем да вземем времеви отрязък и да видим как е изглеждал светът тогава. За данни, които не се нуждаят от дълга история, можем да ограничим броя на версиите или дори да съхраняваме само една - най-новата - тоест по същество да деактивираме версията за определен тип. Можете също така да ограничите историята по време: например да изтриете всички обекти от определен тип, по-стари от 1 година. Поддържа се и архивиране: можем да разтоварим обекти, по-стари от определеното време, освобождавайки място в клъстера.

задачи

Сред интересните функции си струва да се отбележи възможността за стартиране на задачи по график, по искане на потребителя или програмно от пясъчника:

Тук виждаме още една роля - бегач. Тази роля е без състояние и допълнителни екземпляри на приложение с тази роля могат да бъдат добавени към клъстера, ако е необходимо. Отговорността на бегача е да изпълнява задачи. Както споменахме, възможно е да генерирате нови задачи от пясъчника; те се записват в опашка при съхранение и след това се изпълняват в програмата за изпълнение. Този тип задача се нарича работа. Имаме и тип задача, наречена Task - това са дефинирани от потребителя задачи, които се изпълняват по график (използвайки синтаксис на cron) или при поискване. За стартиране и проследяване на такива задачи имаме удобен мениджър на задачи. За да бъде налична тази функционалност, трябва да активирате ролята на планировчик; тази роля има състояние, така че не се мащабира, което не се изисква; в същото време, както всички други роли, може да има реплика, която започва да работи, ако капитанът внезапно откаже.

дървар

Друга роля се нарича logger. Той събира регистрационни файлове от всички членове на клъстера и предоставя интерфейс за качване и преглед през уеб интерфейса.

Услуги

Заслужава да се спомене, че системата улеснява създаването на услуги. В конфигурационния файл можете да посочите кои заявки да се изпращат до написан от потребителя манипулатор, който се изпълнява в пясъчника. В този манипулатор можете например да стартирате някаква аналитична заявка и да върнете резултата.

Услугата е описана в конфигурационния файл:

services:
   sum:
      doc: "adds two numbers"
      function: sum
      return_type: int
      args:
         x: int
         y: int

GraphQL API се генерира автоматично и услугата става достъпна за извикване:

query {
   sum(x: 1, y: 2) 
}

Това ще извика манипулатора sumкоето ще върне резултата:

3

Профилиране на заявки и показатели

За да разберем работата на системата и заявките за профилиране, внедрихме поддръжка за протокола OpenTracing. Системата може да изпраща информация при поискване до инструменти, които поддържат този протокол, като Zipkin, което ще ви позволи да разберете как е изпълнена заявката:

Естествено, системата предоставя вътрешни показатели, които могат да бъдат събрани с помощта на Prometheus и визуализирани с помощта на Grafana.

Разположете

Tarantool Data Grid може да се внедри от RPM пакети или архив, като се използва помощна програма от дистрибуцията или Ansible, има и поддръжка за Kubernetes (Tarantool Kubernetes оператор).

Приложението, което реализира бизнес логиката (конфигурация, манипулатори), се зарежда в разгърнатия Tarantool Data Grid клъстер под формата на архив чрез потребителския интерфейс или чрез използване на скрипт чрез предоставения от нас API.

Буквари на философията

Какви приложения могат да бъдат създадени с помощта на Tarantool Data Grid? Всъщност повечето бизнес задачи по някакъв начин са свързани с обработката, съхранението и достъпа до потока от данни. Следователно, ако имате големи потоци от данни, които трябва да бъдат сигурно съхранявани и достъпни, тогава нашият продукт може да ви спести много време за разработка и да се съсредоточи върху вашата бизнес логика.

Например искаме да събираме информация за пазара на недвижими имоти, така че в бъдеще например да имаме информация за най-добрите оферти. В този случай ще подчертаем следните задачи:

1. Роботи, които събират информация от отворени източници, ще бъдат нашите източници на данни. Можете да разрешите този проблем, като използвате готови решения или като напишете код на всеки език.
2. След това Tarantool Data Grid ще приеме и запази данните. Ако форматът на данните от различни източници е различен, тогава можете да напишете код в Lua, който ще извърши преобразуването в един формат. На етапа на предварителна обработка ще можете например да филтрирате дублиращи се оферти или допълнително да актуализирате информация за агенти, работещи на пазара в базата данни.
3. Сега вече имате мащабируемо решение в клъстер, който може да се запълва с данни и да се избират данни. След това можете да внедрите нова функционалност, например да напишете услуга, която ще направи заявка за данни и ще даде най-изгодната оферта на ден - това ще изисква няколко реда в конфигурационния файл и малко Lua код.

Каква е следващата?

Нашият приоритет е да подобрим лекотата на използване на разработката Tarantool Data Grid. Например, това е IDE с поддръжка за манипулатори за профилиране и отстраняване на грешки, работещи в пясъчна среда.

Обръщаме голямо внимание и на въпросите за безопасността. В момента сме в процес на сертифициране от FSTEC на Русия, за да потвърдим високото ниво на сигурност и да отговорим на изискванията за сертифициране на софтуерни продукти, използвани в информационни системи за лични данни и държавни информационни системи.

Източник: www.habr.com