Մեզ պետք է տվյալների լիճ: Ի՞նչ անել տվյալների պահեստի հետ:

Այս հոդվածը թարգմանությունն է իմ հոդվածի միջին մասին - Ինչպես սկսել Data Lake-ի հետ, որը բավականին տարածված է ստացվել, հավանաբար իր պարզության պատճառով։ Ուստի որոշեցի ռուսերեն գրել և մի փոքր ավելացնել, որպեսզի սովորական մարդուն, ով տվյալների մասնագետ չէ, հասկանալի լինի, թե ինչ է տվյալների պահեստը (DW), և ինչ է տվյալների լիճը (Տվյալների լիճ) և ինչպես են դրանք: յոլա գնալ միասին.

Ինչո՞ւ էի ուզում գրել տվյալների լճի մասին։ Ես աշխատում եմ տվյալների և վերլուծությունների հետ ավելի քան 10 տարի, և այժմ ես հաստատ աշխատում եմ մեծ տվյալների հետ Amazon Alexa AI-ում Քեմբրիջում, որը գտնվում է Բոստոնում, չնայած ես ապրում եմ Վիկտորիայում Վանկուվեր կղզում և հաճախ այցելում եմ Բոստոն, Սիեթլ: և Վանկուվերում, և երբեմն նույնիսկ Մոսկվայում, ես ելույթ եմ ունենում կոնֆերանսների ժամանակ: Ես էլ եմ ժամանակ առ ժամանակ գրում, բայց հիմնականում անգլերեն եմ գրում, ու արդեն գրել եմ որոշ գրքերԵս նաև կարիք ունեմ կիսելու Հյուսիսային Ամերիկայի վերլուծական միտումները, և երբեմն գրում եմ հեռագիր.

Ես միշտ աշխատել եմ տվյալների պահեստների հետ, և 2015 թվականից սկսել եմ սերտորեն համագործակցել Amazon Web Services-ի հետ և, ընդհանուր առմամբ, անցել եմ ամպային վերլուծության (AWS, Azure, GCP): Ես դիտարկել եմ վերլուծական լուծումների էվոլյուցիան 2007 թվականից և նույնիսկ աշխատել եմ Teradata տվյալների պահեստի վաճառողի համար և այն իրականացրել Սբերբանկում, և հենց այդ ժամանակ հայտնվեց Big Data with Hadoop-ը: Բոլորը սկսեցին ասել, որ պահեստավորման դարաշրջանն անցել է, և հիմա ամեն ինչ Hadoop-ի վրա է, և հետո նորից սկսեցին խոսել Data Lake-ի մասին, որ հիմա տվյալների պահեստի վերջը հաստատ եկել է։ Բայց բարեբախտաբար (գուցե, ցավոք, ոմանց համար, ովքեր մեծ գումարներ են վաստակել Hadoop-ի ստեղծման վրա), տվյալների պահեստը չվերացավ:

Այս հոդվածում մենք կանդրադառնանք, թե ինչ է տվյալների լիճը: Այս հոդվածը նախատեսված է այն մարդկանց համար, ովքեր տվյալների պահեստների հետ քիչ կամ չունեն փորձ:

Նկարում Բլեդ լիճն է, սա իմ ամենասիրած լճերից մեկն է, չնայած ես եղել եմ այնտեղ միայն մեկ անգամ, այն հիշում էի ամբողջ կյանքում։ Բայց մենք կխոսենք մեկ այլ տեսակի լճի մասին՝ տվյալների լճի: Թերևս ձեզնից շատերն արդեն մեկ անգամ չէ, որ լսել են այս տերմինի մասին, բայց ևս մեկ սահմանում ոչ մեկին չի վնասի։

Առաջին հերթին, ահա տվյալների լճի ամենատարածված սահմանումները.

«Բոլոր տեսակի չմշակված տվյալների ֆայլերի պահեստավորում, որը հասանելի է կազմակերպությունում որևէ մեկի վերլուծության համար» - Մարտին Ֆաուլեր:

«Եթե կարծում եք, որ տվյալների մարթը ջրի շիշ է՝ մաքրված, փաթեթավորված և փաթեթավորված՝ հարմար սպառման համար, ապա տվյալների լիճն իր բնական տեսքով ջրի հսկայական ջրամբար է: Օգտատերեր, ես կարող եմ ինձ համար ջուր հավաքել, խորը սուզվել, ուսումնասիրել» - Ջեյմս Դիքսոն:

Այժմ մենք հաստատ գիտենք, որ տվյալների լիճը վերաբերում է վերլուծությանը, այն թույլ է տալիս մեզ պահել մեծ քանակությամբ տվյալներ իր սկզբնական տեսքով, և մենք ունենք անհրաժեշտ և հարմար մուտք դեպի տվյալներ:

Ես հաճախ սիրում եմ պարզեցնել իրերը, եթե ես կարողանում եմ պարզ բառերով բացատրել բարդ տերմինը, ապա ինքս եմ հասկանում, թե ինչպես է այն աշխատում և ինչի համար է դա անհրաժեշտ։ Մի օր ես շրջում էի iPhone-ի լուսանկարների ցուցասրահում, և ինձ մոտ բացվեց, սա իսկական տվյալների լիճ է, ես նույնիսկ սլայդ արեցի կոնֆերանսների համար.

Ամեն ինչ շատ պարզ է. Մենք լուսանկարում ենք հեռախոսով, լուսանկարը պահվում է հեռախոսում և կարող է պահպանվել iCloud-ում (ամպային ֆայլերի պահեստավորում): Հեռախոսը հավաքում է նաև լուսանկարների մետատվյալներ՝ ինչ է ցուցադրվում, աշխարհագրական պիտակ, ժամանակ: Արդյունքում մենք կարող ենք օգտագործել iPhone-ի հարմար ինտերֆեյսը մեր լուսանկարը գտնելու համար և նույնիսկ ցուցիչներ ենք տեսնում, օրինակ՝ կրակ բառով լուսանկարներ փնտրելիս գտնում եմ կրակի պատկերով 3 լուսանկար։ Ինձ համար սա նման է Business Intelligence գործիքի, որն աշխատում է շատ արագ և ճշգրիտ:

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

Նույնիսկ նման պարզ պատկերն օգնում է մեզ պատկերացնել, թե ինչ է տվյալների լիճը, դրա տարբերությունները ավանդական տվյալների պահեստից և դրա հիմնական տարրերը.

1. Տվյալների բեռնում (կլանումը) տվյալների լճի հիմնական բաղադրիչն է: Տվյալները կարող են մուտք գործել տվյալների պահեստ երկու եղանակով՝ խմբաքանակ (բեռնում ընդմիջումներով) և հոսքային (տվյալների հոսք):
2. Ֆայլերի պահպանում (Պահեստավորում) Տվյալների լճի հիմնական բաղադրիչն է: Մեզ անհրաժեշտ էր, որ պահեստը լինի հեշտ մասշտաբային, չափազանց հուսալի և ցածր գնով: Օրինակ, AWS-ում դա S3 է:
3. Կատալոգ և որոնում (Կատալոգ և որոնում) - որպեսզի մենք խուսափենք Data Swamp-ից (սա այն դեպքում, երբ մենք բոլոր տվյալները լցնում ենք մեկ կույտի մեջ, և հետո անհնար է աշխատել դրա հետ), մենք պետք է ստեղծենք մետատվյալների շերտ՝ տվյալները դասակարգելու համար։ որպեսզի օգտվողները կարողանան հեշտությամբ գտնել այն տվյալները, որոնք անհրաժեշտ են վերլուծության համար: Բացի այդ, դուք կարող եք օգտագործել լրացուցիչ որոնման լուծումներ, ինչպիսիք են ElasticSearch-ը: Որոնումն օգնում է օգտվողին գտնել անհրաժեշտ տվյալները օգտատիրոջ համար հարմար ինտերֆեյսի միջոցով:
4. Մշակման (Գործընթաց) - այս քայլը պատասխանատու է տվյալների մշակման և փոխակերպման համար: Մենք կարող ենք փոխակերպել տվյալները, փոխել դրանց կառուցվածքը, մաքրել դրանք և շատ ավելին:
5. Безопасность (Անվտանգություն) - Կարևոր է ժամանակ հատկացնել լուծման անվտանգության նախագծմանը: Օրինակ՝ տվյալների կոդավորումը պահպանման, մշակման և բեռնման ժամանակ: Կարևոր է օգտագործել նույնականացման և թույլտվության մեթոդները: Ի վերջո, անհրաժեշտ է աուդիտի գործիք:

