Ինչպես մենք կազմակերպեցինք բարձր արդյունավետ և էժան DataLake և ինչու է դա այդպես

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

Իզուր չէ, որ ավելի փորձառու գործընկերները, որոնց գլուխները ցրված են վրիպակներով և, հետևաբար, արդեն մոխրագույնով, մտածում են «կոնտեյներների» փաթեթների «խորանարդի» մեջ աներևակայելի արագ տեղակայման մասին «նորաձև լեզուներով» տասնյակ սերվերների վրա՝ ներկառուցված աջակցությամբ: ասինխրոն չարգելափակող I/O, համեստ ժպտացեք: Եվ նրանք լուռ շարունակում են վերընթերցել «man ps», խորանալ «nginx» սկզբնաղբյուրի մեջ, մինչև նրանց աչքերը արյունահոսեն, և գրում, գրում, գրում միավորի թեստեր: Գործընկերները գիտեն, որ ամենահետաքրքիրը կգա, երբ «այս ամենը» մի օր գիշերը ցցվի Ամանորի գիշերը: Եվ նրանց կօգնի միայն unix-ի բնույթի խորը ըմբռնումը, անգիր արված TCP/IP վիճակի աղյուսակը և հիմնական տեսակավորման-որոնման ալգորիթմները: Համակարգը կյանքի կոչելու համար, երբ զանգերը հարվածում են:

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

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

Հիմնական տեխնիկական վերլուծություն Bitrix24-ում

Մի քանի տարի առաջ, Bitrix24 ծառայության գործարկմանը զուգահեռ, մենք ակտիվորեն ժամանակ և ռեսուրսներ ներդրեցինք պարզ և հուսալի վերլուծական հարթակ ստեղծելու համար, որը կօգնի արագ տեսնել ենթակառուցվածքում առկա խնդիրները և պլանավորել հաջորդ քայլը: Իհարկե, նպատակահարմար էր վերցնել պատրաստի գործիքներ, որոնք հնարավորինս պարզ ու հասկանալի էին։ Արդյունքում՝ մոնիտորինգի համար ընտրվել է նագիոսը, իսկ վերլուծության և վիզուալիզացիայի համար՝ մունինը: Այժմ մենք ունենք հազարավոր չեկեր nagios-ում, հարյուրավոր գծապատկերներ munin-ում, և մեր գործընկերներն ամեն օր հաջողությամբ օգտագործում են դրանք: Չափիչները պարզ են, գրաֆիկները պարզ են, համակարգը հուսալիորեն աշխատում է մի քանի տարի, և դրան պարբերաբար ավելացվում են նոր թեստեր և գրաֆիկներ. երբ մենք գործարկում ենք նոր ծառայություն, ավելացնում ենք մի քանի թեստեր և գրաֆիկներ: Հաջողություն.

Finger on the Pulse - Ընդլայնված տեխնիկական վերլուծություն

Խնդիրների մասին «որքան հնարավոր է արագ» տեղեկատվություն ստանալու ցանկությունը մեզ հանգեցրեց ակտիվ փորձերի պարզ և հասկանալի գործիքներով՝ pinba և xhprof:

Pinba-ն մեզ ուղարկեց վիճակագրություն UDP փաթեթներով PHP-ում վեբ էջերի մասերի աշխատանքի արագության մասին, և մենք կարող էինք առցանց տեսնել MySQL պահեստում (Pinba-ն գալիս է իր սեփական MySQL շարժիչով՝ իրադարձությունների արագ վերլուծության համար) խնդիրների կարճ ցուցակ և արձագանքել դրանց: նրանց. Եվ xhprof-ը ավտոմատ կերպով մեզ թույլ տվեց հաճախորդներից հավաքել ամենադանդաղ PHP էջերի կատարման գրաֆիկները և վերլուծել, թե ինչ կարող է հանգեցնել դրան՝ հանգիստ, թեյ լցնել կամ ավելի ուժեղ բան:

Որոշ ժամանակ առաջ գործիքակազմը համալրվեց մեկ այլ բավականին պարզ և հասկանալի շարժիչով, որը հիմնված է հակադարձ ինդեքսավորման ալգորիթմի վրա, որը հիանալի կերպով իրականացվել է լեգենդար Lucene գրադարանում՝ Elastic/Kibana: Փաստաթղթերի բազմաթելային ձայնագրման պարզ գաղափարը հակադարձ Lucene ինդեքսի մեջ՝ հիմնված տեղեկամատյաններում տեղի ունեցող իրադարձությունների վրա և դրանց միջով արագ որոնումը՝ օգտագործելով երեսակային բաժանումը, իսկապես օգտակար էր:

Չնայած Kibana-ում պատկերացումների բավականին տեխնիկական տեսքին՝ ցածր մակարդակի հասկացություններով, ինչպիսիք են «դույլը», «հոսում է դեպի վեր» և դեռևս ամբողջությամբ չմոռացված հարաբերական հանրահաշվի նորացված լեզուն, գործիքը սկսեց մեզ լավ օգնել հետևյալ առաջադրանքներում.

• Քանի՞ PHP սխալ է ունեցել Bitrix24 հաճախորդը p1 պորտալում վերջին մեկ ժամում և որոնք: Հասկացեք, ներեք և արագ ուղղեք:
• Գերմանիայում նախորդ 24 ժամվա ընթացքում քանի՞ տեսազանգ է կատարվել պորտալներով, ի՞նչ որակով և արդյոք դժվարություններ կային ալիքի/ցանցում:
• Որքանո՞վ է լավ աշխատում համակարգի ֆունկցիոնալությունը (մեր C ընդլայնումը PHP-ի համար), որը կազմվել է աղբյուրից ծառայության վերջին թարմացման մեջ և տրամադրվել հաճախորդներին: Կա՞ն սխալներ:
• Արդյո՞ք հաճախորդի տվյալները տեղավորվում են PHP հիշողության մեջ: Արդյո՞ք սխալներ կան գործընթացներին հատկացված հիշողությունը գերազանցելու վերաբերյալ. «հիշողությունից դուրս է»: Գտեք և չեզոքացրեք:

Ահա կոնկրետ օրինակ. Չնայած մանրակրկիտ և բազմամակարդակ փորձարկմանը, հաճախորդը, շատ ոչ ստանդարտ պատյանով և վնասված մուտքային տվյալներով, ստացավ անհանգստացնող և անսպասելի սխալ, հնչեց ազդանշան և սկսվեց այն արագ շտկելու գործընթացը.

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

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

Հիմնական բիզնես վերլուծություն

Բոլորը գիտեն, որ ընկերություններում բիզնեսի վերլուծությունը հաճախ սկսվում է, այո, Excel-ի չափազանց ակտիվ օգտագործմամբ: Բայց գլխավորն այն է, որ դրանով չի ավարտվում. Ամպի վրա հիմնված Google Analytics-ը նույնպես կրակի վրա յուղ է լցնում. դուք արագ սկսում եք ընտելանալ լավ բաներին:

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

Բավականին երկար ժամանակ այս ճկուն լուծումը շատ օգնեց, բայց աստիճանաբար սկսեց հասկանալ, որ ClickHouse-ը ռետինե չէ և չի կարելի այդպես ծաղրել։

Այստեղ կարևոր է լավ հասկանալ, որ ClickHouse-ը, ինչպես Druid-ը, Vertica-ն, ինչպես Amazon RedShift-ը (որը հիմնված է postgres-ի վրա), վերլուծական շարժիչներ են, որոնք օպտիմիզացված են բավականին հարմար վերլուծության համար (գումարներ, ագրեգացիաներ, նվազագույն-առավելագույնը ըստ սյունակների և մի քանի հնարավոր միացումներ): ), որովհետեւ կազմակերպված է հարաբերական աղյուսակների սյունակների արդյունավետ պահպանման համար՝ ի տարբերություն MySQL-ի և մեզ հայտնի այլ տվյալների (տողերի վրա հիմնված):

