खुदरा बिक्री में झांकी, वास्तव में?

एक्सेल में रिपोर्टिंग का समय तेजी से लुप्त हो रहा है - सूचना प्रस्तुत करने और उसका विश्लेषण करने के लिए सुविधाजनक उपकरणों की ओर रुझान सभी क्षेत्रों में दिखाई दे रहा है। हम लंबे समय से आंतरिक रूप से रिपोर्टिंग के डिजिटलीकरण पर चर्चा कर रहे हैं और हमने टेबलो विज़ुअलाइज़ेशन और स्वयं-सेवा विश्लेषण प्रणाली को चुना है। एम.वीडियो-एल्डोरैडो समूह के विश्लेषणात्मक समाधान और रिपोर्टिंग विभाग के प्रमुख अलेक्जेंडर बेजुग्ली ने लड़ाकू डैशबोर्ड के निर्माण के अनुभव और परिणामों के बारे में बात की।

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

कट के नीचे यह बताया गया है कि हमने क्या अनुभव किया और हमने क्या सीखा।

हमने कहां से शुरुआत की?

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

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

हमारे अंतिम उपयोगकर्ता तीन श्रेणियों में आते हैं:

उक्चितम प्रबंधन. अच्छी तरह से प्रस्तुत और स्पष्ट रूप से समझने योग्य तरीके से जानकारी का अनुरोध करता है।

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

बड़े पैमाने पर उपयोगकर्ता. वे स्वतंत्र रूप से डेटा का विश्लेषण करने में रुचि नहीं रखते हैं; वे एक्सेल में न्यूज़लेटर और पिवट टेबल के प्रारूप में सीमित स्वतंत्रता के साथ रिपोर्ट का उपयोग करते हैं।

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

चूँकि डैशबोर्ड के उपयोगकर्ता शीर्ष प्रबंधन के थे, उत्पाद का एक और अतिरिक्त KPI सामने आया - प्रतिक्रिया गति। कोई भी डेटा अपडेट होने के लिए 20-30 सेकंड का इंतजार नहीं करेगा। नेविगेशन 4-5 सेकंड के भीतर किया जाना चाहिए था, या इससे भी बेहतर, तुरंत किया जाना चाहिए था। और अफ़सोस, हम इसे हासिल करने में असफल रहे।

हमारे मुख्य डैशबोर्ड का लेआउट इस प्रकार दिखता था:

मुख्य विचार मुख्य KPI ड्राइवरों को बाईं ओर संयोजित करना है, जिनमें से कुल 19 थे, और दाईं ओर मुख्य विशेषताओं द्वारा उनकी गतिशीलता और ब्रेकडाउन प्रस्तुत करना है। कार्य सरल लगता है, विज़ुअलाइज़ेशन तार्किक और समझने योग्य है, जब तक आप विवरण में नहीं उतरते।

विवरण 1. डेटा की मात्रा

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

विवरण 2. गैर-योज्य संकेतक

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

अपनी गणनाओं को सही बनाने के लिए, आप यह कर सकते हैं:

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

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

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

यह बिंदु पिछले बिंदु के समान है. लब्बोलुआब यह है कि किसी कंपनी का विश्लेषण करते समय, पिछली अवधि के साथ तुलना के कई स्तर बनाने की प्रथा है:

पिछली अवधि से तुलना (दिन से दिन, सप्ताह से सप्ताह, महीने से महीने)

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

पिछले साल से तुलना

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

डैशबोर्ड को लागू करते समय, हमने लंबे चुस्त पथ का अनुसरण किया। हमारा कार्य यथाशीघ्र परीक्षण के लिए आवश्यक डेटा के साथ एक कार्यशील उपकरण प्रदान करना था। इसलिए, हम स्प्रिंट में चले गए और वर्तमान भंडारण के पक्ष में काम को कम करने से शुरुआत की।

भाग 1: झांकी में आस्था

आईटी समर्थन को सरल बनाने और परिवर्तनों को शीघ्रता से लागू करने के लिए, हमने गैर-योज्य संकेतकों की गणना करने और झांकी में पिछली अवधियों की तुलना करने के लिए तर्क बनाने का निर्णय लिया।

चरण 1. सब कुछ लाइव है, कोई विंडो संशोधन नहीं।

इस स्तर पर, हमने टेबलो को वर्तमान स्टोरफ्रंट से जोड़ा और यह देखने का निर्णय लिया कि एक वर्ष के लिए प्राप्तियों की संख्या की गणना कैसे की जाएगी।

