Gan ragweld lansio llif newydd ar y gyfradd Rydym wedi paratoi cyfieithiad o ddeunydd diddorol.
Adolygu
Byddwn yn siarad am batrwm eithaf poblogaidd lle mae cymwysiadau'n defnyddio storfeydd data lluosog, lle mae pob storfa'n cael ei ddefnyddio at ei ddibenion ei hun, er enghraifft, i storio'r ffurf canonaidd o ddata (MySQL, ac ati), darparu galluoedd chwilio uwch (ElasticSearch, etc.), caching (Memcached, etc.) ac eraill. Yn nodweddiadol, wrth ddefnyddio storfeydd data lluosog, mae un ohonynt yn gweithredu fel y brif storfa a'r lleill fel storfeydd deilliadol. Yr unig broblem yw sut i gydamseru'r storfeydd data hyn.
Gwnaethom edrych ar nifer o wahanol batrymau a geisiodd ddatrys y broblem o gydamseru siopau lluosog, megis ysgrifennu dwbl, trafodion dosbarthedig, ac ati. Fodd bynnag, mae gan y dulliau hyn gyfyngiadau sylweddol o ran defnydd go iawn, dibynadwyedd a chynnal a chadw. Yn ogystal â chydamseru data, mae angen i rai cymwysiadau hefyd gyfoethogi data trwy ffonio gwasanaethau allanol.
Datblygwyd Delta i ddatrys y problemau hyn. Yn y pen draw, mae Delta yn darparu llwyfan cyson sy'n cael ei yrru gan ddigwyddiadau ar gyfer cydamseru a chyfoethogi data.
Atebion presennol
Mynediad dwbl
I gadw dwy storfa ddata mewn cydamseriad, gallwch ddefnyddio ysgrifennu deuol, sy'n ysgrifennu i un storfa ac yna'n ysgrifennu at y llall yn syth wedi hynny. Gellir adalw'r recordiad cyntaf a gall yr ail gael ei erthylu os bydd y cyntaf yn methu ar ôl i nifer yr ymgeisiau ddod i ben. Fodd bynnag, efallai na fydd y ddwy storfa ddata yn cydamseru os bydd ysgrifennu i'r ail siop yn methu. Mae'r broblem hon fel arfer yn cael ei datrys trwy greu gweithdrefn adfer a all o bryd i'w gilydd ail-drosglwyddo data o'r storfa gyntaf i'r ail, neu wneud hynny dim ond os canfyddir gwahaniaethau yn y data.
Problemau:
Mae cyflawni gweithdrefn adfer yn swydd benodol na ellir ei hailddefnyddio. Yn ogystal, mae data rhwng lleoliadau storio yn parhau i fod allan o gysoni nes bod y weithdrefn adfer yn digwydd. Daw'r ateb yn fwy cymhleth os defnyddir mwy na dwy storfa ddata. Yn olaf, gall y weithdrefn adfer ychwanegu llwyth at y ffynhonnell ddata wreiddiol.
Newid tabl log
Pan fydd newidiadau'n digwydd i set o dablau (fel mewnosod, diweddaru, a dileu cofnod), mae'r cofnodion newid yn cael eu hychwanegu at y tabl log fel rhan o'r un trafodiad. Mae edefyn neu broses arall yn gofyn am ddigwyddiadau o'r tabl log yn gyson ac yn eu hysgrifennu i un neu fwy o siopau data, os oes angen, gan ddileu digwyddiadau o'r tabl log ar ôl i'r cofnod gael ei gadarnhau gan bob siop.
Problemau:
Dylid gweithredu'r patrwm hwn fel llyfrgell, ac yn ddelfrydol heb newid cod y cymhwysiad sy'n ei ddefnyddio. Mewn amgylchedd amlieithog, dylai gweithrediad llyfrgell o'r fath fodoli mewn unrhyw iaith angenrheidiol, ond mae sicrhau cysondeb ymarferoldeb ac ymddygiad ar draws ieithoedd yn anodd iawn.
Problem arall yw cael newidiadau sgema mewn systemau nad ydynt yn cefnogi newidiadau sgema trafodaethol [1][2], megis MySQL. Felly, ni fydd y patrwm o wneud newid (er enghraifft, newid sgema) a'i gofnodi'n drafodol yn y tabl log newid bob amser yn gweithio.
Trafodion Dosbarthedig
Gellir defnyddio trafodion wedi'u dosbarthu i rannu trafodiad ar draws storfeydd data heterogenaidd lluosog fel bod y gweithrediad naill ai wedi'i ymrwymo i'r holl storfeydd data a ddefnyddir, neu heb fod wedi'i ymrwymo i unrhyw un ohonynt.
Problemau:
Mae trafodion dosranedig yn broblem fawr iawn i storfeydd data heterogenaidd. Yn ôl eu natur, dim ond ar enwadur cyffredin isaf y systemau dan sylw y gallant ddibynnu. Er enghraifft, mae trafodion XA yn rhwystro cyflawni os bydd y broses ymgeisio yn methu yn ystod y cyfnod paratoi. Yn ogystal, nid yw XA yn darparu datgeliad cloi nac yn cefnogi cynlluniau rheoli arian cyfred optimistaidd. Yn ogystal, nid yw rhai systemau fel ElasticSearch yn cefnogi XA nac unrhyw fodel trafodiad heterogenaidd arall. Felly, mae sicrhau atomigrwydd ysgrifennu mewn amrywiol dechnolegau storio data yn parhau i fod yn dasg heriol iawn ar gyfer cymwysiadau [3].
Delta
Dyluniwyd Delta i fynd i'r afael â chyfyngiadau datrysiadau cydamseru data presennol a hefyd yn galluogi cyfoethogi data ar-y-hedfan. Ein nod oedd tynnu'r holl gymhlethdodau hyn oddi wrth ddatblygwyr cymwysiadau fel y gallent ganolbwyntio'n llawn ar weithredu ymarferoldeb busnes. Nesaf byddwn yn disgrifio "Movie Search", yr achos defnydd gwirioneddol ar gyfer Netflix's Delta.
Mae Netflix yn defnyddio pensaernïaeth microwasanaeth yn eang, ac mae pob microwasanaeth fel arfer yn gwasanaethu un math o ddata. Mae gwybodaeth sylfaenol am y ffilm wedi'i chynnwys mewn microwasanaeth o'r enw Movie Service, ac mae data cysylltiedig fel gwybodaeth am gynhyrchwyr, actorion, gwerthwyr, ac yn y blaen yn cael ei reoli gan nifer o ficrowasanaethau eraill (sef Gwasanaeth Bargen, Gwasanaeth Talent a Gwasanaeth Gwerthwr).
Yn aml mae angen i ddefnyddwyr busnes yn Netflix Studios chwilio ar draws amrywiol feini prawf ffilm, a dyna pam ei bod yn bwysig iawn iddynt allu chwilio ar draws yr holl ddata sy'n gysylltiedig â ffilmiau.
Cyn Delta, roedd angen i'r tîm chwilio ffilm dynnu data o wasanaethau micro lluosog cyn mynegeio data'r ffilm. Yn ogystal, bu'n rhaid i'r tîm ddatblygu system a fyddai'n diweddaru'r mynegai chwilio o bryd i'w gilydd drwy ofyn am newidiadau gan ficrowasanaethau eraill, hyd yn oed os nad oedd unrhyw newidiadau o gwbl. Daeth y system hon yn gyflym yn gymhleth ac yn anodd ei chynnal.
Ffigur 1. System bleidleisio i Delta
Ar ôl defnyddio Delta, cafodd y system ei symleiddio i system a yrrir gan ddigwyddiadau fel y dangosir yn y ffigur canlynol. Mae digwyddiadau CDC (Newid-Data-Capture) yn cael eu hanfon at bynciau Keystone Kafka gan ddefnyddio Delta-Connector. Mae cymhwysiad Delta a adeiladwyd gan ddefnyddio Fframwaith Prosesu Delta Stream (yn seiliedig ar Flink) yn derbyn digwyddiadau CDC o bwnc, yn eu cyfoethogi trwy ffonio microwasanaethau eraill, ac yn olaf yn trosglwyddo'r data cyfoethog i fynegai chwilio yn Elasticsearch. Mae'r broses gyfan yn digwydd bron mewn amser real, hynny yw, cyn gynted ag y bydd newidiadau wedi'u hymrwymo i'r warws data, caiff mynegeion chwilio eu diweddaru.
Ffigur 2. Piblinell ddata gan ddefnyddio Delta
Yn yr adrannau canlynol, byddwn yn disgrifio gweithrediad y Delta-Connector, sy'n cysylltu â storio ac yn cyhoeddi digwyddiadau CDC i'r haen drafnidiaeth, sef seilwaith trosglwyddo data amser real sy'n llwybro digwyddiadau CDC i bynciau Kafka. Ac ar y diwedd, byddwn yn siarad am fframwaith prosesu ffrwd Delta, y gall datblygwyr cymwysiadau ei ddefnyddio ar gyfer prosesu data a rhesymeg cyfoethogi.
CDC (Newid-Cipio Data)
Rydym wedi datblygu gwasanaeth CDC o'r enw Delta-Connector, sy'n gallu dal newidiadau ymrwymedig o'r storfa ddata mewn amser real a'u hysgrifennu at ffrwd. Cymerir newidiadau amser real o'r log trafodion a'r tomenni storio. Defnyddir dympiau oherwydd nid yw logiau trafodion fel arfer yn storio holl hanes y newidiadau. Mae newidiadau fel arfer yn cael eu cyfresoli fel digwyddiadau Delta, felly nid oes rhaid i'r derbynnydd boeni o ble mae'r newid yn dod.
Mae Delta-Connector yn cefnogi nifer o nodweddion ychwanegol megis:
- Y gallu i ysgrifennu data allbwn personol heibio Kafka.
- Y gallu i actifadu tomenni â llaw ar unrhyw adeg ar gyfer pob bwrdd, bwrdd penodol, neu ar gyfer allweddi cynradd penodol.
- Gellir adalw dympiau mewn talpiau, felly nid oes angen ailddechrau rhag ofn y bydd yn methu.
- Nid oes angen gosod cloeon ar fyrddau, sy'n bwysig iawn i sicrhau nad yw traffig ysgrifennu cronfa ddata byth yn cael ei rwystro gan ein gwasanaeth.
- Argaeledd uchel oherwydd achosion diangen ym Mharthau Argaeledd AWS.
Ar hyn o bryd rydym yn cefnogi MySQL a Postgres, gan gynnwys lleoli ar AWS RDS ac Aurora. Rydym hefyd yn cefnogi Cassandra (aml-feistr). Gallwch ddarganfod mwy o fanylion am Delta-Connector yma .
Kafka a'r haen trafnidiaeth
Mae haen cludo digwyddiadau Delta wedi'i hadeiladu ar wasanaeth negeseuon y platfform .
Yn hanesyddol, mae postio ar Netflix wedi'i optimeiddio ar gyfer hygyrchedd yn hytrach na hirhoedledd (gweler isod). ). Y cyfaddawd oedd anghysondeb data brocer posibl mewn amrywiol senarios ymylol. Er enghraifft, etholiad arweinydd aflan yn gyfrifol am ddigwyddiadau dyblyg neu goll o bosibl gan y derbynnydd.
Gyda Delta, roeddem eisiau gwarantau gwydnwch cryfach i sicrhau bod digwyddiadau CDC yn cael eu cyflwyno i siopau deilliadol. At y diben hwn, fe wnaethom gynnig clwstwr Kafka a ddyluniwyd yn arbennig fel gwrthrych o'r radd flaenaf. Gallwch edrych ar rai gosodiadau brocer yn y tabl isod:
Mewn clystyrau Keystone Kafka, etholiad arweinydd aflan fel arfer yn cael eu cynnwys i sicrhau hygyrchedd cyhoeddwyr. Gall hyn arwain at golli neges os caiff atgynhyrchiad heb ei gydamseru ei ethol yn arweinydd. Ar gyfer clwstwr Kafka newydd sydd ar gael yn uchel, yr opsiwn etholiad arweinydd aflan wedi'i ddiffodd i atal colli neges.
Rydym hefyd wedi cynyddu ffactor atgynhyrchu o 2 hyd 3 a isafswm atgynyrchiadau insync 1 i 2. Mae cyhoeddwyr sy'n ysgrifennu i'r clwstwr hwn angen sylwadau gan bawb arall, gan sicrhau bod 2 allan o 3 replicas yn cael y negeseuon mwyaf cyfredol a anfonir gan y cyhoeddwr.
Pan ddaw achos brocer i ben, mae enghraifft newydd yn disodli'r hen un. Fodd bynnag, bydd angen i'r brocer newydd ddal i fyny â'r copïau heb eu cydamseru, a all gymryd sawl awr. Er mwyn lleihau'r amser adfer ar gyfer y senario hwn, dechreuon ni ddefnyddio storfa ddata bloc (Amazon Elastic Block Store) yn lle disgiau brocer lleol. Pan fydd achos newydd yn disodli enghraifft brocer a derfynwyd, mae'n atodi'r gyfrol EBS a gafodd yr enghraifft a derfynwyd ac yn dechrau dal i fyny â negeseuon newydd. Mae'r broses hon yn lleihau amser clirio ôl-groniad o oriau i funudau oherwydd nid oes angen i'r enghraifft newydd ailadrodd o gyflwr gwag mwyach. Yn gyffredinol, mae cylchoedd bywyd storio a broceriaid ar wahân yn lleihau effaith newid brocer yn sylweddol.
Er mwyn cynyddu'r warant cyflenwi data ymhellach, fe wnaethom ddefnyddio i ganfod unrhyw golled neges o dan amodau eithafol (er enghraifft, dessyncronization cloc yn yr arweinydd rhaniad).
Fframwaith Prosesu Ffrwd
Mae haen brosesu Delta wedi'i adeiladu ar ben platfform Netflix SPaaS, sy'n darparu integreiddiad Apache Flink ag ecosystem Netflix. Mae'r platfform yn darparu rhyngwyneb defnyddiwr sy'n rheoli'r defnydd o swyddi Flink ac offeryniaeth clystyrau Flink ar ben ein platfform rheoli cynwysyddion Titus. Mae'r rhyngwyneb hefyd yn rheoli ffurfweddiadau swyddi ac yn caniatáu i ddefnyddwyr wneud newidiadau cyfluniad yn ddeinamig heb orfod ail-grynhoi swyddi Flink.
Mae Delta yn darparu fframwaith prosesu ffrwd yn seiliedig ar Flink a SPaaS sy'n defnyddio seiliedig ar anodiadau DSL (Iaith Parth Penodol) i dynnu manylion technegol. Er enghraifft, i ddiffinio'r cam y bydd digwyddiadau'n cael eu cyfoethogi trwy alw gwasanaethau allanol, mae angen i ddefnyddwyr ysgrifennu'r DSL canlynol, a bydd y fframwaith yn creu model yn seiliedig arno, a fydd yn cael ei weithredu gan Flink.
Ffigur 3. Enghraifft o gyfoethogi ar DSL yn Delta
Mae'r fframwaith prosesu nid yn unig yn lleihau'r gromlin ddysgu, ond hefyd yn darparu nodweddion prosesu ffrwd gyffredin megis dad-ddyblygu, sgemateiddio, a hyblygrwydd a gwydnwch i ddatrys problemau gweithredol cyffredin.
Mae Fframwaith Prosesu Ffrwd Delta yn cynnwys dau fodiwl allweddol, y modiwl DSL & API a'r modiwl Runtime. Mae'r modiwl DSL & API yn darparu APIs DSL ac UDF (Defnyddiwr-Diffiniedig-Function) fel y gall defnyddwyr ysgrifennu eu rhesymeg prosesu eu hunain (fel hidlo neu drawsnewidiadau). Mae'r modiwl Runtime yn darparu gweithrediad parser DSL sy'n adeiladu cynrychiolaeth fewnol o gamau prosesu mewn modelau DAG. Mae'r gydran Cyflawni yn dehongli modelau DAG i gychwyn y datganiadau Flink gwirioneddol ac yn y pen draw rhedeg y cymhwysiad Flink. Dangosir pensaernïaeth y fframwaith yn y ffigur canlynol.
Ffigur 4. Pensaernïaeth Fframwaith Prosesu Delta Stream
Mae gan y dull hwn nifer o fanteision:
- Gall defnyddwyr ganolbwyntio ar eu rhesymeg busnes heb orfod ymchwilio i fanylion Flink na strwythur SPaaS.
- Gellir gwneud optimeiddio mewn ffordd sy'n dryloyw i ddefnyddwyr, a gellir trwsio gwallau heb fod angen unrhyw newidiadau i'r cod defnyddiwr (UDF).
- Mae profiad cymhwysiad Delta wedi'i symleiddio i ddefnyddwyr oherwydd bod y platfform yn darparu hyblygrwydd a gwydnwch allan o'r bocs ac yn casglu amrywiaeth o fetrigau manwl y gellir eu defnyddio ar gyfer rhybuddion.
Defnydd cynhyrchu
Mae Delta wedi bod yn cynhyrchu ers dros flwyddyn ac mae'n chwarae rhan allweddol mewn llawer o gymwysiadau Netflix Studio. Helpodd hi dimau i weithredu achosion defnydd fel mynegeio chwilio, storio data, a llifoedd gwaith a yrrir gan ddigwyddiadau. Isod mae trosolwg o bensaernïaeth lefel uchel platfform Delta.
Ffigur 5. Pensaernïaeth lefel uchel Delta.
Cydnabyddiaethau
Hoffem ddiolch i'r bobl ganlynol a fu'n ymwneud â chreu a datblygu Delta yn 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 a Zhenzhong Xu.
Ffynonellau
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Prosesu digwyddiadau ar-lein. Cymmun. ACM 62(5): 43–49 (2019). DOI:
: “Offeryn Adeiladu Data ar gyfer Storio Redshift Amazon.”
Ffynhonnell: hab.com