I forventning om lanceringen af et nyt flow på hastigheden Vi har udarbejdet en oversættelse af interessant materiale.
Anmeldelse
Vi vil tale om et ret populært mønster, hvor applikationer bruger flere datalagre, hvor hver butik bruges til sine egne formål, for eksempel til at gemme den kanoniske form for data (MySQL osv.), give avancerede søgefunktioner (ElasticSearch, etc.) .), caching (Memcached osv.) og andre. Typisk, når du bruger flere datalagre, fungerer et af dem som det primære lager og de andre som afledte lagre. Det eneste problem er, hvordan man synkroniserer disse datalagre.
Vi så på en række forskellige mønstre, der forsøgte at løse problemet med at synkronisere flere butikker, såsom dobbeltskrivninger, distribuerede transaktioner osv. Disse tilgange har dog betydelige begrænsninger med hensyn til virkelig brug, pålidelighed og vedligeholdelse. Ud over datasynkronisering skal nogle applikationer også berige data ved at ringe til eksterne tjenester.
Delta blev udviklet til at løse disse problemer. Delta giver i sidste ende en konsistent, begivenhedsdrevet platform til datasynkronisering og berigelse.
Eksisterende løsninger
Dobbelt indgang
For at holde to datalagre synkroniseret kan du bruge dobbeltskrivning, som skriver til det ene lager og derefter skriver til det andet umiddelbart bagefter. Den første optagelse kan prøves igen, og den anden kan afbrydes, hvis den første mislykkes, efter at antallet af forsøg er opbrugt. De to datalagre kan dog blive ude af synkronisering, hvis skrivning til det andet lager mislykkes. Dette problem løses normalt ved at oprette en gendannelsesprocedure, der med jævne mellemrum kan overføre data fra det første lager til det andet, eller kun gøre det, hvis der opdages forskelle i dataene.
Problemerne:
Udførelse af en gendannelsesprocedure er et specifikt job, der ikke kan genbruges. Derudover forbliver data mellem lagerplaceringer ude af synkronisering, indtil gendannelsesproceduren finder sted. Løsningen bliver mere kompleks, hvis der bruges mere end to datalagre. Endelig kan gendannelsesproceduren tilføje belastning til den originale datakilde.
Skift logtabel
Når der sker ændringer i et sæt tabeller (såsom indsættelse, opdatering og sletning af en post), tilføjes ændringsposterne til logtabellen som en del af den samme transaktion. En anden tråd eller proces anmoder konstant om hændelser fra logtabellen og skriver dem til et eller flere datalagre, hvis det er nødvendigt, fjerner hændelser fra logtabellen, efter at posten er bekræftet af alle lagre.
Problemerne:
Dette mønster bør implementeres som et bibliotek, og ideelt set uden at ændre koden for den applikation, der bruger det. I et polyglot-miljø bør en implementering af et sådant bibliotek eksistere på ethvert nødvendigt sprog, men det er meget vanskeligt at sikre ensartethed i funktionalitet og adfærd på tværs af sprog.
Et andet problem ligger i at opnå skemaændringer i systemer, der ikke understøtter transaktionelle skemaændringer [1][2], såsom MySQL. Derfor vil mønsteret med at foretage en ændring (for eksempel en skemaændring) og transaktionsregistrering af den i ændringslogtabellen ikke altid fungere.
Distribuerede transaktioner
Distribuerede transaktioner kan bruges til at opdele en transaktion på tværs af flere heterogene datalagre, så operationen enten er forpligtet til alle de anvendte datalagre eller ikke forpligtet til nogen af dem.
Problemerne:
Distribuerede transaktioner er et meget stort problem for heterogene datalagre. I sagens natur kan de kun stole på den laveste fællesnævner af de involverede systemer. For eksempel blokerer XA-transaktioner eksekvering, hvis ansøgningsprocessen mislykkes under forberedelsesfasen. Derudover leverer XA ikke deadlock-detektion eller understøtter optimistiske samtidighedskontrolordninger. Derudover understøtter nogle systemer som ElasticSearch ikke XA eller nogen anden heterogen transaktionsmodel. Derfor er det fortsat en meget udfordrende opgave for applikationer at sikre skriveatomicitet i forskellige datalagringsteknologier [3].
Delta
Delta er designet til at adressere begrænsningerne ved eksisterende datasynkroniseringsløsninger og muliggør også databerigelse undervejs. Vores mål var at abstrahere alle disse kompleksiteter væk fra applikationsudviklere, så de fuldt ud kunne fokusere på implementering af forretningsfunktionalitet. Dernæst vil vi beskrive "Movie Search", den faktiske anvendelse af Netflix's Delta.
Netflix bruger i vid udstrækning en mikroservicearkitektur, og hver mikroservice serverer typisk én type data. Grundlæggende oplysninger om en film er indeholdt i en mikrotjeneste kaldet Movie Service, og relaterede data, såsom oplysninger om producenter, skuespillere, leverandører og så videre, administreres af flere andre mikrotjenester (nemlig Deal Service, Talent Service og Vendor Service).
Erhvervsbrugere hos Netflix Studios skal ofte søge på tværs af forskellige filmkriterier, hvorfor det er meget vigtigt for dem at kunne søge på tværs af alle filmrelaterede data.
Før Delta skulle filmsøgningsteamet trække data fra flere mikrotjenester, før filmdataene blev indekseret. Derudover skulle teamet udvikle et system, der med jævne mellemrum opdaterede søgeindekset ved at anmode om ændringer fra andre mikrotjenester, selvom der slet ikke var nogen ændringer. Dette system blev hurtigt komplekst og vanskeligt at vedligeholde.
Figur 1. Pollingsystem til Delta
Efter brug af Delta blev systemet forenklet til et hændelsesdrevet system som vist i den følgende figur. CDC-hændelser (Change-Data-Capture) sendes til Keystone Kafka-emner ved hjælp af Delta-Connector. En Delta-applikation bygget ved hjælp af Delta Stream Processing Framework (baseret på Flink) modtager CDC-hændelser fra et emne, beriger dem ved at ringe til andre mikrotjenester og sender til sidst de berigede data til et søgeindeks i Elasticsearch. Hele processen foregår næsten i realtid, det vil sige, så snart ændringer er forpligtet til datavarehuset, opdateres søgeindekser.
Figur 2. Datapipeline ved hjælp af Delta
I de følgende afsnit vil vi beskrive driften af Delta-Connector, som forbinder til lageret og udgiver CDC-hændelser til transportlaget, som er en datatransmissionsinfrastruktur i realtid, der dirigerer CDC-hændelser til Kafka-emner. Og til allersidst vil vi tale om Delta-strømbehandlingsrammerne, som applikationsudviklere kan bruge til databehandling og berigelseslogik.
CDC (Change-Data-Capture)
Vi har udviklet en CDC-tjeneste kaldet Delta-Connector, som kan fange forpligtede ændringer fra datalageret i realtid og skrive dem til en stream. Ændringer i realtid tages fra transaktionsloggen og lagerdumps. Dumps bruges, fordi transaktionslogfiler normalt ikke gemmer hele historikken for ændringer. Ændringer serialiseres typisk som Delta-begivenheder, så modtageren behøver ikke at bekymre sig om, hvor ændringen kommer fra.
Delta-Connector understøtter flere yderligere funktioner, såsom:
- Evne til at skrive brugerdefinerede outputdata forbi Kafka.
- Mulighed for at aktivere manuelle dumps til enhver tid for alle tabeller, en specifik tabel eller for specifikke primærnøgler.
- Dumps kan hentes i bidder, så der er ingen grund til at starte forfra i tilfælde af fejl.
- Der er ingen grund til at placere låse på tabeller, hvilket er meget vigtigt for at sikre, at databaseskrivetrafik aldrig blokeres af vores service.
- Høj tilgængelighed på grund af redundante forekomster i AWS Availability Zones.
Vi understøtter i øjeblikket MySQL og Postgres, herunder implementeringer på AWS RDS og Aurora. Vi støtter også Cassandra (multi-master). Du kan finde flere detaljer om Delta-Connector her .
Kafka og transportlaget
Deltas hændelsestransportlag er bygget på platformens meddelelsestjeneste .
Historisk set er opslag på Netflix blevet optimeret til tilgængelighed frem for lang levetid (se nedenfor). ). Afvejningen var potentiel mæglerdatainkonsekvens i forskellige kantscenarier. For eksempel, urent ledervalg er ansvarlig for, at modtageren potentielt har duplikerede eller mistede begivenheder.
Med Delta ønskede vi stærkere holdbarhedsgarantier for at sikre levering af CDC-begivenheder til afledte butikker. Til dette formål foreslog vi en specialdesignet Kafka-klynge som et førsteklasses objekt. Du kan se nogle mæglerindstillinger i tabellen nedenfor:
I Keystone Kafka-klynger, urent ledervalg normalt inkluderet for at sikre udgiverens tilgængelighed. Dette kan resultere i tab af besked, hvis en usynkroniseret replika vælges som leder. For en ny høj tilgængelig Kafka-klynge, muligheden urent ledervalg slået fra for at forhindre tab af beskeder.
Vi steg også replikationsfaktor fra 2 til 3 og minimum insync replikaer 1 til 2. Udgivere, der skriver til denne klynge, kræver acks fra alle andre for at sikre, at 2 ud af 3 replikaer har de seneste beskeder sendt af udgiveren.
Når en mæglerinstans afsluttes, erstatter en ny instans den gamle. Den nye mægler bliver dog nødt til at indhente de usynkroniserede replikaer, hvilket kan tage flere timer. For at reducere gendannelsestiden for dette scenarie begyndte vi at bruge blokdatalagring (Amazon Elastic Block Store) i stedet for lokale mæglerdiske. Når en ny instans erstatter en afsluttet mæglerinstans, vedhæfter den den EBS-volumen, som den afsluttede instans havde, og begynder at indhente nye beskeder. Denne proces reducerer tilbageholdelsestiden fra timer til minutter, fordi den nye forekomst ikke længere behøver at replikere fra en tom tilstand. Generelt reducerer separat lager- og mæglerlivscyklusser virkningen af mæglerskifte betydeligt.
For yderligere at øge dataleveringsgarantien brugte vi at detektere ethvert meddelelsestab under ekstreme forhold (f.eks. clock-desynkronisering i partitionslederen).
Stream Processing Framework
Deltas behandlingslag er bygget oven på Netflix SPaaS-platformen, som giver Apache Flink-integration med Netflix-økosystemet. Platformen giver en brugergrænseflade, der styrer implementeringen af Flink-job og orkestrering af Flink-klynger oven på vores Titus container management platform. Interfacet administrerer også jobkonfigurationer og giver brugerne mulighed for at foretage konfigurationsændringer dynamisk uden at skulle genkompilere Flink-job.
Delta leverer en strømbehandlingsramme baseret på Flink og SPaaS, der bruger annotationsbaseret DSL (Domain Specific Language) til abstrakte tekniske detaljer. For eksempel, for at definere det trin, hvor hændelser skal beriges ved at ringe til eksterne tjenester, skal brugerne skrive følgende DSL, og rammen vil skabe en model baseret på den, som vil blive udført af Flink.
Figur 3. Eksempel på berigelse på DSL i Delta
Behandlingsrammen reducerer ikke kun indlæringskurven, men giver også fælles strømbehandlingsfunktioner såsom deduplikering, skematisering og fleksibilitet og modstandsdygtighed til at løse almindelige driftsproblemer.
Delta Stream Processing Framework består af to nøglemoduler, DSL & API-modulet og Runtime-modulet. DSL & API modulet leverer DSL og UDF (User-Defined-Function) API'er, så brugerne kan skrive deres egen behandlingslogik (såsom filtrering eller transformationer). Runtime-modulet giver en implementering af en DSL-parser, der bygger en intern repræsentation af behandlingstrin i DAG-modeller. Execution-komponenten fortolker DAG-modeller for at initialisere de faktiske Flink-sætninger og i sidste ende køre Flink-applikationen. Strukturens arkitektur er illustreret i den følgende figur.
Figur 4. Delta Stream Processing Framework-arkitektur
Denne tilgang har flere fordele:
- Brugere kan fokusere på deres forretningslogik uden at skulle dykke ned i detaljerne i Flink eller SPaaS-strukturen.
- Optimering kan udføres på en måde, der er gennemsigtig for brugerne, og fejl kan rettes uden at kræve ændringer i brugerkoden (UDF).
- Delta-applikationsoplevelsen er forenklet for brugerne, fordi platformen giver fleksibilitet og modstandsdygtighed ud af boksen og indsamler en række detaljerede målinger, der kan bruges til advarsler.
Produktionsbrug
Delta har været i produktion i over et år og spiller en nøglerolle i mange Netflix Studio-applikationer. Hun hjalp teams med at implementere use cases såsom søgeindeksering, datalagring og hændelsesdrevne arbejdsgange. Nedenfor er en oversigt over Delta-platformens højniveauarkitektur.
Figur 5. Deltas højniveauarkitektur.
Tak
Vi vil gerne takke følgende personer, der var involveret i skabelsen og udviklingen af Delta hos 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 begivenhedsbehandling. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Dataopbygningsværktøj til Amazon Redshift Storage."
Kilde: www.habr.com