En antaŭĝojo de la lanĉo de nova fluo laŭ la rapideco Ni preparis tradukon de interesa materialo.
trarigardo
Ni parolos pri sufiĉe populara ŝablono per kiu aplikaĵoj uzas plurajn datumbutikojn, kie ĉiu vendejo estas uzata por siaj propraj celoj, ekzemple, por stoki la kanonan formon de datumoj (MySQL, ktp.), provizi altnivelajn serĉkapablojn (ElasticSearch, ktp.) .), kaŝmemoro (Memcached, ktp.) kaj aliaj. Tipe, kiam vi uzas plurajn datumbutikojn, unu el ili funkcias kiel la ĉefa vendejo kaj la aliaj kiel derivitaj vendejoj. La sola problemo estas kiel sinkronigi ĉi tiujn datumbutikojn.
Ni rigardis kelkajn malsamajn ŝablonojn, kiuj provis solvi la problemon de sinkronigado de multoblaj vendejoj, kiel duoblaj skribaĵoj, distribuitaj transakcioj ktp. Tamen, tiuj aliroj havas signifajn limigojn laŭ realviva uzo, fidindeco kaj prizorgado. Krom datumsinkronigado, iuj aplikaĵoj ankaŭ bezonas riĉigi datumojn per vokado de eksteraj servoj.
Delta estis evoluigita por solvi tiujn problemojn. Delta finfine disponigas konsekvencan, okazaĵ-movitan platformon por datumsinkronigado kaj riĉigo.
Ekzistantaj solvoj
Duobla eniro
Por konservi du datumbutikojn sinkronigitaj, vi povas uzi duoblan skribon, kiu skribas al unu vendejo kaj poste skribas al la alia tuj poste. La unua registrado povas esti reprovita kaj la dua povas esti ĉesigita se la unua malsukcesas post kiam la nombro da provoj estis elĉerpita. Tamen, la du datumbutikoj povas malsinkroniĝi se skribo al la dua vendejo malsukcesas. Ĉi tiu problemo estas kutime solvita per kreado de reakiro, kiu povas periode retransdoni datumojn de la unua stokado al la dua, aŭ fari tion nur se diferencoj estas detektitaj en la datumoj.
Problemoj:
Fari reakivan proceduron estas specifa laboro, kiu ne povas esti reuzita. Krome, datumoj inter stokaj lokoj restas nesinkronigitaj ĝis la restaŭra proceduro okazas. La solvo fariĝas pli kompleksa se pli ol du datumbutikoj estas uzataj. Fine, la restariga proceduro povas aldoni ŝarĝon al la originala datumfonto.
Ŝanĝi protokoltabelon
Kiam ŝanĝoj okazas al aro de tabeloj (kiel ekzemple enmetado, ĝisdatigo kaj forigo de rekordo), la ŝanĝregistroj estas aldonitaj al la protokolo-tabelo kiel parto de la sama transakcio. Alia fadeno aŭ procezo konstante petas eventojn de la protokolo-tabelo kaj skribas ilin al unu aŭ pluraj datumbutikoj, se necese, forigante eventojn de la protokolo-tabelo post kiam la registro estis konfirmita de ĉiuj butikoj.
Problemoj:
Ĉi tiu ŝablono devus esti efektivigita kiel biblioteko, kaj ideale sen ŝanĝi la kodon de la aplikaĵo kiu uzas ĝin. En poliglota medio, efektivigo de tia biblioteko devus ekzisti en iu ajn necesa lingvo, sed certigi konsistencon de funkcieco kaj konduto inter lingvoj estas tre malfacila.
Alia problemo kuŝas en akirado de skemŝanĝoj en sistemoj kiuj ne apogas transakciajn skemŝanĝojn [1][2], kiel ekzemple MySQL. Tial, la ŝablono fari ŝanĝon (ekzemple, skemoŝanĝo) kaj transakcie registri ĝin en la ŝanĝprotokolo-tabelo ne ĉiam funkcios.
Distribuitaj Transakcioj
Distribuitaj transakcioj povas esti uzataj por dividi transakcion tra multoblaj heterogenaj datumbutikoj tiel ke la operacio estas aŭ farita al ĉiuj datumbutikoj uzitaj, aŭ ne transigita al iu el ili.
Problemoj:
Distribuitaj transakcioj estas tre granda problemo por heterogenaj datumbutikoj. Laŭ sia naturo, ili povas nur fidi je la plej malsupra komuna denominatoro de la sistemoj engaĝitaj. Ekzemple, XA-transakcioj blokas ekzekuton se la aplika procezo malsukcesas dum la preparfazo. Plie, XA ne disponigas blokiĝon detekton aŭ subtenas optimismajn samtempajn kontrolkabalojn. Krome, iuj sistemoj kiel ElasticSearch ne subtenas XA aŭ ajnan alian heterogenan transakcian modelon. Tiel, certigi skriban atomecon en diversaj datumstokaj teknologioj restas tre malfacila tasko por aplikoj [3].
delta
Delta estis desegnita por trakti la limojn de ekzistantaj datumsinkronigaj solvoj kaj ankaŭ ebligas sur-la-muŝan datumriĉigon. Nia celo estis abstrakti ĉiujn ĉi tiujn kompleksaĵojn for de aplikaĵprogramistoj por ke ili povu plene koncentriĝi pri efektivigado de komerca funkcieco. Poste ni priskribos "Movie Search", la realan uzkazon por Delta de Netflix.
Netflix vaste uzas mikroservan arkitekturon, kaj ĉiu mikroservo kutime servas unu specon de datumoj. Bazaj informoj pri la filmo estas enhavitaj en mikroservo nomata Filmservo, kaj rilataj datumoj kiel informoj pri produktantoj, aktoroj, vendistoj, ktp estas administritaj de pluraj aliaj mikroservoj (nome Deal Service, Talent Service kaj Vendor Service).
Komercaj uzantoj ĉe Netflix Studios ofte bezonas serĉi laŭ diversaj filmkriterioj, tial estas tre grave por ili povi serĉi tra ĉiuj film-rilataj datumoj.
Antaŭ Delta, la filmserĉa teamo bezonis eltiri datumojn de pluraj mikroservoj antaŭ indeksi la filmajn datumojn. Krome, la teamo devis evoluigi sistemon, kiu periode ĝisdatigus la serĉindekson petante ŝanĝojn de aliaj mikroservoj, eĉ se tute ne estus ŝanĝoj. Ĉi tiu sistemo rapide iĝis kompleksa kaj malfacile konservebla.
Figuro 1. Voĉa sistemo al Delta
Post uzado de Delta, la sistemo estis simpligita al okazaĵa sistemo kiel montrite en la sekva figuro. CDC (Ŝanĝo-Datumo-Kapto) okazaĵoj estas senditaj al Keystone Kafka temoj uzante Delta-Konektilon. Delta aplikaĵo konstruita uzante la Delta Stream Processing Framework (bazita sur Flink) ricevas CDC-okazaĵojn de temo, riĉigas ilin vokante aliajn mikroservojn, kaj finfine pasas la riĉigitajn datumojn al serĉindekso en Elasticsearch. La tuta procezo okazas preskaŭ en reala tempo, tio estas, tuj kiam ŝanĝoj estas faritaj al la datumstokejo, serĉaj indeksoj estas ĝisdatigitaj.
Figuro 2. Datuma dukto uzante Delta
En la sekvaj sekcioj, ni priskribos la funkciadon de la Delta-Konektilo, kiu konektas al la stokado kaj publikigas CDC-okazaĵojn al la transporta tavolo, kiu estas realtempa transdona infrastrukturo, kiu direktas CDC-eventojn al Kafka-temoj. Kaj ĉe la fino, ni parolos pri la Delta-flua prilabora kadro, kiun aplikaĵprogramistoj povas uzi por datumtraktado kaj riĉiga logiko.
CDC (Ŝanĝo-Datumo-Kapto)
Ni evoluigis CDC-servon nomitan Delta-Connector, kiu povas kapti faritajn ŝanĝojn de la datumbutiko en reala tempo kaj skribi ilin al rivereto. Realtempaj ŝanĝoj estas prenitaj de la transakcia protokolo kaj stokado-ruboj. Rubejoj estas uzataj ĉar transakciaj protokoloj kutime ne konservas la tutan historion de ŝanĝoj. Ŝanĝoj estas kutime seriigitaj kiel Delta-okazaĵoj, do la ricevanto ne devas zorgi pri de kie venas la ŝanĝo.
Delta-Connector subtenas plurajn kromajn funkciojn kiel ekzemple:
- Kapablo skribi kutimajn eligajn datumojn preter Kafka.
- Kapablo aktivigi manajn rubejojn iam ajn por ĉiuj tabloj, specifa tablo aŭ por specifaj primaraj ŝlosiloj.
- Rubejoj povas esti prenitaj en pecoj, do ne necesas rekomenci en kazo de fiasko.
- Ne necesas meti serurojn sur tabloj, kio estas tre grava por certigi, ke datumbaza skribtrafiko neniam estas blokita de nia servo.
- Alta havebleco pro redundaj okazoj en AWS-Availability Zones.
Ni nuntempe subtenas MySQL kaj Postgres, inkluzive de deplojoj sur AWS RDS kaj Aurora. Ni ankaŭ subtenas Cassandra (multmajstro). Vi povas ekscii pliajn detalojn pri Delta-Connector ĉi tie .
Kafka kaj la transporta tavolo
La evento-transporta tavolo de Delta estas konstruita sur la mesaĝservo de la platformo .
Historie, afiŝado sur Netflix estis optimumigita por alirebleco prefere ol longviveco (vidu sube). ). La kompromiso estis ebla maklerista datuma nekonsekvenco en diversaj randscenaroj. Ekzemple, malpura gvidanto elekto respondecas pri la ricevanto eble havanta duplikatajn aŭ perditajn eventojn.
Kun Delta, ni volis pli fortajn fortikajn garantiojn por certigi liveron de CDC-eventoj al derivitaj vendejoj. Tiucele ni proponis speciale desegnitan Kafka-areton kiel unuaklasan objekton. Vi povas rigardi kelkajn makleristajn agordojn en la suba tabelo:
En Keystone Kafka aretoj, malpura gvidanto elekto kutime inkluzivita por certigi eldonan alireblecon. Tio povas rezultigi mesaĝperdon se nesinkronigita kopio estas elektita kiel la gvidanto. Por nova alta havebleco Kafka-grupo, la opcio malpura gvidanto elekto malŝaltita por malhelpi mesaĝperdon.
Ni ankaŭ pliiĝis replika faktoro de 2 ĝis 3 kaj minimumaj nesinkronigitaj kopioj 1 ĝis 2. Eldonistoj skribantaj al ĉi tiu aro postulas aktojn de ĉiuj aliaj, certigante ke 2 el 3 kopioj havas la plej aktualajn mesaĝojn senditajn de la eldonisto.
Kiam maklerista petskribo finiĝas, nova petskribo anstataŭas la malnovan. Tamen, la nova makleristo devos atingi la nesinkronigitajn kopiojn, kiuj povas daŭri plurajn horojn. Por redukti la reakivan tempon por ĉi tiu scenaro, ni komencis uzi blokan datuman stokadon (Amazon Elastic Block Store) anstataŭ lokaj makleristaj diskoj. Kiam nova petskribo anstataŭigas finitan makleristan petskribon, ĝi aliĝas al la EBS-volumo kiun la finita kazo havis kaj komencas atingi novajn mesaĝojn. Ĉi tiu procezo reduktas la restarpuran tempon de horoj al minutoj ĉar la nova kazo ne plu bezonas reprodukti de malplena stato. Ĝenerale, apartaj stokado kaj maklerista vivocikloj signife reduktas la efikon de makleristoŝanĝado.
Por plue pliigi la garantion de livero de datumoj, ni uzis por detekti ajnan mesaĝperdon sub ekstremaj kondiĉoj (ekzemple, horloĝmalsinkronigo en la subdiskogvidanto).
Flua Pretiga Kadro
La pretigtavolo de Delta estas konstruita sur la Netflix SPaaS-platformo, kiu provizas Apache Flink-integriĝon kun la Netflix-ekosistemo. La platformo disponigas uzantinterfacon, kiu administras la disfaldiĝon de Flink-laboroj kaj instrumentadon de Flink-aretoj aldone al nia Titus-ujo-administra platformo. La interfaco ankaŭ administras laborkonfiguraciojn kaj permesas al uzantoj fari agordajn ŝanĝojn dinamike sen devi rekompili Flink-laborojn.
Delta provizas fluon prilaboradan kadron bazitan sur Flink kaj SPaaS kiu uzas komentario-bazita DSL (Domain Specific Language) por abstrakti teknikajn detalojn. Ekzemple, por difini la paŝon, ĉe kiu eventoj riĉiĝos per vokado de eksteraj servoj, uzantoj devas skribi la sekvan DSL, kaj la kadro kreos modelon bazitan sur ĝi, kiu estos ekzekutita de Flink.
Figuro 3. Ekzemplo de riĉiĝo sur DSL en Delta
La pretigkadro ne nur reduktas la lernkurbon, sed ankaŭ disponigas komunajn fluajn pretigajn funkciojn kiel ekzemple deduplikado, skematigo kaj fleksebleco kaj rezisteco por solvi oftajn funkciajn problemojn.
Delta Stream Processing Framework konsistas el du ŝlosilaj moduloj, la DSL & API-modulo kaj la Runtime-modulo. La DSL & API-modulo disponigas DSL kaj UDF (User-Defined-Function) API-ojn por ke uzantoj povu skribi sian propran pretigan logikon (kiel ekzemple filtrado aŭ transformoj). La Runtime-modulo disponigas efektivigon de DSL-analizilo kiu konstruas internan reprezentadon de pretigaj paŝoj en DAG-modeloj. La Execution-komponento interpretas DAG-modelojn por pravalorigi la faktajn Flink-deklarojn kaj finfine ruli la Flink-aplikaĵon. La arkitekturo de la kadro estas ilustrita en la sekva figuro.
Figuro 4. Delta Stream Processing Framework-arkitekturo
Ĉi tiu aliro havas plurajn avantaĝojn:
- Uzantoj povas koncentriĝi pri sia komerca logiko sen devi enprofundiĝi en la specifaĵoj de Flink aŭ la SPaaS-strukturo.
- Optimumigo povas esti farita en maniero kiu estas travidebla al uzantoj, kaj eraroj povas esti fiksitaj sen postulado de ajnaj ŝanĝoj al la uzantkodo (UDF).
- La sperto de Delta-aplikaĵo estas simpligita por uzantoj ĉar la platformo provizas flekseblecon kaj fortikecon el la skatolo kaj kolektas diversajn detalajn metrikojn, kiuj povas esti uzataj por atentigoj.
Produktada uzo
Delta estas en produktado dum pli ol unu jaro kaj ludas ŝlosilan rolon en multaj Netflix Studio-aplikoj. Ŝi helpis teamojn efektivigi uzkazojn kiel serĉindeksadon, datumstokadon kaj okazaĵajn laborfluojn. Malsupre estas superrigardo de la altnivela arkitekturo de la Delta-platformo.
Figuro 5. La altnivela arkitekturo de Delta.
Dankoj
Ni ŝatus danki la jenajn homojn, kiuj partoprenis en la kreado kaj disvolviĝo de Delta ĉe 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 kaj Zhenzhong Xu.
Fontoj
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Reta eventa prilaborado. Commun. ACM 62 (5): 43–49 (2019). DOI:
: "Datuma Konstrua Ilo por Amazon Redshift Stokado."
fonto: www.habr.com
