Sa pagpaabut sa paglansad sa usa ka bag-ong dagan sa rate Nag-andam kami ug usa ka hubad sa makaiikag nga materyal.
kinatibuk-ang paghulagway
Maghisgot kami bahin sa usa ka medyo popular nga sumbanan diin ang mga aplikasyon naggamit daghang mga tindahan sa datos, diin ang matag tindahan gigamit alang sa kaugalingon nga katuyoan, pananglitan, sa pagtipig sa kanonikal nga porma sa datos (MySQL, ug uban pa), naghatag mga advanced nga kapabilidad sa pagpangita (ElasticSearch, etc.), caching (Memcached, etc.) ug uban pa. Kasagaran, kung mogamit daghang mga tindahan sa datos, ang usa niini molihok ingon panguna nga tindahan ug ang uban ingon mga gigikanan nga tindahan. Ang bugtong problema mao kung giunsa ang pag-synchronize sa kini nga mga tindahan sa datos.
Gitan-aw namon ang daghang lainlaing mga sumbanan nga misulay sa pagsulbad sa problema sa pag-synchronize sa daghang mga tindahan, sama sa doble nga pagsulat, gipang-apod-apod nga mga transaksyon, ug uban pa. Bisan pa, kini nga mga pamaagi adunay hinungdanon nga mga limitasyon sa termino sa tinuod nga kinabuhi nga paggamit, kasaligan, ug pagpadayon. Gawas pa sa pag-synchronize sa datos, ang ubang mga aplikasyon kinahanglan usab nga magpauswag sa datos pinaagi sa pagtawag sa mga serbisyo sa gawas.
Ang Delta gihimo aron masulbad kini nga mga problema. Ang Delta sa katapusan naghatag usa ka makanunayon, gipatuyok sa panghitabo nga plataporma alang sa pag-synchronize sa datos ug pagpauswag.
Anaa nga mga solusyon
Duha ka entry
Aron mapadayon ang pag-sync sa duha ka mga tindahan sa datos, mahimo nimong gamiton ang doble nga pagsulat, nga nagsulat sa usa ka tindahan ug dayon nagsulat sa lain pagkahuman dayon. Ang una nga pagrekord mahimong sulayan pag-usab ug ang ikaduha mahimong ma-abort kung ang una mapakyas pagkahuman sa gidaghanon sa mga pagsulay nga nahurot. Bisan pa, ang duha nga mga tindahan sa datos mahimong dili ma-sync kung mapakyas ang pagsulat sa ikaduha nga tindahan. Kini nga problema kasagarang masulbad pinaagi sa pagmugna og pamaagi sa pagbawi nga matag karon ug unya makabalhin pag-usab sa datos gikan sa unang storage ngadto sa ikaduha, o buhaton lamang kini kung ang mga kalainan makita sa datos.
Problema:
Ang paghimo sa pamaagi sa pagbawi usa ka piho nga trabaho nga dili magamit pag-usab. Dugang pa, ang datos tali sa mga lokasyon sa pagtipig nagpabilin nga wala ma-sync hangtod mahitabo ang pamaagi sa pag-uli. Ang solusyon mahimong mas komplikado kung labaw pa sa duha ka mga tindahan sa datos ang gigamit. Sa katapusan, ang pamaagi sa pagpasig-uli makadugang sa load sa orihinal nga tinubdan sa datos.
Usba ang talaan sa talaan
Kung ang mga pagbag-o mahitabo sa usa ka set sa mga lamesa (sama sa pagsal-ot, pag-update, ug pagtangtang sa usa ka rekord), ang mga rekord sa pagbag-o idugang sa talaan sa log ingon bahin sa parehas nga transaksyon. Ang laing hilo o proseso kanunay nga naghangyo sa mga panghitabo gikan sa talaan sa talaan ug gisulat kini ngadto sa usa o daghan pa nga mga tindahan sa datos, kon gikinahanglan, pagtangtang sa mga panghitabo gikan sa talaan sa talaan human ang rekord mapamatud-an sa tanang mga tindahan.
Problema:
Kini nga sumbanan kinahanglan ipatuman ingon usa ka librarya, ug labing maayo nga dili usbon ang code sa aplikasyon nga naggamit niini. Sa usa ka polyglot nga palibot, ang pagpatuman sa ingon nga librarya kinahanglan nga anaa sa bisan unsang gikinahanglan nga pinulongan, apan ang pagsiguro sa pagkamakanunayon sa pagpaandar ug pamatasan sa mga pinulongan lisud kaayo.
Ang laing problema anaa sa pagkuha sa mga pagbag-o sa schema sa mga sistema nga wala nagsuporta sa mga kausaban sa transactional schema [1][2], sama sa MySQL. Busa, ang sumbanan sa paghimo sa usa ka pagbag-o (pananglitan, usa ka pagbag-o sa eskema) ug ang transaksyon nga pagrekord niini sa lamesa sa pagbag-o sa log dili kanunay molihok.
Giapod-apod nga mga Transaksyon
Ang mga gipang-apod-apod nga mga transaksyon mahimong magamit sa pagbahin sa usa ka transaksyon sa daghang mga heterogenous nga mga tindahan sa datos aron ang operasyon mahimo nga gitugyan sa tanan nga mga tindahan sa datos nga gigamit, o wala gitugyan sa bisan kinsa niini.
Problema:
Ang gipang-apod-apod nga mga transaksyon usa ka dako kaayo nga problema alang sa heterogeneous nga mga tindahan sa datos. Pinaagi sa ilang kinaiya, sila makasalig lamang sa labing ubos nga komon nga denominador sa mga sistema nga nalambigit. Pananglitan, ang mga transaksyon sa XA nag-block sa pagpatuman kung ang proseso sa aplikasyon mapakyas sa yugto sa pagpangandam. Dugang pa, ang XA wala maghatag ug deadlock detection o pagsuporta sa malaumon nga concurrency control schemes. Dugang pa, ang ubang mga sistema sama sa ElasticSearch wala mosuporta sa XA o bisan unsang lain nga heterogenous nga modelo sa transaksyon. Sa ingon, ang pagsiguro sa pagsulat sa atomicity sa lainlaing mga teknolohiya sa pagtipig sa datos nagpabilin nga usa ka mahagiton nga buluhaton alang sa mga aplikasyon [3].
Delta
Gidisenyo ang Delta aron matubag ang mga limitasyon sa naglungtad nga mga solusyon sa pag-synchronize sa datos ug mahimo usab nga mapaayo ang datos nga on-the-fly. Ang among tumong mao ang pag-abstract niining tanan nga mga pagkakomplikado gikan sa mga nag-develop sa aplikasyon aron sila hingpit nga makatutok sa pagpatuman sa pagpaandar sa negosyo. Sunod among ihulagway ang "Pagpangita sa Pelikula", ang aktwal nga kaso sa paggamit alang sa Delta sa Netflix.
Ang Netflix kaylap nga naggamit sa usa ka microservice nga arkitektura, ug ang matag microservice kasagaran nagsilbi usa ka matang sa datos. Ang sukaranang impormasyon bahin sa salida anaa sa usa ka microservice nga gitawag og Movie Service, ug ang mga kaubang datos sama sa impormasyon bahin sa mga prodyuser, aktor, vendor, ug uban pa gidumala sa daghang ubang microservices (nga mao ang Deal Service, Talent Service ug Vendor Service).
Ang mga tiggamit sa negosyo sa Netflix Studios kanunay kinahanglan nga mangita sa lainlaing mga pamatasan sa sine, mao nga hinungdanon kaayo alang kanila nga makapangita sa tanan nga datos nga may kalabotan sa sine.
Sa wala pa ang Delta, ang tim sa pagpangita sa salida kinahanglan nga mokuha sa datos gikan sa daghang mga microservice sa dili pa i-index ang datos sa salida. Dugang pa, ang team kinahanglan nga maghimo usa ka sistema nga matag karon ug unya mag-update sa indeks sa pagpangita pinaagi sa paghangyo sa mga pagbag-o gikan sa ubang mga microservice, bisan kung walaβy mga pagbag-o. Kini nga sistema dali nga nahimong komplikado ug lisud nga mapadayon.
Figure 1. Sistema sa pagboto ngadto sa Delta
Human sa paggamit sa Delta, ang sistema gipasayon ββngadto sa usa ka event driven system sama sa gipakita sa mosunod nga numero. Ang mga panghitabo sa CDC (Change-Data-Capture) gipadala sa mga hilisgutan sa Keystone Kafka gamit ang Delta-Connector. Usa ka aplikasyon sa Delta nga gitukod gamit ang Delta Stream Processing Framework (base sa Flink) nakadawat sa mga panghitabo sa CDC gikan sa usa ka hilisgutan, nagpadato kanila pinaagi sa pagtawag sa ubang mga microservice, ug sa katapusan gipasa ang gipadato nga datos sa usa ka indeks sa pagpangita sa Elasticsearch. Ang tibuuk nga proseso mahitabo hapit sa tinuud nga oras, nga mao, sa diha nga ang mga pagbag-o nahimo sa bodega sa datos, ang mga indeks sa pagpangita gi-update.
Figure 2. Data pipeline gamit ang Delta
Sa mosunud nga mga seksyon, among ihulagway ang operasyon sa Delta-Connector, nga nagkonektar sa pagtipig ug nagpatik sa mga panghitabo sa CDC sa layer sa transportasyon, nga usa ka real-time nga imprastraktura sa pagpadala sa datos nga nag-ruta sa mga panghitabo sa CDC sa mga hilisgutan sa Kafka. Ug sa katapusan, maghisgot kami bahin sa Delta stream processing framework, nga magamit sa mga developer sa aplikasyon alang sa pagproseso sa datos ug lohika sa pagpauswag.
CDC (Pagbag-o-Data-Pagkuha)
Naghimo kami usa ka serbisyo sa CDC nga gitawag Delta-Connector, nga makakuha mga nahimo nga pagbag-o gikan sa data store sa tinuud nga oras ug isulat kini sa usa ka sapa. Ang mga pagbag-o sa tinuud nga oras gikuha gikan sa log sa transaksyon ug mga dump sa pagtipig. Ang mga dump gigamit tungod kay ang mga log sa transaksyon kasagaran dili magtipig sa tibuok kasaysayan sa mga kausaban. Ang mga pagbag-o kasagarang gi-serialize isip mga panghitabo sa Delta, mao nga ang nakadawat dili kinahanglan mabalaka kung diin gikan ang pagbag-o.
Gisuportahan sa Delta-Connector ang daghang dugang nga mga bahin sama sa:
- Abilidad sa pagsulat sa custom output data sa miaging Kafka.
- Abilidad sa pagpaaktibo sa mga manwal nga dump sa bisan unsang oras alang sa tanan nga mga lamesa, usa ka piho nga lamesa, o alang sa piho nga panguna nga mga yawe.
- Ang mga dump mahimong makuha sa mga tipak, mao nga dili na kinahanglan nga magsugod pag-usab kung adunay kapakyasan.
- Dili kinahanglan nga ibutang ang mga kandado sa mga lamesa, nga hinungdanon kaayo aron masiguro nga ang trapiko sa pagsulat sa database dili gyud mapugngan sa among serbisyo.
- Taas nga magamit tungod sa kadaghan nga mga higayon sa AWS Availability Zones.
Gisuportahan namon karon ang MySQL ug Postgres, lakip ang mga pag-deploy sa AWS RDS ug Aurora. Gisuportahan usab namo si Cassandra (multi-master). Mahibal-an nimo ang dugang nga mga detalye bahin sa Delta-Connector dinhi .
Kafka ug ang transport layer
Ang layer sa transportasyon sa panghitabo sa Delta gitukod sa serbisyo sa pagmemensahe sa platform .
Sa kasaysayan, ang pag-post sa Netflix na-optimize para sa accessibility kaysa taas nga kinabuhi (tan-awa sa ubos). ). Ang trade-off mao ang potensyal nga pagkasumpaki sa datos sa broker sa lainlaing mga senaryo sa sulud. Pananglitan, hugaw nga pagpili sa lider mao ang responsable alang sa nakadawat nga posibleng adunay doble o nawala nga mga panghitabo.
Uban sa Delta, gusto namon ang labi ka lig-on nga garantiya sa kalig-on aron masiguro ang paghatud sa mga panghitabo sa CDC sa mga nakuha nga tindahan. Alang niini nga katuyoan, among gisugyot ang usa ka espesyal nga gidisenyo nga cluster sa Kafka ingon usa ka butang nga una nga klase. Mahimo nimong tan-awon ang pipila ka mga setting sa broker sa lamesa sa ubos:
Sa Keystone Kafka clusters, hugaw nga pagpili sa lider kasagarang gilakip aron maseguro ang accessibility sa publisher. Mahimong moresulta kini sa pagkawala sa mensahe kung ang usa ka dili ma-synchronize nga replika ang mapili isip lider. Alang sa usa ka bag-ong high availability nga Kafka cluster, ang kapilian hugaw nga pagpili sa lider gipalong aron malikayan ang pagkawala sa mensahe.
Nadugangan sab mi replikasyon nga hinungdan gikan sa 2 hangtod 3 ug minimum nga insync nga mga replika 1 hangtod 2. Ang mga publisher nga nagsulat niini nga cluster nanginahanglan og acks gikan sa tanan nga uban pa, pagsiguro nga 2 sa 3 nga mga replika ang adunay pinakabag-o nga mga mensahe nga gipadala sa magmamantala.
Kung ang usa ka pananglitan sa broker matapos, usa ka bag-ong instance ang mopuli sa daan. Bisan pa, ang bag-ong broker kinahanglan nga makaapas sa mga unsynchronized nga mga replika, nga mahimoβg magdugay daghang oras. Aron makunhuran ang oras sa pagbawi alang niini nga senaryo, nagsugod kami sa paggamit sa block data storage (Amazon Elastic Block Store) imbes sa mga lokal nga broker disk. Kung ang usa ka bag-ong instance nag-ilis sa usa ka gi-terminate nga instance sa broker, gilakip niini ang volume sa EBS nga naa sa natapos nga instance ug nagsugod sa pagkuha sa mga bag-ong mensahe. Kini nga proseso makapamenos sa oras sa clearance sa backlog gikan sa mga oras ngadto sa mga minuto tungod kay ang bag-ong instance dili na kinahanglan nga kopyahon gikan sa usa ka walay sulod nga kahimtang. Sa kinatibuk-an, ang bulag nga pagtipig ug mga siklo sa kinabuhi sa broker labi nga nagpamenos sa epekto sa pagbalhin sa broker.
Aron madugangan pa ang garantiya sa paghatud sa datos, among gigamit aron mahibal-an ang bisan unsang pagkawala sa mensahe sa ilawom sa grabe nga mga kahimtang (pananglitan, desynchronization sa orasan sa lider sa partisyon).
Framework sa Pagproseso sa Stream
Ang layer sa pagproseso sa Delta gitukod sa ibabaw sa plataporma sa Netflix SPaaS, nga naghatag sa Apache Flink nga integrasyon sa Netflix ecosystem. Ang plataporma naghatag ug user interface nga nagdumala sa deployment sa mga trabaho sa Flink ug orkestra sa Flink clusters sa ibabaw sa among Titus container management platform. Ang interface nagdumala usab sa mga pag-configure sa trabaho ug nagtugot sa mga tiggamit sa paghimo sa mga pagbag-o sa pag-configure nga dinamikong dili kinahanglan nga i-compile ang mga trabaho sa Flink.
Naghatag ang Delta og stream processing framework base sa Flink ug SPaaS nga naggamit gibase sa anotasyon DSL (Domain Specific Language) sa abstract teknikal nga mga detalye. Pananglitan, aron mahibal-an ang lakang kung diin ang mga panghitabo mapauswag pinaagi sa pagtawag sa mga serbisyo sa gawas, ang mga tiggamit kinahanglan nga isulat ang mosunud nga DSL, ug ang balangkas maghimo usa ka modelo nga gibase niini, nga ipatuman sa Flink.
Figure 3. Pananglitan sa pagpalambo sa DSL sa Delta
Ang balangkas sa pagproseso dili lamang makapakunhod sa kurba sa pagkat-on, apan naghatag usab sa kasagarang mga bahin sa pagproseso sa sapa sama sa deduplication, schematization, ug pagka-flexible ug kalig-on aron masulbad ang kasagarang mga problema sa operasyon.
Ang Delta Stream Processing Framework naglangkob sa duha ka yawe nga modules, ang DSL & API module ug ang Runtime module. Ang DSL & API module naghatag DSL ug UDF (User-Defined-Function) API aron ang mga tiggamit makasulat sa ilang kaugalingong pagproseso nga lohika (sama sa pagsala o pagbag-o). Ang Runtime module naghatag ug pagpatuman sa usa ka DSL parser nga nagtukod ug internal nga representasyon sa mga lakang sa pagproseso sa DAG nga mga modelo. Ang Execution component naghubad sa mga modelo sa DAG aron masugdan ang aktuwal nga mga pahayag sa Flink ug sa katapusan modagan ang Flink application. Ang arkitektura sa framework gihulagway sa mosunod nga numero.
Figure 4. Delta Stream Processing Framework nga arkitektura
Kini nga pamaagi adunay daghang mga bentaha:
- Ang mga tiggamit mahimong mag-focus sa ilang lohika sa negosyo nga dili kinahanglan nga magsusi sa mga detalye sa Flink o sa istruktura sa SPaaS.
- Ang pag-optimize mahimo sa paagi nga transparent sa mga tiggamit, ug ang mga sayup mahimong ayohon nga wala magkinahanglan bisan unsang mga pagbag-o sa code sa gumagamit (UDF).
- Ang kasinatian sa aplikasyon sa Delta gipasayon ββββalang sa mga tiggamit tungod kay ang plataporma naghatag og pagka-flexible ug kalig-on sa gawas sa kahon ug nagkolekta sa nagkalain-laing mga detalyado nga sukatan nga magamit alang sa mga alerto.
Paggamit sa produksiyon
Ang Delta naa sa produksiyon sa sobra sa usa ka tuig ug adunay hinungdanon nga papel sa daghang mga aplikasyon sa Netflix Studio. Gitabangan niya ang mga team sa pagpatuman sa mga kaso sa paggamit sama sa pag-indeks sa pagpangita, pagtipig sa datos, ug mga daloy sa trabaho nga gipadagan sa panghitabo. Sa ubos usa ka kinatibuk-ang pagtan-aw sa taas nga lebel nga arkitektura sa plataporma sa Delta.
Figure 5. Ang taas nga lebel nga arkitektura sa Delta.
Mga Pasalamat
Gusto namong pasalamatan ang mosunod nga mga tawo nga nalambigit sa paghimo ug pagpalambo sa 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 ug Zhenzhong Xu.
Mga tinubdan
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Pagproseso sa online nga panghitabo. Komun. ACM 62(5): 43β49 (2019). DOI:
: βData Build Tool para sa Amazon Redshift Storage.β
Source: www.habr.com