किरकोळ मध्ये झांकी, खरोखर?

एक्सेलमध्ये अहवाल देण्याची वेळ झपाट्याने नाहीशी होत आहे - माहितीचे सादरीकरण आणि विश्लेषण करण्यासाठी सोयीस्कर साधनांकडे कल सर्व क्षेत्रांमध्ये दिसून येत आहे. आम्ही बर्याच काळापासून रिपोर्टिंगच्या डिजिटलायझेशनवर अंतर्गत चर्चा करत आहोत आणि आम्ही टॅबलो व्हिज्युअलायझेशन आणि सेल्फ-सर्व्हिस अॅनालिटिक्स सिस्टम निवडले आहे. एम.व्हिडिओ-एल्डोराडो ग्रुपच्या विश्लेषणात्मक उपाय आणि अहवाल विभागाचे प्रमुख अलेक्झांडर बेझुग्ली यांनी लढाऊ डॅशबोर्ड तयार करण्याच्या अनुभवाबद्दल आणि परिणामांबद्दल सांगितले.

मी लगेच म्हणेन की जे काही नियोजित होते ते पूर्ण झाले नाही, परंतु अनुभव मनोरंजक होता, मला आशा आहे की ते तुमच्यासाठी देखील उपयुक्त ठरेल. आणि ते अधिक चांगले कसे करता येईल याबद्दल कोणाला काही कल्पना असल्यास, मी तुमच्या सल्ल्याबद्दल आणि कल्पनांसाठी खूप आभारी आहे.

कट खाली आम्हाला काय आले आणि आम्ही काय शिकलो याबद्दल आहे.

आम्ही कुठे सुरुवात केली?

M.Video-Eldorado कडे सु-विकसित डेटा मॉडेल आहे: आवश्यक स्टोरेज डेप्थ आणि मोठ्या संख्येने निश्चित स्वरूपाच्या अहवालांसह संरचित माहिती (अधिक तपशील पहा हा लेख). यामधून, विश्लेषक एकतर मुख्य सारणी किंवा Excel मध्ये स्वरूपित वृत्तपत्रे किंवा अंतिम वापरकर्त्यांसाठी सुंदर PowerPoint सादरीकरणे बनवतात.

सुमारे दोन वर्षांपूर्वी, निश्चित स्वरूपाच्या अहवालांऐवजी, आम्ही SAP विश्लेषणामध्ये विश्लेषणात्मक अहवाल तयार करण्यास सुरुवात केली (एक एक्सेल अॅड-ऑन, मूलत: OLAP इंजिनवर एक मुख्य सारणी). परंतु हे साधन सर्व वापरकर्त्यांच्या गरजा पूर्ण करण्यास सक्षम नव्हते; बहुसंख्य विश्लेषकांनी अतिरिक्तपणे प्रक्रिया केलेली माहिती वापरणे सुरू ठेवले.

आमचे अंतिम वापरकर्ते तीन श्रेणींमध्ये येतात:

वरिष्ठ व्यवस्थापन. चांगल्या प्रकारे सादर केलेल्या आणि स्पष्टपणे समजण्यायोग्य पद्धतीने माहितीची विनंती करते.

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

मोठ्या प्रमाणात वापरकर्ते. डेटाचे स्वतंत्रपणे विश्लेषण करण्यात त्यांना स्वारस्य नाही; ते एक्सेलमधील वृत्तपत्रे आणि मुख्य सारण्यांच्या स्वरूपात मर्यादित स्वातंत्र्यासह अहवाल वापरतात.

आमची कल्पना सर्व वापरकर्त्यांच्या गरजा पूर्ण करणे आणि त्यांना एकच, सोयीस्कर साधन देणे ही होती. आम्ही शीर्ष व्यवस्थापनापासून सुरुवात करण्याचा निर्णय घेतला. मुख्य व्यवसाय परिणामांचे विश्लेषण करण्यासाठी त्यांना वापरण्यास सुलभ डॅशबोर्डची आवश्यकता होती. म्हणून, आम्ही टॅबलेओसह सुरुवात केली आणि प्रथम दोन दिशानिर्देश निवडले: किरकोळ आणि ऑनलाइन विक्री निर्देशक मर्यादित खोली आणि विश्लेषणाच्या रुंदीसह, जे शीर्ष व्यवस्थापनाद्वारे विनंती केलेल्या डेटाच्या अंदाजे 80% कव्हर करेल.

