खुद्रा मा झांकी, साँच्चै?

एक्सेलमा रिपोर्टिङको लागि समय द्रुत रूपमा गायब हुँदैछ - जानकारी प्रस्तुत गर्न र विश्लेषण गर्नका लागि सुविधाजनक उपकरणहरू तर्फ प्रवृत्ति सबै क्षेत्रमा देखिन्छ। हामीले लामो समयदेखि रिपोर्टिङको डिजिटलाइजेशनको बारेमा आन्तरिक रूपमा छलफल गर्दै आएका छौं र टेबुल भिजुअलाइजेशन र सेल्फ-सर्भिस एनालिटिक्स प्रणाली रोजेका छौं। एम.भिडियो-एल्डोराडो समूहको विश्लेषणात्मक समाधान र रिपोर्टिङ विभागका प्रमुख अलेक्जेन्डर बेजुग्लीले लडाई ड्यासबोर्ड निर्माण गर्ने अनुभव र नतिजाहरूको बारेमा कुरा गरे।

म तुरुन्तै भन्छु कि योजना गरिएको सबै कुरा साकार भएन, तर अनुभव चाखलाग्दो थियो, मलाई आशा छ कि यो तपाईलाई पनि उपयोगी हुनेछ। र यदि कसैलाई यो कसरी राम्रो गर्न सकिन्छ भन्ने बारे कुनै विचार छ भने, म तपाईंको सल्लाह र विचारहरूको लागि धेरै आभारी हुनेछु।

कट तल हामीले के सामना गर्यौं र हामीले के सिक्यौं भन्ने बारे छ।

हामीले कहाँ सुरु गर्यौं?

M.Video-Eldorado सँग राम्रोसँग विकसित डाटा मोडेल छ: आवश्यक भण्डारण गहिराइ र निश्चित-फार्म रिपोर्टहरूको ठूलो संख्याको साथ संरचित जानकारी (थप विवरणहरू हेर्नुहोस् यो लेख)। यिनीहरूबाट, विश्लेषकहरूले या त पिभोट तालिकाहरू वा एक्सेलमा ढाँचाबद्ध न्यूजलेटरहरू, वा अन्त प्रयोगकर्ताहरूको लागि सुन्दर PowerPoint प्रस्तुतीकरणहरू बनाउँछन्।

लगभग दुई वर्ष पहिले, निश्चित-फारम रिपोर्टहरूको सट्टा, हामीले SAP विश्लेषणमा विश्लेषणात्मक रिपोर्टहरू सिर्जना गर्न थाल्यौं (एक एक्सेल एड-अन, अनिवार्य रूपमा OLAP इन्जिनमा पिभोट तालिका)। तर यो उपकरणले सबै प्रयोगकर्ताहरूको आवश्यकताहरू पूरा गर्न सक्षम भएन; अधिकांशले विश्लेषकहरूद्वारा प्रशोधित जानकारीहरू प्रयोग गर्न जारी राखे।

हाम्रा अन्तिम प्रयोगकर्ताहरू तीन कोटिमा पर्छन्:

शीर्ष व्यवस्थापन। राम्रोसँग प्रस्तुत र स्पष्ट रूपमा बुझ्न योग्य तरिकामा जानकारी अनुरोध गर्दछ।

मध्य व्यवस्थापन, उन्नत प्रयोगकर्ताहरू। डाटा अन्वेषणमा रुचि छ र यदि उपकरणहरू उपलब्ध छन् भने स्वतन्त्र रूपमा रिपोर्टहरू निर्माण गर्न सक्षम छन्। तिनीहरू SAP विश्लेषणमा विश्लेषणात्मक रिपोर्टहरूको प्रमुख प्रयोगकर्ता बने।

