В очакване на стартирането на нов поток със скорост Подготвили сме превод на интересен материал.
Преглед
Ще говорим за доста популярен модел, чрез който приложенията използват множество хранилища за данни, където всяко хранилище се използва за свои собствени цели, например за съхраняване на каноничната форма на данни (MySQL и т.н.), предоставяне на разширени възможности за търсене (ElasticSearch, и др.), кеширане (Memcached и др.) и други. Обикновено, когато използвате множество хранилища за данни, едно от тях действа като основно хранилище, а останалите като производни хранилища. Единственият проблем е как да се синхронизират тези хранилища на данни.
Разгледахме редица различни модели, които се опитаха да решат проблема със синхронизирането на множество магазини, като двойни записи, разпределени транзакции и т.н. Тези подходи обаче имат значителни ограничения по отношение на употреба в реалния живот, надеждност и поддръжка. В допълнение към синхронизирането на данни, някои приложения също трябва да обогатят данните чрез извикване на външни услуги.
Delta е разработена за решаване на тези проблеми. Delta в крайна сметка предоставя последователна, управлявана от събития платформа за синхронизиране и обогатяване на данни.
Съществуващи решения
Двоен вход
За да поддържате две хранилища за данни в синхрон, можете да използвате двойно записване, което записва в едното хранилище и след това записва в другото веднага след това. Първият запис може да се опита повторно, а вторият може да бъде прекратен, ако първият е неуспешен след изчерпване на броя опити. Двете хранилища за данни обаче може да се разпаднат в синхрон, ако записът във втората памет е неуспешен. Този проблем обикновено се решава чрез създаване на процедура за възстановяване, която може периодично да прехвърля данни от първото хранилище към второто или да го прави само ако се открият разлики в данните.
проблеми:
Извършването на процедура по възстановяване е специфична задача, която не може да се използва повторно. Освен това данните между местата за съхранение остават несинхронизирани, докато не започне процедурата по възстановяване. Решението става по-сложно, ако се използват повече от две хранилища за данни. И накрая, процедурата за възстановяване може да добави натоварване към оригиналния източник на данни.
Промяна на таблицата с дневник
Когато възникнат промени в набор от таблици (като вмъкване, актуализиране и изтриване на запис), записите за промяна се добавят към таблицата на журнала като част от същата транзакция. Друга нишка или процес постоянно изисква събития от таблицата на журнала и ги записва в едно или повече хранилища за данни, ако е необходимо, като премахва събитията от таблицата на журнала, след като записът е потвърден от всички магазини.
проблеми:
Този модел трябва да бъде внедрен като библиотека и в идеалния случай без промяна на кода на приложението, което го използва. В полиглотска среда внедряването на такава библиотека трябва да съществува на всеки необходим език, но осигуряването на последователност на функционалността и поведението на различните езици е много трудно.
Друг проблем се крие в получаването на промени в схемата в системи, които не поддържат транзакционни промени в схема [1][2], като MySQL. Следователно моделът на извършване на промяна (например промяна на схема) и транзакционното й записване в таблицата на регистъра на промените няма винаги да работи.
Разпределени транзакции
Разпределените транзакции могат да се използват за разделяне на транзакция между множество хетерогенни хранилища за данни, така че операцията да бъде или ангажирана към всички използвани хранилища на данни, или да не е ангажирана към нито едно от тях.
проблеми:
Разпределените транзакции са много голям проблем за разнородните хранилища на данни. По своето естество те могат да разчитат само на най-малкия общ знаменател на включените системи. Например XA транзакциите блокират изпълнението, ако процесът на кандидатстване се провали по време на подготвителната фаза. Освен това XA не осигурява откриване на блокиране или поддържа оптимистични схеми за контрол на паралелността. В допълнение, някои системи като ElasticSearch не поддържат XA или друг модел на разнородни транзакции. По този начин осигуряването на атомарност на запис в различни технологии за съхранение на данни остава много предизвикателна задача за приложенията [3].
Делта
Delta е проектирана да се справи с ограниченията на съществуващите решения за синхронизиране на данни и също така позволява обогатяване на данни в движение. Нашата цел беше да абстрахираме всички тези сложности от разработчиците на приложения, така че те да могат напълно да се съсредоточат върху внедряването на бизнес функционалност. След това ще опишем „Търсене на филми“, действителният случай на използване на Delta на Netflix.
Netflix широко използва архитектура на микроуслуги и всяка микроуслуга обикновено обслужва един тип данни. Основната информация за филма се съдържа в микроуслуга, наречена Movie Service, а свързаните данни като информация за продуценти, актьори, доставчици и т.н. се управляват от няколко други микроуслуги (а именно Deal Service, Talent Service и Vendor Service).
Бизнес потребителите в Netflix Studios често трябва да търсят по различни критерии за филми, поради което е много важно за тях да могат да търсят във всички данни, свързани с филми.
Преди Delta екипът за търсене на филми трябваше да изтегли данни от множество микроуслуги, преди да индексира данните за филмите. В допълнение, екипът трябваше да разработи система, която периодично да актуализира индекса за търсене, като изисква промени от други микроуслуги, дори ако изобщо няма промени. Тази система бързо стана сложна и трудна за поддръжка.
Фигура 1. Система за гласуване към Delta
След използването на Delta системата беше опростена до система, управлявана от събития, както е показано на следващата фигура. CDC (Change-Data-Capture) събития се изпращат към темите на Keystone Kafka с помощта на Delta-Connector. Приложение Delta, създадено с помощта на Delta Stream Processing Framework (базирано на Flink), получава CDC събития от тема, обогатява ги чрез извикване на други микроуслуги и накрая предава обогатените данни към индекс за търсене в Elasticsearch. Целият процес се извършва почти в реално време, т.е. веднага щом промените бъдат ангажирани в хранилището на данни, индексите за търсене се актуализират.
Фигура 2. Тръбопровод за данни с помощта на Delta
В следващите раздели ще опишем работата на Delta-Connector, който се свързва към хранилището и публикува CDC събития на транспортния слой, който е инфраструктура за предаване на данни в реално време, която насочва CDC събития към Kafka теми. И в самия край ще говорим за рамката за обработка на поток Delta, която разработчиците на приложения могат да използват за обработка на данни и логика за обогатяване.
CDC (Change-Data-Capture)
Разработихме CDC услуга, наречена Delta-Connector, която може да улавя извършени промени от хранилището на данни в реално време и да ги записва в поток. Промените в реално време се вземат от регистъра на транзакциите и дъмповете на хранилището. Използват се дъмпове, защото регистрационните файлове на транзакциите обикновено не съхраняват цялата история на промените. Промените обикновено се сериализират като Delta събития, така че получателят не трябва да се тревожи откъде идва промяната.
Delta-Connector поддържа няколко допълнителни функции като:
- Възможност за писане на потребителски изходни данни след Kafka.
- Възможност за активиране на ръчни дъмпове по всяко време за всички таблици, конкретна таблица или за конкретни първични ключове.
- Дъмпите могат да се извличат на парчета, така че няма нужда да започвате всичко отначало в случай на повреда.
- Няма нужда да поставяте ключалки на таблици, което е много важно, за да се гарантира, че трафикът за запис на база данни никога не се блокира от нашата услуга.
- Висока достъпност поради излишни екземпляри в AWS Availability Zones.
В момента поддържаме MySQL и Postgres, включително внедрявания на AWS RDS и Aurora. Ние също поддържаме Cassandra (multi-master). Можете да намерите повече подробности за Delta-Connector тук .
Кафка и транспортният слой
Слоят за транспортиране на събития на Delta е изграден върху услугата за съобщения на платформата .
В исторически план публикуването в Netflix е оптимизирано за достъпност, а не за дълготрайност (вижте по-долу). ). Компромисът беше потенциално несъответствие на данните на брокера в различни крайни сценарии. Например, нечист избор на лидер е отговорен за получателя, който потенциално има дублирани или загубени събития.
С Delta искахме по-силни гаранции за издръжливост, за да осигурим доставка на CDC събития до производни магазини. За тази цел предложихме специално проектиран клъстер Kafka като първокласен обект. Можете да разгледате някои настройки на брокера в таблицата по-долу:
В клъстерите на Keystone Kafka, нечист избор на лидер обикновено се включва, за да се осигури достъпност на издателя. Това може да доведе до загуба на съобщение, ако несинхронизирана реплика бъде избрана за лидер. За нов клъстер Kafka с висока наличност, опцията нечист избор на лидер изключено, за да се предотврати загуба на съобщение.
Ние също увеличихме репликационен фактор от 2 до 3 и минимум инсинхронизирани реплики 1 до 2. Издателите, които пишат в този клъстер, изискват потвърждения от всички останали, като се гарантира, че 2 от 3 реплики имат най-актуалните съобщения, изпратени от издателя.
Когато инстанция на брокер се прекрати, нова инстанция заменя старата. Новият брокер обаче ще трябва да навакса с несинхронизираните реплики, което може да отнеме няколко часа. За да намалим времето за възстановяване за този сценарий, започнахме да използваме блоково съхранение на данни (Amazon Elastic Block Store) вместо локални брокерски дискове. Когато нов екземпляр замени прекратен екземпляр на брокер, той прикачва EBS тома, който е имал прекратеният екземпляр, и започва да наваксва с нови съобщения. Този процес намалява времето за изчистване на натрупани документи от часове до минути, тъй като новият екземпляр вече не трябва да се репликира от празно състояние. Като цяло отделните жизнени цикли на съхранение и брокер значително намаляват въздействието от смяната на брокер.
За да увеличим допълнително гаранцията за доставка на данни, използвахме за откриване на всяка загуба на съобщение при екстремни условия (например десинхронизиране на часовника в лидера на дяла).
Рамка за обработка на потоци
Обработващият слой на Delta е изграден върху платформата Netflix SPaaS, която осигурява интеграция на Apache Flink с екосистемата Netflix. Платформата предоставя потребителски интерфейс, който управлява внедряването на Flink задания и оркестрацията на Flink клъстери върху нашата платформа за управление на контейнери Titus. Интерфейсът също така управлява конфигурации на задачи и позволява на потребителите да правят промени в конфигурацията динамично, без да се налага да компилират повторно задачи на Flink.
Delta предоставя рамка за обработка на потоци, базирана на Flink и SPaaS, която използва базирани на анотация DSL (специфичен за домейн език) за абстрахиране на технически подробности. Например, за да се определи стъпката, на която събитията ще бъдат обогатени чрез извикване на външни услуги, потребителите трябва да напишат следния DSL и рамката ще създаде модел въз основа на него, който ще бъде изпълнен от Flink.
Фигура 3. Пример за обогатяване на DSL в Delta
Рамката за обработка не само намалява кривата на обучение, но също така предоставя общи функции за обработка на потоци като дедупликация, схематизиране и гъвкавост и устойчивост за решаване на общи оперативни проблеми.
Delta Stream Processing Framework се състои от два ключови модула, модул DSL & API и модул Runtime. DSL & API модулът предоставя DSL и UDF (User-Defined-Function) API, така че потребителите да могат да напишат своя собствена логика за обработка (като филтриране или трансформации). Модулът Runtime предоставя реализация на DSL анализатор, който изгражда вътрешно представяне на стъпките за обработка в DAG модели. Компонентът за изпълнение интерпретира DAG моделите, за да инициализира действителните оператори на Flink и в крайна сметка да стартира приложението Flink. Архитектурата на рамката е илюстрирана на следващата фигура.
Фигура 4. Архитектура на Delta Stream Processing Framework
Този подход има няколко предимства:
- Потребителите могат да се съсредоточат върху своята бизнес логика, без да се налага да се задълбочават в спецификата на Flink или структурата на SPaaS.
- Оптимизацията може да се извърши по начин, който е прозрачен за потребителите, и грешките могат да бъдат коригирани, без да се изискват промени в потребителския код (UDF).
- Изживяването с приложението Delta е опростено за потребителите, тъй като платформата осигурява гъвкавост и издръжливост от кутията и събира различни подробни показатели, които могат да се използват за предупреждения.
Производствена употреба
Delta се произвежда повече от година и играе ключова роля в много приложения на Netflix Studio. Тя помогна на екипите да внедрят случаи на използване като индексиране на търсене, съхранение на данни и работни потоци, управлявани от събития. По-долу е даден преглед на архитектурата на високо ниво на платформата Delta.
Фигура 5. Архитектура на високо ниво на Delta.
Признания
Бихме искали да благодарим на следните хора, които участваха в създаването и развитието на Delta в Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Шринивасан, Сандип Гупта, Стивън Ву, Таранга Гамаетиге, Юн Уанг и Женджонг Сю.
източници
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Онлайн обработка на събития. Общ. ACM 62 (5): 43–49 (2019). DOI:
: „Инструмент за изграждане на данни за Amazon Redshift Storage.“
Източник: www.habr.com