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

Սա վերլուծական համակարգերի մասին հոդվածների շարքի երկրորդ մասն է (հղում 1-ին մասի).

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

Հաճախորդների վերլուծաբաններ

Հաճախորդների վերլուծությունը ծառայություն է, որը ընկերությունը միանում է իր կայքին կամ հավելվածին պաշտոնական SDK-ի միջոցով, ինտեգրվում է իր սեփական կոդերի բազային և ընտրում իրադարձությունների գործարկիչները: Այս մոտեցման ակնհայտ թերություն կա. հավաքված բոլոր տվյալները կարող են չմշակվել ճիշտ այնպես, ինչպես կցանկանայիք՝ ձեր ընտրած ցանկացած ծառայության սահմանափակումների պատճառով: Օրինակ, մի համակարգում հեշտ չի լինի գործարկել MapReduce առաջադրանքները, մյուսում դուք չեք կարողանա գործարկել ձեր մոդելը: Մեկ այլ թերություն կլինի ծառայությունների կանոնավոր (տպավորիչ) հաշիվը:
Շուկայում կան հաճախորդների վերլուծության բազմաթիվ լուծումներ, բայց վաղ թե ուշ վերլուծաբանները բախվում են այն փաստի հետ, որ չկա մեկ ունիվերսալ ծառայություն, որը հարմար է յուրաքանչյուր առաջադրանքի համար (մինչ այդ բոլոր ծառայությունների գները անընդհատ բարձրանում են): Նման իրավիճակում ընկերությունները հաճախ որոշում են ստեղծել իրենց սեփական վերլուծական համակարգը՝ բոլոր անհրաժեշտ մաքսային կարգավորումներով և հնարավորություններով:

Սերվերի վերլուծաբաններ

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

Կոալիցիայում
Դեմ

Դուք կարող եք հարմարեցնել այն ամենը, ինչ ցանկանում եք
Սա հաճախ շատ դժվար է և պահանջում է առանձին մշակողներ

Երկրորդ. վերցրեք SaaS ծառայությունները (Amazon, Google, Azure)՝ այն ինքներդ տեղակայելու փոխարեն: SaaS-ի մասին ավելի մանրամասն կխոսենք երրորդ մասում։

Կոալիցիայում
Դեմ

Այն կարող է ավելի էժան լինել միջին ծավալների դեպքում, բայց մեծ աճի դեպքում այն ​​դեռ շատ թանկ կլինի
Հնարավոր չի լինի վերահսկել բոլոր պարամետրերը

Կառավարումն ամբողջությամբ փոխանցվում է ծառայություն մատուցողի ուսերին
Միշտ չէ, որ հայտնի է, թե ինչ կա ծառայության ներսում (կարող է անհրաժեշտ չլինել)

Ինչպես հավաքել սերվերի վերլուծություն

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

1. Տվյալների ստացում

Ինչպես հաճախորդների վերլուծության դեպքում, առաջին հերթին ընկերության վերլուծաբաններն ընտրում են իրադարձությունների այն տեսակները, որոնք նրանք ցանկանում են ուսումնասիրել ապագայում և հավաքում դրանք ցուցակում: Սովորաբար, այս իրադարձությունները տեղի են ունենում որոշակի հերթականությամբ, որը կոչվում է «իրադարձության օրինաչափություն»:
Հաջորդը, պատկերացրեք, որ բջջային հավելվածը (կայքը) ունի կանոնավոր օգտվողներ (սարքեր) և բազմաթիվ սերվերներ: Միջոցառումները սարքերից սերվերներ անվտանգ փոխանցելու համար անհրաժեշտ է միջանկյալ շերտ: Կախված ճարտարապետությունից, կարող են լինել մի քանի տարբեր իրադարձությունների հերթեր:
Apache Kafka - Ից փաբ/ենթահերթ, որն օգտագործվում է որպես իրադարձություններ հավաքելու հերթ։

Ըստ գրառում Quora-ում 2014 թվականին Apache Kafka-ի ստեղծողը որոշեց ծրագրակազմն անվանել Ֆրանց Կաֆկայի անունով, քանի որ «դա գրելու համար օպտիմիզացված համակարգ է» և որովհետև նա սիրում էր Կաֆկայի ստեղծագործությունները: — Wikipedia