आम प्रयोगकर्ताहरू। तिनीहरू स्वतन्त्र रूपमा डेटा विश्लेषणमा रुचि राख्दैनन्; तिनीहरूले एक्सेलमा न्यूजलेटरहरू र पिभोट तालिकाहरूको ढाँचामा सीमित स्वतन्त्रताका साथ रिपोर्टहरू प्रयोग गर्छन्।

हाम्रो विचार सबै प्रयोगकर्ताहरूको आवश्यकताहरू कभर गर्ने र तिनीहरूलाई एकल, सुविधाजनक उपकरण दिनु थियो। हामीले शीर्ष व्यवस्थापनबाट सुरु गर्ने निर्णय गर्यौं। तिनीहरूलाई प्रमुख व्यापार परिणामहरू विश्लेषण गर्न प्रयोग गर्न सजिलो ड्यासबोर्डहरू चाहिन्छ। त्यसोभए, हामीले Tableau को साथ सुरु गर्यौं र पहिले दुई दिशाहरू छनौट गर्‍यौं: सीमित गहिराइ र विश्लेषणको चौडाइका साथ खुद्रा र अनलाइन बिक्री सूचकहरू, जसले शीर्ष व्यवस्थापनद्वारा अनुरोध गरिएको डेटाको लगभग 80% कभर गर्नेछ।

ड्यासबोर्डका प्रयोगकर्ताहरू शीर्ष व्यवस्थापन भएकोले, उत्पादनको अर्को अतिरिक्त KPI देखा पर्‍यो - प्रतिक्रिया गति। डाटा अपडेट हुनको लागि कसैले 20-30 सेकेन्ड पर्खने छैन। नेभिगेसन 4-5 सेकेन्ड भित्र, वा अझ राम्रो, तुरुन्तै गरिसक्नुपर्छ। र, हामी यो हासिल गर्न असफल भयौं।

हाम्रो मुख्य ड्यासबोर्डको लेआउट यस्तो देखिन्छ:

मुख्य विचार भनेको मुख्य KPI ड्राइभरहरू संयोजन गर्नु हो, जसमध्ये कुल 19 थिए, बाँयामा र तिनीहरूको गतिशीलता र दायाँमा मुख्य विशेषताहरूद्वारा ब्रेकडाउन प्रस्तुत गर्ने। कार्य सरल देखिन्छ, भिजुअलाइजेसन तार्किक र बुझ्न योग्य छ, जब सम्म तपाईं विवरणहरूमा डुब्नुहुन्न।

विवरण १. डाटा भोल्युम

वार्षिक बिक्रीको लागि हाम्रो मुख्य तालिकाले लगभग 300 मिलियन पङ्क्तिहरू लिन्छ। गत वर्ष र अघिल्लो वर्षको लागि गतिशीलता प्रतिबिम्बित गर्न आवश्यक भएकोले, वास्तविक बिक्रीमा मात्र डाटाको मात्रा लगभग 1 बिलियन लाइनहरू हो। योजनाबद्ध डाटा र अनलाइन बिक्री ब्लक मा जानकारी पनि अलग भण्डारण गरिएको छ। त्यसकारण, हामीले स्तम्भ इन-मेमोरी DB SAP HANA प्रयोग गरे पनि, फ्लाईमा हालको भण्डारणबाट एक हप्ताको लागि सबै सूचकहरूको चयनको साथ क्वेरीको गति लगभग 15-20 सेकेन्ड थियो। यस समस्याको समाधान आफैले सुझाव दिन्छ - डाटाको अतिरिक्त भौतिकीकरण। तर यसमा कमजोरीहरू पनि छन्, तल तिनीहरूको बारेमा थप।

विवरण 2. गैर-जोडक सूचकहरू

हाम्रा धेरै KPI हरू रसिदहरूको संख्यासँग जोडिएका छन्। र यो सूचकले पङ्क्तिहरूको संख्याको COUNT DISTINCT प्रतिनिधित्व गर्दछ (हेडरहरू जाँच गर्नुहोस्) र चयन गरिएका विशेषताहरूको आधारमा फरक मात्राहरू देखाउँदछ। उदाहरणका लागि, कसरी यो सूचक र यसको व्युत्पन्न गणना गर्नुपर्छ:

