👶 🔦 ❌ Delta: Platform Sinkronisasi Data dan Pengayaan 🔰 🍲 👨🏽‍💻

Untuk mengantisipasi peluncuran aliran baru di kursus Data Engineer, kami menyiapkan terjemahan materi yang menarik.

Gambaran

Kami akan berbicara tentang pola yang cukup populer di mana aplikasi menggunakan beberapa penyimpanan data, di mana setiap toko digunakan untuk keperluannya sendiri, misalnya, untuk menyimpan bentuk data kanonik (MySQL, dll.), Menyediakan kemampuan pencarian lanjutan (ElasticSearch, dll. .), caching (Memcached, dll.) dan lainnya. Biasanya, ketika menggunakan beberapa penyimpanan data, salah satunya berfungsi sebagai penyimpanan utama, dan yang lainnya sebagai penyimpanan derivatif. Satu-satunya masalah adalah bagaimana menyinkronkan penyimpanan data ini.

Kami melihat sejumlah pola berbeda yang mencoba memecahkan masalah sinkronisasi beberapa repositori, seperti entri ganda, transaksi terdistribusi, dll. Namun, pendekatan ini memiliki keterbatasan yang signifikan dalam hal penggunaan kehidupan nyata, keandalan, dan pemeliharaan. Selain sinkronisasi data, beberapa aplikasi juga perlu memperkaya data dengan menggunakan layanan eksternal.

Untuk mengatasi masalah ini, Delta dikembangkan. Delta pada akhirnya adalah platform konsisten yang didorong oleh peristiwa untuk menyinkronkan dan memperkaya data.

Solusi yang ada

Entri ganda

Untuk menyinkronkan dua penyimpanan data, Anda dapat menggunakan perekaman ganda, yang menulis ke satu toko, dan kemudian segera menulis ke yang lain. Rekor pertama dapat diulang, dan yang kedua dapat diinterupsi jika yang pertama gagal setelah melelahkan jumlah upaya. Namun, dua penyimpanan data mungkin berhenti menyinkronkan 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 melakukan ini hanya jika terdapat perbedaan dalam data tersebut.

Masalah:

Melakukan prosedur pemulihan adalah pekerjaan tertentu yang tidak dapat digunakan kembali. Selain itu, data antara penyimpanan tetap tidak sinkron sampai prosedur pemulihan selesai. Solusinya rumit jika lebih dari dua penyimpanan data digunakan. Akhirnya, prosedur pemulihan dapat menambah tekanan pada sumber data asli.

Ubah Tabel Log

Ketika perubahan terjadi dalam satu set tabel (misalnya, menyisipkan, memperbarui, dan menghapus catatan), catatan perubahan ditambahkan ke tabel log sebagai bagian dari transaksi yang sama. Utas atau proses lain terus-menerus meminta acara dari tabel log dan menulisnya ke satu atau beberapa penyimpanan data, ketika menjadi perlu untuk menghapus acara dari tabel log setelah mengonfirmasi catatan oleh semua penyimpanan.

Masalah:

Pola ini harus diterapkan sebagai perpustakaan dan, idealnya, tanpa mengubah kode aplikasi yang menggunakannya. Dalam lingkungan polyglot, implementasi perpustakaan seperti itu harus ada dalam bahasa yang diperlukan, tetapi sangat sulit untuk memastikan koordinasi fungsi dan perilaku antar bahasa.

Masalah lain terletak pada mendapatkan perubahan skema dalam sistem yang tidak mendukung perubahan skema transaksional [1] [2], seperti MySQL. Oleh karena itu, templat untuk membuat perubahan (misalnya, mengubah skema) dan menulisnya ke tabel log perubahan tidak akan selalu berfungsi.

Transaksi Terdistribusi

Transaksi terdistribusi dapat digunakan untuk membagi transaksi antara beberapa penyimpanan data yang heterogen sehingga operasi dilakukan di semua toko yang digunakan atau tidak dilakukan di salah satu dari mereka.

Masalah:

Transaksi terdistribusi adalah masalah yang sangat besar untuk gudang data yang heterogen. Secara alami, mereka hanya dapat mengandalkan penyebut terkecil yang sama dari sistem yang terlibat. Misalnya, transaksi XA memblokir eksekusi jika terjadi kegagalan selama proses persiapan. Selain itu, XA tidak menyediakan deteksi kebuntuan dan tidak mendukung skema manajemen konkurensi optimis. Selain itu, beberapa sistem seperti ElasticSearch tidak mendukung XA atau model transaksi heterogen lainnya. Dengan demikian, memastikan keaslian rekaman dalam berbagai teknologi penyimpanan data tetap menjadi tugas yang sangat sulit untuk aplikasi [3].

Delta