Մեր օրինակում կան բազմաթիվ տվյալների արտադրողներ և տվյալների սպառողներ (սարքեր և սերվերներ), և Կաֆկան օգնում է նրանց միացնել միմյանց: Սպառողներն ավելի մանրամասն կներկայացվեն հաջորդ քայլերում, որտեղ նրանք կլինեն հիմնական սուբյեկտները: Այժմ մենք կդիտարկենք միայն տվյալների արտադրողները (իրադարձությունները):
Կաֆկան ամփոփում է հերթ և բաժանման հասկացությունները, ավելի լավ է այս մասին ավելի կոնկրետ կարդալ մեկ այլ տեղ (օրինակ. փաստաթղթավորում). Առանց մանրամասների խորանալու, եկեք պատկերացնենք, որ բջջային հավելվածը գործարկվում է երկու տարբեր ՕՀ-ների համար։ Այնուհետև յուրաքանչյուր տարբերակ ստեղծում է իր առանձին իրադարձությունների հոսքը: Պրոդյուսերները միջոցառումներ են ուղարկում Կաֆկային, դրանք ձայնագրվում են համապատասխան հերթում։

(նկար ուստի)

Միևնույն ժամանակ, Կաֆկան թույլ է տալիս կարդալ կտորներով և մշակել իրադարձությունների հոսքը մինի խմբաքանակներով: Կաֆկան շատ հարմար գործիք է, որը լավ է չափվում աճող կարիքներով (օրինակ՝ իրադարձությունների աշխարհագրական դիրքով):
Սովորաբար մեկ բեկորը բավական է, բայց ամեն ինչ ավելի բարդանում է մասշտաբով (ինչպես միշտ անում են): Հավանաբար, ոչ ոք չի ցանկանա օգտագործել միայն մեկ ֆիզիկական բեկոր արտադրության մեջ, քանի որ ճարտարապետությունը պետք է լինի սխալ հանդուրժող: Բացի Կաֆկայից, կա ևս մեկ հայտնի լուծում՝ RabbitMQ: Մենք այն չենք օգտագործել արտադրության մեջ որպես իրադարձությունների վերլուծության հերթ (եթե նման փորձ ունեք, ասեք մեզ այդ մասին մեկնաբանություններում): Այնուամենայնիվ, մենք օգտագործեցինք AWS Kinesis:

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

2. Իրադարձությունների հոսքերի մշակում

Բոլոր միջոցառումները պատրաստելուց և համապատասխան հերթերում տեղադրելուց հետո անցնում ենք մշակման փուլին։ Այստեղ ես ձեզ կասեմ մշակման երկու ամենատարածված տարբերակների մասին:
Առաջին տարբերակը Apache համակարգում Spark Streaming-ը միացնելն է: Apache-ի բոլոր արտադրանքներն ապրում են HDFS-ով, ֆայլերի կրկնօրինակներով ապահով ֆայլային համակարգով: Spark Streaming-ը հեշտ օգտագործման գործիք է, որը լավ է մշակում հոսքային տվյալները և լավ մասշտաբավորում: Այնուամենայնիվ, այն կարող է դժվար լինել պահպանելը:
Մեկ այլ տարբերակ է ստեղծել ձեր սեփական իրադարձությունների մշակողը: Դա անելու համար անհրաժեշտ է, օրինակ, գրել Python հավելված, կառուցել այն Docker-ում և բաժանորդագրվել Kafka հերթին։ Երբ գործարկիչները հասնեն դոկեր կառավարիչներին, մշակումը կսկսվի: Այս մեթոդով դուք պետք է մշտապես աշխատեք հավելվածները:
Ենթադրենք, որ ընտրել ենք վերը նկարագրված տարբերակներից մեկը և անցնենք բուն մշակմանը։ Պրոցեսորները պետք է սկսեն ստուգելով տվյալների վավերականությունը, զտելով աղբը և «կոտրված» իրադարձությունները: Վավերացման համար մենք սովորաբար օգտագործում ենք Cerberus. Դրանից հետո դուք կարող եք կատարել տվյալների քարտեզագրում. տարբեր աղբյուրներից ստացված տվյալները նորմալացվում և ստանդարտացվում են ընդհանուր աղյուսակում ավելացնելու համար:

3. Տվյալների բազա