आफ्नो गणना सही बनाउन, तपाईं सक्नुहुन्छ:

• भण्डारणमा उडानमा त्यस्ता संकेतकहरू गणना गर्नुहोस्;
• Tableau मा डाटा को सम्पूर्ण मात्रा मा गणना प्रदर्शन गर्नुहोस्, अर्थात्। Tableau मा अनुरोध गरेपछि, रसीद स्थितिको ग्रेन्युलारिटीमा चयन गरिएका फिल्टरहरू अनुसार सबै डेटा प्रदान गर्नुहोस्;
• एउटा भौतिक शोकेस सिर्जना गर्नुहोस् जसमा सबै सूचकहरू सबै नमूना विकल्पहरूमा गणना गरिनेछ जसले विभिन्न गैर-जोडक परिणामहरू दिन्छ।

यो स्पष्ट छ कि उदाहरणमा UTE1 र UTE2 उत्पादन पदानुक्रम प्रतिनिधित्व गर्ने भौतिक विशेषताहरू हुन्। यो एक स्थिर कुरा होइन; कम्पनी भित्र व्यवस्थापन यसको माध्यमबाट लिन्छ, किनभने विभिन्न प्रबन्धकहरू विभिन्न उत्पादन समूहहरूको लागि जिम्मेवार छन्। हामीसँग यस पदानुक्रमको धेरै विश्वव्यापी संशोधनहरू थिए, जब सबै स्तरहरू परिवर्तन भए, जब सम्बन्धहरू परिमार्जन गरियो, र निरन्तर बिन्दु परिवर्तनहरू, जब एक समूह एक नोडबाट अर्कोमा सर्यो। परम्परागत रिपोर्टिङमा, यो सबै सामग्रीको विशेषताहरूबाट उडानमा गणना गरिन्छ; यस डेटाको भौतिकीकरणको अवस्थामा, त्यस्ता परिवर्तनहरू ट्र्याक गर्न र ऐतिहासिक डेटा स्वचालित रूपमा पुन: लोड गर्ने संयन्त्र विकास गर्न आवश्यक छ। एक धेरै गैर मामूली कार्य।

विवरण 3. डेटा तुलना

यो बिन्दु अघिल्लो एक जस्तै छ। तल्लो रेखा यो हो कि एक कम्पनी को विश्लेषण गर्दा, यो अघिल्लो अवधि संग तुलना को धेरै स्तरहरु गठन गर्न को लागी प्रथागत छ:

अघिल्लो अवधिसँग तुलना गर्नुहोस् (दिनदेखि दिन, हप्तादेखि हप्ता, महिनादेखि महिना)

यस तुलनामा, यो मानिन्छ कि प्रयोगकर्ता द्वारा चयन गरिएको अवधि (उदाहरणका लागि, वर्षको 33 औं हप्ता), हामीले 32 औं हप्तामा गतिशीलता देखाउनुपर्छ; यदि हामीले एक महिनाको लागि डेटा चयन गर्यौं भने, उदाहरणका लागि, मे , त्यसपछि यो तुलनाले अप्रिल सम्म गतिशीलता देखाउनेछ।

गत वर्षको तुलना