डॅशबोर्डचे वापरकर्ते उच्च व्यवस्थापन असल्याने, उत्पादनाचा आणखी एक अतिरिक्त KPI दिसू लागला - प्रतिसाद गती. डेटा अपडेट होण्यासाठी कोणीही 20-30 सेकंद प्रतीक्षा करणार नाही. नेव्हिगेशन 4-5 सेकंदांच्या आत, किंवा अजून चांगले, त्वरित केले गेले पाहिजे. आणि आम्ही, अरेरे, हे साध्य करण्यात अपयशी ठरलो.

आमच्या मुख्य डॅशबोर्डचे लेआउट असे दिसते:

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

तपशील 1. डेटा खंड

वार्षिक विक्रीसाठी आमची मुख्य सारणी सुमारे 300 दशलक्ष पंक्ती घेते. गेल्या वर्षी आणि त्याआधीच्या वर्षातील गतिशीलता प्रतिबिंबित करणे आवश्यक असल्याने, केवळ वास्तविक विक्रीवरील डेटाचे प्रमाण सुमारे 1 अब्ज ओळी आहे. नियोजित डेटा आणि ऑनलाइन विक्री ब्लॉकची माहिती देखील स्वतंत्रपणे संग्रहित केली जाते. म्हणून, जरी आम्ही कॉलम इन-मेमरी DB SAP HANA वापरला असला तरीही, फ्लायवरील वर्तमान स्टोरेजमधून एका आठवड्यासाठी सर्व निर्देशकांच्या निवडीसह क्वेरीची गती सुमारे 15-20 सेकंद होती. या समस्येचे निराकरण स्वतःच सूचित करते - डेटाचे अतिरिक्त भौतिकीकरण. परंतु त्यात तोटे देखील आहेत, त्यांच्याबद्दल खाली अधिक.

तपशील 2. नॉन-अॅडिटिव्ह निर्देशक

आमचे बरेच KPI पावत्यांच्या संख्येशी जोडलेले आहेत. आणि हा सूचक पंक्तींच्या संख्येच्या COUNT DISTINCT (शीर्षलेख तपासा) दर्शवतो आणि निवडलेल्या विशेषतांवर अवलंबून भिन्न रक्कम दर्शवितो. उदाहरणार्थ, हा निर्देशक आणि त्याचे व्युत्पन्न कसे मोजले जावे:

तुमची गणना अचूक करण्यासाठी, तुम्ही हे करू शकता:

• स्टोरेजमध्ये फ्लायवर अशा निर्देशकांची गणना करा;
• टेबलामधील डेटाच्या संपूर्ण व्हॉल्यूमवर गणना करा, उदा. झांकीमध्ये विनंती केल्यावर, पावती स्थितीच्या ग्रॅन्युलॅरिटीमध्ये निवडलेल्या फिल्टरनुसार सर्व डेटा प्रदान करा;
• एक मटेरियलाइज्ड शोकेस तयार करा ज्यामध्ये विविध नॉन-अॅडिटिव्ह परिणाम देणार्‍या सर्व नमुना पर्यायांमध्ये सर्व निर्देशकांची गणना केली जाईल.

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

तपशील 3. डेटा तुलना

हा बिंदू मागील एकसारखाच आहे. मुख्य गोष्ट अशी आहे की कंपनीचे विश्लेषण करताना, मागील कालावधीशी तुलना करण्याचे अनेक स्तर तयार करण्याची प्रथा आहे:

मागील कालावधीशी तुलना (दिवस ते दिवस, आठवडा ते आठवडा, महिना ते महिना)

या तुलनेत, असे गृहीत धरले जाते की वापरकर्त्याने निवडलेल्या कालावधीनुसार (उदाहरणार्थ, वर्षाचा 33 वा आठवडा), आम्ही 32 व्या आठवड्यापर्यंत गतिशीलता दर्शविली पाहिजे; जर आम्ही एका महिन्यासाठी डेटा निवडला असेल, उदाहरणार्थ, मे , नंतर ही तुलना एप्रिलपर्यंत गतिशीलता दर्शवेल.

गेल्या वर्षीची तुलना

