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

Во пресрет на лансирањето на нов проток по стапка Инженер за податоци Подготвивме превод на интересен материјал.

Преглед

Ќе зборуваме за прилично популарна шема со која апликациите користат повеќе складишта на податоци, каде што секоја продавница се користи за свои цели, на пример, за складирање на канонската форма на податоци (MySQL, итн.), обезбедување напредни можности за пребарување (ElasticSearch, итн.) .), кеширање (Memcached, итн.) и други. Вообичаено, кога се користат повеќе складишта на податоци, едната од нив делува како примарна продавница, а другите како складишта за деривати. Единствениот проблем е како да се синхронизираат овие складишта на податоци.

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

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

Постојните решенија

Двоен влез

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

Проблеми:

Извршувањето на процедура за обновување е специфична работа што не може повторно да се користи. Дополнително, податоците помеѓу локациите за складирање остануваат несинхронизирани додека не се изврши процедурата за обновување. Решението станува покомплексно ако се користат повеќе од две складишта на податоци. Конечно, постапката за обновување може да додаде оптоварување на оригиналниот извор на податоци.

Променете ја табелата за дневници

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

Проблеми:

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

Друг проблем лежи во добивањето промени во шемата во системите кои не поддржуваат промени на трансакциските шеми [1][2], како што е MySQL. Затоа, шемата за правење промена (на пример, промена на шемата) и трансакциско снимање во табелата со дневници за промени нема секогаш да работи.

Дистрибуирани трансакции

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

Проблеми:

Дистрибуираните трансакции се многу голем проблем за хетерогени складишта на податоци. По својата природа, тие можат да се потпрат само на најмалиот заеднички именител на вклучените системи. На пример, XA трансакциите го блокираат извршувањето ако процесот на апликација не успее во фазата на подготовка. Дополнително, XA не обезбедува откривање на ќорсокак или поддржува оптимистички шеми за контрола на истовременост. Дополнително, некои системи како ElasticSearch не поддржуваат XA или кој било друг хетероген модел на трансакција. Така, обезбедувањето атомично запишување во различни технологии за складирање податоци останува многу предизвикувачка задача за апликациите [3].

Делта

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

Netflix нашироко користи микросервисна архитектура и секоја микросервис обично опслужува еден тип на податоци. Основните информации за филмот се содржани во микроуслугата наречена Movie Service, а поврзаните податоци како што се информациите за продуцентите, актерите, продавачите и така натаму се управувани од неколку други микроуслуги (имено Deal Service, Talent Service и Vendor Service).
Деловните корисници во студиото Netflix често имаат потреба да пребаруваат низ различни критериуми за филм, па затоа е многу важно за нив да можат да пребаруваат низ сите податоци поврзани со филмови.

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

Слика 1. Систем за гласање до Делта
По користењето на Delta, системот беше поедноставен во систем управуван од настани како што е прикажано на следната слика. Настаните на CDC (Change-Data-Capture) се испраќаат до темите на Keystone Kafka со помош на Delta-Connector. Апликација Delta изградена со помош на рамката за обработка на Delta Stream (заснована на Flink) прима CDC настани од тема, ги збогатува со повикување други микросервиси и конечно ги пренесува збогатените податоци на индексот за пребарување во Elasticsearch. Целиот процес се одвива речиси во реално време, односно, штом се извршат промени во складиштето на податоци, индексите за пребарување се ажурираат.

Слика 2. Гасовод на податоци користејќи Delta
Во следните делови, ќе ја опишеме работата на Delta-Connector, кој се поврзува со складиштето и објавува ЦДЦ настани во транспортниот слој, што е инфраструктура за пренос на податоци во реално време што ги насочува настаните на ЦДЦ кон темите на Кафка. И на самиот крај, ќе зборуваме за рамката за обработка на Delta stream, која развивачите на апликации можат да ја користат за обработка на податоци и логика за збогатување.

CDC (Change-Data-Capture)

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

Delta-Connector поддржува неколку дополнителни функции како што се:

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

Во моментов поддржуваме MySQL и Postgres, вклучително и распоредувања на AWS RDS и Aurora. Ја поддржуваме и Касандра (мулти-мајстор). Можете да дознаете повеќе детали за Delta-Connector овде блог пост.

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

Слојот за транспорт на настани на Delta е изграден на услугата за пораки на платформата клуч.

Историски гледано, објавувањето на Netflix е оптимизирано за пристапност наместо долговечност (види подолу). претходната статија). Размената беше потенцијална недоследност на податоците на брокерот во различни сценарија на работ. На пример, нечист избор на лидер е одговорен за примачот потенцијално да има дупликат или изгубени настани.

