Բաց կոդով DataHub. LinkedIn-ի մետատվյալների որոնման և հայտնաբերման հարթակ

Բաց կոդով DataHub. LinkedIn-ի մետատվյալների որոնման և հայտնաբերման հարթակ

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

Այս հոդվածում մենք կխոսենք այն մասին, թե ինչպես ենք հրապարակել տվյալների աղբյուրը բաց լիցենզիայի ներքո DataHub մեր մետատվյալների որոնման և հայտնաբերման հարթակում, սկսած նախագծի առաջին օրերից ՈրտեղԻնչպես. LinkedIn-ը պահպանում է DataHub-ի իր տարբերակը՝ բաց կոդով տարբերակից առանձին: Մենք կսկսենք բացատրելով, թե ինչու են մեզ անհրաժեշտ երկու առանձին մշակման միջավայրեր, ապա կքննարկենք բաց կոդով WhereHows-ի օգտագործման վաղ մոտեցումները և համեմատենք DataHub-ի մեր ներքին (արտադրական) տարբերակը: GitHub. Մենք նաև կկիսվենք մեր նոր ավտոմատացված լուծման վերաբերյալ՝ բաց կոդով թարմացումներ մղելու և ստանալու համար՝ երկու պահեստները համաժամեցված պահելու համար: Ի վերջո, մենք կտրամադրենք հրահանգներ, թե ինչպես սկսել օգտվել բաց կոդով DataHub-ից և համառոտ կքննարկենք դրա ճարտարապետությունը:

WhereHows-ն այժմ DataHub է:

LinkedIn-ի մետատվյալների թիմը նախկինում ներկայացված էր DataHub (WhereHows-ի իրավահաջորդը), LinkedIn-ի որոնման և մետատվյալների հայտնաբերման հարթակը և այն բացելու ընդհանուր ծրագրերը: Այս հայտարարությունից կարճ ժամանակ անց մենք թողարկեցինք DataHub-ի ալֆա տարբերակը և այն կիսեցինք համայնքի հետ: Այդ ժամանակից ի վեր մենք շարունակաբար ներդրում ենք կատարել պահոցում և աշխատել շահագրգիռ օգտատերերի հետ՝ ավելացնելու ամենաշատ պահանջվող հնարավորությունները և լուծել խնդիրները: Այժմ մենք ուրախ ենք հայտարարել պաշտոնական թողարկման մասին DataHub-ը GitHub-ում.

Բաց կոդով մոտեցումներ

WhereHows, LinkedIn-ի սկզբնական պորտալը՝ տվյալներ գտնելու և որտեղից են դրանք գալիս, սկսվել է որպես ներքին նախագիծ; մետատվյալների թիմը բացեց այն սկզբնական կոդը 2016 թ. Այդ ժամանակից ի վեր թիմը միշտ պահպանել է երկու տարբեր կոդերի բազա՝ մեկը բաց կոդով և մեկը՝ LinkedIn-ի ներքին օգտագործման համար, քանի որ LinkedIn-ի օգտագործման դեպքերի համար մշակված արտադրանքի ոչ բոլոր հատկանիշներն են սովորաբար կիրառելի ավելի լայն լսարանի համար: Բացի այդ, WhereHows-ն ունի որոշ ներքին կախվածություններ (ենթակառուցվածք, գրադարաններ և այլն), որոնք բաց կոդով չեն: Հետագա տարիներին WhereHows-ն անցավ բազմաթիվ կրկնությունների և զարգացման ցիկլերի միջով՝ երկու կոդերի բազաները համաժամեցված պահելը մեծ մարտահրավեր դարձնելով: Մետատվյալների թիմը տարիների ընթացքում փորձել է տարբեր մոտեցումներ՝ փորձելով պահպանել ներքին և բաց կոդով մշակումը համաժամեցված:

Առաջին փորձը. «Սկզբում բաց կոդով»

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

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

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

Երկրորդ փորձ. «Նախ ներքին»

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

Երրորդ անգամ այն ​​աշխատեց:

