Աղյուսակը մանրածախ առևտրում, իրո՞ք:

Excel-ում հաշվետվության ժամանակն արագորեն անհետանում է. տեղեկատվության ներկայացման և վերլուծության համար հարմար գործիքների միտումը տեսանելի է բոլոր ոլորտներում: Մենք երկար ժամանակ քննարկում էինք հաշվետվությունների թվայնացման հարցը և ընտրեցինք Tableau-ի վիզուալիզացիայի և ինքնասպասարկման վերլուծության համակարգը: M.Video-Eldorado Group-ի վերլուծական լուծումների և հաշվետվությունների բաժնի ղեկավար Ալեքսանդր Բեզուգլին խոսեց մարտական ​​վահանակի կառուցման փորձի և արդյունքների մասին։

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

Ստորև բերված է այն մասին, թե ինչի հետ հանդիպեցինք և ինչի մասին իմացանք:

Որտեղի՞ց սկսեցինք:

M.Video-Eldorado-ն ունի տվյալների լավ մշակված մոդել՝ կառուցվածքային տեղեկատվություն պահպանման անհրաժեշտ խորությամբ և ֆիքսված ձևի հաշվետվությունների հսկայական քանակով (տես ավելի մանրամասն այս հոդվածը) Դրանցից վերլուծաբանները կազմում են կամ առանցքային աղյուսակներ կամ ձևաչափված տեղեկագրեր Excel-ում, կամ գեղեցիկ PowerPoint ներկայացումներ վերջնական օգտագործողների համար:

Մոտ երկու տարի առաջ, ֆիքսված ձևի հաշվետվությունների փոխարեն, մենք սկսեցինք ստեղծել վերլուծական հաշվետվություններ SAP Analysis-ում (Excel հավելում, ըստ էության, առանցքային աղյուսակ OLAP շարժիչի վրա): Բայց այս գործիքը չի կարողացել բավարարել բոլոր օգտատերերի կարիքները, մեծամասնությունը շարունակել է օգտագործել վերլուծաբանների կողմից լրացուցիչ մշակված տեղեկատվություն:

Մեր վերջնական օգտագործողները բաժանվում են երեք կատեգորիայի.

Բարձրագույն ղեկավարություն. Հայցում է տեղեկատվություն լավ ներկայացված և հստակ հասկանալի ձևով:

Միջին կառավարում, առաջադեմ օգտվողներ. Հետաքրքրված է տվյալների ուսումնասիրությամբ և կարող է ինքնուրույն հաշվետվություններ պատրաստել, եթե առկա են գործիքներ: Նրանք դարձան SAP Analysis-ի վերլուծական հաշվետվությունների հիմնական օգտվողները:

Զանգվածային օգտվողներ. Նրանք շահագրգռված չեն տվյալների ինքնուրույն վերլուծությամբ, նրանք օգտագործում են հաշվետվություններ սահմանափակ ազատության աստիճանով, Excel-ում տեղեկագրերի և առանցքային աղյուսակների ձևաչափով:

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

Քանի որ վահանակների օգտագործողները բարձրագույն ղեկավարությունն էին, հայտնվեց ապրանքի ևս մեկ լրացուցիչ KPI՝ արձագանքման արագություն: Ոչ ոք չի սպասի 20-30 վայրկյան, որպեսզի տվյալները թարմացվեն։ Նավիգացիան պետք է կատարվեր 4-5 վայրկյանի ընթացքում, կամ ավելի լավ է արվեր անմիջապես: Իսկ մեզ, ավաղ, չհաջողվեց դրան հասնել։

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

Հիմնական գաղափարը ձախ կողմում միավորել KPI-ի հիմնական դրայվերները, որոնցից ընդհանուր առմամբ 19-ն է եղել, և աջ կողմում ներկայացնել դրանց դինամիկան և բաշխումն ըստ հիմնական հատկանիշների: Խնդիրը պարզ է թվում, վիզուալիզացիան տրամաբանական է և հասկանալի, մինչև չես խորասուզվել մանրամասների մեջ:

Մանրամասն 1. Տվյալների ծավալը

