Kwa kutarajia uzinduzi wa mtiririko mpya kwa kiwango Tumetayarisha tafsiri ya nyenzo za kuvutia.
Pitia
Tutazungumza juu ya muundo maarufu ambao programu hutumia hifadhi nyingi za data, ambapo kila duka hutumiwa kwa madhumuni yake mwenyewe, kwa mfano, kuhifadhi aina ya data ya kisheria (MySQL, nk.), kutoa uwezo wa juu wa utafutaji (ElasticSearch, nk) .), caching (Memcached, nk) na wengine. Kwa kawaida, unapotumia hifadhi nyingi za data, mojawapo hufanya kama hifadhi ya msingi na nyingine kama hifadhi zinazotoka. Tatizo pekee ni jinsi ya kusawazisha hifadhi hizi za data.
Tuliangalia idadi ya miundo tofauti iliyojaribu kutatua tatizo la kusawazisha maduka mengi, kama vile kuandika mara mbili, miamala iliyosambazwa, n.k. Hata hivyo, mbinu hizi zina mapungufu makubwa katika suala la matumizi halisi ya maisha, kutegemewa, na matengenezo. Kando na ulandanishi wa data, baadhi ya programu pia zinahitaji kuboresha data kwa kupiga simu kwa huduma za nje.
Delta ilitengenezwa kutatua matatizo haya. Delta hatimaye hutoa jukwaa thabiti, linaloendeshwa na matukio kwa ulandanishi wa data na uboreshaji.
Ufumbuzi uliopo
Kuingia mara mbili
Ili kuweka hifadhi mbili za data katika usawazishaji, unaweza kutumia uandishi wa aina mbili, ambao huandikia duka moja na kisha kuliandikia lingine mara moja baadaye. Rekodi ya kwanza inaweza kujaribiwa tena na ya pili inaweza kufutwa ikiwa ya kwanza itashindwa baada ya idadi ya majaribio kuisha. Walakini, hifadhi hizi mbili za data zinaweza kukosa kusawazishwa ikiwa kuandika kwa duka la pili kutashindwa. Tatizo hili kawaida hutatuliwa kwa kuunda utaratibu wa uokoaji ambao unaweza kuhamisha data mara kwa mara kutoka kwa hifadhi ya kwanza hadi ya pili, au kufanya hivyo tu ikiwa tofauti hugunduliwa katika data.
Shida ni:
Kufanya utaratibu wa kurejesha ni kazi maalum ambayo haiwezi kutumika tena. Kwa kuongeza, data kati ya maeneo ya hifadhi bado haijasawazishwa hadi utaratibu wa kurejesha ufanyike. Suluhisho inakuwa ngumu zaidi ikiwa zaidi ya maduka mawili ya data hutumiwa. Hatimaye, utaratibu wa kurejesha unaweza kuongeza mzigo kwenye chanzo asili cha data.
Badilisha jedwali la kumbukumbu
Mabadiliko yanapotokea kwenye seti ya jedwali (kama vile kuingiza, kusasisha, na kufuta rekodi), rekodi za mabadiliko huongezwa kwenye jedwali la kumbukumbu kama sehemu ya shughuli hiyo hiyo. Thread nyingine au mchakato huomba mara kwa mara matukio kutoka kwa jedwali la logi na huwaandikia kwa hifadhi moja au zaidi ya data, ikiwa ni lazima, kuondoa matukio kutoka kwa meza ya logi baada ya rekodi kuthibitishwa na maduka yote.
Shida ni:
Mchoro huu unapaswa kutekelezwa kama maktaba, na kwa hakika bila kubadilisha msimbo wa programu inayoitumia. Katika mazingira ya polyglot, utekelezaji wa maktaba kama hiyo inapaswa kuwepo katika lugha yoyote muhimu, lakini kuhakikisha uwiano wa utendaji na tabia katika lugha zote ni vigumu sana.
Tatizo jingine liko katika kupata mabadiliko ya taratibu katika mifumo ambayo haiauni mabadiliko ya schema ya shughuli [1][2], kama vile MySQL. Kwa hivyo, muundo wa kufanya mabadiliko (kwa mfano, mabadiliko ya schema) na kurekodi kwa shughuli kwenye jedwali la logi ya mabadiliko haitafanya kazi kila wakati.
Miamala Iliyosambazwa
Miamala iliyosambazwa inaweza kutumika kugawanya muamala katika hifadhi nyingi tofauti za data ili utendakazi ufanyike kwa hifadhi zote za data zinazotumiwa, au zisikabidhiwe kwa lolote kati ya hizo.
Shida ni:
Shughuli zinazosambazwa ni tatizo kubwa sana kwa hifadhi za data tofauti tofauti. Kwa asili yao, wanaweza kutegemea tu dhehebu la chini kabisa la mifumo inayohusika. Kwa mfano, miamala ya XA inazuia utekelezaji ikiwa mchakato wa maombi utashindwa wakati wa awamu ya utayarishaji. Zaidi ya hayo, XA haitoi ugunduzi wa mwisho au kuauni mipango ya udhibiti wa upatanishi yenye matumaini. Kwa kuongeza, baadhi ya mifumo kama vile ElasticSearch haitumii XA au modeli yoyote ya muamala isiyo tofauti. Kwa hivyo, kuhakikisha atomiki ya uandishi katika teknolojia mbalimbali za kuhifadhi data inabakia kuwa kazi ngumu sana kwa programu [3].
Delta
Delta iliundwa kushughulikia mapungufu ya suluhu zilizopo za ulandanishi wa data na pia kuwezesha uboreshaji wa data popote ulipo. Lengo letu lilikuwa kuondoa matatizo haya yote kutoka kwa wasanidi programu ili waweze kuzingatia kikamilifu utekelezaji wa utendaji wa biashara. Ifuatayo tutakuwa tukielezea "Utafutaji wa Filamu", hali halisi ya utumiaji wa Delta ya Netflix.
Netflix hutumia sana usanifu wa huduma ndogo, na kila huduma ndogo hutumikia aina moja ya data. Maelezo ya kimsingi kuhusu filamu yamo katika huduma ndogo inayoitwa Huduma ya Filamu, na data inayohusishwa kama vile taarifa kuhusu watayarishaji, waigizaji, wachuuzi, na kadhalika inasimamiwa na huduma ndogondogo kadhaa (yaani Huduma ya Biashara, Huduma ya Vipaji na Huduma ya Wauzaji).
Watumiaji wa biashara katika Studio za Netflix mara nyingi huhitaji kutafuta katika vigezo mbalimbali vya filamu, ndiyo maana ni muhimu sana kwao kuweza kutafuta data yote inayohusiana na filamu.
Kabla ya Delta, timu ya kutafuta filamu ilihitaji kuvuta data kutoka kwa huduma ndogo ndogo kabla ya kuorodhesha data ya filamu. Kwa kuongezea, timu ililazimika kuunda mfumo ambao ungesasisha faharasa ya utaftaji mara kwa mara kwa kuomba mabadiliko kutoka kwa huduma zingine ndogo, hata kama hakukuwa na mabadiliko yoyote. Mfumo huu haraka ukawa mgumu na mgumu kudumisha.
Kielelezo 1. Mfumo wa kupigia kura kwa Delta
Baada ya kutumia Delta, mfumo umerahisishwa kwa mfumo unaoendeshwa na tukio kama inavyoonyeshwa kwenye takwimu ifuatayo. Matukio ya CDC (Change-Data-Capture) hutumwa kwa mada za Keystone Kafka kwa kutumia Delta-Connector. Programu ya Delta iliyojengwa kwa kutumia Mfumo wa Uchakataji wa Mtiririko wa Delta (kulingana na Flink) hupokea matukio ya CDC kutoka kwa mada, inayaboresha kwa kupiga simu huduma ndogo ndogo, na hatimaye hupitisha data iliyoboreshwa kwenye faharasa ya utafutaji katika Elasticsearch. Mchakato mzima unafanyika karibu kwa wakati halisi, yaani, mara tu mabadiliko yanapofanywa kwenye ghala la data, indexes za utafutaji zinasasishwa.
Kielelezo 2. Bomba la data kwa kutumia Delta
Katika sehemu zifuatazo, tutaelezea uendeshaji wa Delta-Connector, ambayo inaunganisha kwenye hifadhi na kuchapisha matukio ya CDC kwenye safu ya usafiri, ambayo ni miundombinu ya maambukizi ya data ya muda halisi ambayo hupitisha matukio ya CDC kwa mada ya Kafka. Na mwisho kabisa, tutazungumza juu ya mfumo wa usindikaji wa mkondo wa Delta, ambao watengenezaji wa programu wanaweza kutumia kwa usindikaji wa data na mantiki ya uboreshaji.
CDC (Badilisha-Kunasa Data)
Tumeunda huduma ya CDC inayoitwa Delta-Connector, ambayo inaweza kunasa mabadiliko yaliyojitolea kutoka kwa hifadhi ya data kwa wakati halisi na kuyaandika kwenye mkondo. Mabadiliko ya wakati halisi huchukuliwa kutoka kwa kumbukumbu ya ununuzi na utupaji wa hifadhi. Dampo hutumiwa kwa sababu kumbukumbu za miamala kwa kawaida hazihifadhi historia nzima ya mabadiliko. Mabadiliko kwa kawaida hupangwa kama matukio ya Delta, kwa hivyo mpokeaji halazimiki kuwa na wasiwasi kuhusu mahali mabadiliko yanatoka.
Delta-Connector inasaidia huduma kadhaa za ziada kama vile:
- Uwezo wa kuandika data ya pato maalum zamani Kafka.
- Uwezo wa kuwezesha utupaji wa taka wakati wowote kwa meza zote, jedwali mahususi, au kwa funguo maalum za msingi.
- Dampo zinaweza kupatikana kwa vipande, kwa hivyo hakuna haja ya kuanza tena ikiwa itashindwa.
- Hakuna haja ya kuweka kufuli kwenye meza, ambayo ni muhimu sana ili kuhakikisha kuwa trafiki ya uandishi wa hifadhidata haizuiliwi na huduma yetu.
- Upatikanaji wa juu kutokana na matukio yasiyohitajika katika Maeneo ya Upatikanaji ya AWS.
Kwa sasa tunaauni MySQL na Postgres, ikijumuisha utumaji kwenye AWS RDS na Aurora. Pia tunamuunga mkono Cassandra (mabwana wengi). Unaweza kupata maelezo zaidi kuhusu Delta-Connector hapa .
Kafka na safu ya usafiri
Safu ya usafiri wa matukio ya Delta imejengwa kwenye huduma ya utumaji ujumbe ya jukwaa .
Kihistoria, kuchapisha kwenye Netflix kumeboreshwa kwa ufikivu badala ya maisha marefu (tazama hapa chini). ) Ubadilishanaji huo ulikuwa uwezekano wa kutofautiana kwa data ya wakala katika hali mbalimbali za makali. Kwa mfano, uchaguzi wa kiongozi mchafu inawajibikia mpokeaji uwezekano wa kuwa na matukio yaliyorudiwa au yaliyopotea.
Kwa Delta, tulitaka hakikisho dhabiti la uimara ili kuhakikisha uwasilishaji wa hafla za CDC kwenye duka zinazotolewa. Kwa kusudi hili, tulipendekeza nguzo maalum ya Kafka kama kitu cha daraja la kwanza. Unaweza kuangalia baadhi ya mipangilio ya wakala kwenye jedwali hapa chini:
Katika makundi ya Keystone Kafka, uchaguzi wa kiongozi mchafu kawaida hujumuishwa ili kuhakikisha ufikivu wa mchapishaji. Hii inaweza kusababisha upotezaji wa ujumbe ikiwa nakala ambayo haijasawazishwa itachaguliwa kama kiongozi. Kwa mkusanyiko mpya wa upatikanaji wa juu wa Kafka, chaguo uchaguzi wa kiongozi mchafu imezimwa ili kuzuia upotezaji wa ujumbe.
Pia tuliongezeka sababu ya kurudia kutoka 2 hadi 3 na nakala za chini kabisa zisizosawazishwa 1 hadi 2. Wachapishaji wanaoandikia kundi hili wanahitaji acks kutoka kwa wengine wote, kuhakikisha kwamba nakala 2 kati ya 3 zina ujumbe wa sasa zaidi unaotumwa na mchapishaji.
Mfano wa wakala ukikamilika, mfano mpya hubadilisha ule wa zamani. Hata hivyo, wakala mpya atahitaji kupata nakala ambazo hazijasawazishwa, ambazo zinaweza kuchukua saa kadhaa. Ili kupunguza muda wa urejeshaji kwa hali hii, tulianza kutumia hifadhi ya data ya kuzuia (Amazon Elastic Block Store) badala ya diski za wakala wa ndani. Tukio jipya linapochukua nafasi ya mfano uliokatishwa wa wakala, huambatisha sauti ya EBS ambayo tukio lililositishwa lilikuwa nalo na huanza kupata ujumbe mpya. Mchakato huu unapunguza muda wa uondoaji wa kumbukumbu kutoka saa hadi dakika kwa sababu mfano mpya hauhitaji tena kujirudia kutoka kwa hali tupu. Kwa ujumla, uhifadhi tofauti na mizunguko ya maisha ya wakala hupunguza kwa kiasi kikubwa athari za ubadilishaji wa wakala.
Ili kuongeza zaidi dhamana ya utoaji wa data, tulitumia kugundua upotezaji wowote wa ujumbe chini ya hali mbaya zaidi (kwa mfano, ulandanishi wa saa katika kiongozi wa kizigeu).
Mfumo wa Uchakataji wa Mipasho
Safu ya uchakataji ya Delta imejengwa juu ya jukwaa la Netflix SPaaS, ambalo hutoa muunganisho wa Apache Flink na mfumo ikolojia wa Netflix. Mfumo huu hutoa kiolesura cha mtumiaji ambacho hudhibiti utumaji wa kazi za Flink na upangaji wa makundi ya Flink juu ya jukwaa letu la usimamizi wa kontena la Titus. Kiolesura pia hudhibiti usanidi wa kazi na huruhusu watumiaji kufanya mabadiliko ya usanidi kwa nguvu bila kulazimika kurudisha kazi za Flink.
Delta hutoa mfumo wa usindikaji wa mtiririko kulingana na Flink na SPaaS inayotumia kulingana na maelezo DSL (Lugha Maalum ya Kikoa) ili kutoa maelezo ya kiufundi ya muhtasari. Kwa mfano, ili kufafanua hatua ambayo matukio yataboreshwa kwa kupiga huduma za nje, watumiaji wanahitaji kuandika DSL ifuatayo, na mfumo utaunda mfano kulingana na hilo, ambao utatekelezwa na Flink.
Kielelezo 3. Mfano wa uboreshaji kwenye DSL katika Delta
Mfumo wa uchakataji haupunguzi tu mkondo wa kujifunza, lakini pia hutoa vipengele vya kawaida vya uchakataji wa mitiririko kama vile kurudisha nyuma, usanifu, na unyumbufu na uthabiti wa kutatua matatizo ya kawaida ya uendeshaji.
Mfumo wa Uchakataji wa Mtiririko wa Delta una moduli mbili muhimu, moduli ya DSL & API na moduli ya Muda wa Kuendesha. Sehemu ya DSL & API hutoa API za DSL na UDF (User-Defined-Function) ili watumiaji waweze kuandika mantiki yao ya uchakataji (kama vile kuchuja au kubadilisha). Muda wa Runtime hutoa utekelezaji wa kichanganuzi cha DSL ambacho huunda uwakilishi wa ndani wa hatua za uchakataji katika miundo ya DAG. Sehemu ya Utekelezaji hutafsiri miundo ya DAG ili kuanzisha taarifa halisi za Flink na hatimaye kuendesha programu ya Flink. Usanifu wa muundo unaonyeshwa kwenye takwimu ifuatayo.
Kielelezo 4. Usanifu wa Mfumo wa Uchakataji wa Mkondo wa Delta
Mbinu hii ina faida kadhaa:
- Watumiaji wanaweza kuzingatia mantiki ya biashara zao bila kulazimika kuangazia maelezo mahususi ya Flink au muundo wa SPaaS.
- Uboreshaji unaweza kufanywa kwa njia ambayo ni wazi kwa watumiaji, na hitilafu zinaweza kurekebishwa bila kuhitaji mabadiliko yoyote kwenye msimbo wa mtumiaji (UDF).
- Utumiaji wa programu ya Delta hurahisishwa kwa watumiaji kwa sababu mfumo hutoa unyumbufu na uthabiti nje ya boksi na hukusanya vipimo mbalimbali vya kina vinavyoweza kutumika kwa arifa.
Matumizi ya uzalishaji
Delta imekuwa katika uzalishaji kwa zaidi ya mwaka mmoja na ina jukumu muhimu katika programu nyingi za Netflix Studio. Alisaidia timu kutekeleza kesi za utumiaji kama vile kuorodhesha utaftaji, uhifadhi wa data, na mtiririko wa kazi unaoendeshwa na hafla. Chini ni muhtasari wa usanifu wa hali ya juu wa jukwaa la Delta.
Kielelezo 5. Usanifu wa hali ya juu wa Delta.
Shukrani
Tungependa kuwashukuru watu wafuatao ambao walihusika katika uundaji na ukuzaji wa Delta kwenye 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 na Zhenzhong Xu.
Vyanzo
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Usindikaji wa tukio mtandaoni. Jumuiya. ACM 62(5): 43β49 (2019). DOI:
: "Zana ya Kuunda Data kwa Hifadhi ya Redshift ya Amazon."
Chanzo: mapenzi.com