रिजल्ट:

उत्तर निराशाजनक था - 20 मिनट। नेटवर्क पर डेटा का स्थानांतरण, टेबलू पर उच्च भार। हमने महसूस किया कि गैर-योज्य संकेतकों वाले तर्क को HANA पर लागू करने की आवश्यकता है। इससे हमें ज्यादा डर नहीं लगा, हमारे पास पहले से ही बीओ और विश्लेषण के साथ समान अनुभव था और हम जानते थे कि हाना में तेजी से शोकेस कैसे बनाया जाए जो सही ढंग से गणना किए गए गैर-योज्य संकेतक उत्पन्न करते हैं। अब बस उन्हें झांकी में समायोजित करना बाकी था।

चरण 2। हम डिस्प्ले केस को ट्यून करते हैं, कोई भौतिकीकरण नहीं, सब कुछ तुरंत।

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

रिजल्ट:

पहला डैशबोर्ड खोलें: 4-5 मिनट
कोई भी क्लिक: 3-4 मिनट
स्टोरफ्रंट के काम में इतनी अतिरिक्त बढ़ोतरी की किसी को उम्मीद नहीं थी।

भाग 2. झांकी में गोता लगाएँ

चरण 1. झांकी प्रदर्शन विश्लेषण और त्वरित ट्यूनिंग

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

- डेटा ट्रांसपोज़िशन। चूंकि टेबल्यू के पास डेटासेट को ट्रांसपोज़ करने के लिए उपकरण नहीं हैं, इसलिए सभी KPI के विस्तृत प्रतिनिधित्व के साथ डैशबोर्ड के बाईं ओर बनाने के लिए, हमें एक केस का उपयोग करके एक तालिका बनानी पड़ी। डेटाबेस में SQL क्वेरीज़ का आकार 120 वर्णों तक पहुँच गया।

- समय अवधि का चयन. डेटाबेस स्तर पर ऐसी क्वेरी को निष्पादित करने की तुलना में संकलित करने में अधिक समय लगा:

वे। अनुरोध प्रसंस्करण 12 सेकंड + 5 सेकंड निष्पादन।

हमने टेबलू पक्ष पर गणना तर्क को सरल बनाने और गणना के दूसरे भाग को स्टोरफ्रंट और डेटाबेस स्तर पर ले जाने का निर्णय लिया। इसके अच्छे परिणाम आये.

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

यानी, हमने एक सेटिंग टेबल बनाई - एक ट्रांसपोज़िशन मैट्रिक्स (21x21) और पंक्ति-दर-पंक्ति ब्रेकडाउन में सभी संकेतक प्राप्त किए।

यह था:


यह बन गया:


डेटाबेस ट्रांसपोज़िशन पर लगभग कोई भी समय खर्च नहीं होता है। सप्ताह के लिए सभी संकेतकों का अनुरोध लगभग 10 सेकंड में संसाधित होता रहा। लेकिन दूसरी ओर, एक विशिष्ट संकेतक के आधार पर डैशबोर्ड के निर्माण के मामले में लचीलापन खो गया है, यानी। डैशबोर्ड के दाईं ओर जहां एक विशिष्ट संकेतक की गतिशीलता और विस्तृत विवरण प्रस्तुत किया जाता है, पहले डिस्प्ले केस 1-3 सेकंड में काम करता था, क्योंकि अनुरोध एक संकेतक पर आधारित था, और अब डेटाबेस ने हमेशा सभी संकेतकों का चयन किया और परिणाम को Tableau पर वापस करने से पहले फ़िल्टर किया।

परिणामस्वरूप, डैशबोर्ड की गति लगभग 3 गुना कम हो गई।

रिजल्ट:

1. 5 सेकंड - डैशबोर्ड, विज़ुअलाइज़ेशन को पार्स करना
2. 15-20 सेकंड - झांकी में पूर्व-गणना करने के साथ प्रश्नों को संकलित करने की तैयारी
3. 35-45 सेकंड - एसक्यूएल प्रश्नों का संकलन और हाना में उनका समानांतर-अनुक्रमिक निष्पादन
4. 5 सेकंड - टेबलो में परिणामों को संसाधित करना, सॉर्ट करना, विज़ुअलाइज़ेशन की पुनर्गणना करना
5. बेशक, ऐसे नतीजे व्यवसाय के अनुकूल नहीं रहे, और हमने अनुकूलन जारी रखा।