Տարեկան վաճառքի մեր հիմնական աղյուսակը զբաղեցնում է մոտ 300 միլիոն տող: Քանի որ անհրաժեշտ է արտացոլել նախորդ և նախորդ տարվա դինամիկան, միայն փաստացի վաճառքի վերաբերյալ տվյալների ծավալը կազմում է մոտ 1 միլիարդ տող։ Պլանավորված տվյալների և առցանց վաճառքի բլոկի մասին տեղեկությունները նույնպես պահվում են առանձին: Հետևաբար, չնայած մենք օգտագործում էինք սյունակային հիշողության մեջ DB SAP HANA, հարցման արագությունը բոլոր ցուցիչների ընտրությամբ մեկ շաբաթվա ընթացքում ընթացիկ պահոցից մոտ 15-20 վայրկյան էր: Այս խնդրի լուծումն ինքնին հուշում է՝ տվյալների լրացուցիչ նյութականացում։ Բայց այն նաև որոգայթներ ունի, դրանց մասին ավելի մանրամասն ստորև:

Մանրամասն 2. Ոչ հավելյալ ցուցանիշներ

Մեր KPI-ներից շատերը կապված են ստացականների քանակի հետ: Եվ այս ցուցանիշը ներկայացնում է տողերի քանակի COUNT DISTINCT (ստուգեք վերնագրերը) և ցույց է տալիս տարբեր գումարներ՝ կախված ընտրված հատկանիշներից: Օրինակ, ինչպես պետք է հաշվարկվի այս ցուցանիշը և դրա ածանցյալը.

Ձեր հաշվարկները ճիշտ դարձնելու համար կարող եք.

• Հաշվեք նման ցուցանիշները պահեստում թռչելիս.
• Կատարեք հաշվարկներ Tableau-ում տվյալների ողջ ծավալի վրա, այսինքն. Tableau-ում խնդրանքով տրամադրեք բոլոր տվյալները՝ ըստ ընտրված ֆիլտրերի, ստացման դիրքի հստակության մեջ.
• Ստեղծեք նյութականացված ցուցափեղկ, որտեղ բոլոր ցուցանիշները կհաշվարկվեն բոլոր ընտրանքային տարբերակներում, որոնք տալիս են տարբեր ոչ հավելյալ արդյունքներ:

Պարզ է, որ օրինակում UTE1-ը և UTE2-ը արտադրանքի հիերարխիան ներկայացնող նյութական ատրիբուտներ են: Սա ստատիկ բան չէ, ընկերության ներսում կառավարումը տեղի է ունենում դրա միջոցով, քանի որ... Տարբեր մենեջերներ պատասխանատու են տարբեր ապրանքային խմբերի համար: Մենք ունեինք այս հիերարխիայի բազմաթիվ գլոբալ վերանայումներ, երբ փոխվեցին բոլոր մակարդակները, երբ փոխվեցին հարաբերությունները և մշտական ​​կետերի փոփոխություններ, երբ մի խումբը տեղափոխվեց մի հանգույցից մյուսը: Պայմանական հաշվետվության մեջ այս ամենը հաշվարկվում է անմիջապես նյութի ատրիբուտներից, այս տվյալների նյութականացման դեպքում անհրաժեշտ է մշակել նման փոփոխություններին հետևելու և պատմական տվյալների ավտոմատ վերաբեռնման մեխանիզմ: Շատ ոչ տրիվիալ խնդիր.

Մանրամասն 3. Տվյալների համեմատություն

Այս կետը նման է նախորդին. Ներքևի տողն այն է, որ ընկերությունը վերլուծելիս ընդունված է համեմատության մի քանի մակարդակներ կազմել նախորդ ժամանակաշրջանի հետ.

Համեմատություն նախորդ ժամանակաշրջանի հետ (օր առ օր, շաբաթ առ շաբաթ, ամիս առ ամիս)

Այս համեմատության մեջ ենթադրվում է, որ կախված օգտագործողի ընտրած ժամանակաշրջանից (օրինակ՝ տարվա 33-րդ շաբաթը), մենք պետք է դինամիկան ցույց տանք մինչև 32-րդ շաբաթը, եթե ընտրել ենք մեկ ամսվա տվյալներ, օրինակ՝ մայիս. , ապա այս համեմատությունը ցույց կտա դինամիկան մինչև ապրիլ։