Վերը նշված երկու անհաջող փորձերը հանգեցրին նրան, որ WhereHows GitHub պահոցը երկար ժամանակ հնացած մնաց: Թիմը շարունակեց բարելավել արտադրանքի առանձնահատկությունները և ճարտարապետությունը, այնպես որ LinkedIn-ի համար WhereHows-ի ներքին տարբերակը դարձավ ավելի առաջադեմ, քան բաց կոդով տարբերակը: Այն նույնիսկ նոր անուն ուներ՝ DataHub: Հիմնվելով նախկին անհաջող փորձերի վրա՝ թիմը որոշեց զարգացնել լայնածավալ, երկարաժամկետ լուծում:

Ցանկացած նոր բաց կոդով նախագծի համար LinkedIn-ի բաց կոդով թիմը խորհուրդ է տալիս և աջակցում զարգացման մոդելի, որի դեպքում նախագծի մոդուլներն ամբողջությամբ մշակված են բաց կոդով: Տարբերակված արտեֆակտները տեղակայվում են հանրային պահեստում, այնուհետև նորից ստուգվում են LinkedIn-ի ներքին արտեֆակտում՝ օգտագործելով արտաքին գրադարանի հարցում (ELR). Զարգացման այս մոդելին հետևելը ոչ միայն լավ է նրանց համար, ովքեր օգտագործում են բաց կոդով, այլ նաև հանգեցնում է ավելի մոդուլային, ընդարձակվող և խցանելի ճարտարապետության:

Այնուամենայնիվ, հասուն հետին պլանային հավելվածը, ինչպիսին է DataHub-ը, զգալի ժամանակ կպահանջի այս վիճակին հասնելու համար: Սա նաև բացառում է բաց աղբյուրների լիարժեք գործող ներդրման հնարավորությունը, մինչև բոլոր ներքին կախվածությունները լիովին վերացվեն: Ահա թե ինչու մենք մշակել ենք գործիքներ, որոնք օգնում են մեզ բաց կոդով ներդրումներ կատարել ավելի արագ և շատ ավելի քիչ ցավով: Այս լուծումը ձեռնտու է և՛ մետատվյալների թիմին (DataHub ծրագրավորող), և՛ բաց կոդով համայնքին: Հետևյալ բաժինները կքննարկեն այս նոր մոտեցումը:

Բաց կոդով հրատարակչական ավտոմատացում

Մետատվյալների թիմի վերջին մոտեցումը բաց կոդով DataHub-ի նկատմամբ գործիքի մշակումն է, որն ավտոմատ կերպով համաժամացնում է ներքին կոդի բազան և բաց կոդով շտեմարանը: Այս գործիքակազմի բարձր մակարդակի առանձնահատկությունները ներառում են.

1. Համաժամեցրեք LinkedIn-ի կոդը բաց կոդով/բաց կոդով, նմանատիպ rsync.
2. Լիցենզիայի վերնագրի ստեղծումը, նման է Ապաչի առնետ.
3. Ավտոմատ կերպով ստեղծեք բաց կոդով պարտավորությունների գրանցամատյաններ ներքին պարտավորությունների մատյաններից:
4. Կանխել ներքին փոփոխությունները, որոնք խախտում են բաց կոդով կառուցվածները կախվածության փորձարկում.

Հետևյալ ենթաբաժիններում մանրամասն կքննարկվեն հետաքրքիր խնդիրներ ունեցող վերը նշված գործառույթները։

Աղբյուրի կոդի համաժամացում

Ի տարբերություն DataHub-ի բաց կոդով տարբերակի, որը մեկ GitHub պահոց է, DataHub-ի LinkedIn տարբերակը մի քանի պահեստների համակցություն է (որը կոչվում է ներքին բազմատեսակ արտադրանք) DataHub ինտերֆեյսը, մետատվյալների մոդելային գրադարանը, մետատվյալների պահեստի հետին պլանի ծառայությունը և հոսքային աշխատանքները գտնվում են LinkedIn-ի առանձին պահեստներում: Այնուամենայնիվ, բաց կոդով օգտվողների համար հեշտացնելու համար մենք ունենք մեկ պահոց DataHub-ի բաց կոդով տարբերակի համար:

