Dina antisipasi peluncuran aliran anyar dina laju Kami parantos nyiapkeun tarjamahan tina bahan anu pikaresepeun.
gambaran
Urang bakal ngobrol ngeunaan pola anu cukup populér dimana aplikasi nganggo sababaraha toko data, dimana unggal toko dianggo pikeun tujuan sorangan, contona, pikeun nyimpen bentuk kanonik data (MySQL, jsb.), Nyadiakeun kamampuan milarian canggih (ElasticSearch, jsb.), Caching (Memcached, jsb) jeung sajabana. Biasana, nalika nganggo sababaraha toko data, salah sahijina janten toko primér sareng anu sanésna salaku toko turunan. Hiji-hijina masalah nyaéta kumaha nyingkronkeun toko data ieu.
Kami ningali sababaraha pola anu béda anu nyobian ngabéréskeun masalah nyingkronkeun sababaraha toko, sapertos nyerat ganda, transaksi anu disebarkeun, jsb. Nanging, pendekatan ieu gaduh watesan anu signifikan dina hal pamakean, réliabilitas, sareng pangropéa. Salian sinkronisasi data, sababaraha aplikasi ogé kudu ngabeungharan data ku nelepon ladenan éksternal.
Delta dikembangkeun pikeun ngajawab masalah ieu. Delta pamustunganana nyadiakeun konsisten, platform acara-disetir pikeun sinkronisasi data jeung pengayaan.
Solusi anu aya
Éntri ganda
Pikeun nyingkronkeun dua toko data, anjeun tiasa nganggo tulisan ganda, anu nyerat ka hiji toko teras nyerat ka toko anu sanés saatosna. Rekaman kahiji tiasa dicobian deui sareng anu kadua tiasa dibatalkeun upami anu kahiji gagal saatos jumlah usaha parantos béak. Nanging, dua toko data tiasa janten teu sinkron upami nyerat ka toko kadua gagal. Masalah ieu biasana direngsekeun ku nyieun prosedur recovery nu périodik bisa ulang mindahkeun data ti gudang kahiji ka kadua, atawa ngalakukeun kitu ngan lamun béda nu dideteksi dina data.
Masalah:
Ngalaksanakeun prosedur pamulihan mangrupikeun padamelan khusus anu henteu tiasa dianggo deui. Salaku tambahan, data antara lokasi panyimpenan tetep teu sinkron dugi ka prosedur pamulihan lumangsung. Solusina janten langkung kompleks upami dianggo langkung ti dua toko data. Tungtungna, prosedur pamulihan tiasa nambihan beban kana sumber data asli.
Robah tabel log
Nalika parobahan lumangsung dina sakumpulan tabel (sapertos ngalebetkeun, ngamutahirkeun, sareng mupus rékaman), rékaman parobihan ditambihkeun kana méja log salaku bagian tina transaksi anu sami. thread sejen atawa prosés terus requests acara ti tabel log jeung nulis ka hiji atawa leuwih toko data, lamun perlu, miceun kajadian tina tabel log sanggeus rékaman geus dikonfirmasi ku sakabeh toko.
Masalah:
Pola ieu kudu dilaksanakeun salaku perpustakaan, sarta ideally tanpa ngarobah kodeu aplikasi nu ngagunakeun eta. Dina lingkungan polyglot, palaksanaan perpustakaan sapertos kitu kedah aya dina basa anu diperyogikeun, tapi mastikeun konsistensi fungsionalitas sareng paripolah dina basa anu sesah pisan.
Masalah séjén nyaéta pikeun meunangkeun parobahan skéma dina sistem anu henteu ngadukung parobahan skéma transaksional [1][2], sapertos MySQL. Ku alatan éta, pola nyieun parobahan (contona, parobahan schema) jeung transactionally ngarekam dina tabel log robah moal salawasna jalan.
Transaksi anu disebarkeun
Transaksi anu disebarkeun tiasa dianggo pikeun ngabagi transaksi dina sababaraha toko data hétérogén supados operasi éta komitmen ka sadaya toko data anu dianggo, atanapi henteu komitmen ka salah sahijina.
Masalah:
Transaksi anu disebarkeun mangrupikeun masalah anu ageung pikeun toko data hétérogén. Dumasar sifatna, aranjeunna ngan ukur tiasa ngandelkeun pangbagi umum panghandapna tina sistem anu aub. Contona, transaksi XA meungpeuk palaksanaan lamun prosés aplikasi gagal salila fase persiapan. Sajaba ti, XA teu nyadiakeun deteksi deadlock atawa ngarojong skéma kontrol concurrency optimistis. Salaku tambahan, sababaraha sistem sapertos ElasticSearch henteu ngadukung XA atanapi modél transaksi hétérogén anu sanés. Ku kituna, mastikeun atomicity nulis dina sagala rupa téknologi panyimpen data tetep tugas pisan nangtang pikeun aplikasi [3].
Delta
Delta dirancang pikeun ngarengsekeun keterbatasan solusi sinkronisasi data anu tos aya sareng ogé ngaktifkeun pengayaan data on-the-fly. Tujuan kami nya éta pikeun abstrak sagala complexities ieu jauh ti pamekar aplikasi ambéh maranéhanana bisa pinuh difokuskeun ngalaksanakeun fungsionalitas bisnis. Salajengna urang bakal ngajéntrékeun "Panéangan Pilem", kasus pamakéan sabenerna pikeun Delta Netflix.
Netflix loba ngagunakeun arsitektur microservice, sarta unggal microservice ilaharna ngalayanan hiji tipe data. Inpormasi dasar ngeunaan film aya dina layanan mikro anu disebut Movie Service, sareng data anu aya hubunganana sapertos inpormasi ngeunaan produser, aktor, vendor, sareng sajabana diurus ku sababaraha jasa mikro anu sanés (nyaéta Deal Service, Talent Service and Vendor Service).
Pamaké bisnis di Netflix Studios sering kedah milarian dina sagala rupa kriteria pilem, naha éta penting pisan pikeun aranjeunna tiasa milarian sadaya data anu aya hubunganana sareng pilem.
Sateuacan Delta, tim pilarian pilem diperlukeun pikeun narik data ti sababaraha microservices saméméh indexing data pilem. Sajaba ti éta, tim kudu ngamekarkeun sistem anu périodik bakal ngamutahirkeun indéks pilarian ku requesting parobahan ti microservices séjén, sanajan aya euweuh parobahan pisan. Sistim ieu gancang jadi rumit sarta hésé pikeun mulasara.
angka 1. Sistim polling mun Delta
Sanggeus ngagunakeun Delta, sistem ieu disederhanakeun kana sistem acara disetir ditémbongkeun saperti dina gambar di handap ieu. CDC (Robah-Data-Capture) acara dikirim ka topik Keystone Kafka ngagunakeun Delta-Connector. Hiji aplikasi Delta diwangun ngagunakeun Delta Stream Processing Framework (dumasar kana Flink) narima acara CDC tina topik, enriches aranjeunna ku nelepon microservices séjén, sarta tungtungna ngalirkeun data enriched kana indéks pilarian di Elasticsearch. Sakabéh prosés lumangsung ampir sacara real waktos, nyaeta, pas parobahan anu komitmen ka gudang data, indexes pilarian diropéa.
Gambar 2. Pipa data ngagunakeun Delta
Dina bagian handap, urang bakal ngajelaskeun operasi tina Delta-Connector, nu nyambung ka gudang sarta publishes acara CDC kana lapisan angkutan, nu mangrupakeun real-time infrastruktur pangiriman data nu ruteu acara CDC kana topik Kafka. Sareng dina tungtungna, urang bakal ngobrol ngeunaan kerangka pamrosesan aliran Delta, anu tiasa dianggo ku pamekar aplikasi pikeun ngolah data sareng logika pengayaan.
CDC (Robah-Data-Capture)
Kami parantos ngembangkeun layanan CDC anu disebut Delta-Connector, anu tiasa nyandak parobihan komitmen tina toko data sacara real waktos sareng nyerat kana aliran. Parobihan sacara real-time dicandak tina log urus sareng dumps gudang. Dumps dipaké sabab log transaksi biasana henteu nyimpen sakabéh sajarah parobahan. Parobahan ilaharna serialized salaku acara Delta, jadi panarima teu kudu salempang ngeunaan ti mana parobahan asalna.
Delta-Connector ngadukung sababaraha fitur tambahan sapertos:
- Kamampuhan nulis data kaluaran custom kaliwat Kafka.
- Kamampuhan pikeun ngaktipkeun dumps manual iraha wae pikeun sakabéh tabel, tabel husus, atawa pikeun konci primér husus.
- Dumps tiasa dipulut dina sakumpulan, janten henteu kedah ngamimitian deui upami gagal.
- Teu kedah nempatkeun konci dina méja, anu penting pisan pikeun mastikeun yén lalu lintas nyerat database henteu pernah diblokir ku jasa kami.
- Kasadiaan luhur alatan instansi kaleuleuwihan dina Zona Kasadiaan AWS.
Kami ayeuna ngadukung MySQL sareng Postgres, kalebet panyebaran dina AWS RDS sareng Aurora. Urang ogé ngarojong Cassandra (multi-master). Anjeun tiasa mendakan langkung seueur rinci ngeunaan Delta-Connector Ieuh .
Kafka jeung lapisan angkutan
Lapisan angkutan acara Delta diwangun dina layanan olahtalatah platform .
Dina sajarahna, posting dina Netflix geus dioptimalkeun pikeun diakses tinimbang umur panjang (tempo di handap). ). Trade-off éta poténsi inconsistency data calo dina sagala rupa skenario ujung. Salaku conto, pemilihan pamimpin najis tanggung jawab panarima berpotensi gaduh duplikat atawa acara leungit.
Kalayan Delta, kami hoyong jaminan daya tahan anu langkung kuat pikeun mastikeun pangiriman acara CDC ka toko turunan. Pikeun tujuan ieu, kami ngajukeun klaster Kafka anu dirarancang khusus salaku obyék kelas munggaran. Anjeun tiasa ningali sababaraha setélan calo dina tabel di handap ieu:
Dina klaster Keystone Kafka, pemilihan pamimpin najis biasana kaasup pikeun mastikeun diakses penerbit. Ieu tiasa nyababkeun leungitna pesen upami réplika anu teu disinkronkeun kapilih janten pamimpin. Pikeun klaster Kafka kasadiaan tinggi anyar, pilihan pemilihan pamimpin najis dipareuman pikeun nyegah leungitna pesen.
Urang ogé ngaronjat faktor réplikasi ti 2 ka 3 jeung réplika insync minimum 1 ka 2. Penerbit nulis kana klaster ieu merlukeun acks ti sakabeh batur, mastikeun yén 2 ti 3 réplika boga pesen panganyarna dikirim ku penerbit.
Nalika hiji conto calo terminates, hiji instansi anyar ngagantikeun nu heubeul. Sanajan kitu, calo anyar bakal perlu nyekel up jeung réplika unsynchronized, nu bisa nyandak sababaraha jam. Pikeun ngirangan waktos pamulihan pikeun skenario ieu, urang mimitian nganggo panyimpen data blok (Amazon Elastic Block Store) tinimbang disk calo lokal. Nalika hiji instansi anyar ngagantikeun hiji conto calo terminated, eta nempelkeun volume EBS yén conto terminated kagungan tur mimitian nyekel up kalawan pesen anyar. Prosés ieu ngurangan waktu clearance backlog ti jam ka menit sabab instansi anyar euweuh perlu ngayakeun réplikasi tina kaayaan kosong. Gemblengna, panyimpen anu misah sareng siklus kahirupan calo sacara signifikan ngirangan dampak switching calo.
Pikeun ningkatkeun deui jaminan pangiriman data, kami nganggo pikeun ngadeteksi leungitna pesen dina kaayaan ekstrim (contona, desynchronization jam dina pamimpin partisi).
Stream Processing Framework
Lapisan pamrosesan Delta diwangun dina luhureun platform Netflix SPaaS, anu nyayogikeun integrasi Apache Flink sareng ékosistem Netflix. Platform éta nyayogikeun antarbeungeut pangguna anu ngatur panyebaran padamelan Flink sareng orkestrasi klaster Flink di luhur platform manajemén wadah Titus kami. Antarbeungeut ogé ngatur konfigurasi padamelan sareng ngamungkinkeun para pangguna ngarobih konfigurasi sacara dinamis tanpa kedah nyusun ulang padamelan Flink.
Delta nyayogikeun kerangka pamrosésan aliran dumasar kana Flink sareng SPaaS anu dianggo dumasar annotation DSL (Domain Spésifik Basa) pikeun abstrak rinci teknis. Contona, pikeun nangtukeun léngkah di mana acara bakal enriched ku nelepon jasa éksternal, pamaké kudu nulis DSL handap, sarta kerangka bakal nyieun model dumasar kana eta, nu bakal dieksekusi ku Flink.
Gambar 3. Conto pengayaan dina DSL di Delta
Kerangka pangolahan henteu ngan ukur ngirangan kurva diajar, tapi ogé nyayogikeun fitur pamrosésan aliran umum sapertos deduplikasi, skématisasi, sareng kalenturan sareng ketahanan pikeun ngarengsekeun masalah operasional umum.
Delta Stream Processing Framework diwangun ku dua modul konci, modul DSL & API jeung modul Runtime. Modul DSL & API nyayogikeun API DSL sareng UDF (User-Defined-Function) supados pangguna tiasa nyerat logika pamrosésan sorangan (sapertos nyaring atanapi transformasi). Modul Runtime nyayogikeun palaksanaan parser DSL anu ngawangun perwakilan internal léngkah ngolah dina modél DAG. Komponén Palaksanaan napsirkeun modél DAG pikeun ngamimitian pernyataan Flink anu saleresna sareng pamustunganana ngajalankeun aplikasi Flink. Arsitéktur kerangka digambarkeun dina gambar di handap ieu.
angka 4. arsitéktur Delta Stream Processing Framework
Pendekatan ieu ngagaduhan sababaraha kaunggulan:
- Pamaké tiasa museurkeun kana logika bisnisna tanpa kedah ngagali kana spésifik Flink atanapi struktur SPaaS.
- Optimasi tiasa dilakukeun ku cara anu transparan pikeun pangguna, sareng kasalahan tiasa dibenerkeun tanpa meryogikeun parobihan kana kode pangguna (UDF).
- Pangalaman aplikasi Delta disederhanakeun pikeun pangguna sabab platformna nyayogikeun kalenturan sareng kalenturan tina kotak sareng ngumpulkeun rupa-rupa métrik anu lengkep anu tiasa dianggo pikeun ngageter.
pamakéan produksi
Delta parantos produksi langkung ti sataun sareng maénkeun peran konci dina seueur aplikasi Netflix Studio. Anjeunna ngabantosan tim ngalaksanakeun kasus pamakean sapertos indexing milarian, neundeun data, sareng alur kerja anu didorong ku acara. Di handap ieu tinjauan arsitéktur tingkat luhur tina platform Delta.
angka 5. arsitektur-tingkat tinggi Delta urang.
Ngahaturkeun
Kami hoyong hatur nuhun ka jalma-jalma di handap ieu anu kalibet dina nyiptakeun sareng ngembangkeun Delta di 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 jeung Zhenzhong Xu.
sumber
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: processing acara online. Komun. ACM 62(5): 43–49 (2019). DOI:
: "Alat Ngawangun Data pikeun Panyimpenan Redshift Amazon."
sumber: www.habr.com