Dalam jangkaan pelancaran aliran baharu pada kadar Kami telah menyediakan terjemahan bahan yang menarik.
Mengkaji
Kami akan bercakap tentang corak yang agak popular di mana aplikasi menggunakan pelbagai stor data, di mana setiap kedai digunakan untuk tujuannya sendiri, contohnya, untuk menyimpan bentuk data berkanun (MySQL, dll.), menyediakan keupayaan carian lanjutan (ElasticSearch, dll.) .), caching (Memcached, dll.) dan lain-lain. Biasanya, apabila menggunakan berbilang stor data, satu daripadanya bertindak sebagai stor utama dan yang lain sebagai stor derivatif. Satu-satunya masalah ialah bagaimana untuk menyegerakkan stor data ini.
Kami melihat beberapa corak berbeza yang cuba menyelesaikan masalah menyegerakkan berbilang kedai, seperti penulisan berganda, transaksi teragih, dsb. Walau bagaimanapun, pendekatan ini mempunyai had yang ketara dari segi penggunaan kehidupan sebenar, kebolehpercayaan dan penyelenggaraan. Selain penyegerakan data, sesetengah aplikasi juga perlu memperkayakan data dengan memanggil perkhidmatan luaran.
Delta dibangunkan untuk menyelesaikan masalah ini. Delta akhirnya menyediakan platform yang konsisten, dipacu peristiwa untuk penyegerakan dan pengayaan data.
Penyelesaian sedia ada
kemasukan berganda
Untuk memastikan dua stor data disegerakkan, anda boleh menggunakan dwi tulis, yang menulis ke satu kedai dan kemudian menulis kepada yang lain serta-merta selepas itu. Rakaman pertama boleh dicuba semula dan yang kedua boleh dibatalkan jika yang pertama gagal selepas bilangan percubaan telah habis. Walau bagaimanapun, kedua-dua stor data mungkin menjadi tidak segerak jika menulis ke kedai kedua gagal. Masalah ini biasanya diselesaikan dengan mencipta prosedur pemulihan yang boleh memindahkan semula data secara berkala dari storan pertama ke storan kedua, atau berbuat demikian hanya jika perbezaan dikesan dalam data.
Masalah:
Melaksanakan prosedur pemulihan ialah kerja khusus yang tidak boleh digunakan semula. Selain itu, data antara lokasi storan kekal tidak segerak sehingga prosedur pemulihan berlaku. Penyelesaian menjadi lebih kompleks jika lebih daripada dua stor data digunakan. Akhir sekali, prosedur pemulihan boleh menambah beban pada sumber data asal.
Tukar jadual log
Apabila perubahan berlaku pada set jadual (seperti memasukkan, mengemas kini dan memadam rekod), rekod perubahan ditambahkan pada jadual log sebagai sebahagian daripada transaksi yang sama. Urutan atau proses lain sentiasa meminta peristiwa daripada jadual log dan menulisnya ke satu atau lebih stor data, jika perlu, mengalih keluar peristiwa daripada jadual log selepas rekod disahkan oleh semua stor.
Masalah:
Corak ini harus dilaksanakan sebagai perpustakaan, dan idealnya tanpa mengubah kod aplikasi yang menggunakannya. Dalam persekitaran polyglot, pelaksanaan perpustakaan sedemikian harus wujud dalam mana-mana bahasa yang diperlukan, tetapi memastikan keselarasan fungsi dan tingkah laku merentas bahasa adalah sangat sukar.
Masalah lain terletak pada mendapatkan perubahan skema dalam sistem yang tidak menyokong perubahan skema transaksi [1][2], seperti MySQL. Oleh itu, corak membuat perubahan (contohnya, perubahan skema) dan merekodkannya secara transaksi dalam jadual log perubahan tidak akan sentiasa berfungsi.
Transaksi Teragih
Urus niaga yang diedarkan boleh digunakan untuk memisahkan transaksi merentas berbilang stor data heterogen supaya operasi itu sama ada komited kepada semua stor data yang digunakan atau tidak komited kepada mana-mana daripadanya.
Masalah:
Urus niaga teragih adalah masalah yang sangat besar untuk stor data heterogen. Mengikut sifat mereka, mereka hanya boleh bergantung pada penyebut sepunya terendah bagi sistem yang terlibat. Sebagai contoh, transaksi XA menyekat pelaksanaan jika proses permohonan gagal semasa fasa penyediaan. Selain itu, XA tidak menyediakan pengesanan jalan buntu atau menyokong skim kawalan serentak yang optimistik. Selain itu, sesetengah sistem seperti ElasticSearch tidak menyokong XA atau mana-mana model transaksi heterogen lain. Oleh itu, memastikan atomicity menulis dalam pelbagai teknologi penyimpanan data kekal sebagai tugas yang sangat mencabar untuk aplikasi [3].
Delta
Delta direka bentuk untuk menangani had penyelesaian penyegerakan data sedia ada dan juga membolehkan pengayaan data segera. Matlamat kami adalah untuk mengasingkan semua kerumitan ini daripada pembangun aplikasi supaya mereka dapat menumpukan sepenuhnya pada pelaksanaan fungsi perniagaan. Seterusnya kami akan menerangkan "Carian Filem", kes penggunaan sebenar untuk Delta Netflix.
Netflix secara meluas menggunakan seni bina perkhidmatan mikro, dan setiap perkhidmatan mikro biasanya menyediakan satu jenis data. Maklumat asas tentang filem terkandung dalam perkhidmatan mikro yang dipanggil Movie Service, dan data berkaitan, seperti maklumat tentang pengeluar, pelakon, vendor dan sebagainya, diuruskan oleh beberapa perkhidmatan mikro lain (iaitu Deal Service, Talent Service dan Vendor Service).
Pengguna perniagaan di Netflix Studios selalunya perlu mencari merentas pelbagai kriteria filem, itulah sebabnya sangat penting bagi mereka untuk dapat mencari merentas semua data berkaitan filem.
Sebelum Delta, pasukan carian filem perlu menarik data daripada berbilang perkhidmatan mikro sebelum mengindeks data filem. Di samping itu, pasukan itu perlu membangunkan sistem yang akan mengemas kini indeks carian secara berkala dengan meminta perubahan daripada perkhidmatan mikro lain, walaupun tiada perubahan sama sekali. Sistem ini dengan cepat menjadi kompleks dan sukar untuk diselenggara.
Rajah 1. Sistem pengundian ke Delta
Selepas menggunakan Delta, sistem telah dipermudahkan kepada sistem dipacu peristiwa seperti yang ditunjukkan dalam rajah berikut. Acara CDC (Change-Data-Capture) dihantar ke topik Keystone Kafka menggunakan Delta-Connector. Aplikasi Delta yang dibina menggunakan Rangka Kerja Pemprosesan Delta Stream (berdasarkan Flink) menerima acara CDC daripada topik, memperkayakannya dengan memanggil perkhidmatan mikro lain, dan akhirnya menghantar data yang diperkaya ke indeks carian dalam Elasticsearch. Keseluruhan proses berlaku hampir dalam masa nyata, iaitu, sebaik sahaja perubahan dilakukan pada gudang data, indeks carian dikemas kini.
Rajah 2. Saluran paip data menggunakan Delta
Dalam bahagian berikut, kami akan menerangkan operasi Delta-Connector, yang bersambung ke storan dan menerbitkan acara CDC ke lapisan pengangkutan, yang merupakan infrastruktur penghantaran data masa nyata yang mengarahkan acara CDC ke topik Kafka. Dan pada penghujungnya, kita akan bercakap tentang rangka kerja pemprosesan aliran Delta, yang boleh digunakan oleh pembangun aplikasi untuk pemprosesan data dan logik pengayaan.
CDC (Ubah-Tangkapan Data)
Kami telah membangunkan perkhidmatan CDC yang dipanggil Delta-Connector, yang boleh menangkap perubahan komited daripada stor data dalam masa nyata dan menulisnya ke strim. Perubahan masa nyata diambil daripada log transaksi dan pembuangan storan. Lambakan digunakan kerana log transaksi biasanya tidak menyimpan keseluruhan sejarah perubahan. Perubahan biasanya bersiri sebagai acara Delta, jadi penerima tidak perlu risau tentang dari mana perubahan itu datang.
Delta-Connector menyokong beberapa ciri tambahan seperti:
- Keupayaan untuk menulis data output tersuai melepasi Kafka.
- Keupayaan untuk mengaktifkan pembuangan manual pada bila-bila masa untuk semua jadual, jadual tertentu atau untuk kunci utama tertentu.
- Lambakan boleh diambil semula dalam ketulan, jadi tidak perlu dimulakan semula sekiranya berlaku kegagalan.
- Tidak perlu meletakkan kunci di atas meja, yang sangat penting untuk memastikan trafik tulis pangkalan data tidak pernah disekat oleh perkhidmatan kami.
- Ketersediaan tinggi disebabkan kejadian berlebihan dalam Zon Ketersediaan AWS.
Kami kini menyokong MySQL dan Postgres, termasuk penggunaan pada AWS RDS dan Aurora. Kami juga menyokong Cassandra (multi-master). Anda boleh mengetahui butiran lanjut tentang Delta-Connector di sini .
Kafka dan lapisan pengangkutan
Lapisan pengangkutan acara Delta dibina pada perkhidmatan pemesejan platform .
Dari segi sejarah, siaran di Netflix telah dioptimumkan untuk kebolehaksesan dan bukannya umur panjang (lihat di bawah). ). Pertukaran itu ialah ketidakkonsistenan data broker yang berpotensi dalam pelbagai senario kelebihan. Sebagai contoh, pemilihan pemimpin yang tidak bersih bertanggungjawab ke atas penerima yang berpotensi mempunyai acara pendua atau hilang.
Dengan Delta, kami mahukan jaminan ketahanan yang lebih kukuh untuk memastikan penghantaran acara CDC ke kedai terbitan. Untuk tujuan ini, kami mencadangkan gugusan Kafka yang direka khas sebagai objek kelas pertama. Anda boleh melihat beberapa tetapan broker dalam jadual di bawah:
Dalam kelompok Keystone Kafka, pemilihan pemimpin yang tidak bersih biasanya disertakan untuk memastikan kebolehaksesan penerbit. Ini boleh mengakibatkan kehilangan mesej jika replika yang tidak disegerakkan dipilih sebagai ketua. Untuk kluster Kafka ketersediaan tinggi baharu, pilihan pemilihan pemimpin yang tidak bersih dimatikan untuk mengelakkan kehilangan mesej.
Kami juga meningkat faktor replikasi dari 2 hingga 3 dan replika insync minimum 1 hingga 2. Penerbit yang menulis kepada kluster ini memerlukan acks daripada semua yang lain, memastikan 2 daripada 3 replika mempunyai mesej terkini yang dihantar oleh penerbit.
Apabila contoh broker ditamatkan, contoh baharu menggantikan yang lama. Walau bagaimanapun, broker baharu perlu mengejar replika yang tidak disegerakkan, yang mungkin mengambil masa beberapa jam. Untuk mengurangkan masa pemulihan untuk senario ini, kami mula menggunakan storan data blok (Kedai Blok Elastik Amazon) dan bukannya cakera broker tempatan. Apabila tika baharu menggantikan tika broker yang ditamatkan, ia melampirkan volum EBS yang dimiliki oleh tika yang ditamatkan itu dan mula mengejar mesej baharu. Proses ini mengurangkan masa pelepasan tunggakan dari jam ke minit kerana kejadian baharu tidak lagi perlu meniru daripada keadaan kosong. Secara keseluruhan, storan dan kitaran hayat broker yang berasingan mengurangkan kesan penukaran broker dengan ketara.
Untuk meningkatkan lagi jaminan penghantaran data, kami menggunakan untuk mengesan sebarang kehilangan mesej dalam keadaan yang melampau (contohnya, penyahsegerakan jam dalam ketua partition).
Rangka Kerja Pemprosesan Strim
Lapisan pemprosesan Delta dibina di atas platform Netflix SPaaS, yang menyediakan penyepaduan Apache Flink dengan ekosistem Netflix. Platform ini menyediakan antara muka pengguna yang menguruskan penempatan kerja Flink dan orkestrasi kelompok Flink di atas platform pengurusan kontena Titus kami. Antara muka juga mengurus konfigurasi kerja dan membenarkan pengguna membuat perubahan konfigurasi secara dinamik tanpa perlu menyusun semula kerja Flink.
Delta menyediakan rangka kerja pemprosesan strim berdasarkan Flink dan SPaaS yang menggunakan berasaskan anotasi DSL (Bahasa Khusus Domain) kepada butiran teknikal abstrak. Sebagai contoh, untuk menentukan langkah di mana peristiwa akan diperkaya dengan memanggil perkhidmatan luaran, pengguna perlu menulis DSL berikut, dan rangka kerja akan mencipta model berdasarkannya, yang akan dilaksanakan oleh Flink.
Rajah 3. Contoh pengayaan pada DSL dalam Delta
Rangka kerja pemprosesan bukan sahaja mengurangkan keluk pembelajaran, tetapi juga menyediakan ciri pemprosesan strim biasa seperti penyahduplikasian, penskematan dan fleksibiliti dan daya tahan untuk menyelesaikan masalah operasi biasa.
Rangka Kerja Pemprosesan Delta Stream terdiri daripada dua modul utama, modul DSL & API dan modul Runtime. Modul DSL & API menyediakan API DSL dan UDF (User-Defined-Function) supaya pengguna boleh menulis logik pemprosesan mereka sendiri (seperti penapisan atau transformasi). Modul Runtime menyediakan pelaksanaan penghurai DSL yang membina perwakilan dalaman langkah pemprosesan dalam model DAG. Komponen Pelaksanaan mentafsir model DAG untuk memulakan pernyataan Flink sebenar dan akhirnya menjalankan aplikasi Flink. Seni bina rangka kerja digambarkan dalam rajah berikut.
Rajah 4. Seni bina Rangka Kerja Pemprosesan Delta Stream
Pendekatan ini mempunyai beberapa kelebihan:
- Pengguna boleh menumpukan pada logik perniagaan mereka tanpa perlu menyelidiki secara spesifik Flink atau struktur SPaaS.
- Pengoptimuman boleh dilakukan dengan cara yang telus kepada pengguna, dan ralat boleh diperbaiki tanpa memerlukan sebarang perubahan pada kod pengguna (UDF).
- Pengalaman aplikasi Delta dipermudahkan untuk pengguna kerana platform menyediakan fleksibiliti dan daya tahan di luar kotak dan mengumpulkan pelbagai metrik terperinci yang boleh digunakan untuk makluman.
Penggunaan pengeluaran
Delta telah dikeluarkan selama lebih setahun dan memainkan peranan penting dalam banyak aplikasi Netflix Studio. Dia membantu pasukan melaksanakan kes penggunaan seperti pengindeksan carian, storan data dan aliran kerja terdorong peristiwa. Di bawah ialah gambaran keseluruhan seni bina peringkat tinggi platform Delta.
Rajah 5. Seni bina peringkat tinggi Delta.
Ucapan terima kasih
Kami ingin mengucapkan terima kasih kepada orang berikut yang terlibat dalam penciptaan dan pembangunan 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: Pemprosesan acara dalam talian. Commun. ACM 62(5): 43β49 (2019). DOI:
: βAlat Bina Data untuk Storan Amazon Redshift.β
Sumber: www.habr.com