यहाँको मुख्य कुरा यो हो कि दिन र हप्ताको तुलना गर्दा, तपाईंले गत वर्षको उही दिन लिइरहनुभएको छैन, अर्थात्। तपाईले हालको वर्षलाई माइनस एक मात्र राख्न सक्नुहुन्न। तपाईंले तुलना गरिरहनुभएको हप्ताको दिन हेर्नु पर्छ। महिनाहरू तुलना गर्दा, यसको विपरित, तपाईंले गत वर्षको समान क्यालेन्डर दिन लिन आवश्यक छ। त्यहाँ छलांग वर्ष संग बारीकियों पनि छन्। मौलिक भण्डारहरूमा, सबै जानकारी दिनमा वितरित गरिन्छ; त्यहाँ हप्ता, महिना, वा वर्षहरूसँग कुनै छुट्टै क्षेत्रहरू छैनन्। तसर्थ, प्यानलमा पूर्ण विश्लेषणात्मक क्रस-सेक्शन प्राप्त गर्न, तपाईंले एक अवधि, उदाहरणका लागि एक हप्ता, तर 4 हप्ता गणना गर्न आवश्यक छ, र त्यसपछि यी डेटा तुलना गर्नुहोस्, गतिशीलता, विचलनहरू प्रतिबिम्बित गर्नुहोस्। तदनुसार, गतिशीलतामा तुलनाहरू उत्पन्न गर्नको लागि यो तर्क पनि या त Tableau मा वा स्टोरफ्रन्ट साइडमा लागू गर्न सकिन्छ। हो, र पक्कै पनि हामीले डिजाइन चरणमा यी विवरणहरूको बारेमा थाहा पाएका थियौं र सोच्यौं, तर अन्तिम ड्यासबोर्डको प्रदर्शनमा तिनीहरूको प्रभावको भविष्यवाणी गर्न गाह्रो थियो।

ड्यासबोर्ड कार्यान्वयन गर्दा, हामीले लामो चुस्त बाटो पछ्यायौं। हाम्रो काम सकेसम्म चाँडो परीक्षणको लागि आवश्यक डाटाको साथ काम गर्ने उपकरण प्रदान गर्नु थियो। त्यसकारण, हामी स्प्रिन्टहरूमा गयौं र हालको भण्डारणको छेउमा काम कम गर्नबाट सुरु गर्यौं।

भाग १: टेबुलमा विश्वास

IT समर्थनलाई सरल बनाउन र परिवर्तनहरू द्रुत रूपमा कार्यान्वयन गर्न, हामीले गैर-जोडक संकेतकहरू गणना गर्न र Tableau मा विगतका अवधिहरू तुलना गर्ने तर्क बनाउने निर्णय गर्यौं।

चरण 1. सबै कुरा प्रत्यक्ष छ, कुनै विन्डो परिमार्जन छैन।

यस चरणमा, हामीले हालको स्टोरफ्रन्टहरूमा Tableau लाई जोड्यौं र कसरी एक वर्षको लागि प्राप्तिहरूको संख्या गणना गरिनेछ भनेर हेर्ने निर्णय गर्यौं।

परिणाम:

जवाफ निराशाजनक थियो - 20 मिनेट। नेटवर्क मा डाटा को स्थानान्तरण, Tableau मा उच्च लोड। हामीले महसुस गर्यौं कि HANA मा गैर-जोडक सूचकहरू सहितको तर्क लागू गर्न आवश्यक छ। यसले हामीलाई धेरै डराएको छैन, हामीसँग पहिले नै BO र विश्लेषणको समान अनुभव थियो र हामीलाई HANA मा द्रुत शोकेसहरू कसरी निर्माण गर्ने भनेर थाहा थियो जसले सही रूपमा गणना गरिएको गैर-अॅडिटिभ सूचकहरू उत्पादन गर्दछ। अब के बाँकी थियो तिनीहरूलाई Tableau मा समायोजन गर्न थियो।

स्टेज २। हामी डिस्प्ले केसहरू ट्युन गर्छौं, कुनै भौतिकीकरण, उडानमा सबै कुरा।