Նկար 1. Սինխրոնիզացիա պահեստների միջև LinkedIn DataHub և մեկ շտեմարան DataHub բաց կոդով

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

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

Մոդուլի մակարդակի քարտեզագրումը պարզ JSON է, որի բանալիները բաց կոդով պահոցում թիրախային մոդուլներն են, իսկ արժեքները՝ LinkedIn-ի պահոցների աղբյուրի մոդուլների ցանկը: Բաց կոդով շտեմարանի ցանկացած թիրախային մոդուլ կարող է սնվել ցանկացած քանակությամբ աղբյուրի մոդուլներով: Աղբյուրի մոդուլներում պահեստների ներքին անվանումները նշելու համար օգտագործեք լարային ինտերպոլացիա Բաշ ոճով։ Օգտագործելով մոդուլի մակարդակի քարտեզագրման ֆայլ՝ գործիքները ստեղծում են ֆայլի մակարդակի քարտեզագրման ֆայլ՝ սկանավորելով բոլոր ֆայլերը կապված գրացուցակներում:

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

Ֆայլի մակարդակի քարտեզագրումը ավտոմատ կերպով ստեղծվում է գործիքների կողմից. սակայն, այն կարող է նաև ձեռքով թարմացվել օգտագործողի կողմից: Սա LinkedIn աղբյուրի ֆայլի 1:1 քարտեզագրումն է բաց կոդով պահոցում գտնվող ֆայլին: Ֆայլերի ասոցիացիաների այս ավտոմատ ստեղծման հետ կապված կան մի քանի կանոններ.

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

Պարտավորությունների տեղեկամատյանների ստեղծում

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

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

Կախվածության փորձարկում

LinkedIn-ն ունի կախվածության փորձարկման ենթակառուցվածք, որն օգնում է ապահովել, որ ներքին բազմարտադրանքի փոփոխությունները չխախտեն կախյալ բազմարտադրանքների հավաքումը: Բաց կոդով DataHub պահոցը բազմաբնույթ արտադրանք չէ, և այն չի կարող ուղղակիորեն կախված լինել որևէ բազմապրոդուկից, սակայն բազմապրոդուկային փաթեթավորման օգնությամբ, որը բեռնում է բաց կոդով DataHub-ի աղբյուրի կոդը, մենք դեռ կարող ենք օգտագործել կախվածության այս փորձարկումը: համակարգ: Այսպիսով, ցանկացած փոփոխություն (որը հետագայում կարող է բացահայտվել) որևէ բազմապրոդուկտի նկատմամբ, որը սնուցում է բաց կոդով DataHub պահոցը, առաջացնում է build-ի իրադարձություն shell multiproduct-ում: Հետևաբար, ցանկացած փոփոխություն, որը չի կարողանում ստեղծել փաթաթող արտադրանք, չի անցնում թեստերը նախքան սկզբնական արտադրանքը հանձնելը և հետ է վերադարձվում:

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

Տարբերությունները բաց կոդով DataHub-ի և մեր արտադրական տարբերակի միջև

Մինչ այս պահը մենք քննարկել ենք DataHub պահեստների երկու տարբերակների համաժամացման մեր լուծումը, բայց մենք դեռ չենք նշել այն պատճառները, թե ինչու են մեզ առաջին հերթին անհրաժեշտ երկու տարբեր զարգացման հոսքեր: Այս բաժնում մենք կթվարկենք DataHub-ի հանրային տարբերակի և LinkedIn սերվերների արտադրական տարբերակի միջև եղած տարբերությունները և կբացատրենք այդ տարբերությունների պատճառները:

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

