қарқынмен жаңа ағынның іске қосылуын күтумен Біз қызықты материалдың аудармасын дайындадық.
қайта қарау
Біз қолданбалар бірнеше деректер қоймаларын пайдаланатын, мысалы, деректердің канондық пішінін (MySQL және т.б.) сақтау үшін, кеңейтілген іздеу мүмкіндіктерін (ElasticSearch, т.б.) .), кэштеу (Memcached және т.б.) және т.б. Әдетте, бірнеше деректер қоймаларын пайдаланған кезде олардың біреуі негізгі қойма, ал басқалары туынды қоймалар ретінде әрекет етеді. Жалғыз мәселе - бұл деректер қоймаларын синхрондау жолы.
Біз бірнеше дүкендерді синхрондау мәселесін шешуге тырысатын бірнеше түрлі үлгілерді қарастырдық, мысалы, қос жазулар, таратылған транзакциялар және т.б. Дегенмен, бұл тәсілдер нақты өмірде пайдалану, сенімділік және техникалық қызмет көрсету тұрғысынан айтарлықтай шектеулерге ие. Деректерді синхрондаумен қатар, кейбір қолданбаларға сыртқы қызметтерге қоңырау шалу арқылы деректерді байыту қажет.
Delta осы мәселелерді шешу үшін жасалған. Delta, сайып келгенде, деректерді синхрондау және байыту үшін дәйекті, оқиғаға негізделген платформаны қамтамасыз етеді.
Бар шешімдер
Екі жақты енгізу
Екі деректер қоймасын синхрондауды сақтау үшін бір дүкенге жазатын, содан кейін бірден екіншісіне жазатын қос жазуды пайдалануға болады. Әрекеттер саны таусылғаннан кейін бірінші жазба сәтсіз болса, бірінші жазбаны қайталауға болады, ал екіншісін тоқтатуға болады. Дегенмен, екінші қоймаға жазу сәтсіз аяқталса, екі деректер қоймасы синхрондалмаған болуы мүмкін. Бұл мәселе әдетте деректерді бірінші жадтан екіншісіне кезеңді түрде қайта тасымалдай алатын қалпына келтіру процедурасын жасау арқылы шешіледі немесе деректерде айырмашылықтар анықталған жағдайда ғана орындалады.
Мәселелері:
Қалпына келтіру процедурасын орындау қайта пайдалануға болмайтын нақты жұмыс болып табылады. Бұған қоса, сақтау орындары арасындағы деректер қалпына келтіру процедурасы орындалғанша синхрондалмаған болып қалады. Екіден көп деректер қоймасы пайдаланылса, шешім күрделене түседі. Соңында, қалпына келтіру процедурасы бастапқы деректер көзіне жүктеме қоса алады.
Журнал кестесін өзгерту
Кестелер жиынында өзгерістер орын алған кезде (мысалы, жазбаны енгізу, жаңарту және жою), өзгерту жазбалары журнал кестесіне сол транзакцияның бөлігі ретінде қосылады. Басқа ағын немесе процесс журнал кестесінен оқиғаларды үнемі сұрайды және оларды бір немесе бірнеше деректер қоймаларына жазады, қажет болса, жазбаны барлық қоймалар растағаннан кейін журнал кестесінен оқиғаларды жояды.
Мәселелері:
Бұл үлгіні кітапхана ретінде және оны пайдаланатын қолданбаның кодын өзгертпестен орындау керек. Полиглоттық ортада мұндай кітапхананы іске асыру кез келген қажетті тілде болуы керек, бірақ функционалдылық пен тіл арасындағы мінез-құлықтың сәйкестігін қамтамасыз ету өте қиын.
Тағы бір мәселе MySQL сияқты транзакциялық схема өзгерістерін [1][2] қолдамайтын жүйелерде схема өзгерістерін алуда жатыр. Сондықтан өзгерту енгізу үлгісі (мысалы, схеманы өзгерту) және оны өзгерістер журналы кестесінде транзакциялық түрде жазу әрқашан жұмыс істемейді.
Бөлінген транзакциялар
Бөлінген транзакциялар операцияны барлық пайдаланылған деректер қоймаларына орындалатын немесе олардың ешқайсысына бекітілмейтіндей етіп, бірнеше гетерогенді деректер қоймалары бойынша транзакцияны бөлу үшін пайдаланылуы мүмкін.
Мәселелері:
Бөлінген транзакциялар гетерогенді деректер қоймалары үшін өте үлкен мәселе болып табылады. Табиғаты бойынша олар тартылған жүйелердің ең төменгі ортақ бөлгішіне ғана сене алады. Мысалы, егер бағдарлама процесі дайындық кезеңінде сәтсіз болса, XA транзакциялары орындауды блоктайды. Сонымен қатар, XA тұйықталуды анықтауды қамтамасыз етпейді немесе оптимистік параллельді басқару схемаларын қолдамайды. Бұған қоса, ElasticSearch сияқты кейбір жүйелер XA немесе басқа гетерогенді транзакция үлгісін қолдамайды. Осылайша, әртүрлі деректерді сақтау технологияларында жазу атомдылығын қамтамасыз ету қолданбалар үшін өте күрделі міндет болып қала береді [3].
Delta
Delta бар деректерді синхрондау шешімдерінің шектеулерін шешуге арналған және сонымен қатар деректерді жедел байытуға мүмкіндік береді. Біздің мақсатымыз бизнес функционалдығын жүзеге асыруға толығымен назар аударуы үшін қолданбаларды әзірлеушілерден осы қиындықтардың барлығын алып тастау болды. Әрі қарай біз Netflix Delta үшін нақты пайдалану жағдайы «Фильм іздеуді» сипаттайтын боламыз.
Netflix микросервис архитектурасын кеңінен пайдаланады және әрбір микросервис әдетте деректердің бір түріне қызмет етеді. Фильм туралы негізгі ақпарат Movie Service деп аталатын микросервисте қамтылған және продюсерлер, актерлер, жеткізушілер және т.б. туралы ақпарат сияқты қатысты деректер бірнеше басқа микросервистермен (мысалы, Deal Service, Talent Service және Vendor Service) басқарылады.
Netflix Studios-тегі іскери пайдаланушылар жиі әртүрлі фильм критерийлері бойынша іздеуді қажет етеді, сондықтан олар үшін фильмге қатысты барлық деректерден іздеу мүмкіндігі өте маңызды.
Delta-ға дейін фильмді іздеу тобына фильм деректерін индекстеу алдында бірнеше микросервистерден деректерді алу қажет болды. Сонымен қатар, командаға басқа микросервистерден өзгерістерді сұрау арқылы іздеу индексін мезгіл-мезгіл жаңартып отыратын жүйені әзірлеуге тура келді, тіпті ешқандай өзгерістер болмаса да. Бұл жүйе тез күрделі болды және оны ұстау қиын болды.
Сурет 1. Дельтаға дауыс беру жүйесі
Delta пайдаланғаннан кейін жүйе келесі суретте көрсетілгендей оқиғаға негізделген жүйеге жеңілдетілді. CDC (Change-Data-Capture) оқиғалары Delta-Connector көмегімен Keystone Kafka тақырыптарына жіберіледі. Delta Stream Processing Framework (Flink негізінде) көмегімен жасалған Delta қолданбасы тақырыптан CDC оқиғаларын алады, басқа микросервистерге қоңырау шалу арқылы оларды байытады және соңында байытылған деректерді Elasticsearch іздеу индексіне жібереді. Бүкіл процесс дерлік нақты уақытта орын алады, яғни деректер қоймасына өзгерістер енгізілгеннен кейін іздеу индекстері жаңартылады.
Сурет 2. Delta көмегімен деректер құбыры
Келесі бөлімдерде CDC оқиғаларын Кафка тақырыптарына бағыттайтын нақты уақыттағы деректерді тасымалдау инфрақұрылымы болып табылатын CDC оқиғаларын тасымалдау деңгейіне қосатын және CDC оқиғаларын жариялайтын Delta-Connector жұмысын сипаттайтын боламыз. Ең соңында біз Delta ағынын өңдеу құрылымы туралы сөйлесетін боламыз, оны қолданбаларды әзірлеушілер деректерді өңдеу және байыту логикасы үшін пайдалана алады.
CDC (Деректерді өзгерту)
Біз Delta-Connector деп аталатын CDC қызметін әзірледік, ол деректер қоймасынан жасалған өзгерістерді нақты уақытта түсіріп, оларды ағынға жаза алады. Нақты уақыттағы өзгерістер транзакциялар журналынан және сақтау қоқыстарынан алынады. Дамптар пайдаланылады, себебі транзакция журналдары әдетте өзгерістердің бүкіл тарихын сақтамайды. Өзгерістер әдетте Delta оқиғалары ретінде серияланады, сондықтан алушы өзгерістің қайдан келетіні туралы алаңдамауы керек.
Delta-Connector бірнеше қосымша мүмкіндіктерді қолдайды, мысалы:
- Кафка көмегімен реттелетін шығыс деректерін жазу мүмкіндігі.
- Барлық кестелер, белгілі бір кесте немесе нақты бастапқы кілттер үшін кез келген уақытта қолмен демптерді белсендіру мүмкіндігі.
- Қоқыстарды кесектерге алуға болады, сондықтан сәтсіздікке ұшыраған жағдайда бәрін қайтадан бастаудың қажеті жоқ.
- Кестелерге құлыптарды қоюдың қажеті жоқ, бұл дерекқор жазу трафигі біздің қызметімізбен ешқашан блокталмағанын қамтамасыз ету үшін өте маңызды.
- AWS қолжетімділік аймақтарындағы артық даналарға байланысты жоғары қолжетімділік.
Қазіргі уақытта біз MySQL және Postgres, соның ішінде AWS RDS және Aurora-да орналастыруларды қолдаймыз. Біз сондай-ақ Кассандраны (мульти-мастер) қолдаймыз. Delta-Connector туралы қосымша мәліметтерді мына жерден таба аласыз .
Кафка және тасымалдау қабаты
Delta оқиға тасымалдау қабаты платформаның хабар алмасу қызметіне салынған .
Тарихи түрде Netflix-те жариялау ұзақ өмір сүруге емес, қол жетімділікке оңтайландырылған (төменде қараңыз). ). Сауда әр түрлі шеткі сценарийлердегі ықтимал брокер деректерінің сәйкессіздігі болды. Мысалы, таза емес көшбасшы сайлауы алушының қайталанатын немесе жоғалған оқиғаларына жауап береді.
Delta көмегімен біз CDC оқиғаларын туынды дүкендерге жеткізуді қамтамасыз ету үшін беріктік кепілдігін алғымыз келеді. Осы мақсатта біз бірінші дәрежелі объект ретінде арнайы жасалған Кафка кластерін ұсындық. Төмендегі кестеде кейбір брокер параметрлерін қарауға болады:
Кейстоун Кафка кластерлерінде, таза емес көшбасшы сайлауы әдетте жариялаушының қол жетімділігін қамтамасыз ету үшін қосылады. Синхрондалмаған көшірме көшбасшы ретінде таңдалса, бұл хабарлардың жоғалуына әкелуі мүмкін. Жаңа жоғары қолжетімділік Кафка кластері үшін опция таза емес көшбасшы сайлауы хабардың жоғалуын болдырмау үшін өшірілді.
Біз де өстік репликация факторы 2-ден 3-ке дейін және ең аз синхрондау репликалары 1-ден 2-ге дейін. Осы кластерге жазатын жариялаушылар 2 көшірменің 3-сінде жариялаушы жіберген ең ағымдағы хабарларға ие болуын қамтамасыз ету үшін барлық басқа адамдардан рұқсат талап етеді.
Брокер данасы аяқталғанда, жаңа данасы ескісін ауыстырады. Дегенмен, жаңа брокер синхрондалмаған көшірмелерді қуып жетуі керек, бұл бірнеше сағатқа созылуы мүмкін. Осы сценарийді қалпына келтіру уақытын қысқарту үшін жергілікті брокер дискілерінің орнына блок деректерін сақтауды (Amazon Elastic Block Store) пайдалана бастадық. Жаңа данасы тоқтатылған брокер данасын ауыстырғанда, ол тоқтатылған данада болған EBS көлемін қосады және жаңа хабарларды қуып жете бастайды. Бұл процесс кешіктіру уақытын сағаттан минутқа дейін қысқартады, себебі жаңа дананы енді бос күйден қайталау қажет емес. Жалпы алғанда, бөлек сақтау және брокердің өмірлік циклдері брокерді ауыстырудың әсерін айтарлықтай төмендетеді.
Деректерді жеткізу кепілдігін одан әрі арттыру үшін біз қолдандық төтенше жағдайларда кез келген хабардың жоғалуын анықтау үшін (мысалы, бөлім көшбасшысындағы сағатты десинхрондау).
Stream Processing Framework
Delta өңдеу қабаты Netflix экожүйесімен Apache Flink интеграциясын қамтамасыз ететін Netflix SPaaS платформасының үстіне салынған. Платформа Flink тапсырмаларын орналастыруды және Titus контейнерін басқару платформасының жоғарғы жағындағы Flink кластерлерін басқаруды басқаратын пайдаланушы интерфейсін қамтамасыз етеді. Интерфейс сонымен қатар жұмыс конфигурацияларын басқарады және пайдаланушыларға Flink тапсырмаларын қайта құрастырмай-ақ динамикалық түрде конфигурация өзгерістерін жасауға мүмкіндік береді.
Delta пайдаланатын Flink және SPaaS негізіндегі ағынды өңдеу құрылымын ұсынады аннотацияға негізделген Техникалық мәліметтерді алу үшін DSL (доменге тән тіл). Мысалы, сыртқы қызметтерге қоңырау шалу арқылы оқиғалар байытылатын қадамды анықтау үшін пайдаланушылар келесі DSL жазуы керек және фреймворк оның негізінде Flink орындайтын үлгі жасайды.
Сурет 3. Delta жүйесіндегі DSL бойынша байыту мысалы
Өңдеу құрылымы оқу қисығын қысқартып қана қоймайды, сонымен қатар деупликация, схематизация және жалпы операциялық мәселелерді шешу үшін икемділік пен икемділік сияқты жалпы ағынды өңдеу мүмкіндіктерін қамтамасыз етеді.
Delta Stream Processing Framework екі негізгі модульден, DSL & API модулінен және Runtime модулінен тұрады. DSL & API модулі DSL және UDF (Пайдаланушы анықтайтын функция) API интерфейстерін қамтамасыз етеді, осылайша пайдаланушылар өздерінің өңдеу логикасын (сүзу немесе түрлендірулер сияқты) жаза алады. Runtime модулі DAG үлгілеріндегі өңдеу қадамдарының ішкі көрінісін құрайтын DSL талдаушысының іске асырылуын қамтамасыз етеді. Орындау компоненті нақты Flink мәлімдемелерін инициализациялау және соңында Flink қолданбасын іске қосу үшін DAG үлгілерін түсіндіреді. Жақтаудың архитектурасы келесі суретте көрсетілген.
Сурет 4. Delta Stream Processing Framework архитектурасы
Бұл тәсілдің бірнеше артықшылығы бар:
- Пайдаланушылар Flink немесе SPaaS құрылымының ерекшеліктерін зерттемей-ақ өздерінің бизнес логикасына назар аудара алады.
- Оңтайландыруды пайдаланушылар үшін мөлдір етіп жасауға болады және қателерді пайдаланушы кодына (UDF) өзгертулерді талап етпей-ақ түзетуге болады.
- Delta қолданбасының тәжірибесі пайдаланушылар үшін жеңілдетілген, себебі платформа қораптан тыс икемділік пен икемділікті қамтамасыз етеді және ескертулер үшін пайдалануға болатын әртүрлі егжей-тегжейлі көрсеткіштерді жинайды.
Өндірістік пайдалану
Delta бір жылдан астам уақыт бойы өндірісте және көптеген Netflix Studio қолданбаларында маңызды рөл атқарады. Ол топтарға іздеуді индекстеу, деректерді сақтау және оқиғаға негізделген жұмыс процестері сияқты пайдалану жағдайларын жүзеге асыруға көмектесті. Төменде Delta платформасының жоғары деңгейлі архитектурасына шолу берілген.
Сурет 5. Delta-ның жоғары деңгейлі архитектурасы.
Алғыс
Netflix-те Delta-ны құруға және дамытуға атсалысқан келесі адамдарға алғыс айтқымыз келеді: Аллен Ванг, Чарльз Чжао, Джебин Юн, Джош Снайдер, Кастури Чаттерджи, Марк Чо, Олоф Йоханссон, Пиюш Гойал, Прашант Рамдас, Рагурам Онти Шринивасан, Сандип Гупта, Стивен Ву, Таранга Гамаэтиге, Юн Ван және Чжэнчжун Сю.
Ақпарат көздері
- Мартин Клеппман, Аластэр Р. Бересфорд, Борж Свинген: Оқиғаларды онлайн өңдеу. Коммун. ACM 62(5): 43–49 (2019). DOI:
: “Amazon Redshift Storage үшін деректер құрастыру құралы.”
Ақпарат көзі: www.habr.com