हामीले एउटा छुट्टै नयाँ शोकेस सिर्जना गर्यौं जसले उडानमा TABLEAU को लागि आवश्यक डेटा उत्पादन गर्‍यो। सामान्यतया, हामीले राम्रो नतिजा पायौं; हामीले एक हप्तामा सबै सूचकहरू उत्पन्न गर्ने समयलाई 9-10 सेकेन्डमा घटाएका छौं। र हामीले इमानदारीपूर्वक आशा गरेका थियौं कि टेबुलमा ड्यासबोर्डको प्रतिक्रिया समय पहिलो उद्घाटनमा 20-30 सेकेन्ड हुनेछ र त्यसपछि 10 देखि 12 सम्म क्यासको कारणले, जुन सामान्यतया हामीलाई उपयुक्त हुनेछ।

परिणाम:

पहिलो खुला ड्यासबोर्ड: 4-5 मिनेट
कुनै पनि क्लिक: 3-4 मिनेट
स्टोरफ्रन्टको काममा यस्तो थप बृद्धिको आशा कसैले पनि गरेको थिएन।

भाग २. झाँकीमा डुब्नुहोस्

चरण 1. झाँकी प्रदर्शन विश्लेषण र द्रुत ट्युनिङ

हामीले विश्लेषण गर्न थाल्यौं कि Tableau ले आफ्नो अधिकांश समय कहाँ बिताउँछ। र त्यहाँ यसका लागि धेरै राम्रो उपकरणहरू छन्, जुन निस्सन्देह, Tableau को एक प्लस हो। हामीले पहिचान गरेको मुख्य समस्या धेरै जटिल SQL प्रश्नहरू थियो जुन Tableau निर्माण गरिरहेको थियो। तिनीहरू मुख्य रूपमा सम्बन्धित थिए:

- डाटा ट्रान्सपोजिसन। Tableau सँग डाटासेटहरू ट्रान्सपोज गर्नका लागि उपकरणहरू नभएकोले, सबै KPIs को विस्तृत प्रतिनिधित्वको साथ ड्यासबोर्डको बायाँ छेउ निर्माण गर्न, हामीले केस प्रयोग गरेर तालिका बनाउनुपर्यो। डाटाबेसमा SQL क्वेरीहरूको आकार 120 वर्णहरूमा पुग्यो।

- समय अवधि छनोट गर्दै। डाटाबेस स्तरमा यस्तो क्वेरी कार्यान्वयन गर्न भन्दा कम्पाइल गर्न धेरै समय लाग्यो:

ती। अनुरोध प्रशोधन १२ सेकेन्ड + ५ सेकेन्ड कार्यान्वयन।

हामीले Tableau साइडमा गणना तर्कलाई सरल बनाउने र गणनाको अर्को भागलाई स्टोरफ्रन्ट र डाटाबेस स्तरमा सार्ने निर्णय गर्यौं। यसले राम्रो नतिजा ल्यायो।

पहिले, हामीले फ्लाईमा ट्रान्सपोजिसन गर्यौं, हामीले यो विकिमा वर्णन गरिएको दृष्टिकोण अनुसार, दृश्य गणनाको अन्तिम चरणमा पूर्ण बाहिरी जडान मार्फत गर्यौं। ट्रान्सपोज - विकिपीडिया, मुक्त विश्वकोश и प्राथमिक म्याट्रिक्स - विकिपीडिया, मुक्त विश्वकोश.

त्यो हो, हामीले सेटिङ तालिका बनायौं - एक ट्रान्सपोजिसन म्याट्रिक्स (21x21) र पङ्क्ति-द्वारा-पङ्क्ति ब्रेकडाउनमा सबै सूचकहरू प्राप्त गर्‍यौं।

थियो:


यो भयो:


डाटाबेस ट्रान्सपोजिसनमा लगभग कुनै समय खर्च हुँदैन। हप्ताको लागि सबै सूचकहरूको लागि अनुरोध लगभग 10 सेकेन्डमा प्रशोधन गर्न जारी रह्यो। तर अर्कोतर्फ, विशेष सूचकमा आधारित ड्यासबोर्ड निर्माण गर्ने सन्दर्भमा लचिलोपन हराएको छ, अर्थात्। ड्यासबोर्डको दायाँ छेउको लागि जहाँ गतिशीलता र विशिष्ट सूचकको विस्तृत ब्रेकडाउन प्रस्तुत गरिन्छ, पहिले डिस्प्ले केस १-३ सेकेन्डमा काम गर्दथ्यो, किनभने अनुरोध एउटा सूचकमा आधारित थियो, र अब डाटाबेसले सँधै सबै सूचकहरू छनोट गर्‍यो र परिणामलाई Tableau मा फर्काउनु अघि परिणाम फिल्टर गर्‍यो।

