Laukiant naujo srauto paleidimo tokiu greičiu Parengėme įdomios medžiagos vertimą.
Peržiūrėti
Kalbėsime apie gana populiarų modelį, pagal kurį programos naudoja kelias duomenų saugyklas, kai kiekviena saugykla naudojama savo tikslams, pavyzdžiui, saugoti kanoninę duomenų formą (MySQL ir kt.), suteikti išplėstines paieškos galimybes (ElasticSearch, ir kt.) .), talpyklos (Memcached ir kt.) ir kt. Paprastai, kai naudojamos kelios duomenų saugyklos, viena iš jų veikia kaip pagrindinė, o kitos kaip išvestinių duomenų saugyklos. Vienintelė problema yra, kaip sinchronizuoti šias duomenų saugyklas.
Išnagrinėjome daugybę skirtingų modelių, kurie bandė išspręsti kelių parduotuvių sinchronizavimo problemą, pvz., dvigubo rašymo, paskirstytų operacijų ir kt. Tačiau šie metodai turi didelių apribojimų, susijusių su realiu naudojimu, patikimumu ir priežiūra. Be duomenų sinchronizavimo, kai kurios programos taip pat turi praturtinti duomenis skambinant išorinėms tarnyboms.
Delta buvo sukurta siekiant išspręsti šias problemas. „Delta“ galiausiai suteikia nuoseklią, įvykiais pagrįstą platformą duomenims sinchronizuoti ir tobulinti.
Esami sprendimai
Dvigubas įėjimas
Norėdami sinchronizuoti dvi duomenų saugyklas, galite naudoti dvigubą rašymą, kuris įrašo į vieną saugyklą ir iškart po to į kitą. Pirmąjį įrašymą galima bandyti dar kartą, o antrąjį – nutraukti, jei pirmasis nepavyksta išnaudojus bandymų skaičiaus. Tačiau dvi duomenų saugyklos gali būti nesinchronizuotos, jei nepavyks įrašyti į antrąją saugyklą. Ši problema dažniausiai išsprendžiama sukuriant atkūrimo procedūrą, kuri gali periodiškai iš naujo perkelti duomenis iš pirmosios saugyklos į antrąją arba tai padaryti tik tuo atveju, jei duomenyse aptinkami skirtumai.
Problemos:
Atkūrimo procedūros atlikimas yra konkretus darbas, kurio negalima pakartotinai naudoti. Be to, duomenys tarp saugojimo vietų lieka nesinchronizuoti, kol nebus atlikta atkūrimo procedūra. Sprendimas tampa sudėtingesnis, jei naudojamos daugiau nei dvi duomenų saugyklos. Galiausiai, atkūrimo procedūra gali padidinti pradinio duomenų šaltinio apkrovą.
Keisti žurnalo lentelę
Kai įvyksta lentelių rinkinio pakeitimai (pvz., įrašo įterpimas, atnaujinimas ir ištrynimas), pakeitimų įrašai pridedami prie žurnalo lentelės kaip tos pačios operacijos dalis. Kita gija ar procesas nuolat prašo įvykių iš žurnalo lentelės ir įrašo juos į vieną ar daugiau duomenų saugyklų, jei reikia, pašalindami įvykius iš žurnalo lentelės, kai įrašą patvirtina visos saugyklos.
Problemos:
Šis modelis turėtų būti įgyvendintas kaip biblioteka ir idealiu atveju nekeičiant jį naudojančios programos kodo. Poliglotinėje aplinkoje tokios bibliotekos įgyvendinimas turėtų egzistuoti bet kuria reikalinga kalba, tačiau užtikrinti funkcionalumo ir elgesio nuoseklumą skirtingomis kalbomis yra labai sunku.
Kita problema yra gauti schemų pakeitimus sistemose, kurios nepalaiko operacijų schemų pakeitimų [1][2], pvz., MySQL. Todėl pakeitimo (pvz., schemos pakeitimo) ir operacijų įrašymo į pakeitimų žurnalo lentelę modelis ne visada veiks.
Paskirstytos operacijos
Paskirstytos operacijos gali būti naudojamos norint padalyti operaciją keliose nevienalytėse duomenų saugyklose, kad operacija būtų priskirta visoms naudojamoms duomenų saugykloms arba nepriskirta nė vienai iš jų.
Problemos:
Paskirstytos operacijos yra labai didelė heterogeninių duomenų saugyklų problema. Pagal savo pobūdį jie gali pasikliauti tik mažiausiu susijusių sistemų bendru vardikliu. Pavyzdžiui, XA operacijos blokuoja vykdymą, jei paraiškų teikimo procesas nepavyksta parengiamuoju etapu. Be to, XA nepateikia aklavietės aptikimo ir nepalaiko optimistinių lygiagrečio valdymo schemų. Be to, kai kurios sistemos, pvz., ElasticSearch, nepalaiko XA ar bet kokio kito nevienalyčio sandorio modelio. Taigi, užtikrinti rašymo atomiškumą įvairiose duomenų saugojimo technologijose išlieka labai sudėtinga užduotis programoms [3].
delta
„Delta“ buvo sukurta siekiant pašalinti esamų duomenų sinchronizavimo sprendimų apribojimus ir taip pat leidžia praturtinti duomenis skrydžio metu. Mūsų tikslas buvo abstrahuoti visus šiuos sudėtingumus nuo programų kūrėjų, kad jie galėtų visapusiškai sutelkti dėmesį į verslo funkcijų įgyvendinimą. Toliau apibūdinsime „Filmų paiešką“ – tikrąjį „Netflix Delta“ naudojimo atvejį.
„Netflix“ plačiai naudoja mikro paslaugų architektūrą, o kiekviena mikro paslauga paprastai aptarnauja vieno tipo duomenis. Pagrindinė informacija apie filmą yra mikropaslaugoje, vadinamoje Movie Service, o susijusius duomenis, pvz., informaciją apie gamintojus, aktorius, pardavėjus ir pan., tvarko kelios kitos mikropaslaugos (būtent Deal Service, Talent Service ir Vendor Service).
„Netflix Studios“ verslo vartotojams dažnai reikia ieškoti pagal įvairius filmų kriterijus, todėl jiems labai svarbu, kad jie galėtų ieškoti visų su filmais susijusių duomenų.
Prieš „Delta“ filmų paieškos komanda turėjo gauti duomenis iš kelių mikrotarnybų, prieš indeksuodama filmo duomenis. Be to, komanda turėjo sukurti sistemą, kuri periodiškai atnaujintų paieškos indeksą, prašydama pakeitimų iš kitų mikroservisų, net jei jokių pakeitimų nebūtų. Ši sistema greitai tapo sudėtinga ir sunkiai prižiūrima.
1 pav. Apklausos sistema Delta
Panaudojus Delta, sistema buvo supaprastinta iki įvykiais valdomos sistemos, kaip parodyta toliau pateiktame paveikslėlyje. CDC (Change-Data-Capture) įvykiai siunčiami į Keystone Kafka temas naudojant Delta-Connector. „Delta“ programa, sukurta naudojant „Delta Stream Processing Framework“ (pagrįsta „Flink“), gauna CDC įvykius iš temos, praturtina juos iškviesdama kitas mikro tarnybas ir galiausiai perduoda praturtintus duomenis į Elasticsearch paieškos indeksą. Visas procesas vyksta beveik realiu laiku, tai yra, kai tik duomenų saugykloje atliekami pakeitimai, atnaujinami paieškos indeksai.
2 pav. Duomenų srautas naudojant Delta
Tolesniuose skyriuose apibūdinsime Delta-Connector, kuris jungiasi prie saugyklos ir publikuoja CDC įvykius į transporto sluoksnį, veikimą – tai realaus laiko duomenų perdavimo infrastruktūra, nukreipianti CDC įvykius į Kafka temas. Ir pačioje pabaigoje pakalbėsime apie Delta srauto apdorojimo sistemą, kurią programų kūrėjai gali naudoti duomenų apdorojimui ir praturtinimo logikai.
CDC (Change-Data-Capture)
Sukūrėme CDC paslaugą, pavadintą Delta-Connector, kuri gali užfiksuoti padarytus pakeitimus iš duomenų saugyklos realiuoju laiku ir įrašyti juos į srautą. Pakeitimai realiuoju laiku paimami iš operacijų žurnalo ir saugyklos išrašų. Sąvartynai naudojami, nes operacijų žurnaluose paprastai nesaugoma visa pakeitimų istorija. Pakeitimai paprastai yra serijiniai kaip Delta įvykiai, todėl gavėjui nereikia jaudintis, iš kur atsiranda pakeitimas.
Delta-Connector palaiko keletą papildomų funkcijų, tokių kaip:
- Galimybė rašyti pasirinktinius išvesties duomenis po Kafka.
- Galimybė bet kuriuo metu suaktyvinti visų lentelių, konkrečios lentelės arba konkrečių pirminių raktų rankinį išmetimą.
- Sąvartynus galima paimti dalimis, todėl gedimo atveju nereikia visko pradėti iš naujo.
- Nereikia užrakinti lentelių, o tai labai svarbu, kad mūsų paslauga niekada neužblokuotų duomenų bazės rašymo srauto.
- Didelis prieinamumas dėl perteklinių egzempliorių AWS pasiekiamumo zonose.
Šiuo metu palaikome „MySQL“ ir „Postgres“, įskaitant diegimą AWS RDS ir „Aurora“. Mes taip pat palaikome Cassandra (multi-master). Daugiau informacijos apie Delta-Connector galite sužinoti čia .
Kafka ir transporto sluoksnis
Delta įvykių perdavimo sluoksnis yra sukurtas platformos pranešimų siuntimo paslauga .
Istoriškai paskelbimas „Netflix“ buvo optimizuotas prieinamumui, o ne ilgaamžiškumui (žr. toliau). ). Kompromisas buvo galimas tarpininko duomenų neatitikimas įvairiuose kraštutiniuose scenarijuose. Pavyzdžiui, nešvarūs lyderio rinkimai yra atsakingas už tai, kad gavėjas gali pasikartoti arba prarasti įvykius.
Su „Delta“ norėjome tvirtesnių ilgaamžiškumo garantijų, kad būtų užtikrintas CDC įvykių pristatymas į išvestines parduotuves. Šiam tikslui kaip pirmos klasės objektą pasiūlėme specialiai suprojektuotą Kafkos klasterį. Žemiau esančioje lentelėje galite peržiūrėti kai kuriuos tarpininko nustatymus:
Keystone Kafka klasteriuose, nešvarūs lyderio rinkimai paprastai įtraukiami siekiant užtikrinti leidėjo prieinamumą. Dėl to pranešimas gali būti prarastas, jei nesinchronizuota kopija bus išrinkta lyderiu. Naujam didelio pasiekiamumo Kafka klasteriui – parinktis nešvarūs lyderio rinkimai išjungtas, kad neprarastumėte pranešimų.
Mes taip pat padidinome replikacijos faktorius nuo 2 iki 3 ir minimalios nesinchronizuotos kopijos Nuo 1 iki 2. Leidėjai, rašantys į šią grupę, reikalauja visų kitų patvirtinimų, užtikrinančių, kad 2 iš 3 kopijų turi naujausius leidėjo išsiųstus pranešimus.
Kai tarpininko egzempliorius baigiasi, naujas egzempliorius pakeičia senąjį. Tačiau naujasis brokeris turės pasivyti nesinchronizuotas kopijas, o tai gali užtrukti kelias valandas. Norėdami sutrumpinti šio scenarijaus atkūrimo laiką, vietoj vietinių tarpininkų diskų pradėjome naudoti blokinių duomenų saugyklą („Amazon Elastic Block Store“). Kai naujas egzempliorius pakeičia nutrauktą tarpininko egzempliorių, jis prideda EBS tomą, kurį turėjo nutrauktas egzempliorius, ir pradeda pasivyti naujus pranešimus. Šis procesas sutrumpina atsilikimo pašalinimo laiką nuo valandų iki minučių, nes naujo egzemplioriaus nebereikia dauginti iš tuščios būsenos. Apskritai, atskiri saugojimo ir tarpininko gyvavimo ciklai žymiai sumažina tarpininko keitimo poveikį.
Norėdami dar labiau padidinti duomenų pristatymo garantiją, naudojome aptikti bet kokį pranešimų praradimą ekstremaliomis sąlygomis (pavyzdžiui, skaidinio lyderio laikrodžio desinchronizavimas).
Srauto apdorojimo sistema
„Delta“ apdorojimo sluoksnis yra sukurtas ant „Netflix SPAaS“ platformos, kuri suteikia „Apache Flink“ integraciją su „Netflix“ ekosistema. Platformoje yra vartotojo sąsaja, kuri valdo „Flink“ užduočių diegimą ir „Flink“ grupių orkestravimą mūsų „Titus“ konteinerių valdymo platformos viršuje. Sąsaja taip pat valdo užduočių konfigūracijas ir leidžia vartotojams dinamiškai keisti konfigūraciją, nereikia iš naujo kompiliuoti Flink užduočių.
„Delta“ teikia srauto apdorojimo sistemą, pagrįstą „Flink“ ir „SPaaS“, kurią naudoja anotacijos pagrindu DSL (Domeno specifinė kalba), kad abstrakčiai apibūdintų technines detales. Pavyzdžiui, norėdami apibrėžti žingsnį, kuriuo įvykiai bus praturtinami iškviečiant išorines paslaugas, vartotojai turi parašyti šį DSL, o karkasas pagal jį sukurs modelį, kurį vykdys Flink.
3 pav. DSL praturtinimo pavyzdys Delta
Apdorojimo sistema ne tik sumažina mokymosi kreivę, bet ir suteikia bendras srauto apdorojimo funkcijas, tokias kaip dubliavimo panaikinimas, schematizavimas ir lankstumas bei atsparumas sprendžiant įprastas veiklos problemas.
Delta Stream Processing Framework susideda iš dviejų pagrindinių modulių: DSL ir API modulio ir vykdymo modulio. DSL ir API modulis teikia DSL ir UDF (vartotojo nustatytos funkcijos) API, kad vartotojai galėtų rašyti savo apdorojimo logiką (pvz., filtravimą ar transformacijas). Vykdymo modulyje įdiegtas DSL analizatorius, kuris sukuria vidinį apdorojimo etapų vaizdą DAG modeliuose. Vykdymo komponentas interpretuoja DAG modelius, kad inicijuotų tikruosius Flink teiginius ir galiausiai paleistų Flink programą. Karkaso architektūra parodyta toliau pateiktame paveikslėlyje.
4 pav. Delta Stream Processing Framework architektūra
Šis metodas turi keletą privalumų:
- Vartotojai gali sutelkti dėmesį į savo verslo logiką, nesigilindami į „Flink“ ar „SPaaS“ struktūros specifiką.
- Optimizavimas gali būti atliktas vartotojams skaidriu būdu, o klaidas galima ištaisyti nereikalaujant jokių vartotojo kodo (UDF) pakeitimų.
- Delta taikomosios programos naudotojams yra supaprastintos, nes platforma suteikia lankstumo ir atsparumo iš karto ir renka įvairią išsamią metriką, kurią galima naudoti įspėjimams.
Gamybos naudojimas
„Delta“ buvo gaminama daugiau nei metus ir atlieka pagrindinį vaidmenį daugelyje „Netflix Studio“ programų. Ji padėjo komandoms įgyvendinti naudojimo atvejus, tokius kaip paieškos indeksavimas, duomenų saugojimas ir įvykiais pagrįstos darbo eigos. Žemiau pateikiama aukšto lygio Delta platformos architektūros apžvalga.
5 pav. Delta aukšto lygio architektūra.
Padėkos
Norėtume padėkoti šiems žmonėms, kurie dalyvavo kuriant ir plėtojant Delta „Netflix“: 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 ir Zhenzhong Xu.
Informacijos šaltiniai
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Internetinis įvykių apdorojimas. Komun. ACM 62(5): 43–49 (2019). DOI:
: „Duomenų kūrimo įrankis, skirtas Amazon Redshift Storage“.
Šaltinis: www.habr.com