Կան նաև այլ պատճառներ. Քանի որ մենք ստեղծում ենք մետատվյալների մոդելի ընդլայնումներ LinkedIn-ի կարիքների համար, այդ ընդարձակումները սովորաբար շատ հատուկ են LinkedIn-ին և կարող են ուղղակիորեն չկիրառվել այլ միջավայրերի վրա: Օրինակ, մենք ունենք շատ հատուկ պիտակներ մասնակիցների ID-ների և այլ տեսակի համապատասխանող մետատվյալների համար: Այսպիսով, մենք այժմ բացառել ենք այս ընդլայնումները DataHub-ի բաց կոդով մետատվյալների մոդելից: Երբ մենք համագործակցում ենք համայնքի հետ և հասկանում ենք նրանց կարիքները, մենք կաշխատենք այս ընդարձակման ընդհանուր բաց կոդով տարբերակների վրա, որտեղ անհրաժեշտ է:

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

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

Երկու իրականացումների միջև եղած տարբերությունների ամբողջական ցանկը տրված է ստորև բերված աղյուսակում:

Product Features
LinkedIn DataHub
Բաց կոդով DataHub

Աջակցված տվյալների կառուցվածքներ
1) Տվյալների հավաքածուներ 2) Օգտագործողներ 3) Չափումներ 4) ML-ի առանձնահատկություններ 5) գծապատկերներ 6) վահանակներ
1) Տվյալների հավաքածուներ 2) Օգտագործողներ

Աջակցված մետատվյալների աղբյուրներ Տվյալների հավաքածուների համար
1) Էմբրի 2) Couchbase 3) Դալիդներ 4) Էսպրեսսո 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Pinot 12) Պրեստո 12) Seas 13) Տերադատա 13) Վեկտոր 14) Վենետիկ
Փեթակ Կաֆկա RDBMS

Փաբ-ենթ
LinkedIn Կաֆկա
Միաձուլվող Կաֆկա

Հոսքի մշակում
Կարողացավ
Ներկառուցված (ինքնուրույն)

Կախվածության ներարկում և դինամիկ կոնֆիգուրացիա
LinkedIn Offspring
գարուն

Build Tooling
Ligradle (LinkedIn-ի ներքին Gradle փաթաթան)
Գրադլյու

CI / CD
CRT (LinkedIn-ի ներքին CI/CD)
TravisCI և Docker հանգույց

Մետատվյալների խանութներ
Բաշխված բազմակի GMS. 1) Տվյալների հավաքածու GMS 2) Օգտատիրոջ GMS 3) մետրային GMS 4) Հատկանիշ GMS 5) Գծապատկեր/վահանակ GMS
Մեկ GMS՝ 1) Տվյալների հավաքածուներ 2) Օգտագործողների համար

Microservices Docker բեռնարկղերում

դոկեր պարզեցնում է հավելվածների տեղակայումը և բաշխումը կոնտեյներացում. DataHub-ում ծառայության յուրաքանչյուր մաս բաց կոդով է, ներառյալ ենթակառուցվածքի բաղադրիչները, ինչպիսիք են Kafka-ն, Elasticsearch- ը, neo4j и MySQL, ունի իր սեփական Docker պատկերը։ Docker կոնտեյներները կազմակերպելու համար մենք օգտագործեցինք Դոկտոր կազմեք.

Նկար 2. Ճարտարապետություն DataHub *բաց կոդով**

Վերևի նկարում կարող եք տեսնել DataHub-ի բարձր մակարդակի ճարտարապետությունը: Բացի ենթակառուցվածքի բաղադրիչներից, այն ունի չորս տարբեր Docker կոնտեյներ.

datahub-gms՝ մետատվյալների պահպանման ծառայություն

datahub-frontend՝ հավելված խաղալ, սպասարկելով DataHub ինտերֆեյսը:

datahub-mce-consumer՝ դիմում Կաֆկայի հոսքեր, որն օգտագործում է մետատվյալների փոփոխության իրադարձության (MCE) հոսքը և թարմացնում մետատվյալների պահեստը։

datahub-mae-consumer՝ դիմում Կաֆկայի հոսքեր, որն օգտագործում է մետատվյալների աուդիտի իրադարձությունների հոսքը (MAE) և ստեղծում է որոնման ինդեքս և գրաֆիկական տվյալների բազա։

