2017. aastal võitsime konkursi investeerimisharu tehingu tuumajõu väljatöötamiseks Alfa-Banki jaoks ja alustasime tööd (HighLoad++ 2018 esitluses investeerimisharu tuumast Vladimir Drynkin, investeerimisharu tehingu tuuma suuna juht). See süsteem pidi koguma tehinguandmeid erinevatest allikatest erinevates formaatides, ühtlustama andmed, talletama need ja võimaldama nendele juurdepääsu.
Arenduse käigus arenes süsteem ja sai juurde funktsionaalsust ning mingil hetkel mõistsime, et meil tekib midagi palju enamat kui lihtsalt rakendus, mis on loodud spetsiifiliste probleemide lahendamiseks: meil oli tekkinud jaotatud rakenduste ehitamise süsteem, millel on püsiv andmehoidla. Meie saadud kogemus andis aluse uuele tootusele — (TDG).
Soovin rääkida TDG arhitektuurist ja nendest lahendustest, mille oleme arendamise käigus leidnud, tutvustada teile peamist funktsionaalsust ja näidata, kuidas meie toode võib olla alus täielike lahenduste loomiseks.
Arhitektuuriliselt oleme süsteemi jaganud eraldi rollide, millest igaühel on vastutus teatud ülesannete lahendamiseks. Üks käivitatud rakenduse eksemplar rakendab ühte või mitut tüüpi rolli. Klusteris võib olla mitu sama tüüpi rolli:
Connector
Connector vastutab ühenduse eest välismaailmaga; tema ülesanne on vastu võtta päring, see analüüsida ja kui see õnnestub, saata andmed töötlemiseks sisendprotsessorile. Me toetame vormate HTTP, SOAP, Kafka, FIX. Arhitektuur võimaldab lihtsalt lisada uute formaatide tuge, peagi lisandub tugi IBM MQ-le. Kui päringu analüüs lõppes veaga, tagastab connector vea; vastasel juhul vastab ta, et päring töötati edukalt, isegi kui selle edasisel töötlemisel tekkis viga. See on tehtud spetsiaalselt selleks, et töötada süsteemidega, mis ei oska päringut uuesti saata — või vastupidi, teevad seda liiga järjekindlalt. Andmete kaotamise vältimiseks kasutatakse remondijärjekorda: objekt suunatakse esmalt sinna ja alles pärast edukat töötlemist eemaldatakse sealt. Administrator võib saada teateid objektide kohta, mis on jäänud remondijärjekorda, ja pärast tarkvaravea või riistvararikke kõrvaldamist teha uuesti katse.
Sisendprotsessor
Sisendprotsessor klassifitseerib saadud andmed iseloomulike omaduste järgi ning kutsub välja sobivad töötlejad. Töötlejad on kood keeles Lua, mis käivitatakse liivakastis, seega ei saa nad süsteemi toimimist mõjutada. Sel etapil saab andmeid viia nõutud vormi ning vajadusel käivitada ettearvamatult palju ülesandeid, mis võivad rakendada vajalikku loogikat. Näiteks tootes MDM (Master Data Management), mis on loodud Tarantool Data Grid'il, käivitame uue kasutaja lisamisel, et mitte aeglustada päringu töötlemist, kuldse kirje loomise eraldi ülesandena. Liivakast toetab lugemiseks, muutmiseks ja andmete lisamiseks mõeldud päringuid, võimaldab teatud funktsioone teostada kõigi storage tüüpi rollide puhul ning tulemuse aggregeerimist (map/reduce).
Töötlejad võivad olla kirjeldatud failides:
sum.lua
local x, y = unpack(...)
return x + yJa seejärel kuulutatud konfiguratsioonis:
functions:
sum: { __file: sum.lua }
Miks Lua? Lua on väga lihtne keel. Meie kogemuse järgi hakkavad inimesed vaid paar tundi pärast sellega tutvumist kirjutama koodi, mis lahendab nende probleeme. Ja see ei ole ainult professionaalsed arendajad, vaid näiteks ka analüütikud. Lisaks töötab Lua jit-kompilaatori tõttu väga kiiresti.
Salvestus
Storage salvestab püsivaid andmeid. Enne salvestamist tõendatakse, et andmed vastavad andmeskeemile. Skeemide kirjeldamiseks kasutame laiendatud formaati. . Näide:
{
"name": "Kasutaja",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Selle kirjelduse põhjal genereeritakse automaatselt DDL (Data Definition Language) Tarantul DB jaoks ja skeem andmete juurde pääsemiseks.
Toetatakse asünkroonselt andmete replikatsiooni (plaanis on lisada sünkroonne).
Väljundi töötleja
Mõnikord tuleb väliseid tarbijaid uute andmete saabumisest teavitada, selleks on olemas Output processori roll. Pärast andmete salvestamist võivad need olla edastatud vastavale töötlejale (näiteks et viia need tarbija nõutud vormi) - ja seejärel edastatakse need connectorile saatmiseks. Siin kasutatakse samuti parandusteenust: kui objekt ei ole kedagi aktsepteerinud, võib administraator proovida hiljem uuesti.
Mastaapimine
Connectori, input processori ja output processori rollidel ei ole seisundit, mis võimaldab meil süsteemi horisontaalselt skaleerida, lihtsalt lisades uusi rakenduse eksemplare vajaliku tüübi rolliga. Horisontaalsete skaalade jaoks kasutatakse storage'i klastri korraldamiseks virtuaalsete konteinerite abil. Uue serveri lisamisel liigub osa konteinetest vanadelt serveritelt taustal uuele serverile; see toimub kasutajate jaoks sujuvalt ja ei mõjuta kogu süsteemi tööd.
Andmete omadused
Objektid võivad olla väga suured ja sisaldada teisi objekte. Me tagame andmete lisamise ja uuendamise aatomilisuse, säilitades objekti koos kõigi sõltuvustega ühes virtuaalses mahutis. Nii välistame objekti "laiali valgumise" mitmetesse füüsilistesse serveritesse.
Toetatakse versioonimist: iga objekti uuendus loob uue versiooni, ja me saame alati teha ajas kärpe, et vaadata, milline maailm oli siis. Andmete puhul, mis ei vaja pikka ajalugu, saame piirata versioonide arvu või hoida ainult ühte — viimast, mis tähendab, et saame tegelikult välja lülitada versioonimise teatud tüübi jaoks. Samuti saame piirata ajalugu ajaliselt: näiteks kustutada kõik teatud tüüpi objektid, mis on üle 1 aasta vanad. Toetatakse ka arhiveerimist: me saame eksportida objektid, mis on vanemad kui määratud aeg, vabastades ruumi klastris.
Ülesanded
Huvitavatest funktsioonidest tasub märkida võimalust ülesannete käivitamiseks ajakava järgi, kasutaja päringu alusel või programmiliselt liivakastist:
Siin näeme veel ühte rolli — runner. See roll ei oma olekut, ning vajadusel saab klastrisse lisada täiendavaid rakenduse eksemplare selle rolliga. Runneri ülesanne on ülesannete täitmine. Nagu on öeldud, on võimalik liivakastist genereerida uusi ülesandeid; need salvestatakse storage'i järjekorda ja hiljem täidetakse runneris. Seda tüüpi ülesandeid nimetatakse Job'iks. Samuti on meil ülesandete tüüp, mida nimetatakse Task'iks — need on kasutaja määratud ülesanded, mis käivitatakse kas ajakava järgi (kasutatakse cron süntaksit) või nõudmisel. Nende ülesannete käivitamiseks ja jälgimiseks on meil mugav ülesannete haldur. Selle funktsionaalsuse kasutamiseks peab olema sisse lülitatud scheduleri roll; see roll omab olekut, mistõttu see ei ole skaleeritav, kuigi see pole vajalik; samas võib sellel olla replikatsioon, mis hakkab tööle, kui master peaks äkki ebaõnnestuma.
Logger
Teine roll kannab nime logger. See kogub logisid kõigilt klastriliikmetelt ning pakub liidese nende väljundiks ja vaatamiseks läbi veebiliidese.
Teenused
Väärib mainimist, et süsteem võimaldab hõlpsasti teenuseid luua. Konfiguratsioonifailis saab määrata, millised päringud suunatakse kasutaja kirjutatud töötlejale, mis töötab liivakastis. Selles töötlejas saab näiteks teostada mõne analüütilise päringu ja tagastada tulemuse.
Teenust kirjeldatakse konfiguratsioonifailis:
teenused:
sum:
doc: "liidab kaks numbrit"
funktsioon: sum
tagastustüüp: int
argumendid:
x: int
y: int
GraphQL API genereeritakse automaatselt ja teenus muutub kättevõtmiseks kättesaadavaks:
päring {
sum(x: 1, y: 2)
} See kutsub välja töötlejat sum, mis tagastab tulemuse:
3
Päringute profiilimine ja mõõdikud
Süsteemi töö ja päringute profiilimise mõistmiseks oleme rakendanud OpenTracing protokolli toe. Süsteem võib nõudmisel saata teavet protokolli toetavatele tööriistadele, näiteks Zipkin, mis aitab mõista, kuidas päring tehti:
Muidugi pakub süsteem sisemisi mõõdikuid, mida saab koguda Prometheuse abil ja visualiseerida Grafana abil.
Juhtimistöö
Tarantool Data Grid saab juurutada RPM-pakettide või arhiivi kaudu, kasutades tarnimiselt saadud utiliite või Ansible'i, samuti on saadaval toetus Kubernetes'ele ().
Äpis, mis rakendab äriloogikat (konfiguratsioon, töötlejate) laaditakse juurutatud Tarantool Data Grid klastrisse arhiivina läbi kasutajaliidese või skripti abil, meie pakutava API kaudu.
Rakenduse näited
Milliseid rakendusi saab luua Tarantool Data Gridiga? Tegelikult on enamik äriprobleeme mingil moel seotud andmevoogude töötlemise, nende salvestamise ja neile juurdepääsuga. Seetõttu, kui teil on suured andmevood, mida tuleb usaldusväärselt salvestada ja neile juurde pääseda, siis meie toode võib säästa teile palju arendusaja, võimaldades keskenduda oma äriloogikale.
Näiteks soovime koguda teavet kinnisvaraturu kohta, et hiljem näiteks saada teavet kõige soodsamatest pakkumistest. Sel juhul eristame järgmisi ülesandeid:
- Robotid, mis koguvad teavet avatud allikatest - need on meie andmeallikad. Selle ülesande saate lahendada, kasutades valmis lahendusi või kirjutades koodi mis tahes keeles.
- Edasi võtab ja salvestab Tarantool Data Grid andmed. Kui andmeformaat erinevates allikates erineb, võite kirjutada koodi Lua keeles, mis viib selle ühtsesse formaati. Eelprotsessimise etapis saate näiteks filtreerida korduvaid lauseid või värskendada andmebaasis agentide kohta olevat teavet, kes turul tegutsevad.
- Nüüd on teil juba skaleeritav lahendus klastris, millega saab andmeid täita ja andmeid välja teha. Edasi saate rakendada uusi funktsioone, näiteks kirjutada teenuse, mis teeb päringu andmetele ja esitab kõige kasumlikuma pakkumise ühe päeva jooksul — see nõuab vaid paari rida konfiguratsioonifailis ja natuke koodi Lua keeles.
Mis edasi?
Meie prioriteet on arendamise mugavuse suurendamine . Näiteks on see IDE, mis toetab profiilimist ja silumist, mis töötab liivakastis.
Me pöörame ka suurt tähelepanu turvaküsimustele. Praegu läbime Venemaa FSTEK sertifitseerimist, et kinnitada kõrge turvalisuse tase ja vastata tarkvarade sertifitseerimise nõuetele, mida kasutatakse isikuandmete ja riiklike teabe süsteemide infosüsteemides.
Allikas: habr.com
