An Erwaardung vun de Start vun engem neie Flux um Taux Mir hunn eng Iwwersetzung vun interessant Material virbereet.
Iwwersiicht
Mir schwätze vun engem zimlech populäre Muster, duerch deen d'Applikatioune verschidde Datenspeicher benotzen, wou all Geschäft fir seng eegen Zwecker benotzt gëtt, zum Beispill fir déi kanonesch Form vun Daten ze späicheren (MySQL, etc.), fortgeschratt Sichméiglechkeeten ubidden (ElasticSearch, etc.) .), Caching (Memcached, etc.) an anerer. Typesch, wann Dir verschidde Dategeschäfter benotzt, wierkt ee vun hinnen als primäre Buttek an déi aner als Derivatgeschäfter. Deen eenzege Problem ass wéi dës Dategeschäfter synchroniséiert ginn.
Mir hunn eng Rei vu verschiddene Mustere gekuckt, déi probéiert hunn de Problem vun der Synchroniséierung vu verschidde Geschäfter ze léisen, sou wéi duebel Schreifweis, verdeelt Transaktiounen, etc. Wéi och ëmmer, dës Approche hunn bedeitend Aschränkungen a punkto reale Liewen, Zouverlässegkeet an Ënnerhalt. Zousätzlech zu der Datesynchroniséierung mussen e puer Uwendungen och Daten beräicheren andeems se extern Servicer uruffen.
Delta gouf entwéckelt fir dës Problemer ze léisen. Delta bitt schlussendlech eng konsequent, event-driven Plattform fir Datensynchroniséierung a Beräicherung.
Bestehend Léisungen
Duebel Entrée
Fir zwee Datenspeicher synchroniséiert ze halen, kënnt Dir Dual Schreiwen benotzen, déi an ee Geschäft schreift an dann direkt duerno an deen aneren schreift. Déi éischt Opnam kann erëm probéiert ginn an déi zweet kann ofgebrach ginn, wann déi éischt net klappt nodeems d'Zuel vun de Versich erschöpft ass. Wéi och ëmmer, déi zwee Datespeicher kënnen aus der Synchroniséierung sinn wann d'Schreiwen an den zweete Buttek feelt. Dëse Problem gëtt normalerweis geléist andeems Dir eng Erhuelungsprozedur erstellt, déi periodesch Daten vun der éischter Späichere op déi zweet iwwerdroe kann, oder dat nëmme maache wann Differenzen an den Daten festgestallt ginn.
D'Problemer si:
Eng Erhuelungsprozedur ausféieren ass eng spezifesch Aarbecht déi net weiderbenotzt ka ginn. Zousätzlech bleiwen d'Donnéeën tëscht Späicherplazen aus der Synchroniséierung bis d'Restauratiounsprozedur stattfënnt. D'Léisung gëtt méi komplex wa méi wéi zwee Dategeschäfter benotzt ginn. Schlussendlech kann d'Restauratiounsprozedur Laascht op d'originell Datequell addéieren.
Änneren Log Dësch
Wann Ännerunge fir eng Rei vun Dëscher optrieden (sou wéi d'Insertéieren, d'Aktualiséierung an d'Läschen vun engem Rekord), ginn d'Ännerungsrecords als Deel vun der selwechter Transaktioun un de Logtabel bäigefüügt. En anere Fuedem oder Prozess freet dauernd Eventer aus der Logtabelle a schreift se an een oder méi Dategeschäfter, wann néideg, Ewechhuele vun Eventer aus der Logtabelle nodeems de Rekord vun alle Geschäfter bestätegt gouf.
D'Problemer si:
Dëst Muster soll als Bibliothéik implementéiert ginn, an am Idealfall ouni de Code vun der Applikatioun z'änneren déi se benotzt. An engem polyglot Ëmfeld soll eng Ëmsetzung vun esou enger Bibliothéik an all néideg Sprooch existéieren, awer d'Konsistenz vu Funktionalitéit a Verhalen iwwer Sproochen ass ganz schwéier ze garantéieren.
En anere Problem läit am Erhalen vun Schema Ännerungen a Systemer déi Transaktiounsschema Ännerungen net ënnerstëtzen [1][2], sou wéi MySQL. Dofir funktionnéiert d'Muster fir eng Ännerung ze maachen (zum Beispill e Schema Ännerung) an d'Transaktioun opzehuelen an der Changement Log Table net ëmmer.
Verdeelt Transaktiounen
Verdeelt Transaktioune kënne benotzt ginn fir eng Transaktioun iwwer multiple heterogenen Dategeschäfter opzedeelen, sou datt d'Operatioun entweder fir all déi benotzte Dategeschäfter engagéiert ass oder net fir eng vun hinnen engagéiert ass.
D'Problemer si:
Verdeelt Transaktiounen sinn e ganz grousse Problem fir heterogen Daten Geschäfter. Duerch hir Natur kënne si nëmmen op den niddregsten gemeinsamen Nenner vun de betraffene Systemer vertrauen. Zum Beispill blockéieren XA Transaktiounen d'Ausféierung wann den Uwendungsprozess während der Virbereedungsphase feelt. Zousätzlech liwwert XA keng Deadlock Detektioun oder ënnerstëtzt optimistesch Concurrency Kontrollschemaen. Zousätzlech ënnerstëtzen e puer Systemer wéi ElasticSearch keng XA oder all aner heterogen Transaktiounsmodell. Also assuréieren d'Atomkraaftegkeet a verschiddenen Datespeichertechnologien ass eng ganz usprochsvoll Aufgab fir Uwendungen [3].
Delta
Delta gouf entwéckelt fir d'Aschränkungen vun existente Datesynchroniséierungsléisungen unzegoen an erméiglecht och On-the-Fly Dateberäicherung. Eist Zil war all dës Komplexitéiten ewech vun Applikatioun Entwéckler ze abstrakt sou datt se sech voll op d'Ëmsetzung vun der Geschäftsfunktionalitéit konzentréiere kënnen. Als nächst wäerte mir "Movie Search" beschreiwen, den aktuellen Benotzungsfall fir Netflix's Delta.
Netflix benotzt wäit eng Mikroservicearchitektur, an all Mikroservice servéiert typesch eng Zort Daten. Basisinformatioun iwwer de Film ass an engem Mikroservice genannt Movie Service enthale, an assoziéiert Donnéeën wéi Informatioun iwwer Produzenten, Akteuren, Ubidder, a sou weider gi vu verschiddenen anere Mikroservicer geréiert (nämlech Deal Service, Talent Service a Vendor Service).
Geschäftsbenotzer bei Netflix Studios mussen dacks iwwer verschidde Filmkritäre sichen, dofir ass et ganz wichteg fir si kënnen iwwer all Film-relatéiert Donnéeën ze sichen.
Virun Delta, huet d'Filmsichteam missen Daten aus verschidde Mikroservicer zéien ier d'Filmdaten indexéiert goufen. Zousätzlech huet d'Team e System missen entwéckelen, deen de Sichindex periodesch aktualiséieren andeems se Ännerungen vun anere Mikroservicer ufroen, och wann et guer keng Ännerunge ginn. Dëse System gouf séier komplex a schwéier ze erhalen.
Figur 1. Ëmfro System zu Delta
Nodeems Dir Delta benotzt huet, gouf de System vereinfacht op en Event-Undriff System wéi an der folgender Figur gewisen. CDC (Change-Data-Capture) Eventer ginn op Keystone Kafka Themen mat Delta-Connector geschéckt. Eng Delta Applikatioun gebaut mam Delta Stream Processing Framework (baséiert op Flink) kritt CDC Eventer vun engem Thema, beräichert se andeems se aner Mikroservicer uruffen, a passéiert endlech déi beräichert Daten un e Sichindex an Elasticsearch. De ganze Prozess fënnt bal an Echtzäit statt, dat ass, soubal Ännerungen am Datelager engagéiert sinn, ginn d'Sichindexe aktualiséiert.
Figur 2. Daten Pipeline benotzt Delta
An de folgende Sektioune wäerte mir d'Operatioun vum Delta-Connector beschreiwen, deen un d'Späichere verbënnt an CDC-Evenementer op d'Transportschicht verëffentlecht, wat eng Echtzäit-Datentransmissionsinfrastruktur ass, déi CDC-Evenementer op Kafka-Themen routes. An um Enn schwätze mir iwwer den Delta Stream Veraarbechtungskader, deen Applikatioun Entwéckler fir Datenveraarbechtung a Beräicherungslogik benotze kënnen.
CDC (Change-Data-Capture)
Mir hunn en CDC Service genannt Delta-Connector entwéckelt, deen engagéiert Ännerungen aus dem Dategeschäft an Echtzäit erfaasse kann an se an e Stroum schreiwen. Echtzäit Ännerungen ginn aus dem Transaktiounsprotokoll a Späicherdumps geholl. Dumps gi benotzt well Transaktiounsprotokoller normalerweis net déi ganz Geschicht vun Ännerungen späicheren. Ännerungen ginn typesch als Delta-Evenementer serialiséiert, sou datt den Empfänger sech keng Suergen maache muss wou d'Ännerung hierkënnt.
Delta-Connector ënnerstëtzt verschidde zousätzlech Funktiounen wéi:
- D'Kapazitéit fir personaliséiert Ausgangsdaten laanscht Kafka ze schreiwen.
- D'Kapazitéit fir manuell Dumps zu all Moment fir all Dëscher, e spezifeschen Dësch oder fir spezifesch Primärschlësselen ze aktivéieren.
- Dumps kënnen a Stécker erëmfonnt ginn, sou datt et net néideg ass fir am Fall vun engem Echec erëm ze starten.
- Et gëtt kee Besoin fir Spären op Dëscher ze placéieren, wat ganz wichteg ass fir sécherzestellen datt d'Datebank Schreifverkéier ni vun eisem Service blockéiert gëtt.
- Héich Disponibilitéit wéinst redundante Instanzen an AWS Disponibilitéitszonen.
Mir ënnerstëtzen de Moment MySQL a Postgres, dorënner Deployementer op AWS RDS an Aurora. Mir ënnerstëtzen och Cassandra (Multi-Master). Dir kënnt méi Detailer iwwer Delta-Connector erausfannen hei .
Kafka an d'Transportschicht
Delta d'Evenement Transport Layer ass op der Plattform Messagerie Service gebaut .
Historesch ass d'Post op Netflix optimiséiert fir Accessibilitéit anstatt laang Liewensdauer (kuckt hei ënnen). ). Den Ofhandlung war potenziell Brokerdaten Inkonsistenz a verschiddene Randszenarien. Zum Beispill, onreine Leader Wahl ass verantwortlech fir datt den Empfänger potenziell duplizéiert oder verlueren Eventer huet.
Mat Delta wollte mir méi staark Haltbarkeetsgarantie fir d'Liwwerung vun CDC Eventer an ofgeleet Geschäfter ze garantéieren. Fir dësen Zweck hu mir e speziell entwéckelte Kafka-Cluster als éischtklasseg Objet proposéiert. Dir kënnt e puer Broker Astellungen an der Tabell hei ënnen kucken:
An Keystone Kafka Cluster, onreine Leader Wahl normalerweis abegraff fir Verëffentlecher Accessibilitéit ze garantéieren. Dëst kann zu Message Verloscht Resultat wann eng unsynchronized Replika als Leader gewielt gëtt. Fir eng nei héich Disponibilitéit Kafka Stärekoup, der Optioun onreine Leader Wahl ausgeschalt fir Message Verloscht ze verhënneren.
Mir hunn och erhéicht Replikatiounsfaktor vun 2 bis 3 Minimum insync replicas 1 bis 2. Verëffentlecher, déi zu dësem Cluster schreiwen, erfuerderen Acks vun allen aneren, fir sécherzestellen datt 2 vun 3 Repliken déi aktuellst Messagen hunn, déi vum Verlag geschéckt ginn.
Wann eng Broker Instanz ophält, ersetzt eng nei Instanz déi al. Wéi och ëmmer, den neie Broker muss mat den onsynchroniséierten Repliken ophalen, wat e puer Stonnen daueren kann. Fir d'Erhuelungszäit fir dëst Szenario ze reduzéieren, hu mir ugefaang Blockdatenlagerung (Amazon Elastic Block Store) ze benotzen anstatt lokal Broker-Disken. Wann eng nei Instanz eng ofgeschloss Broker-Instanz ersetzt, befestegt se den EBS-Volumen deen déi ofgeschloss Instanz hat a fänkt un mat neie Messagen op. Dëse Prozess reduzéiert Réckstandszäit vun Stonnen op Minutten, well déi nei Instanz net méi aus engem eidelen Zoustand muss replizéieren. Insgesamt, getrennte Späicher- a Broker-Lieweszyklen reduzéieren den Impakt vum Broker-Switch wesentlech.
Fir d'Donnéeën Liwwerung Garantie weider ze erhéijen, hu mir benotzt all Message Verloscht ënner extrem Konditiounen z'entdecken (Zum Beispill, Auer desynchronization am Partitur Leader).
Stream Processing Framework
Dem Delta seng Veraarbechtungsschicht ass uewen op der Netflix SPaaS Plattform gebaut, déi Apache Flink Integratioun mam Netflix Ökosystem ubitt. D'Plattform bitt eng User-Interface déi d'Deployment vu Flink Jobs an d'Orchestratioun vu Flink Cluster op der Spëtzt vun eiser Titus Container Management Plattform geréiert. D'Interface geréiert och Aarbechtskonfiguratiounen an erlaabt d'Benotzer Konfiguratiounsännerungen dynamesch ze maachen ouni Flink Aarbechtsplazen nei ze kompiléieren.
Delta bitt e Stroumveraarbechtungskader baséiert op Flink a SPaaS déi benotzt Annotatioun-baséiert DSL (Domain Specific Language) fir technesch Detailer ze abstrakt. Zum Beispill, fir de Schrëtt ze definéieren, op deem d'Evenementer beräichert ginn andeems Dir extern Servicer urufft, mussen d'Benotzer déi folgend DSL schreiwen, an de Kader erstellt e Modell baséiert op deem, dee vum Flink ausgefouert gëtt.
Figur 3. Beispill vun Beräicherung op DSL an Delta
De Veraarbechtungskader reduzéiert net nëmmen d'Léierkurve, awer bitt och gemeinsame Streamveraarbechtungsfeatures wéi Deduplikatioun, Schematiséierung, a Flexibilitéit a Widderstandsfäegkeet fir allgemeng operationell Probleemer ze léisen.
Delta Stream Processing Framework besteet aus zwee Schlësselmoduler, den DSL & API Modul an de Runtime Modul. Den DSL & API Modul bitt DSL an UDF (User-Defined-Function) APIs fir datt d'Benotzer hir eege Veraarbechtungslogik schreiwen (wéi Filteren oder Transformatiounen). De Runtime Modul bitt eng Implementatioun vun engem DSL Parser deen eng intern Representatioun vu Veraarbechtungsschrëtt an DAG Modeller baut. D'Ausféierungskomponent interpretéiert d'DAG Modeller fir déi tatsächlech Flink Aussoen ze initialiséieren a schlussendlech d'Flink Applikatioun auszeféieren. D'Architektur vum Kader gëtt an der folgender Figur illustréiert.
Figur 4. Delta Stream Processing Framework Architektur
Dës Approche huet verschidde Virdeeler:
- D'Benotzer kënnen op hir Geschäftslogik konzentréieren ouni sech an d'Spezifizitéite vu Flink oder der SPaaS Struktur ze verdéiwen.
- Optimisatioun kann op eng Manéier gemaach ginn, déi fir d'Benotzer transparent ass, a Feeler kënne fixéiert ginn ouni datt Ännerunge vum Benotzercode (UDF) erfuerderlech sinn.
- D'Delta Applikatiounserfarung ass vereinfacht fir d'Benotzer well d'Plattform Flexibilitéit a Widderstandsfäegkeet aus der Këscht ubitt an eng Vielfalt vun detailléierte Metriken sammelt déi fir Alarmer benotzt kënne ginn.
Produktioun benotzen
Delta ass zënter méi wéi engem Joer a Produktioun a spillt eng Schlësselroll a ville Netflix Studio Uwendungen. Si huet Teams gehollef Benotzungsfäll wéi Sichindexéierung, Datelagerung an Event-driven Workflows ëmzesetzen. Drënner ass en Iwwerbléck iwwer d'High-Level Architektur vun der Delta Plattform.
Figur 5. Delta héich-Niveau Architektur.
Unerkennungen
Mir wëllen déi folgend Leit Merci soen, déi un der Schafung an der Entwécklung vum Delta bei Netflix involvéiert waren: 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 and Zhenzhong Xu.
Quellen vun Informatiounen
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online Event Veraarbechtung. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Date Build Tool fir Amazon Redshift Storage."
Source: will.com