Գործնական տեսանկյունից մենք կարող ենք բնութագրել տվյալների լիճը երեք հատկանիշներով.

1. Հավաքեք և պահեք որևէ բան — Տվյալների լիճը պարունակում է բոլոր տվյալները՝ և՛ հում, չմշակված տվյալներ ցանկացած ժամանակաշրջանի համար, և՛ մշակված/մաքրված տվյալներ։
2. Խորը սկանավորում — տվյալների լիճը թույլ է տալիս օգտվողներին ուսումնասիրել և վերլուծել տվյալները:
3. Ճկուն մուտք — Տվյալների լիճն ապահովում է ճկուն հասանելիություն տարբեր տվյալների և տարբեր սցենարների համար:

Այժմ մենք կարող ենք խոսել տվյալների պահեստի և տվյալների լճի տարբերության մասին: Սովորաբար մարդիկ հարցնում են.

• Ինչ վերաբերում է տվյալների պահեստին:
• Տվյալների պահեստը փոխարինում ենք տվյալների լճո՞վ, թե՞ ընդլայնում ենք այն։
• Դեռ հնարավո՞ր է անել առանց տվյալների լճի:

Մի խոսքով, հստակ պատասխան չկա։ Ամեն ինչ կախված է կոնկրետ իրավիճակից, թիմի հմտություններից ու բյուջեից: Օրինակ՝ տվյալների պահեստի տեղափոխումը Oracle դեպի AWS և տվյալների լճի ստեղծում Amazon դուստր ընկերության կողմից՝ Woot. Մեր տվյալների լճի պատմությունը. Ինչպես Woot.com-ը կառուցեց առանց սերվերի տվյալների լիճ AWS-ում.

Մյուս կողմից, վաճառող Snowflake-ն ասում է, որ այլևս կարիք չկա մտածել տվյալների լճի մասին, քանի որ նրանց տվյալների հարթակը (մինչև 2020 թվականը դա տվյալների պահեստ էր) թույլ է տալիս համատեղել և՛ տվյալների լիճը, և՛ տվյալների պահեստը: Ես շատ չեմ աշխատել Snowflake-ի հետ, և դա իսկապես եզակի արտադրանք է, որը կարող է դա անել: Այլ հարց է թողարկման գինը։

Եզրափակելով, իմ անձնական կարծիքն այն է, որ մեզ դեռևս անհրաժեշտ է տվյալների պահեստ՝ որպես տվյալների հիմնական աղբյուր մեր հաշվետվությունների համար, և այն, ինչ չի համապատասխանում, մենք պահում ենք տվյալների լճում: Վերլուծության ամբողջ դերը բիզնեսի համար որոշումներ կայացնելու հեշտ հասանելիություն ապահովելն է: Ինչ էլ որ ասի, բիզնես օգտագործողները ավելի արդյունավետ են աշխատում տվյալների պահեստի հետ, քան տվյալների լճը, օրինակ՝ Amazon-ում. կա Redshift (վերլուծական տվյալների պահեստ) և կա Redshift Spectrum/Athena (SQL ինտերֆեյս S3-ում տվյալների լճի համար՝ հիմնված Փեթակ / Presto): Նույնը վերաբերում է ժամանակակից վերլուծական տվյալների պահեստներին:

Եկեք նայենք տվյալների պահեստի տիպիկ ճարտարապետությանը.

Սա դասական լուծում է։ Մենք ունենք սկզբնաղբյուրային համակարգեր, օգտագործելով ETL/ELT, մենք պատճենում ենք տվյալները վերլուծական տվյալների պահեստում և միացնում այն ​​Business Intelligence-ի լուծմանը (իմ սիրելին Tableau-ն է, իսկ քո՞նը):

Այս լուծումը ունի հետևյալ թերությունները.

• ETL/ELT գործողությունները պահանջում են ժամանակ և ռեսուրսներ:
• Որպես կանոն, վերլուծական տվյալների պահեստում տվյալների պահպանման հիշողությունը էժան չէ (օրինակ, Redshift, BigQuery, Teradata), քանի որ մենք պետք է գնենք մի ամբողջ կլաստեր:
• Բիզնես օգտատերերը մուտք ունեն մաքրված և հաճախ ագրեգացված տվյալներ և չունեն հում տվյալների հասանելիություն:

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

