U iščekivanju pokretanja novog toka po stopi Pripremili smo prijevod zanimljivog materijala.
pregled
Govorit ćemo o prilično popularnom obrascu po kojem aplikacije koriste više skladišta podataka, gdje se svako skladište koristi za svoje potrebe, na primjer, za pohranjivanje kanonskog oblika podataka (MySQL, itd.), pruža napredne mogućnosti pretraživanja (ElasticSearch, itd.) .), keširanje (Memcached, itd.) i drugo. Obično, kada se koristi više skladišta podataka, jedno od njih djeluje kao primarno, a drugo kao derivativna skladišta. Jedini problem je kako sinkronizirati te skladišta podataka.
Pogledali smo niz različitih obrazaca koji su pokušali riješiti problem sinkronizacije više skladišta, kao što su dvostruko upisivanje, distribuirane transakcije itd. Međutim, ovi pristupi imaju značajna ograničenja u smislu stvarne upotrebe, pouzdanosti i održavanja. Osim sinhronizacije podataka, neke aplikacije također trebaju obogatiti podatke pozivanjem vanjskih servisa.
Delta je razvijena da riješi ove probleme. Delta na kraju pruža konzistentnu platformu vođenu događajima za sinhronizaciju i obogaćivanje podataka.
Postojeća rješenja
Dvostruki ulaz
Da biste sinkronizirali dva skladišta podataka, možete koristiti dvostruko upisivanje, koje upisuje u jedno spremište, a zatim upisuje u drugo odmah nakon toga. Prvo snimanje se može ponoviti, a drugo se može prekinuti ako prvo ne uspije nakon što je broj pokušaja iscrpljen. Međutim, dva skladišta podataka mogu postati nesinhronizirana ako upisivanje u drugu pohranu ne uspije. Ovaj problem se obično rješava kreiranjem procedure oporavka koja može periodično ponovo prenositi podatke iz prve memorije u drugu ili to učiniti samo ako se otkriju razlike u podacima.
Problemi:
Izvođenje procedure oporavka je specifičan posao koji se ne može ponovo koristiti. Osim toga, podaci između lokacija za pohranu ostaju nesinhronizirani sve dok se ne izvrši postupak vraćanja. Rješenje postaje složenije ako se koristi više od dva skladišta podataka. Konačno, procedura vraćanja može dodati opterećenje izvornom izvoru podataka.
Promjena tablice dnevnika
Kada dođe do promjena u skupu tabela (kao što je umetanje, ažuriranje i brisanje zapisa), zapisi promjena se dodaju u tablicu dnevnika kao dio iste transakcije. Druga nit ili proces stalno zahtijeva događaje iz tablice dnevnika i upisuje ih u jedno ili više spremišta podataka, ako je potrebno, uklanjajući događaje iz tablice dnevnika nakon što je zapis potvrđen od strane svih skladišta.
Problemi:
Ovaj obrazac treba implementirati kao biblioteku, a idealno bi bilo bez promjene koda aplikacije koja ga koristi. U poliglotskom okruženju implementacija takve biblioteke bi trebala postojati na bilo kojem potrebnom jeziku, ali je vrlo teško osigurati konzistentnost funkcionalnosti i ponašanja među jezicima.
Drugi problem leži u dobijanju promena šeme u sistemima koji ne podržavaju promene transakcionih šema [1][2], kao što je MySQL. Stoga, obrazac unošenja promjene (na primjer, promjena šeme) i transakcijskog evidentiranja u tablici dnevnika promjena neće uvijek raditi.
Distribuirane transakcije
Distribuirane transakcije se mogu koristiti za podjelu transakcije na više heterogenih skladišta podataka tako da je operacija ili posvećena svim korištenim spremištima podataka, ili nije predana ni jednom od njih.
Problemi:
Distribuirane transakcije su veliki problem za heterogene skladišta podataka. Po svojoj prirodi, oni se mogu osloniti samo na najmanji zajednički imenitelj uključenih sistema. Na primjer, XA transakcije blokiraju izvršenje ako proces aplikacije ne uspije tokom faze pripreme. Dodatno, XA ne pruža detekciju zastoja niti podržava optimistične šeme kontrole konkurentnosti. Osim toga, neki sistemi poput ElasticSearch-a ne podržavaju XA ili bilo koji drugi heterogeni model transakcije. Stoga, osiguravanje atomičnosti pisanja u različitim tehnologijama za pohranu podataka ostaje vrlo izazovan zadatak za aplikacije [3].
delta
Delta je dizajnirana da odgovori na ograničenja postojećih rješenja za sinhronizaciju podataka i također omogućava obogaćivanje podataka u hodu. Naš cilj je bio da apstrahujemo sve ove složenosti od programera aplikacija kako bi se mogli u potpunosti fokusirati na implementaciju poslovne funkcionalnosti. Sljedeće ćemo opisati "Movie Search", stvarni slučaj upotrebe Netflixove Delta.
Netflix naširoko koristi arhitekturu mikroservisa, a svaki mikroservis obično opslužuje jednu vrstu podataka. Osnovne informacije o filmu sadržane su u mikroservisu pod nazivom Movie Service, a povezanim podacima kao što su informacije o producentima, glumcima, prodavačima i tako dalje upravlja nekoliko drugih mikroservisa (naime Deal Service, Talent Service i Vendor Service).
Poslovni korisnici u Netflix studiju često moraju da pretražuju različite filmske kriterijume, zbog čega je veoma važno da budu u mogućnosti da pretražuju sve podatke u vezi sa filmom.
Prije Delta-e, tim za pretragu filmova morao je izvući podatke iz više mikroservisa prije indeksiranja podataka filma. Osim toga, tim je morao razviti sistem koji bi periodično ažurirao indeks pretraživanja tražeći promjene od drugih mikroservisa, čak i ako nije bilo nikakvih promjena. Ovaj sistem je brzo postao složen i težak za održavanje.
Slika 1. Sistem prozivanja Delta
Nakon upotrebe Delta, sistem je pojednostavljen na sistem vođen događajima kao što je prikazano na sljedećoj slici. CDC (Change-Data-Capture) događaji se šalju Keystone Kafka temama koristeći Delta-Connector. Delta aplikacija izgrađena pomoću Delta Stream Processing Framework-a (baziranog na Flink-u) prima CDC događaje iz teme, obogaćuje ih pozivanjem drugih mikroservisa i konačno prosljeđuje obogaćene podatke u indeks pretraživanja u Elasticsearch-u. Čitav proces se odvija gotovo u realnom vremenu, odnosno čim se unese promjene u skladište podataka, ažuriraju se indeksi pretraživanja.
Slika 2. Cjevovod podataka koristeći Delta
U narednim odeljcima ćemo opisati rad Delta-konektora, koji se povezuje sa skladištem i objavljuje CDC događaje na transportnom sloju, koji je infrastruktura za prenos podataka u realnom vremenu koja usmerava CDC događaje ka Kafkinim temama. I na samom kraju, govorit ćemo o Delta stream procesorskom okviru, koji programeri aplikacija mogu koristiti za obradu podataka i logiku obogaćivanja.
CDC (Change-Data-Capture)
Razvili smo CDC uslugu pod nazivom Delta-Connector, koja može uhvatiti izvršene promjene iz skladišta podataka u realnom vremenu i zapisati ih u stream. Promjene u realnom vremenu uzimaju se iz evidencije transakcija i dumpova memorije. Dumpovi se koriste jer evidencije transakcija obično ne pohranjuju cijelu povijest promjena. Promjene se obično serijaliziraju kao Delta događaji, tako da primalac ne mora da brine o tome odakle promjena dolazi.
Delta-Connector podržava nekoliko dodatnih funkcija kao što su:
- Mogućnost pisanja prilagođenih izlaznih podataka nakon Kafke.
- Mogućnost aktiviranja ručnih dumpova u bilo kojem trenutku za sve tabele, određenu tabelu ili za određene primarne ključeve.
- Dumpovi se mogu preuzimati u komadima, tako da nema potrebe da počinjete iznova u slučaju kvara.
- Nema potrebe za zaključavanjem tablica, što je vrlo važno kako bismo osigurali da naš servis nikada ne blokira promet pisanja baze podataka.
- Visoka dostupnost zbog redundantnih instanci u zonama dostupnosti AWS-a.
Trenutno podržavamo MySQL i Postgres, uključujući implementacije na AWS RDS i Aurora. Također podržavamo Cassandru (multi-master). Više detalja o Delta-Connectoru možete saznati ovdje .
Kafka i transportni sloj
Deltin sloj za transport događaja izgrađen je na platformi za razmenu poruka .
Istorijski gledano, objavljivanje na Netflixu je optimizirano za pristupačnost, a ne za dugovječnost (pogledajte dolje). ). Kompromis je bio potencijalna nedosljednost brokerskih podataka u različitim scenarijima na rubu. Na primjer, nečisti izbori lidera je odgovoran za potencijalno dupliranje ili izgubljene događaje kod primaoca.
Sa Deltom smo željeli jače garancije trajnosti kako bismo osigurali isporuku CDC događaja izvedenim prodavnicama. U tu svrhu predložili smo posebno dizajniran Kafka klaster kao prvoklasni objekat. Neke postavke brokera možete pogledati u donjoj tabeli:
U Keystone Kafka klasterima, nečisti izbori lidera obično uključen kako bi se osigurala dostupnost izdavača. Ovo može rezultirati gubitkom poruke ako se nesinhronizirana replika izabere kao vodeća. Za novi Kafka klaster visoke dostupnosti, opcija nečisti izbori lidera isključeno da spriječi gubitak poruke.
I mi smo se povećali faktor replikacije od 2 do 3 i minimalne insync replike 1 do 2. Izdavači koji pišu ovom klasteru zahtijevaju potvrde od svih ostalih, osiguravajući da 2 od 3 replike imaju najnovije poruke koje šalje izdavač.
Kada se brokerska instanca okonča, nova instanca zamjenjuje staru. Međutim, novi broker će morati da sustigne nesinhronizovane replike, što može potrajati nekoliko sati. Da bismo smanjili vrijeme oporavka za ovaj scenarij, počeli smo koristiti blok memoriju podataka (Amazon Elastic Block Store) umjesto lokalnih diskova brokera. Kada nova instanca zamijeni prekinutu brokersku instancu, ona pripaja EBS volumen koji je prekinuta instanca imala i počinje sustizati nove poruke. Ovaj proces smanjuje vrijeme otklanjanja zaostalih predmeta sa sati na minute jer se nova instanca više ne mora replicirati iz praznog stanja. Sve u svemu, odvojeno skladištenje i životni ciklus brokera značajno smanjuju uticaj promene brokera.
Da bismo dodatno povećali garanciju isporuke podataka, koristili smo za otkrivanje bilo kakvog gubitka poruke u ekstremnim uslovima (na primjer, desinhronizacija sata u vođi particije).
Stream Processing Framework
Deltin sloj za obradu je izgrađen na vrhu Netflix SPaaS platforme, koja omogućava Apache Flink integraciju sa Netflix ekosistemom. Platforma pruža korisnički interfejs koji upravlja implementacijom Flink poslova i orkestracijom Flink klastera na vrhu naše Titus platforme za upravljanje kontejnerima. Sučelje također upravlja konfiguracijama poslova i omogućava korisnicima da izvrše promjene konfiguracije dinamički bez potrebe za ponovnom kompajliranjem Flink poslova.
Delta pruža okvir za obradu toka baziran na Flink-u i SPaaS-u koji koristi baziran na anotaciji DSL (Domain Specific Language) za apstraktne tehničke detalje. Na primjer, da bi definirali korak u kojem će događaji biti obogaćeni pozivanjem eksternih servisa, korisnici treba da napišu sljedeći DSL, a okvir će na osnovu njega kreirati model koji će izvršiti Flink.
Slika 3. Primjer obogaćivanja na DSL-u u Delti
Okvir za obradu ne samo da smanjuje krivulju učenja, već također pruža uobičajene karakteristike obrade toka kao što su deduplikacija, shematizacija i fleksibilnost i otpornost za rješavanje uobičajenih operativnih problema.
Delta Stream Processing Framework se sastoji od dva ključna modula, DSL & API modula i Runtime modula. DSL & API modul pruža DSL i UDF (korisnički definirana funkcija) API-je tako da korisnici mogu pisati vlastitu logiku obrade (kao što je filtriranje ili transformacije). Runtime modul pruža implementaciju DSL parsera koji gradi interni prikaz koraka obrade u DAG modelima. Komponenta Execution interpretira DAG modele da bi inicijalizirala stvarne Flink izjave i na kraju pokrenula Flink aplikaciju. Arhitektura okvira je ilustrovana na sljedećoj slici.
Slika 4. Arhitektura Delta Stream Processing Framework
Ovaj pristup ima nekoliko prednosti:
- Korisnici se mogu fokusirati na svoju poslovnu logiku bez potrebe da se udubljuju u specifičnosti Flink-a ili strukture SPaaS-a.
- Optimizacija se može obaviti na način koji je transparentan za korisnike, a greške se mogu popraviti bez potrebe za izmjenom korisničkog koda (UDF).
- Iskustvo Delta aplikacije je pojednostavljeno za korisnike jer platforma pruža fleksibilnost i otpornost odmah iz kutije i prikuplja razne detaljne metrike koje se mogu koristiti za upozorenja.
Upotreba u proizvodnji
Delta je u proizvodnji više od godinu dana i igra ključnu ulogu u mnogim Netflix Studio aplikacijama. Pomogla je timovima da implementiraju slučajeve upotrebe kao što su indeksiranje pretraživanja, skladištenje podataka i radni tok vođen događajima. Ispod je pregled arhitekture visokog nivoa Delta platforme.
Slika 5. Deltina arhitektura visokog nivoa.
Zahvalnice
Željeli bismo da se zahvalimo sljedećim ljudima koji su bili uključeni u stvaranje i razvoj Delte u 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 i Zhenzhong Xu.
Izvori
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online obrada događaja. Commun. ACM 62(5): 43–49 (2019). DOI:
: “Alat za pravljenje podataka za Amazon Redshift Storage.”
izvor: www.habr.com