Ըստ էության, ClickHouse-ը պարզապես ավելի տարողունակ «տվյալների բազա է»՝ ոչ այնքան հարմար կետ առ կետ տեղադրմամբ (այդպես է նախատեսված, ամեն ինչ կարգին է), բայց հաճելի վերլուծություններ և տվյալների հետ աշխատելու հետաքրքիր հզոր գործառույթների մի շարք: Այո, դուք նույնիսկ կարող եք ստեղծել կլաստեր, բայց դուք հասկանում եք, որ մանրադիտակով եղունգները մուրճով խփելն այնքան էլ ճիշտ չէ, և մենք սկսեցինք այլ լուծումներ փնտրել:

Պիթոնի և վերլուծաբանների պահանջարկ

Մեր ընկերությունն ունի բազմաթիվ ծրագրավորողներ, ովքեր 10-20 տարի գրեթե ամեն օր կոդ են գրում PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash լեզուներով։ Կան նաև շատ փորձառու համակարգի ադմինիստրատորներ, ովքեր զգացել են մեկից ավելի բացարձակապես անհավանական աղետներ, որոնք չեն տեղավորվում վիճակագրության օրենքների մեջ (օրինակ, երբ Raid-10-ի սկավառակների մեծ մասը ոչնչացվում է ուժեղ կայծակի հարվածից): Նման պայմաններում երկար ժամանակ պարզ չէր, թե ինչ է «python analyst»-ը։ Python-ը նման է PHP-ին, միայն անունը մի փոքր ավելի երկար է, և թարգմանչի սկզբնաղբյուրում կան միտքը փոխող նյութերի մի փոքր քիչ հետքեր: Այնուամենայնիվ, քանի որ ավելի ու ավելի շատ վերլուծական հաշվետվություններ էին ստեղծվում, փորձառու մշակողները սկսեցին ավելի ու ավելի շատ հասկանալ նեղ մասնագիտացման կարևորությունը այնպիսի գործիքներում, ինչպիսիք են Numpy, pandas, matplotlib, seaborn:
Որոշիչ դերը, ամենայն հավանականությամբ, խաղացել է աշխատակիցների հանկարծակի ուշագնացությունը «լոգիստիկ ռեգրեսիա» բառերի համակցությունից և մեծ տվյալների վրա արդյունավետ հաշվետվության ցուցադրումը, օգտագործելով, այո, այո, pyspark:

Apache Spark-ը, նրա ֆունկցիոնալ պարադիգմը, որի վրա հարաբերական հանրահաշիվը կատարելապես տեղավորվում է, և դրա հնարավորությունները այնպիսի տպավորություն թողեցին MySQL-ին սովոր ծրագրավորողների վրա, որ փորձառու վերլուծաբաններով շարքերն ամրապնդելու անհրաժեշտությունը պարզ դարձավ օրվա պես:

Apache Spark/Hadoop-ի հետագա փորձերը թռչելու և այն, ինչը այնքան էլ ըստ սցենարի չընթացավ

Այնուամենայնիվ, շուտով պարզ դարձավ, որ Spark-ի հետ համակարգային ինչ-որ բան այն չէ, կամ պարզապես անհրաժեշտ է ավելի լավ լվանալ ձեռքերը: Եթե ​​Hadoop/MapReduce/Lucene ստեկը պատրաստվել է բավականին փորձառու ծրագրավորողների կողմից, ինչը ակնհայտ է, եթե ուշադիր նայեք Java-ի սկզբնաղբյուրին կամ Դագ Քաթինգի գաղափարներին Lucene-ում, ապա Spark-ը հանկարծ գրված է Scala էկզոտիկ լեզվով, որը. շատ հակասական է գործնականության տեսանկյունից և ներկայումս չի զարգանում: Եվ Spark կլաստերի վրա հաշվարկների կանոնավոր անկումը անտրամաբանական և ոչ շատ թափանցիկ աշխատանքի պատճառով հիշողության բաշխման հետ կրճատման գործողությունների համար (շատ ստեղներ միանգամից գալիս են) դրա շուրջ ստեղծել է մի բան, որը աճելու տեղ ունի: Բացի այդ, իրավիճակը սրվեց մեծ թվով տարօրինակ բաց նավահանգիստների, ամենաանհասկանալի վայրերում աճող ժամանակավոր ֆայլերի և բանկաների դժոխային կախվածության պատճառով, ինչը ստիպեց համակարգի ադմինիստրատորներին մանկուց հայտնի մի զգացում ունենալ. կատաղի ատելություն (կամ գուցե նրանք պետք է իրենց ձեռքերը օճառով լվանային):

