Դելտա. Տվյալների համաժամացման և հարստացման հարթակ

փոխարժեքով նոր հոսքի մեկնարկի ակնկալիքով Տվյալների ինժեներ Հետաքրքիր նյութի թարգմանություն ենք պատրաստել։

Վերանայել

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

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

Delta-ն մշակվել է այս խնդիրները լուծելու համար: Delta-ն, ի վերջո, ապահովում է հետևողական, իրադարձությունների վրա հիմնված հարթակ տվյալների համաժամացման և հարստացման համար:

Առկա լուծումներ

Կրկնակի մուտք

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

Խնդիրներ:

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

Փոխել գրանցամատյանների աղյուսակը

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

Խնդիրներ:

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

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

Բաշխված գործարքներ

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

Խնդիրներ:

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

դելտա

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

Netflix-ը լայնորեն օգտագործում է միկրոսերվիսային ճարտարապետություն, և յուրաքանչյուր միկրոծառայություն սովորաբար սպասարկում է մեկ տեսակի տվյալ: Ֆիլմի մասին հիմնական տեղեկատվությունը պարունակվում է 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-ի իրադարձությունները թեմայից, հարստացնում է դրանք՝ զանգահարելով այլ միկրոծառայություններ և վերջապես փոխանցում է հարստացված տվյալները Elasticsearch-ի որոնման ինդեքսին: Ամբողջ գործընթացը տեղի է ունենում գրեթե իրական ժամանակում, այսինքն, հենց որ փոփոխությունները կատարվեն տվյալների պահեստում, որոնման ինդեքսները թարմացվում են:

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

CDC (Change-Data-Capture)

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

Delta-Connector-ն աջակցում է մի քանի լրացուցիչ հնարավորությունների, ինչպիսիք են՝

• Կաֆկայի կողքին հատուկ ելքային տվյալներ գրելու ունակություն:
• Բոլոր աղյուսակների, որոշակի աղյուսակի կամ հատուկ առաջնային ստեղների համար ցանկացած պահի ձեռքով աղբարկղերը ակտիվացնելու ունակություն:
• Աղբավայրերը կարելի է վերցնել կտորներով, այնպես որ ձախողման դեպքում ամեն ինչ նորից սկսելու կարիք չկա:
• Սեղանների վրա կողպեքներ տեղադրելու կարիք չկա, ինչը շատ կարևոր է ապահովելու համար, որ տվյալների բազայի գրման տրաֆիկը երբեք չի արգելափակվի մեր ծառայության կողմից:
• Բարձր հասանելիություն AWS-ի հասանելիության գոտիներում ավելորդ դեպքերի պատճառով:

Մենք ներկայումս աջակցում ենք MySQL-ին և Postgres-ին, ներառյալ տեղակայումները AWS RDS-ում և Aurora-ում: Մենք նաև աջակցում ենք Կասանդրային (մուլտի վարպետ): Delta-Connector-ի մասին ավելի շատ մանրամասներ կարող եք իմանալ այստեղ բլոգի գրառումը.

Կաֆկան և տրանսպորտային շերտը

Delta-ի իրադարձությունների տրանսպորտային շերտը կառուցված է հարթակի հաղորդագրությունների ծառայության վրա Պորտաքար.

Պատմականորեն, Netflix-ում տեղադրումը օպտիմիզացված է հասանելիության համար, այլ ոչ թե երկարակեցության (տես ստորև): նախորդ հոդվածը) Փոխզիջումը պոտենցիալ բրոքերային տվյալների անհամապատասխանությունն էր տարբեր եզրային սցենարներում: Օրինակ, անմաքուր առաջնորդի ընտրություն պատասխանատու է այն բանի համար, որ ստացողը կարող է կրկնօրինակ կամ կորցրած իրադարձություններ ունենալ:

Delta-ի հետ մենք ցանկանում էինք երկարակեցության ավելի ուժեղ երաշխիքներ՝ ապահովելու CDC միջոցառումների առաքումը ածանցյալ խանութներ: Այդ նպատակով մենք առաջարկեցինք հատուկ մշակված Կաֆկա կլաստերը՝ որպես առաջին կարգի օբյեկտ: Բրոքերի որոշ կարգավորումներ կարող եք դիտել ստորև բերված աղյուսակում.

Keystone Kafka կլաստերներում, անմաքուր առաջնորդի ընտրություն սովորաբար ներառված է հրատարակչի հասանելիությունն ապահովելու համար: Սա կարող է հանգեցնել հաղորդագրության կորստի, եթե չհամաժամեցված կրկնօրինակն ընտրվի որպես առաջատար: Նոր բարձր հասանելիության Kafka կլաստերի համար տարբերակը անմաքուր առաջնորդի ընտրություն անջատված է հաղորդագրության կորուստը կանխելու համար:

Մենք էլ ավելացրինք կրկնօրինակման գործոնը 2-ից 3 և նվազագույն insync կրկնօրինակներ 1-ից 2. Այս կլաստերին գրող հրատարակիչները պահանջում են բոլոր մյուսներից ելքեր՝ ապահովելով, որ 2 կրկնօրինակներից 3-ն ունենան հրատարակչի կողմից ուղարկված ամենաթարմ հաղորդագրությունները:

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

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

Stream Processing Framework

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

Delta-ն ապահովում է հոսքի մշակման շրջանակ՝ հիմնված Flink-ի և SPaaS-ի վրա, որն օգտագործում է անոտացիայի վրա հիմնված DSL (Domain Specific Language) վերացական տեխնիկական մանրամասների համար: Օրինակ, որոշելու համար, թե ինչ քայլով իրադարձությունները կհարստացվեն՝ կանչելով արտաքին ծառայություններ, օգտատերերը պետք է գրեն հետևյալ DSL-ը, և շրջանակը դրա հիման վրա կստեղծի մոդել, որը կկատարվի Flink-ի կողմից։

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

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

Delta Stream Processing Framework-ը բաղկացած է երկու հիմնական մոդուլներից՝ DSL & API մոդուլից և Runtime մոդուլից: DSL & API մոդուլը տրամադրում է DSL և UDF (User-Defined-Function) API-ներ, որպեսզի օգտվողները կարողանան գրել իրենց սեփական մշակման տրամաբանությունը (օրինակ՝ զտումը կամ փոխակերպումները): Runtime մոդուլը ապահովում է DSL վերլուծիչի իրականացում, որը կառուցում է մշակման քայլերի ներքին ներկայացում DAG մոդելներում: Execution բաղադրիչը մեկնաբանում է DAG մոդելները՝ սկզբնավորելու իրական Flink հայտարարությունները և ի վերջո գործարկելու Flink հավելվածը: Շրջանակի ճարտարապետությունը պատկերված է հետևյալ նկարում:

Նկար 4. Delta Stream Processing Framework ճարտարապետությունը

Այս մոտեցումը մի քանի առավելություն ունի.

• Օգտագործողները կարող են կենտրոնանալ իրենց բիզնեսի տրամաբանության վրա՝ առանց Flink-ի կամ SPaaS կառուցվածքի առանձնահատկությունների մեջ խորանալու:
• Օպտիմալացումը կարող է իրականացվել այնպես, որ օգտագործողների համար թափանցիկ լինի, և սխալները կարող են շտկվել՝ չպահանջելով որևէ փոփոխություն օգտվողի կոդը (UDF):
• Delta հավելվածի փորձը պարզեցված է օգտատերերի համար, քանի որ հարթակն ապահովում է ճկունություն և ճկունություն, ինչպես նաև հավաքում է մի շարք մանրամասն չափումներ, որոնք կարող են օգտագործվել ահազանգերի համար:

Արտադրության օգտագործումը

Delta-ն արտադրվում է ավելի քան մեկ տարի և առանցքային դեր է խաղում Netflix Studio-ի բազմաթիվ հավելվածներում: Նա օգնեց թիմերին կիրառել օգտագործման դեպքեր, ինչպիսիք են որոնման ինդեքսավորումը, տվյալների պահպանումը և իրադարձությունների վրա հիմնված աշխատանքային հոսքերը: Ստորև ներկայացված է Delta հարթակի բարձր մակարդակի ճարտարապետության ակնարկ:

Նկար 5. Դելտայի բարձր մակարդակի ճարտարապետությունը:

Շնորհակալագրեր

Ցանկանում ենք շնորհակալություն հայտնել հետևյալ մարդկանց, ովքեր մասնակցել են Netflix-ում Delta-ի ստեղծմանը և զարգացմանը. Սրինիվասան, Սանդիպ Գուպտա, Սթիվեն Վու, Թարանգա Գամաեթիգեն, Յուն Վանգ և Չժենժոն Սյու:

Տեղեկատվության աղբյուրներ

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. Առցանց իրադարձությունների մշակում: կոմուն. ACM 62(5): 43–49 (2019): DOI: doi.org/10.1145/3312527

Գրանցվեք անվճար վեբինարին«Տվյալների ստեղծման գործիք Amazon Redshift Storage-ի համար»:

Source: www.habr.com