Բաշխված հաշվարկների և մեծ տվյալների շուկան, ըստ , աճում է տարեկան 18-19%-ով։ Սա նշանակում է, որ այդ նպատակների համար ծրագրային ապահովման ընտրության հարցը մնում է արդիական: Այս գրառման մեջ մենք կսկսենք նրանից, թե ինչու է մեզ անհրաժեշտ բաշխված հաշվարկը, մենք ավելի մանրամասն կանդրադառնանք ծրագրաշարի ընտրությանը, կխոսենք Hadoop-ի օգտագործման մասին Cloudera-ի հետ, և վերջապես մենք կխոսենք սարքաշարի ընտրության և այն մասին, թե ինչպես է դա ազդում աշխատանքի վրա: տարբեր ձևերով:
Ինչու՞ է ձեզ անհրաժեշտ բաշխված հաշվարկը սովորական բիզնեսում: Ամեն ինչ պարզ է և միևնույն ժամանակ բարդ։ Պարզ - քանի որ շատ դեպքերում մենք համեմատաբար պարզ հաշվարկներ ենք կատարում տեղեկատվության միավորի համար: Դժվար, քանի որ նման տեղեկատվությունը շատ է: Այնքան շատ. Որպես հետևանք, այն պետք է . Այսպիսով, օգտագործման դեպքերը բավականին ունիվերսալ են. հաշվարկները կարող են կիրառվել ամենուր, որտեղ պահանջվում է հաշվի առնել մեծ թվով չափումներ նույնիսկ ավելի մեծ տվյալների զանգվածի վրա:
Մեկ վերջին օրինակ՝ Dodo Pizza Հաճախորդների պատվերների բազայի վերլուծության հիման վրա, որ կամայական լցոններով պիցցա ընտրելիս օգտվողները սովորաբար աշխատում են միայն վեց հիմնական բաղադրիչներով, գումարած մի քանի պատահական: Ըստ այդմ՝ պիցցերիան ճշգրտել է գնումները։ Բացի այդ, այն կարողացավ ավելի լավ առաջարկել օգտատերերին պատվերի փուլում առաջարկվող լրացուցիչ ապրանքներ, ինչը մեծացրեց շահույթը:
Մեկ այլ օրինակ ` ապրանքները թույլ են տվել H&M-ին առանձին խանութներում տեսականին նվազեցնել 40%-ով՝ պահպանելով վաճառքի մակարդակը։ Դրան հաջողվել է բացառել վատ վաճառքի դիրքերը, և հաշվարկներում հաշվի է առնվել սեզոնայնությունը։
Գործիքների ընտրություն
Այս տեսակի հաշվարկների արդյունաբերության ստանդարտը Hadoop-ն է: Ինչո՞ւ։ Քանի որ Hadoop-ը հիանալի, լավ փաստագրված շրջանակ է (նույն Habr-ը տալիս է շատ մանրամասն հոդվածներ այս թեմայի վերաբերյալ), որն ուղեկցվում է կոմունալ ծառայությունների և գրադարանների մի ամբողջ շարքով: Որպես մուտքագրում կարող եք ներկայացնել ինչպես կառուցվածքային, այնպես էլ չկառուցված տվյալների հսկայական հավաքածուներ, և համակարգն ինքը կբաշխի դրանք հաշվողական հզորության միջև: Ավելին, այս նույն հզորությունները կարող են ցանկացած պահի ավելացվել կամ անջատվել՝ նույն հորիզոնական մասշտաբայնությունը գործողության մեջ:
Gartner ազդեցիկ խորհրդատվական ընկերությունը 2017թ որ Hadoop-ը շուտով կհնանա։ Պատճառը միանգամայն բանական է. վերլուծաբանները կարծում են, որ ընկերությունները զանգվածաբար կտեղափոխվեն ամպ, քանի որ այնտեղ նրանք կկարողանան վճարել՝ ելնելով հաշվողական հզորությունից։ Երկրորդ կարևոր գործոնը, որն իբր կարող է «թաղել» Հադոպին, աշխատանքի արագությունն է։ Քանի որ տարբերակները, ինչպիսիք են Apache Spark-ը կամ Google Cloud DataFlow-ն, ավելի արագ են, քան MapReduce-ի հիմքում ընկած Hadoop-ը:
Hadoop-ը հիմնված է մի քանի սյուների վրա, որոնցից առավել նշանավոր են MapReduce տեխնոլոգիաները (սերվերների միջև հաշվարկների համար տվյալների բաշխման համակարգ) և HDFS ֆայլային համակարգը։ Վերջինս հատուկ նախագծված է կլաստերային հանգույցների միջև բաշխված տեղեկատվությունը պահելու համար. ֆիքսված չափի յուրաքանչյուր բլոկ կարող է տեղադրվել մի քանի հանգույցների վրա, և կրկնօրինակման շնորհիվ համակարգը դիմացկուն է առանձին հանգույցների խափանումներին: Ֆայլերի աղյուսակի փոխարեն օգտագործվում է հատուկ սերվեր, որը կոչվում է NameNode:
Ստորև բերված նկարը ցույց է տալիս, թե ինչպես է աշխատում MapReduce-ը: Առաջին փուլում տվյալները բաժանվում են ըստ որոշակի հատկանիշի, երկրորդ փուլում դրանք բաշխվում են հաշվողական հզորությամբ, երրորդ փուլում կատարվում է հաշվարկը։
MapReduce-ն ի սկզբանե ստեղծվել է Google-ի կողմից իր որոնման կարիքների համար: Հետո MapReduce-ն անցավ անվճար կոդ, և Apache-ն ստանձնեց նախագիծը: Դե, Google-ը աստիճանաբար տեղափոխվեց այլ լուծումներ: Հետաքրքիր նրբերանգ. այս պահին Google-ն ունի Google Cloud Dataflow կոչվող նախագիծը, որը դիրքավորվում է որպես Hadoop-ից հետո հաջորդ քայլ՝ որպես դրա արագ փոխարինում։
Ավելի ուշադիր նայելը ցույց է տալիս, որ Google Cloud Dataflow-ը հիմնված է Apache Beam-ի տարբերակի վրա, մինչդեռ Apache Beam-ը ներառում է լավ փաստաթղթավորված Apache Spark շրջանակը, որը թույլ է տալիս մեզ խոսել լուծումների կատարման գրեթե նույն արագության մասին: Դե, Apache Spark-ը լավ է աշխատում HDFS ֆայլային համակարգի վրա, որը թույլ է տալիս այն տեղակայել Hadoop սերվերների վրա:
Ավելացրե՛ք այստեղ փաստաթղթերի ծավալը և պատրաստի լուծումները Hadoop-ի և Spark-ի համար Google Cloud Dataflow-ի դեմ, և գործիքի ընտրությունն ակնհայտ է դառնում։ Ավելին, ինժեներները կարող են ինքնուրույն որոշել, թե որ կոդը՝ Hadoop-ի կամ Spark-ի ներքո, նրանք կկատարեն՝ կենտրոնանալով առաջադրանքի, փորձի և որակավորման վրա:
Ամպային կամ տեղական սերվեր
Ամպային ընդհանուր անցման միտումը նույնիսկ այնպիսի հետաքրքիր տերմին է առաջացրել, ինչպիսին է Hadoop-as-a-service: Նման սցենարի դեպքում միացված սերվերների կառավարումը շատ կարևոր է դարձել։ Քանի որ, ավաղ, չնայած իր ժողովրդականությանը, մաքուր Hadoop-ը բավականին բարդ գործիք է կարգավորելու համար, քանի որ դուք պետք է շատ բան անեք ձեռքով: Օրինակ, դուք կարող եք առանձին կարգավորել սերվերները, վերահսկել դրանց կատարումը և ճշգրտել բազմաթիվ պարամետրեր: Ընդհանրապես, աշխատիր սիրողականի համար, և մեծ հնարավորություն կա ինչ-որ տեղ խայտառակելու կամ ինչ-որ բան բաց թողնելու:
Հետևաբար, շատ տարածված են դարձել տարբեր բաշխումներ, որոնք ի սկզբանե հագեցած են տեղակայման և կառավարման հարմար գործիքներով: Ամենահայտնի բաշխումներից մեկը, որն աջակցում է Spark-ին և հեշտացնում է իրերը, Cloudera-ն է: Այն ունի և՛ վճարովի, և՛ անվճար տարբերակներ, իսկ վերջինում առկա են բոլոր հիմնական գործառույթները և առանց հանգույցների քանակի սահմանափակման:
Կարգավորման ընթացքում Cloudera Manager-ը SSH-ի միջոցով կմիանա ձեր սերվերներին: Հետաքրքիր կետ՝ տեղադրման ժամանակ ավելի լավ է նշել, որ այն իրականացվի այսպես կոչված ծանրոցներՀատուկ փաթեթներ, որոնցից յուրաքանչյուրը պարունակում է բոլոր անհրաժեշտ բաղադրիչները, որոնք կազմաձևված են միմյանց հետ աշխատելու համար: Փաստորեն, սա փաթեթների կառավարչի նման բարելավված տարբերակ է:
Տեղադրվելուց հետո մենք ստանում ենք կլաստերի կառավարման վահանակ, որտեղ դուք կարող եք տեսնել կլաստերների հեռաչափությունը, տեղադրված ծառայությունները, ինչպես նաև կարող եք ավելացնել/հեռացնել ռեսուրսները և խմբագրել կլաստերի կազմաձևումը:
Արդյունքում ձեր առջեւ հայտնվում է այդ հրթիռի կտրումը, որը ձեզ կտանի դեպի BigData-ի պայծառ ապագա։ Բայց նախքան «գնանք» ասելը, եկեք արագ առաջ շարժվենք գլխարկի տակ:
ապարատային պահանջներ
Իրենց կայքում Cloudera-ն նշում է տարբեր հնարավոր կոնֆիգուրացիաներ: Ընդհանուր սկզբունքները, որոնցով դրանք կառուցված են, ներկայացված են նկարազարդում.
MapReduce-ը կարող է լղոզել այս լավատեսական պատկերը: Կրկին նայելով նախորդ բաժնի գծապատկերին, պարզ է դառնում, որ գրեթե բոլոր դեպքերում MapReduce-ի աշխատանքը կարող է խցանվել սկավառակից կամ ցանցից տվյալներ կարդալիս: Այս մասին նշվում է նաև Cloudera բլոգում։ Արդյունքում, ցանկացած արագ հաշվարկի համար, ներառյալ Spark-ի միջոցով, որը հաճախ օգտագործվում է իրական ժամանակում հաշվարկների համար, I/O արագությունը շատ կարևոր է։ Հետևաբար, Hadoop-ն օգտագործելիս շատ կարևոր է, որ հավասարակշռված և արագ մեքենաները մտնեն կլաստեր, որը, մեղմ ասած, միշտ չէ, որ ապահովված է ամպային ենթակառուցվածքում։
Բեռի բաշխման հավասարակշռությունը ձեռք է բերվում Openstack վիրտուալացման միջոցով հզոր բազմամիջուկ պրոցեսորներով սերվերների վրա: Տվյալների հանգույցներին հատկացվում են իրենց սեփական պրոցեսորային ռեսուրսները և որոշակի սկավառակներ: Մեր լուծման մեջ Atos Codex Data Lake Engine ձեռք է բերվել լայն վիրտուալացում, ինչի պատճառով մենք հաղթում ենք և՛ կատարողականի (ցանցային ենթակառուցվածքի ազդեցությունը նվազագույնի հասցված է), և՛ TCO (լրացուցիչ ֆիզիկական սերվերները վերացված են):
BullSequana S200 սերվերների օգտագործման դեպքում մենք ստանում ենք շատ միատեսակ ծանրաբեռնվածություն՝ զուրկ որոշ խցաններից։ Նվազագույն կոնֆիգուրացիան ներառում է 3 BullSequana S200 սերվեր, որոնցից յուրաքանչյուրը ունի երկու JBOD, գումարած լրացուցիչ S200-ները, որոնք պարունակում են տվյալների չորս հանգույց, ընտրովի միացված են: Ահա TeraGen թեստի բեռնման օրինակ.
Տվյալների տարբեր ծավալներով և կրկնօրինակման արժեքներով թեստերը ցույց են տալիս նույն արդյունքները կլաստերի հանգույցների վրա բեռի բաշխման առումով: Ստորև ներկայացված է սկավառակի հասանելիության բաշխման գրաֆիկը ըստ կատարողականի թեստերի:
Հաշվարկները հիմնված են 3 BullSequana S200 սերվերների նվազագույն կազմաձևման վրա: Այն ներառում է 9 տվյալների հանգույց և 3 հիմնական հանգույց, ինչպես նաև պահպանված վիրտուալ մեքենաներ OpenStack վիրտուալացման հիման վրա պաշտպանության տեղակայման դեպքում: TeraSort-ի թեստի արդյունքը. 512 ՄԲ բլոկի չափը կրկնօրինակման գործակիցը երեքն է՝ գաղտնագրմամբ 23,1 րոպե:
Ինչպե՞ս կարելի է ընդլայնել համակարգը: Data Lake Engine-ի համար հասանելի են ընդլայնումների տարբեր տեսակներ.
- Տվյալների հանգույցներ՝ յուրաքանչյուր 40 ՏԲ օգտագործելի տարածքի համար
- Անալիտիկ հանգույցներ՝ GPU տեղադրելու ունակությամբ
- Այլ տարբերակներ՝ կախված բիզնեսի կարիքներից (օրինակ, եթե Ձեզ անհրաժեշտ է Կաֆկա և այլն)
Atos Codex Data Lake Engine համալիրը ներառում է ինչպես սերվերները, այնպես էլ նախապես տեղադրված ծրագրակազմը, ներառյալ Cloudera փաթեթը լիցենզիայով; Ինքը՝ Hadoop-ը, OpenStack-ը վիրտուալ մեքենաներով, որոնք հիմնված են RedHat Enterprise Linux միջուկի, տվյալների կրկնօրինակման և կրկնօրինակման համակարգերի հետ (ներառյալ՝ օգտագործելով պահեստային հանգույց և Cloudera BDR - Backup and Disaster Recovery): Atos Codex Data Lake Engine-ը առաջին վիրտուալացման լուծումն է, որը հավաստագրված է .
Եթե ձեզ հետաքրքրում է մանրամասները, սիրով կպատասխանենք մեր հարցերին մեկնաբանություններում։
Source: www.habr.com