Delta dirancang untuk mengatasi keterbatasan solusi sinkronisasi data yang ada, dan juga memperkaya data dengan cepat. Tujuan kami adalah untuk mengabstraksikan semua poin kompleks ini dari pengembang aplikasi sehingga mereka dapat sepenuhnya berkonsentrasi pada implementasi fungsionalitas bisnis. Selanjutnya, kami akan menjelaskan "Pencarian Film," kasus penggunaan aktual untuk Netflix Delta.

Netflix menggunakan arsitektur microservice secara ekstensif dan setiap microservice biasanya melayani satu jenis data. Informasi utama tentang film diambil dalam layanan microser yang disebut Movie Service, serta data terkait, seperti informasi tentang produser, aktor, vendor, dan sebagainya, dikelola oleh beberapa layanan microser lainnya (yaitu, Layanan Deal, Layanan Talenta, dan Layanan Vendor).
Pengguna bisnis di Netflix Studios sering perlu mencari dengan berbagai kriteria untuk film, oleh karena itu sangat penting bagi mereka untuk dapat mencari semua data yang terkait dengan 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 akan memperbarui indeks pencarian, meminta perubahan dari layanan microser lainnya, bahkan jika tidak ada perubahan sama sekali. Sistem ini dengan cepat menjadi ditumbuhi kompleksitas dan menjadi sulit dipertahankan.

Gambar 1. Sistem polling sebelum Delta
Setelah menggunakan Delta, sistem disederhanakan menjadi sistem event-driven, seperti yang ditunjukkan pada gambar berikut. Acara 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 topik, memperkaya mereka, memanggil layanan microser lainnya, dan akhirnya meneruskan data yang diperkaya ke indeks pencarian di Elasticsearch. Seluruh proses berlangsung hampir secara real time, yaitu, segera setelah perubahan dicatat dalam data warehouse, indeks pencarian diperbarui.

Gambar 2. Jalur pipa data menggunakan Delta
Pada bagian berikut, kami menjelaskan pekerjaan Delta-Connector, yang menghubungkan ke repositori dan menerbitkan acara CDC di tingkat transportasi, yang merupakan infrastruktur transmisi data real-time yang mengarahkan acara CDC ke topik Kafka. Dan pada akhirnya, kita akan berbicara tentang kerangka pemrosesan aliran Delta yang dapat digunakan pengembang aplikasi untuk pemrosesan dan pengayaan logika.

CDC (Ubah-Data-Capture)

Kami telah mengembangkan layanan CDC yang disebut Delta-Connector, yang dapat menangkap perubahan yang dilakukan dari penyimpanan data secara real time dan menuliskannya ke stream. Perubahan waktu nyata diambil dari log transaksi dan tempat penyimpanan. Dump digunakan karena log transaksi biasanya tidak menyimpan seluruh riwayat perubahan. Perubahan biasanya diserialisasi sebagai peristiwa Delta, sehingga penerima tidak perlu khawatir tentang dari mana perubahan itu berasal.

Delta-Connector mendukung beberapa fitur tambahan, seperti:

Kemampuan untuk menulis keluaran khusus melewati Kafka.
Kemampuan untuk mengaktifkan dump manual kapan saja untuk semua tabel, tabel tertentu atau untuk kunci primer tertentu.
Dump dapat diambil dengan potongan, sehingga tidak perlu memulai dari awal lagi jika terjadi kegagalan.
Tidak perlu meletakkan kunci di atas meja, yang sangat penting agar lalu lintas tulis ke basis data tidak pernah diblokir oleh layanan kami.
Ketersediaan tinggi karena cadangan di Zona Ketersediaan AWS.

Kami saat ini mendukung MySQL dan Postgres, termasuk penyebaran ke AWS RDS dan Aurora. Kami juga mendukung Cassandra (multi-master). Anda dapat mempelajari lebih lanjut tentang Delta-Connector di blog ini .

Tingkat kafka dan transportasi

Lapisan Transport Acara Delta dibangun di atas layanan pengiriman pesan platform Keystone .

Jadi secara historis, posting di Netflix telah dioptimalkan untuk meningkatkan ketersediaan daripada umur panjang (lihat artikel sebelumnya ). Kompromi adalah potensi inkonsistensi data broker dalam berbagai skenario perbatasan. Misalnya, pemilihan pemimpin yang tidak bersih bertanggung jawab untuk memastikan bahwa penerima berpotensi menduplikasi atau kehilangan acara.

Dengan Delta, kami ingin mendapatkan jaminan ketahanan yang lebih kuat untuk memastikan pengiriman acara CDC ke penyimpanan turunan. Untuk melakukan ini, kami mengusulkan kluster Kafka yang dirancang khusus sebagai objek kelas satu. Anda dapat melihat beberapa pengaturan broker pada tabel di bawah ini:

Di kluster Keystone Kafka, pemilihan pemimpin yang tidak bersih biasanya diaktifkan untuk memastikan ketersediaan penerbit. Ini dapat mengakibatkan hilangnya pesan jika replika yang tidak disinkronkan dipilih sebagai pemimpin. Untuk kluster Kafka baru yang sangat andal, opsi pemilihan pemimpin yang tidak bersih dinonaktifkan untuk mencegah hilangnya pesan.

Kami juga meningkatkan faktor replikasi dari 2 menjadi 3 dan replika insink minimumdari 1 hingga 2. Penerbit yang menulis ke kluster ini memerlukan acks dari semua yang lain, memastikan bahwa 2 dari 3 replika akan memiliki pesan terbaru yang dikirim oleh penerbit.

Ketika instance broker keluar, instance baru menggantikan yang lama. Namun, broker baru perlu mengejar ketinggalan dengan replika yang tidak disinkronkan, yang bisa memakan waktu beberapa jam. Untuk mengurangi waktu pemulihan untuk skenario ini, kami mulai menggunakan Amazon Elastic Block Store alih-alih disk broker lokal. Ketika instance baru menggantikan instance broker yang sudah selesai, itu akan melampirkan volume EBS yang dimiliki instance yang sudah selesai dan mulai mengejar ketinggalan dengan pesan baru. Proses ini mengurangi waktu untuk menghilangkan simpanan dari beberapa jam menjadi beberapa menit, karena instance baru tidak perlu lagi direplikasi dari keadaan kosong. Secara umum, penyimpanan terpisah dan siklus masa pakai broker secara signifikan mengurangi efek perubahan broker.

Untuk lebih meningkatkan jaminan pengiriman data, kami menggunakan sistem pelacakan pesan untuk mendeteksi hilangnya pesan dalam kondisi ekstrem (misalnya, sinkronisasi jam pada pemimpin bagian).

Kerangka pemrosesan aliran

Tingkat pemrosesan di Delta didasarkan pada platform Netflix SPaaS, yang memungkinkan integrasi Apache Flink dengan ekosistem Netflix. Platform ini menyediakan antarmuka pengguna yang mengontrol penyebaran pekerjaan Flink dan orkestrasi cluster Flink di atas platform manajemen wadah Titus kami. Antarmuka juga mengelola konfigurasi pekerjaan dan memungkinkan pengguna untuk melakukan perubahan konfigurasi secara dinamis tanpa harus mengkompilasi ulang pekerjaan Flink.

Delta menyediakan kerangka pemrosesan aliran untuk data berbasis Flink dan SPaaS, yang menggunakan berbasis anotasiDSL (Domain Specific Language) untuk detail teknis abstrak. Misalnya, untuk menentukan langkah di mana peristiwa akan diperkaya dengan memanggil layanan eksternal, pengguna perlu menulis DSL berikutnya, dan kerangka kerja akan membuat model berdasarkan itu yang akan dijalankan Flink.

Gambar 3. Contoh pengayaan DSL di Delta

Kerangka pemrosesan tidak hanya memperpendek kurva belajar, tetapi juga menyediakan fungsi pemrosesan aliran umum, seperti deduplikasi, skematisasi, serta fleksibilitas dan toleransi kesalahan untuk menyelesaikan masalah umum di tempat kerja.

Kerangka Pemrosesan Stream Delta terdiri dari dua modul utama, modul DSL & API dan modul Runtime. Modul DSL & API menyediakan API DSL dan UDF (Fungsi yang Ditentukan Pengguna) sehingga pengguna dapat menulis logika pemrosesan mereka sendiri (seperti penyaringan atau transformasi). Modul Runtime menyediakan implementasi parser DSL, yang membangun representasi internal dari langkah-langkah pemrosesan dalam model DAG. Komponen Eksekusi menginterpretasikan model DAG untuk menginisialisasi pernyataan Flink yang sebenarnya dan akhirnya meluncurkan aplikasi Flink. Arsitektur kerangka diilustrasikan pada gambar berikut.

Gambar 4. Arsitektur Kerangka Pemrosesan Delta Stream

Pendekatan ini memiliki beberapa keunggulan:

- Flink SPaaS.
, - (UDF).
Delta , , .

Delta telah berproduksi selama lebih dari setahun dan memainkan peran kunci dalam banyak aplikasi Netflix Studio. Ini membantu tim menerapkan kasus penggunaan seperti pengindeksan pencarian, penyimpanan data, dan alur kerja berdasarkan kejadian. Berikut ini adalah ikhtisar arsitektur tingkat tinggi dari platform Delta.

Gambar 5. Arsitektur Delta tingkat tinggi.

Ucapan Terima Kasih

Kami ingin mengucapkan terima kasih kepada orang-orang berikut yang berkontribusi pada penciptaan 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

dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
dev.mysql.com/doc/refman/5.7/id/cannot-roll-back.html
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

: «Data Build Tool Amazon Redshift».

Delta: Platform Sinkronisasi Data dan Pengayaan