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

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

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



हमने जो भी सामना किया और जो हमने सीखा उसके बारे में कटौती के तहत।

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

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

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

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

शीर्ष प्रबंधन । एक सुव्यवस्थित और स्पष्ट रूप से समझने योग्य रूप में जानकारी का अनुरोध करता है।

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

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

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

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

यह हमारे बुनियादी डैशबोर्ड लेआउट जैसा दिखता है:



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

विस्तार 1. डेटा वॉल्यूम

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

भाग 2. गैर-योजक संकेतक

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



गणना की शुद्धता के लिए, आप कर सकते हैं:

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

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

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

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

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

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

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

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

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

भाग 1. झांकी में विश्वास

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

स्टेज 1. लाइव में सब कुछ, कोई विंडो ड्रेसिंग सुधार नहीं।

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

परिणाम:

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

स्टेज 2. हम खिड़कियों को ट्यून करते हैं, कोई भौतिकता नहीं, सब कुछ मक्खी पर है।

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

परिणाम:

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

भाग 2. झांकी में विसर्जन

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

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

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



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



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

हमने झांकी की ओर से गणना के तर्क को सरल बनाने और गणना का एक और हिस्सा स्टोरफ्रंट और डेटाबेस स्तर पर स्थानांतरित करने का निर्णय लिया। यह अच्छे परिणाम लाए।

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



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

यह था:


यह बन गया:


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

नतीजतन, डैशबोर्ड की गति लगभग 3 गुना कम हो गई थी।

परिणाम:

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

चरण 2. झांकी में न्यूनतम तर्क, पूर्ण सामग्रीकरण

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

इसलिए, इस अंतिम चरण में, हमने एक अलग रिपॉजिटरी लगाई जिसमें सभी KPI ट्रांसपोज़ किए गए थे। डेटाबेस की ओर, इस तरह के भंडार के लिए कोई भी अनुरोध 0.1 - 0.3 सेकंड में पूरा होता है। डैशबोर्ड में, हमें निम्नलिखित परिणाम मिले:

पहला उद्घाटन: 8-10 सेकंड
कोई भी क्लिक: 6-7 सेकंड

झांकी में जो समय व्यतीत होता है, वह है:

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

संक्षेप में देना

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

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

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

हमने झांकी को विराम नहीं दिया। लेकिन एक उपकरण के रूप में जो औद्योगिक डैशबोर्ड का निर्माण कर सकता है और एक ऐसा उपकरण जिसके साथ आप कंपनी के संपूर्ण कॉर्पोरेट रिपोर्टिंग सिस्टम को बदल सकते हैं और डिजिटल कर सकते हैं, झांकी पर विचार नहीं किया जाता है।

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

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