Delta: Տվյաների սինխրոնացման և հարստացման հարթակ

Նոր հոսքի մեկնարկի նախաշեմին «Data Engineer» մենք պատրաստել ենք հետաքրքիր նյութի թարգմանություն։

Ամփոփում

Մենք կսահմանենք բավականին հայտնի ժամանակահատված, որի օգնությամբ հավելվածները օգտագործում են մի քանի տվյալների պահեստներ, որտեղ յուրաքանչյուր պահեստ օգտագործվում է իր նպատակներում, օրինակ՝ տվյալների կանոնական ձևերի պահեստավորման համար (MySQL և այլն), ընդլայնված որոնողական հնարավորությունների ապահովման համար (ElasticSearch և այլն), կառավարման (Memcached և այլն) և այլնի։ Ը généralement, երբ օգտագործվում են մի քանի տվյալների պահեստներ, դրանցից մեկը գործում է որպես հիմնական պահեստ, իսկ մյուսները՝ որպես derivative պահպանողներ։ Միակ խնդիրն այն է, թե ինչպես սինխրոնացնել այս տվյալների պահեստները։

Մենք դիտել ենք մի շարք տարբեր ժամանակահատվածներ, որոնք փորձում էին լուծել մի քանի պահեստների սինխրոնացման խնդիրը, օրինակ՝ կրկնակի գրանցում, բաշխված տրանզակցիաներ և այլն։ Սակայն այս մոտեցումները կարեւոր սահմանափակում ունեն իրական կյանքի, հուսալիության և տեխնիկական սպասարկման առումով։ Տվյալների սինխրոնացմանը ավելին, որոշ հավելվածներին նաև անհրաժեշտ է հարստացնել տվյալները, կոչելով արտաքին ծառայություններ։

Այս խնդիրների լուծման համար մշակվել է Delta։ Delta ժամանակի ընթացքում ներկայացնում է միակակիրթ, միջոցներով կառավարվող հարթակ տվյալների սինխրոնացման և հարստացման համար։

Սովորական լուծումներ

Կրկնակի գրառում

Երկու տվյալների պահեստների սինխրոնացման համար կարող եք օգտագործել կրկնակի գրառում, որը կատարում է գրառում մեկ պահեստում, և հետո անմիջապես գրառում մեկ ուրիշում։ Առաջին գրառումը կարելի է կրկնել, իսկ երկրորդը՝ ընդհատել, եթե առաջինն անհաջող լինի փորձերի քանակի լրանալուց հետո։ Սակայն երկու պահեստներ կարող են դադարեցնել սինխրոնացումը, եթե գրառումը երկրորդ պահեստում անհաջող լինի։ Այս խնդիրը սովորաբար լուծվում է վերականգնման ընթացակարգ ստեղծելով, որը կարող է ժամանակի ընթացքում կրկին տեղափոխել տվյալները առաջին պահեստից երկրորդ կամ դա անել միայն այն դեպքում, եթե տվյալներում տարբերություններ հայտնաբերվեն։

Անհարմարություններ՝

Վերականգնման ընթացակարգն՝ հատուկ աշխատանք է, որը չի կարելի վերաօգտագործել։ Հավելյալ, տվյալները պահեստների միջև շարունակում են մնալ չսինխրոնացված, մինչև վերականգնման ընթացակարգը տեղի ունենա։ Հիմքի դժվարացվում է, եթե օգտագործվում է ավելի քան երկու տվյալների պահեստ։ Եվ վերջապես, վերականգնման ընթացակարգը կարող է ավելացնել բեռը սկզբնական տվյալների աղբյուրին։

Փոփոխությունների լոգեր