फलस्वरूप, ड्यासबोर्डको गति लगभग 3 गुणाले घट्यो।

परिणाम:

1. 5 सेकेन्ड - ड्यासबोर्डहरू पार्स गर्दै, दृश्यहरू
2. 15-20 सेकेन्ड - Tableau मा पूर्व-गणना प्रदर्शन संग प्रश्न संकलन को लागी तयारी
3. 35-45 सेकेन्ड - SQL क्वेरीहरूको संकलन र हानामा तिनीहरूको समानान्तर-अनुक्रमिक कार्यान्वयन
4. 5 सेकेन्ड - प्रशोधन परिणामहरू, क्रमबद्ध, Tableau मा दृश्यहरू पुन: गणना
5. निस्सन्देह, त्यस्ता परिणामहरू व्यापार अनुरूप थिएन, र हामीले अनुकूलन जारी राख्यौं।

स्टेज २. टेबुलमा न्यूनतम तर्क, पूर्ण भौतिकीकरण

हामीले 10 सेकेन्डको लागि चल्ने स्टोरफ्रन्टमा धेरै सेकेन्डको प्रतिक्रिया समयको साथ ड्यासबोर्ड निर्माण गर्न असम्भव छ भनेर बुझ्यौं, र हामीले विशेष गरी आवश्यक ड्यासबोर्डको लागि डाटाबेस साइडमा डाटालाई भौतिक बनाउने विकल्पहरू विचार गर्यौं। तर हामीले माथि वर्णन गरिएको विश्वव्यापी समस्याको सामना गर्‍यौं - गैर-जोडक सूचकहरू। हामीले फिल्टरहरू वा ड्रिलडाउनहरू परिवर्तन गर्दा, Tableau लचिलो रूपमा विभिन्न उत्पादन पदानुक्रमहरूका लागि पूर्व-डिजाइन गरिएका विभिन्न स्टोरफ्रन्टहरू र स्तरहरू बीच स्विच गर्न सकेनौं (उदाहरणका लागि, UTE बिना तीनवटा प्रश्नहरू, UTE1 र UTE2 सँग फरक परिणामहरू उत्पन्न हुन्छन्)। तसर्थ, हामीले ड्यासबोर्डलाई सरल बनाउने निर्णय गर्यौं, ड्यासबोर्डमा उत्पादन पदानुक्रम त्यागौं र सरलीकृत संस्करणमा यो कति छिटो हुन सक्छ हेर्नुहोस्।

त्यसोभए, यो अन्तिम चरणमा, हामीले एउटा छुट्टै भण्डार भेला गर्यौं जसमा हामीले सबै केपीआईहरू ट्रान्सपोज्ड फारममा थप्यौं। डाटाबेस पक्षमा, यस्तो भण्डारणको लागि कुनै पनि अनुरोध ०.१ - ०.३ सेकेन्डमा प्रशोधन गरिन्छ। ड्यासबोर्डमा हामीले निम्न परिणामहरू प्राप्त गर्यौं:

पहिलो उद्घाटन: 8-10 सेकेन्ड
कुनै पनि क्लिक: 6-7 सेकेन्ड

Tableau द्वारा बिताएको समय समावेश छ:

1. ०.३ सेकेन्ड - ड्यासबोर्ड पार्सिङ र SQL प्रश्नहरूको संकलन
2. १.५-३ सेकेन्ड - मुख्य भिजुअलाइजेसनको लागि हानामा SQL क्वेरीहरूको कार्यान्वयन (चरण 1,5 सँग समानान्तरमा चल्छ)
3. १.५-२ सेकेन्ड - प्रतिपादन, दृश्यहरूको पुन: गणना
4. १.३ सेकेन्ड - सान्दर्भिक फिल्टर मानहरू (ब्रान्ड, डिभिजन, शहर, स्टोर), पार्सिङ परिणामहरू प्राप्त गर्न अतिरिक्त SQL प्रश्नहरूको कार्यान्वयन।

छोटकरीमा भन्नुपर्दा

हामीले एक दृश्य परिप्रेक्ष्यबाट Tableau उपकरण मन पराउनुभयो। प्रोटोटाइपिङ चरणमा, हामीले विभिन्न भिजुअलाइजेशन तत्वहरू विचार गर्यौं र ती सबैलाई पुस्तकालयहरूमा भेट्टायौं, जटिल बहु-स्तर विभाजन र बहु-ड्राइभर झरना सहित।

मुख्य बिक्री सूचकहरूसँग ड्यासबोर्डहरू कार्यान्वयन गर्दा, हामीले प्रदर्शन कठिनाइहरूको सामना गर्यौं जुन हामीले अझै पार गर्न सकेनौं। हामीले दुई महिना भन्दा बढी समय बितायौं र कार्यात्मक रूपमा अपूर्ण ड्यासबोर्ड प्राप्त गर्‍यौं, जसको प्रतिक्रिया गति स्वीकार्य हुने कगारमा छ। र हामीले आफ्नै लागि निष्कर्ष निकाल्यौं:

1. Tableau डेटा को ठूलो मात्रा संग काम गर्न सक्दैन। यदि मूल डेटा मोडेलमा तपाईंसँग 10 GB भन्दा बढी डाटा (लगभग 200 मिलियन X 50 पङ्क्तिहरू) छ भने, त्यसपछि ड्यासबोर्ड गम्भीर रूपमा ढिलो हुनेछ - प्रत्येक क्लिकको लागि 10 सेकेन्डदेखि धेरै मिनेटसम्म। हामीले लाइभ-कनेक्ट र एक्स्ट्र्याक्ट दुवै प्रयोग गर्यौं। सञ्चालन गति तुलनात्मक छ।
2. धेरै भण्डारणहरू (डेटासेटहरू) प्रयोग गर्दा सीमा। मानक माध्यमहरू प्रयोग गरेर डेटासेटहरू बीचको सम्बन्धलाई संकेत गर्ने कुनै तरिका छैन। यदि तपाइँ डेटासेटहरू जडान गर्न समाधानहरू प्रयोग गर्नुहुन्छ भने, यसले कार्यसम्पादनलाई धेरै असर गर्नेछ। हाम्रो केसमा, हामीले प्रत्येक आवश्यक दृश्य खण्डमा डेटालाई भौतिक बनाउने र पहिले चयन गरिएका फिल्टरहरू सुरक्षित गर्दा यी भौतिक डेटासेटहरूमा स्विच गर्ने विकल्पलाई विचार गर्यौं - यो Tableau मा गर्न असम्भव भयो।
3. Tableau मा गतिशील प्यारामिटरहरू बनाउन सम्भव छैन। तपाईले एउटा प्यारामिटर भर्न सक्नुहुन्न जुन डेटासेटलाई एक्स्ट्र्याक्टमा वा लाइभ-कनेक्टको समयमा डेटासेटबाट अर्को चयनको परिणाम वा अर्को SQL क्वेरीको परिणामसँग फिल्टर गर्न प्रयोग गरिन्छ, केवल नेटिभ प्रयोगकर्ता इनपुट वा स्थिर।
4. OLAP|PivotTable तत्वहरूसँग ड्यासबोर्ड निर्माण गर्न सम्बन्धित सीमाहरू।
   MSTR, SAP SAC, SAP विश्लेषणमा, यदि तपाईंले रिपोर्टमा डेटासेट थप्नुभयो भने, त्यसमा भएका सबै वस्तुहरू पूर्वनिर्धारित रूपमा एकअर्कासँग सम्बन्धित हुन्छन्। Tableau मा यो छैन; जडान म्यानुअल रूपमा कन्फिगर हुनुपर्छ। यो सम्भवतः अधिक लचिलो छ, तर हाम्रा सबै ड्यासबोर्डहरूको लागि यो तत्वहरूको लागि अनिवार्य आवश्यकता हो - त्यसैले यो अतिरिक्त श्रम लागत हो। यसबाहेक, यदि तपाइँ सम्बन्धित फिल्टरहरू बनाउनुहुन्छ भने, उदाहरणका लागि, कुनै क्षेत्र फिल्टर गर्दा, शहरहरूको सूची यस क्षेत्रका शहरहरूमा मात्र सीमित छ, तपाइँ तुरुन्तै डाटाबेस वा एक्स्ट्र्याक्टमा क्रमिक प्रश्नहरूको साथ समाप्त हुन्छ, जसले उल्लेखनीय रूपमा ढिलो गर्दछ। ड्यासबोर्ड।