चरण 2। झांकी में न्यूनतम तर्क, पूर्ण भौतिकीकरण

हमने समझा कि 10 सेकंड तक चलने वाले स्टोरफ्रंट पर कई सेकंड के प्रतिक्रिया समय के साथ डैशबोर्ड बनाना असंभव था, और हमने विशेष रूप से आवश्यक डैशबोर्ड के लिए डेटाबेस पक्ष पर डेटा को भौतिक बनाने के विकल्पों पर विचार किया। लेकिन हमें ऊपर वर्णित एक वैश्विक समस्या का सामना करना पड़ा - गैर-योज्य संकेतक। हम यह सुनिश्चित करने में असमर्थ थे कि फ़िल्टर या ड्रिलडाउन बदलते समय, टेबलू ने अलग-अलग स्टोरफ्रंट और विभिन्न उत्पाद पदानुक्रमों के लिए पूर्व-डिज़ाइन किए गए स्तरों के बीच लचीले ढंग से स्विच किया (उदाहरण में, यूटीई के बिना तीन क्वेरीज़, यूटीई1 और यूटीई2 के साथ अलग-अलग परिणाम उत्पन्न करती हैं)। इसलिए, हमने डैशबोर्ड को सरल बनाने, डैशबोर्ड में उत्पाद पदानुक्रम को त्यागने और यह देखने का निर्णय लिया कि सरलीकृत संस्करण में यह कितना तेज़ हो सकता है।

इसलिए, इस अंतिम चरण में, हमने एक अलग रिपॉजिटरी इकट्ठी की जिसमें हमने सभी KPI को ट्रांसपोज़्ड रूप में जोड़ा। डेटाबेस पक्ष पर, ऐसे भंडारण के लिए कोई भी अनुरोध 0,1 - 0,3 सेकंड में संसाधित किया जाता है। डैशबोर्ड में हमें निम्नलिखित परिणाम प्राप्त हुए:

पहली शुरुआत: 8-10 सेकंड
कोई भी क्लिक: 6-7 सेकंड

झांकी द्वारा बिताया गया समय इस प्रकार है:

1. 0,3 सेकंड. - डैशबोर्ड पार्सिंग और SQL क्वेरीज़ का संकलन
2. 1,5-3 सेकंड. - मुख्य विज़ुअलाइज़ेशन के लिए हाना में SQL क्वेरी का निष्पादन (चरण 1 के समानांतर चलता है)
3. 1,5-2 सेकंड. - विज़ुअलाइज़ेशन का प्रतिपादन, पुनर्गणना
4. 1,3 सेकंड. - प्रासंगिक फ़िल्टर मान (ब्रांड, डिवीजन, शहर, स्टोर) प्राप्त करने के लिए अतिरिक्त SQL क्वेरी का निष्पादन, पार्सिंग परिणाम

इसे संक्षेप में कहें तो

विज़ुअलाइज़ेशन के नजरिए से हमें टेब्लू टूल पसंद आया। प्रोटोटाइप चरण में, हमने विभिन्न विज़ुअलाइज़ेशन तत्वों पर विचार किया और उन सभी को पुस्तकालयों में पाया, जिनमें जटिल बहु-स्तरीय विभाजन और बहु-चालक झरना शामिल थे।

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

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

हमने झांकी को नहीं छोड़ा है। लेकिन हम टेबलो को औद्योगिक डैशबोर्ड बनाने में सक्षम उपकरण और कंपनी की संपूर्ण कॉर्पोरेट रिपोर्टिंग प्रणाली को बदलने और डिजिटल बनाने में सक्षम उपकरण नहीं मानते हैं।

अब हम सक्रिय रूप से एक अन्य टूल में एक समान डैशबोर्ड विकसित कर रहे हैं और साथ ही, इसे और भी अधिक सरल बनाने के लिए टेबल्यू में डैशबोर्ड आर्किटेक्चर को संशोधित करने का प्रयास कर रहे हैं। यदि समुदाय रुचि रखता है, तो हम आपको परिणामों के बारे में बताएंगे।

हम आपके विचारों या सलाह का भी इंतजार कर रहे हैं कि टैब्यू में आप इतनी बड़ी मात्रा में डेटा पर त्वरित डैशबोर्ड कैसे बना सकते हैं, क्योंकि हमारे पास एक वेबसाइट है जहां खुदरा की तुलना में बहुत अधिक डेटा है।

स्रोत: www.habr.com