Fluxu berri baten abiaraztearen esperoan Material interesgarriaren itzulpena prestatu dugu.
ΠΠ±Π·ΠΎΡ
Nahiko eredu ezagun bati buruz hitz egingo dugu, zeinetan aplikazioek hainbat datu biltegi erabiltzen dituzten, non denda bakoitza bere helburuetarako erabiltzen den, adibidez, datuen forma kanonikoa gordetzeko (MySQL, etab.), bilaketa-gaitasun aurreratuak (ElasticSearch, etab.) gordetzeko. etab.) .), cachea (Memcached, etab.) eta beste batzuk. Normalean, hainbat datu biltegi erabiltzean, horietako batek biltegi nagusi gisa jokatzen du eta besteek biltegi deribatu gisa. Arazo bakarra datu biltegi hauek nola sinkronizatu da.
Hainbat denda sinkronizatzeko arazoa konpontzen saiatzen ziren eredu ezberdin batzuk aztertu genituen, hala nola idazketa bikoitzak, transakzio banatuak, etab. Hala ere, ikuspegi hauek muga handiak dituzte bizitza errealeko erabilerari, fidagarritasunari eta mantentzeari dagokionez. Datuen sinkronizazioaz gain, aplikazio batzuek datuak aberastu behar dituzte kanpoko zerbitzuetara deituz.
Arazo horiek konpontzeko Delta garatu zen. Delta-k, azken finean, datuen sinkronizaziorako eta aberasteko plataforma koherentea eta gertaeretan oinarrituta eskaintzen du.
Dauden irtenbideak
Sarrera bikoitza
Bi datu biltegi sinkronizatuta mantentzeko, idazketa bikoitza erabil dezakezu, denda batean idazten duena eta berehala bestean idazten duena. Lehenengo grabaketa berriro saia daiteke eta bigarrena bertan behera utz daiteke saiakera kopurua agortu ondoren lehenengoak huts egiten badu. Hala ere, baliteke bi datu biltegiak sinkronizatzea bigarren biltegian idazten huts egiten badu. Arazo hau, normalean, lehen biltegiratzetik bigarrenera datuak aldian-aldian berriro transferi ditzakeen berreskuratze prozedura bat sortuz konpontzen da, edo datuetan desberdintasunak hautematen badira bakarrik egin.
Arazoak:
Berreskuratze prozedura bat egitea berrerabili ezin den lan zehatza da. Gainera, biltegiratze-kokapenen arteko datuak sinkronizatuta geratzen dira leheneratzeko prozedura egiten den arte. Irtenbidea konplexuagoa bihurtzen da bi datu biltegi baino gehiago erabiltzen badira. Azkenik, leheneratzeko prozedurak karga gehi diezaioke jatorrizko datu-iturburuari.
Aldatu erregistro-taula
Taula multzo batean aldaketak gertatzen direnean (adibidez, erregistro bat txertatzea, eguneratzea eta ezabatzea), aldaketa-erregistroak erregistro-taulara gehitzen dira transakzio beraren zati gisa. Beste hari edo prozesu batek etengabe eskatzen ditu gertaerak erregistro-taulatik eta datu-biltegi batean edo gehiagotan idazten ditu, beharrezkoa bada, erregistro-taulatik gertaerak kenduz, erregistroa denda guztiek baieztatu ondoren.
Arazoak:
Eredu hau liburutegi gisa inplementatu behar da, eta hobe da hura erabiltzen duen aplikazioaren kodea aldatu gabe. Ingurune poliglota batean, liburutegi horren inplementazioa beharrezkoa den edozein hizkuntzatan egon beharko litzateke, baina hizkuntzen arteko funtzionaltasunaren eta portaeraren koherentzia bermatzea oso zaila da.
Beste arazo bat eskema-aldaketak lortzean datza transakzio-eskema-aldaketak onartzen ez dituzten sistemetan [1][2], MySQL adibidez. Hori dela eta, aldaketa bat egiteko ereduak (adibidez, eskema-aldaketa bat) eta transakzioz aldaketen erregistro-taulan erregistratzeko ereduak ez du beti funtzionatuko.
Banatutako Transakzioak
Banatutako transakzioak transakzio bat hainbat datu-biltegi heterogeneotan banatzeko erabil daitezke, eragiketa erabilitako datu-biltegi guztietan konprometituta egon dadin, edo horietako inongo konprometitu gabe.
Arazoak:
Banatutako transakzioak oso arazo handiak dira datu biltegi heterogeneoentzat. Bere izaeragatik, inplikatutako sistemen izendatzaile komun txikienean soilik fidatu daitezke. Adibidez, XA transakzioek exekuzioa blokeatzen dute aplikazio-prozesuak prestaketa-fasean huts egiten badu. Gainera, XAk ez du blokeo-blokea detektatzeko edo aldiberekotasun-kontroleko eskema baikorrak onartzen. Gainera, ElasticSearch bezalako sistema batzuek ez dute XA edo beste transakzio eredu heterogeneorik onartzen. Beraz, hainbat datu biltegiratzeko teknologietan idazketa atomotasuna ziurtatzea oso erronka zaila izaten jarraitzen du aplikazioentzat [3].
Delta
Delta lehendik dauden datuak sinkronizatzeko soluzioen mugei aurre egiteko diseinatu zen eta, gainera, berehalako datuak aberastea ahalbidetzen du. Gure helburua konplexutasun horiek guztiak aplikazioen garatzaileengandik urruntzea zen, negozio-funtzionalitateak ezartzean guztiz zentratu ahal izateko. Jarraian, "Movie Search" deskribatuko dugu, Netflix-en Deltaren benetako erabilera kasua.
Netflixek asko erabiltzen du mikrozerbitzuen arkitektura bat, eta mikrozerbitzu bakoitzak normalean datu mota bat eskaintzen du. Filmari buruzko oinarrizko informazioa Movie Service izeneko mikrozerbitzu batean dago, eta erlazionatutako datuak, hala nola ekoizle, aktore, saltzaile eta abarrei buruzko informazioa, beste hainbat mikrozerbitzuk kudeatzen dute (Deal Service, Talent Service eta Vendor Service, alegia).
Netflix Studios-en negozio-erabiltzaileek askotan filmaren irizpide ezberdinetan bilatu behar dute, horregatik oso garrantzitsua da haientzat filmekin lotutako datu guztietan bilatu ahal izatea.
Delta baino lehen, filmak bilatzeko taldeak hainbat mikrozerbitzutako datuak atera behar zituen filmaren datuak indexatu aurretik. Gainera, taldeak beste mikrozerbitzuei aldaketak eskatuz bilaketa-indizea aldian-aldian eguneratuko zuen sistema garatu behar izan zuen, nahiz eta aldaketarik egon ez. Sistema hau azkar bihurtu zen konplexua eta mantentzea zaila.
1. irudia. Deltarako galdeketa sistema
Delta erabili ondoren, sistema sinplifikatu egin zen gertaeren bidezko sistema batera, hurrengo irudian erakusten den moduan. CDC (Change-Data-Capture) gertaerak Keystone Kafka gaietara bidaltzen dira Delta-Connector erabiliz. Delta Stream Processing Framework (Flink-en oinarrituta) erabiliz eraikitako Delta aplikazio batek gai bateko CDC gertaerak jasotzen ditu, beste mikrozerbitzu batzuetara deituz aberasten ditu eta, azkenik, datu aberastuak Elasticsearch-eko bilaketa-indize batera pasatzen ditu. Prozesu osoa ia denbora errealean gertatzen da, hau da, datu biltegian aldaketak egin bezain laster, bilaketa-indizeak eguneratzen dira.
2. irudia. Delta erabiliz datu kanalizazioa
Hurrengo ataletan, Delta-Connector-aren funtzionamendua deskribatuko dugu, biltegiratzera konektatzen dena eta CDC gertaerak garraio-geruzara argitaratzen dituena, hau da, denbora errealeko datu-transmisioko azpiegitura bat da, CDCko gertaerak Kafka gaietara bideratzen dituena. Eta amaieran, Delta stream prozesatzeko esparruari buruz hitz egingo dugu, aplikazioen garatzaileek datuen prozesatzeko eta aberasteko logikarako erabil dezaketena.
CDC (Aldaketa-Datu-Captura)
Delta-Connector izeneko CDC zerbitzua garatu dugu, datu biltegitik konprometitutako aldaketak denbora errealean jaso eta korronte batean idatzi ditzakeena. Denbora errealeko aldaketak transakzioen erregistrotik eta biltegiratze-zerbitzuetatik ateratzen dira. Zabortegiak erabiltzen dira transakzioen erregistroek normalean ez dutelako aldaketen historia osoa gordetzen. Aldaketak, normalean, Delta gertaera gisa seriatzen dira, beraz, hartzaileak ez du kezkatu behar aldaketa nondik datorren.
Delta-Connector-ek hainbat funtzio gehigarri onartzen ditu, hala nola:
- Kafka erabiliz irteerako datuak pertsonalizatuak idazteko gaitasuna.
- Eskuzko iraulketak edozein unetan aktibatzeko gaitasuna taula guztietarako, taula zehatz baterako edo lehen gako zehatzetarako.
- Zabortegiak zatika har daitezke, beraz, hutsegite kasuan ez dago berriro berriro hasi beharrik.
- Tauletan ez dago blokeorik jarri beharrik, eta hori oso garrantzitsua da datu-baseen idazketa-trafikoa gure zerbitzuak inoiz blokeatzen ez duela ziurtatzeko.
- Eskuragarritasun handia AWSren erabilgarritasun guneetako instantzia erredundanteengatik.
Gaur egun MySQL eta Postgres onartzen ditugu, AWS RDS eta Aurora inplementazioak barne. Cassandra ere onartzen dugu (multi-master). Delta-Connector-i buruzko xehetasun gehiago aurki ditzakezu hemen .
Kafka eta garraio geruza
Deltaren gertaeren garraio-geruza plataformaren mezularitza-zerbitzuan eraikita dago .
Historikoki, Netflix-en argitalpenak irisgarritasunerako optimizatu dira, iraupenerako baino (ikus behean). ). Konpromisoa brokerren datuen inkoherentzia izan zen hainbat ertz agertokitan. Adibidez, buruzagi zikinen hautaketa hartzaileak gertakari bikoiztuak edo galduak izan ditzakeen arduraduna da.
Deltarekin, iraunkortasun berme sendoagoak nahi genituen CDC ekitaldiak eratorritako dendetara entregatzeko. Horretarako, bereziki diseinatutako Kafka kluster bat proposatu genuen lehen mailako objektu gisa. Artekarien ezarpen batzuk ikus ditzakezu beheko taulan:
Keystone Kafka multzoetan, buruzagi zikinen hautaketa normalean sartzen dira argitaletxeen irisgarritasuna bermatzeko. Honek mezuak galtzea eragin dezake sinkronizatu gabeko erreplika bat buruzagi gisa hautatzen bada. Erabilgarritasun handiko Kafka kluster berri baterako, aukera buruzagi zikinen hautaketa desaktibatuta mezua gal ez dadin.
Gu ere handitu ginen erreplikazio-faktorea 2tik 3ra eta gutxieneko erreplika insinkronizatuak 1etik 2ra. Kluster honetan idazten duten argitaletxeek beste guztien akzioak eskatzen dituzte, eta 2 errepliketatik 3k argitaletxeak bidalitako mezu berrienak dituztela ziurtatuz.
Agentearen instantzia amaitzen denean, instantzia berri batek zaharra ordezkatzen du. Hala ere, artekari berriak sinkronizatu gabeko erreplikekin harrapatu beharko ditu, eta horrek hainbat ordu behar izan ditzake. Egoera honen berreskuratze-denbora murrizteko, bloke-datuen biltegiratzea erabiltzen hasi ginen (Amazon Elastic Block Store) tokiko broker-diskoen ordez. Instantzia berri batek amaitutako broker-instantzia bat ordezkatzen duenean, amaitutako instantzia horrek zeukan EBS bolumena eransten du eta mezu berriekin harrapatzen hasten da. Prozesu honek atzerapena garbitzeko denbora orduetatik minutuetara murrizten du, instantzia berriak jada ez duelako egoera huts batetik errepikatu behar. Oro har, biltegiratze eta artekarien bizi-ziklo bereiziek nabarmen murrizten dute artekarien aldaketaren eragina.
Datuak emateko bermea are gehiago handitzeko, erabili dugu edozein mezu-galera detektatzeko muturreko baldintzetan (adibidez, erlojuaren desinkronizazioa partizioaren lidergoan).
Korronteen prozesatzeko esparrua
Deltaren prozesatzeko geruza Netflix SPaaS plataformaren gainean eraikita dago, eta horrek Apache Flink Netflix ekosistemarekin integratzen du. Plataformak erabiltzaile-interfaze bat eskaintzen du, Flink lanpostuen hedapena eta Flink klusterren orkestrazioa kudeatzen dituena gure Titus edukiontzien kudeaketa plataformaren gainean. Interfazeak lan-konfigurazioak ere kudeatzen ditu eta erabiltzaileei konfigurazio-aldaketak dinamikoki egiteko aukera ematen die Flink-eko lanak berriro konpilatu beharrik gabe.
Deltak erabiltzen duen Flink eta SPaaS-en oinarritutako korronte prozesatzeko esparru bat eskaintzen du oharpenetan oinarrituta DSL (Domain Specific Language) xehetasun teknikoak laburtzeko. Esaterako, kanpoko zerbitzuetara deituz gertaerak zein urrats aberastuko diren definitzeko, erabiltzaileek honako DSL hau idatzi behar dute, eta markoak horretan oinarritutako eredu bat sortuko du, Flinkek exekutatuko duena.
3. Irudia. Deltan DSLn aberastearen adibidea
Prozesamendu-esparruak ikaskuntza-kurba murrizteaz gain, korronte-prozesatzeko ezaugarri komunak ere eskaintzen ditu, hala nola deduplicazioa, eskematizazioa eta malgutasuna eta erresilientzia arazo operatibo arruntak konpontzeko.
Delta Stream Processing Framework gako bi modulu ditu, DSL eta API modulua eta Runtime modulua. DSL & API moduluak DSL eta UDF (User-Defined-Function) APIak eskaintzen ditu, erabiltzaileek beren prozesatzeko logika propioa idatzi ahal izateko (adibidez, iragazkiak edo eraldaketak). Runtime moduluak DSL analizatzaile baten inplementazioa eskaintzen du, DAG ereduetan prozesatzeko urratsen barne irudikapena eraikitzen duena. Execution osagaiak DAG ereduak interpretatzen ditu benetako Flink adierazpenak hasieratzeko eta, azken finean, Flink aplikazioa exekutatzeko. Markoaren arkitektura hurrengo irudian azaltzen da.
4. Irudia. Delta Stream Processing Framework arkitektura
Ikuspegi honek hainbat abantaila ditu:
- Erabiltzaileek beren negozio-logikan zentratu ahal izango dute Flink-en edo SPaaS egituraren berezitasunetan sakondu beharrik gabe.
- Optimizazioa erabiltzaileentzat gardena den moduan egin daiteke, eta akatsak konpondu daitezke erabiltzaile-kodean (UDF) aldaketarik behar izan gabe.
- Delta aplikazioaren esperientzia sinplifikatu egiten da erabiltzaileentzat, plataformak malgutasuna eta erresilientzia eskaintzen dituelako kaxatik kanpo eta abisuetarako erabil daitezkeen hainbat neurri zehatz biltzen dituelako.
Produkzioaren erabilera
Delta-k urtebete baino gehiago darama produkzioan eta funtsezko papera betetzen du Netflix Studio aplikazio askotan. Taldeei laguntza kasuak inplementatzen lagundu zien, hala nola bilaketa-indexatzea, datuak biltegiratzea eta gertaeretan oinarritutako lan-fluxuak. Jarraian, Delta plataformaren goi-mailako arkitekturaren ikuspegi orokorra dago.
5. Irudia. Deltaren goi-mailako arkitektura.
Eskerrak
Netflixen Deltaren sorreran eta garapenean parte hartu zuten pertsona hauei eskerrak eman nahi dizkiegu: 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 eta Zhenzhong Xu.
iturri
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Lineako gertaeren prozesatzea. Komunik. ACM 62 (5): 43β49 (2019). DOI:
: "Amazon Redshift biltegirako datuak sortzeko tresna".
Iturria: www.habr.com