Uue kursuse voolu käivitamise eel valmistasime huvitava materjali tõlke.
Ülevaade
Räägime üsna populaarsetest mustritest, mille abil rakendused kasutavad mitmeid andmehoidlaid, kus iga andmehoidla on mõeldud oma eesmärkide jaoks, näiteks andmete kanonilise vormi (MySQL jne) salvestamiseks, täiustatud otsinguvõimaluste tagamiseks (ElasticSearch jne), vahemällu salvestamiseks (Memcached jne) ja muuks. Tavalise praktikana on ühe andmehoidla keskne kasutamine, samas kui teised toimivad kui tuletatud andmehoidlad. Ainuke probleem seisneb selles, kuidas neid andmehoidlaid sünkroonida.
Olemegi uurinud mitmeid erinevaid mustreid, mis üritasid lahendada mitme andmehoidla sünkroniseerimise probleemi, näiteks kahetine kirjutamine, jaotatud tehingud jne. Siiski on nende lähenemisviisidel reaalses elus, usaldusväärsuses ja hooldamises olulised piirangud. Lisaks andmete sünkroonimisele peavad mõned rakendused ka rikastama andmeid, kutsudes väliseid teenuseid.
Nende probleemide lahendamiseks loodi Delta. Delta esindab lõpuks kooskõlastatud, sündmustel põhinevat platvormi andmete sünkroonimiseks ja rikastamiseks.
Olemasolevad lahendused
Kahetine kirjutamine
Kaht andmehoidla sünkroonimiseks saab kasutada kahetist kirjutamist, mis kirjutab andmed ühte hoidlasse ja seejärel kohe pärast seda teise. Esimest kirjutamist võib korrata, samas kui teist saab katkestada, kui esimene ebaõnnestub pärast katsete arvu ammendumist. Siiski võivad kaks andmehoidlat lõpetada sünkroonimise, kui teise hoidlasse kirjutamine ebaõnnestub. Selle probleemi lahendamiseks luuakse tavaliselt taastamisprotseduur, mis võib perioodiliselt andmeid esimesest hoidlasse teise tuua või teha seda vaid siis, kui andmetes leitakse erinevusi.
Probleemid:
Taasteprotsessi läbiviimine on spetsiifiline töö, mida ei saa kasutusele võtta. Lisaks jäävad andmed salvestite vahel sünkroonimata kuni taasteprotsess on lõpetatud. Probleem muutub keerulisemaks, kui kasutatakse rohkem kui kahte andmesalvestust. Ja lõpuks võib taasteprotsess lisada koormust andmeallika algsetele andmetele.
Muudatuste logimise tabel
Kui tabelikogumis toimuvad muutused (nt kirje lisamine, uuendamine ja kustutamine), lisatakse muudatuste kirjed logimistabelisse sama tehingu osana. Teine voog või protsess küsib pidevalt sündmusi logimistabelist ja talletab need ühte või mitmesse andmesalvestusse, vajadusel kustutades sündmused logimistabelist, kui kõik salvestused on kirje kinnitanud.
Probleemid:
Seda mustrit peaks rakendama raamatukoguna ja ideaalis ilma rakenduskoodi muutmata, mis seda kasutab. Poliglotikeskkonnas peaks selline raamatukogu olema olemas igas vajalikus keeles, kuid funktsioonide ja käitumise ühtsuse tagamine keelte vahel on väga keeruline.
Teine probleem seisneb skeemimuudatuste saamisel süsteemides, mis ei toeta tehingulisi skeemimuudatusi [1][2], nagu näiteks MySQL. Seetõttu ei pruugi skeemimuudatuste rakendamise mall ja selle tehingulisus logimistabelisse alati tööle hakata.
Jagatud Tehingud
Jagatud tehinguid saab kasutada, et jagada tehing mitme erineva andmesalvestuse vahel nii, et operatsioon kas kinnitatakse kõigis kasutatavates salvestustes või ei kinnitata üheski neist.
Probleemid:
Jagatud tehingud on väga suur probleem heterogeensete andmete salvestamiseks. Omakorda võivad nad toetuda ainult osalevate süsteemide väikseimale ühisosale. Näiteks XA-tehingud blokeerivad täitmise, kui rakenduse protsessis toimub viga ettevalmistuse etapil. Lisaks ei paku XA ummikute avastamist ja ei toeta optimistlikke paralleelsuse juhtimise skeeme. Lisaks ei toeta mõned süsteemid nagu ElasticSearch XA-d või ühtegi muud heterogeenset tehingute mudelit. Seega jääb andmete kirjutamise atomaarne tagamine erinevates andmesalvestustehnoloogiates rakenduste jaoks väga keeruliseks ülesandeks [3].
Delta
Delta on välja töötatud, et kõrvaldada olemasolevate andmete sünkroonimise lahenduste piirangud ning see võimaldab andmeid rikastada reaalajas. Meie eesmärk oli abstraheerida kõik need keerulised aspektid rakenduse arendajatelt, et nad saaksid täielikult keskenduda ärifunktsioonide rakendamisele. Järgmisena kirjeldame "Movie Search'i", Delta tegelikku kasutusjuhtu Netflixis.
Netflixis rakendatakse laialdaselt mikroteenuste arhitektuuri ja iga mikroteenus teenindab tavaliselt ühte andmetüüpi. Filmi põhiteave on välja toodud mikroteenuses, mida nimetatakse Movie Service'iks, ning sellega seotud andmed, näiteks produtsentide, näitlejate, teenusepakkujate teave jne, haldavad mitmed teised mikroteenused (nimelt Deal Service, Talent Service ja Vendor Service).
Netflix Studioses vajavad äritöötajad sageli filmide otsimist erinevate kriteeriumide alusel, mistõttu on neile väga oluline, et nad saaksid otsida filme puudutavaid andmeid.
Enne Delta kasutuselevõttu pidi filmide otsimise meeskond saama andmeid mitmest mikroteenusest, enne kui nad suudavad filmide andmed indekseerida. Lisaks pidi meeskond välja töötama süsteemi, mis perioodiliselt uuendaks otsingumudelit, küsides muudatusi teistelt mikroteenustelt, isegi kui muudatusi ei olnud. See süsteem kasvas kiiresti keerukaks ja seda oli raske toetada.
Joonis 1. Polleerimissüsteem enne Delta
Delta kasutuselevõtu järel lihtsustati süsteem, muutudes sündmustest juhitavaks süsteemiks, nagu on näidatud järgmises joonises. CDC (Change-Data-Capture) sündmused saadetakse Keystone Kafka teemadesse Delta-Connectori abil. Delta rakendus, mis on ehitatud Delta Stream Processing Framework'i (põhinedes Flink'ile) kasutades, saab CDC-sündmusi teemast, rikastab neid, kutsudes välja teisi mikroteenuseid, ja lõpuks edastab rikastatud andmed Elasticsearch'i otsinguindeksisse. Kogu protsess toimub peaaegu reaalajas, st nii pea, kui muudatused salvestatakse andmehoidlas, uuendatakse otsinguindekseid.
Joonis 2. Andmepipeline Delta kasutamisel
Järgmistes osades kirjeldame Delta-Connector'i tööd, mis ühendub andmehoidla ja avaldab CDC-sündmusi transportimise tasemel, mis esindab reaalajas andmeedastuse infrastruktuuri, suunates CDC-sündmused Kafka teemadesse. Ja lõpuks räägime Delta voogude töötlemise struktuurist, mida rakenduste arendajad saavad kasutada andmete töötlemise ja rikastamise loogikaks.
CDC (Change-Data-Capture)
Oleme välja töötanud CDC teenuse nimega Delta-Connector, mis suudab reaalajas fikseerida andmehoidla sisse kirjutatud muudatused ja kirjutada need voogu. Reaalajas muudatused saadakse tehingute ajaloost ja andmehoidla dump'idest. Dump'id on vajalikud, kuna tehingute ajalugu ei halda tavaliselt kõiki muudatuste ajaloosid. Muudatused seostatakse tavaliselt Delta sündmustega, et saaja ei peaks muretsema, kust muudatus pärineb.
Delta-Connector toetab mitmeid lisafunktsioone, näiteks:
- Võimalus kirjutada kohandatud väljunditesse mööda Kafka't.
- Võimalus aktiveerida käsitsi dump'id igal ajal kõigi tabelite, teatud tabeli või teatud primaarvõtmete jaoks.
- Dump'e saab võtta chunk'idena, seega ei ole vaja kõike algusest peale alustada, kui juhtub tõrge.
- Tabelite lukustamise vajadus puudub, mis on väga oluline, et andmebaasi kirjutamise liiklus ei oleks kunagi meie teenuse tõttu blokeeritud.
- Kõrge kättesaadavus tänu varukoopia instantsidele AWS Availability Zones'is.
Praegu toetame MySQL-i ja Postgres-i, sealhulgas AWS RDS-i ja Aurora kaudu juurutamist. Toetame ka Cassandra't (multi-master). Rohkem teavet Delta-Connectori kohta leiate siit .
Kafka ja transporditasand
Delta sündmuste transporditasand on üles ehitatud platvormi sõnumivahetusteenusele .
Ajalooliselt on Netflixi sõnumite avaldamine optimeeritud saadavuse, mitte püsivuse säilitamise suunas (vt ). Kompromissiks on potentsiaalne andmete vastavuse puudumine brokera vahel erinevates piirjoonetes. Näiteks ebapuhas liidri valimine tuleb objekti, mis võib tekitada saajale sündmuste dubleerimist või kaotamist.
Delta puhul soovisime saavutada tugevamaid püsivuse tagatisi, et tagada CDC-sündmuste kohaletoimetamine tuletatud ladustamisse. Selleks esitasime spetsiaalselt kavandatud Kafka klastrina esmaklassilise objekti. Saate vaadata mõned brokera seadistused allolevas tabelis:
Keystone Kafka klastrites, ebapuhas liidri valimine on tavaliselt sisse lülitatud, et tagada väljaandja saadavus. See võib põhjustada sõnumite kadumist, kui sünkroonimata koopia valitakse liidriks. Uue kõrge usaldusväärsusega Kafka klastris on parameeter ebapuhas liidri valimine välja lülitatud, et vältida sõnumite kadumist.
Keskmiselt oleme suurendanud replikatsiooni faktorit 2-lt 3-le ja minimaalsetes sünkroonitud koopiates 1-lt 2-le. Väljaandjad, kes kirjutavad sellesse klastrisse, nõuavad acks, tagades, et 2 3-st koopiast omavad kõige ajakohasemaid sõnumeid, mille on saatnud väljaandja.
Kui brokeri instants lõpetab tööd, asendab uus instants vanema. Kuid uuel brokeril tuleb sünkroniseerimata koopiad järele jõuda, mis võib võtta mitu tundi. Selle stsenaariumi taastamisaja vähendamiseks oleme hakanud kasutama andmete plokkhõive süsteemi (Amazon Elastic Block Store) kohalike brokeri ketaste asemel. Kui uus instants asendab lõpetatud brokeri instantsi, liidab ta EBS-i mahu, mis kuulus lõpetatud instantsile, ja hakkab järele jõudma uutele sõnumitele. See protsess vähendab viivituse likvideerimise aega mitmest tunnist mõne minutini, kuna uusel instantsil ei ole enam vaja alustada nullseisundist. Üldiselt vähendavad eraldi salvestusseadmete ja brokeri elutsüklid oluliselt brokri vahetuse mõju.
Andmete edastamise garanteerimise suurendamiseks oleme kasutanud sõnumikaotuse tuvastamiseks ekstreemsetes tingimustes (näiteks sektsiooni juhi kellade desünkroniseerimine).
Voogude töötlemise raamistik
Delta töötlemistaseme aluseks on Netflix SPaaS platvorm, mis integreerib Apache Flinki Netflixi ökosüsteemiga. Platvorm pakub kasutajaliidest, mis haldab Flinki tööde juurutamist ja Flinki klastrite orkestreerimist meie konteinerihaldusplatvormi Titus üle. Liidest haldab ka tööde konfiguratsioone ja võimaldab kasutajatel dünaamiliselt konfiguratsioonides muudatusi teha, ilma Flinki töid uuesti kompileerimata.
Delta pakub voogude töötlemise raamistikku (stream processing framework), mis põhineb Flinkil ja SPaaS-il, kasutades annotatsioonipõhist DSL (spetsiifiline domeeni keel), et abstrakteerida tehnilised detailid. Näiteks, et määrata samm, millega sündmused rikastatakse, kutsudes väliseid teenuseid, peavad kasutajad kirjutama järgmise DSL-i ja raamistik loob selle põhjal mudeli, mis Flinkis töötab.
Joonis 3. Näide DSL-i rikastamisest Delta-s
Töötlemise raamistik mitte ainult ei lühenda õppimiskurvi, vaid pakub ka üldisi voogude töötlemise funktsioone, nagu deduplikatsioon, skeemide haldamine, samuti paindlikkust ja tõrkekindlust tavaliste tööprotsesside probleemide lahendamiseks.
Delta Stream Processing Framework koosneb kahest põhikomponendist: DSL & API moodul ja Runtime moodul. DSL & API moodul pakub DSL-i ja UDF (kasutaja määratud funktsioon) API-d, et kasutajad saaksid kirjutada oma töötlemisloogika (nt filtreerimine või teisendamine). Runtime moodul pakub DSL-i parsimise teostust, mis loob sisemise esitluse töötlemise sammudest DAG-mudelite kujul. Täitmise komponent tõlgendab DAG-mudeleid, et initsialiseerida tegelikud Flinki operaatorid ja lõpuks käivitada Flinki rakendus. Raamistikku illustreerib järgmine joonis.
Joonis 4. Delta Stream Processing Frameworki arhitektuur
Sellisel lähenemisel on mitmeid eeliseid:
- Kasutajad saavad keskenduda oma äri loogikale ilma, et peaksid süvenema Flinki või SPaaS-i struktuuri üksikasjadesse.
- Optimeerimist saab teostada kasutajatele läbipaistvas viisis ning vigu saab parandada ilma, et oleks vaja kasutaja koodi (UDF) muuta.
- Delta rakenduste töö on kasutajate jaoks lihtsustatud, kuna platvorm pakub kohe paindlikkust ja tõrketaluvust ning kogub palju üksikasjalikke mõõdikuid, mida saab kasutada teavitamiseks.
Kasutamine tootmises
Delta on tootmises töötanud juba üle aasta ja mängib olulist rolli paljudes Netflix Studio rakendustes. See on aidanud meeskondadel teostada selliseid kasutusjuhtumeid nagu otsingu indekseerimine, andmete salvestamine ja sündmustega juhitavad töövood. Allpool on esitatud Delta platvormi kõrgetasemeline arhitektuur.
Joonis 5. Delta kõrgetasemeline arhitektuur.
Tänud
Soovime tänada järgmisi inimesi, kes osalesid Delta loomises ja arendamises 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