Արդյունքում, մենք «գոյատեւեցինք» մի քանի ներքին վերլուծական նախագծեր, որոնք ակտիվորեն օգտագործում են Apache Spark-ը (ներառյալ Spark Streaming, Spark SQL) և Hadoop էկոհամակարգը (և այլն, և այլն): Չնայած այն հանգամանքին, որ ժամանակի ընթացքում մենք սովորեցինք բավականին լավ պատրաստել և վերահսկել «դա», և «այն» գործնականում դադարեց հանկարծակի խափանվել տվյալների բնույթի փոփոխության և RDD-ի համաչափ հաշման անհավասարակշռության պատճառով, արդեն պատրաստ ինչ-որ բան վերցնելու ցանկությունը: , թարմացված և կառավարվող ինչ-որ տեղ ամպի մեջ ավելի ու ավելի ուժեղացավ: Հենց այս պահին մենք փորձեցինք օգտագործել Amazon Web Services-ի պատրաստի ամպային հավաքը. EMR և, հետագայում, փորձելով լուծել խնդիրները՝ օգտագործելով այն: EMR-ը Apache Spark-ն է, որը պատրաստվել է Amazon-ի կողմից էկոհամակարգի լրացուցիչ ծրագրաշարով, ինչպես Cloudera/Hortonworks-ի կառուցումները:

Վերլուծությունների համար ռետինե ֆայլերի պահպանումը հրատապ անհրաժեշտություն է

Մարմնի տարբեր մասերի այրվածքներով Hadoop/Spark «եփելու» փորձն իզուր չէր։ Ֆայլերի մեկ, էժան և հուսալի պահեստավորման ստեղծման անհրաժեշտությունը, որը դիմացկուն կլինի ապարատային խափանումներին, և որտեղ հնարավոր կլինի տարբեր համակարգերից տարբեր ձևաչափերով ֆայլեր պահել և այս տվյալներից հաշվետվությունների համար արդյունավետ և ժամանակի արդյունավետ նմուշներ պատրաստել: պարզ.

Ես նաև ցանկանում էի, որ այս հարթակի ծրագրաշարի թարմացումը չվերածվեր ամանորյա մղձավանջի՝ կարդալով 20 էջանոց Java հետքեր և վերլուծելով կլաստերի կիլոմետրանոց մանրամասն տեղեկամատյանները՝ օգտագործելով Spark History Server-ը և հետին լուսավորված խոշորացույցը: Ես ուզում էի ունենալ պարզ և թափանցիկ գործիք, որը չպահանջեր կանոնավոր սուզումներ գլխարկի տակ, եթե մշակողի ստանդարտ MapReduce հարցումը դադարեցնի իրագործումը, երբ տվյալների կրճատման աշխատողը դուրս եկավ հիշողությունից՝ աղբյուրի տվյալների բաժանման ոչ այնքան լավ ընտրված ալգորիթմի պատճառով:

Արդյո՞ք Amazon S3-ը թեկնածու է DataLake-ի համար:

Hadoop/MapReduce-ի հետ ունեցած փորձը մեզ սովորեցրել է, որ մեզ անհրաժեշտ է լայնածավալ, հուսալի ֆայլային համակարգ և մասշտաբավոր աշխատողներ, որոնք «մոտենան» տվյալներին, որպեսզի տվյալները չտանեն ցանցի վրայով: Աշխատողները պետք է կարողանան կարդալ տվյալներ տարբեր ձևաչափերով, բայց գերադասելի է՝ չկարդան ավելորդ տեղեկությունները և կարողանան նախապես տվյալները պահել աշխատողների համար հարմար ձևաչափերով:

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

Ի՞նչ կլինի, եթե ֆայլերը պահեք ծանոթ և հայտնի մասշտաբային ամպային պահեստում՝ Amazon S3-ում, առանց Hadoop-ից ձեր սեփական կոտլետներ պատրաստելու:

Հասկանալի է, որ անձնական տվյալները «ցածր են», բայց ինչ վերաբերում է այլ տվյալներին, եթե մենք դրանք դուրս բերենք և «արդյունավետ կերպով վարենք»:

Amazon Web Services-ի կլաստեր-բիգտվյալների-վերլուծական էկոհամակարգը` շատ պարզ բառերով

Դատելով AWS-ի հետ ունեցած մեր փորձից՝ Apache Hadoop/MapReduce-ն այնտեղ երկար ժամանակ ակտիվորեն օգտագործվում է տարբեր սոուսների տակ, օրինակ՝ DataPipeline ծառայության մեջ (ես նախանձում եմ իմ գործընկերներին, նրանք սովորեցին, թե ինչպես ճիշտ պատրաստել): Այստեղ մենք տեղադրում ենք կրկնօրինակներ տարբեր ծառայություններից DynamoDB աղյուսակներից.


Եվ նրանք արդեն մի քանի տարի է, ինչ կանոնավոր կերպով աշխատում են ներկառուցված Hadoop/MapReduce կլաստերների վրա, ինչպիսիք են ժամացույցը: «Կարգավորիր և մոռացիր այն».

Դուք կարող եք նաև արդյունավետորեն ներգրավվել տվյալների սատանիզմի մեջ՝ տեղադրելով Յուպիտերի նոութբուքեր ամպի մեջ վերլուծաբանների համար և օգտագործելով AWS SageMaker ծառայությունը՝ AI մոդելները մարտում վարժեցնելու և տեղակայելու համար: Ահա թե ինչ տեսք ունի այն մեզ համար.

Եվ այո, դուք կարող եք վերցնել նոութբուք ձեզ համար կամ ամպի վերլուծաբանի համար և այն կցել Hadoop/Spark կլաստերին, կատարել հաշվարկները և այնուհետև ամեն ինչ փակել:

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

AWS սոսինձ - կոկիկ փաթեթավորված Apache Spark ստերոիդների վրա

Պարզվեց, որ AWS-ն ունի «Hive/Pig/Spark» ստեկի իր տարբերակը: Փեթակի դերը, այսինքն. DataLake-ում ֆայլերի և դրանց տեսակների կատալոգը կատարվում է «Տվյալների կատալոգ» ծառայության կողմից, որը չի թաքցնում իր համատեղելիությունը Apache Hive ձևաչափի հետ։ Դուք պետք է այս ծառայությանը տեղեկատվություն ավելացնեք այն մասին, թե որտեղ են գտնվում ձեր ֆայլերը և ինչ ձևաչափով են դրանք: Տվյալները կարող են լինել ոչ միայն s3-ում, այլ նաև տվյալների բազայում, բայց դա այս գրառման թեման չէ։ Ահա թե ինչպես է կազմակերպված մեր DataLake տվյալների գրացուցակը.

Ֆայլերը գրանցված են, հիանալի։ Եթե ​​ֆայլերը թարմացվել են, մենք գործարկում ենք սողուններ կամ ձեռքով կամ ժամանակացույցով, որը կթարմացնի դրանց մասին տեղեկատվությունը լճից և կպահի դրանք: Այնուհետև լճից ստացված տվյալները կարելի է մշակել և արդյունքները վերբեռնել ինչ-որ տեղ։ Ամենապարզ դեպքում ներբեռնում ենք նաև s3։ Տվյալների մշակումը կարող է իրականացվել ցանկացած վայրում, սակայն առաջարկվում է, որ դուք կարգավորեք մշակումը Apache Spark կլաստերի վրա՝ օգտագործելով առաջադեմ հնարավորություններ AWS Glue API-ի միջոցով: Փաստորեն, դուք կարող եք վերցնել հին ու ծանոթ python կոդը՝ օգտագործելով pyspark գրադարանը և կարգավորել դրա կատարումը որոշ հզորության կլաստերի N հանգույցների վրա՝ մոնիտորինգով, առանց Hadoop-ի աղիքները փորելու և դոկեր-մոգերի կոնտեյներները քաշելու և կախվածության կոնֆլիկտները վերացնելու: .

Եվս մեկ պարզ միտք. Կարիք չկա կարգավորել Apache Spark-ը, պարզապես պետք է գրել python կոդը pyspark-ի համար, փորձարկել այն տեղական աշխատասեղանին և այնուհետև գործարկել ամպի մեծ կլաստերի վրա՝ նշելով, թե որտեղ են աղբյուրի տվյալները և որտեղ դնել արդյունքը: Երբեմն սա անհրաժեշտ և օգտակար է, և ահա թե ինչպես ենք մենք այն կարգավորել.

Այսպիսով, եթե Ձեզ անհրաժեշտ է ինչ-որ բան հաշվարկել Spark կլաստերի վրա՝ օգտագործելով s3-ի տվյալները, մենք կոդ ենք գրում python/pyspark-ում, փորձարկում ենք այն և հաջողություն ենք մաղթում ամպին:

Ինչ վերաբերում է նվագախմբին: Իսկ եթե առաջադրանքն ընկնի և անհետանա։ Այո, առաջարկվում է գեղեցիկ խողովակաշար պատրաստել Apache Pig ոճով, և մենք նույնիսկ փորձեցինք դրանք, բայց առայժմ որոշեցինք օգտագործել մեր խորապես հարմարեցված նվագախումբը PHP-ում և JavaScript-ում (հասկանում եմ, կա ճանաչողական դիսոնանս, բայց այն աշխատում է, տարիներ և առանց սխալների):

Լճում պահվող ֆայլերի ձևաչափը կատարման բանալին է

Շատ, շատ կարևոր է հասկանալ ևս երկու հիմնական կետ: Որպեսզի լճում առկա ֆայլերի տվյալների վերաբերյալ հարցումները հնարավորինս արագ կատարվեն և նոր տեղեկությունների ավելացման ժամանակ կատարողականությունը չնվազի, դուք պետք է.

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

Ըստ էության, այս կերպ դուք շարադրում եք սկզբնաղբյուրի տվյալները ամենաարդյունավետ ձևով վերևում կախված վերլուծական շարժիչների համար, որոնք նույնիսկ բեկորային թղթապանակներում կարող են ընտրովի մուտքագրել և կարդալ միայն անհրաժեշտ սյունակները ֆայլերից: Ձեզ հարկավոր չէ որևէ տեղ «լրացնել» տվյալները (պահեստը պարզապես կպայթի), պարզապես անմիջապես խելամտորեն տեղադրեք դրանք ֆայլային համակարգում ճիշտ ձևաչափով: Իհարկե, այստեղ պետք է պարզ լինի, որ DataLake-ում հսկայական csv ֆայլ պահելը, որը նախ պետք է տող առ տող կարդալ կլաստերի կողմից՝ սյունակները հանելու համար, այնքան էլ նպատակահարմար չէ։ Կրկին մտածեք վերը նշված երկու կետերի մասին, եթե դեռ պարզ չէ, թե ինչու է այս ամենը տեղի ունենում:

AWS Athena - վանդակում

Եվ հետո, լիճ ստեղծելիս, մի ​​կերպ պատահաբար հանդիպեցինք Amazon Athena-ին։ Հանկարծ պարզվեց, որ ուշադիր դասավորելով մեր հսկայական մատյան ֆայլերը թղթապանակների բեկորների մեջ ճիշտ (մանրահատակի) սյունակի ձևաչափով, դուք կարող եք շատ արագ կատարել դրանցից չափազանց տեղեկատվական ընտրություն և պատրաստել հաշվետվություններ ԱՌԱՆՑ, առանց Apache Spark/Glue կլաստերի:

Athena շարժիչը, որն աշխատում է s3-ի տվյալների վրա, հիմնված է լեգենդարի վրա Presto - MPP (զանգվածային զուգահեռ մշակում) տվյալների մշակման մոտեցումների ընտանիքի ներկայացուցիչ, տվյալներ տանելով այնտեղ, որտեղ դրանք գտնվում են՝ s3-ից և Hadoop-ից մինչև Cassandra և սովորական տեքստային ֆայլեր: Դուք պարզապես պետք է խնդրեք Athena-ին կատարել SQL հարցում, այնուհետև ամեն ինչ «արագ և ինքնաբերաբար կաշխատի»: Կարևոր է նշել, որ Athena-ն «խելացի» է, այն գնում է միայն անհրաժեշտ մասնատված թղթապանակներ և կարդում է միայն հարցումում անհրաժեշտ սյունակները:

Հետաքրքիր է նաև Աթենային ուղղված հարցումների գները: Մենք վճարում ենք սկանավորված տվյալների ծավալը. Նրանք. ոչ թե կլաստերի մեկ րոպեում մեքենաների քանակի համար, այլ... 100-500 մեքենաների վրա իրականում սկանավորված տվյալների համար միայն այն տվյալները, որոնք անհրաժեշտ են հարցումը կատարելու համար:

Եվ ճիշտ բեկորված թղթապանակներից պահանջելով միայն անհրաժեշտ սյունակները, պարզվեց, որ Athena ծառայությունը մեզ ամսական մի քանի տասնյակ դոլար արժե։ Դե, հիանալի, գրեթե անվճար, համեմատած կլաստերների վերլուծության հետ:

Ի դեպ, ահա թե ինչպես ենք մենք կիսում մեր տվյալները s3-ում.

Արդյունքում, կարճ ժամանակում ընկերության բոլորովին այլ բաժիններ՝ տեղեկատվական անվտանգությունից մինչև վերլուծություն, սկսեցին ակտիվորեն հարցումներ կատարել Athena-ին և արագ, վայրկյանների ընթացքում ստանալ օգտակար պատասխաններ «մեծ» տվյալներից բավականին երկար ժամանակահատվածներում. ամիսներ, կես տարի և այլն Պ.

Բայց մենք ավելի հեռուն գնացինք և սկսեցինք ամպի մոտ գնալ պատասխանների ODBC վարորդի միջոցովվերլուծաբանը SQL հարցում է գրում ծանոթ կոնսոլում, որը 100-500 մեքենաների վրա «կոպեկների դիմաց» տվյալներ է ուղարկում s3-ին և պատասխան տալիս սովորաբար մի քանի վայրկյանում: Հարմարավետ. Եվ արագ: Ես դեռ չեմ կարողանում հավատալ դրան:

Արդյունքում, որոշելով տվյալները պահել s3-ում, արդյունավետ սյունակային ձևաչափով և տվյալների խելամիտ փոխանակմամբ թղթապանակներում... մենք ստացանք DataLake և արագ և էժան վերլուծական շարժիչ՝ անվճար: Եվ նա շատ հայտնի դարձավ ընկերությունում, քանի որ... հասկանում է SQL-ն և աշխատում է մեծության կարգեր ավելի արագ, քան կլաստերների մեկնարկի/դադարեցման/ստեղծման միջոցով: «Եվ եթե արդյունքը նույնն է, ինչո՞ւ ավելի շատ վճարել»:

Աթենային ուղղված խնդրանքը մոտավորապես այսպիսի տեսք ունի. Ցանկության դեպքում, իհարկե, կարող եք բավականաչափ ձևավորել բարդ և բազմաէջ SQL հարցում, բայց մենք կսահմանափակվենք պարզ խմբավորմամբ։ Տեսնենք, թե ինչ պատասխանի կոդեր ուներ հաճախորդը մի քանի շաբաթ առաջ վեբ սերվերի մատյաններում և համոզվեք, որ սխալներ չկան.

Արդյունքները

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

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

Ճանապարհորդության սկզբում գլուխս կտրվում էր բաց և փակ ծրագրային ապահովման բազմաթիվ վայրի կենդանաբանական այգիներից և ժառանգների հանդեպ պատասխանատվության բեռի գիտակցումից: Պարզապես սկսեք կառուցել ձեր DataLake-ը պարզ գործիքներից՝ nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., հավաքելով արձագանքներ և խորապես հասկանալով տեղի ունեցող գործընթացների ֆիզիկան: Ամեն ինչ բարդ և պղտոր է՝ տվեք այն թշնամիներին և մրցակիցներին:

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

Source: www.habr.com