En antaŭĝojo de la lanĉo de nova fluo laŭ la rapideco Ni preparis tradukon de interesa materialo.
trarigardo
Ni parolos pri sufiĉe populara ŝablono per kiu aplikaĵoj uzas plurajn datumbutikojn, kie ĉiu vendejo estas uzata por siaj propraj celoj, ekzemple, por stoki la kanonan formon de datumoj (MySQL, ktp.), provizi altnivelajn serĉkapablojn (ElasticSearch, ktp.) .), kaŝmemoro (Memcached, ktp.) kaj aliaj. Tipe, kiam vi uzas plurajn datumbutikojn, unu el ili funkcias kiel la ĉefa vendejo kaj la aliaj kiel derivitaj vendejoj. La sola problemo estas kiel sinkronigi ĉi tiujn datumbutikojn.
Мы рассмотрели ряд различных паттернов, которые пытались решить проблему синхронизации нескольких хранилищ, таких как двойная запись, распределенные транзакции и т.д. Однако эти подходы имеют существенные ограничения в плане использования в реальной жизни, надежности и технического обслуживания. Помимо синхронизации данных, некоторым приложениям также необходимо обогащать данные, вызывая внешние сервисы.
Delta estis evoluigita por solvi tiujn problemojn. Delta finfine disponigas konsekvencan, okazaĵ-movitan platformon por datumsinkronigado kaj riĉigo.
Ekzistantaj solvoj
Duobla eniro
Чтобы синхронизировать два хранилища данных, можно использовать двойную запись, которая выполняет запись в одно хранилище, а потом сразу после этого делает запись в другое. Первую запись можно повторить, а вторую – прервать, если первая завершится неудачей после исчерпания количества попыток. Однако два хранилища данных могут перестать синхронизироваться, если запись во второе хранилище завершится неудачей. Решается эта проблема обычно созданием процедуры восстановления, которая может периодически повторно переносить данные из первого хранилища во второе или делать это только в том случае, если в данных обнаруживаются различия.
Problemoj:
Fari reakivan proceduron estas specifa laboro, kiu ne povas esti reuzita. Krome, datumoj inter stokaj lokoj restas nesinkronigitaj ĝis la restaŭra proceduro okazas. La solvo fariĝas pli kompleksa se pli ol du datumbutikoj estas uzataj. Fine, la restariga proceduro povas aldoni ŝarĝon al la originala datumfonto.
Ŝanĝi protokoltabelon
Kiam ŝanĝoj okazas al aro de tabeloj (kiel ekzemple enmetado, ĝisdatigo kaj forigo de rekordo), la ŝanĝregistroj estas aldonitaj al la protokolo-tabelo kiel parto de la sama transakcio. Alia fadeno aŭ procezo konstante petas eventojn de la protokolo-tabelo kaj skribas ilin al unu aŭ pluraj datumbutikoj, se necese, forigante eventojn de la protokolo-tabelo post kiam la registro estis konfirmita de ĉiuj butikoj.
Problemoj:
Ĉi tiu ŝablono devus esti efektivigita kiel biblioteko, kaj ideale sen ŝanĝi la kodon de la aplikaĵo kiu uzas ĝin. En poliglota medio, efektivigo de tia biblioteko devus ekzisti en iu ajn necesa lingvo, sed certigi konsistencon de funkcieco kaj konduto inter lingvoj estas tre malfacila.
Alia problemo kuŝas en akirado de skemŝanĝoj en sistemoj kiuj ne apogas transakciajn skemŝanĝojn [1][2], kiel ekzemple MySQL. Tial, la ŝablono fari ŝanĝon (ekzemple, skemoŝanĝo) kaj transakcie registri ĝin en la ŝanĝprotokolo-tabelo ne ĉiam funkcios.
Distribuitaj Transakcioj
Распределенные транзакции можно использовать для того, чтобы разделить транзакцию между несколькими разнородными хранилищами данных так, чтобы операция либо фиксировалась во всех используемых хранилищах, либо не фиксировалась ни в одном из них.
Problemoj:
Распределенные транзакции – очень большая проблема для разнородных хранилищ данных. По своей природе они могут полагаться только на наименьший общий знаменатель участвующих систем. Например, XA-транзакции блокируют выполнение, если в процессе приложения происходит сбой на этапе подготовки. Кроме того, XA не обеспечивает обнаружения дедлоков и не поддерживает оптимистические схемы управления параллелизмом. Помимо этого, некоторые системы по типу ElasticSearch не поддерживают XA или любую другую гетерогенную модель транзакций. Таким образом, обеспечение атомарности записи в различных технологиях хранения данных остается для приложений весьма сложной задачей [3].
delta
Delta estis desegnita por trakti la limojn de ekzistantaj datumsinkronigaj solvoj kaj ankaŭ ebligas sur-la-muŝan datumriĉigon. Nia celo estis abstrakti ĉiujn ĉi tiujn kompleksaĵojn for de aplikaĵprogramistoj por ke ili povu plene koncentriĝi pri efektivigado de komerca funkcieco. Poste ni priskribos "Movie Search", la realan uzkazon por Delta de Netflix.
Netflix vaste uzas mikroservan arkitekturon, kaj ĉiu mikroservo kutime servas unu specon de datumoj. Bazaj informoj pri la filmo estas enhavitaj en mikroservo nomata Filmservo, kaj rilataj datumoj kiel informoj pri produktantoj, aktoroj, vendistoj, ktp estas administritaj de pluraj aliaj mikroservoj (nome Deal Service, Talent Service kaj Vendor Service).
Komercaj uzantoj ĉe Netflix Studios ofte bezonas serĉi laŭ diversaj filmkriterioj, tial estas tre grave por ili povi serĉi tra ĉiuj film-rilataj datumoj.
Antaŭ Delta, la filmserĉa teamo bezonis eltiri datumojn de pluraj mikroservoj antaŭ indeksi la filmajn datumojn. Krome, la teamo devis evoluigi sistemon, kiu periode ĝisdatigus la serĉindekson petante ŝanĝojn de aliaj mikroservoj, eĉ se tute ne estus ŝanĝoj. Ĉi tiu sistemo rapide iĝis kompleksa kaj malfacile konservebla.
Figuro 1. Voĉa sistemo al Delta
Post uzado de Delta, la sistemo estis simpligita al okazaĵa sistemo kiel montrite en la sekva figuro. CDC (Ŝanĝo-Datumo-Kapto) okazaĵoj estas senditaj al Keystone Kafka temoj uzante Delta-Konektilon. Delta aplikaĵo konstruita uzante la Delta Stream Processing Framework (bazita sur Flink) ricevas CDC-okazaĵojn de temo, riĉigas ilin vokante aliajn mikroservojn, kaj finfine pasas la riĉigitajn datumojn al serĉindekso en Elasticsearch. La tuta procezo okazas preskaŭ en reala tempo, tio estas, tuj kiam ŝanĝoj estas faritaj al la datumstokejo, serĉaj indeksoj estas ĝisdatigitaj.
Figuro 2. Datuma dukto uzante Delta
En la sekvaj sekcioj, ni priskribos la funkciadon de la Delta-Konektilo, kiu konektas al la stokado kaj publikigas CDC-okazaĵojn al la transporta tavolo, kiu estas realtempa transdona infrastrukturo, kiu direktas CDC-eventojn al Kafka-temoj. Kaj ĉe la fino, ni parolos pri la Delta-flua prilabora kadro, kiun aplikaĵprogramistoj povas uzi por datumtraktado kaj riĉiga logiko.
CDC (Ŝanĝo-Datumo-Kapto)
Мы разработали CDC-сервис под названием Delta-Connector, который может фиксировать закоммиченные изменения из хранилища данных в режиме реального времени и писать их в поток. Изменения в реальном времени берутся из журнала транзакций и дампов хранилища. Дампы используются поскольку журналы транзакций обычно не хранят всю историю изменений. Изменения обычно сериализуются как события Delta, так что получателю не нужно беспокоиться о том, откуда появляется изменение.
Delta-Connector поддерживает несколько дополнительных функций, таких как:
- Kapablo skribi kutimajn eligajn datumojn preter Kafka.
- Возможность активации ручных дампов в любое время для всех таблиц, какой-то определенной таблицы или для определенных первичных ключей.
- Rubejoj povas esti prenitaj en pecoj, do ne necesas rekomenci en kazo de fiasko.
- Нет необходимости ставить блокировки на таблицы, что очень важно для того, чтобы трафик записи в базу данных никогда не блокировался нашим сервисом.
- Высокая доступность из-за резервных экземпляров в AWS Availability Zones.
Ni nuntempe subtenas MySQL kaj Postgres, inkluzive de deplojoj sur AWS RDS kaj Aurora. Ni ankaŭ subtenas Cassandra (multmajstro). Vi povas ekscii pliajn detalojn pri Delta-Connector ĉi tie .
Kafka kaj la transporta tavolo
Транспортный уровень событий Delta построен на сервисе обмена сообщениями платформы .
Historie, afiŝado sur Netflix estis optimumigita por alirebleco prefere ol longviveco (vidu sube). ). La kompromiso estis ebla maklerista datuma nekonsekvenco en diversaj randscenaroj. Ekzemple, malpura gvidanto elekto respondecas pri la ricevanto eble havanta duplikatajn aŭ perditajn eventojn.
Kun Delta, ni volis pli fortajn fortikajn garantiojn por certigi liveron de CDC-eventoj al derivitaj vendejoj. Tiucele ni proponis speciale desegnitan Kafka-areton kiel unuaklasan objekton. Vi povas rigardi kelkajn makleristajn agordojn en la suba tabelo:
En Keystone Kafka aretoj, malpura gvidanto elekto kutime inkluzivita por certigi eldonan alireblecon. Tio povas rezultigi mesaĝperdon se nesinkronigita kopio estas elektita kiel la gvidanto. Por nova alta havebleco Kafka-grupo, la opcio malpura gvidanto elekto malŝaltita por malhelpi mesaĝperdon.
Ni ankaŭ pliiĝis replika faktoro de 2 ĝis 3 kaj minimumaj nesinkronigitaj kopioj 1 ĝis 2. Eldonistoj skribantaj al ĉi tiu aro postulas aktojn de ĉiuj aliaj, certigante ke 2 el 3 kopioj havas la plej aktualajn mesaĝojn senditajn de la eldonisto.
Kiam maklerista petskribo finiĝas, nova petskribo anstataŭas la malnovan. Tamen, la nova makleristo devos atingi la nesinkronigitajn kopiojn, kiuj povas daŭri plurajn horojn. Por redukti la reakivan tempon por ĉi tiu scenaro, ni komencis uzi blokan datuman stokadon (Amazon Elastic Block Store) anstataŭ lokaj makleristaj diskoj. Kiam nova petskribo anstataŭigas finitan makleristan petskribon, ĝi aliĝas al la EBS-volumo kiun la finita kazo havis kaj komencas atingi novajn mesaĝojn. Ĉi tiu procezo reduktas la restarpuran tempon de horoj al minutoj ĉar la nova kazo ne plu bezonas reprodukti de malplena stato. Ĝenerale, apartaj stokado kaj maklerista vivocikloj signife reduktas la efikon de makleristoŝanĝado.
Por plue pliigi la garantion de livero de datumoj, ni uzis por detekti ajnan mesaĝperdon sub ekstremaj kondiĉoj (ekzemple, horloĝmalsinkronigo en la subdiskogvidanto).
Flua Pretiga Kadro
La pretigtavolo de Delta estas konstruita sur la Netflix SPaaS-platformo, kiu provizas Apache Flink-integriĝon kun la Netflix-ekosistemo. La platformo disponigas uzantinterfacon, kiu administras la disfaldiĝon de Flink-laboroj kaj instrumentadon de Flink-aretoj aldone al nia Titus-ujo-administra platformo. La interfaco ankaŭ administras laborkonfiguraciojn kaj permesas al uzantoj fari agordajn ŝanĝojn dinamike sen devi rekompili Flink-laborojn.
Delta provizas fluon prilaboradan kadron bazitan sur Flink kaj SPaaS kiu uzas komentario-bazita DSL (Domain Specific Language) por abstrakti teknikajn detalojn. Ekzemple, por difini la paŝon, ĉe kiu eventoj riĉiĝos per vokado de eksteraj servoj, uzantoj devas skribi la sekvan DSL, kaj la kadro kreos modelon bazitan sur ĝi, kiu estos ekzekutita de Flink.
Рисунок 3. Пример обогащения на DSL в Delta
La pretigkadro ne nur reduktas la lernkurbon, sed ankaŭ disponigas komunajn fluajn pretigajn funkciojn kiel ekzemple deduplikado, skematigo kaj fleksebleco kaj rezisteco por solvi oftajn funkciajn problemojn.
Delta Stream Processing Framework konsistas el du ŝlosilaj moduloj, la DSL & API-modulo kaj la Runtime-modulo. La DSL & API-modulo disponigas DSL kaj UDF (User-Defined-Function) API-ojn por ke uzantoj povu skribi sian propran pretigan logikon (kiel ekzemple filtrado aŭ transformoj). La Runtime-modulo disponigas efektivigon de DSL-analizilo kiu konstruas internan reprezentadon de pretigaj paŝoj en DAG-modeloj. La Execution-komponento interpretas DAG-modelojn por pravalorigi la faktajn Flink-deklarojn kaj finfine ruli la Flink-aplikaĵon. La arkitekturo de la kadro estas ilustrita en la sekva figuro.
Figuro 4. Delta Stream Processing Framework-arkitekturo
Ĉi tiu aliro havas plurajn avantaĝojn:
- Uzantoj povas koncentriĝi pri sia komerca logiko sen devi enprofundiĝi en la specifaĵoj de Flink aŭ la SPaaS-strukturo.
- Optimumigo povas esti farita en maniero kiu estas travidebla al uzantoj, kaj eraroj povas esti fiksitaj sen postulado de ajnaj ŝanĝoj al la uzantkodo (UDF).
- Работа приложений Delta упрощена для пользователей, поскольку платформа обеспечивает гибкость и отказоустойчивость из коробки и собирает множество подробных метрик, которые можно использовать для оповещений.
Produktada uzo
Delta estas en produktado dum pli ol unu jaro kaj ludas ŝlosilan rolon en multaj Netflix Studio-aplikoj. Ŝi helpis teamojn efektivigi uzkazojn kiel serĉindeksadon, datumstokadon kaj okazaĵajn laborfluojn. Malsupre estas superrigardo de la altnivela arkitekturo de la Delta-platformo.
Figuro 5. La altnivela arkitekturo de Delta.
Dankoj
Ni ŝatus danki la jenajn homojn, kiuj partoprenis en la kreado kaj disvolviĝo de Delta ĉe Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang kaj Zhenzhong Xu.
Fontoj
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Datuma Konstrua Ilo por Amazon Redshift Stokado."
fonto: www.habr.com