Բաց կոդով պահեստային փաստաթղթեր և DataHub բլոգի բնօրինակ գրառումը պարունակում է ավելի մանրամասն տեղեկատվություն տարբեր ծառայությունների գործառույթների մասին:

DataHub-ի CI/CD-ն բաց կոդ է

Բաց կոդով DataHub պահոցն օգտագործում է TravisCI շարունակական ինտեգրման համար և Docker հանգույց շարունակական տեղակայման համար: Երկուսն էլ ունեն լավ GitHub ինտեգրում և հեշտ է կարգավորել: Համայնքի կամ մասնավոր ընկերությունների կողմից մշակված բաց կոդով ենթակառուցվածքների մեծ մասի համար (օրինակ. Հանգույց), Docker պատկերները ստեղծվում և տեղադրվում են Docker Hub-ում՝ համայնքի կողմից հեշտ օգտագործման համար: Docker Hub-ում հայտնաբերված ցանկացած Docker պատկեր կարող է հեշտությամբ օգտագործվել պարզ հրամանի միջոցով դոկերի քաշում.

«DataHub» բաց կոդով շտեմարանի յուրաքանչյուր պարտավորություն կատարելիս Docker-ի բոլոր պատկերները ավտոմատ կերպով կառուցվում և տեղադրվում են Docker Hub-ում՝ «վերջին» պիտակով: Եթե ​​Docker Hub-ը կազմաձևված է որոշների հետ կանոնավոր արտահայտությունների ճյուղերի անվանումը, բաց կոդով շտեմարանի բոլոր պիտակները նույնպես թողարկվում են Docker Hub-ում համապատասխան պիտակների անուններով:

Օգտագործելով DataHub

DataHub-ի կարգավորում շատ պարզ է և բաղկացած է երեք պարզ քայլերից.

1. Կլոնավորեք բաց կոդով պահոցը և գործարկեք Docker-ի բոլոր կոնտեյներները docker-compose-ով, օգտագործելով տրամադրված docker-compose սկրիպտը՝ արագ մեկնարկի համար:
2. Ներբեռնեք պահեստում ներկայացված տվյալների նմուշը՝ օգտագործելով հրամանի տող գործիքը, որը նույնպես տրամադրվում է:
3. Զննեք DataHub-ը ձեր բրաուզերում:

Ակտիվորեն հետևվում է Գիտեր զրույց նաև կազմաձևված է արագ հարցերի համար: Օգտագործողները կարող են նաև խնդիրներ ստեղծել անմիջապես GitHub-ի պահոցում: Ամենակարևորը, մենք ողջունում և գնահատում ենք բոլոր արձագանքներն ու առաջարկությունները:

Պլանները ապագայի համար

Ներկայումս բաց կոդով DataHub-ի յուրաքանչյուր ենթակառուցվածք կամ միկրոծառայություն կառուցված է որպես Docker կոնտեյներ, և ամբողջ համակարգը կազմակերպված է օգտագործելով դոկտոր-կոմպոզիցիա. Հաշվի առնելով ժողովրդականությունը և տարածվածությունը Կուբերնետես, մենք նաև կցանկանայինք մոտ ապագայում տրամադրել Kubernetes-ի վրա հիմնված լուծում:

Մենք նաև նախատեսում ենք ապահովել բանտապահ լուծում՝ DataHub-ը հանրային ամպային ծառայության վրա տեղակայելու համար, ինչպիսին է Երկնագույն, AWS կամ Google Cloud- ը. Հաշվի առնելով LinkedIn-ի Azure միգրացիայի մասին վերջին հայտարարությունը, դա կհամապատասխանի մետատվյալների թիմի ներքին առաջնահերթություններին:

Վերջապես, բայց ոչ պակաս կարևոր, շնորհակալություն բաց կոդով համայնքում DataHub-ի բոլոր վաղ ընդունողներին, ովքեր գնահատել են DataHub ալֆաները և օգնել մեզ բացահայտել խնդիրները և բարելավել փաստաթղթերը:

Source: www.habr.com