Հե՜յ Հաբր։ Դասընթացների նոր հոսքի գրանցումը բաց է OTUS-ում հենց հիմա . Դասընթացի մեկնարկին ընդառաջ՝ ավանդաբար ձեզ համար պատրաստել ենք հետաքրքիր նյութերի թարգմանություն։
Ամեն օր ավելի քան հարյուր միլիոն մարդ այցելում է Twitter՝ պարզելու, թե ինչ է կատարվում աշխարհում և քննարկում այն: Յուրաքանչյուր թվիթ և օգտվողի ցանկացած այլ գործողություն առաջացնում է իրադարձություն, որը հասանելի է Twitter-ի ներքին տվյալների վերլուծության համար: Հարյուրավոր աշխատակիցներ վերլուծում և պատկերացնում են այս տվյալները, և նրանց փորձի բարելավումը Twitter Data Platform թիմի գլխավոր առաջնահերթությունն է:
Մենք կարծում ենք, որ տեխնիկական հմտությունների լայն շրջանակ ունեցող օգտատերերը պետք է կարողանան գտնել տվյալներ և հասանելիություն ունենան SQL-ի վրա հիմնված վերլուծության և վիզուալիզացիայի լավ գործող գործիքներին: Սա թույլ կտա ավելի քիչ տեխնիկական օգտատերերի մի ամբողջ նոր խմբի, ներառյալ տվյալների վերլուծաբաններին և արտադրանքի մենեջերներին, պատկերացումներ կորզել տվյալներից՝ թույլ տալով նրանց ավելի լավ հասկանալ և օգտագործել Twitter-ի ուժը: Ահա թե ինչպես ենք մենք ժողովրդավարացնում տվյալների վերլուծությունը Twitter-ում:
Քանի որ ներքին տվյալների վերլուծության մեր գործիքներն ու հնարավորությունները բարելավվել են, մենք տեսանք Twitter ծառայության բարելավումը: Այնուամենայնիվ, դեռ բարելավման տեղ կա: Ներկայիս գործիքները, ինչպիսիք են Scalding-ը, պահանջում են ծրագրավորման փորձ: SQL-ի վրա հիմնված վերլուծության գործիքները, ինչպիսիք են Presto-ն և Vertica-ն, մեծ մասշտաբով ունեն կատարողականի խնդիրներ: Մենք նաև խնդիր ունենք տվյալների բաշխման հետ կապված բազմաթիվ համակարգերի վրա՝ առանց դրանց մշտական հասանելիության:
Անցյալ տարի մենք հայտարարել էինք , որի շրջանակներում մենք փոխանցում ենք մեր մասերը Google Cloud Platform-ում (GCP): Մենք եզրակացրինք, որ Google Cloud գործիքները կարող է օգնել մեզ Twitter-ում վերլուծության, վիզուալիզացիայի և մեքենայական ուսուցման ժողովրդավարացման մեր նախաձեռնություններում.
- Ձեռնարկությունների տվյալների պահեստ՝ հիմնված SQL շարժիչով , որը հայտնի է իր արագությամբ, պարզությամբ և հաղթահարում .
- մեծ տվյալների վիզուալիզացիայի գործիք՝ Google Docs-ի նման համագործակցության առանձնահատկություններով:
Այս հոդվածում դուք կիմանաք այս գործիքների հետ կապված մեր փորձի մասին՝ ինչ ենք մենք արել, ինչ ենք սովորել և ինչ ենք անելու հետո: Այժմ մենք կկենտրոնանանք խմբաքանակի և ինտերակտիվ վերլուծությունների վրա: Իրական ժամանակի վերլուծությունը կքննարկվի հաջորդ հոդվածում:
Տվյալների պահեստների պատմությունը Twitter-ում
Նախքան BigQuery-ի մեջ մտնելը, արժե համառոտ վերապատմել Twitter-ում տվյալների պահեստների պատմությունը: 2011 թվականին Twitter-ում տվյալների վերլուծությունը կատարվել է Vertica-ում և Hadoop-ում։ MapReduce Hadoop-ի աշխատատեղեր ստեղծելու համար մենք օգտագործեցինք Pig-ը: 2012-ին մենք փոխարինեցինք Pig-ը Scalding-ով, որն ուներ Scala API՝ առավելություններով, ինչպիսիք են բարդ խողովակաշարեր ստեղծելու կարողությունը և թեստավորման հեշտությունը: Այնուամենայնիվ, շատ տվյալների վերլուծաբանների և արտադրանքի մենեջերների համար, ովքեր ավելի հարմարավետ էին աշխատում SQL-ի հետ, դա բավականին կտրուկ ուսուցման կոր էր: Մոտավորապես 2016-ին մենք սկսեցինք Presto-ն օգտագործել որպես մեր SQL առջևի վերջ Hadoop տվյալների համար: Spark-ն առաջարկեց Python ինտերֆեյս, որը այն լավ ընտրություն է դարձնում ժամանակավոր տվյալների գիտության և մեքենայական ուսուցման համար:
2018 թվականից մենք օգտագործել ենք տվյալների վերլուծության և վիզուալիզացիայի հետևյալ գործիքները.
- Այրվել է արտադրական գծերի համար
- Scalding և Spark տվյալների ժամանակավոր վերլուծության և մեքենայական ուսուցման համար
- Vertica և Presto՝ ժամանակավոր և ինտերակտիվ SQL վերլուծության համար
- Դրյուիդ ցածր ինտերակտիվ, հետախուզական և ցածր ուշացումով հասանելիության ժամանակային շարքերի չափման համար
- Tableau, Zeppelin և Pivot տվյալների վիզուալացման համար
Մենք պարզել ենք, որ թեև այս գործիքներն առաջարկում են շատ հզոր հնարավորություններ, մենք դժվարությամբ ենք այդ հնարավորությունները հասանելի դարձնելու ավելի լայն լսարանի Twitter-ում: Ընդլայնելով մեր հարթակը Google Cloud-ի միջոցով՝ մենք կենտրոնանում ենք Twitter-ի ողջ վերլուծական գործիքների պարզեցման վրա:
Google-ի BigQuery տվյալների պահեստ
Twitter-ի մի քանի թիմեր արդեն ներառել են BigQuery-ն իրենց որոշ արտադրական խողովակաշարերում: Օգտագործելով նրանց փորձը՝ մենք սկսեցինք գնահատել BigQuery-ի հնարավորությունները Twitter-ի օգտագործման բոլոր դեպքերի համար: Մեր նպատակն էր առաջարկել BigQuery-ն ամբողջ ընկերությանը և այն ստանդարտացնել և աջակցել Տվյալների պլատֆորմի գործիքակազմի շրջանակներում: Սա դժվար էր բազմաթիվ պատճառներով։ Մենք պետք է մշակեինք ենթակառուցվածք՝ մեծ քանակությամբ տվյալներ հուսալիորեն ստանալու, ամբողջ ընկերության տվյալների կառավարմանը աջակցելու, մուտքի պատշաճ վերահսկողություն ապահովելու և հաճախորդների գաղտնիությունը ապահովելու համար: Մենք նաև պետք է ստեղծեինք համակարգեր ռեսուրսների բաշխման, մոնիտորինգի և հետվճարման համար, որպեսզի թիմերը կարողանան արդյունավետ օգտագործել BigQuery-ն:
2018 թվականի նոյեմբերին մենք թողարկեցինք BigQuery-ի և Data Studio-ի ալֆա թողարկումն ամբողջ ընկերության համար: Մենք Twitter-ի աշխատակիցներին առաջարկել ենք մեր ամենաշատ օգտագործվող անձնական տվյալների մաքրման աղյուսակները: BigQuery-ն օգտագործվել է ավելի քան 250 օգտվողների կողմից տարբեր թիմերից, ներառյալ ճարտարագիտությունը, ֆինանսները և մարքեթինգը: Բոլորովին վերջերս նրանք կատարում էին մոտ 8 հարցումներ՝ մշակելով ամսական մոտ 100 PB՝ չհաշված պլանավորված հարցումները: Շատ դրական արձագանքներ ստանալուց հետո մենք որոշեցինք առաջ շարժվել և առաջարկել BigQuery-ն որպես Twitter-ում տվյալների հետ փոխազդելու առաջնային ռեսուրս:
Ահա մեր Google BigQuery տվյալների պահեստի բարձր մակարդակի ճարտարապետության դիագրամը:
Մենք պատճենում ենք տվյալները տեղական Hadoop կլաստերներից Google Cloud Storage (GCS)՝ օգտագործելով ներքին Cloud Replicator գործիքը: Այնուհետև մենք օգտագործում ենք Apache Airflow խողովակաշարեր ստեղծելու համար, որոնք օգտագործում են «» GCS-ից տվյալները BigQuery-ում բեռնելու համար: Մենք օգտագործում ենք Presto՝ GCS-ում Parquet կամ Thrift-LZO տվյալների հավաքածուներ հարցումներ անելու համար: BQ Blaster-ը ներքին Scalding գործիք է՝ HDFS Vertica և Thrift-LZO տվյալների հավաքածուները BigQuery-ում բեռնելու համար:
Հետևյալ բաժիններում մենք կքննարկենք մեր մոտեցումն ու փորձը օգտագործման հեշտության, կատարողականի, տվյալների կառավարման, համակարգի առողջության և ծախսերի վերաբերյալ:
Օգտագործման դյուրինություն
Մենք պարզեցինք, որ օգտատերերի համար հեշտ էր սկսել BigQuery-ով, քանի որ այն չի պահանջում ծրագրային ապահովման տեղադրում, և օգտվողները կարող էին մուտք գործել դրան ինտուիտիվ վեբ ինտերֆեյսի միջոցով: Այնուամենայնիվ, օգտվողները պետք է ծանոթանային GCP-ի որոշ առանձնահատկություններին և հասկացություններին, ներառյալ ռեսուրսները, ինչպիսիք են նախագծերը, տվյալների հավաքածուները և աղյուսակները: Մենք մշակել ենք ձեռնարկներ և ձեռնարկներ, որոնք կօգնեն օգտատերերին սկսել: Ձեռք բերված հիմնական հասկացողությամբ օգտվողների համար հեշտ է նավարկել տվյալների հավաքածուները, դիտել սխեման և աղյուսակի տվյալները, կատարել պարզ հարցումներ և պատկերացնել արդյունքները Data Studio-ում:
BigQuery-ում տվյալների մուտքագրման հետ կապված մեր նպատակն էր ապահովել HDFS կամ GCS տվյալների հավաքածուների անխափան բեռնում մեկ սեղմումով: Մենք համարել ենք (կառավարվում է Airflow-ի կողմից), բայց չկարողացան օգտագործել այն մեր «Դոմենի սահմանափակ համօգտագործման» անվտանգության մոդելի պատճառով (այս մասին ավելին ստորև՝ Տվյալների կառավարում բաժնում): Մենք փորձեցինք օգտագործել Google Data Transfer Service (DTS)՝ BigQuery բեռնման առաջադրանքները կազմակերպելու համար: Թեև DTS-ը արագ տեղադրվեց, այն ճկուն չէր կախվածություն ունեցող խողովակաշարեր կառուցելու համար: Մեր ալֆա թողարկման համար մենք ստեղծել ենք մեր սեփական Apache Airflow միջավայրը GCE-ում և պատրաստում ենք այն արտադրությանը և ավելի շատ տվյալների աղբյուրներին աջակցելու հնարավորություն, ինչպիսին է Vertica-ն:
Տվյալները BigQuery-ի փոխակերպելու համար օգտվողները ստեղծում են պարզ SQL տվյալների խողովակաշարեր՝ օգտագործելով պլանավորված հարցումներ: Կախվածություն ունեցող բարդ բազմաստիճան խողովակաշարերի համար մենք նախատեսում ենք օգտագործել կամ մեր սեփական Airflow շրջանակը կամ Cloud Composer-ը .
Արտադրողականություն
BigQuery-ն նախատեսված է ընդհանուր նշանակության SQL հարցումների համար, որոնք մշակում են մեծ քանակությամբ տվյալներ: Այն նախատեսված չէ գործարքային տվյալների բազայի կողմից պահանջվող ցածր ուշացման, բարձր թողունակության հարցումների կամ իրականացված ցածր հետաձգման ժամանակային շարքերի վերլուծության համար։ . Ինտերակտիվ վերլուծական հարցումների համար մեր օգտատերերն ակնկալում են մեկ րոպեից պակաս պատասխան ժամանակ: Մենք պետք է նախագծեինք BigQuery-ի օգտագործումը՝ այս ակնկալիքները բավարարելու համար: Մեր օգտատերերի համար կանխատեսելի կատարողականություն ապահովելու համար մենք օգտագործել ենք BigQuery ֆունկցիոնալությունը, որը հասանելի է հաճախորդներին ֆիքսված վճարի հիմունքներով, ինչը թույլ է տալիս նախագծի սեփականատերերին վերապահել նվազագույն սլոտերը իրենց հարցումների համար: BigQuery-ն հաշվողական հզորության միավոր է, որն անհրաժեշտ է SQL հարցումները կատարելու համար:
Մենք վերլուծել ենք ավելի քան 800 հարցումներ, որոնք մշակում են յուրաքանչյուրը մոտ 1 ՏԲ տվյալ և պարզել ենք, որ կատարման միջին ժամանակը 30 վայրկյան է: Մենք նաև իմացանք, որ կատարումը մեծապես կախված է տարբեր նախագծերում և առաջադրանքներում մեր անցքի օգտագործումից: Մենք պետք է հստակ տարանջատեինք մեր արտադրական և ժամանակավոր տեղամասերի պաշարները, որպեսզի պահպանենք արդյունավետությունը արտադրության օգտագործման դեպքերի և ինտերակտիվ վերլուծության համար: Սա մեծապես ազդեց բնիկների ամրագրման և նախագծերի հիերարխիայի մեր նախագծման վրա:
Տվյալների կառավարման, ֆունկցիոնալության և համակարգերի արժեքի մասին կխոսենք առաջիկա օրերին թարգմանության երկրորդ մասում, իսկ այժմ բոլորին հրավիրում ենք. , որտեղ կարող եք ավելին իմանալ դասընթացի մասին, ինչպես նաև հարցեր տալ մեր փորձագետին՝ Եգոր Մատեշուկին (Տվյալների ավագ ինժեներ, MaximaTelecom):
Կարդալ ավելին:
Source: www.habr.com