Uue kursuse voolu käivitamise eel valmistasime huvitava materjali tõlke.
Ülevaade
Räägime üsna populaarset mustrist, mille abil rakendused kasutavad mitmeid andmehoidlaid, kus iga hoidla teenib oma eesmärke, näiteks andmete kanoniseerimise (MySQL jne), täiustatud otsinguvõimaluste tagamise (ElasticSearch jne), vahemälustamise (Memcached jne) ja muude funktsioonide jaoks. Tavaliselt toimib mitme andmehoidla kasutamisel üks neist peamise hoidlana, samas kui teised on tuletatud hoidlad. Ainsaks probleemiks on, kuidas neid andmehoidlaid sünkroniseerida.
Olemegi uurinud erinevaid mustreid, mis püüdsid lahendada mitme hoidla sünkroniseerimise probleemi, nagu kahekordne kirjutamine, jaotatud tehingud jne. Siiski on neil lähenemisviisidel olulised piirangud, mis puudutavad rakendatavust, usaldusväärsust ja hooldust. Peale andmete sünkroniseerimise on mõnedele rakendustele vajalik ka andmete rikastamine, kutsudes üles väliseid teenuseid.
Need for seamless data synchronization and enrichment led to the development of Delta. Ultimately, Delta serves as a cohesive, event-driven platform for data synchronization and enhancement.
Praegused lahendused
Topeltkanne
Andmehoidlate sünkroonimiseks saab kasutada topeltkannet, mis kirjutab esmalt ühte andmehoidlasse ja seejärel kohe pärast seda teise. Esimene kanne võib korduda, kuid teine võib katkeda, kui esimene ebaõnnestub pärast proovide arvu ammendumist. Siiski võivad kaks andmehoidlat sünkroonimisest loobuda, kui teise andmehoidla kanne ebaõnnestub. Selle probleemi lahendamiseks luuakse tavaliselt taastamisprotseduur, mis võib perioodiliselt üle kanda andmed esimesest andmehoidlast teise või teha seda ainult juhul, kui andmetes avastatakse erinevusi.
Probleemid:
Taastamisprotseduuri teostamine on spetsiifiline töö, mida ei saa taaskasutada. Lisaks jäävad andmed ladude vahel sünkroonneimatta seni, kuni taastamisprotseduur on läbi viidud. Lahendust raskendab, kui kasutatakse rohkem kui kahte andmehoidlat. Ja lõpuks, taastamisprotseduur võib suurendada koormust algsele andmeallikale.
Muutuste logimise tabel
Kui tabelite kogumis toimuvad muutused (nt salvestuse lisamine, uuendamine või kustutamine), lisatakse muutuste salvestused logimise tabelisse sama tehingu osana. Teine voog või protsess küsib pidevalt sündmusi logimise tabelist ja kirjutab need ühte või mehrere andmehoidlasse, vajadusel eemaldades sündmused logimise tabelist pärast kõigi hoidlate kinnitust.
Probleemid:
See must be implemented as a library ideally without modifying the using application code. In a polyglot environment, such a library should exist in any necessary language, but ensuring consistent function and behavior across languages is very challenging.
Another issue lies in obtaining schema changes in systems that do not support transactional schema changes [1][2], like MySQL. Therefore, the pattern for making the change (for example, schema modifications) and the transactional recording of it in the change log table does not always work.
Jaotatud Tehingud
Jaotatud tehingute abil saab jagada tehingu mitme erineva andmehoidla vahel, et operatsioon kas fikseeriks kõigis kasutatavates hoidlates või ei fikseeriks üheski.
Probleemid:
Jaotatud tehingud on väga suur probleem heterogeensete andmesalvestuste jaoks. Need võivad oma iseloomu tõttu tugineda vaid osalevate süsteemide väikseimale ühisele nimetajale. Näiteks XA-tehingud blokeerivad täitmise, kui rakenduse protsessi käigus toimub ettevalmistamise etapis rike. Lisaks ei paku XA ummistuste avastamist ja ei toeta optimistlikke paralleelsuse haldamise skeeme. Samuti ei toeta mõned süsteemid, nagu ElasticSearch, XA-d ega mingeid muid heterogeenseid tehingumudeleid. Seetõttu jääb atomaarsete kirjutamiste tagamine erinevates andmesalvestustehnoloogiates rakenduste jaoks endiselt väga keeruliseks ülesandeks [3].
Delta
Delta on välja töötatud, et ületada olemasolevatest andmete sünkroniseerimise lahendustest tulenevaid piiranguid, samuti võimaldab see andmete reaalajas rikastamist. Meie eesmärk oli eristada kõik need keerulised aspektid rakenduste arendajatelt, et nad saaksid täielikult keskenduda ärifunktsionaalsuse rakendamisele. Järgnevalt kirjeldame "Movie Search", mis on Delta tegelik kasutusjuht Netflixist.
Netflixis kasutatakse laialdaselt mikroteenuste arhitektuuri, kus iga mikroteenus teenindab tavaliselt üht tüüpi andmeid. Peamised filmiandmed on jagatud mikroteenusesse, mida nimetatakse Movie Service'iks, samuti seotud andmed, nagu tootjate, näitlejate, tarnijate ja nii edasi teave, millega tegelevad mitmed teised mikroteenused (nimelt Deal Service, Talent Service ja Vendor Service).
Ärikasutajad Netflix Studioses peavad sageli otsima filme erinevate kriteeriumide alusel, mistõttu on neil väga oluline, et nad saaksid otsida kõiki filme puudutavaid andmeid.
Enne Delta ilmumist pidi filmide otsingumeeskond saama andmed mitmest mikroteenusest enne filmide andmete indekseerimist. Lisaks pidi meeskond arendama süsteemi, mis perioodiliselt uuendaks otsinguindeksi, küsides muudatusi teistelt mikroteenustelt, isegi kui muudatusi ei toimunud. See süsteem muutus kiiresti keeruliseks ja seda oli raske toetada.
Joonis 1. Pollimisüsteem enne Delta.
Delta kasutuselevõtu järel on süsteem lihtsustatud sündmuste LKB (Logika-Kallake-Baas) süsteemiks, nagu on näidatud alloleval joonisel. CDC (Change-Data-Capture) sündmused saadetakse Keystone Kafka teemadesse Delta-Connector'i kaudu. Delta rakendus, mis on loodud Delta Stream Processing Framework'i (Flink'ile tuginev) abil, saab CDC-sündmusi teemast, rikastab neid, kutsudes teisi mikroteenuseid, ja lõpuks edastab rikastatud andmed otsingumällu Elasticsearch'is. Kogu protsess toimub peaaegu reaalajas, st niipea kui muudatused fikseeritakse andmehoidlasse, uuendatakse otsingumälusid.
Joonis 2. Andmepipeline Delta kasutamisel
Järgnevates jaotistes kirjeldame Delta-Connector'i tööd, mis ühendub andmehoidla ja avaldab CDC-sündmusi transportimise tasemel, mis on reaalajas andmete edastamise infrastruktuur, suunates CDC-sündmused Kafka teemadesse. Lõpus räägime Delta voogude töötlemise struktuurist, mida rakenduste arendajad saavad kasutada andmete töötlemise ja rikastamise loogika jaoks.
CDC (Change-Data-Capture)
Oleme välja töötanud CDC teenuse nimega Delta-Connector, mis suudab reaalajas jälgida andmehoidlas tehtud muudatusi ja kirjutada need voogu. Reaalajas muudatused saadakse tehingute logidelt ja andmehoidla dump'idelt. Dumpsid on vajalikud, kuna tehingute logid ei tantsi tavaliselt kogu muudatuste ajalugu. Muudatused serializeeritakse tavaliselt Delta sündmustena, mistõttu saaja ei pea muretsema, kust muudatused pärit on.
Delta-Connector toetab mitmeid lisafunktsioone, nagu:
- Võime kirjutada kohandatud väljunditesse mööda Kafka't.
- Võime aktiveerida käsitsi dump'id igal ajal kõigi tabelite, kindla tabeli või teatud peavõtmete jaoks.
- Dump'e saab võtta fleshedina, seega pole vaja alustada kõike algusest peale, kui juhtub viga.
- Tabelite lukustamine pole vajalik, mis on väga oluline, et andmebaasi kirjutamise liiklus ei oleks meie teenuse tõttu blokeeritud.
- Kõrge kättesaadavus AWS Availability Zones'i varukoopia eksemplaride tõttu.
Praegu toetame MySQL ja Postgressi, sealhulgas AWS RDS ja Aurora kasutamisel. Toetame ka Cassandra't (multi-master). Delta-Connectori kohta leiate rohkem teavet siit .
Kafka ja transpordikiht
Delta sündmuste transpordikiht on ehitatud platvormi sõnumiteenuse vahetuse peale .
Ajalooliselt on Netflixis sõnumite avaldamine optimeeritud keskenduma kättesaadavusele, mitte vastupidavusele (vt. ). Kompromissiks on potentsiaalne andmete mittevastavus erinevates piiriolukordades. Näiteks, ebapuhas liidrivalimine toob kaasa selle, et vastuvõtja võib potentsiaalselt dubleerida või kaotada sündmusi.
Delta puhul soovisime saada tugevamaid vastupidavuse garanteerimisi, et tagada CDC-sündmuste toimetamine tuletatud ladustamisse. Sel eesmärgil pakkusime spetsiaalselt kavandatud Kafka klastrit esmaklassilise objektina. Võite allpool vaadata mõningaid maakleri seadeid:
Keystone Kafka klastrites, ebapuhas liidrivalimine on tavaliselt lubatud väljaandja kättesaadavuse tagamiseks. See võib viia sõnumite kadumiseni, kui sünkroniseerimata koopiat valitakse liidrina. Uue kõrgelt usaldusväärse Kafka klastri jaoks on seade ebapuhas liidrivalimine välja lülitatud sõnumite kaotuse vältimiseks.
Samuti oleme suurendanud replication factor 2-lt 3-le ja minimum insync replicas 1-lt 2-le. Klastrisse kirjutavad väljaandjad nõuavad kõigilt teistelt acks'e, tagades, et 2 3-st koopiast omab kõige ajakohasemaid sõnumeid, mille väljaandja on saatnud.
Kui brokeri eksemplar lõpetab töö, asendab uus eksemplar vana. Kuid uuest brokerist peab jõudma sünkroniseerimata koopiatele, milleks võib kuluda mitu tundi. Selle stsenaariumi taastamise aega lühendades oleme hakanud kasutama andmete plokkhoidlat (Amazon Elastic Block Store) kohalike diskide asemel. Kui uus eksemplar asendab lõpetatud brokeri eksemplari, liitub ta EBS-mahuga, mis oli lõpetatud eksemplaril, ja hakkab uut sõnumit jõudma. See protsess vähendab viivituste kõrvaldamise aega mitmest tunnist mõne minutini, kuna uuest eksemplarist ei pea enam replitseerima tühi olek. Ühesõnaga, eraldi salvestus- ja brokeri elutsüklid vähendavad brokeri vahetuse mõju järsult.
Veelgi suurema andmeedastuse garantii tagamiseks oleme kasutanud kõikide sõnumikaotuste tuvastamiseks ekstreemsetes tingimustes (näiteks jaotuse juhi kellade desünkroniseerimine).
Striimimise töötlemise raamistik
Delta töötlemise tase on rajatud Netflix SPaaS platvormile, mis tagab Apache Flinki integreerimise Netflixi ökosüsteemiga. Platvorm pakub kasutajaliidest, mis haldab Flinki ülesannete juurutamist ja Flinki klastrite orkestreerimist meie konteinerihalduse platvormi Titus peal. Liides haldab ka ülesannete konfigureerimist ja võimaldab kasutajatel teha muudatusi konfigureerimises dünaamiliselt ilma Flinki ülesandeid uuesti kompileerimata.
Delta pakub voogedastuse (stream processing) andmete töötlemise raamistiku, mis põhineb Flinkil ja SPaaSil, mis kasutab annotatsioonide põhjal DSL (Domain Specific Language), et abstraktiseerida tehnilisi detaile. Näiteks, et määratleda samm, millega sündmused rikastatakse, kutsudes esile välist teenust, peavad kasutajad kirjutama järgmise DSL-i, ja raamistik loob selle põhjal mudeli, mis täidetakse Flinkis.
Joonis 3. Näidis rikastamisest DSL-is Delta-s
Kasutatav raamistik mitte ainult ei lühenda õpikõverat, vaid pakub ka üldisi vooprotsessi funktsioone, nagu dedupeerimine, skeematamu ja samuti paindlikkust ja tõrketaluvust levinud probleemide lahendamiseks.
Delta vooprotsessi raamistik koosneb kahest peamisest moodulist: DSL & API moodul ja käitusmoodul. DSL & API moodul pakub DSL-i ja UDF (kasutaja määratud funktsioon) API-d, et kasutajad saaksid kirjutada oma töötlemisloogikat (nt filtreerimine või teisendamine). Käitusmoodul pakub DSL-i parsi realiseerimist, mis loob sisemise esitluse töötlemise sammudest DAG mudelites. Teostuse komponent tõlgendab DAG mudeleid, et algatada tegelikud Flinki operaatorid ja lõpuks käivitada Flinki rakendus. Raamistiku arhitektuur on illustreeritud järgmises joonises.
Joonis 4. Delta vooprotsessi raamistiku arhitektuur
Sel lähenemisviisil on mitu eelist:
- Kasutajad saavad keskenduda oma äri loogikale, ilma et peaksid süvenema Flinki spetsiifikasse või SPaaSi struktuuri.
- Optimeerimine võib toimuda kasutajatele läbi nähtamatute muudatuste ja vead saavad parandatud ilma, et kasutaja koodi (UDF) oleks vaja muuta.
- Delta rakenduste töö on kasutajatele lihtsustatud, kuna platvorm pakub kohe paindlikkust ja katkestustaluvust, kogudes hulgaliselt üksikasjalikke mõõdikuid, mida saab kasutada teavitamiseks.
Kasutamine tootmises
Delta on tootmises töötanud juba üle aasta ja mängib võtmerolli paljudes Netflix Studio rakendustes. See on aidanud meeskondadel ellu viia selliseid kasutusvõimalusi nagu otsingu indekseerimine, andmete säilitamine ja sündmustega juhitavad töövood. Allpool on toodud Delta platvormi kõrgema taseme arhitektuuri ülevaade.
Joonis 5. Delta kõrgema taseme arhitektuur.
Tänud
Soovime tänada järgmisi inimesi, kes aitasid Delta loomisel ja arendamisel Netflixis: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang ja Zhenzhong Xu.
Allikad
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Veebipõhine sündmuste töötlemine. Commun. ACM 62(5): 43–49 (2019). DOI:
: «Data Build Tool Amazon Redshifti ladustamiseks».
Allikas: habr.com
