ժամանակակից բաց կոդով տվյալների կույտ բլոկչեյնի համար

1. Ժամանակակից բլոկչեյն տվյալների կույտի մարտահրավերը

Կան մի քանի մարտահրավերներ, որոնց կարող է հանդիպել ժամանակակից բլոկչեյն ինդեքսավորման ստարտափը, այդ թվում՝

• Հսկայական քանակությամբ տվյալներ. Քանի որ բլոկչեյնի տվյալների քանակն ավելանում է, տվյալների ինդեքսը պետք է մեծանա՝ կարգավորելու ավելացած բեռը և ապահովելու տվյալներին արդյունավետ հասանելիություն: Հետևաբար, դա հանգեցնում է պահեստավորման ավելի մեծ ծախսերի, չափումների դանդաղ հաշվարկի և տվյալների բազայի սերվերի բեռի ավելացման:
• Տվյալների մշակման համալիր խողովակաշար: Blockchain տեխնոլոգիան բարդ է, և տվյալների համապարփակ և հուսալի ինդեքսի կառուցումը պահանջում է հիմքում ընկած տվյալների կառուցվածքների և ալգորիթմների խորը պատկերացում: Բլոկչեյնի ներդրման բազմազանությունը ժառանգում է այն: Ելնելով կոնկրետ օրինակներից՝ NFT-ները Ethereum-ում սովորաբար ստեղծվում են խելացի պայմանագրերի շրջանակներում՝ հետևելով ERC721 և ERC1155 ձևաչափերին: Ի հակադրություն, օրինակ, Polkadot-ում դրանց իրականացումը սովորաբար կառուցվում է անմիջապես բլոկչեյնի գործարկման ընթացքում: Դրանք պետք է համարվեն NFT և պետք է պահպանվեն որպես այդպիսին:
• Ինտեգրման հնարավորություններ. Օգտատերերին առավելագույն արժեք ապահովելու համար բլոկչեյն ինդեքսավորման լուծումը կարող է անհրաժեշտ լինել իր տվյալների ինդեքսը ինտեգրել այլ համակարգերի հետ, ինչպիսիք են վերլուծական հարթակները կամ API-ները: Սա դժվար է և պահանջում է զգալի ջանքեր, որոնք ներդրվում են ճարտարապետության նախագծման մեջ:

Քանի որ բլոկչեյն տեխնոլոգիան դարձել է ավելի լայն տարածում, բլոկչեյնում պահվող տվյալների քանակը մեծացել է։ Դա պայմանավորված է նրանով, որ ավելի շատ մարդիկ օգտագործում են տեխնոլոգիան, և յուրաքանչյուր գործարք ավելացնում է նոր տվյալներ բլոկչեյնին: Բացի այդ, բլոկչեյն տեխնոլոգիան վերածվել է փողի փոխանցման պարզ հավելվածներից, ինչպիսիք են Bitcoin-ի օգտագործումը, մինչև ավելի բարդ հավելվածներ, որոնք ներառում են բիզնես տրամաբանության իրականացում խելացի պայմանագրերում: Այս խելացի պայմանագրերը կարող են մեծ քանակությամբ տվյալներ ստեղծել՝ նպաստելով բլոկչեյնի բարդության և չափի ավելացմանը: Ժամանակի ընթացքում դա հանգեցրել է ավելի մեծ և բարդ բլոկչեյնի:

Այս հոդվածում մենք վերանայում ենք Footprint Analytics-ի տեխնոլոգիական ճարտարապետության էվոլյուցիան փուլերով՝ որպես դեպքի ուսումնասիրություն, որպեսզի ուսումնասիրենք, թե ինչպես է Iceberg-Trino տեխնոլոգիական փաթեթը լուծում շղթայական տվյալների մարտահրավերներին:

Footprint Analytics-ը ինդեքսավորել է մոտ 22 հանրային բլոկչեյնի տվյալներ և 17 NFT շուկա, 1900 GameFi նախագիծ և ավելի քան 100,000 NFT հավաքածուներ իմաստային աբստրակցիոն տվյալների շերտում: Դա բլոկչեյն տվյալների պահեստի ամենաընդգրկուն լուծումն է աշխարհում:

Անկախ բլոկչեյնի տվյալներից, որոնք ներառում են ավելի քան 20 միլիարդ տող ֆինանսական գործարքների գրառումների, որոնք տվյալների վերլուծաբանները հաճախ հարցնում են: այն տարբերվում է ավանդական տվյալների պահեստներում ներխուժման տեղեկամատյաններից:

Անցած մի քանի ամիսների ընթացքում մենք ունեցել ենք 3 հիմնական արդիականացում՝ բավարարելու աճող բիզնեսի պահանջները.

2. Ճարտարապետություն 1.0 Bigquery

Footprint Analytics-ի սկզբում մենք օգտագործեցինք Google Bigquery որպես մեր պահեստավորման և հարցումների շարժիչ; Bigquery-ն հիանալի արտադրանք է: Այն ահավոր արագ է, հեշտ օգտագործման համար և ապահովում է դինամիկ թվաբանական ուժ և ճկուն UDF շարահյուսություն, որն օգնում է մեզ արագ կատարել աշխատանքը:

Այնուամենայնիվ, Bigquery-ն ունի նաև մի քանի խնդիրներ.

• Տվյալները չեն սեղմվում, ինչը հանգեցնում է բարձր ծախսերի, հատկապես, երբ պահպանվում են Footprint Analytics-ի ավելի քան 22 բլոկչեյնների չմշակված տվյալները:
• Անբավարար համաժամանակություն. Bigquery-ն աջակցում է միայն 100 միաժամանակյա հարցումների, ինչը հարմար չէ Footprint Analytics-ի բարձր միաժամանակության սցենարների համար, երբ սպասարկում է բազմաթիվ վերլուծաբանների և օգտատերերի:
• Կողպեք Google Bigquery-ի միջոցով, որը փակ կոդով արտադրանք է:

Այսպիսով, մենք որոշեցինք ուսումնասիրել այլ այլընտրանքային ճարտարապետություններ:

3. Ճարտարապետություն 2.0 OLAP

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

Մենք ընտրեցինք OLAP-ի լավագույն տվյալների բազաներից մեկը, Դորիս, փորձելու համար։ Այս շարժիչը լավ է աշխատում: Այնուամենայնիվ, ինչ-որ պահի մենք շուտով հանդիպեցինք մի քանի այլ խնդիրների.

• Տվյալների տեսակները, ինչպիսիք են Array-ը կամ JSON-ը, դեռ չեն աջակցվում (նոյեմբեր, 2022): Զանգվածները տվյալների տարածված տեսակ են որոշ բլոկչեյններում: Օրինակ՝ թեմայի դաշտ evm տեղեկամատյաններում. Array-ի վրա հաշվելու անհնարինությունը ուղղակիորեն ազդում է բիզնեսի բազմաթիվ ցուցանիշներ հաշվարկելու մեր ունակության վրա:
• Սահմանափակ աջակցություն DBT-ին և միաձուլման հայտարարություններին: Սրանք ընդհանուր պահանջներ են տվյալների ինժեներների համար ETL/ELT սցենարների համար, որտեղ մենք պետք է թարմացնենք որոշ նոր ինդեքսավորված տվյալներ:

Այսպիսով, մենք չկարողացանք օգտագործել Doris-ը արտադրության վերաբերյալ մեր ամբողջ տվյալների խողովակաշարի համար, ուստի մենք փորձեցինք օգտագործել Doris-ը որպես OLAP տվյալների բազա՝ լուծելու մեր խնդրի մի մասը տվյալների արտադրության խողովակաշարում՝ գործելով որպես հարցումների շարժիչ և ապահովելով արագ և բարձր մակարդակ։ միաժամանակյա հարցումների հնարավորություններ:

Ցավոք, մենք չկարողացանք Bigquery-ին փոխարինել Doris-ով, ուստի ստիպված էինք պարբերաբար համաժամեցնել տվյալները Bigquery-ից Doris-ին՝ օգտագործելով դրանք որպես հարցումների շարժիչ: Այս համաժամացման գործընթացն ուներ մի քանի խնդիրներ, որոնցից մեկն այն էր, որ թարմացման գրությունները արագ կուտակվեցին, երբ OLAP շարժիչը զբաղված էր ֆրոնտային հաճախորդներին հարցումներ մատուցելով: Հետագայում գրելու գործընթացի արագությունը ազդեց, և համաժամացումը տևեց շատ ավելի երկար, և երբեմն նույնիսկ անհնար էր դառնում ավարտվել:

Մենք հասկացանք, որ OLAP-ը կարող է լուծել մեր առջև ծառացած մի շարք խնդիրներ և չի կարող դառնալ Footprint Analytics-ի բանական լուծումը, հատկապես տվյալների մշակման խողովակաշարի համար: Մեր խնդիրն ավելի մեծ է և բարդ, և մենք կարող ենք ասել, որ OLAP-ը, քանի որ միայն հարցումների շարժիչը մեզ համար բավարար չէր:

4. Ճարտարապետություն 3.0 Այսբերգ + Տրինո

Բարի գալուստ Footprint Analytics ճարտարապետություն 3.0՝ հիմքում ընկած ճարտարապետության ամբողջական վերանայում: Մենք վերանախագծել ենք ամբողջ ճարտարապետությունը ի սկզբանե՝ տվյալների պահեստավորումը, հաշվարկը և հարցումը բաժանելու երեք տարբեր մասերի: Դասեր քաղելով Footprint Analytics-ի երկու նախկին ճարտարապետություններից և սովորելով այլ հաջողված մեծ տվյալների նախագծերի փորձից, ինչպիսիք են Uber-ը, Netflix-ը և Databricks-ը:

4.1. Տվյալների լճի ներդրում

Մենք առաջին հերթին մեր ուշադրությունը դարձրեցինք տվյալների լճի վրա, որը տվյալների պահպանման նոր տեսակ է ինչպես կառուցվածքային, այնպես էլ ոչ կառուցվածքային տվյալների համար: Տվյալների լիճը կատարյալ է շղթայական տվյալների պահպանման համար, քանի որ շղթայական տվյալների ձևաչափերը լայնորեն տատանվում են՝ չկառուցված չմշակված տվյալներից մինչև կառուցվածքային աբստրակցիոն տվյալների Footprint Analytics-ը հայտնի է: Մենք ակնկալում էինք օգտագործել տվյալների լիճը տվյալների պահպանման խնդիրը լուծելու համար, և իդեալականորեն այն նաև կաջակցեր հիմնական հաշվողական շարժիչներին, ինչպիսիք են Spark-ը և Flink-ը, որպեսզի դժվար չլինի ինտեգրվել տարբեր տեսակի մշակող շարժիչներին, քանի որ Footprint Analytics-ը զարգանում է: .

Այսբերգը շատ լավ ինտեգրվում է Spark, Flink, Trino և այլ հաշվողական շարժիչների հետ, և մենք կարող ենք ընտրել ամենահարմար հաշվարկը մեր յուրաքանչյուր ցուցանիշի համար: Օրինակ:

• Նրանց համար, ովքեր պահանջում են բարդ հաշվողական տրամաբանություն, Spark-ը կլինի ընտրությունը:
• Flink իրական ժամանակում հաշվարկելու համար:
• Պարզ ETL առաջադրանքների համար, որոնք կարող են կատարվել SQL-ի միջոցով, մենք օգտագործում ենք Trino:

4.2. Հարցման շարժիչ

Այսբերգը լուծելով պահեստավորման և հաշվարկման խնդիրները, մենք պետք է մտածեինք հարցումների շարժիչ ընտրելու մասին: Շատ տարբերակներ չկան։ Մեր դիտարկած այլընտրանքներն էին

Ամենակարևորը, որ մենք հաշվի առանք նախքան ավելի խորանալը, այն էր, որ ապագա հարցումների շարժիչը պետք է համապատասխաներ մեր ներկայիս ճարտարապետությանը:

• Bigquery-ին որպես տվյալների աղբյուր աջակցելու համար
• DBT-ին աջակցելու համար, որի վրա մենք հիմնվում ենք բազմաթիվ չափումների արտադրության համար
• BI գործիքի մեթաբազային աջակցելու համար

Ելնելով վերը նշվածից՝ մենք ընտրեցինք Trino-ն, որն ունի շատ լավ աջակցություն Iceberg-ի համար, և թիմն այնքան արձագանքեց, որ մենք բարձրացրինք սխալ, որը շտկվեց հաջորդ օրը և թողարկվեց վերջին տարբերակին հաջորդ շաբաթ: Սա լավագույն ընտրությունն էր Footprint թիմի համար, որը նույնպես պահանջում է կատարման բարձր արձագանք:

4.3. Կատարման փորձարկում

Երբ մենք որոշեցինք մեր ուղղությունը, մենք կատարողականության թեստ արեցինք Trino + Iceberg համակցության վրա՝ տեսնելու, թե արդյոք այն կարող է բավարարել մեր կարիքները, և ի զարմանս մեզ, հարցումները աներևակայելի արագ էին:

Իմանալով, որ Presto + Hive-ը տարիներ շարունակ ամենավատ համեմատողն է եղել OLAP-ի ողջ աղմուկի մեջ, Trino + Այսբերգի համադրությունը ամբողջովին փչեց մեր միտքը:

Ահա մեր թեստերի արդյունքները.

դեպք 1. միացնել մեծ տվյալների բազա

800 ԳԲ աղյուսակը1 միանում է ևս 50 ԳԲ սեղան2 և կատարում է բարդ բիզնես հաշվարկներ

Case2. օգտագործել մեծ մեկ աղյուսակ՝ հստակ հարցում կատարելու համար

Փորձարկեք sql. ընտրեք առանձին (հասցե) աղյուսակի խմբից ըստ օրվա

Trino+Iceberg համակցությունը մոտ 3 անգամ ավելի արագ է, քան Դորիսը նույն կոնֆիգուրացիայի մեջ:

Բացի այդ, կա ևս մեկ անակնկալ, քանի որ Iceberg-ը կարող է օգտագործել տվյալների ձևաչափեր, ինչպիսիք են Parquet, ORC և այլն, որոնք կսեղմեն և կպահեն տվյալները: Այսբերգի սեղանի պահեստավորումը զբաղեցնում է տվյալների այլ պահեստների տարածքի միայն 1/5-ը: Նույն աղյուսակի պահեստավորման չափը երեք տվյալների բազայում հետևյալն է.

Նշում. Վերոնշյալ թեստերը օրինակներ են, որոնք մենք հանդիպել ենք իրական արտադրության մեջ և նախատեսված են միայն հղման համար:

4.4. Թարմացման էֆեկտ

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

• Բազմաթիվ համակարգչային շարժիչներ համապատասխանում են մեր տարբեր կարիքներին:
• Trino-ն աջակցում է DBT-ին և կարող է ուղղակիորեն հարցումներ կատարել Iceberg-ին, այնպես որ մենք այլևս ստիպված չենք լինի զբաղվել տվյալների համաժամացման հետ:
• Trino + Iceberg-ի զարմանալի կատարումը թույլ է տալիս մեզ բացել բոլոր բրոնզե տվյալները (հում տվյալներ) մեր օգտատերերի համար:

5. Ամփոփում

2021 թվականի օգոստոսին իր գործարկումից ի վեր, Footprint Analytics-ի թիմը մեկուկես տարուց պակաս ժամանակում ավարտել է երեք ճարտարապետական ​​արդիականացում՝ շնորհիվ իր մեծ ցանկության և վճռականության՝ իր կրիպտո օգտատերերին բերելու տվյալների բազայի լավագույն տեխնոլոգիայի առավելությունները, ինչպես նաև կիրառման և կիրառման ամուր կատարման: արդիականացնելով դրա հիմքում ընկած ենթակառուցվածքը և ճարտարապետությունը:

Footprint Analytics ճարտարապետության արդիականացումը 3.0-ն իր օգտատերերին նոր փորձ է ձեռք բերել՝ թույլ տալով տարբեր ծագում ունեցող օգտատերերին պատկերացումներ ստանալ ավելի բազմազան օգտագործման և հավելվածների վերաբերյալ.

• Կառուցված Metabase BI գործիքով, Footprint-ը վերլուծաբաններին հեշտացնում է մուտք գործել վերծանված շղթայական տվյալներ, ուսումնասիրել գործիքների ընտրության լիակատար ազատությամբ (առանց կոդերի կամ կոշտ լարերի), հարցումներ կատարել ամբողջ պատմության մեջ և խաչաձև ուսումնասիրել տվյալների հավաքածուները՝ պատկերացում կազմելու համար: ոչ ժամանակ.
• Ինտեգրել և՛ շղթայական, և՛ շղթայից դուրս տվյալները վեբ2 + վեբ3-ի վերլուծության համար;
• Footprint-ի բիզնեսի աբստրակցիայի վերևում կառուցելով/հարցումների չափումներ՝ վերլուծաբանները կամ մշակողները ժամանակ են խնայում կրկնվող տվյալների մշակման աշխատանքների 80%-ի վրա և կենտրոնանում են իրենց բիզնեսի վրա հիմնված իմաստալից չափումների, հետազոտությունների և արտադրանքի լուծումների վրա:
• Անթերի փորձ Footprint Web-ից մինչև REST API զանգեր՝ բոլորը հիմնված են SQL-ի վրա
• Իրական ժամանակի ծանուցումներ և գործող ծանուցումներ հիմնական ազդանշանների վերաբերյալ՝ աջակցելու ներդրումային որոշումներին