Համեմատություն անցած տարվա հետ

Այստեղ հիմնական նրբերանգն այն է, որ ըստ օրվա և շաբաթվա համեմատության դեպքում դուք չեք վերցնում անցյալ տարվա նույն օրը, այսինքն. Դուք չեք կարող պարզապես ընթացիկ տարին մինուս մեկ դնել: Դուք պետք է նայեք շաբաթվա օրը, որը համեմատում եք: Ամիսները համեմատելիս, ընդհակառակը, պետք է վերցնել անցյալ տարվա ճիշտ նույն օրացուցային օրը։ Նահանջ տարիների հետ կապված կան նաև նրբերանգներ։ Բնօրինակ պահոցներում ամբողջ տեղեկատվությունը բաշխվում է օրական, չկան առանձին դաշտեր շաբաթներով, ամիսներով կամ տարիներով: Հետևաբար, պանելում ամբողջական վերլուծական խաչմերուկ ստանալու համար հարկավոր է հաշվել ոչ թե մեկ ժամանակահատված, օրինակ մեկ շաբաթ, այլ 4 շաբաթ, այնուհետև համեմատել այս տվյալները, արտացոլել դինամիկան, շեղումները: Համապատասխանաբար, դինամիկայի համեմատություններ ստեղծելու այս տրամաբանությունը կարող է իրականացվել նաև Tableau-ում կամ խանութի ցուցափեղկի վրա: Այո, և, իհարկե, մենք գիտեինք և մտածեցինք այս մանրամասների մասին նախագծման փուլում, բայց դժվար էր կանխատեսել դրանց ազդեցությունը վերջնական վահանակի աշխատանքի վրա:

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

Մաս 1. Հավատք աղյուսակին

ՏՏ աջակցությունը պարզեցնելու և փոփոխություններն արագ իրականացնելու համար մենք որոշեցինք տրամաբանություն ստեղծել Tableau-ում ոչ հավելյալ ցուցանիշների հաշվարկման և անցյալ ժամանակաշրջանների համեմատման համար:

Փուլ 1. Ամեն ինչ Live է, պատուհանի փոփոխություններ չկան:

Այս փուլում մենք Tableau-ին միացրինք ներկայիս ցուցափեղկերին և որոշեցինք տեսնել, թե ինչպես է հաշվարկվելու մեկ տարվա կտրոնների քանակը։

Արդյունքը:

Պատասխանը ճնշող էր՝ 20 րոպե։ Տվյալների փոխանցում ցանցի միջոցով, Tableau-ի մեծ ծանրաբեռնվածություն: Մենք հասկացանք, որ ՀԱՆԱ-ում պետք է իրականացնել ոչ հավելյալ ցուցանիշներով տրամաբանություն։ Սա մեզ այնքան էլ չվախեցրեց, մենք արդեն ունեինք նմանատիպ փորձ BO-ի և Analysis-ի հետ, և մենք գիտեինք, թե ինչպես կառուցել արագ ցուցափեղկեր ՀԱՆԱ-ում, որոնք արտադրում են ճիշտ հաշվարկված ոչ հավելյալ ցուցանիշներ: Այժմ մնում էր միայն դրանք հարմարեցնել Tableau-ին։

Փուլ 2. Մենք լարում ենք ցուցափեղկերը, առանց նյութականացման, ամեն ինչ թռիչքի մեջ է:

Մենք ստեղծեցինք առանձին նոր ցուցափեղկ, որն ապահովում էր TABLEAU-ի համար անհրաժեշտ տվյալները: Ընդհանուր առմամբ, մենք լավ արդյունք ստացանք՝ մեկ շաբաթվա ընթացքում բոլոր ցուցանիշների գեներացման ժամանակը կրճատեցինք մինչև 9-10 վայրկյան։ Եվ մենք անկեղծորեն ակնկալում էինք, որ Tableau-ում վահանակի արձագանքման ժամանակը կկազմի 20-30 վայրկյան առաջին բացման ժամանակ, այնուհետև 10-ից 12-ի քեշի պատճառով, որն ընդհանուր առմամբ մեզ կհամապատասխանի:

Արդյունքը:

Առաջին բաց վահանակը՝ 4-5 րոպե
Ցանկացած սեղմում` 3-4 րոպե
Ոչ ոք չէր սպասում ցուցափեղկի աշխատանքի նման հավելյալ աճ։

Մաս 2. Սուզվեք աղյուսակի մեջ

Փուլ 1. Աղյուսակների կատարողականի վերլուծություն և արագ թյունինգ

Մենք սկսեցինք վերլուծել, թե որտեղ է անցկացնում Tableau-ն իր ժամանակի մեծ մասը: Եվ դրա համար կան բավականին լավ գործիքներ, ինչը, իհարկե, Tableau-ի պլյուսն է։ Հիմնական խնդիրը, որը մենք բացահայտեցինք, շատ բարդ SQL հարցումներն էին, որոնք կառուցում էր Tableau-ն: Դրանք հիմնականում կապված էին.

- տվյալների փոխանցում: Քանի որ Tableau-ն չունի տվյալների հավաքածուների փոխադրման գործիքներ, վահանակի ձախ կողմը բոլոր KPI-ների մանրամասն ներկայացմամբ կառուցելու համար մենք պետք է աղյուսակ ստեղծեինք՝ օգտագործելով պատյան: SQL հարցումների չափը տվյալների բազայում հասել է 120 նիշի:

- ժամանակաշրջանի ընտրություն. Տվյալների բազայի մակարդակում նման հարցումը կազմելու համար ավելի շատ ժամանակ պահանջվեց, քան կատարման համար.

Նրանք. հարցումների մշակում 12 վայրկյան + 5 վայրկյան կատարում:

Մենք որոշեցինք պարզեցնել Tableau-ի կողմից հաշվարկների տրամաբանությունը և հաշվարկների մեկ այլ մասը տեղափոխել ցուցափեղկի և տվյալների բազայի մակարդակ: Սա լավ արդյունքներ բերեց։

Նախ, մենք կատարեցինք փոխադրումը անմիջապես, մենք դա արեցինք ամբողջական արտաքին միացման միջոցով VIEW հաշվարկի վերջնական փուլում, ըստ վիքիում նկարագրված այս մոտեցման: Transpose - Վիքիպեդիա, ազատ հանրագիտարան и Տարրական մատրիցա - Վիքիպեդիա, ազատ հանրագիտարան.

Այսինքն, մենք կազմեցինք պարամետրերի աղյուսակ՝ տրանսպոզիցիոն մատրիցա (21x21) և ստացանք բոլոր ցուցիչները տող առ տող:

էր.


Դարձավ՝


Գրեթե ժամանակ չի ծախսվում տվյալների բազայի փոխադրման վրա: Շաբաթվա բոլոր ցուցանիշների հարցումը շարունակվել է մշակվել մոտ 10 վայրկյանում։ Բայց մյուս կողմից, ճկունությունը կորել է կոնկրետ ցուցանիշի հիման վրա վահանակ կառուցելու առումով, այսինքն. վահանակի աջ կողմի համար, որտեղ ներկայացված է կոնկրետ ցուցիչի դինամիկան և մանրամասն վերլուծությունը, նախկինում ցուցափեղկն աշխատում էր 1-3 վայրկյանում, քանի որ. հարցումը հիմնված էր մեկ ցուցիչի վրա, և այժմ տվյալների բազան միշտ ընտրում էր բոլոր ցուցիչները և զտում արդյունքը՝ նախքան արդյունքը Tableau վերադարձնելը:

Արդյունքում վահանակի արագությունը նվազել է գրեթե 3 անգամ։

Արդյունքը:

1. 5 վրկ – վահանակների վերլուծություն, վիզուալիզացիա
2. 15-20 վայրկյան - նախապատրաստություն Tableau-ում նախնական հաշվարկներով հարցումներ կազմելու համար
3. 35-45 վրկ - SQL հարցումների հավաքում և դրանց զուգահեռ հաջորդական կատարում Հանա-ում
4. 5 վրկ – արդյունքների մշակում, տեսակավորում, պատկերացումների վերահաշվարկ Tableau-ում
5. Իհարկե, նման արդյունքները չեն սազում բիզնեսին, և մենք շարունակեցինք օպտիմալացումը։

Փուլ 2. Նվազագույն տրամաբանություն Tableau-ում, ամբողջական նյութականացում

Մենք հասկացանք, որ անհնար է մի քանի վայրկյան արձագանքման ժամանակով ցուցատախտակ ստեղծել ցուցափեղկի վրա, որն աշխատում է 10 վայրկյան, և մենք դիտարկեցինք տվյալների բազայի կողմից տվյալների նյութականացման տարբերակները՝ հատուկ պահանջվող վահանակի համար: Բայց մենք հանդիպեցինք վերը նկարագրված գլոբալ խնդրի՝ ոչ հավելյալ ցուցանիշների։ Մենք չկարողացանք համոզվել, որ ֆիլտրերը կամ զտիչները փոխելիս Tableau-ն ճկուն կերպով անցում է կատարում տարբեր ցուցափեղկերի և տարբեր ապրանքների հիերարխիայի համար նախապես մշակված մակարդակների միջև (օրինակ՝ երեք հարցում առանց UTE-ի, UTE1-ով և UTE2-ով տարբեր արդյունքներ են ստեղծում): Հետևաբար, մենք որոշեցինք պարզեցնել վահանակը, հրաժարվել արտադրանքի հիերարխիայից վահանակում և տեսնել, թե որքան արագ այն կարող է լինել պարզեցված տարբերակում:

Այսպիսով, այս վերջին փուլում մենք հավաքեցինք առանձին պահոց, որտեղ ավելացրինք բոլոր KPI-ները փոխակերպված տեսքով: Տվյալների բազայի կողմից նման պահեստի ցանկացած հարցում մշակվում է 0,1 - 0,3 վայրկյանում: Վահանակի վրա մենք ստացանք հետևյալ արդյունքները.

Առաջին բացումը` 8-10 վայրկյան
Ցանկացած սեղմում` 6-7 վայրկյան

Tableau-ի անցկացրած ժամանակը բաղկացած է.

1. 0,3 վրկ. — վահանակի վերլուծություն և SQL հարցումների կազմում
2. 1,5-3 վրկ. — SQL հարցումների կատարում Hana-ում հիմնական վիզուալիզացիաների համար (գործում է քայլ 1-ին զուգահեռ)
3. 1,5-2 վրկ. — արտացոլում, պատկերացումների վերահաշվարկ
4. 1,3 վրկ. - լրացուցիչ SQL հարցումների կատարում՝ համապատասխան ֆիլտրի արժեքներ ստանալու համար (ապրանքանիշ, բաժին, քաղաք, խանութ), վերլուծության արդյունքներ

Համառոտ ամփոփելու համար

Մեզ դուր եկավ Tableau գործիքը վիզուալիզացիայի տեսանկյունից: Նախատիպային փուլում մենք դիտարկեցինք տարբեր վիզուալացման տարրեր և գտանք դրանք բոլորը գրադարաններում, ներառյալ բարդ բազմամակարդակ հատվածավորումը և բազմաշերտ ջրվեժը:

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

1. Tableau-ն չի կարող աշխատել մեծ քանակությամբ տվյալների հետ: Եթե ​​տվյալների սկզբնական մոդելում դուք ունեք 10 ԳԲ-ից ավելի տվյալներ (մոտ 200 միլիոն X 50 տող), ապա վահանակը լրջորեն կդանդաղի` յուրաքանչյուր սեղմման համար 10 վայրկյանից մինչև մի քանի րոպե: Մենք փորձարկեցինք ինչպես կենդանի կապի, այնպես էլ էքստրակտի հետ: Գործողության արագությունը համեմատելի է:
2. Սահմանափակում մի քանի պահեստներ (տվյալների հավաքածուներ) օգտագործելիս: Չկա ստանդարտ միջոցների միջոցով տվյալների հավաքածուների միջև կապը ցույց տալու միջոց: Եթե ​​դուք լուծումներ եք օգտագործում տվյալների հավաքածուները միացնելու համար, դա մեծապես կազդի աշխատանքի վրա: Մեր դեպքում մենք դիտարկեցինք տվյալների նյութականացման տարբերակը յուրաքանչյուր պահանջվող դիտման բաժնում և անջատիչներ անելու այս նյութականացված տվյալների հավաքածուները՝ պահպանելով նախկինում ընտրված զտիչները, ինչը անհնարին դարձավ Tableau-ում:
3. Հնարավոր չէ դինամիկ պարամետրեր կատարել Tableau-ում: Դուք չեք կարող լրացնել պարամետրը, որն օգտագործվում է տվյալների հավաքակազմը զտելու համար քաղվածքում կամ ուղիղ միացման ընթացքում տվյալների հավաքածուից մեկ այլ ընտրության կամ մեկ այլ SQL հարցման արդյունքի հետ, միայն օգտատիրոջ մուտքագրում կամ հաստատուն:
4. Սահմանափակումներ՝ կապված OLAP|PivotTable տարրերով վահանակ ստեղծելու հետ:
   MSTR-ում, SAP SAC-ում, SAP Analysis-ում, եթե դուք տվյալների բազա եք ավելացնում զեկույցին, ապա դրա վրա գտնվող բոլոր օբյեկտները լռելյայնորեն կապված են միմյանց հետ: Tableau-ում սա չկա, կապը պետք է կարգավորվի ձեռքով: Սա, հավանաբար, ավելի ճկուն է, բայց մեր բոլոր վահանակների համար սա պարտադիր պահանջ է տարրերի համար, ուստի սա լրացուցիչ աշխատանքային ծախսեր է: Ավելին, եթե դուք պատրաստում եք համապատասխան զտիչներ, որպեսզի, օրինակ, տարածաշրջանը զտելիս, քաղաքների ցանկը սահմանափակվի միայն այս տարածաշրջանի քաղաքներով, դուք անմիջապես հայտնվում եք տվյալների բազայում կամ Extract-ի հաջորդական հարցումներով, ինչը նկատելիորեն դանդաղեցնում է վահանակ.