Երրորդ քայլը նորմալացված իրադարձությունների պահպանումն է: Պատրաստի վերլուծական համակարգի հետ աշխատելիս մենք ստիպված կլինենք հաճախ մուտք գործել դրանց, ուստի կարևոր է ընտրել հարմար տվյալների բազա:
Եթե ​​տվյալները լավ տեղավորվում են ֆիքսված սխեմայի մեջ, կարող եք ընտրել clickhouse կամ որևէ այլ սյունակային տվյալների բազա: Այս կերպ ագրեգացիաները շատ արագ կաշխատեն։ Բացասական կողմն այն է, որ սխեման խիստ ամրագրված է, և, հետևաբար, հնարավոր չի լինի կամայական օբյեկտներ ավելացնել առանց փոփոխության (օրինակ, երբ տեղի է ունենում ոչ ստանդարտ իրադարձություն): Բայց դուք կարող եք իսկապես շատ արագ հաշվել:
Չկառուցված տվյալների համար կարող եք վերցնել NoSQL, օրինակ. Apache Cassandra. Այն աշխատում է HDFS-ով, լավ է կրկնօրինակվում, կարող եք բազմաթիվ օրինակներ բարձրացնել և հանդուրժող է սխալների նկատմամբ:
Կարող եք նաև ավելի պարզ բան բարձրացնել, օրինակ. MongoDB- ը. Այն բավականին դանդաղ է և փոքր ծավալների համար։ Բայց գումարածն այն է, որ այն շատ պարզ է և, հետևաբար, հարմար է սկսելու համար:

4. Ագրեգացիաներ

Զգուշորեն պահպանելով բոլոր իրադարձությունները՝ մենք ցանկանում ենք հավաքել բոլոր կարևոր տեղեկությունները ժամանած խմբաքանակից և թարմացնել տվյալների բազան: Համաշխարհային մասշտաբով մենք ցանկանում ենք ստանալ համապատասխան վահանակներ և չափումներ: Օրինակ, հավաքեք օգտվողի պրոֆիլը իրադարձություններից և ինչ-որ կերպ չափեք վարքագիծը: Իրադարձությունները հավաքվում են, հավաքվում և նորից պահվում (օգտագործողների աղյուսակներում): Միևնույն ժամանակ, դուք կարող եք կառուցել այնպիսի համակարգ, որպեսզի կարողանաք նաև զտիչ միացնել ագրեգատոր-համակարգողին. հավաքել օգտվողներին միայն որոշակի տեսակի իրադարձություններից:
Դրանից հետո, եթե թիմից որևէ մեկին միայն բարձր մակարդակի վերլուծություն է անհրաժեշտ, ապա կարող են միանալ արտաքին վերլուծական համակարգերը: Դուք կարող եք կրկին վերցնել Mixpanel-ը: բայց քանի որ դա բավականին թանկ է, ոչ բոլոր օգտվողների իրադարձություններն են ուղարկվում այնտեղ, այլ միայն այն, ինչ անհրաժեշտ է: Դա անելու համար մենք պետք է ստեղծենք համակարգող, ով կտեղափոխի որոշ հումքային իրադարձություններ կամ ինչ-որ բան, որը մենք ինքներս ավելի վաղ համախմբել ենք արտաքին համակարգերի, API-ների կամ գովազդային հարթակների վրա:

5. Frontend

Դուք պետք է միացնեք ճակատը ստեղծված համակարգին: Լավ օրինակ է սպասարկումը կարմրել, տվյալների բազայի GUI է, որն օգնում է ստեղծել վահանակներ: Ինչպես է աշխատում փոխազդեցությունը.

1. Օգտագործողը կատարում է SQL հարցում:
2. Ի պատասխան նա նշան է ստանում.
3. Այն ստեղծում է «նոր վիզուալիզացիա» դրա համար և ստանում է գեղեցիկ գրաֆիկ, որը կարող եք պահպանել ինքներդ ձեզ համար:

Ծառայության պատկերացումներն ավտոմատ թարմացվում են, դուք կարող եք հարմարեցնել և հետևել ձեր մոնիտորինգին: Redash-ը անվճար է, եթե ինքնուրույն հյուրընկալվի, բայց որպես SaaS այն կարժենա ամսական 50 դոլար:

Ամփոփում

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

Շնորհակալություն կարդալու համար: Ուրախ կլինեմ հարցեր տալ մեկնաբանություններում։

Source: www.habr.com