Untuk mengantisipasi peluncuran aliran baru di rate Kami telah menyiapkan terjemahan materi yang menarik.
Tinjau
Kita akan berbicara tentang pola yang cukup populer di mana aplikasi menggunakan beberapa penyimpanan data, di mana setiap penyimpanan digunakan untuk tujuannya masing-masing, misalnya, untuk menyimpan data dalam bentuk kanonik (MySQL, dll.), menyediakan kemampuan pencarian lanjutan (ElasticSearch, dll.) .), caching (Memcached, dll.) dan lain-lain. Biasanya, saat menggunakan beberapa penyimpanan data, salah satunya bertindak sebagai penyimpanan utama dan yang lainnya sebagai penyimpanan turunan. Satu-satunya masalah adalah bagaimana menyinkronkan penyimpanan data ini.
Kami melihat sejumlah pola berbeda yang mencoba memecahkan masalah sinkronisasi beberapa penyimpanan, seperti penulisan ganda, transaksi terdistribusi, dll. Namun, pendekatan ini memiliki keterbatasan yang signifikan dalam hal penggunaan, keandalan, dan pemeliharaan di kehidupan nyata. Selain sinkronisasi data, beberapa aplikasi juga perlu memperkaya data dengan memanggil layanan eksternal.
Delta dikembangkan untuk mengatasi masalah ini. Delta pada akhirnya menyediakan platform yang konsisten dan berbasis peristiwa untuk sinkronisasi dan pengayaan data.
Solusi yang ada
Pembukuan rangkap
Untuk menjaga dua penyimpanan data tetap sinkron, Anda dapat menggunakan penulisan ganda, yang menulis ke satu penyimpanan dan kemudian menulis ke penyimpanan lainnya segera setelahnya. Perekaman pertama dapat dicoba ulang dan rekaman kedua dapat dibatalkan jika rekaman pertama gagal setelah jumlah percobaan habis. Namun, kedua penyimpanan data mungkin menjadi tidak sinkron jika penulisan ke penyimpanan kedua gagal. Masalah ini biasanya diselesaikan dengan membuat prosedur pemulihan yang secara berkala dapat mentransfer kembali data dari penyimpanan pertama ke penyimpanan kedua, atau melakukannya hanya jika ditemukan perbedaan dalam data.
Masalahnya adalah:
Melakukan prosedur pemulihan adalah pekerjaan khusus yang tidak dapat digunakan kembali. Selain itu, data antar lokasi penyimpanan tetap tidak sinkron hingga prosedur pemulihan dilakukan. Solusinya menjadi lebih kompleks jika lebih dari dua penyimpanan data digunakan. Terakhir, prosedur pemulihan dapat menambah beban pada sumber data asli.
Ubah tabel log
Ketika perubahan terjadi pada sekumpulan tabel (seperti menyisipkan, memperbarui, dan menghapus catatan), catatan perubahan ditambahkan ke tabel log sebagai bagian dari transaksi yang sama. Thread atau proses lain secara konstan meminta kejadian dari tabel log dan menuliskannya ke satu atau lebih penyimpanan data, jika perlu, menghapus kejadian dari tabel log setelah catatan dikonfirmasi oleh semua penyimpanan.
Masalahnya adalah:
Pola ini harus diimplementasikan sebagai perpustakaan dan, idealnya, tanpa mengubah kode aplikasi yang menggunakannya. Dalam lingkungan poliglot, implementasi perpustakaan semacam itu harus ada dalam bahasa apa pun yang diperlukan, tetapi sangat sulit untuk memastikan konsistensi fungsionalitas dan perilaku antar bahasa.
Masalah lainnya terletak pada perolehan perubahan skema pada sistem yang tidak mendukung perubahan skema transaksional [1] [2], seperti MySQL. Oleh karena itu, pola melakukan perubahan (misalnya perubahan skema) dan mencatatnya secara transaksional dalam tabel log perubahan tidak akan selalu berhasil.
Transaksi Terdistribusi
Transaksi terdistribusi dapat digunakan untuk membagi transaksi ke beberapa penyimpanan data yang heterogen sehingga operasi dapat dilakukan pada semua penyimpanan data yang digunakan, atau tidak dilakukan pada salah satu penyimpanan tersebut.
Masalahnya adalah:
Transaksi terdistribusi adalah masalah yang sangat besar bagi penyimpanan data yang heterogen. Berdasarkan sifatnya, mereka hanya dapat mengandalkan common denominator terendah dari sistem yang terlibat. Misalnya, transaksi XA memblokir eksekusi jika proses aplikasi gagal selama tahap persiapan. Selain itu, XA tidak menyediakan deteksi kebuntuan atau mendukung skema kontrol konkurensi optimis. Selain itu, beberapa sistem seperti ElasticSearch tidak mendukung XA atau model transaksi heterogen lainnya. Dengan demikian, memastikan atomisitas penulisan dalam berbagai teknologi penyimpanan data tetap menjadi tugas yang sangat menantang bagi aplikasi [3].
Delta
Delta dirancang untuk mengatasi keterbatasan solusi sinkronisasi data yang ada dan juga memungkinkan pengayaan data saat itu juga. Tujuan kami adalah untuk menghilangkan semua kerumitan ini dari pengembang aplikasi sehingga mereka dapat sepenuhnya fokus pada penerapan fungsi bisnis. Selanjutnya kami akan menjelaskan "Pencarian Film", kasus penggunaan sebenarnya untuk Delta Netflix.
Netflix banyak menggunakan arsitektur layanan mikro, dan setiap layanan mikro biasanya melayani satu jenis data. Informasi dasar tentang film terdapat pada sebuah microservice bernama Movie Service, dan data terkait seperti informasi tentang produser, aktor, vendor, dan lain sebagainya dikelola oleh beberapa microservice lainnya (yaitu Deal Service, Talent Service, dan Vendor Service).
Pengguna bisnis di Netflix Studios sering kali perlu mencari di berbagai kriteria film, itulah sebabnya sangat penting bagi mereka untuk dapat mencari di semua data terkait film.
Sebelum Delta, tim pencarian film perlu mengambil data dari beberapa layanan mikro sebelum mengindeks data film. Selain itu, tim harus mengembangkan sistem yang secara berkala memperbarui indeks pencarian dengan meminta perubahan dari layanan mikro lainnya, meskipun tidak ada perubahan sama sekali. Sistem ini dengan cepat menjadi rumit dan sulit dipelihara.
Gambar 1. Sistem pemungutan suara ke Delta
Setelah menggunakan Delta, sistem disederhanakan menjadi sistem event-driven seperti yang ditunjukkan pada gambar berikut. Peristiwa CDC (Change-Data-Capture) dikirim ke topik Keystone Kafka menggunakan Delta-Connector. Aplikasi Delta yang dibangun menggunakan Delta Stream Processing Framework (berdasarkan Flink) menerima kejadian CDC dari suatu topik, memperkayanya dengan memanggil layanan mikro lainnya, dan akhirnya meneruskan data yang diperkaya ke indeks pencarian di Elasticsearch. Seluruh proses berlangsung hampir secara real time, yaitu, segera setelah perubahan dilakukan pada gudang data, indeks pencarian diperbarui.
Gambar 2. Pipeline data menggunakan Delta
Di bagian berikut, kami akan menjelaskan pengoperasian Delta-Connector, yang menghubungkan ke penyimpanan dan menerbitkan peristiwa CDC ke lapisan transport, yang merupakan infrastruktur transmisi data real-time yang merutekan peristiwa CDC ke topik Kafka. Dan pada bagian akhir, kita akan membahas tentang kerangka pemrosesan aliran Delta, yang dapat digunakan oleh pengembang aplikasi untuk pemrosesan data dan logika pengayaan.
CDC (Ubah-Pengambilan Data)
Kami telah mengembangkan layanan CDC yang disebut Delta-Connector, yang dapat menangkap perubahan yang dilakukan dari penyimpanan data secara real-time dan menuliskannya ke aliran. Perubahan waktu nyata diambil dari log transaksi dan dump penyimpanan. Dumps digunakan karena log transaksi biasanya tidak menyimpan seluruh riwayat perubahan. Perubahan biasanya diserialkan sebagai peristiwa Delta, sehingga penerima tidak perlu khawatir tentang dari mana perubahan itu berasal.
Delta-Connector mendukung beberapa fitur tambahan seperti:
- Kemampuan untuk menulis data keluaran khusus melewati Kafka.
- Kemampuan untuk mengaktifkan dump manual kapan saja untuk semua tabel, tabel tertentu, atau untuk kunci utama tertentu.
- Dump dapat diambil dalam beberapa bagian, jadi tidak perlu memulai dari awal lagi jika terjadi kegagalan.
- Tidak perlu mengunci tabel, yang sangat penting untuk memastikan lalu lintas penulisan database tidak pernah diblokir oleh layanan kami.
- Ketersediaan tinggi karena instans redundan di AWS Availability Zone.
Saat ini kami mendukung MySQL dan Postgres, termasuk penerapan di AWS RDS dan Aurora. Kami juga mendukung Cassandra (multi-master). Anda dapat mengetahui detail lebih lanjut tentang Delta-Connector di sini .
Kafka dan lapisan transport
Lapisan transport acara Delta dibangun pada layanan pesan platform .
Secara historis, postingan di Netflix telah dioptimalkan untuk aksesibilitas dibandingkan umur panjang (lihat di bawah). ). Dampaknya adalah potensi inkonsistensi data broker dalam berbagai skenario edge. Misalnya, pemilihan pemimpin yang tidak bersih bertanggung jawab atas penerima yang berpotensi mengalami duplikat atau kehilangan acara.
Dengan Delta, kami menginginkan jaminan ketahanan yang lebih kuat untuk memastikan pengiriman acara CDC ke toko turunannya. Untuk tujuan ini, kami mengusulkan cluster Kafka yang dirancang khusus sebagai objek kelas satu. Anda dapat melihat beberapa pengaturan broker pada tabel di bawah ini:
Di cluster Keystone Kafka, pemilihan pemimpin yang tidak bersih biasanya disertakan untuk memastikan aksesibilitas penerbit. Hal ini dapat mengakibatkan hilangnya pesan jika replika yang tidak disinkronkan terpilih sebagai pemimpin. Untuk klaster Kafka dengan ketersediaan tinggi yang baru, opsinya pemilihan pemimpin yang tidak bersih dimatikan untuk mencegah hilangnya pesan.
Kami juga meningkat faktor replikasi dari 2 hingga 3 dan replika insync minimum 1 hingga 2. Penerbit yang menulis ke klaster ini memerlukan persetujuan dari semua penerbit lainnya, untuk memastikan bahwa 2 dari 3 replika memiliki pesan terbaru yang dikirim oleh penerbit.
Ketika sebuah instance broker berakhir, sebuah instance baru menggantikan yang lama. Namun, broker baru harus mengejar replika yang tidak disinkronkan, yang mungkin memerlukan waktu beberapa jam. Untuk mengurangi waktu pemulihan skenario ini, kami mulai menggunakan penyimpanan data blok (Amazon Elastic Block Store) alih-alih disk broker lokal. Ketika sebuah instance baru menggantikan instance broker yang dihentikan, instance tersebut akan melampirkan volume EBS yang dimiliki oleh instance yang dihentikan tersebut dan mulai menerima pesan-pesan baru. Proses ini mengurangi waktu pembersihan backlog dari jam menjadi menit karena instance baru tidak perlu lagi mereplikasi dari keadaan kosong. Secara umum, penyimpanan terpisah dan siklus hidup broker secara signifikan mengurangi dampak peralihan broker.
Untuk lebih meningkatkan jaminan pengiriman data, kami menggunakan untuk mendeteksi hilangnya pesan dalam kondisi ekstrem (misalnya, desinkronisasi jam di pemimpin partisi).
Kerangka Pemrosesan Aliran
Lapisan pemrosesan Delta dibangun di atas platform Netflix SPaaS, yang menyediakan integrasi Apache Flink dengan ekosistem Netflix. Platform ini menyediakan antarmuka pengguna yang mengelola penerapan pekerjaan Flink dan orkestrasi klaster Flink di atas platform manajemen kontainer Titus kami. Antarmuka juga mengelola konfigurasi pekerjaan dan memungkinkan pengguna membuat perubahan konfigurasi secara dinamis tanpa harus mengkompilasi ulang pekerjaan Flink.
Delta menyediakan kerangka pemrosesan aliran berdasarkan Flink dan SPaaS yang digunakan berbasis anotasi DSL (Bahasa Khusus Domain) untuk abstrak detail teknis. Misalnya, untuk menentukan langkah di mana peristiwa akan diperkaya dengan memanggil layanan eksternal, pengguna perlu menulis DSL berikut, dan kerangka kerja akan membuat model berdasarkan DSL tersebut, yang akan dieksekusi oleh Flink.
Gambar 3. Contoh pengayaan DSL di Delta
Kerangka kerja pemrosesan tidak hanya mengurangi kurva pembelajaran, tetapi juga menyediakan fitur pemrosesan aliran umum seperti deduplikasi, skema, serta fleksibilitas dan ketahanan untuk memecahkan masalah operasional umum.
Delta Stream Processing Framework terdiri dari dua modul utama, modul DSL & API dan modul Runtime. Modul DSL & API menyediakan API DSL dan UDF (Fungsi Buatan Pengguna) sehingga pengguna dapat menulis logika pemrosesan mereka sendiri (seperti pemfilteran atau transformasi). Modul Runtime menyediakan implementasi parser DSL yang membangun representasi internal langkah-langkah pemrosesan dalam model DAG. Komponen Eksekusi menafsirkan model DAG untuk menginisialisasi pernyataan Flink yang sebenarnya dan pada akhirnya menjalankan aplikasi Flink. Arsitektur kerangka diilustrasikan pada gambar berikut.
Gambar 4. Arsitektur Delta Stream Processing Framework
Pendekatan ini memiliki beberapa keuntungan:
- Pengguna dapat fokus pada logika bisnis mereka tanpa harus mempelajari secara spesifik Flink atau struktur SPaaS.
- Optimasi dapat dilakukan dengan cara yang transparan bagi pengguna, dan kesalahan dapat diperbaiki tanpa memerlukan perubahan apa pun pada kode pengguna (UDF).
- Pengalaman aplikasi Delta disederhanakan bagi pengguna karena platform ini memberikan fleksibilitas dan ketahanan yang siap pakai serta mengumpulkan berbagai metrik terperinci yang dapat digunakan untuk peringatan.
Penggunaan produksi
Delta telah berproduksi selama lebih dari setahun dan memainkan peran penting dalam banyak aplikasi Netflix Studio. Dia membantu tim menerapkan kasus penggunaan seperti pengindeksan pencarian, penyimpanan data, dan alur kerja berbasis peristiwa. Di bawah ini adalah ikhtisar arsitektur tingkat tinggi platform Delta.
Gambar 5. Arsitektur tingkat tinggi Delta.
Ucapan Terima Kasih
Kami ingin mengucapkan terima kasih kepada orang-orang berikut yang terlibat dalam pembuatan dan pengembangan 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 dan Zhenzhong Xu.
sumber
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Pemrosesan acara online. Komunitas. ACM 62(5): 43β49 (2019). DOI:
: βAlat Pembuatan Data untuk Penyimpanan Amazon Redshift.β
Sumber: www.habr.com