ProHoster > Blogs > Administrācija > Delta: datu sinhronizācijas un bagātināŔanas platforma

Delta: datu sinhronizācijas un bagātināŔanas platforma

Gaidot jaunas plūsmas uzsākŔanu ar ātrumu Datu inženieris Esam sagatavojuŔi interesanta materiāla tulkojumu.

Delta: datu sinhronizācijas un bagātināŔanas platforma

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.

Delta: datu sinhronizācijas un bagātināŔanas platforma
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.

Delta: datu sinhronizācijas un bagātināŔanas platforma
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 emuāra ziņa.

Kafka un transporta slānis

Delta notikumu transporta slānis ir veidots uz platformas ziņojumapmaiņas pakalpojuma Pamatprincips.

Vēsturiski publicÄ“Å”ana pakalpojumā Netflix ir optimizēta pieejamÄ«bai, nevis ilgmūžībai (skatiet tālāk). iepriekŔējais raksts). 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:

Delta: datu sinhronizācijas un bagātināŔanas platforma

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 ziņojumu izsekoÅ”anas sistēma 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.

Delta: datu sinhronizācijas un bagātināŔanas platforma
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ā.

Delta: datu sinhronizācijas un bagātināŔanas platforma
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.

Delta: datu sinhronizācijas un bagātināŔanas platforma
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

  1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
  2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
  3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: TieÅ”saistes notikumu apstrāde. Commun. ACM 62(5): 43ā€“49 (2019). DOI: doi.org/10.1145/3312527

ReÄ£istrējieties bezmaksas vebināram: ā€œDatu veidoÅ”anas rÄ«ks Amazon Redshift Storageā€.

Avots: www.habr.com

Pievieno komentāru