In afwachting van de lancering van een nieuwe stroom tegen het tarief We hebben een vertaling van interessant materiaal voorbereid.
Recensie
We zullen het hebben over een redelijk populair patroon waarbij applicaties meerdere datastores gebruiken, waarbij elke winkel voor zijn eigen doeleinden wordt gebruikt, bijvoorbeeld om de canonieke vorm van gegevens op te slaan (MySQL, enz.), geavanceerde zoekmogelijkheden te bieden (ElasticSearch, etc.) .), caching (Memcached, etc.) en anderen. Wanneer u meerdere gegevensopslagplaatsen gebruikt, fungeert doorgaans één ervan als de primaire opslag en de andere als afgeleide opslagplaatsen. Het enige probleem is hoe deze gegevensopslag te synchroniseren.
We hebben gekeken naar een aantal verschillende patronen die probeerden het probleem van het synchroniseren van meerdere winkels op te lossen, zoals dubbele schrijfbewerkingen, gedistribueerde transacties, enz. Deze benaderingen hebben echter aanzienlijke beperkingen op het gebied van gebruik in de praktijk, betrouwbaarheid en onderhoud. Naast datasynchronisatie moeten sommige applicaties ook data verrijken door externe diensten aan te roepen.
Delta is ontwikkeld om deze problemen op te lossen. Delta biedt uiteindelijk een consistent, gebeurtenisgestuurd platform voor gegevenssynchronisatie en -verrijking.
Bestaande oplossingen
Dubbele ingang
Om twee gegevensarchieven gesynchroniseerd te houden, kunt u dual write gebruiken, waarbij naar het ene archief wordt geschreven en onmiddellijk daarna naar het andere wordt geschreven. De eerste opname kan opnieuw worden geprobeerd en de tweede kan worden afgebroken als de eerste mislukt nadat het aantal pogingen is opgebruikt. De twee gegevensopslagplaatsen kunnen echter niet meer synchroon lopen als het schrijven naar de tweede opslag mislukt. Dit probleem wordt meestal opgelost door een herstelprocedure te creëren die periodiek gegevens van de eerste opslag naar de tweede kan overbrengen, of dit alleen kan doen als er verschillen in de gegevens worden gedetecteerd.
Eigenschappen:
Het uitvoeren van een herstelprocedure is een specifieke taak die niet opnieuw kan worden gebruikt. Bovendien blijven gegevens tussen opslaglocaties niet gesynchroniseerd totdat de herstelprocedure plaatsvindt. De oplossing wordt complexer als er meer dan twee datastores worden gebruikt. Ten slotte kan de herstelprocedure de oorspronkelijke gegevensbron belasten.
Wijzig de logboektabel
Wanneer er wijzigingen optreden in een reeks tabellen (zoals het invoegen, bijwerken en verwijderen van een record), worden de wijzigingsrecords toegevoegd aan de logboektabel als onderdeel van dezelfde transactie. Een andere thread of proces vraagt voortdurend om gebeurtenissen uit de logtabel en schrijft deze naar een of meer gegevensarchieven. Indien nodig worden gebeurtenissen uit de logtabel verwijderd nadat de record door alle winkels is bevestigd.
Eigenschappen:
Dit patroon moet worden geïmplementeerd als een bibliotheek, en idealiter zonder de code te wijzigen van de applicatie die er gebruik van maakt. In een meertalige omgeving zou een implementatie van een dergelijke bibliotheek in elke benodigde taal moeten bestaan, maar het garanderen van consistentie van functionaliteit en gedrag tussen talen is erg moeilijk.
Een ander probleem ligt in het verkrijgen van schemawijzigingen in systemen die geen transactionele schemawijzigingen ondersteunen [1][2], zoals MySQL. Daarom zal het patroon van het aanbrengen van een wijziging (bijvoorbeeld een schemawijziging) en het transactioneel vastleggen ervan in de tabel met wijzigingenlogboeken niet altijd werken.
Gedistribueerde transacties
Gedistribueerde transacties kunnen worden gebruikt om een transactie te splitsen over meerdere heterogene gegevensarchieven, zodat de bewerking wordt vastgelegd voor alle gebruikte gegevensarchieven, of niet voor een daarvan.
Eigenschappen:
Gedistribueerde transacties vormen een zeer groot probleem voor heterogene dataopslagplaatsen. Door hun aard kunnen zij alleen vertrouwen op de kleinste gemene deler van de betrokken systemen. XA-transacties blokkeren bijvoorbeeld de uitvoering als het aanvraagproces mislukt tijdens de voorbereidingsfase. Bovendien biedt XA geen deadlock-detectie en ondersteunt het geen optimistische controlesystemen voor gelijktijdigheid. Bovendien ondersteunen sommige systemen zoals ElasticSearch geen XA of enig ander heterogeen transactiemodel. Het garanderen van schrijfatomiciteit in verschillende technologieën voor gegevensopslag blijft dus een zeer uitdagende taak voor toepassingen [3].
Delta
Delta is ontworpen om de beperkingen van bestaande datasynchronisatieoplossingen aan te pakken en maakt ook on-the-fly dataverrijking mogelijk. Ons doel was om al deze complexiteiten weg te nemen van applicatieontwikkelaars, zodat zij zich volledig konden concentreren op het implementeren van zakelijke functionaliteit. Vervolgens beschrijven we "Movie Search", de daadwerkelijke gebruikssituatie voor Netflix's Delta.
Netflix maakt op grote schaal gebruik van een microservice-architectuur, en elke microservice bedient doorgaans één type gegevens. Basisinformatie over de film is opgenomen in een microservice genaamd Movie Service, en bijbehorende gegevens, zoals informatie over producenten, acteurs, leveranciers, enzovoort, worden beheerd door verschillende andere microservices (namelijk Deal Service, Talent Service en Vendor Service).
Zakelijke gebruikers bij Netflix Studios moeten vaak zoeken in verschillende filmcriteria. Daarom is het erg belangrijk dat ze in alle filmgerelateerde gegevens kunnen zoeken.
Vóór Delta moest het filmzoekteam gegevens uit meerdere microservices halen voordat de filmgegevens konden worden geïndexeerd. Bovendien moest het team een systeem ontwikkelen dat de zoekindex periodiek zou bijwerken door wijzigingen aan te vragen bij andere microservices, zelfs als er helemaal geen wijzigingen waren. Dit systeem werd al snel complex en moeilijk te onderhouden.
Figuur 1. Pollingsysteem voor Delta
Na het gebruik van Delta werd het systeem vereenvoudigd tot een gebeurtenisgestuurd systeem, zoals weergegeven in de volgende afbeelding. CDC-gebeurtenissen (Change-Data-Capture) worden met behulp van Delta-Connector naar Keystone Kafka-onderwerpen verzonden. Een Delta-applicatie die is gebouwd met behulp van het Delta Stream Processing Framework (gebaseerd op Flink) ontvangt CDC-gebeurtenissen van een onderwerp, verrijkt deze door andere microservices aan te roepen en geeft de verrijkte gegevens uiteindelijk door aan een zoekindex in Elasticsearch. Het hele proces vindt vrijwel in realtime plaats, dat wil zeggen dat zodra wijzigingen in het datawarehouse worden doorgevoerd, de zoekindexen worden bijgewerkt.
Figuur 2. Datapijplijn met behulp van Delta
In de volgende paragrafen beschrijven we de werking van de Delta-Connector, die verbinding maakt met de opslag en CDC-gebeurtenissen publiceert naar de transportlaag, wat een realtime datatransmissie-infrastructuur is die CDC-gebeurtenissen naar Kafka-onderwerpen routeert. En helemaal aan het einde zullen we het hebben over het Delta-streamverwerkingsframework, dat applicatie-ontwikkelaars kunnen gebruiken voor gegevensverwerking en verrijkingslogica.
CDC (wijzigingsgegevens vastleggen)
We hebben een CDC-service ontwikkeld, Delta-Connector genaamd, die vastgelegde wijzigingen in realtime uit de dataopslag kan vastleggen en naar een stream kan schrijven. Realtime wijzigingen worden overgenomen uit het transactielogboek en de opslagdumps. Dumps worden gebruikt omdat transactielogboeken doorgaans niet de gehele geschiedenis van wijzigingen opslaan. Wijzigingen worden doorgaans geserialiseerd als Delta-gebeurtenissen, zodat de ontvanger zich geen zorgen hoeft te maken over waar de wijziging vandaan komt.
Delta-Connector ondersteunt verschillende extra functies, zoals:
- Mogelijkheid om aangepaste uitvoergegevens voorbij Kafka te schrijven.
- Mogelijkheid om op elk moment handmatige dumps te activeren voor alle tabellen, een specifieke tabel of voor specifieke primaire sleutels.
- Dumps kunnen in delen worden opgehaald, zodat u bij een storing niet helemaal opnieuw hoeft te beginnen.
- Het is niet nodig om vergrendelingen op tabellen te plaatsen, wat erg belangrijk is om ervoor te zorgen dat databaseschrijfverkeer nooit door onze service wordt geblokkeerd.
- Hoge beschikbaarheid dankzij redundante instances in AWS Availability Zones.
We ondersteunen momenteel MySQL en Postgres, inclusief implementaties op AWS RDS en Aurora. We ondersteunen ook Cassandra (multimaster). Meer informatie over Delta-Connector vindt u hier .
Kafka en de transportlaag
De evenemententransportlaag van Delta is gebouwd op de berichtenservice van het platform .
Historisch gezien is het posten op Netflix geoptimaliseerd voor toegankelijkheid in plaats van voor een lange levensduur (zie hieronder). ). De wisselwerking was de potentiële inconsistentie van makelaarsgegevens in verschillende randscenario's. Bijvoorbeeld, onreine leidersverkiezing is er verantwoordelijk voor dat de ontvanger mogelijk dubbele of verloren evenementen heeft.
Met Delta wilden we sterkere duurzaamheidsgaranties om de levering van CDC-evenementen aan afgeleide winkels te garanderen. Voor dit doel hebben we een speciaal ontworpen Kafka-cluster voorgesteld als eersteklas object. In de onderstaande tabel kunt u enkele brokerinstellingen bekijken:
In Keystone Kafka-clusters, onreine leidersverkiezing meestal opgenomen om de toegankelijkheid van de uitgever te garanderen. Dit kan resulteren in berichtverlies als een niet-gesynchroniseerde replica als leider wordt gekozen. Voor een nieuw Kafka-cluster met hoge beschikbaarheid is de optie onreine leidersverkiezing uitgeschakeld om berichtverlies te voorkomen.
Wij zijn ook toegenomen replicatiefactor van 2 naar 3 en minimale insync-replica's 1 tot 2. Uitgevers die naar dit cluster schrijven, hebben bevestigingen van alle anderen nodig, zodat twee van de drie replica's de meest recente berichten bevatten die door de uitgever zijn verzonden.
Wanneer een brokerinstantie wordt beëindigd, vervangt een nieuwe instantie de oude. De nieuwe makelaar zal echter de niet-gesynchroniseerde replica's moeten inhalen, wat enkele uren kan duren. Om de hersteltijd voor dit scenario te verkorten, zijn we begonnen met het gebruik van blokgegevensopslag (Amazon Elastic Block Store) in plaats van lokale brokerschijven. Wanneer een nieuw exemplaar een beëindigde brokerinstantie vervangt, wordt het EBS-volume toegevoegd dat het beëindigde exemplaar had en begint het nieuwe berichten in te halen. Dit proces reduceert de tijd voor het opruimen van de achterstand van uren naar minuten, omdat het nieuwe exemplaar niet langer vanuit een lege status hoeft te repliceren. Over het algemeen verminderen gescheiden opslag- en brokerlevenscycli de impact van het wisselen van broker aanzienlijk.
Om de dataleveringsgarantie verder te vergroten, hebben we gebruik gemaakt van om berichtverlies onder extreme omstandigheden te detecteren (bijvoorbeeld klokdesynchronisatie in de partitieleider).
Kader voor stroomverwerking
De verwerkingslaag van Delta is bovenop het Netflix SPAaS-platform gebouwd, dat Apache Flink-integratie met het Netflix-ecosysteem biedt. Het platform biedt een gebruikersinterface die de inzet van Flink-taken en de orkestratie van Flink-clusters beheert bovenop ons Titus containerbeheerplatform. De interface beheert ook taakconfiguraties en stelt gebruikers in staat configuratiewijzigingen dynamisch aan te brengen zonder Flink-taken opnieuw te hoeven compileren.
Delta biedt een streamverwerkingsframework gebaseerd op Flink en SPAaS dat gebruikmaakt van op basis van annotaties DSL (Domain Specific Language) om technische details te abstraheren. Om bijvoorbeeld de stap te definiëren waarin gebeurtenissen zullen worden verrijkt door het aanroepen van externe diensten, moeten gebruikers de volgende DSL schrijven, en het raamwerk zal daarop een model creëren, dat zal worden uitgevoerd door Flink.
Figuur 3. Voorbeeld van verrijking op DSL in Delta
Het verwerkingsframework verkort niet alleen de leercurve, maar biedt ook algemene stroomverwerkingsfuncties zoals deduplicatie, schematisering en flexibiliteit en veerkracht om veelvoorkomende operationele problemen op te lossen.
Delta Stream Processing Framework bestaat uit twee belangrijke modules, de DSL & API-module en de Runtime-module. De DSL & API-module biedt DSL- en UDF-API's (User-Defined-Function), zodat gebruikers hun eigen verwerkingslogica kunnen schrijven (zoals filtering of transformaties). De Runtime-module biedt een implementatie van een DSL-parser die een interne representatie van verwerkingsstappen in DAG-modellen opbouwt. De uitvoeringscomponent interpreteert DAG-modellen om de daadwerkelijke Flink-instructies te initialiseren en uiteindelijk de Flink-applicatie uit te voeren. De architectuur van het raamwerk wordt geïllustreerd in de volgende afbeelding.
Figuur 4. Delta Stream Processing Framework-architectuur
Deze aanpak heeft verschillende voordelen:
- Gebruikers kunnen zich concentreren op hun bedrijfslogica zonder zich te hoeven verdiepen in de specifieke kenmerken van Flink of de SPAaS-structuur.
- Optimalisatie kan worden uitgevoerd op een manier die transparant is voor gebruikers en fouten kunnen worden verholpen zonder dat er wijzigingen in de gebruikerscode (UDF) nodig zijn.
- De Delta-applicatie-ervaring is vereenvoudigd voor gebruikers omdat het platform out-of-the-box flexibiliteit en veerkracht biedt en een verscheidenheid aan gedetailleerde statistieken verzamelt die kunnen worden gebruikt voor waarschuwingen.
Productie gebruik
Delta is al ruim een jaar in productie en speelt een sleutelrol in veel Netflix Studio-applicaties. Ze hielp teams bij het implementeren van gebruiksscenario's zoals zoekindexering, gegevensopslag en gebeurtenisgestuurde workflows. Hieronder vindt u een overzicht van de hoogwaardige architectuur van het Delta-platform.
Figuur 5. Delta's architectuur op hoog niveau.
Dankbetuigingen
We willen graag de volgende mensen bedanken die betrokken waren bij de creatie en ontwikkeling van Delta bij 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 en Zhenzhong Xu.
bronnen
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online gebeurtenisverwerking. Gemeenschappelijk. ACM 62(5): 43–49 (2019). DOI:
: "Gegevensopbouwtool voor Amazon Redshift-opslag."
Bron: www.habr.com