In anticipazione di u lanciamentu di un novu flussu à a tarifa Avemu preparatu una traduzzione di materiale interessante.
riassuntu
Parleremu di un mudellu abbastanza populari da quale l'applicazioni utilizanu parechje magazzini di dati, induve ogni tenda hè aduprata per i so propiu scopi, per esempiu, per almacenà a forma canonica di dati (MySQL, etc.), furnisce capacità di ricerca avanzata (ElasticSearch, etc.) .), caching (Memcached, etc.) è altri. Di genere, quandu si usanu parechji magazzini di dati, unu di elli agisce cum'è a tenda primaria è l'altri cum'è magazzini derivati. L'unicu prublema hè cumu sincronizà sti magazzini di dati.
Avemu guardatu una quantità di mudelli diffirenti chì anu pruvatu à risolve u prublema di sincronizà parechje magazzini, cum'è scrittura doppia, transazzione distribuita, etc. Tuttavia, questi approcci anu limitazioni significativu in quantu à l'usu di a vita reale, affidabilità è mantenimentu. In più di a sincronizazione di dati, alcune applicazioni anu ancu bisognu di arricchisce e dati chjamendu servizii esterni.
Delta hè statu sviluppatu per risolve questi prublemi. Delta infine furnisce una piattaforma coherente, guidata da l'avvenimenti per a sincronizazione di dati è l'arricchimentu.
Soluzioni esistenti
Doppia entrata
Per mantene dui magazzini di dati in sincronia, pudete aduprà a doppia scrittura, chì scrive in una tenda è poi scrive à l'altru immediatamente dopu. U primu arregistramentu pò esse ripruvatu è u sicondu pò esse abortu se u primu fiasca dopu chì u numeru di tentativi hè statu esauritu. Tuttavia, i dui magazzini di dati ponu esse sincronizzati se a scrittura à a seconda tenda falla. Stu prublema hè di solitu risolta da a creazione di una prucedura di ricuperazione chì pò periodicamente re-trasferisce dati da u primu almacenamentu à u sicondu, o fate cusì solu s'ellu sò rilevati differenzi in i dati.
Prublemi:
Realizà una prucedura di ricuperazione hè un travagliu specificu chì ùn pò micca esse riutilizatu. Inoltre, i dati trà i lochi di almacenamento restanu fora di sincronia finu à chì a prucedura di restaurazione hè fatta. A suluzione diventa più cumplessa si sò usati più di dui magazzini di dati. Infine, a prucedura di risturà pò aghjunghje carica à a fonte di dati uriginale.
Cambia tavula di log
Quandu i cambiamenti accadenu à un inseme di tavule (cum'è inserimentu, aghjurnà è sguassate un registru), i registri di cambiamentu sò aghjuntu à a tavola di log cum'è parte di a listessa transazzione. Un altru filu o prucessu dumanda constantemente l'avvenimenti da a tavola di log è li scrive à unu o più magazzini di dati, se ne necessariu, sguassate l'avvenimenti da a tavola di log dopu chì a registrazione hè cunfirmata da tutti i magazzini.
Prublemi:
Stu mudellu deve esse implementatu cum'è una biblioteca, è idealmente senza cambià u codice di l'applicazione chì l'utiliza. In un ambiente poliglotta, una implementazione di una tale biblioteca deve esse in ogni lingua necessaria, ma assicurà a coherenza di funziunalità è cumportamentu in tutte e lingue hè assai difficiule.
Un altru prublema si trova à ottene cambiamenti di schema in sistemi chì ùn supportanu micca cambiamenti di schema transazionale [1][2], cum'è MySQL. Per quessa, u mudellu di fà un cambiamentu (per esempiu, un cambiamentu di schema) è di registramentu transazzione in a tavola di log di cambiamentu ùn hè micca sempre travagliatu.
Transazzioni distribuite
E transazzione distribuite ponu esse aduprate per sparte una transazzione in parechje magazzini di dati eterogenei in modu chì l'operazione sia impegnata in tutti i magazzini di dati utilizati, o micca impegnata in alcunu di elli.
Prublemi:
E transazzioni distribuite sò un prublema assai grande per i magazzini di dati eterogenei. Per a so natura, ponu solu cunfidendu u denominatore cumunu più bassu di i sistemi implicati. Per esempiu, e transazzioni XA bluccà l'esekzione se u prucessu di l'applicazione falla durante a fase di preparazione. Inoltre, XA ùn furnisce micca a rilevazione di blocchi o supporta schemi ottimisti di cuntrollu di cuncurrenza. Inoltre, certi sistemi cum'è ElasticSearch ùn sustene micca XA o qualsiasi altru mudellu di transazzione eterogeneu. Cusì, assicurà l'atomicità di scrittura in diverse tecnulugia di almacenamentu di dati resta un compitu assai sfida per l'applicazioni [3].
Delta
Delta hè statu cuncepitu per affruntà e limitazioni di e soluzioni di sincronizazione di dati esistenti è permette ancu l'arricchimentu di dati in u volu. U nostru scopu era di astrattu tutta sta cumplessità luntanu da i sviluppatori di l'applicazioni per ch'elli ponu fucalizza cumplettamente in l'implementazione di e funziunalità cummerciale. In seguitu, descriveremu "Movie Search", u casu d'usu attuale per Delta di Netflix.
Netflix usa largamente una architettura di microserviziu, è ogni microserviziu generalmente serve un tipu di dati. L'infurmazione basica nantu à u filmu hè cuntenuta in un microserviziu chjamatu Movie Service, è e dati assuciati cum'è l'infurmazioni nantu à i pruduttori, attori, venditori, è cusì sò gestiti da parechji altri microservizi (vale à dì Deal Service, Talent Service è Vendor Service).
L'utilizatori di l'imprese in Netflix Studios spessu anu bisognu di circà à traversu diversi criterii di filmi, per quessa hè assai impurtante per elli à pudè ricercà in tutti i dati di filmi.
Prima di Delta, a squadra di ricerca di filmi avia bisognu di tirà dati da parechji microservizi prima di indexà i dati di u filmu. Inoltre, a squadra avia da sviluppà un sistema chì aghjurnà periodicamente l'indici di ricerca dumandendu cambiamenti da altri microservizi, ancu s'ellu ùn ci era micca cambiamenti in tuttu. Stu sistema hè diventatu prestu cumplessu è difficiule di mantene.
Figura 1. Sistema di votazione à Delta
Dopu l'usu di Delta, u sistema hè statu simplificatu à un sistema guidatu per l'avvenimenti cum'è mostra in a figura seguente. L'avvenimenti CDC (Change-Data-Capture) sò mandati à temi Keystone Kafka usendu Delta-Connector. Una applicazione Delta custruita cù u Delta Stream Processing Framework (basatu nantu à Flink) riceve l'avvenimenti CDC da un tema, l'arricchisce chjamendu altri microservizi, è infine passa i dati arricchiti à un indice di ricerca in Elasticsearch. U prucessu tutale hè quasi in tempu reale, vale à dì, quandu i cambiamenti sò impegnati in u magazzinu di dati, l'indici di ricerca sò aghjurnati.
Figura 2. Pipeline di dati cù Delta
In i seguenti rùbbriche, descriveremu l'operazione di u Delta-Connector, chì cunnetta à l'almacenamiento è publica l'avvenimenti CDC à a capa di trasportu, chì hè una infrastruttura di trasmissione di dati in tempu reale chì indirizza l'avvenimenti CDC à i temi Kafka. È à a fine, parlemu di u quadru di trasfurmazione di u flussu Delta, chì i sviluppatori di l'applicazioni ponu aduprà per a logica di trasfurmazioni di dati è arricchimentu.
CDC (Change-Data-Capture)
Avemu sviluppatu un serviziu CDC chjamatu Delta-Connector, chì pò catturà cambiamenti impegnati da u magazzinu di dati in tempu reale è scrive in un flussu. I cambiamenti in tempu reale sò pigliati da u logu di transazzione è i dumps di almacenamiento. Dumps sò usati perchè i logs di transazzione di solitu ùn guardanu micca tutta a storia di i cambiamenti. I cambiamenti sò tipicamente serializzati cum'è avvenimenti Delta, cusì u destinatariu ùn deve micca preoccupatu di induve vene u cambiamentu.
Delta-Connector supporta parechje funzioni supplementari cum'è:
- Capacità di scrive dati di output persunalizati passatu Kafka.
- Capacità di attivà dumps manuali in ogni mumentu per tutti i tavulini, una tavula specifica, o per chjavi primari specifichi.
- Dumps ponu esse ritruvati in pezzi, per quessa, ùn ci hè bisognu di ricuminciari tuttu in casu di fallimentu.
- Ùn ci hè bisognu di mette chjusi nantu à e tavule, chì hè assai impurtante per assicurà chì u trafficu di scrittura di basa di dati ùn hè mai bluccatu da u nostru serviziu.
- Alta disponibilità per via di istanze ridondanti in AWS Availability Zones.
Attualmente supportemu MySQL è Postgres, cumprese implementazioni in AWS RDS è Aurora. Avemu ancu sustegnu Cassandra (multi-maestru). Pudete truvà più dettagli nantu à Delta-Connector quì .
Kafka è a capa di trasportu
A strata di trasportu di l'avvenimenti di Delta hè custruitu nantu à u serviziu di messageria di a piattaforma .
Stòricamente, a pubblicazione in Netflix hè stata ottimizzata per l'accessibilità piuttostu chè a longevità (vede quì sottu). ). U scambiu era l'incoerenza potenziale di dati di broker in diversi scenarii di punta. Per esempiu, elezzione di capu impuru hè rispunsevuli di u destinatariu potenzialmente avè eventi duplicati o persi.
Cù Delta, vuliamu garanzii di durabilità più forti per assicurà a consegna di l'avvenimenti CDC à i magazzini derivati. Per questu scopu, avemu prupostu un cluster Kafka apposta cum'è un ughjettu di prima classe. Pudete vede alcuni paràmetri di broker in a tavula sottu:
In i cluster Keystone Kafka, elezzione di capu impuru generalmente inclusi per assicurà l'accessibilità di l'editore. Questu pò esse risultatu in a perdita di missaghju se una replica non sincronizata hè elettu cum'è u capu. Per un novu cluster Kafka di alta dispunibilità, l'opzione elezzione di capu impuru disattivatu per impedisce a perdita di missaghju.
Avemu ancu aumentatu fattore di replicazione da 2 à 3 è repliche insync minime 1 à 2. L'editori chì scrivenu à questu cluster necessitanu ack da tutti l'altri, assicurendu chì 2 di 3 repliche anu i missaghji più attuali mandati da l'editore.
Quandu una istanza di broker finisce, una nova istanza rimpiazza u vechju. In ogni casu, u novu broker hà bisognu di ritruvà cù e rèpliche micca sincronizate, chì pò piglià parechje ore. Per riduce u tempu di ricuperazione per questu scenariu, avemu cuminciatu à utilizà l'almacenamiento di dati di bloccu (Amazon Elastic Block Store) invece di dischi di broker locale. Quandu una nova istanza rimpiazza una istanza di broker terminata, attache u voluminu EBS chì l'istanza terminata hà avutu è cumencia à piglià novi messagi. Stu prucessu riduce u tempu di cancellazione di u backlog da ore à minuti perchè a nova istanza ùn hà più bisognu di riplicà da un statu viotu. In generale, l'almacenamiento separatu è i cicli di vita di u broker riducenu significativamente l'impattu di u cambiamentu di broker.
Per aumentà ulteriormente a garanzia di consegna di dati, avemu usatu per detectà ogni perdita di missaghju in cundizioni estremi (per esempiu, desincronizazione di u clock in u capu di partizione).
Stream Processing Framework
A strata di trasfurmazioni di Delta hè custruitu nantu à a piattaforma Netflix SPaaS, chì furnisce l'integrazione Apache Flink cù l'ecosistema Netflix. A piattaforma furnisce una interfaccia d'utilizatore chì gestisce l'implementazione di l'impieghi Flink è l'orchestrazione di clusters Flink in cima à a nostra piattaforma di gestione di container Titus. L'interfaccia gestisce ancu e cunfigurazioni di u travagliu è permette à l'utilizatori di fà cambiamenti di cunfigurazione dinamicamente senza avè da recompilà i travaglii di Flink.
Delta furnisce un quadru di trasfurmazioni di flussu basatu in Flink è SPaaS chì usa basatu nantu à l'annotazione DSL (Domain Specific Language) per astrazione di dettagli tecnichi. Per esempiu, per definisce u passu à quale l'avvenimenti seranu arricchiti chjamendu servizii esterni, l'utilizatori anu bisognu di scrive u seguente DSL, è u quadru creà un mudellu basatu annantu à questu, chì serà eseguitu da Flink.
Figura 3. Esempiu di arricchimentu nantu à DSL in Delta
U quadru di trasfurmazioni ùn solu riduce a curva di apprendimentu, ma furnisce ancu funzioni cumuni di trasfurmazioni di flussu cum'è deduplicazione, schematizazione, flessibilità è resilienza per risolve i prublemi operativi cumuni.
Delta Stream Processing Framework hè custituitu da dui moduli chjave, u modulu DSL è API è u modulu Runtime. U modulu DSL & API furnisce API DSL è UDF (User-Defined-Function) per chì l'utilizatori ponu scrive a so propria logica di trasfurmazioni (cum'è filtru o trasfurmazioni). U modulu Runtime furnisce una implementazione di un parser DSL chì custruisce una rappresentazione interna di i passi di trasfurmazioni in mudelli DAG. U cumpunente di Esecuzione interpreta i mudelli DAG per inizializza l'attuali dichjarazioni Flink è infine eseguisce l'applicazione Flink. L'architettura di u quadru hè illustrata in a figura seguente.
Figura 4. Architettura Delta Stream Processing Framework
Stu approcciu hà parechji vantaghji:
- L'utilizatori ponu fucalizza nantu à a so logica cummerciale senza avè da sfondà in e specificità di Flink o di a struttura SPaaS.
- L'ottimisazione pò esse fatta in una manera chì hè trasparente per l'utilizatori, è l'errori ponu esse riparati senza avè bisognu di cambiamenti à u codice d'utilizatore (UDF).
- L'esperienza di l'applicazione Delta hè simplificata per l'utilizatori perchè a piattaforma furnisce flessibilità è resilienza fora di a scatula è raccoglie una varietà di metriche dettagliate chì ponu esse aduprate per alerti.
Usu di pruduzzione
Delta hè in produzzione per più di un annu è ghjoca un rolu chjave in parechje applicazioni Netflix Studio. Hà aiutatu i squadre à implementà casi d'usu cum'è l'indexazione di ricerca, u almacenamentu di dati è i flussi di travagliu guidati da l'avvenimenti. A sottu hè una panoramica di l'architettura di altu livellu di a piattaforma Delta.
Figura 5. L'architettura d'altu livellu di Delta.
Ringraziamenti
Vulemu ringrazià e seguenti persone chì anu participatu à a creazione è u sviluppu di Delta in 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 è Zhenzhong Xu.
Fonti
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Trattamentu di l'avvenimenti in linea. Cumunu. ACM 62 (5): 43-49 (2019). DOI:
: "Strumentu di creazione di dati per Amazon Redshift Storage".
Source: www.habr.com