येथे मुख्य गोष्ट अशी आहे की दिवस आणि आठवड्यानुसार तुलना करताना, आपण मागील वर्षाचा समान दिवस घेत नाही, म्हणजे. तुम्ही फक्त चालू वर्ष वजा एक ठेवू शकत नाही. तुम्ही ज्या आठवड्याची तुलना करत आहात त्या दिवशी तुम्ही पहा. महिन्यांची तुलना करताना, उलटपक्षी, आपल्याला मागील वर्षाचा समान कॅलेंडर दिवस घेणे आवश्यक आहे. लीप वर्षांसह बारकावे देखील आहेत. मूळ भांडारांमध्ये, सर्व माहिती दिवसा वितरीत केली जाते; आठवडे, महिने किंवा वर्षांसह कोणतेही वेगळे फील्ड नाहीत. म्हणून, पॅनेलमध्ये संपूर्ण विश्लेषणात्मक क्रॉस-सेक्शन प्राप्त करण्यासाठी, आपल्याला एक कालावधी मोजण्याची आवश्यकता नाही, उदाहरणार्थ एक आठवडा, परंतु 4 आठवडे, आणि नंतर या डेटाची तुलना करा, गतिशीलता, विचलन प्रतिबिंबित करा. त्यानुसार, डायनॅमिक्समध्ये तुलना निर्माण करण्यासाठी हे तर्क एकतर टेबलॉमध्ये किंवा स्टोअरफ्रंट बाजूला लागू केले जाऊ शकते. होय, आणि अर्थातच आम्हाला डिझाइन स्टेजवर हे तपशील माहित होते आणि त्याबद्दल विचार केला, परंतु अंतिम डॅशबोर्डच्या कार्यक्षमतेवर त्यांच्या प्रभावाचा अंदाज लावणे कठीण होते.

डॅशबोर्ड लागू करताना, आम्ही लांब चपळ मार्गाचा अवलंब केला. आमचे कार्य शक्य तितक्या लवकर चाचणीसाठी आवश्यक डेटासह कार्यरत साधन प्रदान करणे हे होते. म्हणून, आम्ही स्प्रिंटमध्ये गेलो आणि सध्याच्या स्टोरेजच्या बाजूला काम कमी करण्यापासून सुरुवात केली.

भाग 1: झांकीवरील विश्वास

आयटी सपोर्ट सुलभ करण्यासाठी आणि बदलांची त्वरीत अंमलबजावणी करण्यासाठी, आम्ही नॉन-अॅडिटिव्ह इंडिकेटर्सची गणना करण्यासाठी आणि टेब्लूमध्ये मागील कालावधीची तुलना करण्यासाठी तर्क तयार करण्याचा निर्णय घेतला.

स्टेज 1. सर्व काही थेट आहे, विंडोमध्ये कोणतेही बदल नाहीत.

या टप्प्यावर, आम्ही सध्याच्या स्टोअरफ्रंट्सशी टॅबला जोडला आणि एका वर्षासाठीच्या पावत्यांची संख्या कशी मोजली जाईल हे पाहण्याचा निर्णय घेतला.

निकाल:

उत्तर निराशाजनक होते - 20 मिनिटे. नेटवर्कवर डेटाचे हस्तांतरण, झांकीवरील उच्च भार. आम्हाला समजले की HANA वर नॉन-अॅडिटिव्ह इंडिकेटरसह तर्क लागू करणे आवश्यक आहे. यामुळे आम्हाला फारशी भीती वाटली नाही, आम्हाला BO आणि विश्लेषणाचा असाच अनुभव आधीच आला होता आणि आम्हाला HANA मध्ये जलद शोकेस कसे तयार करायचे हे माहित होते जे योग्यरित्या गणना केलेले नॉन-अॅडिटिव्ह इंडिकेटर तयार करतात. आता फक्त त्यांना झांकीशी जुळवून घेणे बाकी होते.

स्टेज 2. आम्ही डिस्प्ले केस ट्यून करतो, कोणतेही भौतिकीकरण नाही, सर्वकाही उडते.

आम्ही एक वेगळा नवीन शोकेस तयार केला ज्याने फ्लायवर TABLEAU साठी आवश्यक डेटा तयार केला. सर्वसाधारणपणे, आम्हाला एक चांगला परिणाम मिळाला; आम्ही एका आठवड्यात सर्व निर्देशक तयार करण्यासाठी वेळ 9-10 सेकंदांपर्यंत कमी केला. आणि आम्ही प्रामाणिकपणे अशी अपेक्षा केली होती की टेब्लूमध्ये डॅशबोर्डचा प्रतिसाद वेळ पहिल्या ओपनिंगमध्ये 20-30 सेकंद असेल आणि नंतर 10 ते 12 कॅशेमुळे, जे सर्वसाधारणपणे आम्हाला अनुकूल असेल.

निकाल:

प्रथम उघडा डॅशबोर्ड: 4-5 मिनिटे
कोणतेही क्लिक: 3-4 मिनिटे
स्टोअरफ्रंटच्या कामात अशा अतिरिक्त वाढीची कोणालाही अपेक्षा नव्हती.