Օգտագործելով տվյալների լճի մոտեցումը, մենք բեռնում ենք չմշակված տվյալները մեր տվյալների լճում (խմբաքանակ կամ հոսք), այնուհետև մենք մշակում ենք տվյալները ըստ անհրաժեշտության: Տվյալների լիճը թույլ է տալիս բիզնես օգտագործողներին ստեղծել իրենց սեփական տվյալների փոխակերպումները (ETL/ELT) կամ վերլուծել տվյալները Business Intelligence լուծումներում (եթե անհրաժեշտ դրայվերն առկա է):

Ցանկացած վերլուծական լուծման նպատակը բիզնես օգտագործողներին սպասարկելն է: Ուստի մենք միշտ պետք է աշխատենք բիզնեսի պահանջներին համապատասխան։ (Amazon-ում սա սկզբունքներից մեկն է՝ աշխատել հետընթաց):

Աշխատելով ինչպես տվյալների պահեստի, այնպես էլ տվյալների լճի հետ, մենք կարող ենք համեմատել երկու լուծումները.

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

Կցանկանայի պատմել նաև այն դեպքերից մեկը, երբ սկսեցի օգտագործել տվյալների լճի մոտեցումը։ Ամեն ինչ բավականին տրիվիալ է, ես փորձեցի օգտագործել ELT գործիք (մենք ունեինք Matillion ETL) և Amazon Redshift, իմ լուծումը աշխատեց, բայց չէր համապատասխանում պահանջներին:

Ինձ անհրաժեշտ էր վերցնել վեբ տեղեկամատյանները, վերափոխել դրանք և համախմբել դրանք 2 դեպքի համար տվյալներ տրամադրելու համար.

1. Մարքեթինգային թիմը ցանկանում էր վերլուծել բոտերի գործունեությունը SEO-ի համար
2. IT-ը ցանկանում էր դիտարկել վեբ կայքի կատարողականի չափումները

Շատ պարզ, շատ պարզ տեղեկամատյաններ: Ահա մի օրինակ.

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

Մեկ ֆայլը կշռում էր 1-4 մեգաբայթ։

Բայց կար մեկ դժվարություն. Մենք ունեինք 7 տիրույթ ամբողջ աշխարհում, և մեկ օրում ստեղծվեց 7000 հազար ֆայլ։ Սա շատ ավելի ծավալ չէ, ընդամենը 50 գիգաբայթ: Բայց մեր Redshift կլաստերի չափը նույնպես փոքր էր (4 հանգույց): Մեկ ֆայլի ավանդական եղանակով բեռնումը տևեց մոտ մեկ րոպե: Այսինքն՝ խնդիրը դեմ առ դեմ չի լուծվել։ Եվ սա այն դեպքն էր, երբ ես որոշեցի օգտագործել տվյալների լճի մոտեցումը։ Լուծումը այսպիսի տեսք ուներ.

Դա բավականին պարզ է (ուզում եմ նշել, որ ամպում աշխատելու առավելությունը պարզությունն է): Ես օգտագործել եմ.

• AWS Elastic Map Reduce (Hadoop) հաշվարկային հզորության համար
• AWS S3-ը որպես ֆայլերի պահեստավորում՝ տվյալների կոդավորման և մուտքը սահմանափակելու ունակությամբ
• Spark որպես InMemory հաշվողական հզորություն և PySpark տրամաբանության և տվյալների փոխակերպման համար
• Մանրահատակ Spark-ի արդյունքում
• AWS Glue Crawler որպես մետատվյալների հավաքող նոր տվյալների և բաժանմունքների մասին
• Redshift Spectrum-ը որպես SQL ինտերֆեյս տվյալների լճի առկա Redshift օգտագործողների համար

Ամենափոքր EMR+Spark կլաստերը մշակել է ֆայլերի ամբողջ փաթեթը 30 րոպեում: AWS-ի այլ դեպքեր կան, հատկապես շատերը՝ կապված Alexa-ի հետ, որտեղ շատ տվյալներ կան։

Վերջերս ես իմացա, որ տվյալների լճի թերություններից մեկը GDPR-ն է: Խնդիրն այն է, երբ հաճախորդը խնդրում է ջնջել այն, և տվյալները գտնվում են ֆայլերից մեկում, մենք չենք կարող օգտագործել տվյալների մանիպուլյացիայի լեզուն և DELETE գործողությունը, ինչպես տվյալների բազայում:

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

Source: www.habr.com