Self-service डैशबोर्ड काम क्यों नहीं करते

 (briefer.cloud)
3 पॉइंट द्वारा GN⁺ 2024-06-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • "self-serve dashboards" वास्तव में अच्छी तरह काम नहीं करते। ऐसा इसलिए है क्योंकि इंजीनियरों या डेटा वैज्ञानिकों को बिज़नेस यूज़र्स के लिए क्वेरी लिखने और डैशबोर्ड तैयार करने में बहुत समय खर्च करना पड़ता है।

"self-serve BI" काम क्यों नहीं करता

  • SQL ही एकमात्र "self-serve BI" टूल है। लेकिन ज़्यादातर "self-serve BI" वेंडर SQL को किसी और चीज़ के रूप में छिपाने की कोशिश करते हैं।
  • SQL क्वेरी लिखना ही वह एकमात्र बाधा नहीं है जो बिज़नेस स्टेकहोल्डर्स को डेटा क्वेरी करने से रोकती है। वे डेटा का मतलब, उसका स्रोत, उसकी गणना कैसे हुई, यह नहीं समझते, और न ही वे यह जानते हैं कि परिणामों की व्याख्या और सत्यापन कैसे किया जाए।

प्रयास 1: पारंपरिक "ड्रॉपडाउन और चेकबॉक्स" तरीका

  • यह इंटरफ़ेस सिर्फ "SQL-by-mouse" की कोशिश भर है। यह SQL से बेहतर नहीं है; बल्कि अधिक धीमा, कम भरोसेमंद, अधिक सीमित है, और दूसरे टूल्स में सामान्यीकृत नहीं किया जा सकता।
  • CFO जैसे लोग इस इंटरफ़ेस का उपयोग करके डेटा क्वेरी नहीं करेंगे। ऐसा इसलिए है क्योंकि उनके पास डेटा को समझने का संदर्भ नहीं है और वे परिणामों को लेकर आश्वस्त नहीं हो सकते।

प्रयास 2: text-to-SQL तरीका

  • LLM प्राकृतिक भाषा को SQL में अनुवाद करने में लगभग जरूरत से ज़्यादा प्रभावी हैं। सवाल सही न भी हो, तब भी वे क्वेरी बनाने की कोशिश करेंगे।
  • तकनीकी लोग समझ जाएंगे कि सवाल सही नहीं है और वे अधिक संदर्भ मांगेंगे। वे उपलब्ध डेटा के प्रकारों की व्याख्या करेंगे और सटीक व उपयोगी सवाल बनाने के लिए बिज़नेस टीम के साथ काम करेंगे।
  • LLM "self-serve BI" का वास्तविक समाधान बन सकते हैं, लेकिन अपने मौजूदा रूप में नहीं। उन्हें अधिक संदर्भ की ज़रूरत है, और उन्हें अनिश्चितता व्यक्त करने व अधिक जानकारी मांगने में अधिक सक्षम होना होगा।

जो वास्तव में काम करता है

  • "self-serve BI" की समस्या SQL नहीं, बल्कि डेटा का संदर्भ और अर्थ है। समाधान यह है कि इंटरफ़ेस चाहे जो भी हो, लोगों को उस डेटा के बारे में सिखाया जाए जिसे वे क्वेरी कर रहे हैं।
  • टेक्निकल टीम से हर ज्ञान को दस्तावेज़ित करवाना काफी ओवरहेड पैदा करता है और वह जल्दी पुराना भी हो जाता है।
  • "self-serve BI" का असली समाधान यह नहीं है कि गैर-तकनीकी लोगों के लिए BI को "self-serve" बनाया जाए, बल्कि यह है कि तकनीकी लोग बेहतर टूल्स का उपयोग करके बिज़नेस स्टेकहोल्डर्स की अधिक कुशलता से मदद करें।

बेहतर टूल्स के लिए सुझाव:

  1. LLM को बिज़नेस स्टेकहोल्डर्स की बजाय तकनीकी लोगों को दिया जाए।
  2. Python, R जैसे सुविधाजनक टूल्स का उपयोग करके डेटा को स्वतंत्र रूप से संभालने की सुविधा दी जाए।
  3. तकनीकी लोग अपना काम आसानी से साझा कर सकें। notebooks और internal data applications को containers, dependencies, और infrastructure संभालने पड़ते हैं, इसलिए उन्हें साझा करना कठिन होता है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-13
Hacker News की राय

  • BI टूल्स की समस्या: BI टूल्स का उपयोग करते समय ऐसा अनुभव रहा कि query के join गलत सेट होने से डेटा गलत दिखा। इससे उन लोगों के लिए बने abstraction layer पर भरोसा खत्म हो गया जो SQL अच्छी तरह नहीं जानते।

  • Text-to-SQL की उपयोगिता: डेवलपर्स के लिए यह अब भी उपयोगी है, लेकिन non-developers के लिए database structure को ठीक से न समझ पाने के कारण गलत query बनने की संभावना रहती है।

  • संस्थागत अक्षमता: BI टूल्स और AI टूल्स की गलतियों तथा गलत जानकारी वाले reports वास्तव में इस्तेमाल हो रहे हैं, और Dilbert comic में भी इसी तरह की आलोचना की गई है।

  • बिज़नेस यूज़र्स की सीखने की क्षमता: यह मान लेना गलत है कि business users data model और dropdown के संबंध को समझ नहीं सकते। समस्या तब पैदा होती है जब data modeler domain को अच्छी तरह नहीं समझता।

  • डेटा उपलब्ध कराने का अनुभव: 24 साल के data delivery अनुभव के आधार पर, वास्तव में केवल कुछ ही users टूल्स का उपयोग करते हैं, जबकि executives KPI dashboards को पसंद करते हैं।

  • Metabase के फायदे: Metabase, BI टूल्स में एक अच्छा interface देता है, और GUI से बने SQL को pure SQL में बदल सकता है, इसलिए कम technical skill वाले लोग भी इसे आसानी से उपयोग कर सकते हैं।

  • self-service BI की सीमाएँ: self-service BI की सीमाओं को पहचानना और business users के सामने SQL लाए बिना custom dashboards बनाना ही समाधान है।

  • Metabase उपयोग का अनुभव: Metabase का उपयोग करते हुए 'office hours' के जरिए non-technical users को सिखाया गया, जिसके परिणामस्वरूप कई requests engineering team तक जाने से रुक गईं।

  • SQL उपयोग की विडंबना: यह विडंबनापूर्ण है कि senior managers SQL query नहीं चला पाते। SQL मूल रूप से managers को डेटा आसानी से query करने देने के लिए बनाया गया था।

  • ETL की कठिनाई: BI की तुलना में ETL में non-technical users के लिए डेटा संभालना और भी कठिन है। AWS Glue विकसित करते समय यह एहसास हुआ कि technical users को समस्याएँ debug करने के लिए tools चाहिए।