Gaidot jaunas plūsmas uzsākšanu ar ātrumu Esam sagatavojuši interesanta materiāla tulkojumu.
Pārskatiet
Mēs runāsim par diezgan populāru modeli, kurā lietojumprogrammas izmanto vairākus datu krātuves, kur katrs veikals tiek izmantots saviem mērķiem, piemēram, lai saglabātu datu kanonisko formu (MySQL utt.), nodrošinātu uzlabotas meklēšanas iespējas (ElasticSearch, utt.) .), kešatmiņa (Memcached utt.) un citi. Parasti, izmantojot vairākus datu krātuves, viens no tiem darbojas kā primārais, bet citi kā atvasinātie krātuvi. Vienīgā problēma ir šo datu krātuves sinhronizēšana.
Mēs apskatījām vairākus dažādus modeļus, kas mēģināja atrisināt vairāku veikalu sinhronizācijas problēmu, piemēram, dubultā rakstīšana, izplatīti darījumi utt. Tomēr šīm pieejām ir būtiski ierobežojumi attiecībā uz lietošanu reālajā dzīvē, uzticamību un apkopi. Papildus datu sinhronizācijai dažām lietojumprogrammām ir nepieciešams arī bagātināt datus, izsaucot ārējos pakalpojumus.
Delta tika izstrādāta, lai atrisinātu šīs problēmas. Galu galā Delta nodrošina konsekventu, uz notikumiem balstītu platformu datu sinhronizēšanai un bagātināšanai.
Esošie risinājumi
Dubultā ieeja
Lai sinhronizētu divus datu veikalus, varat izmantot duālo rakstīšanu, kas raksta vienā krātuvē un tūlīt pēc tam raksta otrā. Pirmo ierakstu var mēģināt atkārtoti un otro var pārtraukt, ja pirmais neizdodas pēc tam, kad ir izsmelts mēģinājumu skaits. Tomēr, ja neizdodas rakstīt uz otro krātuvi, abi datu krātuves var tikt nesinhronizētas. Šo problēmu parasti atrisina, izveidojot atkopšanas procedūru, kas var periodiski atkārtoti pārsūtīt datus no pirmās krātuves uz otro vai darīt to tikai tad, ja datos tiek konstatētas atšķirības.
Problēmas:
Atkopšanas procedūras veikšana ir īpašs darbs, ko nevar izmantot atkārtoti. Turklāt dati starp krātuves vietām netiek sinhronizēti, līdz tiek veikta atjaunošanas procedūra. Risinājums kļūst sarežģītāks, ja tiek izmantoti vairāk nekā divi datu krātuves. Visbeidzot, atjaunošanas procedūra var palielināt sākotnējo datu avota slodzi.
Mainīt žurnāla tabulu
Ja tiek veiktas izmaiņas tabulu kopā (piemēram, ieraksta ievietošana, atjaunināšana un dzēšana), izmaiņu ieraksti tiek pievienoti žurnāla tabulai kā daļa no tās pašas transakcijas. Cits pavediens vai process pastāvīgi pieprasa notikumus no žurnāla tabulas un ieraksta tos vienā vai vairākos datu krātuvēs, ja nepieciešams, noņemot notikumus no žurnāla tabulas pēc tam, kad ieraksts ir apstiprināts visos veikalos.
Problēmas:
Šis modelis ir jāievieš kā bibliotēka un ideālā gadījumā nemainot lietojumprogrammas kodu, kas to izmanto. Poliglota vidē šādas bibliotēkas ieviešanai vajadzētu pastāvēt jebkurā nepieciešamajā valodā, taču ir ļoti grūti nodrošināt funkcionalitātes un uzvedības konsekvenci dažādās valodās.
Vēl viena problēma ir shēmu izmaiņu iegūšana sistēmās, kas neatbalsta transakciju shēmu izmaiņas [1][2], piemēram, MySQL. Tāpēc izmaiņu veikšanas (piemēram, shēmas maiņas) modelis un transakciju ierakstīšana izmaiņu žurnāla tabulā ne vienmēr darbosies.
Sadalītie darījumi
Izkliedētās transakcijas var izmantot, lai sadalītu darījumu vairākos neviendabīgos datu krātuvēs, lai operācija būtu saistīta ar visiem izmantotajiem datu krātuvēm vai netiktu saistīta nevienā no tiem.
Problēmas:
Izkliedētie darījumi ir ļoti liela problēma neviendabīgu datu krātuvēm. Pēc savas būtības tās var paļauties tikai uz iesaistīto sistēmu zemāko kopsaucēju. Piemēram, XA transakcijas bloķē izpildi, ja pieteikšanās process neizdodas sagatavošanas posmā. Turklāt XA nenodrošina strupceļa noteikšanu un neatbalsta optimistiskas vienlaicības kontroles shēmas. Turklāt dažas sistēmas, piemēram, ElasticSearch, neatbalsta XA vai jebkuru citu neviendabīgu darījumu modeli. Tādējādi rakstīšanas atomitātes nodrošināšana dažādās datu uzglabāšanas tehnoloģijās joprojām ir ļoti izaicinošs uzdevums lietojumprogrammām [3].
Delta
Delta tika izstrādāts, lai novērstu esošo datu sinhronizācijas risinājumu ierobežojumus, kā arī nodrošina datu bagātināšanu lidojumā. Mūsu mērķis bija visas šīs sarežģītības novērst no lietojumprogrammu izstrādātājiem, lai viņi varētu pilnībā koncentrēties uz biznesa funkcionalitātes ieviešanu. Tālāk mēs aprakstīsim "Filmu meklēšanu", kas ir faktiskais Netflix Delta lietošanas gadījums.
Netflix plaši izmanto mikropakalpojumu arhitektūru, un katrs mikropakalpojums parasti apkalpo viena veida datus. Pamatinformācija par filmu ir ietverta mikropakalpojumā Movie Service, un saistītos datus, piemēram, informāciju par producentiem, aktieriem, pārdevējiem un tā tālāk, pārvalda vairāki citi mikropakalpojumi (proti, Deal Service, Talent Service un Vendor Service).
Netflix Studios biznesa lietotājiem bieži ir jāmeklē pēc dažādiem filmu kritērijiem, tāpēc viņiem ir ļoti svarīgi, lai viņi varētu meklēt visos ar filmām saistītajos datos.
Pirms Delta filmu meklēšanas komandai pirms filmas datu indeksēšanas vajadzēja iegūt datus no vairākiem mikropakalpojumiem. Turklāt komandai bija jāizstrādā sistēma, kas periodiski atjauninātu meklēšanas indeksu, pieprasot izmaiņas no citiem mikropakalpojumiem, pat ja izmaiņu nav vispār. Šī sistēma ātri kļuva sarežģīta un grūti uzturējama.
1. attēls. Delta aptaujas sistēma
Pēc Delta izmantošanas sistēma tika vienkāršota līdz notikumiem balstītai sistēmai, kā parādīts nākamajā attēlā. CDC (Change-Data-Capture) notikumi tiek nosūtīti Keystone Kafka tēmām, izmantojot Delta-Connector. Delta lietojumprogramma, kas izveidota, izmantojot Delta Stream Processing Framework (pamatojoties uz Flink), saņem CDC notikumus no tēmas, bagātina tos, izsaucot citus mikropakalpojumus, un visbeidzot nodod bagātinātos datus Elasticsearch meklēšanas indeksam. Viss process notiek gandrīz reāllaikā, tas ir, tiklīdz datu noliktavā tiek veiktas izmaiņas, meklēšanas indeksi tiek atjaunināti.
2. attēls. Datu cauruļvads, izmantojot Delta
Nākamajās sadaļās mēs aprakstīsim Delta-Connector darbību, kas savienojas ar krātuvi un publicē CDC notikumus transporta slānim, kas ir reāllaika datu pārraides infrastruktūra, kas maršrutē CDC notikumus uz Kafka tēmām. Un pašās beigās parunāsim par Delta straumes apstrādes ietvaru, ko lietojumprogrammu izstrādātāji var izmantot datu apstrādei un bagātināšanas loģikai.
CDC (Change-Data-Capture)
Mēs esam izstrādājuši CDC pakalpojumu ar nosaukumu Delta-Connector, kas var reāllaikā uztvert veiktās izmaiņas no datu krātuves un ierakstīt tās straumē. Reāllaika izmaiņas tiek ņemtas no darījumu žurnāla un krātuves izgāztuvēm. Izgāztuves tiek izmantotas, jo darījumu žurnālos parasti netiek saglabāta visa izmaiņu vēsture. Izmaiņas parasti tiek serializētas kā Delta notikumi, tāpēc adresātam nav jāuztraucas par to, no kurienes nāk izmaiņas.
Delta-Connector atbalsta vairākas papildu funkcijas, piemēram:
- Iespēja rakstīt pielāgotus izvades datus, izmantojot Kafka.
- Iespēja jebkurā laikā aktivizēt manuālās izgāztuves visām tabulām, noteiktai tabulai vai konkrētām primārajām atslēgām.
- Izgāztuves var izgūt pa daļām, tāpēc neveiksmes gadījumā nav jāsāk no jauna.
- Nav nepieciešams izvietot slēdzenes uz tabulām, kas ir ļoti svarīgi, lai nodrošinātu, ka mūsu pakalpojums nekad nebloķē datubāzes rakstīšanas trafiku.
- Augsta pieejamība AWS pieejamības zonās esošo lieko gadījumu dēļ.
Pašlaik mēs atbalstām MySQL un Postgres, tostarp izvietošanu AWS RDS un Aurora. Mēs arī atbalstām Cassandra (multi-master). Šeit varat uzzināt vairāk par Delta-Connector .
Kafka un transporta slānis
Delta notikumu transporta slānis ir veidots uz platformas ziņojumapmaiņas pakalpojuma .
Vēsturiski publicēšana pakalpojumā Netflix ir optimizēta pieejamībai, nevis ilgmūžībai (skatiet tālāk). ). Kompromiss bija iespējama brokeru datu neatbilstība dažādos malu scenārijos. Piemēram, netīras līdera vēlēšanas ir atbildīgs par to, ka adresātam, iespējams, ir dublēti vai pazaudēti notikumi.
Ar Delta mēs vēlējāmies spēcīgākas izturības garantijas, lai nodrošinātu CDC notikumu piegādi atvasinātajiem veikaliem. Šim nolūkam mēs piedāvājām īpaši izstrādātu Kafkas klasteru kā pirmās klases objektu. Tālāk esošajā tabulā varat apskatīt dažus brokeru iestatījumus:
Keystone Kafka klasteros, netīras līdera vēlēšanas parasti tiek iekļauti, lai nodrošinātu izdevēja pieejamību. Tas var izraisīt ziņojuma zudumu, ja par vadītāju tiek izvēlēta nesinhronizēta kopija. Jaunam augstas pieejamības Kafka klasterim šī opcija netīras līdera vēlēšanas atspējota, lai novērstu ziņojumu zudumu.
Mēs arī palielinājām replikācijas faktors no 2 līdz 3 un minimālais insync replikas No 1 līdz 2. Izdevēji, kas raksta šajā klasterī, pieprasa apstiprinājumu no visiem pārējiem, nodrošinot, ka 2 no 3 replikām ir jaunākie izdevēja nosūtītie ziņojumi.
Kad starpnieka instances darbība tiek pārtraukta, veco aizstāj ar jaunu. Tomēr jaunajam brokerim būs jāpanāk nesinhronizētās kopijas, kas var ilgt vairākas stundas. Lai samazinātu šī scenārija atkopšanas laiku, lokālo brokeru disku vietā sākām izmantot bloku datu krātuvi (Amazon Elastic Block Store). Kad jauna instance aizstāj pārtraukto brokera instanci, tā pievieno EBS sējumu, kas bija pārtrauktajai instancei, un sāk saņemt jaunus ziņojumus. Šis process samazina neizpildīto uzkrājumu dzēšanas laiku no stundām līdz minūtēm, jo jaunajai instancei vairs nav jāreplicē no tukša stāvokļa. Kopumā atsevišķi uzglabāšanas un brokeru dzīves cikli ievērojami samazina starpnieka maiņas ietekmi.
Lai vēl vairāk palielinātu datu piegādes garantiju, mēs izmantojām lai atklātu ziņojumu zudumu ekstremālos apstākļos (piemēram, pulksteņa desinhronizācija nodalījuma līderā).
Straumes apstrādes ietvars
Delta apstrādes slānis ir veidots uz Netflix SPAaS platformas, kas nodrošina Apache Flink integrāciju ar Netflix ekosistēmu. Platforma nodrošina lietotāja saskarni, kas pārvalda Flink darbu izvietošanu un Flink klasteru orķestrēšanu mūsu Titus konteineru pārvaldības platformā. Interfeiss arī pārvalda darbu konfigurācijas un ļauj lietotājiem dinamiski veikt konfigurācijas izmaiņas, nepārkompilējot Flink darbus.
Delta nodrošina straumes apstrādes sistēmu, kuras pamatā ir Flink un SPAaS, ko izmanto balstās uz anotācijām DSL (Domain Specific Language), lai abstrakti tehniskas detaļas. Piemēram, lai definētu soli, kurā notikumi tiks bagātināti, izsaucot ārējos pakalpojumus, lietotājiem ir jāraksta sekojošais DSL, un ietvars uz tā bāzes izveidos modeli, kuru izpildīs Flink.
3. attēls. DSL bagātināšanas piemērs Deltā
Apstrādes sistēma ne tikai samazina mācīšanās līkni, bet arī nodrošina kopējas straumes apstrādes funkcijas, piemēram, dublēšanas atdalīšanu, shematizāciju, kā arī elastību un elastību, lai atrisinātu izplatītas darbības problēmas.
Delta Stream Processing Framework sastāv no diviem galvenajiem moduļiem — DSL un API moduļa un izpildlaika moduļa. DSL un API modulis nodrošina DSL un UDF (User-Defined-Function) API, lai lietotāji varētu rakstīt savu apstrādes loģiku (piemēram, filtrēšanu vai transformācijas). Runtime modulis nodrošina DSL parsētāja ieviešanu, kas veido DAG modeļu apstrādes darbību iekšējo attēlojumu. Izpildes komponents interpretē DAG modeļus, lai inicializētu faktiskos Flink paziņojumus un visbeidzot palaistu Flink lietojumprogrammu. Ietvara arhitektūra ir parādīta nākamajā attēlā.
4. attēls. Delta Stream Processing Framework arhitektūra
Šai pieejai ir vairākas priekšrocības:
- Lietotāji var koncentrēties uz savu biznesa loģiku, neiedziļinoties Flink vai SPAaS struktūras specifikā.
- Optimizāciju var veikt lietotājiem pārskatāmā veidā, un kļūdas var novērst, neprasot nekādas izmaiņas lietotāja kodā (UDF).
- Lietojumprogrammas Delta pieredze lietotājiem ir vienkāršota, jo platforma nodrošina elastību un elastību jau no kastes un apkopo dažādus detalizētus rādītājus, ko var izmantot brīdinājumiem.
Ražošanas izmantošana
Delta ir ražota vairāk nekā gadu, un tai ir galvenā loma daudzās Netflix Studio lietojumprogrammās. Viņa palīdzēja komandām ieviest tādus lietošanas gadījumus kā meklēšanas indeksēšana, datu glabāšana un uz notikumiem balstītas darbplūsmas. Tālāk ir sniegts pārskats par Delta platformas augsta līmeņa arhitektūru.
5. attēls. Delta augsta līmeņa arhitektūra.
Pateicības
Mēs vēlamies pateikties šādiem cilvēkiem, kuri bija iesaistīti Delta izveidē un attīstībā Netflix: Alens Vangs, Čārlzs Džao, Džebins Jons, Džošs Snaiders, Kasturi Čaterdžī, Marks Čo, Olofs Johansons, Pijušs Gojs, Prašants Ramdass, Raghurams Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang un Zhenzhong Xu.
avoti
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Tiešsaistes notikumu apstrāde. Commun. ACM 62(5): 43–49 (2019). DOI:
: “Datu veidošanas rīks Amazon Redshift Storage”.
Avots: www.habr.com
