Архитектура и можности на 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 }

Зошто Луа? Луа е многу едноставен јазик. Врз основа на нашето искуство, неколку часа откако ќе го запознаат, луѓето почнуваат да пишуваат код кој го решава нивниот проблем. И ова не се само професионални програмери, туку, на пример, аналитичари. Покрај тоа, благодарение на jit компајлерот, Луа работи многу брзо.

Складирање

Складирањето складира постојани податоци. Пред зачувување, податоците се потврдуваат според шемата за податоци. За да го опишеме колото користиме продолжен формат Апачи Авро... Пример:

{
    "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 DBMS и GraphQL шема за пристап до податоци.

Поддржана е асинхрона репликација на податоци (се планира да се додаде синхрона).

Излезен процесор

Понекогаш е неопходно да се известат надворешните потрошувачи за пристигнувањето на нови податоци за оваа намена, постои улогата на Output процесорот; По зачувувањето на податоците, тие може да се пренесат на соодветниот управувач (на пример, да се доведат до формата што ја бара потрошувачот) - а потоа да се предаде на конекторот за испраќање. Овде се користи и ред за поправка: ако никој не го прифати објектот, администраторот може да се обиде повторно подоцна.

Скалирање

Улогите на конекторот, влезниот процесор и излезниот процесор се без државјанство, што ни овозможува да го размериме системот хоризонтално со едноставно додавање на нови примероци на апликација со овозможен саканиот тип на улога. Складирањето се користи за хоризонтално скалирање пристап за организирање кластер користејќи виртуелни кофи. По додавањето на нов сервер, некои од кофите од старите сервери се преместуваат на новиот сервер во позадина; ова им се случува транспарентно на корисниците и не влијае на работата на целиот систем.

Својства на податоци

Предметите можат да бидат многу големи и да содржат други предмети. Ние обезбедуваме атомичност на додавање и ажурирање податоци со складирање на објект со сите зависности во една виртуелна корпа. Ова го спречува објектот да се „рашири“ низ неколку физички сервери.

Поддржано е верзии: секое ажурирање на објект создава нова верзија и секогаш можеме да одвоиме време и да видиме како изгледал светот тогаш. За податоци за кои не е потребна долга историја, можеме да го ограничиме бројот на верзии или дури и да складираме само една - најновата - односно, во суштина да го оневозможиме верзиирањето за одреден тип. Исто така, можете да ја ограничите историјата по време: на пример, избришете ги сите објекти од одреден тип постари од 1 година. Поддржано е и архивирање: можеме да растоваруваме објекти постари од одреденото време, ослободувајќи простор во кластерот.

задачи

Меѓу интересните карактеристики, вреди да се забележи можноста за започнување задачи на распоред, на барање на корисникот или програмски од песокот:

Овде гледаме уште една улога - тркач. Оваа улога е без државјанство и дополнителни примероци на апликации со оваа улога може да се додадат во кластерот по потреба. Одговорноста на тркачот е да ги заврши задачите. Како што споменавме, можно е да се генерираат нови задачи од песокот; тие се зачувуваат во редица на складирање и потоа се извршуваат на тркачот. Овој тип на задача се нарекува Job. Имаме и тип на задача наречена Задача - ова се задачи дефинирани од корисникот кои се извршуваат според распоред (со користење на синтакса на cron) или на барање. За да започнеме и следиме такви задачи, имаме пригоден менаџер на задачи. За да биде достапна оваа функционалност, мора да ја овозможите улогата на распоредувачот; оваа улога има состојба, па затоа не се зголемува, што не е потребно; во исто време, како и сите други улоги, може да има реплика што почнува да работи ако господарот одеднаш одбие.

Дрвосечач

Друга улога се нарекува дрвосечач. Ги собира дневниците од сите членови на кластерот и обезбедува интерфејс за нивно поставување и прегледување преку веб-интерфејсот.

Услуги

Вреди да се спомене дека системот го олеснува креирањето на услуги. Во конфигурациската датотека, можете да одредите кои барања се испраќаат до управувачот напишан од корисникот кој работи во песокот. Во овој управувач, можете, на пример, да извршите некој вид аналитичко барање и да го вратите резултатот.

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

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, што ќе ви овозможи да разберете како е извршено барањето:

Секако, системот обезбедува внатрешни метрики што може да се соберат со помош на Прометеј и да се визуелизираат со помош на Графана.

Распоредување

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