I påvente av lanseringen av en ny flyt på rate Vi har utarbeidet en oversettelse av interessant materiale.
Gjennomgå
Vi vil snakke om et ganske populært mønster der applikasjoner bruker flere datalagre, der hver butikk brukes til sine egne formål, for eksempel for å lagre den kanoniske formen for data (MySQL, etc.), gi avanserte søkefunksjoner (ElasticSearch, etc.) .), caching (Memcached, etc.) og andre. Vanligvis, når du bruker flere datalagre, fungerer ett av dem som primærlager og de andre som derivatlagre. Det eneste problemet er hvordan man synkroniserer disse datalagrene.
Vi så på en rekke forskjellige mønstre som prøvde å løse problemet med å synkronisere flere butikker, for eksempel dobbeltskriving, distribuerte transaksjoner, etc. Imidlertid har disse tilnærmingene betydelige begrensninger når det gjelder virkelig bruk, pålitelighet og vedlikehold. I tillegg til datasynkronisering, må noen applikasjoner også berike data ved å ringe eksterne tjenester.
Delta ble utviklet for å løse disse problemene. Delta gir til syvende og sist en konsistent, hendelsesdrevet plattform for datasynkronisering og berikelse.
Eksisterende løsninger
Dobbel inngang
For å holde to datalagre synkronisert, kan du bruke dobbel skriving, som skriver til ett lager og deretter skriver til det andre umiddelbart etterpå. Den første innspillingen kan prøves på nytt, og den andre kan avbrytes hvis den første mislykkes etter at antall forsøk er oppbrukt. Imidlertid kan de to datalagrene bli usynkroniserte hvis skriving til det andre lagret mislykkes. Dette problemet løses vanligvis ved å opprette en gjenopprettingsprosedyre som med jevne mellomrom kan overføre data fra den første lagringen til den andre, eller bare gjøre det hvis det oppdages forskjeller i dataene.
problemer:
Å utføre en gjenopprettingsprosedyre er en spesifikk jobb som ikke kan gjenbrukes. I tillegg forblir data mellom lagringsplasseringer usynkroniserte til gjenopprettingsprosedyren finner sted. Løsningen blir mer kompleks hvis det brukes mer enn to datalagre. Til slutt kan gjenopprettingsprosedyren legge til belastning til den opprinnelige datakilden.
Endre loggtabell
Når endringer skjer i et sett med tabeller (som å sette inn, oppdatere og slette en post), legges endringspostene til loggtabellen som en del av den samme transaksjonen. En annen tråd eller prosess ber konstant om hendelser fra loggtabellen og skriver dem til ett eller flere datalagre, om nødvendig, fjerner hendelser fra loggtabellen etter at posten er bekreftet av alle lagre.
problemer:
Dette mønsteret bør implementeres som et bibliotek, og ideelt sett uten å endre koden til applikasjonen som bruker det. I et polyglotmiljø bør en implementering av et slikt bibliotek eksistere på et hvilket som helst nødvendig språk, men å sikre konsistens i funksjonalitet og oppførsel på tvers av språk er svært vanskelig.
Et annet problem ligger i å få skjemaendringer i systemer som ikke støtter transaksjonelle skjemaendringer [1][2], for eksempel MySQL. Derfor vil ikke alltid mønsteret for å gjøre en endring (for eksempel en skjemaendring) og transaksjonelt registrere den i endringsloggtabellen fungere.
Distribuerte transaksjoner
Distribuerte transaksjoner kan brukes til å dele en transaksjon på tvers av flere heterogene datalagre slik at operasjonen enten er forpliktet til alle datalagrene som brukes, eller ikke forpliktet til noen av dem.
problemer:
Distribuerte transaksjoner er et veldig stort problem for heterogene datalagre. Av natur kan de bare stole på den laveste fellesnevneren av de involverte systemene. For eksempel blokkerer XA-transaksjoner kjøring hvis søknadsprosessen mislykkes under forberedelsesfasen. I tillegg gir ikke XA deteksjon av dødlås eller støtter optimistiske samtidighetskontrollsystemer. I tillegg støtter noen systemer som ElasticSearch ikke XA eller noen annen heterogen transaksjonsmodell. Dermed er det fortsatt en svært utfordrende oppgave for applikasjoner å sikre skriveatomitet i ulike datalagringsteknologier [3].
Delta
Delta ble designet for å møte begrensningene til eksisterende datasynkroniseringsløsninger og muliggjør også dataanriking underveis. Målet vårt var å abstrahere alle disse kompleksitetene bort fra applikasjonsutviklere slik at de fullt ut kunne fokusere på å implementere forretningsfunksjonalitet. Deretter skal vi beskrive "Movie Search", den faktiske brukssaken for Netflixs Delta.
Netflix bruker mye en mikrotjenestearkitektur, og hver mikrotjeneste serverer vanligvis én type data. Grunnleggende informasjon om en film finnes i en mikrotjeneste kalt Movie Service, og relaterte data, som informasjon om produsenter, skuespillere, leverandører og så videre, administreres av flere andre mikrotjenester (nemlig Deal Service, Talent Service og Vendor Service).
Bedriftsbrukere hos Netflix Studios trenger ofte å søke på tvers av ulike filmkriterier, og derfor er det veldig viktig for dem å kunne søke på tvers av alle filmrelaterte data.
Før Delta måtte filmsøketeamet hente data fra flere mikrotjenester før filmdataene ble indeksert. I tillegg måtte teamet utvikle et system som periodisk skulle oppdatere søkeindeksen ved å be om endringer fra andre mikrotjenester, selv om det ikke var noen endringer i det hele tatt. Dette systemet ble raskt komplekst og vanskelig å vedlikeholde.
Figur 1. Pollingsystem til Delta
Etter bruk av Delta ble systemet forenklet til et hendelsesdrevet system som vist i følgende figur. CDC-hendelser (Change-Data-Capture) sendes til Keystone Kafka-emner ved hjelp av Delta-Connector. En Delta-applikasjon bygget ved hjelp av Delta Stream Processing Framework (basert på Flink) mottar CDC-hendelser fra et emne, beriker dem ved å ringe andre mikrotjenester, og sender til slutt de berikede dataene til en søkeindeks i Elasticsearch. Hele prosessen foregår nesten i sanntid, det vil si at så snart endringer er forpliktet til datavarehuset, oppdateres søkeindeksene.
Figur 2. Datarørledning ved bruk av Delta
I de følgende avsnittene vil vi beskrive driften av Delta-Connector, som kobles til lagringen og publiserer CDC-hendelser til transportlaget, som er en sanntidsdataoverføringsinfrastruktur som ruter CDC-hendelser til Kafka-emner. Og helt til slutt skal vi snakke om Delta-strømbehandlingsrammeverket, som applikasjonsutviklere kan bruke til databehandling og berikelseslogikk.
CDC (Change-Data-Capture)
Vi har utviklet en CDC-tjeneste kalt Delta-Connector, som kan fange opp forpliktede endringer fra datalageret i sanntid og skrive dem til en strøm. Sanntidsendringer hentes fra transaksjonsloggen og lagringsdumpene. Dumper brukes fordi transaksjonslogger vanligvis ikke lagrer hele endringshistorikken. Endringer er vanligvis serialisert som Delta-hendelser, slik at mottakeren ikke trenger å bekymre seg for hvor endringen kommer fra.
Delta-Connector støtter flere tilleggsfunksjoner som:
- Evne til å skrive tilpassede utdata forbi Kafka.
- Evne til å aktivere manuelle dumper når som helst for alle tabeller, en spesifikk tabell eller for spesifikke primærnøkler.
- Dumper kan hentes i biter, så det er ikke nødvendig å starte på nytt i tilfelle feil.
- Det er ikke nødvendig å plassere låser på tabeller, noe som er veldig viktig for å sikre at databaseskrivetrafikk aldri blokkeres av vår tjeneste.
- Høy tilgjengelighet på grunn av redundante forekomster i AWS Availability Zones.
Vi støtter for tiden MySQL og Postgres, inkludert distribusjoner på AWS RDS og Aurora. Vi støtter også Cassandra (multi-master). Du kan finne ut mer om Delta-Connector her .
Kafka og transportlaget
Deltas hendelsestransportlag er bygget på plattformens meldingstjeneste .
Historisk sett har innlegg på Netflix blitt optimalisert for tilgjengelighet i stedet for lang levetid (se nedenfor). ). Avveiningen var potensiell inkonsistens i meglerdata i ulike kantscenarier. For eksempel, urent ledervalg er ansvarlig for at mottakeren potensielt har dupliserte eller tapte hendelser.
Med Delta ønsket vi sterkere holdbarhetsgarantier for å sikre levering av CDC-arrangementer til avledede butikker. For dette formålet foreslo vi en spesialdesignet Kafka-klynge som et førsteklasses objekt. Du kan se på noen meglerinnstillinger i tabellen nedenfor:
I Keystone Kafka-klynger, urent ledervalg vanligvis inkludert for å sikre publisistens tilgjengelighet. Dette kan føre til meldingstap hvis en usynkronisert kopi velges som leder. For en ny høy tilgjengelig Kafka-klynge, alternativet urent ledervalg slått av for å forhindre tap av meldinger.
Vi økte også replikasjonsfaktor fra 2 til 3 og minimum insync replikaer 1 til 2. Utgivere som skriver til denne klyngen krever bekreftelser fra alle andre, for å sikre at 2 av 3 replikaer har de nyeste meldingene sendt av utgiveren.
Når en meglerforekomst avsluttes, erstatter en ny forekomst den gamle. Den nye megleren må imidlertid ta igjen de usynkroniserte kopiene, noe som kan ta flere timer. For å redusere gjenopprettingstiden for dette scenariet, begynte vi å bruke blokkdatalagring (Amazon Elastic Block Store) i stedet for lokale meglerdisker. Når en ny forekomst erstatter en avsluttet meglerforekomst, legger den ved EBS-volumet som den avsluttede forekomsten hadde og begynner å ta igjen nye meldinger. Denne prosessen reduserer tiden for oppklaring av etterslep fra timer til minutter fordi den nye forekomsten ikke lenger trenger å replikere fra en tom tilstand. Generelt reduserer separate lagrings- og meglerlivssykluser betydelig virkningen av meglerbytte.
For ytterligere å øke dataleveringsgarantien brukte vi for å oppdage eventuelle meldingstap under ekstreme forhold (for eksempel klokkedesynkronisering i partisjonslederen).
Stream Processing Framework
Deltas prosesseringslag er bygget på toppen av Netflix SPaaS-plattformen, som gir Apache Flink-integrasjon med Netflix-økosystemet. Plattformen gir et brukergrensesnitt som administrerer distribusjonen av Flink-jobber og orkestrering av Flink-klynger på toppen av vår Titus-beholderadministrasjonsplattform. Grensesnittet administrerer også jobbkonfigurasjoner og lar brukere gjøre konfigurasjonsendringer dynamisk uten å måtte rekompilere Flink-jobber.
Delta tilbyr et strømbehandlingsrammeverk basert på Flink og SPaaS som bruker annotasjonsbasert DSL (Domain Specific Language) for å abstrakte tekniske detaljer. For å definere trinnet hvor hendelser skal berikes ved å ringe eksterne tjenester, må brukere skrive følgende DSL, og rammeverket vil lage en modell basert på den, som vil bli utført av Flink.
Figur 3. Eksempel på berikelse på DSL i Delta
Behandlingsrammeverket reduserer ikke bare læringskurven, men gir også vanlige strømbehandlingsfunksjoner som deduplisering, skjematisering og fleksibilitet og robusthet for å løse vanlige driftsproblemer.
Delta Stream Processing Framework består av to nøkkelmoduler, DSL & API-modulen og Runtime-modulen. DSL & API-modulen gir DSL og UDF (User-Defined-Function) APIer slik at brukere kan skrive sin egen prosesseringslogikk (som filtrering eller transformasjoner). Runtime-modulen gir en implementering av en DSL-parser som bygger en intern representasjon av behandlingstrinn i DAG-modeller. Utførelseskomponenten tolker DAG-modeller for å initialisere de faktiske Flink-setningene og til slutt kjøre Flink-applikasjonen. Arkitekturen til rammeverket er illustrert i følgende figur.
Figur 4. Delta Stream Processing Framework-arkitektur
Denne tilnærmingen har flere fordeler:
- Brukere kan fokusere på sin forretningslogikk uten å måtte fordype seg i detaljene til Flink eller SPaaS-strukturen.
- Optimalisering kan gjøres på en måte som er transparent for brukerne, og feil kan rettes uten at det kreves endringer i brukerkoden (UDF).
- Delta-applikasjonsopplevelsen er forenklet for brukere fordi plattformen gir fleksibilitet og robusthet rett ut av boksen og samler inn en rekke detaljerte beregninger som kan brukes til varsler.
Produksjonsbruk
Delta har vært i produksjon i over et år og spiller en nøkkelrolle i mange Netflix Studio-applikasjoner. Hun hjalp team med å implementere brukstilfeller som søkeindeksering, datalagring og hendelsesdrevne arbeidsflyter. Nedenfor er en oversikt over høynivåarkitekturen til Delta-plattformen.
Figur 5. Deltas høynivåarkitektur.
Anerkjennelser
Vi vil gjerne takke følgende personer som var involvert i opprettelsen og utviklingen av Delta på 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 og Zhenzhong Xu.
kilder
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). GJØR JEG:
: "Data Build Tool for Amazon Redshift Storage."
Kilde: www.habr.com