Делта: Платформа за синхронизацију и обогаћивање података

У ишчекивању покретања новог тока по стопи Дата Енгинеер Припремили смо превод занимљивог материјала.

Преглед

Говорићемо о прилично популарном обрасцу по којем апликације користе више складишта података, при чему се свако складиште користи за своје потребе, на пример, за складиштење канонског облика података (МиСКЛ, итд.), пружа напредне могућности претраживања (ЕластицСеарцх, итд.) .), кеширање (Мемцацхед, итд.) и др. Обично, када се користи више складишта података, једно од њих делује као примарно складиште, а друго као деривативно складиште. Једини проблем је како да синхронизујете ове складишта података.

Погледали смо бројне различите обрасце који су покушали да реше проблем синхронизације више продавница, као што су двоструко уписивање, дистрибуиране трансакције итд. Међутим, ови приступи имају значајна ограничења у погледу употребе у стварном животу, поузданости и одржавања. Поред синхронизације података, неке апликације такође треба да обогате податке позивањем екстерних сервиса.

Делта је развијена да реши ове проблеме. Делта на крају пружа конзистентну платформу вођену догађајима за синхронизацију и обогаћивање података.

Постојећа решења

Двојног

Да бисте синхронизовали две складишта података, можете користити двоструко уписивање, које уписује у једно складиште, а затим уписује у друго одмах након тога. Прво снимање се може поновити, а друго се може прекинути ако први не успе након што је број покушаја исцрпљен. Међутим, два складишта података могу постати несинхронизована ако уписивање у друго складиште не успе. Овај проблем се обично решава креирањем процедуре опоравка која може периодично поново преносити податке из прве меморије у другу, или то чини само ако се открију разлике у подацима.

Проблеми:

Извођење поступка опоравка је специфичан посао који се не може поново користити. Поред тога, подаци између локација за складиштење остају несинхронизовани док се не изврши поступак враћања. Решење постаје сложеније ако се користи више од два складишта података. Коначно, процедура враћања може додати оптерећење оригиналном извору података.

Промена табеле дневника

Када дође до промена у скупу табела (као што је уметање, ажурирање и брисање записа), записи промена се додају у табелу евиденције као део исте трансакције. Друга нит или процес константно захтева догађаје из табеле евиденције и уписује их у једно или више складишта података, ако је потребно, уклањајући догађаје из табеле евиденције након што је запис потврђен од стране свих складишта.

Проблеми:

Овај образац би требало да се имплементира као библиотека, а идеално је да се не мења код апликације која га користи. У полиглотском окружењу, имплементација такве библиотеке треба да постоји на било ком неопходном језику, али је веома тешко обезбедити доследност функционалности и понашања на различитим језицима.

Други проблем лежи у добијању промена шеме у системима који не подржавају промене трансакционих шема [1][2], као што је МиСКЛ. Због тога, образац прављења промене (на пример, промене шеме) и трансакционог евидентирања у табели евиденције промена неће увек функционисати.

Дистрибутед Трансацтионс

Дистрибуиране трансакције се могу користити за поделу трансакције на више хетерогених складишта података тако да је операција или посвећена свим коришћеним складиштима података, или није посвећена ниједном од њих.

Проблеми:

Дистрибуиране трансакције представљају велики проблем за хетерогена складишта података. По својој природи, они се могу ослонити само на најмањи заједнички именитељ укључених система. На пример, КСА трансакције блокирају извршење ако процес апликације не успе током фазе припреме. Поред тога, КСА не обезбеђује откривање застоја нити подржава оптимистичне шеме контроле паралелности. Поред тога, неки системи као што је ЕластицСеарцх не подржавају КСА или било који други хетерогени модел трансакције. Стога, обезбеђивање атомичности писања у различитим технологијама складиштења података остаје веома изазован задатак за апликације [3].

Делта

Делта је дизајнирана да одговори на ограничења постојећих решења за синхронизацију података и такође омогућава обогаћивање података у лету. Наш циљ је био да апстрахујемо све ове сложености од програмера апликација како би се могли у потпуности фокусирати на имплементацију пословне функционалности. Затим ћемо описати „Претрагу филмова“, стварни случај употребе Нетфлик-ове Делта.

Нетфлик нашироко користи архитектуру микросервиса, а свака микросервис обично опслужује једну врсту података. Основне информације о филму садржане су у микросервису под називом Мовие Сервице, а повезаним подацима као што су информације о продуцентима, глумцима, продавцима и тако даље управља неколико других микросервиса (наиме Деал Сервице, Талент Сервице и Вендор Сервице).
Пословни корисници у Нетфлик Студиос-у често морају да претражују различите критеријуме филмова, због чега је веома важно да могу да претражују све податке у вези са филмом.

