Yn ôfwachting fan de lansearring fan in nije stream op it taryf in oersetting makke fan nijsgjirrich materiaal.
oersjoch
Wy sille prate oer in frij populêr patroan wêrby't applikaasjes meardere gegevenswinkels brûke, wêrby't elke winkel wurdt brûkt foar har eigen doelen, bygelyks om de kanonike foarm fan gegevens op te slaan (MySQL, ensfh.), Avansearre sykmooglikheden leverje (ElasticSearch, ensfh.) .), caching (Memcached, ensfh.) en oaren. Typysk, by it brûken fan meardere gegevenswinkels, fungearret ien fan har as de primêre winkel en de oaren as derivative winkels. It ienige probleem is hoe't jo dizze gegevenswinkels syngronisearje.
Wy seagen in oantal ferskillende patroanen dy't besochten it probleem op te lossen fan syngronisaasje fan meardere winkels, lykas dûbele skriuwingen, ferspraat transaksjes, ensfh. Dizze oanpak hawwe lykwols wichtige beheiningen yn termen fan gebrûk, betrouberens en ûnderhâld yn it echte libben. Neist gegevenssyngronisaasje moatte guon applikaasjes ek gegevens ferrykje troch eksterne tsjinsten te skiljen.
Delta waard ûntwikkele om dizze problemen op te lossen. Delta leveret úteinlik in konsekwint, evenemint-oandreaune platfoarm foar datasyngronisaasje en ferriking.
Besteande oplossings
Dûbele yngong
Om twa gegevenswinkels syngronisearje te hâlden, kinne jo dûbele skriuw brûke, dy't skriuwt nei de iene winkel en dan direkt nei de oare skriuwt. De earste opname kin op 'e nij besocht wurde en de twadde kin ôfbrutsen wurde as de earste mislearret nei't it oantal besykjen is útput. De twa gegevenswinkels kinne lykwols net syngronisearje as it skriuwen nei de twadde winkel mislearret. Dit probleem wurdt normaal oplost troch it meitsjen fan in herstelproseduere dy't periodyk gegevens fan 'e earste opslach nei de twadde kin oerdrage, of allinich dwaan as ferskillen yn' e gegevens ûntdutsen wurde.
Problemen:
It útfieren fan in herstelproseduere is in spesifike taak dy't net opnij brûkt wurde kin. Derneist bliuwe gegevens tusken opslachlokaasjes net syngronisearre oant de herstelproseduere plakfynt. De oplossing wurdt komplekser as mear as twa data winkels wurde brûkt. Uteinlik kin de weromsetteproseduere lading tafoegje oan 'e orizjinele gegevensboarne.
Feroarje log tabel
As feroarings foarkomme oan in set fan tabellen (lykas it ynfoegje, bywurkje en wiskjen fan in record), wurde de feroaringsrecords tafoege oan de logtabel as ûnderdiel fan deselde transaksje. In oare tried of proses freget hieltyd eveneminten út de log tafel en skriuwt se nei ien of mear gegevens winkels, as it nedich is, it fuortsmiten fan eveneminten út de log tafel nei it rekord is befêstige troch alle winkels.
Problemen:
Dit patroan moat wurde ymplementearre as in bibleteek, en by útstek sûnder feroarjen fan de koade fan de applikaasje dy't it brûkt. Yn in polyglot-omjouwing soe in ymplemintaasje fan sa'n bibleteek moatte bestean yn elke nedige taal, mar it garandearjen fan gearhing fan funksjonaliteit en gedrach oer talen is heul lestich.
In oar probleem leit yn it krijen fan skemawizigingen yn systemen dy't transaksjeske skemawizigingen net stypje [1][2], lykas MySQL. Dêrom sil it patroan fan it meitsjen fan in wiziging (bygelyks in skemawiziging) en it transaksjoneel opnimmen yn 'e wizigingslogtabel net altyd wurkje.
Ferspraat Transaksjes
Ferdielde transaksjes kinne brûkt wurde om in transaksje te splitsen oer meardere heterogene gegevenswinkels, sadat de operaasje óf ynset is foar alle brûkte gegevenswinkels, óf net ynsette foar ien fan har.
Problemen:
Ferdielde transaksjes binne in heul grut probleem foar heterogene gegevenswinkels. Troch har aard kinne se allinich fertrouwe op de leechste mienskiplike neamer fan 'e belutsen systemen. Bygelyks, XA-transaksjes blokkearje útfiering as it oanfraachproses mislearret tidens de tariedingsfaze. Derneist leveret XA gjin deadlock-deteksje of stipet optimistyske regelingen foar concurrency-kontrôle. Derneist stypje guon systemen lykas ElasticSearch gjin XA of in oar heterogene transaksjemodel. Sa bliuwt it garandearjen fan skriuwatomiteit yn ferskate technologyen foar gegevensopslach in heul útdaagjende taak foar applikaasjes [3].
Delta
Delta is ûntworpen om de beheiningen fan besteande oplossings foar gegevenssyngronisaasje oan te pakken en makket ek gegevensferriking on-the-fly mooglik. Us doel wie om al dizze kompleksiteiten fuort te abstraheren fan applikaasje-ûntwikkelders, sadat se folslein koenen rjochtsje op it ymplementearjen fan saaklike funksjonaliteit. Folgjende sille wy "Movie Search" beskriuwe, it eigentlike gebrûk foar Netflix's Delta.
Netflix brûkt in protte mikroservicearsjitektuer, en elke mikroservice tsjinnet typysk ien soart gegevens. Basisynformaasje oer de film is befette yn in mikrotsjinst neamd Movie Service, en byhearrende gegevens lykas ynformaasje oer produsinten, akteurs, ferkeapers, ensafuorthinne, wurdt beheard troch ferskate oare mikrotsjinsten (nammentlik Deal Service, Talent Service en Vendor Service).
Saaklike brûkers by Netflix Studios moatte faak sykje oer ferskate filmkritearia, dat is de reden dat it tige wichtich is foar har om te kinnen sykje oer alle filmrelatearre gegevens.
Foardat Delta moast it filmsykteam gegevens fan meardere mikrotsjinsten lûke foardat de filmgegevens yndekseare. Dêrnjonken moast it team in systeem ûntwikkelje dat de sykyndeks periodyk bywurkje soe troch feroaringen oan te freegjen fan oare mikrotsjinsten, sels as d'r hielendal gjin wizigingen wiene. Dit systeem waard fluch kompleks en dreech te ûnderhâlden.
figuer 1. Polling systeem nei Delta
Nei it brûken fan Delta, waard it systeem ferienfâldige ta in evenemint oandreaune systeem lykas werjûn yn de folgjende figuer. CDC (Change-Data-Capture)-eveneminten wurde stjoerd nei Keystone Kafka-ûnderwerpen mei Delta-Connector. In Delta-applikaasje boud mei it Delta Stream Processing Framework (basearre op Flink) ûntfangt CDC-eveneminten fan in ûnderwerp, ferrykt se troch oare mikrotsjinsten te roppen, en bringt úteinlik de ferrike gegevens troch nei in sykopdracht yn Elasticsearch. It hiele proses fynt plak hast yn echte tiid, dat is, sa gau as wizigingen wurde ynset op it data warehouse, sykje yndeksen wurde bywurke.
figuer 2. Data pipeline mei help fan Delta
Yn 'e folgjende seksjes sille wy de wurking fan' e Delta-Connector beskriuwe, dy't oanslút op 'e opslach en publisearret CDC-eveneminten oan' e ferfierslaach, dat is in ynfrastruktuer foar real-time gegevensferfier dy't CDC-eveneminten nei Kafka-ûnderwerpen rûtes. En oan 'e ein sille wy prate oer it Delta-streamferwurkingskader, dat applikaasje-ûntwikkelders kinne brûke foar gegevensferwurking en logika foar ferriking.
CDC (Change-Data-Capture)
Wy hawwe ûntwikkele in CDC tsjinst neamd Delta-Connector, dat kin fange tawijd feroarings út de gegevens winkel yn it echt en skriuwe se nei in stream. Real-time feroarings wurde nommen út it transaksje log en opslach dumps. Dumps wurde brûkt om't transaksjelogboeken normaal net de hiele skiednis fan feroaringen opslaan. Feroarings wurde typysk serialisearre as Delta-eveneminten, sadat de ûntfanger gjin soargen hoecht te meitsjen oer wêr't de feroaring weikomt.
Delta-Connector stipet ferskate ekstra funksjes lykas:
- Mooglikheid om oanpaste útfiergegevens nei Kafka te skriuwen.
- Mooglikheid om manuele dumps op elk momint te aktivearjen foar alle tabellen, in spesifike tabel, of foar spesifike primêre kaaien.
- Dumps kinne wurde ophelle yn brokken, dus it is net nedich om opnij te begjinnen yn gefal fan mislearring.
- D'r is gjin needsaak om slûzen op tabellen te pleatsen, wat heul wichtich is om te soargjen dat databankskriuwferkear nea blokkearre wurdt troch ús tsjinst.
- Hege beskikberens fanwege oerstallige ynstânsjes yn AWS Beskikberenssônes.
Wy stypje op it stuit MySQL en Postgres, ynklusyf ynset op AWS RDS en Aurora. Wy stypje ek Cassandra (multi-master). Jo kinne hjir mear details fine oer Delta-Connector .
Kafka en de transportlaach
Delta's evenemintferfierlaach is boud op 'e berjochtentsjinst fan it platfoarm .
Histoarysk is it pleatsen op Netflix optimalisearre foar tagonklikens ynstee fan langstme (sjoch hjirûnder). ). De ôfwikseling wie potinsjele ynkonsistinsje fan brokergegevens yn ferskate râne-senario's. Bygelyks, ûnreine lieder ferkiezing is ferantwurdlik foar de ûntfanger mooglik hawwende dûbele of ferlerne eveneminten.
Mei Delta woenen wy sterkere garânsjes foar duorsumens om levering fan CDC-eveneminten te garandearjen oan ôflaat winkels. Foar dit doel hawwe wy in spesjaal ûntwurpen Kafka-kluster foarsteld as in earste-klasse objekt. Jo kinne nei guon brokerynstellingen sjen yn 'e tabel hjirûnder:
Yn Keystone Kafka-klusters, ûnreine lieder ferkiezing meastal opnommen om de tagonklikheid fan útjouwers te garandearjen. Dit kin resultearje yn berjochtferlies as in net-syngronisearre replika wurdt keazen as lieder. Foar in nij hege beskikberens Kafka kluster, de opsje ûnreine lieder ferkiezing útskeakele om berjochtferlies foar te kommen.
Wy hawwe ek ferhege replikaasje faktor fan 2 oan 3 minimale insync replika's 1 oan 2. Utjouwers dy't skriuwe nei dit kluster fereaskje acks fan alle oaren, soargje derfoar dat 2 fan de 3 replika's hawwe de meast aktuele berjochten ferstjoerd troch de útjouwer.
As in broker-eksimplaar beëiniget, ferfangt in nije eksimplaar de âlde. De nije makelder sil lykwols moatte ynhelje mei de unsyngronisearre replika's, dy't ferskate oeren duorje kinne. Om de hersteltiid foar dit senario te ferminderjen, begûnen wy blokgegevens opslach te brûken (Amazon Elastic Block Store) ynstee fan lokale brokerskiven. As in nije eksimplaar in beëinige broker-eksimplaar ferfangt, heakket it it EBS-folume oan dat it beëinige eksimplaar hie en begjint nije berjochten yn te heljen. Dit proses ferminderet efterstân klaring tiid fan oeren nei minuten omdat de nije eksimplaar net mear hoecht te replicate út in lege steat. Oer it algemien ferminderje aparte opslach- en broker-libbenssyklusen de ynfloed fan brokerwikseling signifikant.
Om fierder te fergrutsjen de gegevens levering garânsje, wy brûkt om elk berjochtferlies te detektearjen ûnder ekstreme omstannichheden (Bygelyks klok desyngronisaasje yn 'e partition lieder).
Stream Processing Framework
De ferwurkingslaach fan Delta is boud boppe op it Netflix SPaaS-platfoarm, dat Apache Flink-yntegraasje leveret mei it Netflix-ekosysteem. It platfoarm biedt in brûkersynterface dy't de ynset fan Flink-banen en orkestraasje fan Flink-klusters beheart boppe op ús Titus-kontenerbehearplatfoarm. De ynterface beheart ek baankonfiguraasjes en lit brûkers konfiguraasjewizigingen dynamysk meitsje sûnder Flink-banen opnij te kompilearjen.
Delta jout in stream ferwurkjen ramt basearre op Flink en SPaaS dat brûkt annotaasje-basearre DSL (Domain Specific Language) foar abstrakte technyske details. Bygelyks, om de stap te definiearjen wêryn eveneminten ferrike wurde troch eksterne tsjinsten te roppen, moatte brûkers de folgjende DSL skriuwe, en it ramt sil dêrop in model meitsje, dat sil wurde útfierd troch Flink.
figuer 3. Foarbyld fan ferriking op DSL yn Delta
It ferwurkingskader ferminderet net allinich de learkurve, mar leveret ek mienskiplike streamferwurkingsfunksjes lykas deduplikaasje, skematisaasje, en fleksibiliteit en fearkrêft om mienskiplike operasjonele problemen op te lossen.
Delta Stream Processing Framework bestiet út twa kaai modules, de DSL & API module en de Runtime module. De module DSL & API leveret DSL en UDF (User-Defined-Function) API's sadat brûkers har eigen ferwurkingslogika kinne skriuwe (lykas filterjen of transformaasjes). De Runtime-module leveret in ymplemintaasje fan in DSL-parser dy't in ynterne fertsjintwurdiging bout fan ferwurkingsstappen yn DAG-modellen. De útfieringskomponint ynterpretearret DAG-modellen om de eigentlike Flink-útspraken te inisjalisearjen en úteinlik de Flink-applikaasje út te fieren. De arsjitektuer fan it ramt wurdt yllustrearre yn de folgjende figuer.
figuer 4. Delta Stream Processing Framework arsjitektuer
Dizze oanpak hat ferskate foardielen:
- Brûkers kinne har rjochtsje op har bedriuwslogika sûnder hoege te ferdjipjen yn 'e spesifiken fan Flink of de SPaaS-struktuer.
- Optimalisaasje kin dien wurde op in manier dy't trochsichtich is foar brûkers, en flaters kinne wurde reparearre sûnder feroaringen oan 'e brûkerskoade (UDF) nedich te meitsjen.
- De Delta-applikaasjeûnderfining is ferienfâldige foar brûkers, om't it platfoarm fleksibiliteit en fearkrêft leveret út 'e doaze en in ferskaat oan detaillearre metriken sammelt dy't kinne wurde brûkt foar warskôgings.
Produksje gebrûk
Delta is al mear as in jier yn produksje en spilet in wichtige rol yn in protte Netflix Studio-applikaasjes. Se holp teams mei it ymplementearjen fan gebrûksgefallen lykas sykyndeksearring, gegevensopslach, en evenemint-oandreaune workflows. Hjirûnder is in oersjoch fan 'e arsjitektuer op hege nivo fan it Delta-platfoarm.
figuer 5. Delta syn hege-nivo arsjitektuer.
Erkennings
Wy wolle de folgjende minsken betankje dy't belutsen wiene by de skepping en ûntwikkeling fan 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.
Boarnen
- Martin Kleppmann, Alastair R. Beresford, Boorge Svingen: Online evenemint ferwurking. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Data Build Tool foar Amazon Redshift Storage."
Boarne: www.habr.com