5. कार्यहरूमा सीमितताहरू। सामूहिक रूपान्तरणहरू या त एक्स्ट्र्याक्टमा गर्न सकिँदैन वा, विशेष गरी, Live-connecta बाट डेटासेटमा। यो Tableau Prep मार्फत गर्न सकिन्छ, तर यो अतिरिक्त काम र सिक्न र कायम राख्न अर्को उपकरण हो। उदाहरण को लागी, तपाईले डाटा ट्रान्सपोज गर्न सक्नुहुन्न वा यसलाई आफैसँग जोड्न सक्नुहुन्न। व्यक्तिगत स्तम्भ वा क्षेत्रहरूमा रूपान्तरणहरू मार्फत के बन्द हुन्छ, जुन केस वा यदि मार्फत चयन गर्नुपर्छ, र यसले धेरै जटिल SQL प्रश्नहरू उत्पन्न गर्छ, जसमा डाटाबेसले आफ्नो अधिकांश समय क्वेरी पाठ कम्पाइल गर्न खर्च गर्दछ। उपकरणको यी लचिलोपनलाई शोकेस स्तरमा समाधान गर्न आवश्यक थियो, जसले थप जटिल भण्डारण, अतिरिक्त डाउनलोडहरू र रूपान्तरणहरू निम्त्याउँछ।

हामीले टेबुलमा छोडेका छैनौं। तर हामी Tableau लाई औद्योगिक ड्यासबोर्डहरू निर्माण गर्न सक्षम उपकरण र कम्पनीको सम्पूर्ण कर्पोरेट रिपोर्टिङ प्रणालीलाई प्रतिस्थापन र डिजिटलाइज गर्ने उपकरणको रूपमा विचार गर्दैनौं।

हामी अब सक्रिय रूपमा अर्को उपकरणमा समान ड्यासबोर्ड विकास गर्दैछौं र, एकै समयमा, यसलाई अझ सरल बनाउन Tableau मा ड्यासबोर्ड आर्किटेक्चरलाई परिमार्जन गर्ने प्रयास गर्दैछौं। यदि समुदायले चासो राख्यो भने, हामी तपाईंलाई नतिजाहरूको बारेमा बताउनेछौं।

हामी Tabeau मा तपाईले यति ठूलो मात्रामा डाटाको द्रुत ड्यासबोर्डहरू कसरी निर्माण गर्न सक्नुहुन्छ भन्ने बारे तपाईको विचार वा सल्लाहको लागि पनि पर्खिरहेका छौं, किनकि हामीसँग एउटा वेबसाइट छ जहाँ रिटेलमा भन्दा धेरै डाटा छ।

स्रोत: www.habr.com