भाग 2. झांकी मध्ये जा

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

आम्ही विश्लेषण करू लागलो की टेबलाओ आपला बहुतेक वेळ कुठे घालवतो. आणि यासाठी बरीच चांगली साधने आहेत, जी अर्थातच टॅब्यूचा एक प्लस आहे. आम्‍ही ओळखलेली मुख्‍य समस्‍या ही अतिशय गुंतागुंतीची एसक्यूएल क्‍वेरी होती जी टेब्‍लो तयार करत होती. ते प्रामुख्याने संबंधित होते:

- डेटा ट्रान्स्पोझिशन. Tableau मध्ये डेटासेट ट्रान्सपोज करण्यासाठी साधने नसल्यामुळे, सर्व KPI चे तपशीलवार प्रतिनिधित्व असलेल्या डॅशबोर्डच्या डाव्या बाजूला तयार करण्यासाठी, आम्हाला केस वापरून टेबल तयार करावे लागले. डेटाबेसमधील SQL क्वेरीचा आकार 120 वर्णांपर्यंत पोहोचला आहे.

- कालावधी निवडणे. डेटाबेस स्तरावरील अशा क्वेरीला अंमलात आणण्यापेक्षा संकलित करण्यासाठी अधिक वेळ लागला:

त्या. विनंती प्रक्रिया 12 सेकंद + 5 सेकंद अंमलबजावणी.

आम्‍ही टेब्‍लोच्‍या बाजूने गणनेचे तर्क सोपे करण्‍याचे ठरवले आणि गणनेचा दुसरा भाग स्टोअरफ्रंट आणि डेटाबेस स्‍तरावर हलवण्‍याचा निर्णय घेतला. यामुळे चांगले परिणाम दिसून आले.

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

म्हणजेच, आम्ही एक सेटिंग सारणी बनवली - एक ट्रान्सपोझिशन मॅट्रिक्स (21x21) आणि सर्व निर्देशक एका पंक्ती-दर-पंक्ती ब्रेकडाउनमध्ये प्राप्त केले.

होते:


झाले:


डेटाबेस ट्रान्स्पोझिशनवर जवळजवळ वेळ घालवला जात नाही. आठवड्यासाठी सर्व निर्देशकांची विनंती सुमारे 10 सेकंदात प्रक्रिया केली जात होती. परंतु दुसरीकडे, विशिष्ट निर्देशकावर आधारित डॅशबोर्ड तयार करण्याच्या दृष्टीने लवचिकता गमावली आहे, म्हणजे. डॅशबोर्डच्या उजव्या बाजूसाठी जेथे विशिष्ट निर्देशकाची गतिशीलता आणि तपशीलवार ब्रेकडाउन सादर केले जाते, पूर्वी डिस्प्ले केस 1-3 सेकंदात काम करत असे, कारण विनंती एका सूचकावर आधारित होती, आणि आता डेटाबेस नेहमी सर्व निर्देशक निवडत असे आणि निकाल टॅबलावर परत करण्यापूर्वी निकाल फिल्टर करते.

परिणामी, डॅशबोर्डचा वेग जवळपास 3 पट कमी झाला.

निकाल:

1. 5 सेकंद - डॅशबोर्ड पार्स करणे, व्हिज्युअलायझेशन
2. 15-20 सेकंद - टॅबलेटमध्ये पूर्व-गणना करून प्रश्नांचे संकलन करण्याची तयारी
3. 35-45 सेकंद - एसक्यूएल क्वेरीचे संकलन आणि हाना मध्ये त्यांचे समांतर-अनुक्रमिक अंमलबजावणी
4. 5 सेकंद - परिणामांवर प्रक्रिया करणे, वर्गीकरण करणे, झांकीमधील व्हिज्युअलायझेशनची पुनर्गणना करणे
5. अर्थात, असे परिणाम व्यवसायासाठी अनुकूल नव्हते आणि आम्ही ऑप्टिमायझेशन चालू ठेवले.

स्टेज 2. झांकीतील किमान तर्कशास्त्र, संपूर्ण भौतिकीकरण