Пре Делте, тим за претрагу филмова је морао да извуче податке из више микросервиса пре индексирања података о филму. Поред тога, тим је морао да развије систем који би периодично ажурирао индекс претраге тражећи промене од других микросервиса, чак и ако није било никаквих промена. Овај систем је брзо постао сложен и тежак за одржавање.

Слика 1. Систем прозивања Делта
Након коришћења Делте, систем је поједностављен на систем вођен догађајима као што је приказано на следећој слици. ЦДЦ (Цханге-Дата-Цаптуре) догађаји се шаљу у Кеистоне Кафка теме помоћу Делта-Цоннецтор-а. Делта апликација направљена коришћењем Делта Стреам Процессинг Фрамеворк-а (заснованог на Флинк-у) прима ЦДЦ догађаје из теме, обогаћује их позивањем других микросервиса и коначно прослеђује обогаћене податке у индекс претраге у Еластицсеарцх-у. Цео процес се одвија скоро у реалном времену, односно чим се промене у складишту података ажурирају индекси претраге.

Слика 2. Цевовод података користећи Делта
У следећим одељцима ћемо описати рад Делта-конектора, који се повезује са складиштем и објављује ЦДЦ догађаје на транспортном слоју, који је инфраструктура за пренос података у реалном времену која усмерава ЦДЦ догађаје ка Кафкиним темама. И на самом крају, говорићемо о оквиру за обраду Делта стреам-а, који програмери апликација могу да користе за обраду података и логику обогаћивања.

ЦДЦ (Цханге-Дата-Цаптуре)

Развили смо ЦДЦ услугу под називом Делта-Цоннецтор, која може да ухвати извршене промене из складишта података у реалном времену и да их запише у ток. Промене у реалном времену се преузимају из евиденције трансакција и депонија складишта. Думпови се користе јер евиденције трансакција обично не чувају целу историју промена. Промене се обично серијализују као Делта догађаји, тако да прималац не мора да брине о томе одакле промена долази.

Делта-Цоннецтор подржава неколико додатних функција као што су:

• Могућност писања прилагођених излазних података мимо Кафке.
• Могућност активирања ручних думпова у било ком тренутку за све табеле, одређену табелу или за одређене примарне кључеве.
• Думпови се могу преузимати у комадима, тако да нема потребе да почињете изнова у случају неуспеха.
• Нема потребе да закључавате табеле, што је веома важно како бисмо осигурали да наш сервис никада не блокира саобраћај уписивања у базу података.
• Висока доступност због редундантних инстанци у зонама доступности АВС-а.

Тренутно подржавамо МиСКЛ и Постгрес, укључујући примену на АВС РДС и Аурора. Такође подржавамо Цассандра (мулти-мастер). Више детаља о Делта-Цоннецтор-у можете сазнати овде блог пост.

Кафка и транспортни слој

Делтин слој за транспорт догађаја изграђен је на сервису за размену порука платформе главни принцип.

Историјски гледано, објављивање на Нетфлик-у је оптимизовано за приступачност, а не за дуговечност (погледајте доле). претходни чланак). Компромис је био потенцијална недоследност брокерских података у различитим сценаријима на ивици. На пример, нечисти избори за вођу је одговоран за потенцијално дуплирање или изгубљене догађаје код примаоца.

Са Делтом, желели смо јаче гаранције трајности како бисмо обезбедили испоруку ЦДЦ догађаја изведеним продавницама. У ту сврху предложили смо посебно дизајниран Кафка кластер као првокласни објекат. Можете погледати нека подешавања брокера у табели испод:

У Кеистоне Кафка кластерима, нечисти избори за вођу обично укључен да би се обезбедила доступност издавача. Ово може довести до губитка поруке ако се несинхронизована реплика изабере као водећа. За нови Кафка кластер високе доступности, опција нечисти избори за вођу искључено да спречи губитак поруке.

И ми смо се повећали фактор репликације од 2 до 3 и минималне инсинхронизоване реплике 1 до 2. Издавачи који пишу овом кластеру захтевају потврде од свих осталих, обезбеђујући да 2 од 3 реплике имају најновије поруке које шаље издавач.

