U iščekivanju pokretanja novog protoka po stopi pripremio prijevod zanimljivog materijala.
Pregled
Govorit ćemo o prilično popularnom obrascu po kojem aplikacije koriste više pohrana podataka, pri čemu se svaka pohrana koristi za svoje potrebe, npr. za pohranjivanje kanonskog oblika podataka (MySQL itd.), pružanje naprednih mogućnosti pretraživanja (ElasticSearch, itd.), predmemoriranje (Memcached itd.) i drugi. Obično, kada koristite više pohrana podataka, jedna od njih djeluje kao primarna pohrana, a druge kao izvedene pohrane. Jedini problem je kako sinkronizirati te pohrane podataka.
Proučili smo niz različitih obrazaca koji su pokušali riješiti problem sinkronizacije više trgovina, kao što su dvostruko pisanje, distribuirane transakcije itd. Međutim, ovi pristupi imaju značajna ograničenja u pogledu korištenja u stvarnom životu, pouzdanosti i održavanja. Osim sinkronizacije podataka, neke aplikacije trebaju i obogaćivanje podataka pozivanjem vanjskih servisa.
Delta je razvijena za rješavanje ovih problema. Delta u konačnici pruža dosljednu platformu vođenu događajima za sinkronizaciju i obogaćivanje podataka.
Postojeća rješenja
Dvostruki ulaz
Kako biste sinkronizirali dva skladišta podataka, možete koristiti dvostruko pisanje, koje piše u jedno spremište, a zatim odmah nakon toga piše u drugo. Prvo snimanje može se pokušati ponovno, a drugo se može prekinuti ako prvo ne uspije nakon što je broj pokušaja iscrpljen. Međutim, dvije pohrane podataka mogu postati neusklađene ako pisanje u drugu pohranu ne uspije. Ovaj se problem obično rješava stvaranjem postupka oporavka koji može povremeno ponovno prenijeti podatke iz prve pohrane u drugu ili to učiniti samo ako se otkriju razlike u podacima.
Problemi:
Izvođenje postupka oporavka poseban je posao koji se ne može ponovno koristiti. Osim toga, podaci između lokacija za pohranu ostaju nesinkronizirani dok se ne izvrši postupak vraćanja. Rješenje postaje složenije ako se koriste više od dvije pohrane podataka. Konačno, postupak vraćanja može dodatno opteretiti izvorni izvor podataka.
Tablica dnevnika promjena
Kada dođe do promjena u skupu tablica (kao što je umetanje, ažuriranje i brisanje zapisa), zapisi promjena dodaju se u tablicu dnevnika kao dio iste transakcije. Druga nit ili proces stalno zahtijeva događaje iz tablice dnevnika i zapisuje ih u jednu ili više pohrana podataka, ako je potrebno, uklanjajući događaje iz tablice dnevnika nakon što su zapis potvrdili svi spremnici.
Problemi:
Ovaj obrazac bi trebao biti implementiran kao biblioteka, i idealno bez mijenjanja koda aplikacije koja ga koristi. U poliglotskom okruženju, implementacija takve biblioteke trebala bi postojati na bilo kojem potrebnom jeziku, ali je vrlo teško osigurati dosljednost funkcionalnosti i ponašanja na više jezika.
Drugi problem leži u dobivanju promjena sheme u sustavima koji ne podržavaju transakcijske promjene sheme [1][2], kao što je MySQL. Stoga, obrazac unošenja promjena (na primjer, promjena sheme) i transakcijskog bilježenja u tablici dnevnika promjena neće uvijek funkcionirati.
Distribuirane transakcije
Distribuirane transakcije mogu se koristiti za dijeljenje transakcije na više heterogenih pohrana podataka tako da je operacija ili posvećena svim korištenim pohranama podataka ili nije posvećena nijednoj od njih.
Problemi:
Distribuirane transakcije su vrlo veliki problem za heterogene pohrane podataka. Po svojoj prirodi, oni se mogu osloniti samo na najmanji zajednički nazivnik uključenih sustava. Na primjer, XA transakcije blokiraju izvršenje ako proces prijave ne uspije tijekom pripremne faze. Dodatno, XA ne pruža otkrivanje zastoja niti podržava optimistične sheme kontrole paralelnosti. Osim toga, neki sustavi poput ElasticSearcha ne podržavaju XA ili bilo koji drugi model heterogenih transakcija. Stoga osiguravanje atomičnosti pisanja u različitim tehnologijama za pohranu podataka ostaje vrlo izazovan zadatak za aplikacije [3].
Delta
Delta je dizajnirana za rješavanje ograničenja postojećih rješenja za sinkronizaciju podataka i također omogućuje obogaćivanje podataka u hodu. Naš je cilj bio apstrahirati svu ovu složenost dalje od programera aplikacija kako bi se mogli u potpunosti usredotočiti na implementaciju poslovne funkcionalnosti. Zatim ćemo opisati "Movie Search", stvarni slučaj korištenja Netflixove Delte.
Netflix naširoko koristi arhitekturu mikroservisa, a svaki mikroservis obično služi 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 Studios često moraju pretraživati različite filmske kriterije, zbog čega im je vrlo važno da mogu pretraživati sve podatke koji se odnose na filmove.
Prije Delte, tim za pretraživanje filmova trebao je izvući podatke iz više mikroservisa prije indeksiranja podataka o filmu. Osim toga, tim je morao razviti sustav koji bi povremeno ažurirao indeks pretraživanja tražeći promjene od drugih mikroservisa, čak i ako nije bilo nikakvih promjena. Ovaj je sustav brzo postao složen i težak za održavanje.
Slika 1. Sustav glasanja prema Delti
Nakon korištenja Delte, sustav je pojednostavljen na sustav vođen događajima kao što je prikazano na sljedećoj slici. CDC (Change-Data-Capture) događaji šalju se Keystone Kafka temama pomoću Delta-Connectora. Delta aplikacija izgrađena korištenjem Delta Stream Processing Framework (temeljene na Flinku) prima CDC događaje iz teme, obogaćuje ih pozivanjem drugih mikroservisa i na kraju prosljeđuje obogaćene podatke indeksu pretraživanja u Elasticsearchu. Cijeli se proces odvija gotovo u stvarnom vremenu, odnosno čim se promjene unesu u skladište podataka, indeksi pretraživanja se ažuriraju.
Slika 2. Cjevovod podataka pomoću Delte
U sljedećim odjeljcima opisat ćemo rad Delta-konektora koji se povezuje sa pohranom i objavljuje CDC događaje na transportnom sloju, što je infrastruktura za prijenos podataka u stvarnom vremenu koja usmjerava CDC događaje na Kafkine teme. I na samom kraju, govorit ćemo o Delta stream framework frameworku koji programeri aplikacija mogu koristiti za logiku obrade i obogaćivanja podataka.
CDC (Change-Data-Capture)
Razvili smo CDC uslugu pod nazivom Delta-Connector, koja može uhvatiti predane promjene iz pohrane podataka u stvarnom vremenu i zapisati ih u tok. Promjene u stvarnom vremenu preuzimaju se iz dnevnika transakcija i izvadaka pohrane. Dumpovi se koriste jer zapisnici transakcija obično ne pohranjuju cijelu povijest promjena. Promjene se obično serijaliziraju kao Delta događaji, tako da primatelj ne mora brinuti odakle promjena dolazi.
Delta-Connector podržava nekoliko dodatnih značajki kao što su:
- Sposobnost pisanja prilagođenih izlaznih podataka mimo Kafke.
- Mogućnost aktiviranja ručnih ispisa u bilo kojem trenutku za sve tablice, određenu tablicu ili za određene primarne ključeve.
- Dumpovi se mogu dohvaćati u komadima, tako da nema potrebe za počinjanje ispočetka u slučaju kvara.
- Nema potrebe za zaključavanjem tablica, što je vrlo važno kako bismo osigurali da naša usluga nikada ne blokira promet pisanja baze podataka.
- Visoka dostupnost zbog redundantnih instanci u AWS zonama dostupnosti.
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 prijenosa događaja izgrađen je na platformi za razmjenu poruka .
Povijesno gledano, objavljivanje na Netflixu bilo je optimizirano za pristupačnost, a ne za dugotrajnost (vidi dolje). ). Kompromis je bila potencijalna nedosljednost podataka brokera u različitim rubnim scenarijima. Na primjer, nečisti izbor vođe je odgovoran za primatelja koji potencijalno ima duplicirane ili izgubljene događaje.
S Deltom smo željeli jača jamstva trajnosti kako bismo osigurali isporuku CDC događaja u izvedene trgovine. U tu svrhu predložili smo posebno dizajniran Kafkin klaster kao prvorazredni objekt. Neke postavke brokera možete pogledati u tablici ispod:
U klasterima Keystone Kafka, nečisti izbor vođe obično uključeni kako bi se osigurala dostupnost izdavača. To može dovesti do gubitka poruke ako je nesinkronizirana replika izabrana kao vodeća. Za novi Kafka klaster visoke dostupnosti, opcija nečisti izbor vođe isključeno kako bi se spriječio gubitak poruke.
Također smo povećali faktor replikacije od 2 do 3 i minimalne nesinkronizirane replike 1 do 2. Izdavači koji pišu u ovaj klaster zahtijevaju acks od svih ostalih, osiguravajući da 2 od 3 replike imaju najnovije poruke koje je poslao izdavač.
Kada brokerska instanca prestane s radom, nova instanca zamjenjuje staru. Međutim, novi će posrednik morati uhvatiti korak s nesinkroniziranim replikama, što može potrajati nekoliko sati. Kako bismo smanjili vrijeme oporavka za ovaj scenarij, počeli smo koristiti blokovnu pohranu podataka (Amazon Elastic Block Store) umjesto lokalnih brokerskih diskova. Kada nova instanca zamijeni prekinutu brokersku instancu, pridružuje EBS volumen koji je imala prekinuta instanca i počinje sustizati nove poruke. Ovaj proces smanjuje vrijeme rješavanja zaostataka sa sati na minute jer se nova instanca više ne mora replicirati iz praznog stanja. Općenito, odvojeni životni ciklusi pohrane i brokera značajno smanjuju utjecaj promjene brokera.
Kako bismo dodatno povećali jamstvo isporuke podataka, koristili smo za otkrivanje bilo kakvog gubitka poruke u ekstremnim uvjetima (na primjer, desinkronizacija sata u voditelju particije).
Okvir za obradu toka
Deltin sloj obrade izgrađen je na platformi Netflix SPaaS, koja omogućuje integraciju Apache Flinka s Netflix ekosustavom. Platforma pruža korisničko sučelje koje upravlja implementacijom Flink poslova i orkestracijom Flink klastera na vrhu naše platforme za upravljanje kontejnerima Titus. Sučelje također upravlja konfiguracijama poslova i omogućuje korisnicima da dinamički mijenjaju konfiguraciju bez potrebe za ponovnim kompajliranjem Flink poslova.
Delta pruža okvir za obradu toka koji se temelji na Flinku i SPaaS-u koji koristi na temelju anotacija DSL (Domain Specific Language) za apstrahiranje tehničkih detalja. Na primjer, za definiranje koraka u kojem će se događaji obogatiti pozivanjem vanjskih servisa, korisnici trebaju napisati sljedeći DSL, a okvir će na temelju njega kreirati model koji će Flink izvršiti.
Slika 3. Primjer obogaćivanja na DSL-u u Delti
Okvir obrade ne samo da smanjuje krivulju učenja, već također pruža uobičajene značajke obrade toka kao što su deduplikacija, shematizacija te fleksibilnost i otpornost za rješavanje uobičajenih operativnih problema.
Delta Stream Processing Framework sastoji se od dva ključna modula, DSL & API modula i Runtime modula. DSL & API modul pruža DSL i UDF (korisnički definirane funkcije) API-je tako da korisnici mogu napisati vlastitu logiku obrade (kao što su filtriranje ili transformacije). Runtime modul pruža implementaciju DSL parsera koji gradi interni prikaz koraka obrade u DAG modelima. Izvršna komponenta tumači DAG modele kako bi inicijalizirala stvarne Flink izjave i na kraju pokrenula Flink aplikaciju. Arhitektura okvira ilustrirana je na sljedećoj slici.
Slika 4. Arhitektura Delta Stream Processing Frameworka
Ovaj pristup ima nekoliko prednosti:
- Korisnici se mogu usredotočiti na svoju poslovnu logiku, a da ne moraju ulaziti u specifičnosti Flinka ili SPaaS strukture.
- Optimizacija se može napraviti na način koji je transparentan za korisnike, a greške se mogu popraviti bez potrebe za bilo kakvim promjenama korisničkog koda (UDF).
- Iskustvo Delta aplikacije je pojednostavljeno za korisnike jer platforma pruža fleksibilnost i otpornost odmah po otvaranju 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 aplikacijama Netflix Studio. Pomogla je timovima implementirati slučajeve korištenja kao što su indeksiranje pretraživanja, pohrana podataka i tijek rada vođen događajima. U nastavku je pregled arhitekture visoke razine Delta platforme.
Slika 5. Deltina arhitektura visoke razine.
Blagodarnosti
Željeli bismo zahvaliti 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. Komun. ACM 62(5): 43-49 (2019). DOI:
: “Alat za izgradnju podataka za Amazon Redshift Storage.”
Izvor: www.habr.com