ტაბლო საცალო ვაჭრობაში, მართლა?

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: რწმენა ტაბლოში

IT მხარდაჭერის გასამარტივებლად და ცვლილებების სწრაფად განხორციელებისთვის, ჩვენ გადავწყვიტეთ შეგვექმნა არადამატებითი ინდიკატორების გამოანგარიშების ლოგიკა და გასული პერიოდების შედარება Tableau-ში.

ეტაპი 1. ყველაფერი ცოცხალია, ფანჯრის ცვლილებების გარეშე.

ამ ეტაპზე Tableau დავუკავშირეთ ახლანდელ ვიტრინებს და გადავწყვიტეთ გვენახა, როგორ გამოითვლებოდა ქვითრების რაოდენობა ერთი წლის განმავლობაში.

შედეგი:

პასუხი დამთრგუნველი იყო - 20 წუთი. მონაცემთა გადაცემა ქსელში, მაღალი დატვირთვა Tableau-ზე. ჩვენ მივხვდით, რომ არადამატებითი ინდიკატორების ლოგიკა უნდა განხორციელდეს HANA-ზე. ამან დიდად არ შეგვაშინა, ჩვენ უკვე გვქონდა მსგავსი გამოცდილება BO-სთან და ანალიზთან დაკავშირებით და ვიცოდით, როგორ აგვეშენებინა სწრაფი ვიტრინები HANA-ში, რომლებიც აწარმოებენ სწორად გათვლილ არადამატებით ინდიკატორებს. ახლა დარჩა მხოლოდ მათი ტაბლოზე მორგება.

ეტაპი 2. ჩვენ ვაწყობთ ვიტრინებს, არ არის მატერიალიზებული, ყველაფერი მიდის.

ჩვენ შევქმენით ცალკე ახალი ვიტრინა, რომელიც აწარმოებდა საჭირო მონაცემებს TABLEAU-სთვის. ზოგადად, კარგი შედეგი მივიღეთ, ერთ კვირაში ყველა ინდიკატორის გენერირების დრო 9-10 წამამდე შევამცირეთ. და ჩვენ გულწრფელად ველოდით, რომ Tableau-ში დაფის რეაგირების დრო პირველ გახსნაზე იქნებოდა 20-30 წამი, შემდეგ კი ქეშის გამო 10-დან 12-მდე, რაც ზოგადად მოგვწონს.

შედეგი:

პირველი გახსნილი დაფა: 4-5 წუთი
ნებისმიერი დაწკაპუნება: 3-4 წუთი
ვიტრინის მუშაობის ასეთ დამატებით ზრდას არავინ ელოდა.

ნაწილი 2. ჩაყვინთვის ტაბლოში

ეტაპი 1. Tableau შესრულების ანალიზი და სწრაფი tuning

დავიწყეთ იმის ანალიზი, თუ სად ატარებს 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-ს არ აქვს ეს; კავშირი ხელით უნდა იყოს კონფიგურირებული. ეს, ალბათ, უფრო მოქნილია, მაგრამ ჩვენი ყველა დაფისთვის ეს ელემენტებისთვის სავალდებულო მოთხოვნაა - ასე რომ, ეს არის დამატებითი შრომის ხარჯები. უფრო მეტიც, თუ თქვენ გააკეთებთ დაკავშირებულ ფილტრებს ისე, რომ, მაგალითად, რეგიონის გაფილტვრისას, ქალაქების სია შემოიფარგლება მხოლოდ ამ რეგიონის ქალაქებით, თქვენ დაუყოვნებლივ ასრულებთ თანმიმდევრულ შეკითხვებს მონაცემთა ბაზაში ან ამონაწერში, რაც შესამჩნევად ანელებს დაფა.
5. შეზღუდვები ფუნქციებში. მასობრივი ტრანსფორმაციები არ შეიძლება განხორციელდეს არც ამონაწერზე და არც, განსაკუთრებით, მონაცემთა ბაზაზე Live-connecta-დან. ეს შეიძლება გაკეთდეს Tableau Prep-ის საშუალებით, მაგრამ ეს არის დამატებითი სამუშაო და კიდევ ერთი ინსტრუმენტი შესასწავლად და შესანარჩუნებლად. მაგალითად, თქვენ არ შეგიძლიათ მონაცემების ტრანსპონირება ან მათი შეერთება. რა იხურება ტრანსფორმაციების მეშვეობით ცალკეულ სვეტებზე ან ველებზე, რომლებიც უნდა იყოს შერჩეული ქეისით ან თუ, და ეს წარმოქმნის ძალიან რთულ SQL შეკითხვებს, რომლებშიც მონაცემთა ბაზა დროის უმეტეს ნაწილს ხარჯავს მოთხოვნის ტექსტის შედგენაზე. ხელსაწყოს ეს მოუქნელობა უნდა მოგვარებულიყო გამოფენის დონეზე, რაც იწვევს უფრო რთულ შენახვას, დამატებით ჩამოტვირთვებს და ტრანსფორმაციას.

ჩვენ არ დავთმობთ Tableau-ზე. მაგრამ ჩვენ არ განვიხილავთ Tableau-ს, როგორც ინსტრუმენტს, რომელსაც შეუძლია შექმნას სამრეწველო დაფები და ინსტრუმენტი, რომლითაც შეიცვლება და ციფრული გახდება კომპანიის მთელი კორპორატიული ანგარიშგების სისტემა.

ახლა ჩვენ აქტიურად ვამუშავებთ მსგავს დაფის სხვა ინსტრუმენტს და, ამავე დროს, ვცდილობთ გადახედოთ დაფის არქიტექტურას Tableau-ში, რათა კიდევ უფრო გავამარტივოთ იგი. თუ საზოგადოება დაინტერესდება, შედეგებს მოგიყვებით.

ჩვენ ასევე ველოდებით თქვენს იდეებს ან რჩევებს იმის შესახებ, თუ როგორ შეგიძლიათ Tabeau-ში შექმნათ სწრაფი დაფები მონაცემთა ამხელა მოცულობებზე, რადგან ჩვენ გვაქვს ვებსაიტი, სადაც გაცილებით მეტი მონაცემია, ვიდრე საცალო ვაჭრობაში.

წყარო: www.habr.com