Ing nunggu Bukak saka aliran anyar ing tingkat Kita wis nyiapake terjemahan materi sing menarik.
Ringkesan
Kita bakal ngomong babagan pola sing cukup populer ing ngendi aplikasi nggunakake macem-macem toko data, ing ngendi saben toko digunakake kanggo tujuan dhewe, contone, kanggo nyimpen wangun data kanonik (MySQL, etc.), Nyedhiyakake kemampuan telusuran lanjut (ElasticSearch, etc.), caching (Memcached, etc.) lan liya-liyane. Biasane, nalika nggunakake macem-macem toko data, salah sijine minangka toko utama lan liyane minangka toko turunan. Masalah mung yaiku carane nyinkronake nyimpen data kasebut.
Kita ndeleng sawetara pola sing beda-beda sing nyoba ngatasi masalah nyinkronake pirang-pirang toko, kayata nulis kaping pindho, transaksi sing disebarake, lsp. Nanging, pendekatan kasebut duwe watesan sing signifikan babagan panggunaan, linuwih, lan pangopènan nyata. Saliyane sinkronisasi data, sawetara aplikasi uga kudu nambah data kanthi nelpon layanan eksternal.
Delta dikembangake kanggo ngatasi masalah kasebut. Delta pungkasane nyedhiyakake platform sing konsisten, didorong acara kanggo sinkronisasi lan pengayaan data.
Solusi sing wis ana
entri pindho
Kanggo nyimpen loro nyimpen data ing sinkronisasi, sampeyan bisa nggunakake dual nulis, kang nulis menyang siji nyimpen banjur nulis menyang liyane sanalika sawise. Rekaman pisanan bisa dicoba maneh lan sing kapindho bisa dibatalake yen sing pisanan gagal sawise jumlah upaya wis kesel. Nanging, loro nyimpen data bisa dadi ora sinkron yen nulis menyang toko kapindho gagal. Masalah iki biasane ditanggulangi kanthi nggawe prosedur pemulihan sing bisa mindhah data kanthi periodik saka panyimpenan pisanan menyang panyimpenan kaloro, utawa mung yen ana bedane ing data kasebut.
Masalah:
Nindakake prosedur pemulihan minangka tugas tartamtu sing ora bisa digunakake maneh. Kajaba iku, data ing antarane lokasi panyimpenan tetep ora sinkron nganti prosedur pamulihan ditindakake. Solusi dadi luwih rumit yen luwih saka rong nyimpen data digunakake. Pungkasan, prosedur mulihake bisa nambah beban menyang sumber data asli.
Ngganti tabel log
Nalika owah-owahan dumadi ing sakumpulan tabel (kayata nglebokake, nganyari, lan mbusak rekaman), cathetan owah-owahan ditambahake menyang tabel log minangka bagéan saka transaksi sing padha. Utas utawa proses liyane terus-terusan njaluk acara saka tabel log lan nulis menyang siji utawa luwih data nyimpen, yen perlu, mbusak acara saka tabel log sawise rekaman wis dikonfirmasi dening kabeh toko.
Masalah:
Pola iki kudu dileksanakake minangka perpustakaan, lan saenipun tanpa ngganti kode aplikasi sing nggunakake. Ing lingkungan polyglot, implementasi perpustakaan kasebut kudu ana ing basa apa wae sing dibutuhake, nanging mesthekake konsistensi fungsi lan prilaku ing antarane basa pancen angel banget.
Masalah liyane dumunung ing entuk owah-owahan skema ing sistem sing ora ndhukung owah-owahan skema transaksional [1] [2], kayata MySQL. Mulane, pola nggawe owah-owahan (contone, owah-owahan skema) lan transaksi ngrekam ing tabel log owah-owahan ora bakal tansah bisa.
Transaksi sing disebarake
Transaksi sing disebarake bisa digunakake kanggo misahake transaksi ing pirang-pirang toko data sing heterogen supaya operasi kasebut setya marang kabeh toko data sing digunakake, utawa ora setya marang samubarang.
Masalah:
Transaksi sing disebarake minangka masalah gedhe banget kanggo toko data heterogen. Miturut sifate, dheweke mung bisa ngandelake denominator umum sing paling murah ing sistem kasebut. Contone, transaksi XA mblokir eksekusi yen proses aplikasi gagal sajrone tahap persiapan. Kajaba iku, XA ora nyedhiyakake deteksi deadlock utawa ndhukung skema kontrol konkurensi optimistis. Kajaba iku, sawetara sistem kaya ElasticSearch ora ndhukung XA utawa model transaksi heterogen liyane. Mangkono, njamin atomicity nulis ing macem-macem teknologi panyimpenan data tetep dadi tugas sing tantangan banget kanggo aplikasi [3].
Delta
Delta dirancang kanggo ngatasi watesan saka solusi sinkronisasi data sing wis ana lan uga ngidini pengayaan data on-the-fly. Tujuane yaiku ngilangi kabeh kerumitan kasebut saka pangembang aplikasi supaya bisa fokus ing implementasine fungsi bisnis. Sabanjure kita bakal njlèntrèhaké "Panelusuran Film", kasus panggunaan nyata kanggo Delta Netflix.
Netflix akeh nggunakake arsitektur microservice, lan saben microservice biasane nglayani siji jinis data. Informasi dhasar babagan film kasebut ana ing layanan mikro sing diarani Movie Service, lan data sing gegandhengan kayata informasi babagan produser, aktor, vendor, lan liya-liyane dikelola dening sawetara layanan mikro liyane (yaiku Deal Service, Talent Service lan Vendor Service).
Pangguna bisnis ing Netflix Studios kerep kudu nggoleki macem-macem kritéria film, mula iku penting banget kanggo bisa nggoleki kabeh data sing gegandhengan karo film.
Sadurunge Delta, tim telusuran film kudu narik data saka macem-macem layanan mikro sadurunge ngindeks data film. Kajaba iku, tim kudu ngembangake sistem sing bakal nganyari indeks telusuran kanthi periodik kanthi njaluk owah-owahan saka layanan mikro liyane, sanajan ora ana owah-owahan. Sistem iki cepet dadi rumit lan angel kanggo njaga.
Gambar 1. Sistem polling menyang Delta
Sawise nggunakake Delta, sistem iki simplified kanggo sistem acara mimpin minangka ditampilake ing tokoh ing ngisor iki. CDC (Ganti-Data-Capture) acara dikirim menyang topik Keystone Kafka nggunakake Delta-Connector. Aplikasi Delta sing dibangun nggunakake Delta Stream Processing Framework (adhedhasar Flink) nampa acara CDC saka topik, nambahake kanthi nelpon layanan mikro liyane, lan pungkasane ngirim data sing diperkaya menyang indeks telusuran ing Elasticsearch. Proses kabeh kedadeyan meh ing wektu nyata, yaiku, sanalika owah-owahan ditindakake ing gudang data, indeks telusuran dianyari.
Gambar 2. Pipa data nggunakake Delta
Ing bagean ing ngisor iki, kita bakal njlèntrèhaké operasi saka Delta-Connector, kang nyambung menyang panyimpenan lan nerbitaké acara CDC kanggo lapisan transportasi, kang infrastruktur transmisi data nyata-wektu sing rute acara CDC kanggo topik Kafka. Lan ing pungkasan, kita bakal ngomong babagan kerangka pangolahan stream Delta, sing bisa digunakake pangembang aplikasi kanggo ngolah data lan logika pengayaan.
CDC (Ganti-Data-Capture)
Kita wis ngembangake layanan CDC sing diarani Delta-Connector, sing bisa njupuk owah-owahan setya saka nyimpen data ing wektu nyata lan nulis menyang stream. Owah-owahan nyata-wektu dijupuk saka log transaksi lan dumps panyimpenan. Dumps digunakake amarga log transaksi biasane ora nyimpen kabeh riwayat owah-owahan. Owah-owahan biasane serialized minangka acara Delta, supaya panampa ora kudu padha sumelang ing bab ngendi asalé owah-owahan.
Delta-Connector ndhukung sawetara fitur tambahan kayata:
- Kemampuan kanggo nulis data output khusus liwat Kafka.
- Kemampuan kanggo ngaktifake dumps manual sawayah-wayah kanggo kabeh tabel, tabel tartamtu, utawa kanggo tombol utami tartamtu.
- Dumps bisa dijupuk ing chunks, supaya ora perlu kanggo miwiti maneh ing cilik saka Gagal.
- Ora perlu nyelehake kunci ing meja, sing penting banget kanggo mesthekake yen lalu lintas nulis database ora bakal diblokir dening layanan kita.
- Kasedhiya dhuwur amarga kedadeyan sing berlebihan ing Zona Kasedhiyan AWS.
Saiki kita ndhukung MySQL lan Postgres, kalebu panyebaran ing AWS RDS lan Aurora. Kita uga ndhukung Cassandra (multi-master). Sampeyan bisa ngerteni rincian liyane babagan Delta-Connector ing kene .
Kafka lan lapisan transportasi
Lapisan transportasi acara Delta dibangun ing layanan olahpesen platform .
Secara historis, posting ing Netflix wis dioptimalake kanggo aksesibilitas tinimbang umur dawa (ndeleng ngisor). ). Trade-off ana potensial inkonsistensi data broker ing macem-macem skenario pinggiran. Tuladhane, pemilihan pimpinan sing ora resik tanggung jawab kanggo panampa duweni potensi duplikat utawa acara ilang.
Kanthi Delta, kita pengin njamin kekiatan sing luwih kuat kanggo njamin pangiriman acara CDC menyang toko asale. Kanggo maksud iki, kita ngusulake kluster Kafka sing dirancang khusus minangka obyek kelas siji. Sampeyan bisa ndeleng sawetara setelan broker ing tabel ing ngisor iki:
Ing klompok Keystone Kafka, pemilihan pimpinan sing ora resik biasane kalebu kanggo njamin aksesibilitas penerbit. Iki bisa nyebabake mundhut pesen yen replika sing ora disinkronake dipilih minangka pimpinan. Kanggo kasedhiyan dhuwur Kafka cluster anyar, pilihan pemilihan pimpinan sing ora resik dipatèni kanggo nyegah mundhut pesen.
Kita uga tambah faktor replikasi saka 2 kanggo 3 lan replika insync minimal 1 kanggo 2. Penerbit sing nulis menyang kluster iki mbutuhake acks saka kabeh liyane, mesthekake yen 2 saka 3 replika duwe pesen paling anyar sing dikirim dening penerbit.
Nalika conto broker mungkasi, conto anyar ngganti sing lawas. Nanging, makelar anyar kudu ngetutake replika sing ora disinkronake, sing butuh sawetara jam. Kanggo nyuda wektu pemulihan kanggo skenario iki, kita wiwit nggunakake panyimpenan data blok (Amazon Elastic Block Store) tinimbang disk broker lokal. Nalika instance anyar ngganti conto broker sing diakhiri, nempelake volume EBS sing ana ing instance sing diakhiri lan wiwit nyekel pesen anyar. Proses iki nyuda wektu reresik backlog saka jam kanggo menit amarga conto anyar ora perlu maneh kanggo niru saka negara kosong. Sakabèhé, panyimpenan lan siklus urip broker sing kapisah bisa nyuda pengaruh switching broker.
Kanggo luwih nambah njamin pangiriman data, kita digunakake kanggo ndeteksi mundhut pesen ing kahanan sing ekstrim (contone, desynchronization jam ing pimpinan partisi).
Stream Processing Framework
Lapisan pangolahan Delta dibangun ing ndhuwur platform Netflix SPaaS, sing nyedhiyakake integrasi Apache Flink karo ekosistem Netflix. Platform kasebut nyedhiyakake antarmuka pangguna sing ngatur panyebaran proyek Flink lan orkestrasi klompok Flink ing ndhuwur platform manajemen wadah Titus. Antarmuka uga ngatur konfigurasi proyek lan ngidini pangguna nggawe owah-owahan konfigurasi kanthi dinamis tanpa kudu nyusun ulang proyek Flink.
Delta nyedhiyakake kerangka pangolahan stream adhedhasar Flink lan SPaaS sing digunakake adhedhasar anotasi DSL (Basa Spesifik Domain) kanggo rincian teknis abstrak. Contone, kanggo netepake langkah ing ngendi acara bakal diperkaya kanthi nelpon layanan eksternal, pangguna kudu nulis DSL ing ngisor iki, lan kerangka bakal nggawe model adhedhasar, sing bakal ditindakake dening Flink.
Gambar 3. Conto pengayaan ing DSL ing Delta
Kerangka pangolahan ora mung nyuda kurva sinau, nanging uga nyedhiyakake fitur pangolahan stream umum kayata deduplikasi, skema, lan keluwesan lan ketahanan kanggo ngatasi masalah operasional umum.
Delta Stream Processing Framework kasusun saka rong modul utama, modul DSL & API lan modul Runtime. Modul DSL & API nyedhiyakake API DSL lan UDF (User-Defined-Function) supaya pangguna bisa nulis logika pangolahan dhewe (kayata nyaring utawa transformasi). Modul Runtime nyedhiyakake implementasi parser DSL sing nggawe perwakilan internal langkah-langkah pangolahan ing model DAG. Komponen Eksekusi napsirake model DAG kanggo miwiti pernyataan Flink sing nyata lan pungkasane mbukak aplikasi Flink. Arsitektur framework digambarake ing gambar ing ngisor iki.
Gambar 4. Arsitektur Delta Stream Processing Framework
Pendekatan iki nduweni sawetara kaluwihan:
- Pangguna bisa fokus ing logika bisnis tanpa kudu nyelidiki spesifik Flink utawa struktur SPaaS.
- Optimasi bisa ditindakake kanthi cara sing transparan kanggo pangguna, lan kesalahan bisa didandani tanpa mbutuhake owah-owahan ing kode pangguna (UDF).
- Pengalaman aplikasi Delta disederhanakake kanggo pangguna amarga platform kasebut nyedhiyakake keluwesan lan ketahanan metu saka kothak lan ngumpulake macem-macem metrik rinci sing bisa digunakake kanggo tandha.
Panggunaan produksi
Delta wis produksi luwih saka setahun lan nduweni peran penting ing akeh aplikasi Netflix Studio. Dheweke mbantu tim ngetrapake kasus panggunaan kayata indeksasi telusuran, panyimpenan data, lan alur kerja sing didorong acara. Ing ngisor iki ringkesan arsitektur tingkat dhuwur saka platform Delta.
Gambar 5. Arsitektur tingkat dhuwur Delta.
Matur suwun
We would like to thank the following people who were involved in the creation and development Delta at 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 and Zhenzhong Xu.
Sumber informasi
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Proses acara online. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Alat Gawe Data kanggo Panyimpenan Amazon Redshift."
Source: www.habr.com