V pričakovanju začetka novega toka po stopnji Pripravili smo prevod zanimivega gradiva.
Pregled
Govorili bomo o dokaj priljubljenem vzorcu, po katerem aplikacije uporabljajo več podatkovnih shramb, kjer se vsaka shramba uporablja za svoje namene, na primer za shranjevanje kanonične oblike podatkov (MySQL ipd.), zagotavljanje naprednih možnosti iskanja (ElasticSearch, itd.), predpomnjenje (Memcached itd.) in drugi. Običajno pri uporabi več podatkovnih shramb ena od njih deluje kot primarna shramba, druge pa kot izpeljane shrambe. Edina težava je, kako sinhronizirati te shrambe podatkov.
Ogledali smo si številne različne vzorce, ki so poskušali rešiti problem sinhronizacije več trgovin, kot so dvojno pisanje, porazdeljene transakcije itd. Vendar imajo ti pristopi znatne omejitve glede uporabe v resničnem življenju, zanesljivosti in vzdrževanja. Nekatere aplikacije morajo poleg sinhronizacije podatkov obogatiti podatke tudi s klicanjem zunanjih storitev.
Delta je bila razvita za reševanje teh težav. Delta navsezadnje zagotavlja dosledno platformo, ki temelji na dogodkih, za sinhronizacijo in obogatitev podatkov.
Obstoječe rešitve
Dvojni vstop
Če želite ohraniti sinhronizacijo dveh podatkovnih shramb, lahko uporabite dvojno pisanje, ki piše v eno shrambo in nato takoj zatem v drugo. Prvo snemanje je mogoče poskusiti znova, drugo pa prekiniti, če prvo ne uspe, potem ko je bilo število poskusov izčrpano. Vendar lahko obe shrambi podatkov ne bosta sinhronizirani, če pisanje v drugo shrambo ne uspe. Ta težava se običajno reši z ustvarjanjem obnovitvenega postopka, ki lahko občasno znova prenaša podatke iz prvega pomnilnika v drugega ali pa to stori le, če so v podatkih zaznane razlike.
Težave so:
Izvajanje postopka obnovitve je posebno opravilo, ki ga ni mogoče ponovno uporabiti. Poleg tega podatki med lokacijami za shranjevanje ostanejo nesinhronizirani, dokler se ne izvede postopek obnovitve. Rešitev postane kompleksnejša, če uporabimo več kot dve podatkovni shrambi. Končno lahko obnovitveni postopek dodatno obremeni izvirni vir podatkov.
Dnevnik sprememb tabele
Ko pride do sprememb niza tabel (kot je vstavljanje, posodabljanje in brisanje zapisa), se zapisi sprememb dodajo v tabelo dnevnika kot del iste transakcije. Druga nit ali proces nenehno zahteva dogodke iz tabele dnevnika in jih zapisuje v eno ali več podatkovnih shramb, po potrebi odstrani dogodke iz tabele dnevnika, ko zapis potrdijo vse shrambe.
Težave so:
Ta vzorec je treba implementirati kot knjižnico in idealno brez spreminjanja kode aplikacije, ki ga uporablja. V poliglotskem okolju bi morala obstajati izvedba takšne knjižnice v katerem koli potrebnem jeziku, vendar je zagotavljanje skladnosti funkcionalnosti in vedenja med jeziki zelo težko.
Druga težava je pridobivanje sprememb sheme v sistemih, ki ne podpirajo sprememb transakcijske sheme [1][2], kot je MySQL. Zato vzorec izvajanja spremembe (na primer spremembe sheme) in njenega transakcijskega beleženja v tabeli dnevnika sprememb ne bo vedno deloval.
Porazdeljene transakcije
Porazdeljene transakcije je mogoče uporabiti za razdelitev transakcije na več heterogenih shramb podatkov, tako da je operacija dodeljena vsem uporabljenim shrambam podatkov ali pa ni dodeljena nobeni od njih.
Težave so:
Porazdeljene transakcije so zelo velik problem za heterogene podatkovne shrambe. Po svoji naravi se lahko zanašajo le na najmanjši skupni imenovalec vključenih sistemov. Na primer, transakcije XA blokirajo izvedbo, če postopek prijave ne uspe med pripravljalno fazo. Poleg tega XA ne zagotavlja odkrivanja zastoja ali podpira optimističnih shem nadzora sočasnosti. Poleg tega nekateri sistemi, kot je ElasticSearch, ne podpirajo XA ali katerega koli drugega modela heterogenih transakcij. Tako zagotavljanje atomičnosti pisanja v različnih tehnologijah za shranjevanje podatkov ostaja zelo zahtevna naloga za aplikacije [3].
Delta
Delta je bila zasnovana tako, da obravnava omejitve obstoječih rešitev za sinhronizacijo podatkov in omogoča tudi sprotno obogatitev podatkov. Naš cilj je bil abstrahirati vso to kompleksnost od razvijalcev aplikacij, tako da se lahko popolnoma osredotočijo na implementacijo poslovne funkcionalnosti. Nato bomo opisali "Iskanje filmov", dejanski primer uporabe Netflixove Delte.
Netflix široko uporablja arhitekturo mikrostoritev in vsaka mikrostoritev običajno služi eni vrsti podatkov. Osnovne informacije o filmu so vsebovane v mikrostoritvi, imenovani Movie Service, povezane podatke, kot so informacije o producentih, igralcih, prodajalcih itd., pa upravlja več drugih mikrostoritev (in sicer Deal Service, Talent Service in Vendor Service).
Poslovni uporabniki Netflix Studios morajo pogosto iskati po različnih filmskih kriterijih, zato je zelo pomembno, da lahko iščejo po vseh podatkih, povezanih s filmom.
Pred Delto je morala skupina za iskanje filmov potegniti podatke iz več mikrostoritev, preden je indeksirala filmske podatke. Poleg tega je morala ekipa razviti sistem, ki bi občasno posodabljal iskalni indeks z zahtevanjem sprememb drugih mikrostoritev, tudi če sprememb sploh ni bilo. Ta sistem je hitro postal zapleten in težak za vzdrževanje.
Slika 1. Sistem glasovanja za Delto
Po uporabi Delte je bil sistem poenostavljen na sistem, ki ga poganjajo dogodki, kot je prikazano na naslednji sliki. Dogodki CDC (Change-Data-Capture) so poslani v teme Keystone Kafka z uporabo Delta-Connectorja. Aplikacija Delta, zgrajena z uporabo Delta Stream Processing Framework (ki temelji na Flinku), prejme dogodke CDC iz teme, jih obogati s klicanjem drugih mikrostoritev in na koncu obogatene podatke posreduje iskalnemu indeksu v Elasticsearch. Celoten proces poteka skoraj v realnem času, kar pomeni, da se iskalni indeksi posodobijo takoj, ko so v podatkovno skladišče vnesene spremembe.
Slika 2. Podatkovni cevovod z uporabo Delte
V naslednjih razdelkih bomo opisali delovanje Delta-Connectorja, ki se povezuje s shrambo in objavlja dogodke CDC na transportni plasti, ki je infrastruktura za prenos podatkov v realnem času, ki usmerja dogodke CDC v teme Kafke. In čisto na koncu bomo govorili o ogrodju za obdelavo toka Delta, ki ga razvijalci aplikacij lahko uporabljajo za obdelavo podatkov in logiko obogatitve.
CDC (Change-Data-Capture)
Razvili smo storitev CDC, imenovano Delta-Connector, ki lahko zajame potrjene spremembe iz podatkovne shrambe v realnem času in jih zapiše v tok. Spremembe v realnem času so vzete iz dnevnika transakcij in izpisov pomnilnika. Odlagališča se uporabljajo, ker dnevniki transakcij običajno ne shranijo celotne zgodovine sprememb. Spremembe so običajno serializirane kot dogodki Delta, tako da prejemniku ni treba skrbeti, od kod prihaja sprememba.
Delta-Connector podpira več dodatnih funkcij, kot so:
- Sposobnost pisanja izhodnih podatkov po meri mimo Kafke.
- Možnost aktiviranja ročnih izpisov kadar koli za vse tabele, določeno tabelo ali za določene primarne ključe.
- Odlagališča je mogoče pridobiti v kosih, tako da v primeru napake ni treba začeti znova.
- Na tabelah ni treba namestiti ključavnic, kar je zelo pomembno za zagotovitev, da naša storitev nikoli ne blokira prometa zapisovanja v bazo podatkov.
- Visoka razpoložljivost zaradi redundantnih instanc v območjih razpoložljivosti AWS.
Trenutno podpiramo MySQL in Postgres, vključno z uvedbami na AWS RDS in Aurora. Podpiramo tudi Cassandro (multi-master). Več podrobnosti o Delta-Connectorju najdete tukaj .
Kafka in transportna plast
Deltin transportni sloj dogodkov je zgrajen na sporočilni storitvi platforme .
V preteklosti je bilo objavljanje na Netflixu optimizirano za dostopnost in ne za dolgoživost (glejte spodaj). ). Kompromis je bila morebitna nedoslednost podatkov posrednika v različnih robnih scenarijih. na primer nečiste volitve vodje je odgovoren za morebitne podvojene ali izgubljene dogodke prejemnika.
Z Delto smo želeli močnejša jamstva za vzdržljivost, da bi zagotovili dostavo dogodkov CDC v izpeljane trgovine. V ta namen smo kot prvorazredni objekt predlagali posebej zasnovano Kafkovo gručo. Nekatere nastavitve posrednika si lahko ogledate v spodnji tabeli:
V grozdih Keystone Kafka, nečiste volitve vodje običajno vključeno, da se zagotovi dostopnost založnika. To lahko povzroči izgubo sporočila, če je za vodilno izbrana nesinhronizirana replika. Za novo visoko razpoložljivo gručo Kafka, možnost nečiste volitve vodje izklopljeno, da preprečite izgubo sporočila.
Povečali smo tudi replikacijski faktor od 2 do 3 in minimalne insinhronizirane replike 1 do 2. Založniki, ki pišejo v to gručo, zahtevajo potrditve od vseh drugih, kar zagotavlja, da imata 2 od 3 replik najnovejša sporočila, ki jih je poslal založnik.
Ko se instanca posrednika prekine, novo instanco nadomesti staro. Vendar bo moral novi posrednik dohiteti nesinhronizirane replike, kar lahko traja več ur. Da bi zmanjšali čas obnovitve za ta scenarij, smo začeli uporabljati blokovno shranjevanje podatkov (Amazon Elastic Block Store) namesto lokalnih posredniških diskov. Ko nov primerek nadomesti prekinjeni primerek posrednika, pripne nosilec EBS, ki ga je imel prekinjeni primerek, in začne dohitevati nova sporočila. Ta postopek skrajša čas reševanja zaostankov z ur na minute, ker novemu primerku ni več treba podvajati iz praznega stanja. Na splošno ločena življenjska cikla pomnilnika in posrednika znatno zmanjšata vpliv zamenjave posrednika.
Za dodatno povečanje garancije dostave podatkov smo uporabili za zaznavanje kakršne koli izgube sporočila v ekstremnih pogojih (na primer desinhronizacija ure v vodilni particiji).
Ogrodje za obdelavo toka
Deltin procesni sloj je zgrajen na platformi Netflix SPaaS, ki zagotavlja integracijo Apache Flink z ekosistemom Netflix. Platforma ponuja uporabniški vmesnik, ki upravlja uvajanje opravil Flink in orkestracijo gruč Flink na vrhu naše platforme za upravljanje vsebnikov Titus. Vmesnik prav tako upravlja konfiguracije opravil in uporabnikom omogoča dinamično spreminjanje konfiguracije, ne da bi morali znova prevajati opravila Flink.
Delta ponuja okvir za obdelavo toka, ki temelji na Flinku in SPaaS, ki uporablja temelji na opombah DSL (Domain Specific Language) za povzetek tehničnih podrobnosti. Na primer, za določitev koraka, v katerem bodo dogodki obogateni s klicanjem zunanjih storitev, morajo uporabniki napisati naslednji DSL, ogrodje pa bo na njegovi podlagi ustvarilo model, ki ga bo izvedel Flink.
Slika 3. Primer obogatitve na DSL v Delti
Ogrodje za obdelavo ne samo zmanjša krivuljo učenja, ampak tudi zagotavlja običajne funkcije obdelave toka, kot so deduplikacija, shematizacija ter prilagodljivost in odpornost za reševanje pogostih operativnih težav.
Delta Stream Processing Framework je sestavljen iz dveh ključnih modulov, modula DSL & API in modula Runtime. Modul DSL & API ponuja DSL in UDF (uporabniško definirane funkcije) API-je, tako da lahko uporabniki napišejo lastno logiko obdelave (kot je filtriranje ali transformacije). Modul Runtime zagotavlja implementacijo razčlenjevalnika DSL, ki gradi notranjo predstavitev korakov obdelave v modelih DAG. Izvršilna komponenta interpretira modele DAG za inicializacijo dejanskih stavkov Flink in na koncu zažene aplikacijo Flink. Arhitektura ogrodja je prikazana na naslednji sliki.
Slika 4. Arhitektura Delta Stream Processing Framework
Ta pristop ima več prednosti:
- Uporabniki se lahko osredotočijo na svojo poslovno logiko, ne da bi se morali poglobiti v posebnosti Flinka ali strukture SPaaS.
- Optimizacijo je mogoče izvesti na način, ki je pregleden za uporabnike, napake pa je mogoče popraviti, ne da bi bilo treba spremeniti uporabniško kodo (UDF).
- Izkušnja z aplikacijo Delta je za uporabnike poenostavljena, ker platforma zagotavlja prilagodljivost in odpornost takoj po namestitvi ter zbira različne podrobne meritve, ki jih je mogoče uporabiti za opozorila.
Proizvodna uporaba
Delta je v proizvodnji že več kot eno leto in ima ključno vlogo v številnih aplikacijah Netflix Studio. Pomagala je ekipam implementirati primere uporabe, kot so indeksiranje iskanja, shranjevanje podatkov in delovni tokovi, ki jih vodijo dogodki. Spodaj je pregled visoke ravni arhitekture platforme Delta.
Slika 5. Deltina arhitektura na visoki ravni.
Zahvala
Zahvaljujemo se naslednjim ljudem, ki so sodelovali pri ustvarjanju in razvoju Delte pri Netflixu: 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 in Zhenzhong Xu.
viri
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Spletna obdelava dogodkov. Komun. ACM 62 (5): 43–49 (2019). DOI:
: »Orodje za gradnjo podatkov za Amazon Redshift Storage.«
Vir: www.habr.com