Со Delta, сакавме посилни гаранции за издржливост за да обезбедиме испорака на ЦДЦ настани до изведени продавници. За таа цел предложивме специјално дизајниран кластер Кафка како првокласен објект. Можете да погледнете некои поставки на брокерот во табелата подолу:

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

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

Кога брокерската инстанца завршува, нова инстанца ја заменува старата. Сепак, новиот брокер ќе треба да ги достигне несинхронизираните реплики, што може да потрае неколку часа. За да го намалиме времето за обновување за ова сценарио, почнавме да користиме блок складирање податоци (Amazon Elastic Block Store) наместо локални брокерски дискови. Кога нов примерок заменува прекинат примерок на брокер, тој го прикачува волуменот на EBS што го имал прекинатиот пример и почнува да ги достигнува новите пораки. Овој процес го намалува времето на расчистување на заостанатите од часови на минути бидејќи новиот пример повеќе не треба да се реплицира од празна состојба. Севкупно, одделното складирање и животниот циклус на посредникот значително го намалуваат влијанието на префрлувањето на брокерите.

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

Рамка за обработка на тек

Слојот за обработка на Delta е изграден на врвот на платформата Netflix SPaaS, која обезбедува интеграција на Apache Flink со екосистемот Netflix. Платформата обезбедува кориснички интерфејс кој управува со распоредувањето на работните места на Flink и оркестрацијата на кластерите на Flink на врвот на нашата платформа за управување со контејнери Titus. Интерфејсот, исто така, управува со конфигурациите на работните задачи и им овозможува на корисниците динамично да прават промени во конфигурацијата без да мора повторно да ги компилираат задачите на Flink.

Делта обезбедува рамка за обработка на пренос базирана на Flink и SPaaS што користи базирани на прибелешки DSL (Специфичен јазик за домен) за апстрактни технички детали. На пример, за да се дефинира чекорот во кој настаните ќе се збогатуваат со повикување надворешни сервиси, корисниците треба да го напишат следниов DSL, а рамката ќе создаде модел врз основа на него, кој ќе го изврши Flink.

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

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

Рамката за обработка на Delta Stream се состои од два клучни модула, модулот DSL и API и модулот Runtime. Модулот DSL & API обезбедува DSL и UDF (User-Defined-Function) API, така што корисниците можат да напишат сопствена логика за обработка (како филтрирање или трансформации). Модулот Runtime обезбедува имплементација на DSL парсер кој гради внатрешно претставување на чекорите за обработка во DAG моделите. Компонентата Execution ги интерпретира DAG моделите за да ги иницијализира вистинските изјави на Flink и на крајот да ја изврши апликацијата Flink. Архитектурата на рамката е илустрирана на следната слика.

Слика 4. Архитектура на рамката за обработка на делта тек

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

• Корисниците можат да се фокусираат на нивната деловна логика без да мора да истражуваат во спецификите на Flink или структурата SPaaS.
• Оптимизацијата може да се направи на начин кој е транспарентен за корисниците, а грешките може да се поправат без да се бараат какви било промени во корисничкиот код (UDF).
• Искуството со апликацијата Delta е поедноставено за корисниците бидејќи платформата обезбедува флексибилност и еластичност надвор од кутијата и собира различни детални метрики што може да се користат за предупредувања.

Производна употреба

Делта е во продукција повеќе од една година и игра клучна улога во многу апликации на Netflix Studio. Таа им помогна на тимовите да имплементираат случаи на употреба како што се индексирање на пребарување, складирање податоци и работни текови управувани од настани. Подолу е преглед на архитектурата на високо ниво на платформата Делта.

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

Благодарници

Би сакале да им се заблагодариме на следните луѓе кои беа вклучени во создавањето и развојот на Делта во Нетфликс: Ален Ванг, Чарлс Жао, Џебин Јун, Џош Снајдер, Кастури Чатерџи, Марк Чо, Олоф Јохансон, Пијуш Гојал, Прашант Рамдас, Рагурам Онти Сринивасан, Сандип Гупта, Стивен Ву, Таранга Гамаетиге, Јун Ванг и Џенџонг Ксу.

Извори

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Обработка на онлајн настани. Commun. ACM 62 (5): 43–49 (2019). DOI: doi.org/10.1145/3312527

Пријавете се за бесплатен вебинар: „Алатка за градење податоци за складирање на Amazon Redshift“.

Извор: www.habr.com