5. Գործառույթների սահմանափակումներ. Զանգվածային փոխակերպումներ չեն կարող կատարվել ոչ քաղվածքի վրա, ոչ էլ, ՀԱՏԿԱՊԵՍ, Live-connecta-ի տվյալների բազայի վրա: Սա կարելի է անել Tableau Prep-ի միջոցով, բայց դա լրացուցիչ աշխատանք է և ևս մեկ գործիք սովորելու և պահպանելու համար: Օրինակ, դուք չեք կարող փոխանցել տվյալները կամ միացնել դրանք ինքնին: Ինչը փակվում է առանձին սյունակների կամ դաշտերի փոխակերպումների միջոցով, որոնք պետք է ընտրվեն case-ի կամ if-ի միջոցով, և դա առաջացնում է շատ բարդ SQL հարցումներ, որոնցում տվյալների բազան իր ժամանակի մեծ մասը ծախսում է հարցման տեքստը կազմելու վրա: Գործիքի այս անճկունությունը պետք է լուծվեր ցուցադրական մակարդակում, ինչը հանգեցնում է ավելի բարդ պահեստավորման, լրացուցիչ ներբեռնումների և փոխակերպումների:

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

Այժմ մենք ակտիվորեն մշակում ենք նմանատիպ վահանակ մեկ այլ գործիքի մեջ և, միևնույն ժամանակ, փորձում ենք վերանայել վահանակի ճարտարապետությունը Tableau-ում՝ այն էլ ավելի պարզեցնելու համար: Եթե ​​համայնքը հետաքրքրված է, մենք ձեզ կասենք արդյունքների մասին:

Մենք նաև սպասում ենք ձեր գաղափարներին կամ խորհուրդներին, թե ինչպես կարող եք Tabeau-ում արագ վահանակներ ստեղծել նման մեծ ծավալների տվյալների վրա, քանի որ մենք ունենք կայք, որտեղ շատ ավելի շատ տվյալներ կան, քան մանրածախ:

Source: www.habr.com