Uue voo käivitamise ootuses kiirusega Oleme koostanud huvitava materjali tõlke.
Vaadata
Räägime üsna populaarsest mustrist, mille kohaselt rakendused kasutavad mitut andmesalvet, kus iga poodi kasutatakse oma eesmärkidel, näiteks andmete kanoonilise vormi salvestamiseks (MySQL jne), täiustatud otsinguvõimaluste pakkumiseks (ElasticSearch, jne) .), vahemällu salvestamine (Memcached jne) ja teised. Tavaliselt toimib mitme andmesalve kasutamisel üks neist peamise ja teised tuletishoidlatena. Ainus probleem on selles, kuidas neid andmesalve sünkroonida.
Vaatasime mitmeid erinevaid mustreid, mis püüdsid lahendada mitme poe sünkroonimise probleemi, nagu topeltkirjutamine, hajutatud tehingud jne. Nendel lähenemisviisidel on aga tegeliku kasutamise, töökindluse ja hoolduse osas märkimisväärsed piirangud. Lisaks andmete sünkroonimisele peavad mõned rakendused andmeid rikastama ka välisteenustele helistades.
Delta töötati välja nende probleemide lahendamiseks. Delta pakub andmete sünkroonimiseks ja rikastamiseks järjepidevat sündmustepõhist platvormi.
Olemasolevad lahendused
Topeltsisestus
Kahe andmesalve sünkroonis hoidmiseks saate kasutada kahekordset kirjutamist, mis kirjutab ühte poodi ja seejärel kohe teise. Esimest salvestust saab uuesti proovida ja teise saab katkestada, kui esimene ebaõnnestub pärast seda, kui katsete arv on ammendunud. Siiski võivad kaks andmesalvesti sünkroonist välja minna, kui teise poodi kirjutamine ebaõnnestub. See probleem lahendatakse tavaliselt taasteprotseduuri loomisega, mis suudab perioodiliselt andmeid esimesest salvestusruumist teise üle kanda või teha seda ainult siis, kui andmetes tuvastatakse erinevusi.
Probleemid:
Taasteprotseduuri läbiviimine on konkreetne töö, mida ei saa uuesti kasutada. Lisaks jäävad salvestuskohtade vahelised andmed sünkroonist välja kuni taastamisprotseduuri toimumiseni. Lahendus muutub keerulisemaks, kui kasutatakse rohkem kui kahte andmesalvet. Lõpuks võib taastamisprotseduur lisada algsele andmeallikale koormust.
Muuda logitabelit
Kui tabelite komplektis tehakse muudatusi (nt kirje sisestamine, värskendamine ja kustutamine), lisatakse muudatuste kirjed sama tehingu osana logitabelisse. Teine lõim või protsess küsib pidevalt sündmusi logitabelist ja kirjutab need ühte või mitmesse andmesalve, vajaduse korral eemaldades sündmused logitabelist pärast seda, kui kirje on kõigi kaupluste poolt kinnitatud.
Probleemid:
Seda mustrit tuleks rakendada raamatukoguna ja ideaaljuhul ilma seda kasutava rakenduse koodi muutmata. Polügloti keskkonnas peaks sellise teegi rakendus olemas olema mis tahes vajalikus keeles, kuid funktsionaalsuse ja käitumise järjepidevuse tagamine erinevates keeltes on väga keeruline.
Teine probleem seisneb skeemimuudatuste hankimises süsteemides, mis ei toeta tehinguskeemi muudatusi [1][2], näiteks MySQL. Seetõttu ei tööta alati muster muudatuse (näiteks skeemi muutmise) tegemise ja selle tehinguliselt muudatuste logi tabelisse salvestamise muster.
Jaotatud tehingud
Jaotatud tehinguid saab kasutada tehingu jagamiseks mitme heterogeense andmesalve vahel, nii et toiming on seotud kõikide kasutatavate andmesalvedega või mitte ühelegi neist.
Probleemid:
Hajutatud tehingud on heterogeensete andmehoidlate jaoks väga suureks probleemiks. Oma olemuselt saavad nad tugineda ainult asjaomaste süsteemide väikseimale ühisnimetajale. Näiteks XA tehingud blokeerivad täitmise, kui rakendusprotsess ettevalmistusfaasis ebaõnnestub. Lisaks ei paku XA ummikseisu tuvastamist ega toeta optimistlikke samaaegsuse juhtimisskeeme. Lisaks ei toeta mõned süsteemid, nagu ElasticSearch, XA-d ega ühtegi muud heterogeenset tehingumudelit. Seega on erinevates andmesalvestustehnoloogiates kirjutamise aatomilisuse tagamine rakenduste jaoks endiselt väga keeruline ülesanne [3].
Delta
Delta loodi olemasolevate andmete sünkroonimislahenduste piirangutega tegelemiseks ja võimaldab ka lennu ajal andmete rikastamist. Meie eesmärk oli kogu see keerukus rakenduste arendajatest eemale tõmmata, et nad saaksid täielikult keskenduda ärifunktsioonide rakendamisele. Järgmisena kirjeldame "Filmiotsingut", mis on Netflixi Delta tegelik kasutusjuht.
Netflix kasutab laialdaselt mikroteenuste arhitektuuri ja iga mikroteenus teenindab tavaliselt ühte tüüpi andmeid. Põhiteave filmi kohta sisaldub mikroteenuses nimega Movie Service ning seotud andmeid, nagu teave tootjate, näitlejate, müüjate ja muu kohta, haldavad mitmed teised mikroteenused (nimelt Deal Service, Talent Service ja Vendor Service).
Netflix Studiosi ärikasutajad peavad sageli otsima erinevate filmikriteeriumide järgi, mistõttu on väga oluline, et nad saaksid otsida kõigist filmiga seotud andmetest.
Enne Deltat pidi filmiotsingu meeskond enne filmiandmete indekseerimist hankima andmeid mitmest mikroteenusest. Lisaks pidi meeskond välja töötama süsteemi, mis uuendaks perioodiliselt otsinguindeksit, nõudes muudatusi teistelt mikroteenustelt, isegi kui muudatusi ei toimunud. See süsteem muutus kiiresti keeruliseks ja raskesti hooldatavaks.
Joonis 1. Delta küsitlussüsteem
Pärast Delta kasutamist lihtsustati süsteem sündmusepõhiseks süsteemiks, nagu on näidatud järgmisel joonisel. CDC (Change-Data-Capture) sündmused saadetakse Keystone Kafka teemadele Delta-Connectori abil. Delta rakendus, mis on loodud Delta Stream Processing Frameworki abil (Flinkil põhinev), võtab teemast vastu CDC sündmused, rikastab neid teiste mikroteenuste kutsumisega ja lõpuks edastab rikastatud andmed Elasticsearchi otsinguindeksisse. Kogu protsess toimub peaaegu reaalajas, st niipea, kui andmelaos on tehtud muudatusi, uuendatakse otsinguindekseid.
Joonis 2. Deltat kasutav andmekonveier
Järgmistes osades kirjeldame Delta-Connectori tööd, mis ühendub salvestusruumiga ja avaldab CDC sündmused transpordikihile, mis on reaalajas andmeedastuse infrastruktuur, mis suunab CDC sündmused Kafka teemadele. Ja päris lõpus räägime Delta vootöötluse raamistikust, mida rakenduste arendajad saavad kasutada andmetöötluse ja rikastamise loogika jaoks.
CDC (Change-Data-Capture)
Oleme välja töötanud CDC teenuse nimega Delta-Connector, mis suudab salvestada tehtud muudatusi andmesalvest reaalajas ja kirjutada need voogu. Reaalajas tehtud muudatused võetakse tehingulogist ja salvestusmälust. Dumpe kasutatakse seetõttu, et tehingulogid tavaliselt ei salvesta kogu muudatuste ajalugu. Muudatused jadatakse tavaliselt Delta sündmustena, nii et saaja ei pea muretsema selle pärast, kust muudatus tuleb.
Delta-Connector toetab mitmeid lisafunktsioone, näiteks:
- Võimalus kirjutada kohandatud väljundandmeid Kafkast mööda.
- Võimalus aktiveerida kõikide tabelite, konkreetse tabeli või konkreetsete primaarvõtmete käsitsi väljavõtted igal ajal.
- Prügipuid saab kätte tükkidena, nii et ebaõnnestumise korral pole vaja kõike otsast alustada.
- Tabelitele pole vaja lukke panna, mis on väga oluline tagamaks, et meie teenus ei blokeeriks kunagi andmebaasi kirjutamise liiklust.
- Kõrge kättesaadavus AWS-i saadavuse tsoonide koondatud eksemplaride tõttu.
Praegu toetame MySQL-i ja Postgresi, sealhulgas juurutamist AWS RDS-is ja Auroras. Toetame ka Cassandrat (multi-master). Delta-Connectori kohta leiate lisateavet siit .
Kafka ja transpordikiht
Delta sündmuste transpordikiht on üles ehitatud platvormi sõnumsideteenusele .
Ajalooliselt on Netflixi postitamist optimeeritud pigem juurdepääsetavuse kui pikaealisuse jaoks (vt allpool). ). Kompromiss oli potentsiaalne maakleri andmete ebakõla erinevates servastsenaariumides. Näiteks, ebapuhas juhi valimine vastutab selle eest, et adressaadil võivad olla dubleeritud või kadunud sündmused.
Deltaga soovisime tugevamaid vastupidavuse garantiisid, et tagada CDC sündmuste tarnimine tuletatud kauplustesse. Selleks pakkusime esmaklassiliseks objektiks välja spetsiaalselt kujundatud Kafka klastri. Allolevas tabelis saate vaadata mõningaid maakleri seadeid:
Keystone Kafka klastrites ebapuhas juhi valimine tavaliselt kaasas, et tagada väljaandja juurdepääs. Kui juhiks valitakse sünkroonimata koopia, võib see põhjustada sõnumi kadumise. Uue kõrge kättesaadavusega Kafka klastri jaoks on see valik ebapuhas juhi valimine sõnumi kadumise vältimiseks välja lülitatud.
Samuti suurendasime replikatsioonitegur 2 kuni 3 ja minimaalsed sünkroonimata koopiad 1 kuni 2. Sellesse klastrisse kirjutavad avaldajad nõuavad kõigilt teistelt kinnitusi, tagades, et kolmest koopiast kahel on väljaandja saadetud uusimad sõnumid.
Kui maakleri eksemplar lõpetab tegevuse, asendab vana eksemplari uus. Uus maakler peab aga sünkroonimata koopiatele järele jõudma, mis võib võtta mitu tundi. Selle stsenaariumi taasteaja vähendamiseks hakkasime kohalike maakleri ketaste asemel kasutama plokkide andmesalvestust (Amazon Elastic Block Store). Kui uus eksemplar asendab lõpetatud vahendaja eksemplari, lisab see lõpetatud eksemplari EBS-i köite ja hakkab uutele sõnumitele järele jõudma. See protsess vähendab mahajäämuse kustutamise aega tundidelt minutitele, kuna uus eksemplar ei pea enam tühjast olekust kopeerima. Üldiselt vähendavad eraldi ladustamis- ja maakleri elutsüklid oluliselt maakleri vahetamise mõju.
Andmete edastamise garantii edasiseks suurendamiseks kasutasime mis tahes sõnumi kadumise tuvastamiseks äärmuslikes tingimustes (nt kella desünkroniseerimine partitsioonijuhis).
Voo töötlemise raamistik
Delta töötlemiskiht on ehitatud Netflixi SPAaS platvormi peale, mis pakub Apache Flinki integratsiooni Netflixi ökosüsteemiga. Platvorm pakub kasutajaliidest, mis haldab meie Tituse konteinerihaldusplatvormi peal Flinki tööde juurutamist ja Flinki klastrite orkestreerimist. Liides haldab ka tööde konfiguratsioone ja võimaldab kasutajatel dünaamiliselt konfiguratsioonimuudatusi teha, ilma et peaksid Flinki töid uuesti kompileerima.
Delta pakub vootöötluse raamistikku, mis põhineb Flinkil ja SPAaS-il, mida kasutab annotatsioonipõhine DSL (domeenispetsiifiline keel) tehniliste üksikasjade abstrakteerimiseks. Näiteks selleks, et määrata, millisel etapil sündmusi välisteenuste väljakutsumisega rikastatakse, peavad kasutajad kirjutama järgmise DSL-i ning raamistik loob selle põhjal mudeli, mille Flink teostab.
Joonis 3. DSL-i rikastamise näide Deltas
Töötlemisraamistik mitte ainult ei vähenda õppimiskõverat, vaid pakub ka ühiseid vootöötlusfunktsioone, nagu dubleerimine, skemaatiline koostamine ning paindlikkus ja vastupidavus tavaliste tööprobleemide lahendamiseks.
Delta Stream Processing Framework koosneb kahest võtmemoodulist, DSL & API moodulist ja Runtime moodulist. DSL- ja API-moodul pakub DSL-i ja UDF-i (kasutaja määratletud funktsiooni) API-sid, et kasutajad saaksid kirjutada oma töötlemisloogika (nt filtreerimine või teisendused). Käitusmoodul pakub DSL-parseri juurutamist, mis loob DAG-mudelites töötlemisetappide sisemise esituse. Täitmise komponent tõlgendab DAG-mudeleid tegelike Flink-lausete lähtestamiseks ja lõpuks Flinki rakenduse käivitamiseks. Raamistiku arhitektuur on illustreeritud järgmisel joonisel.
Joonis 4. Delta Stream Processing Frameworki arhitektuur
Sellel lähenemisviisil on mitmeid eeliseid:
- Kasutajad saavad keskenduda oma äriloogikale, ilma et peaksid süüvima Flinki või SPAaS-i struktuuri eripäradesse.
- Optimeerimist saab teha kasutajatele läbipaistval viisil ja vigu saab parandada ilma kasutajakoodi (UDF) muutmata.
- Delta rakenduskogemus on kasutajate jaoks lihtsustatud, kuna platvorm pakub koheselt paindlikkust ja vastupidavust ning kogub mitmesuguseid üksikasjalikke mõõdikuid, mida saab kasutada hoiatuste jaoks.
Tootmiskasutus
Delta on olnud tootmises üle aasta ja mängib võtmerolli paljudes Netflix Studio rakendustes. Ta aitas meeskondadel rakendada selliseid kasutusjuhtumeid nagu otsingu indekseerimine, andmete salvestamine ja sündmustepõhised töövood. Allpool on ülevaade Delta platvormi kõrgetasemelisest arhitektuurist.
Joonis 5. Delta kõrgetasemeline arhitektuur.
Tänusõnad
Soovime tänada järgmisi inimesi, kes Netflixis Delta loomise ja arendamisega seotud olid: 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.
allikatest
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online sündmuste töötlemine. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Andmete koostamise tööriist Amazon Redshift Storage jaoks."
Allikas: www.habr.com