Në pritje të nisjes së një fluksi të ri në normë Ne kemi përgatitur një përkthim të materialit interesant.
Rishikimi
Ne do të flasim për një model mjaft të njohur me të cilin aplikacionet përdorin shumë dyqane të dhënash, ku çdo dyqan përdoret për qëllimet e veta, për shembull, për të ruajtur formën kanonike të të dhënave (MySQL, etj.), për të ofruar aftësi të avancuara kërkimi (ElasticSearch, etj.) .), caching (Memcached, etj.) dhe të tjera. Në mënyrë tipike, kur përdorni shumë dyqane të dhënash, njëra prej tyre vepron si ruajtja kryesore dhe të tjerët si depo derivatesh. Problemi i vetëm është se si të sinkronizohen këto depo të të dhënave.
Ne shikuam një sërë modelesh të ndryshme që u përpoqën të zgjidhnin problemin e sinkronizimit të dyqaneve të shumta, të tilla si shkrime të dyfishta, transaksione të shpërndara, etj. Megjithatë, këto qasje kanë kufizime të rëndësishme për sa i përket përdorimit në jetën reale, besueshmërisë dhe mirëmbajtjes. Përveç sinkronizimit të të dhënave, disa aplikacione gjithashtu duhet të pasurojnë të dhënat duke thirrur shërbime të jashtme.
Delta u zhvillua për të zgjidhur këto probleme. Delta në fund të fundit ofron një platformë të qëndrueshme, të drejtuar nga ngjarjet për sinkronizimin dhe pasurimin e të dhënave.
Zgjidhjet ekzistuese
Hyrja e dyfishtë
Për të mbajtur dy depo të dhënash të sinkronizuara, mund të përdorni shkrimin e dyfishtë, i cili shkruan në një dyqan dhe më pas shkruan në tjetrin menjëherë më pas. Regjistrimi i parë mund të riprovohet dhe i dyti mund të ndërpritet nëse i pari dështon pasi të jetë shteruar numri i përpjekjeve. Megjithatë, të dy dyqanet e të dhënave mund të bëhen jashtë sinkronizimit nëse shkrimi në dyqanin e dytë dështon. Ky problem zakonisht zgjidhet duke krijuar një procedurë rikuperimi që mund të ritransferojë periodikisht të dhënat nga ruajtja e parë në të dytin, ose ta bëjë këtë vetëm nëse zbulohen dallime në të dhëna.
Problemet:
Kryerja e një procedure rikuperimi është një punë specifike që nuk mund të ripërdoret. Përveç kësaj, të dhënat ndërmjet vendndodhjeve të ruajtjes mbeten jashtë sinkronizimit derisa të kryhet procedura e rivendosjes. Zgjidhja bëhet më komplekse nëse përdoren më shumë se dy depo të dhënash. Më në fund, procedura e rivendosjes mund të shtojë ngarkesë në burimin origjinal të të dhënave.
Ndrysho tabelën e regjistrave
Kur ndodhin ndryshime në një grup tabelash (të tilla si futja, përditësimi dhe fshirja e një regjistrimi), të dhënat e ndryshimit shtohen në tabelën e regjistrit si pjesë e të njëjtit transaksion. Një fill ose proces tjetër kërkon vazhdimisht ngjarje nga tabela e regjistrave dhe i shkruan ato në një ose më shumë depo të dhënash, nëse është e nevojshme, duke hequr ngjarjet nga tabela e regjistrave pasi regjistrimi të konfirmohet nga të gjitha dyqanet.
Problemet:
Ky model duhet të zbatohet si një bibliotekë, dhe në mënyrë ideale pa ndryshuar kodin e aplikacionit që e përdor atë. Në një mjedis poliglot, një zbatim i një biblioteke të tillë duhet të ekzistojë në çdo gjuhë të nevojshme, por sigurimi i qëndrueshmërisë së funksionalitetit dhe sjelljes në të gjitha gjuhët është shumë i vështirë.
Një problem tjetër qëndron në marrjen e ndryshimeve të skemës në sisteme që nuk mbështesin ndryshimet e skemës transaksionale [1][2], të tilla si MySQL. Prandaj, modeli i bërjes së një ndryshimi (për shembull, ndryshimi i skemës) dhe regjistrimi i tij në mënyrë transaksionale në tabelën e regjistrit të ndryshimeve nuk do të funksionojë gjithmonë.
Transaksionet e Shpërndara
Transaksionet e shpërndara mund të përdoren për të ndarë një transaksion në dyqane të shumta heterogjene të të dhënave, në mënyrë që operacioni të jetë i angazhuar për të gjitha dyqanet e të dhënave të përdorura, ose nuk angazhohet për asnjë prej tyre.
Problemet:
Transaksionet e shpërndara janë një problem shumë i madh për dyqanet heterogjene të të dhënave. Nga natyra e tyre, ato mund të mbështeten vetëm në emëruesin më të ulët të përbashkët të sistemeve të përfshira. Për shembull, transaksionet XA bllokojnë ekzekutimin nëse procesi i aplikimit dështon gjatë fazës së përgatitjes. Për më tepër, XA nuk ofron zbulimin e bllokimit ose nuk mbështet skemat optimiste të kontrollit të konkurencës. Për më tepër, disa sisteme si ElasticSearch nuk mbështesin XA ose ndonjë model tjetër heterogjen transaksioni. Kështu, sigurimi i atomicitetit të shkrimit në teknologji të ndryshme të ruajtjes së të dhënave mbetet një detyrë shumë sfiduese për aplikacionet [3].
deltë
Delta u krijua për të adresuar kufizimet e zgjidhjeve ekzistuese të sinkronizimit të të dhënave dhe gjithashtu mundëson pasurimin e të dhënave në fluturim. Qëllimi ynë ishte të abstragojmë gjithë këtë kompleksitet larg zhvilluesve të aplikacioneve, në mënyrë që ata të mund të fokusohen plotësisht në zbatimin e funksionalitetit të biznesit. Më pas do të përshkruajmë "Kërkimi i Filmit", rasti aktual i përdorimit për Delta të Netflix.
Netflix përdor gjerësisht një arkitekturë mikroservice, dhe çdo mikroshërbim zakonisht shërben një lloj të dhënash. Informacioni bazë për filmin gjendet në një mikroshërbim të quajtur Shërbimi i Filmit, dhe të dhënat përkatëse, si p.sh. informacionet për prodhuesit, aktorët, shitësit, etj., menaxhohen nga disa mikroshërbime të tjera (domethënë Deal Service, Talent Service dhe Vendor Service).
Përdoruesit e biznesit në Netflix Studios shpesh duhet të kërkojnë sipas kritereve të ndryshme të filmit, prandaj është shumë e rëndësishme që ata të jenë në gjendje të kërkojnë në të gjitha të dhënat e lidhura me filmin.
Përpara Delta-s, ekipi i kërkimit të filmit duhej të tërhiqte të dhëna nga shumë mikroshërbime përpara se të indeksonte të dhënat e filmit. Përveç kësaj, ekipi duhej të zhvillonte një sistem që do të përditësonte periodikisht indeksin e kërkimit duke kërkuar ndryshime nga mikroshërbime të tjera, edhe nëse nuk do të kishte fare ndryshime. Ky sistem shpejt u bë kompleks dhe i vështirë për t'u mirëmbajtur.
Figura 1. Sistemi i votimit në Delta
Pas përdorimit të Delta, sistemi u thjeshtua në një sistem të drejtuar nga ngjarjet siç tregohet në figurën e mëposhtme. Ngjarjet CDC (Change-Data-Capture) dërgohen në temat Keystone Kafka duke përdorur Delta-Connector. Një aplikacion Delta i ndërtuar duke përdorur Kornizën e Përpunimit të Rrjedhës Delta (bazuar në Flink) merr ngjarje të CDC nga një temë, i pasuron ato duke thirrur mikroshërbime të tjera dhe në fund i kalon të dhënat e pasuruara në një indeks kërkimi në Elasticsearch. I gjithë procesi zhvillohet pothuajse në kohë reale, domethënë, sapo të bëhen ndryshime në depon e të dhënave, indekset e kërkimit përditësohen.
Figura 2. Tubacioni i të dhënave duke përdorur Delta
Në seksionet e mëposhtme, ne do të përshkruajmë funksionimin e Delta-Connector, i cili lidhet me hapësirën ruajtëse dhe publikon ngjarjet e CDC-së në shtresën e transportit, e cila është një infrastrukturë e transmetimit të të dhënave në kohë reale që drejton ngjarjet e CDC-së në temat e Kafkës. Dhe në fund, do të flasim për kornizën e përpunimit të rrjedhës Delta, të cilën zhvilluesit e aplikacioneve mund ta përdorin për përpunimin e të dhënave dhe logjikën e pasurimit.
CDC (Change-Data-Capture)
Ne kemi zhvilluar një shërbim CDC të quajtur Delta-Connector, i cili mund të kapë ndryshimet e kryera nga ruajtja e të dhënave në kohë reale dhe t'i shkruajë ato në një transmetim. Ndryshimet në kohë reale merren nga regjistri i transaksioneve dhe deponitë e ruajtjes. Deponitë përdoren sepse regjistrat e transaksioneve zakonisht nuk e ruajnë të gjithë historinë e ndryshimeve. Ndryshimet zakonisht serializohen si ngjarje Delta, kështu që marrësi nuk duhet të shqetësohet se nga vjen ndryshimi.
Delta-Connector mbështet disa veçori shtesë si:
- Aftësia për të shkruar të dhëna dalëse të personalizuara pas Kafkës.
- Aftësia për të aktivizuar deponitë manuale në çdo kohë për të gjitha tabelat, një tabelë specifike ose për çelësa primar specifik.
- Deponitë mund të merren në copa, kështu që nuk ka nevojë të filloni nga e para në rast dështimi.
- Nuk ka nevojë të vendosni bravë në tavolina, gjë që është shumë e rëndësishme për të siguruar që trafiku i shkrimit të bazës së të dhënave të mos bllokohet kurrë nga shërbimi ynë.
- Disponueshmëri e lartë për shkak të rasteve të tepërta në Zonat e Disponueshmërisë AWS.
Aktualisht ne mbështesim MySQL dhe Postgres, duke përfshirë vendosjet në AWS RDS dhe Aurora. Ne gjithashtu mbështesim Cassandra (multi-master). Mund të mësoni më shumë detaje rreth Delta-Connector këtu .
Kafka dhe shtresa e transportit
Shtresa e transportit të ngjarjeve të Delta-s është ndërtuar në shërbimin e mesazheve të platformës .
Historikisht, postimi në Netflix është optimizuar për aksesueshmëri dhe jo jetëgjatësi (shih më poshtë). ). Shkëmbimi ishte mospërputhje e mundshme e të dhënave të ndërmjetësit në skenarë të ndryshëm të avantazhit. Për shembull, zgjedhje të papastër lideri është përgjegjës që marrësi të ketë ngjarje të kopjuara ose të humbura.
Me Delta, ne donim garanci më të forta qëndrueshmërie për të siguruar shpërndarjen e ngjarjeve të CDC në dyqanet e derivuara. Për këtë qëllim, ne propozuam një grup Kafka të projektuar posaçërisht si një objekt të klasit të parë. Ju mund të shikoni disa cilësime ndërmjetësi në tabelën më poshtë:
Në grupimet Keystone Kafka, zgjedhje të papastër lideri zakonisht përfshihet për të siguruar aksesin e botuesit. Kjo mund të rezultojë në humbjen e mesazhit nëse një kopje e pasinkronizuar zgjidhet si drejtues. Për një grup të ri Kafka me disponueshmëri të lartë, opsioni zgjedhje të papastër lideri fikur për të parandaluar humbjen e mesazhit.
Ne gjithashtu u rritëm faktori i replikimit nga 2 në 3 dhe kopje minimale të insinkronizuara 1 deri në 2. Botuesit që shkruajnë në këtë grup kërkojnë pranime nga të gjithë të tjerët, duke siguruar që 2 nga 3 kopje të kenë mesazhet më aktuale të dërguara nga botuesi.
Kur një shembull ndërmjetësi përfundon, një shembull i ri zëvendëson atë të vjetër. Megjithatë, ndërmjetësi i ri do të duhet të arrijë me kopjet e pasinkronizuara, të cilat mund të zgjasin disa orë. Për të reduktuar kohën e rikuperimit për këtë skenar, ne filluam të përdorim ruajtjen e të dhënave në bllok (Amazon Elastic Block Store) në vend të disqeve lokale të ndërmjetësit. Kur një shembull i ri zëvendëson një shembull ndërmjetësi të përfunduar, ai bashkon vëllimin EBS që kishte shembulli i përfunduar dhe fillon të arrijë me mesazhe të reja. Ky proces redukton kohën e pastrimit të mbeturinave nga orë në minuta, sepse shembulli i ri nuk ka më nevojë të përsëritet nga një gjendje boshe. Në përgjithësi, magazinimi i veçantë dhe ciklet e jetës së ndërmjetësit reduktojnë ndjeshëm ndikimin e ndërrimit të ndërmjetësit.
Për të rritur më tej garancinë e shpërndarjes së të dhënave, ne përdorëm për të zbuluar çdo humbje të mesazhit në kushte ekstreme (për shembull, desinkronizimi i orës në liderin e ndarjes).
Korniza e përpunimit të rrjedhës
Shtresa e përpunimit e Delta është ndërtuar në krye të platformës Netflix SPaaS, e cila siguron integrimin e Apache Flink me ekosistemin Netflix. Platforma ofron një ndërfaqe përdoruesi që menaxhon vendosjen e punëve Flink dhe orkestrimin e grupimeve Flink në krye të platformës sonë të menaxhimit të kontejnerëve Titus. Ndërfaqja gjithashtu menaxhon konfigurimet e punëve dhe i lejon përdoruesit të bëjnë ndryshime konfigurimi në mënyrë dinamike pa pasur nevojë të ripërpilojnë punët e Flink.
Delta ofron një kornizë përpunimi të transmetimit bazuar në Flink dhe SPaaS që përdor bazuar në shënime DSL (Gjuha specifike e domenit) për detaje teknike abstrakte. Për shembull, për të përcaktuar hapin në të cilin ngjarjet do të pasurohen duke thirrur shërbime të jashtme, përdoruesit duhet të shkruajnë DSL-në e mëposhtme dhe korniza do të krijojë një model të bazuar në të, i cili do të ekzekutohet nga Flink.
Figura 3. Shembull i pasurimit në DSL në Delta
Korniza e përpunimit jo vetëm që zvogëlon kurbën e të mësuarit, por gjithashtu ofron veçori të zakonshme të përpunimit të rrjedhës, si deduplikimi, skematizimi dhe fleksibiliteti dhe elasticiteti për të zgjidhur problemet e zakonshme operacionale.
Korniza e Përpunimit të Delta Stream përbëhet nga dy module kryesore, moduli DSL & API dhe moduli Runtime. Moduli DSL & API ofron API DSL dhe UDF (User-Defined-Function) në mënyrë që përdoruesit të mund të shkruajnë logjikën e tyre të përpunimit (si filtrimi ose transformimet). Moduli Runtime ofron një implementim të një analizuesi DSL që ndërton një paraqitje të brendshme të hapave të përpunimit në modelet DAG. Komponenti Ekzekutimi interpreton modelet DAG për të inicializuar deklaratat aktuale të Flink dhe në fund të ekzekutojë aplikacionin Flink. Arkitektura e kornizës është ilustruar në figurën e mëposhtme.
Figura 4. Arkitektura e Kornizës së Përpunimit të Rrjedhës Delta
Kjo qasje ka disa përparësi:
- Përdoruesit mund të fokusohen në logjikën e tyre të biznesit pa pasur nevojë të thellohen në specifikat e Flink ose strukturës SPaaS.
- Optimizimi mund të bëhet në një mënyrë transparente për përdoruesit dhe gabimet mund të rregullohen pa kërkuar ndonjë ndryshim në kodin e përdoruesit (UDF).
- Përvoja e aplikacionit Delta është thjeshtuar për përdoruesit sepse platforma ofron fleksibilitet dhe elasticitet jashtë kutisë dhe mbledh një sërë metrikash të detajuara që mund të përdoren për sinjalizime.
PĂ«rdorimi i prodhimit
Delta ka qenë në prodhim për më shumë se një vit dhe luan një rol kyç në shumë aplikacione të Netflix Studio. Ajo ndihmoi ekipet të zbatonin raste të përdorimit të tillë si indeksimi i kërkimit, ruajtja e të dhënave dhe flukset e punës të drejtuara nga ngjarjet. Më poshtë është një pasqyrë e arkitekturës së nivelit të lartë të platformës Delta.
Figura 5. Arkitektura e nivelit të lartë të Delta.
Mirënjohje
Ne dëshirojmë të falënderojmë njerëzit e mëposhtëm që u përfshinë në krijimin dhe zhvillimin e Delta në 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 dhe Zhenzhong Xu.
burime
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: PĂ«rpunimi i ngjarjeve nĂ« internet. Komuna. ACM 62(5): 43â49 (2019). DOI:
: "Mjeti i krijimit të të dhënave për ruajtjen e Amazon Redshift."
Burimi: www.habr.com
