V očekávání spuštění nového toku v sazbě Připravili jsme překlad zajímavého materiálu.
Recenze
Budeme mluvit o poměrně oblíbeném vzoru, podle kterého aplikace využívají více datových úložišť, kde každé úložiště slouží pro své vlastní účely, například k ukládání kanonické formy dat (MySQL atd.), poskytují pokročilé možnosti vyhledávání (ElasticSearch, atd.) .), ukládání do mezipaměti (Memcached atd.) a další. Při použití více datových úložišť obvykle jedno z nich funguje jako primární úložiště a ostatní jako odvozené úložiště. Jediným problémem je, jak tato úložiště dat synchronizovat.
Podívali jsme se na řadu různých vzorů, které se pokusily vyřešit problém synchronizace více obchodů, jako jsou dvojité zápisy, distribuované transakce atd. Tyto přístupy však mají významná omezení, pokud jde o reálné použití, spolehlivost a údržbu. Některé aplikace potřebují kromě synchronizace dat také obohacovat data voláním externích služeb.
Delta byla vyvinuta k vyřešení těchto problémů. Delta v konečném důsledku poskytuje konzistentní platformu řízenou událostmi pro synchronizaci a obohacování dat.
Stávající řešení
Dvojitý vstup
Chcete-li zachovat synchronizaci dvou datových úložišť, můžete použít duální zápis, který zapisuje do jednoho úložiště a poté ihned zapisuje do druhého. První nahrávání lze opakovat a druhé lze přerušit, pokud první selže po vyčerpání počtu pokusů. Pokud však zápis do druhého úložiště selže, mohou se tato dvě úložiště dat nesynchronizovat. Tento problém se obvykle řeší vytvořením procedury obnovy, která může periodicky znovu přenášet data z prvního úložiště do druhého, nebo tak učinit pouze v případě, že jsou v datech zjištěny rozdíly.
Problémy jsou:
Provedení procedury obnovy je specifická úloha, kterou nelze znovu použít. Data mezi umístěními úložiště navíc zůstávají nesynchronizovaná, dokud neproběhne procedura obnovy. Řešení se stává složitějším, pokud se používají více než dvě datová úložiště. Nakonec může procedura obnovy přidat zatížení do původního zdroje dat.
Změna tabulky protokolu
Když dojde ke změnám v sadě tabulek (jako je vložení, aktualizace a odstranění záznamu), jsou záznamy změn přidány do tabulky protokolu jako součást stejné transakce. Jiné vlákno nebo proces neustále požaduje události z tabulky protokolů a zapisuje je do jednoho nebo více datových úložišť, v případě potřeby odebírá události z tabulky protokolu poté, co byl záznam potvrzen všemi úložištěmi.
Problémy jsou:
Tento vzor by měl být implementován jako knihovna a ideálně beze změny kódu aplikace, která jej používá. V prostředí polyglot by implementace takové knihovny měla existovat v jakémkoli potřebném jazyce, ale zajistit konzistenci funkčnosti a chování napříč jazyky je velmi obtížné.
Další problém spočívá v získávání změn schématu v systémech, které nepodporují změny transakčního schématu [1][2], jako je MySQL. Proto vzor provedení změny (například změny schématu) a transakčního záznamu do tabulky protokolu změn nebude vždy fungovat.
Distribuované transakce
Distribuované transakce lze použít k rozdělení transakce mezi více heterogenních datových úložišť, takže operace je buď potvrzena všem použitým datovým úložištím, nebo nebude potvrzena žádnému z nich.
Problémy jsou:
Distribuované transakce jsou velmi velkým problémem pro heterogenní úložiště dat. Ze své podstaty se mohou spolehnout pouze na nejmenšího společného jmenovatele zúčastněných systémů. Například transakce XA zablokují provádění, pokud proces aplikace selže během přípravné fáze. XA navíc neposkytuje detekci uváznutí ani nepodporuje optimistická schémata řízení souběžnosti. Některé systémy jako ElasticSearch navíc nepodporují XA ani jiný heterogenní transakční model. Zajištění atomicity zápisu v různých technologiích ukládání dat tedy zůstává pro aplikace velmi náročným úkolem [3].
Delta
Delta byla navržena tak, aby řešila omezení stávajících řešení synchronizace dat a také umožnila obohacování dat za běhu. Naším cílem bylo abstrahovat všechny tyto složitosti od vývojářů aplikací, aby se mohli plně soustředit na implementaci podnikových funkcí. Dále popíšeme „Vyhledávání filmů“, skutečný případ použití Delta od Netflixu.
Netflix široce používá architekturu mikroslužeb a každá mikroslužba obvykle obsluhuje jeden typ dat. Základní informace o filmu jsou obsaženy v mikroslužbě zvané Movie Service a související data, jako jsou informace o producentech, hercích, prodejcích a tak dále, jsou spravována několika dalšími mikroslužbami (jmenovitě Deal Service, Talent Service a Vendor Service).
Firemní uživatelé v Netflix Studios často potřebují prohledávat různá filmová kritéria, a proto je pro ně velmi důležité, aby mohli vyhledávat ve všech datech souvisejících s filmy.
Před Deltou potřeboval tým pro vyhledávání filmů získat data z několika mikroslužeb před indexováním dat filmu. Kromě toho musel tým vyvinout systém, který by periodicky aktualizoval vyhledávací index vyžádáním změn od jiných mikroslužeb, i když k žádným změnám vůbec nedošlo. Tento systém se rychle stal složitým a obtížně udržovatelný.
Obrázek 1. Systém dotazování na Delta
Po použití Delta byl systém zjednodušen na systém řízený událostmi, jak je znázorněno na následujícím obrázku. Události CDC (Change-Data-Capture) jsou odesílány do témat Keystone Kafka pomocí Delta-Connector. Aplikace Delta vytvořená pomocí rozhraní Delta Stream Processing Framework (založené na Flinku) přijímá události CDC z tématu, obohacuje je voláním dalších mikroslužeb a nakonec předává obohacená data do vyhledávacího indexu v Elasticsearch. Celý proces probíhá téměř v reálném čase, to znamená, že jakmile jsou změny přijaty do datového skladu, indexy vyhledávání se aktualizují.
Obrázek 2. Datový kanál pomocí Delta
V následujících částech popíšeme fungování Delta-Connector, který se připojuje k úložišti a publikuje události CDC do transportní vrstvy, což je infrastruktura přenosu dat v reálném čase, která směruje události CDC ke Kafkovým tématům. A úplně na závěr si povíme o frameworku Delta stream processing framework, který mohou vývojáři aplikací využít pro zpracování dat a logiku obohacování.
CDC (Change-Data-Capture)
Vyvinuli jsme službu CDC s názvem Delta-Connector, která dokáže zachytit potvrzené změny z úložiště dat v reálném čase a zapsat je do streamu. Změny v reálném čase jsou převzaty z protokolu transakcí a výpisů úložiště. Výpisy se používají, protože protokoly transakcí obvykle neukládají celou historii změn. Změny jsou obvykle serializovány jako události Delta, takže se příjemce nemusí starat o to, odkud změna pochází.
Delta-Connector podporuje několik dalších funkcí, jako jsou:
- Schopnost psát vlastní výstupní data mimo Kafka.
- Možnost kdykoli aktivovat ruční výpisy pro všechny tabulky, konkrétní tabulku nebo pro konkrétní primární klíče.
- Výsypky lze načíst po kouscích, takže v případě selhání není třeba začínat znovu.
- Není třeba umisťovat zámky na tabulky, což je velmi důležité pro zajištění toho, že provoz zápisu do databáze nebude naší službou nikdy blokován.
- Vysoká dostupnost díky redundantním instancím v zónách dostupnosti AWS.
V současné době podporujeme MySQL a Postgres, včetně nasazení na AWS RDS a Aurora. Podporujeme také Cassandru (multimaster). Více podrobností o Delta-Connector najdete zde .
Kafka a transportní vrstva
Vrstva přenosu událostí společnosti Delta je postavena na službě zasílání zpráv platformy .
Historicky bylo zveřejňování příspěvků na Netflixu optimalizováno spíše pro dostupnost než pro dlouhou životnost (viz níže). ). Kompromisem byla potenciální nekonzistence údajů makléřů v různých okrajových scénářích. Například, nečisté volby vůdce je odpovědný za to, že příjemce může mít duplicitní nebo ztracené události.
U společnosti Delta jsme chtěli silnější záruky trvanlivosti, abychom zajistili doručení událostí CDC do odvozených obchodů. Pro tento účel jsme jako prvotřídní objekt navrhli speciálně navržený Kafkův cluster. Na některá nastavení brokera se můžete podívat v tabulce níže:
Ve shlucích Keystone Kafka, nečisté volby vůdce obvykle součástí, aby byla zajištěna dostupnost pro vydavatele. To může vést ke ztrátě zprávy, pokud je jako vedoucí zvolena nesynchronizovaná replika. Pro nový cluster Kafka s vysokou dostupností možnost nečisté volby vůdce vypnuto, aby nedošlo ke ztrátě zpráv.
Také jsme zvýšili replikační faktor od 2 do 3 a minimální nesynchronizované repliky 1 až 2. Vydavatelé píšící do tohoto clusteru vyžadují potvrzení od všech ostatních, což zajišťuje, že 2 ze 3 replik mají nejaktuálnější zprávy odeslané vydavatelem.
Když instance zprostředkovatele skončí, nová instance nahradí starou. Nový broker však bude muset dohnat nesynchronizované repliky, což může trvat několik hodin. Abychom u tohoto scénáře zkrátili dobu obnovy, začali jsme místo disků místních brokerů používat blokové úložiště dat (Amazon Elastic Block Store). Když nová instance nahradí ukončenou instanci zprostředkovatele, připojí svazek EBS, který měla ukončená instance, a začne dohánět nové zprávy. Tento proces zkracuje dobu likvidace nevyřízených položek z hodin na minuty, protože nová instance se již nemusí replikovat z prázdného stavu. Obecně platí, že oddělené úložiště a životní cykly zprostředkovatele významně snižují dopad změny zprostředkovatele.
Pro další zvýšení garance doručení dat jsme použili k detekci jakékoli ztráty zprávy za extrémních podmínek (například desynchronizace hodin ve vedoucím oddílu).
Stream Processing Framework
Zpracovací vrstva Delta je postavena na platformě Netflix SPaaS, která zajišťuje integraci Apache Flink s ekosystémem Netflix. Platforma poskytuje uživatelské rozhraní, které spravuje nasazení úloh Flink a orchestraci clusterů Flink nad naší platformou pro správu kontejnerů Titus. Rozhraní také spravuje konfigurace úloh a umožňuje uživatelům provádět změny konfigurace dynamicky, aniž by museli znovu kompilovat úlohy Flink.
Delta poskytuje rámec pro zpracování streamů založený na Flink a SPaaS, který používá na základě anotace DSL (Domain Specific Language) k abstraktním technickým detailům. Například pro definování kroku, ve kterém budou události obohaceny voláním externích služeb, musí uživatelé napsat následující DSL a framework na jeho základě vytvoří model, který bude spuštěn Flinkem.
Obrázek 3. Příklad obohacení na DSL v Delta
Procesní rámec nejen snižuje křivku učení, ale také poskytuje běžné funkce zpracování toku, jako je deduplikace, schématizace a flexibilita a odolnost pro řešení běžných provozních problémů.
Delta Stream Processing Framework se skládá ze dvou klíčových modulů, modulu DSL & API a modulu Runtime. Modul DSL & API poskytuje DSL a UDF (User-Defined-Function) API, takže uživatelé mohou psát svou vlastní logiku zpracování (jako je filtrování nebo transformace). Modul Runtime poskytuje implementaci analyzátoru DSL, který vytváří interní reprezentaci kroků zpracování v modelech DAG. Komponenta Execution interpretuje modely DAG k inicializaci skutečných příkazů Flink a nakonec ke spuštění aplikace Flink. Architektura frameworku je znázorněna na následujícím obrázku.
Obrázek 4. Architektura Delta Stream Processing Framework
Tento přístup má několik výhod:
- Uživatelé se mohou soustředit na svou obchodní logiku, aniž by se museli ponořit do specifik Flink nebo struktury SPaaS.
- Optimalizaci lze provést způsobem, který je pro uživatele transparentní, a chyby lze opravit bez nutnosti jakýchkoli změn uživatelského kódu (UDF).
- Aplikace Delta je pro uživatele zjednodušena, protože platforma poskytuje flexibilitu a odolnost ihned po vybalení a shromažďuje řadu podrobných metrik, které lze použít pro upozornění.
Výrobní využití
Delta je ve výrobě více než rok a hraje klíčovou roli v mnoha aplikacích Netflix Studio. Pomohla týmům implementovat případy použití, jako je indexování vyhledávání, ukládání dat a pracovní postupy řízené událostmi. Níže je uveden přehled architektury na vysoké úrovni platformy Delta.
Obrázek 5. Architektura vysoké úrovně Delta.
Poděkování
Rádi bychom poděkovali následujícím lidem, kteří se podíleli na vzniku a vývoji Delta v Netflixu: 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 zpracování událostí. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Nástroj pro vytváření dat pro úložiště Amazon Redshift."
Zdroj: www.habr.com