Када се брокерска инстанца оконча, нова инстанца замењује стару. Међутим, нови брокер ће морати да ухвати корак са несинхронизованим репликама, што може потрајати неколико сати. Да бисмо смањили време опоравка за овај сценарио, почели смо да користимо блок складиштење података (Амазон Еластиц Блоцк Сторе) уместо локалних дискова брокера. Када нова инстанца замени прекинуту инстанцу брокера, она прилаже ЕБС волумен који је прекинута инстанца имала и почиње да сустиже нове поруке. Овај процес смањује време отклањања заосталих предмета са сати на минуте јер нова инстанца више не мора да се реплицира из празног стања. Све у свему, одвојено складиште и животни циклус брокера значајно смањују утицај промене брокера.

Да бисмо додатно повећали гаранцију испоруке података, користили смо систем за праћење порука да детектује губитак поруке у екстремним условима (на пример, десинхронизација сата у вођи партиције).

Стреам Процессинг Фрамеворк

Делта слој за обраду је изграђен на врху Нетфлик СПааС платформе, која обезбеђује Апацхе Флинк интеграцију са Нетфлик екосистемом. Платформа обезбеђује кориснички интерфејс који управља постављањем Флинк послова и оркестрацијом Флинк кластера на врху наше Титус платформе за управљање контејнерима. Интерфејс такође управља конфигурацијама послова и омогућава корисницима да изврше промене у конфигурацији динамички без потребе да поново компајлирају Флинк послове.

Делта обезбеђује оквир за обраду тока заснован на Флинк-у и СПааС-у који користи заснован на анотацији ДСЛ (Домаин Специфиц Лангуаге) за апстрактне техничке детаље. На пример, да би дефинисали корак на коме ће догађаји бити обогаћени позивањем екстерних сервиса, корисници треба да напишу следећи ДСЛ, а оквир ће на основу њега креирати модел који ће извршити Флинк.

Слика 3. Пример обогаћивања на ДСЛ-у у Делти

Оквир за обраду не само да смањује криву учења, већ такође обезбеђује заједничке карактеристике обраде тока као што су дедупликација, шематизација и флексибилност и еластичност за решавање уобичајених оперативних проблема.

Делта Стреам Процессинг Фрамеворк се састоји од два кључна модула, ДСЛ & АПИ модула и Рунтиме модула. ДСЛ & АПИ модул обезбеђује ДСЛ и УДФ (кориснички дефинисана функција) АПИ-је тако да корисници могу да напишу сопствену логику обраде (као што су филтрирање или трансформације). Рунтиме модул обезбеђује имплементацију ДСЛ парсера који гради интерни приказ корака обраде у ДАГ моделима. Компонента Екецутион тумачи ДАГ моделе да би иницијализовала стварне Флинк изјаве и на крају покренула Флинк апликацију. Архитектура оквира је илустрована на следећој слици.

Слика 4. Архитектура Делта Стреам Процессинг Фрамеворк

Овај приступ има неколико предности:

• Корисници могу да се фокусирају на своју пословну логику без потребе да се удубљују у специфичности Флинк-а или структуре СПааС-а.
• Оптимизација се може обавити на начин који је транспарентан за кориснике, а грешке се могу поправити без потребе за било каквим изменама корисничког кода (УДФ).
• Искуство Делта апликације је поједностављено за кориснике јер платформа обезбеђује флексибилност и отпорност ван кутије и прикупља разне детаљне метрике које се могу користити за упозорења.

Употреба у производњи

Делта је у производњи више од годину дана и игра кључну улогу у многим апликацијама Нетфлик Студио. Помогла је тимовима да имплементирају случајеве коришћења као што су индексирање претраге, складиштење података и токови рада вођени догађајима. Испод је преглед архитектуре високог нивоа Делта платформе.

Слика 5. Делта архитектура високог нивоа.

Захвалнице

Желели бисмо да се захвалимо следећим људима који су били укључени у стварање и развој Делте на Нетфликсу: Аллен Ванг, Цхарлес Зхао, Јаебин Иоон, Јосх Снидер, Кастури Цхаттерјее, Марк Цхо, Олоф Јоханссон, Пииусх Гоиал, Прасхантх Рамдас, Рагхурам Онти Сринивасан, Сандееп Гупта, Стевен Ву, Тхаранга Гамаетхиге, Иун Ванг и Зхензхонг Ксу.

izvori

1. дев.мискл.цом/доц/рефман/5.7/ен/имплицит-цоммит.хтмл
2. дев.мискл.цом/доц/рефман/5.7/ен/цаннот-ролл-бацк.хтмл
3. Мартин Клеппманн, Аластаир Р. Бересфорд, Боерге Свинген: Онлине обрада догађаја. Цоммун. АЦМ 62(5): 43–49 (2019). ДОИ: дои.орг/10.1145/3312527

Пријавите се за бесплатни вебинар: „Алатка за прављење података за Амазон Редсхифт Стораге.“

Извор: ввв.хабр.цом