In afwagting van die bekendstelling van 'n nuwe vloei teen die koers Ons het 'n vertaling van interessante materiaal voorberei.
Hersien
Ons sal praat oor 'n redelik gewilde patroon waarvolgens toepassings veelvuldige datawinkels gebruik, waar elke winkel vir sy eie doeleindes gebruik word, byvoorbeeld om die kanonieke vorm van data (MySQL, ens.) te stoor, om gevorderde soekvermoëns te verskaf (ElasticSearch, ens.) .), caching (Memcached, ens.) en ander. Tipies, wanneer veelvuldige datawinkels gebruik word, tree een van hulle op as die primêre winkel en die ander as afgeleide winkels. Die enigste probleem is hoe om hierdie datawinkels te sinchroniseer.
Ons het na 'n aantal verskillende patrone gekyk wat probeer het om die probleem van sinchronisering van verskeie winkels op te los, soos dubbelskryf, verspreide transaksies, ens. Hierdie benaderings het egter aansienlike beperkings in terme van werklike gebruik, betroubaarheid en instandhouding. Benewens datasinchronisasie, moet sommige toepassings ook data verryk deur eksterne dienste te skakel.
Delta is ontwikkel om hierdie probleme op te los. Delta bied uiteindelik 'n konsekwente, gebeurtenisgedrewe platform vir datasinchronisasie en -verryking.
Bestaande oplossings
Dubbel inskrywing
Om twee datastore sinchroniseer te hou, kan jy dubbelskryf gebruik, wat na een winkel skryf en dan onmiddellik daarna na die ander skryf. Die eerste opname kan herprobeer word en die tweede kan geaborteer word as die eerste misluk nadat die aantal pogings uitgeput is. Die twee datawinkels kan egter nie gesinchroniseer word as skryf na die tweede winkel misluk nie. Hierdie probleem word gewoonlik opgelos deur 'n herstelprosedure te skep wat data periodiek van die eerste berging na die tweede kan oordra, of dit slegs doen as verskille in die data bespeur word.
Probleme:
Om 'n herstelprosedure uit te voer is 'n spesifieke werk wat nie hergebruik kan word nie. Daarbenewens bly data tussen stoorliggings nie gesinchroniseer nie totdat die herstelprosedure plaasvind. Die oplossing word meer kompleks as meer as twee datastore gebruik word. Laastens kan die herstelprosedure las by die oorspronklike databron voeg.
Verander logtabel
Wanneer veranderinge aan 'n stel tabelle plaasvind (soos die invoeging, opdatering en uitvee van 'n rekord), word die veranderingsrekords by die logtabel gevoeg as deel van dieselfde transaksie. 'n Ander draad of proses versoek voortdurend gebeurtenisse van die logtabel en skryf dit na een of meer datastore, indien nodig, en verwyder gebeurtenisse van die logtabel nadat die rekord deur alle winkels bevestig is.
Probleme:
Hierdie patroon moet as 'n biblioteek geïmplementeer word, en ideaal gesproke sonder om die kode van die toepassing wat dit gebruik, te verander. In 'n poliglot-omgewing behoort 'n implementering van so 'n biblioteek in enige nodige taal te bestaan, maar om konsekwentheid van funksionaliteit en gedrag oor tale heen te verseker, is baie moeilik.
Nog 'n probleem lê in die verkryging van skemaveranderinge in stelsels wat nie transaksionele skemaveranderings ondersteun nie [1][2], soos MySQL. Daarom sal die patroon om 'n verandering (byvoorbeeld 'n skemaverandering) te maak en dit transaksioneel in die veranderingslogtabel aan te teken nie altyd werk nie.
Verspreide transaksies
Verspreide transaksies kan gebruik word om 'n transaksie oor verskeie heterogene datastore te verdeel sodat die bewerking óf verbind is tot al die datastore wat gebruik word, óf nie verbind is tot enige van hulle nie.
Probleme:
Verspreide transaksies is 'n baie groot probleem vir heterogene datawinkels. Uit hul aard kan hulle net staatmaak op die laagste gemene deler van die betrokke sisteme. Byvoorbeeld, XA-transaksies blokkeer uitvoering as die aansoekproses tydens die voorbereidingsfase misluk. Boonop bied XA nie dooiepuntopsporing of ondersteun optimistiese gelyktydigheidsbeheerskemas nie. Daarbenewens ondersteun sommige stelsels soos ElasticSearch nie XA of enige ander heterogene transaksiemodel nie. Die versekering van skryfatomisiteit in verskeie databergingstegnologieë bly dus 'n baie uitdagende taak vir toepassings [3].
Delta
Delta is ontwerp om die beperkings van bestaande datasinchronisasie-oplossings aan te spreek en maak ook dataverryking onmiddellik moontlik. Ons doel was om al hierdie kompleksiteite weg van toepassingsontwikkelaars te abstraheer sodat hulle ten volle kon fokus op die implementering van besigheidsfunksionaliteit. Volgende sal ons "Movie Search" beskryf, die werklike gebruiksgeval vir Netflix se Delta.
Netflix gebruik wyd 'n mikrodiensargitektuur, en elke mikrodiens bedien tipies een tipe data. Basiese inligting oor die film is vervat in 'n mikrodiens genaamd Movie Service, en gepaardgaande data soos inligting oor vervaardigers, akteurs, verskaffers, ensovoorts word deur verskeie ander mikrodienste (naamlik Deal Service, Talent Service en Vendor Service) bestuur.
Besigheidsgebruikers by Netflix Studios moet dikwels oor verskeie rolprentkriteria soek, en daarom is dit baie belangrik vir hulle om oor alle filmverwante data te kan soek.
Voor Delta moes die flieksoekspan data uit verskeie mikrodienste trek voordat die fliekdata geïndekseer word. Daarbenewens moes die span 'n stelsel ontwikkel wat die soekindeks periodiek sou bywerk deur veranderinge van ander mikrodienste aan te vra, selfs al was daar glad nie veranderinge nie. Hierdie stelsel het vinnig kompleks geword en moeilik om in stand te hou.
Figuur 1. Pollingstelsel na Delta
Nadat Delta gebruik is, is die stelsel vereenvoudig na 'n gebeurtenisgedrewe stelsel soos in die volgende figuur getoon. CDC-gebeurtenisse (Change-Data-Capture) word na Keystone Kafka-onderwerpe gestuur deur Delta-Connector te gebruik. 'n Delta-toepassing wat gebou is met behulp van die Delta Stream Processing Framework (gebaseer op Flink) ontvang CDC-gebeure van 'n onderwerp, verryk dit deur ander mikrodienste te skakel, en gee uiteindelik die verrykte data deur na 'n soekindeks in Elasticsearch. Die hele proses vind byna in reële tyd plaas, dit wil sê sodra veranderinge aan die datapakhuis toegepas word, word soekindekse opgedateer.
Figuur 2. Datapyplyn wat Delta gebruik
In die volgende afdelings sal ons die werking van die Delta-Connector beskryf, wat aan die berging koppel en CDC-gebeure na die vervoerlaag publiseer, wat 'n intydse data-oordrag-infrastruktuur is wat CDC-gebeure na Kafka-onderwerpe stuur. En heel aan die einde sal ons praat oor die Delta-stroomverwerkingsraamwerk, wat toepassingsontwikkelaars kan gebruik vir dataverwerking en verrykingslogika.
CDC (Change-Data-Capture)
Ons het 'n CDC-diens genaamd Delta-Connector ontwikkel, wat toegewyde veranderinge van die datastoor in reële tyd kan vaslê en dit na 'n stroom kan skryf. Intydse veranderinge word uit die transaksielogboek en stoorstortings geneem. Stortings word gebruik omdat transaksielogboeke gewoonlik nie die hele geskiedenis van veranderinge stoor nie. Veranderinge word tipies as Delta-gebeure gerangskik, so die ontvanger hoef nie bekommerd te wees oor waar die verandering vandaan kom nie.
Delta-Connector ondersteun verskeie bykomende kenmerke soos:
- Vermoë om pasgemaakte uitvoerdata verby Kafka te skryf.
- Vermoë om handmatige stortings te eniger tyd vir alle tabelle, 'n spesifieke tabel of vir spesifieke primêre sleutels te aktiveer.
- Stortings kan in stukke opgespoor word, so dit is nie nodig om van voor af te begin in geval van mislukking nie.
- Dit is nie nodig om slotte op tafels te plaas nie, wat baie belangrik is om te verseker dat databasisskryfverkeer nooit deur ons diens geblokkeer word nie.
- Hoë beskikbaarheid as gevolg van oortollige gevalle in AWS-beskikbaarheidsones.
Ons ondersteun tans MySQL en Postgres, insluitend implementerings op AWS RDS en Aurora. Ons ondersteun ook Cassandra (multi-meester). Jy kan meer besonderhede oor Delta-Connector hier uitvind .
Kafka en die vervoerlaag
Delta se gebeurtenisvervoerlaag is gebou op die platform se boodskapdiens .
Histories is plasing op Netflix geoptimaliseer vir toeganklikheid eerder as langlewendheid (sien hieronder). ). Die afweging was potensiële makelaardata-teenstrydigheid in verskeie randscenario's. Byvoorbeeld, onrein leier verkiesing is daarvoor verantwoordelik dat die ontvanger moontlik duplikaat of verlore gebeure het.
Met Delta wou ons sterker duursaamheidswaarborge hê om aflewering van CDC-geleenthede aan afgeleide winkels te verseker. Vir hierdie doel het ons 'n spesiaal ontwerpte Kafka-kluster as 'n eersteklas voorwerp voorgestel. U kan na 'n paar makelaarinstellings in die tabel hieronder kyk:
In Keystone Kafka-klusters, onrein leier verkiesing gewoonlik ingesluit om toeganklikheid vir uitgewer te verseker. Dit kan lei tot verlore boodskappe as 'n ongesinchroniseerde replika as die leier verkies word. Vir 'n nuwe hoë beskikbaarheid Kafka-kluster, die opsie onrein leier verkiesing afgeskakel om boodskapverlies te voorkom.
Ons het ook toegeneem replikasie faktor van 2 tot 3 en minimum insinkroniseer replikas 1 tot 2. Uitgewers wat na hierdie groepie skryf, vereis bevestigings van alle ander, om te verseker dat 2 uit 3 replikas die nuutste boodskappe het wat deur die uitgewer gestuur is.
Wanneer 'n makelaar-instansie beëindig word, vervang 'n nuwe instansie die ou een. Die nuwe makelaar sal egter die ongesinchroniseerde replikas moet inhaal, wat 'n paar uur kan neem. Om die hersteltyd vir hierdie scenario te verminder, het ons blokdataberging (Amazon Elastic Block Store) in plaas van plaaslike makelaarskywe begin gebruik. Wanneer 'n nuwe instansie 'n beëindigde makelaar-instansie vervang, heg dit die EBS-volume aan wat die beëindigde instansie gehad het en begin nuwe boodskappe inhaal. Hierdie proses verminder die agterstandopruimingstyd van ure na minute omdat die nuwe instansie nie meer vanuit 'n leë toestand hoef te repliseer nie. In die algemeen verminder afsonderlike berging- en makelaarlewensiklusse die impak van makelaarskakeling aansienlik.
Om die data-leweringswaarborg verder te verhoog, het ons gebruik om enige boodskapverlies onder uiterste toestande op te spoor (byvoorbeeld klok desinchronisasie in die partisieleier).
Stroomverwerkingsraamwerk
Delta se verwerkingslaag is bo-op die Netflix SPaaS-platform gebou, wat Apache Flink-integrasie met die Netflix-ekosisteem bied. Die platform bied 'n gebruikerskoppelvlak wat die ontplooiing van Flink-take en orkestrasie van Flink-klusters bestuur bo-op ons Titus-houerbestuurplatform. Die koppelvlak bestuur ook werkkonfigurasies en stel gebruikers in staat om konfigurasieveranderinge dinamies aan te bring sonder om Flink-take te hersaamstel.
Delta bied 'n stroomverwerkingsraamwerk gebaseer op Flink en SPaaS wat gebruik op annotasie gebaseer DSL (Domain Specific Language) om tegniese besonderhede te abstraheer. Byvoorbeeld, om die stap te definieer waarop gebeure verryk sal word deur eksterne dienste te bel, moet gebruikers die volgende DSL skryf, en die raamwerk sal 'n model skep wat daarop gebaseer is, wat deur Flink uitgevoer sal word.
Figuur 3. Voorbeeld van verryking op DSL in Delta
Die verwerkingsraamwerk verminder nie net die leerkurwe nie, maar verskaf ook algemene stroomverwerkingskenmerke soos deduplisering, skematisering en buigsaamheid en veerkragtigheid om algemene operasionele probleme op te los.
Delta Stream Processing Framework bestaan uit twee sleutelmodules, die DSL & API module en die Runtime module. Die DSL & API-module verskaf DSL- en UDF (User-Defined-Function) API's sodat gebruikers hul eie verwerkingslogika (soos filtering of transformasies) kan skryf. Die Runtime-module verskaf 'n implementering van 'n DSL-ontleder wat 'n interne voorstelling van verwerkingstappe in DAG-modelle bou. Die uitvoeringskomponent interpreteer DAG-modelle om die werklike Flink-stellings te inisialiseer en uiteindelik die Flink-toepassing te laat loop. Die argitektuur van die raamwerk word in die volgende figuur geïllustreer.
Figuur 4. Deltastroomverwerkingsraamwerkargitektuur
Hierdie benadering het verskeie voordele:
- Gebruikers kan op hul besigheidslogika fokus sonder om in die besonderhede van Flink of die SPaaS-struktuur te delf.
- Optimalisering kan gedoen word op 'n manier wat deursigtig is vir gebruikers, en foute kan reggestel word sonder dat enige veranderinge aan die gebruikerskode (UDF) vereis word.
- Die Delta-toepassingservaring word vir gebruikers vereenvoudig omdat die platform buigsaamheid en veerkragtigheid buite die boks bied en 'n verskeidenheid gedetailleerde statistieke versamel wat vir waarskuwings gebruik kan word.
Produksie gebruik
Delta is al meer as 'n jaar in produksie en speel 'n sleutelrol in baie Netflix Studio-toepassings. Sy het spanne gehelp om gebruiksgevalle soos soekindeksering, databerging en gebeurtenisgedrewe werkvloei te implementeer. Hieronder is 'n oorsig van die hoëvlak-argitektuur van die Delta-platform.
Figuur 5. Delta se hoëvlak-argitektuur.
Erkennings
Ons wil graag die volgende mense bedank wat betrokke was by die skepping en ontwikkeling van Delta by 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.
bronne
- Martin Kleppmann, Alastair R. Beresford, Boorge Svingen: Aanlyn gebeurtenis verwerking. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Databou-nutsding vir Amazon Redshift-berging."
Bron: will.com