V očakávaní spustenia nového toku v sadzbe Pripravili sme preklad zaujímavého materiálu.
Recenzia
Budeme hovoriť o pomerne populárnom vzore, podľa ktorého aplikácie využívajú viacero dátových úložísk, pričom každý obchod sa používa na svoje vlastné účely, napríklad na ukladanie kanonickej formy dát (MySQL atď.), poskytujú pokročilé možnosti vyhľadávania (ElasticSearch, atď.) .), ukladanie do vyrovnávacej pamäte (Memcached atď.) a iné. Pri použití viacerých dátových úložísk zvyčajne jeden z nich funguje ako primárny úložný priestor a ostatné ako odvodené úložiská. Jediným problémom je, ako tieto dátové úložiská synchronizovať.
Pozreli sme sa na množstvo rôznych vzorov, ktoré sa snažili vyriešiť problém synchronizácie viacerých obchodov, ako sú dvojité zápisy, distribuované transakcie atď. Tieto prístupy však majú značné obmedzenia z hľadiska používania v reálnom živote, spoľahlivosti a údržby. Niektoré aplikácie potrebujú okrem synchronizácie dát aj obohacovať dáta volaním externých služieb.
Delta bola vyvinutá na riešenie týchto problémov. Delta v konečnom dôsledku poskytuje konzistentnú platformu riadenú udalosťami na synchronizáciu a obohatenie údajov.
Existujúce riešenia
Dvojitý vstup
Ak chcete zachovať synchronizáciu dvoch dátových úložísk, môžete použiť duálny zápis, ktorý zapíše do jedného úložiska a hneď potom zapíše do druhého. Prvé nahrávanie možno zopakovať a druhé možno prerušiť, ak prvé zlyhá po vyčerpaní počtu pokusov. Ak však zápis do druhého úložiska zlyhá, môžu sa tieto dva úložiská údajov nesynchronizovať. Tento problém sa zvyčajne rieši vytvorením procedúry obnovy, ktorá môže pravidelne prenášať údaje z prvého úložiska do druhého, alebo tak urobiť iba vtedy, ak sa v údajoch zistia rozdiely.
problémy:
Vykonanie procedúry obnovy je špecifická úloha, ktorú nemožno znova použiť. Okrem toho údaje medzi miestami uloženia zostávajú nesynchronizované, kým sa neuskutoční procedúra obnovy. Riešenie sa stáva zložitejším, ak sa používajú viac ako dva dátové úložiská. Nakoniec môže procedúra obnovy pridať zaťaženie pôvodného zdroja údajov.
Zmeniť tabuľku denníka
Keď sa v skupine tabuliek vyskytnú zmeny (ako je vloženie, aktualizácia a vymazanie záznamu), záznamy zmien sa pridajú do protokolovej tabuľky ako súčasť tej istej transakcie. Iné vlákno alebo proces neustále požaduje udalosti z tabuľky protokolu a zapisuje ich do jedného alebo viacerých dátových skladov, ak je to potrebné, odstraňuje udalosti z tabuľky denníka po potvrdení záznamu všetkými skladmi.
problémy:
Tento vzor by mal byť implementovaný ako knižnica a ideálne bez zmeny kódu aplikácie, ktorá ho používa. V prostredí polyglot by implementácia takejto knižnice mala existovať v akomkoľvek potrebnom jazyku, ale zabezpečiť konzistentnosť funkčnosti a správania medzi jazykmi je veľmi ťažké.
Ďalší problém spočíva v získavaní zmien schém v systémoch, ktoré nepodporujú zmeny transakčných schém [1][2], ako napríklad MySQL. Preto vzor vykonania zmeny (napríklad zmeny schémy) a jej transakčného zaznamenávania do tabuľky protokolu zmien nebude vždy fungovať.
Distribuované transakcie
Distribuované transakcie možno použiť na rozdelenie transakcie medzi viacero heterogénnych dátových skladov, takže operácia je buď potvrdená všetkým použitým dátovým skladom, alebo nie je potvrdená žiadnemu z nich.
problémy:
Distribuované transakcie sú veľmi veľkým problémom pre heterogénne dátové úložiská. Svojou povahou sa môžu spoľahnúť len na najnižšieho spoločného menovateľa zapojených systémov. Napríklad transakcie XA blokujú spustenie, ak proces aplikácie zlyhá počas prípravnej fázy. Okrem toho XA neposkytuje detekciu uviaznutia ani nepodporuje optimistické schémy kontroly súbežnosti. Okrem toho niektoré systémy ako ElasticSearch nepodporujú XA ani žiadny iný heterogénny transakčný model. Zaistenie atomicity zápisu v rôznych technológiách ukladania údajov teda zostáva pre aplikácie veľmi náročnou úlohou [3].
delta
Delta bola navrhnutá tak, aby riešila obmedzenia existujúcich riešení synchronizácie údajov a tiež umožňuje obohacovanie údajov za chodu. Naším cieľom bolo abstrahovať všetky tieto zložitosti od vývojárov aplikácií, aby sa mohli plne sústrediť na implementáciu podnikových funkcií. Ďalej popíšeme „Vyhľadávanie filmov“, skutočný prípad použitia Delta od Netflixu.
Netflix široko používa architektúru mikroslužieb a každá mikroslužba zvyčajne poskytuje jeden typ údajov. Základné informácie o filme sú obsiahnuté v mikroslužbe s názvom Filmová služba a súvisiace údaje, ako sú informácie o producentoch, hercoch, dodávateľoch atď., spravuje niekoľko ďalších mikroslužieb (konkrétne Deal Service, Talent Service a Vendor Service).
Firemní používatelia v Netflix Studios často potrebujú vyhľadávať v rôznych filmových kritériách, a preto je pre nich veľmi dôležité, aby mohli vyhľadávať vo všetkých údajoch súvisiacich s filmom.
Pred Deltou potreboval tím na vyhľadávanie filmov získať údaje z viacerých mikroslužieb pred indexovaním údajov o filme. Okrem toho musel tím vyvinúť systém, ktorý by pravidelne aktualizoval index vyhľadávania vyžiadaním zmien od iných mikroslužieb, aj keď k žiadnym zmenám nedošlo. Tento systém sa rýchlo stal zložitým a ťažko udržiavateľný.
Obrázok 1. Systém hlasovania do Delty
Po použití Delta bol systém zjednodušený na systém riadený udalosťami, ako je znázornené na nasledujúcom obrázku. Udalosti CDC (Change-Data-Capture) sa odosielajú do tém Keystone Kafka pomocou Delta-Connector. Aplikácia Delta postavená pomocou Delta Stream Processing Framework (založená na Flink) prijíma udalosti CDC z témy, obohacuje ich volaním iných mikroslužieb a nakoniec odovzdáva obohatené údaje do indexu vyhľadávania v Elasticsearch. Celý proces prebieha takmer v reálnom čase, to znamená, že hneď ako sa zmeny zavedú do dátového skladu, indexy vyhľadávania sa aktualizujú.
Obrázok 2. Dátový kanál pomocou Delta
V nasledujúcich častiach popíšeme fungovanie Delta-Connector, ktorý sa pripája k úložisku a publikuje udalosti CDC do transportnej vrstvy, čo je infraštruktúra prenosu dát v reálnom čase, ktorá smeruje udalosti CDC ku Kafkovým témam. A úplne na záver si povieme niečo o rámci Delta stream processing framework, ktorý môžu vývojári aplikácií využiť na spracovanie dát a logiku obohacovania.
CDC (Change-Data-Capture)
Vyvinuli sme službu CDC s názvom Delta-Connector, ktorá dokáže zachytiť potvrdené zmeny z úložiska údajov v reálnom čase a zapísať ich do streamu. Zmeny v reálnom čase sa preberajú z protokolu transakcií a výpisov z pamäte. Výpisy sa používajú, pretože protokoly transakcií zvyčajne neukladajú celú históriu zmien. Zmeny sú zvyčajne serializované ako udalosti Delta, takže príjemca sa nemusí starať o to, odkiaľ zmena pochádza.
Delta-Connector podporuje niekoľko ďalších funkcií, ako napríklad:
- Schopnosť písať vlastné výstupné dáta pomocou Kafka.
- Možnosť kedykoľvek aktivovať manuálne výpisy pre všetky tabuľky, konkrétnu tabuľku alebo pre konkrétne primárne kľúče.
- Skládky je možné získať po kúskoch, takže v prípade zlyhania nie je potrebné začínať odznova.
- Nie je potrebné umiestňovať zámky na tabuľky, čo je veľmi dôležité, aby sa zabezpečilo, že prevádzka zápisu do databázy nebude nikdy blokovaná našou službou.
- Vysoká dostupnosť vďaka redundantným inštanciám v zónach dostupnosti AWS.
V súčasnosti podporujeme MySQL a Postgres, vrátane nasadení na AWS RDS a Aurora. Podporujeme aj Cassandru (multi-master). Viac podrobností o Delta-Connector nájdete tu .
Kafka a transportná vrstva
Vrstva prenosu udalostí spoločnosti Delta je postavená na službe zasielania správ platformy .
Historicky bolo uverejňovanie na Netflixe optimalizované skôr pre dostupnosť ako pre dlhovekosť (pozri nižšie). ). Kompromisom bola potenciálna nekonzistentnosť údajov makléra v rôznych okrajových scenároch. Napríklad, nečisté voľby vodcu je zodpovedný za to, že príjemca môže mať duplicitné alebo stratené udalosti.
S Deltou sme chceli silnejšie záruky trvanlivosti, aby sme zabezpečili doručenie udalostí CDC do odvodených obchodov. Na tento účel sme navrhli špeciálne navrhnutý Kafkov klaster ako prvotriedny objekt. Niektoré nastavenia brokera si môžete pozrieť v tabuľke nižšie:
V klastroch Keystone Kafka, nečisté voľby vodcu zvyčajne zahrnuté, aby sa zabezpečila dostupnosť vydavateľa. To môže viesť k strate správy, ak je ako vedúca zvolená nesynchronizovaná replika. Pre nový klaster Kafka s vysokou dostupnosťou je táto možnosť nečisté voľby vodcu vypnuté, aby sa zabránilo strate správy.
Tiež sme zvýšili replikačný faktor od 2 do 3 a minimálne nesynchronizované repliky 1 až 2. Vydavatelia, ktorí píšu do tohto klastra, vyžadujú potvrdenia od všetkých ostatných, čím sa zabezpečí, že 2 z 3 replík majú najaktuálnejšie správy odoslané vydavateľom.
Keď inštancia makléra skončí, nová inštancia nahradí starú. Nový maklér však bude musieť dobehnúť nesynchronizované repliky, čo môže trvať niekoľko hodín. Aby sme skrátili čas obnovy pre tento scenár, začali sme používať blokové ukladanie údajov (Amazon Elastic Block Store) namiesto diskov miestnych brokerov. Keď nová inštancia nahradí ukončenú inštanciu sprostredkovateľa, pripojí zväzok EBS, ktorý mala ukončená inštancia, a začne doháňať nové správy. Tento proces skracuje čas likvidácie nevybavených vecí z hodín na minúty, pretože nová inštancia sa už nemusí replikovať z prázdneho stavu. Oddelené úložisko a životné cykly makléra celkovo výrazne znižujú vplyv zmeny makléra.
Na ďalšie zvýšenie záruky doručenia údajov sme použili na zistenie akejkoľvek straty správy v extrémnych podmienkach (napríklad desynchronizácia hodín vo vedúcej časti oddielu).
Stream Processing Framework
Spracovateľská vrstva Delta je postavená na platforme Netflix SPaaS, ktorá poskytuje integráciu Apache Flink s ekosystémom Netflix. Platforma poskytuje používateľské rozhranie, ktoré riadi nasadenie úloh Flink a orchestráciu klastrov Flink na vrchole našej platformy na správu kontajnerov Titus. Rozhranie tiež spravuje konfigurácie úloh a umožňuje používateľom vykonávať zmeny konfigurácie dynamicky bez toho, aby museli znova kompilovať úlohy Flink.
Delta poskytuje rámec na spracovanie toku založený na Flink a SPaaS, ktorý používa na základe anotácie DSL (Domain Specific Language) na abstraktné technické detaily. Napríklad na definovanie kroku, v ktorom budú udalosti obohatené o volanie externých služieb, musia používatelia napísať nasledujúce DSL a framework na základe neho vytvorí model, ktorý vykoná Flink.
Obrázok 3. Príklad obohatenia na DSL v Delte
Rámec spracovania nielen znižuje krivku učenia, ale poskytuje aj bežné funkcie spracovania toku, ako je deduplikácia, schematizácia a flexibilita a odolnosť na riešenie bežných prevádzkových problémov.
Delta Stream Processing Framework pozostáva z dvoch kľúčových modulov, modulu DSL & API a modulu Runtime. Modul DSL & API poskytuje DSL a UDF (User-Defined-Function) API, takže používatelia môžu písať svoju vlastnú logiku spracovania (ako je filtrovanie alebo transformácie). Modul Runtime poskytuje implementáciu analyzátora DSL, ktorý vytvára internú reprezentáciu krokov spracovania v modeloch DAG. Komponent Execution interpretuje modely DAG tak, aby inicializoval skutočné príkazy Flink a nakoniec spustil aplikáciu Flink. Architektúra rámca je znázornená na nasledujúcom obrázku.
Obrázok 4. Architektúra Delta Stream Processing Framework
Tento prístup má niekoľko výhod:
- Používatelia sa môžu sústrediť na svoju obchodnú logiku bez toho, aby sa museli ponoriť do špecifík Flink alebo štruktúry SPaaS.
- Optimalizáciu je možné vykonať spôsobom, ktorý je pre používateľov transparentný, a chyby možno opraviť bez toho, aby bolo potrebné meniť používateľský kód (UDF).
- Aplikácia Delta je pre používateľov zjednodušená, pretože platforma poskytuje flexibilitu a odolnosť hneď po vybalení a zhromažďuje množstvo podrobných metrík, ktoré možno použiť na upozornenia.
Výrobné využitie
Delta sa vyrába už viac ako rok a hrá kľúčovú úlohu v mnohých aplikáciách Netflix Studio. Pomohla tímom implementovať prípady použitia, ako je indexovanie vyhľadávania, ukladanie údajov a pracovné postupy riadené udalosťami. Nižšie je uvedený prehľad architektúry na vysokej úrovni platformy Delta.
Obrázok 5. Architektúra vysokej úrovne spoločnosti Delta.
Poďakovanie
Radi by sme poďakovali nasledujúcim ľuďom, ktorí sa podieľali na vytvorení a vývoji Delta v Netflixe: 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.
zdroje
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online spracovanie udalostí. komun. ACM 62 (5): 43 – 49 (2019). DOI:
: "Nástroj na vytváranie údajov pre úložisko Amazon Redshift."
Zdroj: hab.com