Í aðdraganda nýs flæðis á genginu Við höfum útbúið þýðingu á áhugaverðu efni.
Skoða
Við munum tala um nokkuð vinsælt mynstur þar sem forrit nota margar gagnageymslur, þar sem hver verslun er notuð í eigin tilgangi, til dæmis til að geyma kanónískt form gagna (MySQL, osfrv.), veita háþróaða leitargetu (ElasticSearch, o.fl.) .), skyndiminni (Memcached, osfrv.) og aðrir. Venjulega, þegar margar gagnageymslur eru notaðar, virkar ein þeirra sem aðalgeymsla og hin sem afleidd geymsla. Eina vandamálið er hvernig á að samstilla þessar gagnageymslur.
Við skoðuðum fjölda mismunandi mynstur sem reyndu að leysa vandamálið við að samstilla margar verslanir, svo sem tvöföld skrif, dreifð viðskipti o.s.frv. Hins vegar hafa þessar aðferðir verulegar takmarkanir hvað varðar raunverulega notkun, áreiðanleika og viðhald. Auk gagnasamstillingar þurfa sum forrit einnig að auðga gögn með því að hringja í utanaðkomandi þjónustu.
Delta var þróað til að leysa þessi vandamál. Delta veitir að lokum samræmdan, atburðadrifinn vettvang fyrir samstillingu og auðgun gagna.
Núverandi lausnir
Tvöfaldur inngangur
Til að halda tveimur gagnageymslum samstilltum geturðu notað tvöfalt skrif, sem skrifar í eina geymslu og skrifar síðan í hina strax á eftir. Fyrstu upptökuna er hægt að reyna aftur og stöðva þá seinni ef sú fyrri mistekst eftir að fjöldi tilrauna hefur verið búinn. Hins vegar gætu gagnageymslurnar tvær orðið úr samstillingu ef ekki tekst að skrifa í aðra geymsluna. Þetta vandamál er venjulega leyst með því að búa til endurheimtarferli sem getur reglulega flutt gögn frá fyrstu geymslu yfir í þá seinni, eða gert það aðeins ef munur er greindur í gögnunum.
Vandamál:
Að framkvæma endurheimt er ákveðið starf sem ekki er hægt að endurnýta. Að auki eru gögn á milli geymslustaða ósamstillt þar til endurheimtarferlið fer fram. Lausnin verður flóknari ef notaðar eru fleiri en tvær gagnageymslur. Að lokum getur endurheimtaraðferðin bætt álagi við upprunalega gagnagjafann.
Breyta log töflu
Þegar breytingar verða á setti af töflum (svo sem að setja inn, uppfæra og eyða færslu), er breytingaskránum bætt við annálatöfluna sem hluti af sömu færslu. Annar þráður eða ferli biður stöðugt um atburði úr skráningartöflunni og skrifar þá í eina eða fleiri gagnageymslur, ef nauðsyn krefur, fjarlægir atburði úr skráningartöflunni eftir að skráningin hefur verið staðfest af öllum verslunum.
Vandamál:
Þetta mynstur ætti að vera útfært sem bókasafn og helst án þess að breyta kóða forritsins sem notar það. Í marglita umhverfi ætti útfærsla slíks bókasafns að vera til á hvaða tungumáli sem er, en það er mjög erfitt að tryggja samræmi í virkni og hegðun á milli tungumála.
Annað vandamál liggur í því að fá skemabreytingar í kerfum sem styðja ekki viðskiptaskemubreytingar [1][2], eins og MySQL. Þess vegna mun mynstur þess að gera breytingu (til dæmis skemabreytingu) og skrá hana í viðskiptaskrá ekki alltaf virka.
Dreifð viðskipti
Dreifðar færslur geta verið notaðar til að skipta færslu yfir margar ólíkar gagnageymslur þannig að aðgerðin er annaðhvort skuldbundin til allra gagnageymslna sem notuð eru eða ekki skuldbundin til neinnar þeirra.
Vandamál:
Dreifð viðskipti eru mjög stórt vandamál fyrir ólíkar gagnageymslur. Eðli málsins samkvæmt geta þeir aðeins treyst á lægsta samnefnara þeirra kerfa sem í hlut eiga. Til dæmis, XA viðskipti loka fyrir framkvæmd ef umsóknarferlið mistekst á undirbúningsstigi. Að auki veitir XA ekki uppgötvun á stöðvun eða styður ekki bjartsýnt samhliðaeftirlitskerfi. Að auki styðja sum kerfi eins og ElasticSearch ekki XA eða önnur ólík viðskiptalíkan. Það er því mjög krefjandi verkefni fyrir forrit að tryggja að ritstýring í ýmsum gagnageymslutækni sé mjög krefjandi [3].
delta
Delta var hannað til að taka á takmörkunum núverandi gagnasamstillingarlausna og gerir einnig kleift að auðga gögn á flugi. Markmið okkar var að fjarlægja alla þessa margbreytileika frá forriturum svo þeir gætu einbeitt sér að fullu að innleiðingu viðskiptavirkni. Næst munum við lýsa „kvikmyndaleit“, raunverulegu notkunartilviki Netflix's Delta.
Netflix notar víða örþjónustuarkitektúr og hver örþjónusta þjónar venjulega eina tegund gagna. Grunnupplýsingar um kvikmynd eru í örþjónustu sem kallast Movie Service og tengdum gögnum, svo sem upplýsingum um framleiðendur, leikara, söluaðila og svo framvegis, er stjórnað af nokkrum öðrum örþjónustum (þ.e. Deal Service, Talent Service og Vendor Service).
Viðskiptanotendur hjá Netflix Studios þurfa oft að leita í ýmsum kvikmyndaviðmiðum og þess vegna er mjög mikilvægt fyrir þá að geta leitað í öllum kvikmyndatengdum gögnum.
Fyrir Delta þurfti kvikmyndaleitarteymið að draga gögn frá mörgum örþjónustum áður en kvikmyndagögnin voru skráð. Að auki þurfti teymið að þróa kerfi sem myndi uppfæra leitarvísitöluna reglulega með því að biðja um breytingar frá öðrum örþjónustum, jafnvel þótt engar breytingar yrðu. Þetta kerfi varð fljótt flókið og erfitt í viðhaldi.
Mynd 1. Könnunarkerfi til Delta
Eftir að Delta var notað var kerfið einfaldað í atburðadrifið kerfi eins og sýnt er á eftirfarandi mynd. CDC (Change-Data-Capture) viðburðir eru sendir til Keystone Kafka efnis með því að nota Delta-Connector. Delta forrit sem byggt er með Delta Stream Processing Framework (byggt á Flink) tekur á móti CDC atburðum frá efni, auðgar þá með því að hringja í aðrar örþjónustur og sendir að lokum auðguðu gögnin til leitarvísitölu í Elasticsearch. Allt ferlið fer fram nánast í rauntíma, það er að segja um leið og breytingar eru gerðar á gagnageymslunni eru leitarvísitölur uppfærðar.
Mynd 2. Gagnaleiðsla með Delta
Í eftirfarandi köflum munum við lýsa virkni Delta-tengisins, sem tengist geymslunni og birtir CDC atburði í flutningslagið, sem er rauntíma gagnaflutningsinnviði sem beinir CDC atburðum til Kafka efnisþátta. Og alveg í lokin munum við tala um Delta straumvinnsluramma, sem forritarar geta notað fyrir gagnavinnslu og auðgunarrökfræði.
CDC (Change-Data-Capture)
Við höfum þróað CDC þjónustu sem kallast Delta-Connector, sem getur fanga framlagðar breytingar úr gagnageymslunni í rauntíma og skrifað þær í straum. Rauntímabreytingar eru teknar úr viðskiptaskránni og geymslumunum. Notuð eru sorp vegna þess að viðskiptaskrár geyma venjulega ekki alla breytingasöguna. Breytingar eru venjulega settar í röð sem Delta-viðburðir, þannig að viðtakandinn þarf ekki að hafa áhyggjur af því hvaðan breytingin kemur.
Delta-tengi styður nokkra viðbótareiginleika eins og:
- Geta til að skrifa sérsniðin úttaksgögn með Kafka.
- Geta til að virkja handvirkt dump hvenær sem er fyrir allar töflur, tiltekna töflu eða fyrir tiltekna aðallykla.
- Hægt er að taka haugana í bitum, svo það er engin þörf á að byrja upp á nýtt ef bilun kemur upp.
- Það er engin þörf á að setja læsingar á töflur, sem er mjög mikilvægt til að tryggja að skrifumferð gagnagrunns sé aldrei læst af þjónustu okkar.
- Mikið framboð vegna óþarfa tilvika í AWS Availability Zones.
Við styðjum nú MySQL og Postgres, þar á meðal uppsetningar á AWS RDS og Aurora. Við styðjum líka Cassöndru (fjölmeistara). Þú getur fundið frekari upplýsingar um Delta-tengi hér .
Kafka og flutningalagið
Atburðaflutningalag Delta er byggt á skilaboðaþjónustu vettvangsins .
Sögulega hefur póstur á Netflix verið fínstilltur fyrir aðgengi frekar en langlífi (sjá hér að neðan). ). Viðskiptin voru hugsanleg ósamræmi í miðlaragögnum í ýmsum jaðartilvikum. Til dæmis, óhrein leiðtogakjör ber ábyrgð á því að viðtakandinn hafi hugsanlega afrit eða glatað atburði.
Með Delta vildum við sterkari endingartryggingar til að tryggja afhendingu CDC viðburða til afleiddra verslana. Í þessu skyni lögðum við til sérhannaðan Kafka-þyrping sem fyrsta flokks hlut. Þú getur skoðað nokkrar miðlarastillingar í töflunni hér að neðan:
Í Keystone Kafka klösum, óhrein leiðtogakjör venjulega innifalinn til að tryggja aðgengi útgefenda. Þetta getur leitt til glataðra skilaboða ef ósamstillt eftirmynd er kosin sem leiðtogi. Fyrir nýjan Kafka þyrping með mikilli framboði, kosturinn óhrein leiðtogakjör slökkt til að koma í veg fyrir að skeyti glatist.
Við fjölguðum líka afritunarstuðull frá 2 til 3 og lágmarks insync eftirlíkingar 1 til 2. Útgefendur sem skrifa í þennan klasa krefjast svars frá öllum öðrum til að tryggja að 2 af hverjum 3 eftirlíkingum séu með nýjustu skilaboðin sem útgefandinn sendir.
Þegar miðlaratilviki lýkur kemur nýtt tilvik í stað þess gamla. Hins vegar mun nýi miðlarinn þurfa að ná í ósamstilltu eftirmyndirnar, sem getur tekið nokkrar klukkustundir. Til að draga úr endurheimtartíma fyrir þessa atburðarás byrjuðum við að nota blokkgagnageymslu (Amazon Elastic Block Store) í stað staðbundinna miðlaradiska. Þegar nýtt tilvik kemur í stað hætt miðlaratilviks, festir það EBS bindi sem sagt var upp á og byrjar að ná nýjum skilaboðum. Þetta ferli dregur úr tíma til að útrýma eftirstöðvum úr klukkustundum í mínútur vegna þess að nýja tilvikið þarf ekki lengur að endurtaka sig úr tómu ástandi. Almennt séð draga aðskilin geymslu- og líftíma miðlara verulega úr áhrifum þess að skipta um miðlara.
Til að auka enn frekar gagnaafhendingarábyrgð notuðum við til að greina hvers kyns skilaboðatap við erfiðar aðstæður (til dæmis, klukkuafsamstillingu í skiptingarleiðara).
Stream Processing Framework
Vinnslulag Delta er byggt ofan á Netflix SPaaS pallinum, sem veitir Apache Flink samþættingu við Netflix vistkerfið. Vettvangurinn býður upp á notendaviðmót sem stjórnar uppsetningu Flink starfa og skipulagningu Flink þyrpinga ofan á Titus gámastjórnunarvettvang okkar. Viðmótið heldur einnig utan um vinnustillingar og gerir notendum kleift að gera stillingarbreytingar á kraftmikinn hátt án þess að þurfa að endursafna Flink verkum.
Delta býður upp á straumvinnsluramma byggt á Flink og SPaaS sem notar byggt á athugasemdum DSL (Domain Specific Language) til að draga saman tæknilegar upplýsingar. Til dæmis, til að skilgreina skrefið þar sem atburðir verða auðgaðir með því að hringja í utanaðkomandi þjónustu, þurfa notendur að skrifa eftirfarandi DSL, og ramminn mun búa til líkan byggt á því, sem verður framkvæmt af Flink.
Mynd 3. Dæmi um auðgun á DSL í Delta
Vinnsluramminn minnkar ekki aðeins námsferilinn heldur býður einnig upp á algenga straumvinnslueiginleika eins og aftvíföldun, skematingu og sveigjanleika og seiglu til að leysa algeng rekstrarvandamál.
Delta Stream Processing Framework samanstendur af tveimur lykileiningum, DSL & API einingunni og Runtime einingunni. DSL & API einingin veitir DSL og UDF (User-Defined-Function) API svo að notendur geti skrifað sína eigin vinnslurökfræði (svo sem síun eða umbreytingar). Runtime einingin býður upp á útfærslu á DSL-flokki sem byggir innri framsetningu vinnsluþrepa í DAG módelum. Framkvæmdarhlutinn túlkar DAG líkön til að frumstilla raunverulegar Flink staðhæfingar og keyra að lokum Flink forritið. Arkitektúr rammans er sýnd á eftirfarandi mynd.
Mynd 4. Arkitektúr Delta Stream Processing Framework
Þessi aðferð hefur nokkra kosti:
- Notendur geta einbeitt sér að viðskiptarökfræði sinni án þess að þurfa að kafa ofan í sérstöðu Flink eða SPaaS uppbyggingu.
- Hagræðingu er hægt að gera á þann hátt sem er gagnsæ fyrir notendur og villur er hægt að laga án þess að þurfa að breyta notendakóðanum (UDF).
- Upplifun Delta forritsins er einfölduð fyrir notendur vegna þess að vettvangurinn veitir sveigjanleika og seiglu út úr kassanum og safnar ýmsum ítarlegum mælingum sem hægt er að nota fyrir viðvaranir.
Framleiðslunotkun
Delta hefur verið í framleiðslu í meira en ár og gegnir lykilhlutverki í mörgum Netflix Studio forritum. Hún hjálpaði teymum að innleiða notkunartilvik eins og leitarflokkun, gagnageymslu og atburðadrifið verkflæði. Hér að neðan er yfirlit yfir háþróaða arkitektúr Delta pallsins.
Mynd 5. Háttsettur arkitektúr Delta.
Viðurkenningar
Við viljum þakka eftirfarandi aðilum sem tóku þátt í stofnun og þróun Delta hjá 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 og Zhenzhong Xu.
Heimildir
- Martin Kleppmann, Alastair R. Beresford, Boorge Svingen: Atburðavinnsla á netinu. Samfélag. ACM 62(5): 43–49 (2019). DOI:
: „Gagnasmíðatól fyrir Amazon Redshift geymslu.“
Heimild: www.habr.com