Թվում է, որ տվյալների ցանկերի մեջ փոփոխություններ լինում են (օրինակ, շարունակական, թարմացում և գրառման հեռացում), փոփոխությունների գրառումները ավելացվում են քրոնոլոգիական աղյուսակ, իբրև նույն գործարքի մի մաս: Մյուս հոսքը կամ գործընթացը մշտապես հարցնում է իրադարձություններ քրոնոլոգիական աղյուսակից և գրանցում դրանք մեկ կամ մի քանի տվյալների պահեստներում, երբ անհրաժեշտ է հեռացնել իրադարձությունները քրոնոլոգիական աղյուսակից, երբ գրանցման հաստատման արդյունքում բոլոր պահեստները հաստատում են դրանք:

Անհարմարություններ՝

Այս նախատիպը պետք է իրականացվի որպես գրադարան և իդեալական է առանց փոփոխության կիրառող ծրագրի ծածկագրի: Քաղաքական միջավայրում այսպիսի գրադարանի իրականացումը պետք է գոյություն ունենա ցանկացած անհրաժեշտ լեզվով, սակայն ֆունկցիաների և վարքագծի հարմասնություն պահելը լեզուների միջև շատ դժվար է:

Այն խնդիրը, որ առաջանում է, կապված է սխեմայի փոփոխությունների ստացման հետ, այն կառավարման համակարգերում, որոնք չեն աջակցում գործարքային սխեմայի փոփոխություններին [1][2], ինչպես, օրինակ, MySQL: Այդ պատճառով փոփոխությունների կատարելու նախատիպը (օրինակ, սխեմայի փոփոխությունը) և այդ փոփոխությունների գրառումը քրոնոլոգիական աղյուսակի մեջ միշտ չէ, որ կաշխատի:

Վարակված Գործարքներ

Վարակված գործարքները կարող են օգտագործվել, որպեսզի բաժանեն գործարքը մի քանի տարատեսակ տվյալների պահեստներում, այնպես, որ գործողությունը ֆիքսվի բոլոր օգտագործվող պահեստներում, կամ էլ չֆիքսվի որևէ մեկում:

Անհարմարություններ՝

Վարակված գործարքները շատ մեծ խնդիր են բազմազան տվյալների պահեստների համար: Նկարագրությանպիսին, նրանք կարող են համենայնդեպս, հիմնվել միայն մասնակցող համակարգերի ամենափոքր ընդհանուր մասնակիցների վրա: Օրինակ, XA-գործարքները արգելափակում են կատարման, եթե հայտի մշակման ընթացքում տեղի է ունենում անհաջողություն նախապատրաստության փուլում: Բացի այդ, XA-ն չի տրամադրում բլոկերների հայտնաբերման և չի աջակցում օպտիմիստական համահեղինակման սխեմաներին: Իր հերթին, որոշ համակարգեր, ինչպիսիք են ElasticSearch, չեն աջակցում XA-ին կամ ցանկացած այլ հիբրիդային գործարքների մոդելին: Այսպիսով, տարբեր տվյալների պահերի տեխնոլոգիաներում գրառումների ձերբազատման ապահովումը մնում է չափազանց բարդ խնդիր ծրագրերի համար [3].

Delta

Delta մշակվել է առկա տվյալների համաժամացման լուծումների սահմանափակումները վերացնելու համար, այն նաև թույլ է տալիս տվյալները հարստացնել վարագույրի վրա: Մեր նպատակն է այս բոլոր բարդությունները աբստրակտել ծրագրավորման մշակողների համար, որպեսզի նրանք կարողանան ամբողջովին կենտրոնանալ բիզնես-ֆունկցիայի իրականացման վրա: Ապագայում մենք կբնութագրենք «Movie Search»-ը՝ Netflix-ի Delta-ի իրական կիրառման դեպքը:

Netflix-ում լայնորեն կիրառվում է միկրո ծառայությունների arquitectura և յուրաքանչյուր միկրո ծառայություն սովորաբար սպասարկում է մեկ տվյալների տեսակի. Ֆիլմի մասին հիմնական տեղեկատվությունը հասանելի է Movie Service միկրո ծառայությունում, ինչպես նաև դրա հետ կապված տվյալները, ինչպիսիք են պրոդյուսերների, դերասանների, վաճառողների տեղեկությունները և այլն, կառավարում են մի քանի այլ միկրո ծառայություններ (特别乎 Deal Service, Talent Service և Vendor Service).
Բիզնես օգտվողները Netflix Studios-ում հաճախ պահանջում են ֆիլմերի որոնում տարբեր չափանիշներով, ուստի նրանց համար առկա է շատ կարևոր ունենա ամենաթարմ տվյալների որոնման հնարավորություն, որոնք կապված են ֆիլմերի հետ.

Դելտայի առաջամարտիկին թիմը ֆիլմերի որոնման պահին պետք է ստանա տվյալներ մի քանի միկրո ծառայություններից, մինչև ֆիրմերը տվյալները: Բացի այդ, թիմը պետք է մշակեր համակարգ, որը ժամանակին թարմացրեց որոնման ինդեքսը, հարցնելով փոփոխություններ մյուս միկրո ծառայություններից, նույնիսկ եթե փոփոխություններ չկային: Այս համակարգը շատ արագ բարդացավ և դժվար եղավ աջակցելու համար.

Ռուսույց 1. Փոլլինգի համակարգը մինչև Delta
Դելտայի օգտագործման սկսվելուց հետո, համակարգը պարզվեց մինչև իրադարձություններով կառավարվող համակարգ, ինչպես ցույց է տրված հաջորդ բնույթով: CDC (Change-Data-Capture) իրադարձությունները ուղարկվում են Keystone Kafka-ի թեմաներ Delta-Connector-ի միջոցով: Delta ծրագիրը, որը կառուցված է Delta Stream Processing Framework-ի (Flink-ի հիման վրա), ստանում է CDC իրադարձությունները թեմայից, enriquecición է դրանք, հրավիրելով այլ միկրո ծառայություններ և վերջապես փոխանցում է հարուստ տվյալները որոնման ինդեքսում Elasticsearch: Ամբողջ գործընթացը անցնում է գրեթե իրական ժամանակում, այսինքն, երբ փոփոխությունները նշվում են տվյալների պահեստում, որոնման ինդեքսները թարմացվում են.

Ռուսույց 2. Տվյալների պipeline Delta-ի օգտագործմամբ
Հաջորդ բաժիններում մենք կբռնենք Delta-Connector-ի աշխատանքը, որը միանում է պահեստին և հրապարակում է CDC իրադարձությունները տրանսպորտի մակարդակում, որը ներկայացնում է իրական ժամանակի տվյալների փոխանցման ենթակառուցվածքը, ուղղված CDC իրադարձությունները Kafka-ի թեմաներին: Իսկ վերջում մենք կխոսենք Delta հոսքային մշակման կառուցվածքի մասին, որը կարող են օգտագործել ծրագրի մշակողները տվյալների մշակման և enrichment տրամաբանության համար.

CDC (Change-Data-Capture)

Մենք մշակել ենք CDC ծառայություն, որը կոչվում է Delta-Connector, որը կարող է իրական ժամանակում գրանցել կատարված փոփոխություններ տվյալների պահեստում և գրանցել դրանք հոսքում: Իրական ժամանակի փոփոխությունները վերցվում են գործարքների գրանցումից և պահեստի շրջանակից: Շրջանակները օգտագործվում են, քանի որ գործարքների գրանցումները սովորաբար չեն պահում փոփոխությունների ամբողջ պատմությունը. Փոփոխությունները սովորաբար սերիալացված են որպես Delta իրադարձություններ, որպեսզի ընդունողը չվախենա, թե որտեղից է գալիս փոփոխությունը.

Delta-Connector-ը աջակցում է մի քանի լրացուցիչ ֆունկցիաների, ինչպիսիք են:

• Հնարավորություն գրելու համար եզակի ելքային տվյալներ, շրջանցելով Kafka:
• Հնարավորություն ակտիվացնելու ձեռքով ռեժիմների ընտանեկան տվյալների հավաքման հնարավորություն ցանկացած ժամանակ՝ բոլոր աղյուսակների, որոշակի աղյուսակի կամ որոշակի հիմնական բանալիի համար:
• Տվյալները կարելի է հավաքել կտորներով, այնպես որ, սբուրզմայի դեպքում սկսելու անհրաժեշտություն չկա:
• Աղյուսակները արգելափակելու անհրաժեշտություն չկա, ինչը շատ կարևոր է, որպեսզի տվյալների բազայի գրանցման հոսքը երբեք չարգելափակվի մեր ծառայության կողմից:
• Բարձր հասանելիություն AWS Availability Zones-ում резервային օրինակների շնորհիվ:

Այս պահին մենք աջակցում ենք MySQL և Postgres, ներառյալ AWS RDS և Aurora-ում տեղակայման ժամանակ: Մենք նաև աջակցում ենք Cassandra-ին (բազմաթագավոր): Դելտա-կոնեկտորի մասին ավելին կարող եք իմանալ այս բլոգում:.

Kafka և փոխադրումնիկի մակարդակը:

Դեհետումների տեղափոխման մակարդակը Delta-ծառավող է բովանդակության փոխանակման ծառայության վրա: Keystone:.

Պատմականորեն, հաղորդագրությունների տարածումը Netflix-ում օպտիմիզացրել է հասանելիության բարձրացման համար, ոչ թե մշտության (տես նախորդ հոդվածը)). Դրա փոխհատուցումը կարող էր լինել տվյալների համապատասխանության պոտենցիալ անջատում` տարբեր այդ ծայրահեղ իրավիճակներում: Օրինակ՝ unclean leader election: Այս խնդրով կարող է լինել այն, որ ընդունողը պոտենցիալ կրկնակի է անում կամ կորցնում է հաշիվները:

Delta-ով մենք ցանկացանք ստանալ ավելի ուժեղ հավաստիացումներ մշտության վերաբերյալ, որպեսզի ապահովենք CDC-միջոցները ճանապարհով դեպի ծնողական պահոցներ: Այդ նպատակով մենք առաջարկեցինք` հատուկ նախագծված Kafka խումբ որպես առաջին կարգի օբյեկտ: Դուք կարող եք դիտարկել որոշ տեղեկություններ ստորև բերված աղյուսակում:

Keystone Kafka խմբերում: unclean leader election: Հաճախ կոնֆիգուրացված է՝ հրապարակողի հասանելիությունը ապահովելու համար: Սա կարող է հանգեցնել հաղորդագրությունների կորուստներին, եթե մեկ ստուգված կրկնօրինակ ընտրվում է որպես առաջնորդ: Նոր բարձր հուսալի Kafka խմբի պարամետր unclean leader election: ներառում է պահպանման ընկերությունը հաղորդագրությունների կորուստը կանխելու համար:

Մենք նաև բարձրացրել ենք replication factor-ը 2-ից 3, և minimum insync replicas-ը 1-ից 2: Առաջարկողները, գրելու այս խմբում, պահանջում են acks մյուսներից, ապահովելով, որ 2-ի 3 կրկնօրինակները օրենքում ունեն ավելի արդիական հաղորդագրություններ, ուղարկված առաջարկողից:

Երբ բրոքերի օրինակն ավարտում է աշխատանքը, նոր օրինակն փոխարինում է հինին: Սակայն նոր բրոքերին անհրաժեշտ կլինի հասնել չսինխռոնիզացված կրկնօրինակներին, ինչը կարող է տևել մի քանի ժամ: Այս սցենարի վերականգնման ժամանակը կրճատելու համար մենք սկսել ենք օգտագործել բլոկային տվյալների պահեստ (Amazon Elastic Block Store)՝ բրոքերների տեղական դրոշներով փոխարեն: Երբ նոր օրինակն ակնթարթորեն փոխարինում է ավարտված բրոքերի օրինակին, նա միանում է EBS ծավալին, որը բաժանվել է ավարտված օրինակին, և սկսում է հասնել նոր հաղորդագրություններին: Այս գործընթացը կրճատում է ուշացումները մի քանի ժամից մինչև մի քանի րոպե, քանի որ նոր օրինակին այլևս չի հարկավոր կրկնօրինակումից սկսել: Ընդհանուր առմամբ, պահեստի և բրոքերի առանձին Lebenszyklen-երը զգալիորեն նվազեցնում են բրոքերի փոփոխման ազդեցությունը.

Դա դեռ ավելի շատ համակարգ ապահովելու համար մենք օգտագործել ենք Հաղորդագրությունների հետևման համակարգ հայտնաբերելու համար ցանկացած հաղորդագրության կորուստ ծայրահեղ պայմաններում (օրինակ, բաժնի ղեկավարի ժամերի դիսհարмониայում):

Հոսքային մշակման շրջանակ

Delta-ի մշակման մակարդակը կառուցված է Netflix SPaaS հարթակի հիման վրա, որը ապահովում է Apache Flink-ի ինտեգրումը Netflix-ի էկոհամակարգին: Հարթակը ապահովում է օգտատերերի ինտերֆեյս, որը կառավարում է Flink աշխատանքների տեղաբաշխումը և Flink կլաստերների օրկեստրացիան մեր Titus կոնտեյներների կառավարման հարթակի վրա: Ինտերֆեյսը նաև կառավարում է աշխատանքի կոնֆիգուրացիաները և թույլ է տալիս օգտվողներին դինամիկ կերպով փոփոխել կոնֆիգուրացիան առանց Flink աշխատանքի վերակոմպիլյացիայի անհրաժեշտության.

Delta-ն ապահովում է Flink և SPaaS հիմնված հոսքային մշակման շրջանակ, որը օգտագործում է անշանակումների վրա հիմնված DSL (特定领域语言), որպեսզի հեռացվի տեխնիկական մանրամասները: Օրինակ, որպեսզի սահմանեք այն քայլը, որով կետերը ամբողջացվեն, կոչելով արտաքին ծառայություններ, օգտվողները պետք է գրեն հետևյալ DSL-ն, իսկ շրջանակը կստեղծի դրա հիման վրա մոդել, որը կկատարի Flink-ը.

Պատկեր 3. Դելտայում DSL-ի վրա հիմնված հարստացման օրինակ

Հոսքային մշակման շրջանակը ոչ միայն կրճատում է ուսման ոլորանն, այլ նաև ապահովում է ընդհանուր հոսքային մշակման գործառույթներ, ինչպիսիք են կրկնօրինակումից խուսափելու, սխեմայի սահմանում, ինչպես նաև ճկունություն և դիմակայություն, որպեսզի լուծեն ընդհանուր խնդիրները ծրագրերում.

Delta Stream Processing Framework-ը բաղկացած է երկու հիմնական մոդուլներից՝ DSL & API մոդուլից և Runtime մոդուլից: DSL & API մոդուլը предоставляет DSL և UDF (User-Defined-Function) API, որպեսզի օգտվողները կարողանան գրել իրենց սեփական մշակման lógica (օրինակ՝ ֆիլտրում կամ վերափոխում): Runtime մոդուլը বাস্তագործում է DSL-ի վերբանման պարսեր, որը կառուցում է աշխատանքների ներքին ներկայացումը DAG մոդելներում: Execution բաղադրիչը մեկնաբանում է 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 Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang և Zhenzhong Xu.

Աղբյուրներ

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: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

Գրանցվել անվճար վեբինարի համար: «Data Build Tool для хранилища Amazon Redshift».

Ընտանիք: habr.com