Sa pag-asa ng paglulunsad ng isang bagong daloy sa rate Naghanda kami ng pagsasalin ng kawili-wiling materyal.
Repasuhin
Pag-uusapan natin ang isang medyo sikat na pattern kung saan ang mga application ay gumagamit ng maramihang mga tindahan ng data, kung saan ang bawat tindahan ay ginagamit para sa sarili nitong mga layunin, halimbawa, upang mag-imbak ng canonical form ng data (MySQL, atbp.), magbigay ng mga advanced na kakayahan sa paghahanap (ElasticSearch, atbp.) .), pag-cache (Memcached, atbp.) at iba pa. Karaniwan, kapag gumagamit ng maramihang mga data store, ang isa sa mga ito ay gumaganap bilang pangunahing tindahan at ang iba bilang mga derivative na tindahan. Ang tanging problema ay kung paano i-synchronize ang mga data store na ito.
Tumingin kami sa ilang iba't ibang pattern na sinubukang lutasin ang problema sa pag-synchronize ng maraming tindahan, gaya ng double writes, distributed transactions, atbp. Gayunpaman, ang mga pamamaraang ito ay may makabuluhang limitasyon sa mga tuntunin ng paggamit, pagiging maaasahan, at pagpapanatili sa totoong buhay. Bilang karagdagan sa pag-synchronize ng data, kailangan din ng ilang application na pagyamanin ang data sa pamamagitan ng pagtawag sa mga panlabas na serbisyo.
Ang Delta ay binuo upang malutas ang mga problemang ito. Ang Delta sa huli ay nagbibigay ng pare-pareho, platform na hinimok ng kaganapan para sa pag-synchronize at pagpapayaman ng data.
Umiiral na mga solusyon
Dobleng pagpasok
Upang panatilihing naka-sync ang dalawang data store, maaari mong gamitin ang dalawahang pagsusulat, na nagsusulat sa isang tindahan at pagkatapos ay nagsusulat kaagad sa isa pagkatapos. Ang unang pag-record ay maaaring subukang muli at ang pangalawa ay maaaring i-abort kung ang una ay nabigo pagkatapos maubos ang bilang ng mga pagtatangka. Gayunpaman, maaaring maging out of sync ang dalawang data store kung mabigo ang pagsulat sa pangalawang store. Ang problemang ito ay kadalasang nalulutas sa pamamagitan ng paggawa ng pamamaraan sa pagbawi na maaaring pana-panahong maglipat ng data mula sa unang imbakan patungo sa pangalawa, o gawin lamang ito kung may nakitang mga pagkakaiba sa data.
Mga problema:
Ang pagsasagawa ng pamamaraan sa pagbawi ay isang partikular na trabaho na hindi magagamit muli. Bilang karagdagan, ang data sa pagitan ng mga lokasyon ng storage ay nananatiling hindi naka-sync hanggang sa maganap ang proseso ng pag-restore. Ang solusyon ay nagiging mas kumplikado kung higit sa dalawang data store ang ginagamit. Sa wakas, ang pamamaraan ng pag-restore ay maaaring magdagdag ng pag-load sa orihinal na pinagmulan ng data.
Baguhin ang log table
Kapag naganap ang mga pagbabago sa isang hanay ng mga talahanayan (tulad ng pagpasok, pag-update, at pagtanggal ng isang tala), ang mga talaan ng pagbabago ay idinaragdag sa log table bilang bahagi ng parehong transaksyon. Ang isa pang thread o proseso ay patuloy na humihiling ng mga kaganapan mula sa talahanayan ng log at isinusulat ang mga ito sa isa o higit pang mga tindahan ng data, kung kinakailangan, inaalis ang mga kaganapan mula sa talahanayan ng log pagkatapos makumpirma ng lahat ng mga tindahan ang talaan.
Mga problema:
Ang pattern na ito ay dapat na ipatupad bilang isang library, at perpektong hindi binabago ang code ng application na gumagamit nito. Sa isang polyglot na kapaligiran, ang pagpapatupad ng naturang library ay dapat na umiiral sa anumang kinakailangang wika, ngunit ang pagtiyak ng pare-pareho ng pag-andar at pag-uugali sa mga wika ay napakahirap.
Ang isa pang problema ay nakasalalay sa pagkuha ng mga pagbabago sa schema sa mga system na hindi sumusuporta sa mga pagbabago sa transactional schema [1][2], tulad ng MySQL. Samakatuwid, hindi palaging gagana ang pattern ng paggawa ng pagbabago (halimbawa, pagbabago ng schema) at transactional na pagre-record nito sa change log table.
Mga Ibinahagi na Transaksyon
Maaaring gamitin ang mga ibinahagi na transaksyon upang hatiin ang isang transaksyon sa maraming magkakaibang mga tindahan ng data upang ang operasyon ay maaaring nakatuon sa lahat ng mga tindahan ng data na ginamit, o hindi nakatuon sa alinman sa mga ito.
Mga problema:
Ang mga ipinamamahaging transaksyon ay isang napakalaking problema para sa magkakaibang mga tindahan ng data. Sa kanilang likas na katangian, maaari lamang silang umasa sa pinakamababang karaniwang denominator ng mga sistemang kasangkot. Halimbawa, hinaharangan ng mga transaksyon ng XA ang pagpapatupad kung nabigo ang proseso ng aplikasyon sa yugto ng paghahanda. Bukod pa rito, hindi nagbibigay ang XA ng deadlock detection o sumusuporta sa mga optimistic concurrency control scheme. Bilang karagdagan, ang ilang mga system tulad ng ElasticSearch ay hindi sumusuporta sa XA o anumang iba pang heterogenous na modelo ng transaksyon. Kaya, ang pagtiyak sa pagsulat ng atomicity sa iba't ibang mga teknolohiya sa pag-iimbak ng data ay nananatiling isang napakahirap na gawain para sa mga aplikasyon [3].
Delta
Ang Delta ay idinisenyo upang tugunan ang mga limitasyon ng umiiral na mga solusyon sa pag-synchronize ng data at nagbibigay-daan din sa on-the-fly na pagpapayaman ng data. Ang aming layunin ay i-abstract ang lahat ng mga kumplikadong ito mula sa mga developer ng application upang sila ay ganap na tumutok sa pagpapatupad ng paggana ng negosyo. Susunod, ilalarawan namin ang "Paghahanap ng Pelikula", ang aktwal na kaso ng paggamit para sa Delta ng Netflix.
Ang Netflix ay malawakang gumagamit ng isang microservice architecture, at ang bawat microservice ay karaniwang naghahatid ng isang uri ng data. Ang pangunahing impormasyon tungkol sa pelikula ay nakapaloob sa isang microservice na tinatawag na Movie Service, at ang nauugnay na data tulad ng impormasyon tungkol sa mga producer, aktor, vendor, at iba pa ay pinamamahalaan ng ilang iba pang microservices (ibig sabihin, Deal Service, Talent Service at Vendor Service).
Ang mga user ng negosyo sa Netflix Studios ay madalas na kailangang maghanap sa iba't ibang pamantayan ng pelikula, kaya naman napakahalaga para sa kanila na makapaghanap sa lahat ng data na nauugnay sa pelikula.
Bago ang Delta, kailangan ng koponan sa paghahanap ng pelikula na kumuha ng data mula sa maraming microservice bago i-index ang data ng pelikula. Bilang karagdagan, ang koponan ay kailangang bumuo ng isang sistema na pana-panahong mag-a-update sa index ng paghahanap sa pamamagitan ng paghiling ng mga pagbabago mula sa iba pang mga microservice, kahit na walang mga pagbabago. Ang sistemang ito ay mabilis na naging kumplikado at mahirap mapanatili.
Figure 1. Sistema ng botohan sa Delta
Pagkatapos gamitin ang Delta, ang system ay pinasimple sa isang event driven system tulad ng ipinapakita sa sumusunod na figure. Ang mga kaganapan sa CDC (Change-Data-Capture) ay ipinapadala sa mga paksa ng Keystone Kafka gamit ang Delta-Connector. Ang isang Delta application na binuo gamit ang Delta Stream Processing Framework (batay sa Flink) ay tumatanggap ng mga kaganapan sa CDC mula sa isang paksa, nagpapayaman sa kanila sa pamamagitan ng pagtawag sa iba pang mga microservice, at sa wakas ay ipinapasa ang enriched na data sa isang search index sa Elasticsearch. Ang buong proseso ay nagaganap halos sa real time, iyon ay, sa sandaling ang mga pagbabago ay ginawa sa data warehouse, ang mga index ng paghahanap ay ina-update.
Figure 2. Data pipeline gamit ang Delta
Sa mga sumusunod na seksyon, ilalarawan namin ang pagpapatakbo ng Delta-Connector, na kumokonekta sa storage at nagpa-publish ng mga kaganapan sa CDC sa layer ng transportasyon, na isang real-time na imprastraktura ng paghahatid ng data na nagruruta ng mga kaganapan sa CDC sa mga paksa ng Kafka. At sa pinakadulo, pag-uusapan natin ang tungkol sa balangkas ng pagproseso ng Delta stream, na magagamit ng mga developer ng application para sa pagpoproseso ng data at lohika ng pagpapayaman.
CDC (Change-Data-Capture)
Bumuo kami ng serbisyo ng CDC na tinatawag na Delta-Connector, na maaaring makuha ang mga nakatuong pagbabago mula sa data store nang real time at isulat ang mga ito sa isang stream. Ang mga real-time na pagbabago ay kinuha mula sa log ng transaksyon at mga dump ng imbakan. Ginagamit ang mga dump dahil karaniwang hindi iniimbak ng mga log ng transaksyon ang buong kasaysayan ng mga pagbabago. Karaniwang naka-serialize ang mga pagbabago bilang mga kaganapan sa Delta, kaya hindi kailangang mag-alala ang tatanggap kung saan nagmumula ang pagbabago.
Sinusuportahan ng Delta-Connector ang ilang karagdagang mga tampok tulad ng:
- Kakayahang magsulat ng custom na data ng output sa nakalipas na Kafka.
- Kakayahang i-activate ang mga manu-manong dump anumang oras para sa lahat ng mga talahanayan, isang partikular na talahanayan, o para sa mga partikular na pangunahing key.
- Maaaring kunin ang mga dump sa mga tipak, kaya hindi na kailangang magsimulang muli kung sakaling mabigo.
- Hindi na kailangang maglagay ng mga kandado sa mga mesa, na napakahalaga upang matiyak na ang trapiko sa pagsulat ng database ay hindi kailanman hinarangan ng aming serbisyo.
- Mataas na availability dahil sa mga paulit-ulit na pagkakataon sa AWS Availability Zone.
Kasalukuyan naming sinusuportahan ang MySQL at Postgres, kabilang ang mga deployment sa AWS RDS at Aurora. Sinusuportahan din namin si Cassandra (multi-master). Maaari mong malaman ang higit pang mga detalye tungkol sa Delta-Connector dito .
Kafka at ang layer ng transportasyon
Ang layer ng transport ng kaganapan ng Delta ay binuo sa serbisyo ng pagmemensahe ng platform .
Sa kasaysayan, ang pag-post sa Netflix ay na-optimize para sa accessibility kaysa sa mahabang buhay (tingnan sa ibaba). ). Ang trade-off ay potensyal na hindi pagkakapare-pareho ng data ng broker sa iba't ibang mga gilid na sitwasyon. Halimbawa, hindi malinis na halalan ng pinuno ay responsable para sa tatanggap na posibleng magkaroon ng mga duplicate o nawala na mga kaganapan.
Sa Delta, gusto namin ng mas malakas na garantiya ng tibay upang matiyak ang paghahatid ng mga kaganapan sa CDC sa mga nagmula na tindahan. Para sa layuning ito, iminungkahi namin ang isang espesyal na idinisenyong Kafka cluster bilang isang first-class na bagay. Maaari mong tingnan ang ilang setting ng broker sa talahanayan sa ibaba:
Sa mga kumpol ng Keystone Kafka, hindi malinis na halalan ng pinuno karaniwang kasama para matiyak ang pagiging naa-access ng publisher. Ito ay maaaring magresulta sa pagkawala ng mensahe kung ang isang hindi naka-synchronize na replika ay mahalal bilang pinuno. Para sa isang bagong high availability Kafka cluster, ang opsyon hindi malinis na halalan ng pinuno naka-off para maiwasan ang pagkawala ng mensahe.
Nadagdagan din kami kadahilanan ng pagtitiklop mula 2 hanggang 3 at pinakamababang insync na mga replika 1 hanggang 2. Ang mga publisher na sumusulat sa cluster na ito ay nangangailangan ng acks mula sa lahat ng iba, na tinitiyak na 2 sa 3 replica ang may pinakabagong mga mensaheng ipinadala ng publisher.
Kapag natapos ang isang instance ng broker, pinapalitan ng bagong instance ang luma. Gayunpaman, kakailanganin ng bagong broker na abutin ang mga hindi naka-synchronize na mga replika, na maaaring tumagal ng ilang oras. Upang bawasan ang oras ng pagbawi para sa sitwasyong ito, nagsimula kaming gumamit ng block data storage (Amazon Elastic Block Store) sa halip na mga lokal na disk ng broker. Kapag pinalitan ng isang bagong instance ang isang instance na winakasan ng broker, inilalagay nito ang volume ng EBS na mayroon ang winakasan na instance at nagsisimulang makahabol ng mga bagong mensahe. Binabawasan ng prosesong ito ang backlog clearance time mula sa mga oras hanggang minuto dahil hindi na kailangan ng bagong instance na kopyahin mula sa isang walang laman na estado. Sa pangkalahatan, makabuluhang binabawasan ng magkahiwalay na imbakan at mga lifecycle ng broker ang epekto ng paglipat ng broker.
Upang higit pang madagdagan ang garantiya sa paghahatid ng data, ginamit namin upang makita ang anumang pagkawala ng mensahe sa ilalim ng matinding kundisyon (halimbawa, pag-desynchronize ng orasan sa pinuno ng partisyon).
Stream Processing Framework
Ang layer ng pagpoproseso ng Delta ay binuo sa ibabaw ng platform ng Netflix SPaaS, na nagbibigay ng pagsasama ng Apache Flink sa ecosystem ng Netflix. Nagbibigay ang platform ng user interface na namamahala sa pag-deploy ng mga trabaho sa Flink at pag-orkestra ng mga cluster ng Flink sa ibabaw ng aming platform ng pamamahala ng container ng Titus. Pinamamahalaan din ng interface ang mga configuration ng trabaho at nagbibigay-daan sa mga user na gumawa ng mga pagbabago sa configuration nang dynamic nang hindi kinakailangang muling i-compile ang mga trabaho sa Flink.
Nagbibigay ang Delta ng isang stream processing framework batay sa Flink at SPaaS na gumagamit batay sa anotasyon DSL (Domain Specific Language) sa mga abstract na teknikal na detalye. Halimbawa, upang tukuyin ang hakbang kung saan pagyayamanin ang mga kaganapan sa pamamagitan ng pagtawag sa mga panlabas na serbisyo, kailangang isulat ng mga user ang sumusunod na DSL, at gagawa ang framework ng isang modelo batay dito, na isasagawa ng Flink.
Larawan 3. Halimbawa ng pagpapayaman sa DSL sa Delta
Hindi lang binabawasan ng processing framework ang learning curve, ngunit nagbibigay din ng mga karaniwang feature sa pagpoproseso ng stream gaya ng deduplication, schematization, at flexibility at resiliency para malutas ang mga karaniwang problema sa pagpapatakbo.
Ang Delta Stream Processing Framework ay binubuo ng dalawang pangunahing module, ang DSL at API module at ang Runtime module. Ang module ng DSL at API ay nagbibigay ng mga DSL at UDF (User-Defined-Function) API upang ang mga user ay makapagsulat ng sarili nilang logic sa pagpoproseso (gaya ng pag-filter o pagbabago). Ang Runtime module ay nagbibigay ng pagpapatupad ng isang DSL parser na bumubuo ng panloob na representasyon ng mga hakbang sa pagproseso sa mga modelo ng DAG. Ang bahagi ng Pagpapatupad ay nagbibigay kahulugan sa mga modelo ng DAG upang simulan ang aktwal na mga pahayag ng Flink at sa huli ay patakbuhin ang Flink application. Ang arkitektura ng balangkas ay inilalarawan sa sumusunod na pigura.
Larawan 4. arkitektura ng Delta Stream Processing Framework
Ang diskarte na ito ay may ilang mga pakinabang:
- Maaaring tumuon ang mga user sa kanilang lohika sa negosyo nang hindi kinakailangang suriin ang mga detalye ng Flink o ang istraktura ng SPaaS.
- Maaaring gawin ang pag-optimize sa paraang malinaw sa mga user, at maaaring ayusin ang mga error nang hindi nangangailangan ng anumang pagbabago sa user code (UDF).
- Ang karanasan sa Delta application ay pinasimple para sa mga user dahil ang platform ay nagbibigay ng flexibility at resiliency out of the box at nangongolekta ng iba't ibang detalyadong sukatan na magagamit para sa mga alerto.
Paggamit ng produksyon
Ang Delta ay nasa produksyon nang higit sa isang taon at gumaganap ng isang mahalagang papel sa maraming mga aplikasyon ng Netflix Studio. Tinulungan niya ang mga team na ipatupad ang mga kaso ng paggamit gaya ng pag-index ng paghahanap, pag-iimbak ng data, at mga daloy ng trabaho na hinihimok ng kaganapan. Nasa ibaba ang isang pangkalahatang-ideya ng mataas na antas na arkitektura ng Delta platform.
Figure 5. Ang mataas na antas ng arkitektura ng Delta.
Mga Pasasalamat
Nais naming pasalamatan ang mga sumusunod na tao na kasangkot sa paglikha at pagbuo ng Delta sa 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 at Zhenzhong Xu.
pinagmumulan
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online na pagproseso ng kaganapan. Commun. ACM 62(5): 43β49 (2019). DOI:
: βTool sa Pagbuo ng Data para sa Amazon Redshift Storage.β
Pinagmulan: www.habr.com