Kurs bo'yicha yangi oqim boshlanishini kutish bilan Biz qiziqarli materialning tarjimasini tayyorladik.
haqida umumiy ma'lumot
Biz ilovalar bir nechta ma'lumotlar do'konlaridan foydalanadigan juda mashhur model haqida gapiramiz, bu erda har bir do'kon o'z maqsadlari uchun ishlatiladi, masalan, ma'lumotlarning kanonik shaklini saqlash uchun (MySQL va boshqalar), kengaytirilgan qidiruv imkoniyatlarini ta'minlaydi (ElasticSearch, h.k.) .), keshlash (Memcached va boshqalar) va boshqalar. Odatda, bir nechta ma'lumotlar do'konlaridan foydalanilganda, ulardan biri asosiy do'kon, boshqalari esa lotin do'konlari sifatida ishlaydi. Bitta muammo bu ma'lumotlar do'konlarini qanday sinxronlashtirishdir.
Biz bir nechta do'konlarni sinxronlashtirish muammosini hal qilishga uringan bir qator turli xil naqshlarni ko'rib chiqdik, masalan, ikki marta yozish, taqsimlangan tranzaktsiyalar va boshqalar. Biroq, bu yondashuvlar real hayotda foydalanish, ishonchlilik va texnik xizmat ko'rsatish nuqtai nazaridan sezilarli cheklovlarga ega. Ma'lumotlarni sinxronlashdan tashqari, ba'zi ilovalar tashqi xizmatlarga qo'ng'iroq qilish orqali ham ma'lumotlarni boyitishi kerak.
Delta ushbu muammolarni hal qilish uchun ishlab chiqilgan. Delta oxir-oqibat ma'lumotlarni sinxronlashtirish va boyitish uchun izchil, voqealarga asoslangan platformani taqdim etadi.
Mavjud yechimlar
Ikki marta kirish
Ikkita ma'lumot do'konini sinxronlashtirish uchun siz bir do'konga yozadigan, so'ngra darhol boshqasiga yozadigan ikkita yozishdan foydalanishingiz mumkin. Agar urinishlar soni tugagandan so'ng birinchisi muvaffaqiyatsiz bo'lsa, birinchi yozuvni qayta urinib ko'rish va ikkinchisini to'xtatish mumkin. Biroq, agar ikkinchi do'konga yozish muvaffaqiyatsiz bo'lsa, ikkita ma'lumot do'koni sinxronlashtirilmasligi mumkin. Ushbu muammo odatda ma'lumotlarni birinchi xotiradan ikkinchisiga vaqti-vaqti bilan qayta o'tkazishi mumkin bo'lgan tiklash protsedurasini yaratish orqali hal qilinadi yoki faqat ma'lumotlarda farqlar aniqlangan taqdirda amalga oshiriladi.
Muammolar:
Qayta tiklash jarayonini bajarish - bu qayta ishlatib bo'lmaydigan muayyan ish. Bundan tashqari, saqlash joylari o'rtasidagi ma'lumotlar tiklash jarayoni amalga oshirilgunga qadar sinxronlashtirilmaydi. Agar ikkitadan ortiq ma'lumotlar ombori ishlatilsa, yechim yanada murakkablashadi. Nihoyat, tiklash jarayoni asl ma'lumotlar manbasiga yuk qo'shishi mumkin.
Jurnal jadvalini o'zgartirish
Jadvallar to'plamiga o'zgartirishlar kiritilganda (masalan, yozuvni qo'shish, yangilash va o'chirish), o'zgarishlar yozuvlari xuddi shu tranzaksiyaning bir qismi sifatida jurnal jadvaliga qo'shiladi. Boshqa bir oqim yoki jarayon doimiy ravishda jurnallar jadvalidan hodisalarni so'raydi va ularni bir yoki bir nechta ma'lumotlar omboriga yozadi, agar kerak bo'lsa, yozuv barcha do'konlar tomonidan tasdiqlanganidan keyin jurnal jadvalidan voqealarni olib tashlaydi.
Muammolar:
Ushbu naqsh kutubxona sifatida va uni ishlatadigan dastur kodini o'zgartirmasdan amalga oshirilishi kerak. Poliglot muhitida bunday kutubxonani amalga oshirish har qanday zarur tilda mavjud bo'lishi kerak, ammo tillar bo'ylab funksionallik va xatti-harakatlarning izchilligini ta'minlash juda qiyin.
Yana bir muammo MySQL kabi tranzaktsion sxema oʻzgarishlarini [1][2] qoʻllab-quvvatlamaydigan tizimlarda sxema oʻzgarishlarini olishdadir. Shuning uchun, o'zgartirish kiritish (masalan, sxemani o'zgartirish) va uni o'zgarishlar jurnali jadvalida tranzaksiya sifatida qayd etish tartibi har doim ham ishlamaydi.
Taqsimlangan operatsiyalar
Taqsimlangan tranzaktsiyalar tranzaktsiyani bir nechta heterojen ma'lumotlar do'konlari bo'ylab ajratish uchun ishlatilishi mumkin, shunda operatsiya barcha foydalanilgan ma'lumotlar do'konlari bilan bog'liq bo'ladi yoki ularning hech biriga bog'liq bo'lmaydi.
Muammolar:
Tarqalgan tranzaktsiyalar heterojen ma'lumotlar do'konlari uchun juda katta muammodir. O'z tabiatiga ko'ra, ular faqat ishtirok etayotgan tizimlarning eng past umumiy maxrajiga tayanishi mumkin. Misol uchun, agar dastur jarayoni tayyorgarlik bosqichida muvaffaqiyatsiz bo'lsa, XA tranzaksiyalari bajarilishini bloklaydi. Bundan tashqari, XA blokirovkani aniqlashni ta'minlamaydi yoki optimistik parallellikni boshqarish sxemalarini qo'llab-quvvatlamaydi. Bundan tashqari, ElasticSearch kabi ba'zi tizimlar XA yoki boshqa heterojen tranzaksiya modelini qo'llab-quvvatlamaydi. Shunday qilib, turli xil ma'lumotlarni saqlash texnologiyalarida yozish atomligini ta'minlash ilovalar uchun juda qiyin vazifa bo'lib qolmoqda [3].
Delta
Delta mavjud ma'lumotlarni sinxronlashtirish yechimlarining cheklovlarini hal qilish uchun ishlab chiqilgan va shuningdek, ma'lumotlarni tezkor boyitish imkonini beradi. Bizning maqsadimiz dastur ishlab chiquvchilardan barcha bu murakkablikni mavhumlashtirish edi, shunda ular biznes funksiyalarini amalga oshirishga to'liq e'tibor qaratishlari mumkin edi. Keyinchalik biz Netflix Deltasi uchun haqiqiy foydalanish holati bo'lgan "Film qidirish" ni tavsiflaymiz.
Netflix mikroservis arxitekturasidan keng foydalanadi va har bir mikroservis odatda bitta turdagi ma'lumotlarga xizmat qiladi. Film haqidagi asosiy ma'lumotlar Movie Service deb nomlangan mikroservisda mavjud va prodyuserlar, aktyorlar, sotuvchilar va boshqalar haqidagi ma'lumotlar kabi ma'lumotlar boshqa bir qancha mikroservislar (masalan, Deal Service, Talent Service va Vendor Service) tomonidan boshqariladi.
Netflix Studios-dagi biznes foydalanuvchilari ko'pincha turli film mezonlari bo'yicha qidirishlari kerak, shuning uchun ular filmga oid barcha ma'lumotlarni qidirish imkoniyatiga ega bo'lishlari juda muhimdir.
Delta'dan oldin kino qidiruv guruhi film ma'lumotlarini indekslashdan oldin bir nechta mikroservislardan ma'lumotlarni olishi kerak edi. Bundan tashqari, jamoa boshqa mikroservislardan, hatto umuman o'zgarishlar bo'lmasa ham, o'zgarishlarni so'rash orqali qidiruv indeksini vaqti-vaqti bilan yangilab turadigan tizimni ishlab chiqishi kerak edi. Ushbu tizim tezda murakkablashdi va uni saqlash qiyin bo'ldi.
Shakl 1. Deltaga ovoz berish tizimi
Delta-dan foydalangandan so'ng, tizim quyidagi rasmda ko'rsatilganidek, hodisalarga asoslangan tizimga soddalashtirildi. CDC (Change-Data-Capture) voqealari Delta-Connector yordamida Keystone Kafka mavzulariga yuboriladi. Delta Stream Processing Framework (Flink asosida) yordamida yaratilgan Delta ilovasi mavzudan CDC hodisalarini oladi, boshqa mikroservislarni chaqirish orqali ularni boyitadi va nihoyat boyitilgan ma'lumotlarni Elasticsearch qidiruv indeksiga uzatadi. Butun jarayon deyarli real vaqtda sodir bo'ladi, ya'ni ma'lumotlar omboriga o'zgartirishlar kiritilishi bilanoq, qidiruv indekslari yangilanadi.
Shakl 2. Delta yordamida ma'lumotlar uzatish liniyasi
Keyingi bo'limlarda biz saqlashga ulanadigan va CDC hodisalarini Kafka mavzulariga yo'naltiruvchi real vaqtda ma'lumotlarni uzatish infratuzilmasi bo'lgan transport qatlamiga nashr etadigan Delta-Ulagichning ishlashini tasvirlab beramiz. Va nihoyat, biz Delta oqimini qayta ishlash tizimi haqida gaplashamiz, dastur ishlab chiquvchilari ma'lumotlarni qayta ishlash va mantiqni boyitish uchun foydalanishlari mumkin.
CDC (Ma'lumotlarni o'zgartirish)
Biz Delta-Connector deb nomlangan CDC xizmatini ishlab chiqdik, u real vaqt rejimida ma'lumotlar omboridan kiritilgan o'zgarishlarni yozib olishi va ularni oqimga yozishi mumkin. Haqiqiy vaqtda o'zgarishlar tranzaktsiyalar jurnali va saqlash chiqindilaridan olinadi. Dumplar ishlatiladi, chunki tranzaksiya jurnallari odatda o'zgarishlarning butun tarixini saqlamaydi. O'zgarishlar odatda Delta hodisalari sifatida ketma-ketlashtiriladi, shuning uchun qabul qiluvchi o'zgarishlar qayerdan kelgani haqida tashvishlanmasligi kerak.
Delta-Connector bir nechta qo'shimcha funktsiyalarni qo'llab-quvvatlaydi, masalan:
- Kafkadan o'tgan maxsus chiqish ma'lumotlarini yozish qobiliyati.
- Barcha jadvallar, ma'lum bir jadval yoki ma'lum birlamchi kalitlar uchun istalgan vaqtda qo'lda dumplarni faollashtirish imkoniyati.
- Chiqindilarni qismlarga bo'lib olish mumkin, shuning uchun muvaffaqiyatsizlikka uchragan taqdirda hammasini qaytadan boshlashning hojati yo'q.
- Jadvallarga qulflar qo'yishning hojati yo'q, bu ma'lumotlar bazasi yozish trafigini hech qachon bizning xizmatimiz tomonidan bloklanmasligini ta'minlash uchun juda muhimdir.
- AWS Availability Zonesdagi ortiqcha misollar tufayli yuqori mavjudlik.
Hozirda biz MySQL va Postgres-ni, shu jumladan AWS RDS va Aurora-da joylashtirishni qo'llab-quvvatlaymiz. Shuningdek, biz Kassandrani (multi-master) qo'llab-quvvatlaymiz. Delta-Connector haqida batafsil ma'lumotni bu yerda topishingiz mumkin .
Kafka va transport qatlami
Deltaning hodisalarni tashish qatlami platformaning xabar almashish xizmatida qurilgan .
Tarixiy jihatdan, Netflix-ga joylashtirish uzoq umr ko'rish uchun emas, balki qulaylik uchun optimallashtirilgan (pastga qarang). ). Shartnoma turli xil stsenariylarda broker ma'lumotlarining nomuvofiqligi edi. Masalan, nopok rahbar saylovi oluvchi potentsial takrorlangan yoki yo'qolgan voqealar uchun javobgardir.
Delta bilan biz CDC hodisalarini olingan do'konlarga yetkazib berishni ta'minlash uchun mustahkam mustahkamlik kafolatlarini xohladik. Shu maqsadda biz birinchi darajali ob'ekt sifatida maxsus ishlab chiqilgan Kafka klasterini taklif qildik. Quyidagi jadvalda ba'zi broker sozlamalarini ko'rishingiz mumkin:
Keystone Kafka klasterlarida, nopok rahbar saylovi odatda nashriyotga kirish imkoniyatini ta'minlash uchun kiritilgan. Sinxronlashtirilmagan replika yetakchi sifatida saylansa, bu xabarning yo'qolishiga olib kelishi mumkin. Yangi yuqori mavjudligi Kafka klasteri uchun variant nopok rahbar saylovi xabar yo'qolishining oldini olish uchun o'chirilgan.
Biz ham ko'paydik replikatsiya omili 2 dan 3 gacha va minimal sinxronlash nusxalari 1 dan 2 gacha. Ushbu klasterga yozayotgan noshirlar boshqalardan aklar talab qiladi, bu esa 2 ta replikadan 3 tasida nashriyot tomonidan yuborilgan eng dolzarb xabarlarga ega bo'lishini ta'minlaydi.
Broker namunasi tugagach, yangisi eskisini almashtiradi. Biroq, yangi broker sinxronlashtirilmagan replikalarni ushlashi kerak, bu bir necha soat davom etishi mumkin. Ushbu stsenariyni tiklash vaqtini qisqartirish uchun biz mahalliy broker disklari o'rniga blok ma'lumotlarni saqlashdan (Amazon Elastic Block Store) foydalanishni boshladik. Yangi nusxa tugatilgan broker nusxasini almashtirganda, u tugatilgan nusxada bo'lgan EBS hajmini biriktiradi va yangi xabarlarni ushlay boshlaydi. Bu jarayon kechikish vaqtini soatdan daqiqagacha qisqartiradi, chunki yangi nusxa endi bo'sh holatdan takrorlanishi kerak emas. Umuman olganda, alohida saqlash va broker hayot davrlari broker almashinuvining ta'sirini sezilarli darajada kamaytiradi.
Ma'lumotlarni yetkazib berish kafolatini yanada oshirish uchun biz foydalandik ekstremal sharoitlarda har qanday xabar yo'qolishini aniqlash uchun (masalan, bo'lim yetakchisida soatni sinxronizatsiya qilish).
Stream Processing Framework
Deltaning ishlov berish qatlami Netflix SPaaS platformasi ustiga qurilgan bo'lib, u Apache Flink Netflix ekotizimiga integratsiyani ta'minlaydi. Platforma bizning Titus konteynerlarini boshqarish platformamiz tepasida Flink ishlarini joylashtirish va Flink klasterlarini orkestrlashni boshqaradigan foydalanuvchi interfeysini taqdim etadi. Interfeys, shuningdek, ish konfiguratsiyasini boshqaradi va foydalanuvchilarga Flink ishlarini qayta kompilyatsiya qilmasdan konfiguratsiyani dinamik ravishda o'zgartirishga imkon beradi.
Delta Flink va SPaaS-ga asoslangan oqimlarni qayta ishlash tizimini taqdim etadi izohga asoslangan Texnik tafsilotlarni mavhumlashtirish uchun DSL (domenga xos til). Masalan, tashqi xizmatlarga qo'ng'iroq qilish orqali voqealarni boyitish bosqichini aniqlash uchun foydalanuvchilar quyidagi DSL-ni yozishlari kerak va ramka uning asosida Flink tomonidan bajariladigan modelni yaratadi.
Shakl 3. Delta'da DSL bo'yicha boyitish misoli
Qayta ishlash tizimi nafaqat o'rganish egri chizig'ini qisqartiradi, balki umumiy operatsion muammolarni hal qilish uchun deuplikatsiya, sxematiklashtirish va moslashuvchanlik va moslashuvchanlik kabi umumiy oqimni qayta ishlash xususiyatlarini ham ta'minlaydi.
Delta Stream Processing Framework ikkita asosiy moduldan, DSL & API modulidan va Runtime modulidan iborat. DSL & API moduli DSL va UDF (User-Defined-Function) API-larini taqdim etadi, shunda foydalanuvchilar o'zlarining ishlov berish mantiqlarini (masalan, filtrlash yoki o'zgartirishlar) yozishlari mumkin. Runtime moduli DAG modellarida ishlov berish bosqichlarining ichki tasvirini yaratuvchi DSL tahlilchisini amalga oshirishni ta'minlaydi. Ijro komponenti haqiqiy Flink iboralarini ishga tushirish va oxir-oqibat Flink ilovasini ishga tushirish uchun DAG modellarini sharhlaydi. Ramkaning arxitekturasi quyidagi rasmda ko'rsatilgan.
Shakl 4. Delta Stream Processing Framework arxitekturasi
Ushbu yondashuv bir qator afzalliklarga ega:
- Foydalanuvchilar Flink yoki SPaaS tuzilmasining o'ziga xos xususiyatlarini o'rganmasdan turib, o'zlarining biznes mantig'iga e'tibor qaratishlari mumkin.
- Optimallashtirish foydalanuvchilar uchun shaffof tarzda amalga oshirilishi mumkin va xatolar foydalanuvchi kodiga (UDF) hech qanday o'zgartirish kiritishni talab qilmasdan tuzatilishi mumkin.
- Delta ilovasi tajribasi foydalanuvchilar uchun soddalashtirilgan, chunki platforma qutidan tashqarida moslashuvchanlik va moslashuvchanlikni ta'minlaydi va ogohlantirishlar uchun ishlatilishi mumkin bo'lgan turli xil batafsil ko'rsatkichlarni to'playdi.
Ishlab chiqarishdan foydalanish
Delta bir yildan ortiq ishlab chiqarilmoqda va ko'plab Netflix Studio ilovalarida asosiy rol o'ynaydi. U jamoalarga qidiruvni indekslash, ma'lumotlarni saqlash va voqealarga asoslangan ish oqimlari kabi foydalanish holatlarini amalga oshirishda yordam berdi. Quyida Delta platformasining yuqori darajadagi arxitekturasining umumiy ko'rinishi keltirilgan.
Rasm 5. Deltaning yuqori darajadagi arxitekturasi.
Rahmatlar
Biz Netflix-da Delta-ni yaratish va rivojlantirishda ishtirok etgan quyidagi odamlarga minnatdorchilik bildiramiz: Allen Vang, Charlz Chjao, Jaebin Yun, Josh Snayder, Kasturi Chatterji, Mark Cho, Olof Yoxansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Stiven Vu, Tharanga Gamaethige, Yun Vang va Zhenzhong Xu.
Axborot manbalari
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Hodisalarni onlayn qayta ishlash. Kommun. ACM 62(5): 43–49 (2019). DOI:
: "Amazon Redshift Storage uchun ma'lumotlarni yaratish vositasi."
Manba: www.habr.com