आम्हाला समजले की 10 सेकंदांपर्यंत चालणार्‍या स्टोअरफ्रंटवर काही सेकंदांच्या प्रतिसाद वेळेसह डॅशबोर्ड तयार करणे अशक्य आहे आणि आम्ही विशेषतः आवश्यक डॅशबोर्डसाठी डेटाबेसच्या बाजूने डेटा तयार करण्याच्या पर्यायांचा विचार केला. परंतु आम्हाला वर वर्णन केलेली जागतिक समस्या आली - नॉन-अॅडिटिव्ह इंडिकेटर. फिल्टर किंवा ड्रिलडाउन बदलताना, विविध उत्पादन पदानुक्रमांसाठी (उदाहरणार्थ, UTE शिवाय तीन क्वेरी, UTE1 आणि UTE2 सह भिन्न परिणाम व्युत्पन्न करतात). म्हणून, आम्ही डॅशबोर्ड सरलीकृत करण्याचा निर्णय घेतला, डॅशबोर्डमधील उत्पादन पदानुक्रम सोडला आणि सरलीकृत आवृत्तीमध्ये ते किती वेगवान असू शकते ते पहा.

म्हणून, या शेवटच्या टप्प्यावर, आम्ही एक वेगळे भांडार एकत्र केले ज्यामध्ये आम्ही सर्व KPIs ट्रान्सपोस्ड फॉर्ममध्ये जोडले. डेटाबेसच्या बाजूने, अशा स्टोरेजची कोणतीही विनंती 0,1 - 0,3 सेकंदात प्रक्रिया केली जाते. डॅशबोर्डमध्ये आम्हाला खालील परिणाम प्राप्त झाले:

प्रथम उघडणे: 8-10 सेकंद
कोणतेही क्लिक: 6-7 सेकंद

झांकीद्वारे घालवलेल्या वेळेत हे समाविष्ट आहे:

1. 0,3 से. - डॅशबोर्डचे विश्लेषण आणि SQL क्वेरीचे संकलन
2. 1,5-3 से. — मुख्य व्हिज्युअलायझेशनसाठी हानामध्ये SQL क्वेरीची अंमलबजावणी (चरण 1 च्या समांतर चालते)
3. 1,5-2 से. — प्रस्तुतीकरण, व्हिज्युअलायझेशनची पुनर्गणना
4. १.३से. - संबंधित फिल्टर मूल्ये (ब्रँड, विभाग, शहर, स्टोअर), पार्सिंग परिणाम प्राप्त करण्यासाठी अतिरिक्त SQL क्वेरींची अंमलबजावणी

थोडक्यात सांगायचे तर

आम्हाला व्हिज्युअलायझेशनच्या दृष्टीकोनातून टेब्ल्यू टूल आवडले. प्रोटोटाइपिंग स्टेजवर, आम्ही विविध व्हिज्युअलायझेशन घटकांचा विचार केला आणि ते सर्व लायब्ररीमध्ये सापडले, ज्यात जटिल मल्टी-लेव्हल सेगमेंटेशन आणि मल्टी-ड्रायव्हर वॉटरफॉल यांचा समावेश आहे.

प्रमुख विक्री निर्देशकांसह डॅशबोर्डची अंमलबजावणी करताना, आम्हाला कार्यप्रदर्शन अडचणींचा सामना करावा लागला ज्यावर आम्ही अद्याप मात करू शकलो नाही. आम्ही दोन महिन्यांहून अधिक काळ घालवला आणि एक कार्यात्मक अपूर्ण डॅशबोर्ड प्राप्त झाला, ज्याचा प्रतिसाद गती स्वीकार्य होण्याच्या मार्गावर आहे. आणि आम्ही स्वतःसाठी निष्कर्ष काढले:

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

आम्ही झांकी सोडली नाही. परंतु आम्ही झांकीला औद्योगिक डॅशबोर्ड तयार करण्यास सक्षम साधन आणि कंपनीच्या संपूर्ण कॉर्पोरेट अहवाल प्रणालीला पुनर्स्थित आणि डिजिटल करण्यासाठी एक साधन मानत नाही.

आम्‍ही आता दुसर्‍या टूलमध्‍ये एक समान डॅशबोर्ड सक्रियपणे विकसित करत आहोत आणि त्याच वेळी, ते आणखी सोप्या करण्‍यासाठी टॅबलेऊमध्‍ये डॅशबोर्ड आर्किटेक्चर सुधारण्‍याचा प्रयत्‍न करत आहोत. समुदायाला स्वारस्य असल्यास, आम्ही तुम्हाला परिणामांबद्दल सांगू.

Tabeau मध्ये तुम्ही इतक्या मोठ्या प्रमाणात डेटावर झटपट डॅशबोर्ड कसे तयार करू शकता याबद्दल आम्ही तुमच्या कल्पना किंवा सल्ल्याची वाट पाहत आहोत, कारण आमच्याकडे एक वेबसाइट आहे जिथे किरकोळपेक्षा जास्त डेटा आहे.

स्त्रोत: www.habr.com