ایکسل میں رپورٹنگ کا وقت تیزی سے ختم ہو رہا ہے - معلومات کو پیش کرنے اور تجزیہ کرنے کے لیے آسان ٹولز کی طرف رجحان تمام شعبوں میں نظر آ رہا ہے۔ ہم اندرونی طور پر ایک طویل عرصے سے رپورٹنگ کی ڈیجیٹلائزیشن پر بحث کر رہے ہیں اور ٹیبلو ویژولائزیشن اور سیلف سروس اینالیٹکس سسٹم کا انتخاب کیا ہے۔ M.Video-Eldorado گروپ کے تجزیاتی حل اور رپورٹنگ ڈیپارٹمنٹ کے سربراہ الیگزینڈر بیزگلی نے جنگی ڈیش بورڈ بنانے کے تجربے اور نتائج کے بارے میں بات کی۔
میں فوراً کہوں گا کہ جو کچھ بھی منصوبہ بنایا گیا تھا وہ پورا نہیں ہوا، لیکن تجربہ دلچسپ تھا، مجھے امید ہے کہ یہ آپ کے لیے بھی کارآمد ثابت ہوگا۔ اور اگر کسی کے پاس اس بارے میں کوئی آئیڈیاز ہے کہ یہ کیسے بہتر ہو سکتا ہے تو میں آپ کے مشورے اور خیالات کا بہت مشکور ہوں گا۔
کٹ کے نیچے یہ ہے کہ ہم نے کیا سامنا کیا اور ہم نے کیا سیکھا۔
ہم نے کہاں سے شروع کیا؟
M.Video-Eldorado کے پاس ایک اچھی طرح سے تیار کردہ ڈیٹا ماڈل ہے: مطلوبہ سٹوریج کی گہرائی کے ساتھ ساختی معلومات اور مقررہ شکل کی رپورٹس کی ایک بڑی تعداد (مزید تفصیلات دیکھیں )۔ ان سے، تجزیہ کار ایکسل میں پیوٹ ٹیبل یا فارمیٹ شدہ نیوز لیٹر، یا آخری صارفین کے لیے خوبصورت پاورپوائنٹ پریزنٹیشنز بناتے ہیں۔
تقریباً دو سال پہلے، فکسڈ فارم رپورٹس کے بجائے، ہم نے SAP تجزیہ (ایک ایکسل ایڈ آن، بنیادی طور پر OLAP انجن پر ایک پیوٹ ٹیبل) میں تجزیاتی رپورٹیں بنانا شروع کیں۔ لیکن یہ ٹول تمام صارفین کی ضروریات کو پورا کرنے کے قابل نہیں تھا؛ اکثریت نے تجزیہ کاروں کی طرف سے اضافی طور پر کارروائی کی گئی معلومات کا استعمال جاری رکھا۔
ہمارے آخری صارفین تین زمروں میں آتے ہیں:
اعلی افسران. اچھی طرح سے پیش کردہ اور واضح طور پر قابل فہم انداز میں معلومات کی درخواست کرتا ہے۔
درمیانی انتظام، اعلی درجے کے صارفین۔ ڈیٹا ایکسپلوریشن میں دلچسپی رکھتے ہیں اور اگر ٹولز دستیاب ہوں تو آزادانہ طور پر رپورٹس بنانے کے قابل۔ وہ SAP تجزیہ میں تجزیاتی رپورٹس کے کلیدی صارف بن گئے۔
بڑے پیمانے پر صارفین. وہ ڈیٹا کا آزادانہ تجزیہ کرنے میں دلچسپی نہیں رکھتے؛ وہ ایکسل میں خبرنامے اور پیوٹ ٹیبل کی شکل میں محدود آزادی کے ساتھ رپورٹس کا استعمال کرتے ہیں۔
ہمارا خیال تمام صارفین کی ضروریات کو پورا کرنا اور انہیں ایک واحد، آسان ٹول دینا تھا۔ ہم نے اعلیٰ انتظامیہ کے ساتھ شروع کرنے کا فیصلہ کیا۔ انہیں اہم کاروباری نتائج کا تجزیہ کرنے کے لیے استعمال میں آسان ڈیش بورڈز کی ضرورت تھی۔ لہذا، ہم نے ٹیبلاؤ کے ساتھ شروعات کی اور پہلے دو سمتوں کا انتخاب کیا: تجزیہ کی محدود گہرائی اور وسعت کے ساتھ خوردہ اور آن لائن فروخت کے اشارے، جو اعلیٰ انتظامیہ کے ذریعہ درخواست کردہ ڈیٹا کا تقریباً 80% احاطہ کرے گا۔
چونکہ ڈیش بورڈز کے صارفین اعلیٰ انتظامی تھے، اس لیے پروڈکٹ کا ایک اور اضافی KPI ظاہر ہوا - ردعمل کی رفتار۔ ڈیٹا اپ ڈیٹ ہونے کے لیے کوئی بھی 20-30 سیکنڈ انتظار نہیں کرے گا۔ نیویگیشن 4-5 سیکنڈ کے اندر، یا اس سے بہتر، فوری طور پر ہو جانا چاہیے تھا۔ اور ہم، افسوس، اس کو حاصل کرنے میں ناکام رہے.
ہمارے مرکزی ڈیش بورڈ کی ترتیب اس طرح دکھائی دیتی تھی:
کلیدی خیال یہ ہے کہ مرکزی KPI ڈرائیوروں کو یکجا کیا جائے، جن میں سے کل 19 تھے، بائیں طرف اور ان کی حرکیات اور بریک ڈاؤن کو دائیں طرف اہم صفات کے ذریعے پیش کرنا ہے۔ کام آسان لگتا ہے، تصور منطقی اور قابل فہم ہے، جب تک کہ آپ تفصیلات میں غوطہ نہ لگائیں۔
تفصیل 1. ڈیٹا والیوم
سالانہ فروخت کے لیے ہماری مرکزی میز تقریباً 300 ملین قطاروں پر مشتمل ہے۔ چونکہ پچھلے سال اور اس سے پہلے کے سال کی حرکیات کی عکاسی کرنا ضروری ہے، اس لیے صرف حقیقی فروخت پر ڈیٹا کا حجم تقریباً 1 بلین لائنز ہے۔ منصوبہ بند ڈیٹا اور آن لائن سیلز بلاک کی معلومات بھی الگ سے محفوظ کی جاتی ہیں۔ اس لیے، اگرچہ ہم نے کالم ان-میموری DB SAP HANA کا استعمال کیا، فلائی پر موجودہ اسٹوریج سے ایک ہفتے کے لیے تمام اشاریوں کے انتخاب کے ساتھ استفسار کی رفتار تقریباً 15-20 سیکنڈ تھی۔ اس مسئلے کا حل خود تجویز کرتا ہے - ڈیٹا کی اضافی مادی کاری۔ لیکن اس میں نقصانات بھی ہیں، ان کے بارے میں مزید ذیل میں۔
تفصیل 2. غیر اضافی اشارے
ہمارے بہت سے KPIs رسیدوں کی تعداد سے منسلک ہیں۔ اور یہ اشارے قطاروں کی تعداد کے COUNT DISTINCT کی نمائندگی کرتا ہے (ہیڈر چیک کریں) اور منتخب کردہ صفات کے لحاظ سے مختلف مقداریں دکھاتا ہے۔ مثال کے طور پر، اس اشارے اور اس کے مشتق کا حساب کیسے لگایا جائے:
اپنے حسابات کو درست کرنے کے لیے، آپ یہ کر سکتے ہیں:
- اسٹوریج میں فلائی پر اس طرح کے اشارے کا حساب لگائیں؛
- ٹیبلو میں ڈیٹا کے پورے حجم پر حساب لگائیں، یعنی ٹیبلاؤ میں درخواست کرنے پر، رسید کی پوزیشن کی گرانولریٹی میں منتخب فلٹرز کے مطابق تمام ڈیٹا فراہم کریں؛
- ایک مادّہ نما شوکیس بنائیں جس میں تمام انڈیکیٹرز کو تمام نمونے کے اختیارات میں شمار کیا جائے گا جو مختلف غیر اضافی نتائج دیتے ہیں۔
یہ واضح ہے کہ مثال میں UTE1 اور UTE2 مادی صفات ہیں جو مصنوعات کے درجہ بندی کی نمائندگی کرتے ہیں۔ یہ کوئی جامد چیز نہیں ہے؛ کمپنی کے اندر انتظام اسی کے ذریعے ہوتا ہے، کیونکہ مختلف مینیجرز مختلف پروڈکٹ گروپس کے ذمہ دار ہیں۔ ہمارے پاس اس درجہ بندی کی بہت سی عالمی نظر ثانی ہوئی، جب تمام سطحیں تبدیل ہوئیں، جب تعلقات پر نظرثانی کی گئی، اور جب ایک گروپ ایک نوڈ سے دوسرے میں منتقل ہوا تو مسلسل نقطہ بدلتا رہا۔ روایتی رپورٹنگ میں، یہ سب مواد کی صفات سے اڑتے ہوئے حساب کیا جاتا ہے؛ اس ڈیٹا کو مادّی بنانے کی صورت میں، ایسی تبدیلیوں کو ٹریک کرنے اور تاریخی ڈیٹا کو خود بخود دوبارہ لوڈ کرنے کے لیے ایک طریقہ کار تیار کرنا ضروری ہے۔ ایک بہت ہی غیر معمولی کام۔
تفصیل 3. ڈیٹا کا موازنہ
یہ نقطہ پچھلے ایک سے ملتا جلتا ہے۔ سب سے اہم بات یہ ہے کہ جب کسی کمپنی کا تجزیہ کرتے ہیں، تو یہ رواج ہے کہ پچھلی مدت کے ساتھ موازنہ کی کئی سطحیں بنائیں:
پچھلی مدت کے ساتھ موازنہ (دن سے دن، ہفتے سے ہفتے، مہینے سے مہینے)
اس مقابلے میں، یہ فرض کیا جاتا ہے کہ صارف کی جانب سے منتخب کی گئی مدت (مثال کے طور پر سال کا 33 واں ہفتہ) پر منحصر ہے، ہمیں 32ویں ہفتے تک حرکیات دکھانی چاہیے؛ اگر ہم ایک مہینے کے لیے ڈیٹا منتخب کرتے ہیں، مثال کے طور پر، مئی ، پھر یہ موازنہ اپریل تک حرکیات کو ظاہر کرے گا۔
پچھلے سال کے ساتھ موازنہ
یہاں اہم بات یہ ہے کہ دن اور ہفتے کے حساب سے موازنہ کرتے وقت، آپ پچھلے سال کا ایک ہی دن نہیں لے رہے ہیں، یعنی آپ صرف موجودہ سال کو مائنس ایک نہیں رکھ سکتے۔ آپ کو ہفتے کے دن کو دیکھنا چاہیے جس کا آپ موازنہ کر رہے ہیں۔ مہینوں کا موازنہ کرتے وقت، اس کے برعکس، آپ کو پچھلے سال کے بالکل وہی کیلنڈر دن لینے کی ضرورت ہے۔ لیپ سال کے ساتھ باریکیاں بھی ہیں۔ اصل ذخیروں میں، تمام معلومات کو دن کے حساب سے تقسیم کیا جاتا ہے؛ ہفتوں، مہینوں یا سالوں کے ساتھ کوئی الگ فیلڈ نہیں ہے۔ لہذا، پینل میں ایک مکمل تجزیاتی کراس سیکشن حاصل کرنے کے لیے، آپ کو ایک مدت، مثال کے طور پر ایک ہفتہ، بلکہ 4 ہفتے شمار کرنے کی ضرورت ہے، اور پھر ان اعداد و شمار کا موازنہ کریں، حرکیات، انحراف کی عکاسی کریں۔ اس کے مطابق، حرکیات میں موازنہ پیدا کرنے کے لیے اس منطق کو ٹیبلو میں یا اسٹور فرنٹ سائیڈ پر بھی لاگو کیا جا سکتا ہے۔ ہاں، اور یقیناً ہم ڈیزائن کے مرحلے پر ان تفصیلات کے بارے میں جانتے اور سوچتے تھے، لیکن حتمی ڈیش بورڈ کی کارکردگی پر ان کے اثرات کا اندازہ لگانا مشکل تھا۔
ڈیش بورڈ کو لاگو کرتے وقت، ہم نے لمبے فرتیلی راستے کی پیروی کی۔ ہمارا کام جلد از جلد جانچ کے لیے ضروری ڈیٹا کے ساتھ ایک ورکنگ ٹول فراہم کرنا تھا۔ لہذا، ہم سپرنٹ میں گئے اور موجودہ اسٹوریج کی طرف کام کو کم سے کم کرنے سے شروع کیا۔
حصہ 1: ٹیبلو پر ایمان
آئی ٹی سپورٹ کو آسان بنانے اور تبدیلیوں کو تیزی سے لاگو کرنے کے لیے، ہم نے غیر اضافی اشارے کا حساب لگانے اور ٹیبلو میں ماضی کے ادوار کا موازنہ کرنے کے لیے منطق بنانے کا فیصلہ کیا۔
مرحلہ 1۔ ہر چیز لائیو ہے، کوئی ونڈو ترمیم نہیں۔
اس مرحلے پر، ہم نے ٹیبلو کو موجودہ اسٹور فرنٹ سے جوڑ دیا اور یہ دیکھنے کا فیصلہ کیا کہ ایک سال کی رسیدوں کی تعداد کا حساب کیسے لگایا جائے گا۔
نتیجہ:
جواب افسردہ کن تھا - 20 منٹ۔ نیٹ ورک پر ڈیٹا کی منتقلی، ٹیبلو پر زیادہ بوجھ۔ ہم نے محسوس کیا کہ HANA پر غیر اضافی اشارے والی منطق کو لاگو کرنے کی ضرورت ہے۔ اس نے ہمیں زیادہ خوفزدہ نہیں کیا، ہمیں پہلے ہی BO اور Analysis کے ساتھ ایسا ہی تجربہ تھا اور ہم جانتے تھے کہ HANA میں تیزی سے شوکیس بنانے کا طریقہ جو درست طریقے سے کیلکولیشن شدہ غیر اضافی اشارے تیار کرتے ہیں۔ اب بس انہیں ٹیبلو میں ایڈجسٹ کرنا باقی تھا۔
مرحلہ 2۔ ہم ڈسپلے کیسز کو ٹیون کرتے ہیں، کوئی مادّہ کاری نہیں، ہر چیز مکھی پر ہے۔
ہم نے ایک علیحدہ نیا شوکیس بنایا جس نے پرواز پر TABLEAU کے لیے مطلوبہ ڈیٹا تیار کیا۔ عام طور پر، ہمیں اچھا نتیجہ ملا؛ ہم نے ایک ہفتے میں تمام اشاریے بنانے کا وقت کم کر کے 9-10 سیکنڈ کر دیا۔ اور ہم ایمانداری سے توقع کرتے تھے کہ ٹیبلو میں ڈیش بورڈ کا رسپانس ٹائم پہلے اوپننگ میں 20-30 سیکنڈ ہوگا اور پھر 10 سے 12 تک کیش کی وجہ سے، جو کہ عام طور پر ہمارے مطابق ہوگا۔
نتیجہ:
پہلا کھلا ڈیش بورڈ: 4-5 منٹ
کوئی بھی کلک: 3-4 منٹ
سٹور فرنٹ کے کام میں اس طرح کے اضافی اضافے کی کسی کو بھی توقع نہیں تھی۔
حصہ 2۔ ٹیبلو میں غوطہ لگائیں۔
اسٹیج 1۔ ٹیبلو کی کارکردگی کا تجزیہ اور فوری ٹیوننگ
ہم نے تجزیہ کرنا شروع کیا کہ ٹیبلو اپنا زیادہ تر وقت کہاں گزارتا ہے۔ اور اس کے لیے کافی اچھے ٹولز موجود ہیں، جو یقیناً ٹیبلاؤ کا ایک پلس ہے۔ بنیادی مسئلہ جس کی ہم نے نشاندہی کی وہ انتہائی پیچیدہ SQL سوالات تھے جو ٹیبلاؤ بنا رہے تھے۔ وہ بنیادی طور پر منسلک تھے:
- ڈیٹا کی منتقلی چونکہ ٹیبلو کے پاس ڈیٹا سیٹس کو منتقل کرنے کے لیے ٹولز نہیں ہیں، اس لیے ڈیش بورڈ کے بائیں جانب کو تمام KPIs کی تفصیلی نمائندگی کے ساتھ بنانے کے لیے، ہمیں کیس کا استعمال کرتے ہوئے ایک ٹیبل بنانا پڑا۔ ڈیٹا بیس میں SQL سوالات کا سائز 120 حروف تک پہنچ گیا۔
- وقت کی مدت کا انتخاب۔ ڈیٹا بیس کی سطح پر اس طرح کے استفسار پر عمل کرنے کے بجائے مرتب کرنے میں زیادہ وقت لگا:
وہ. پروسیسنگ 12 سیکنڈ + 5 سیکنڈ پر عمل درآمد کی درخواست کریں۔
ہم نے ٹیبلو سائیڈ پر حساب کی منطق کو آسان بنانے اور حساب کے دوسرے حصے کو اسٹور فرنٹ اور ڈیٹا بیس کی سطح پر منتقل کرنے کا فیصلہ کیا۔ اس سے اچھے نتائج برآمد ہوئے۔
سب سے پہلے، ہم نے فلائی پر ٹرانسپوزیشن کی، ویکی پر بیان کردہ اس نقطہ نظر کے مطابق، ہم نے VIEW کیلکولیشن کے آخری مرحلے میں مکمل بیرونی شمولیت کے ذریعے اسے کیا۔ и .
یعنی، ہم نے ایک سیٹنگ ٹیبل بنایا - ایک ٹرانسپوزیشن میٹرکس (21x21) اور تمام اشاریے قطار در قطار بریک ڈاؤن میں موصول ہوئے۔
تھا:
بن گیا:
ڈیٹا بیس کی منتقلی پر تقریباً کوئی وقت نہیں خرچ ہوتا ہے۔ ہفتے کے لیے تمام اشاریوں کی درخواست پر تقریباً 10 سیکنڈ میں کارروائی ہوتی رہی۔ لیکن دوسری طرف، ایک مخصوص اشارے کی بنیاد پر ڈیش بورڈ بنانے کے معاملے میں لچک کھو گئی ہے، یعنی ڈیش بورڈ کے دائیں جانب جہاں ایک مخصوص اشارے کی حرکیات اور تفصیلی خرابی پیش کی جاتی ہے، پہلے ڈسپلے کیس 1-3 سیکنڈ میں کام کرتا تھا، کیونکہ درخواست ایک اشارے پر مبنی تھی، اور اب ڈیٹا بیس ہمیشہ تمام اشارے منتخب کرتا ہے اور نتیجہ کو ٹیبلو پر واپس کرنے سے پہلے نتیجہ کو فلٹر کرتا ہے۔
نتیجے کے طور پر، ڈیش بورڈ کی رفتار تقریبا 3 گنا کم ہوگئی.
نتیجہ:
- 5 سیکنڈ - ڈیش بورڈز کو پارس کرنا، تصورات
- 15-20 سیکنڈز - ٹیبلو میں پہلے سے حساب کتاب کرنے کے ساتھ سوالات کو مرتب کرنے کی تیاری
- 35-45 سیکنڈ - SQL سوالات کی تالیف اور ہانا میں ان کے متوازی ترتیب وار عمل
- 5 سیکنڈ - ٹیبلاؤ میں نتائج کی پروسیسنگ، چھانٹنا، دوبارہ گنتی کرنا
- یقیناً، اس طرح کے نتائج کاروبار کے موافق نہیں تھے، اور ہم نے اصلاح جاری رکھی۔
اسٹیج 2۔ ٹیبلو میں کم از کم منطق، مکمل مادّہ کاری
ہم سمجھ گئے کہ 10 سیکنڈ تک چلنے والے سٹور فرنٹ پر کئی سیکنڈ کے رسپانس ٹائم کے ساتھ ڈیش بورڈ بنانا ناممکن ہے، اور ہم نے ڈیٹا بیس کی طرف خاص طور پر مطلوبہ ڈیش بورڈ کے لیے ڈیٹا کو عملی شکل دینے کے اختیارات پر غور کیا۔ لیکن ہمیں اوپر بیان کردہ ایک عالمی مسئلہ کا سامنا کرنا پڑا - غیر اضافی اشارے۔ ہم اس بات کو یقینی بنانے سے قاصر تھے کہ فلٹرز یا ڈرل ڈاؤنز کو تبدیل کرتے وقت، ٹیبلو لچکدار طریقے سے مختلف اسٹور فرنٹ اور مختلف پروڈکٹ کے درجہ بندی کے لیے پہلے سے تیار کردہ لیولز کے درمیان تبدیل ہوتا ہے (مثال کے طور پر، UTE کے بغیر تین سوالات، UTE1 اور UTE2 کے ساتھ مختلف نتائج پیدا کرتے ہیں)۔ لہذا، ہم نے ڈیش بورڈ کو آسان بنانے، ڈیش بورڈ میں پروڈکٹ کے درجہ بندی کو ترک کرنے اور یہ دیکھنے کا فیصلہ کیا کہ یہ ایک آسان ورژن میں کتنی تیز ہو سکتی ہے۔
لہذا، اس آخری مرحلے پر، ہم نے ایک علیحدہ ذخیرہ جمع کیا جس میں ہم نے تمام KPIs کو ٹرانسپوزڈ شکل میں شامل کیا۔ ڈیٹا بیس کی طرف، اس طرح کے اسٹوریج کی کسی بھی درخواست پر 0,1 - 0,3 سیکنڈ میں کارروائی کی جاتی ہے۔ ڈیش بورڈ میں ہمیں درج ذیل نتائج موصول ہوئے:
پہلا افتتاح: 8-10 سیکنڈ
کوئی بھی کلک: 6-7 سیکنڈ
ٹیبلو کے ذریعے گزارے گئے وقت پر مشتمل ہے:
- 0,3 سیکنڈ - ڈیش بورڈ کی تجزیہ اور SQL سوالات کی تالیف
- 1,5-3 سیکنڈ - اہم تصورات کے لیے ہانا میں ایس کیو ایل کے سوالات پر عمل درآمد (مرحلہ 1 کے متوازی طور پر چلتا ہے)
- 1,5-2 سیکنڈ - رینڈرنگ، تصورات کی دوبارہ گنتی
- 1,3 سیکنڈ - متعلقہ فلٹر ویلیوز (برانڈ، ڈویژن، سٹی، اسٹور) حاصل کرنے کے لیے اضافی ایس کیو ایل کے سوالات پر عمل درآمد، نتائج کو پارس کرنا
مختصراً اس کا خلاصہ کرنا
ہمیں تصوراتی نقطہ نظر سے ٹیبلاؤ ٹول پسند آیا۔ پروٹو ٹائپنگ کے مرحلے پر، ہم نے مختلف ویژولائزیشن عناصر پر غور کیا اور ان سب کو لائبریریوں میں پایا، بشمول پیچیدہ ملٹی لیول سیگمنٹیشن اور ملٹی ڈرائیور واٹرفال۔
سیلز کے کلیدی اشاریوں کے ساتھ ڈیش بورڈز کو نافذ کرتے ہوئے، ہمیں کارکردگی کی مشکلات کا سامنا کرنا پڑا جن پر ہم ابھی تک قابو نہیں پا سکے۔ ہم نے دو ماہ سے زیادہ وقت گزارا اور ایک فعال طور پر نامکمل ڈیش بورڈ موصول ہوا، جس کے ردعمل کی رفتار قابل قبول ہونے کے قریب ہے۔ اور ہم نے اپنے لیے یہ نتیجہ اخذ کیا:
- ٹیبلو بڑی مقدار میں ڈیٹا کے ساتھ کام نہیں کر سکتا۔ اگر اصل ڈیٹا ماڈل میں آپ کے پاس 10 جی بی سے زیادہ ڈیٹا ہے (تقریباً 200 ملین X 50 قطاریں)، تو ڈیش بورڈ سنجیدگی سے سست ہو جائے گا - ہر کلک کے لیے 10 سیکنڈ سے کئی منٹ تک۔ ہم نے لائیو کنیکٹ اور ایکسٹریکٹ دونوں کے ساتھ تجربہ کیا۔ آپریٹنگ رفتار موازنہ ہے.
- ایک سے زیادہ اسٹوریج (ڈیٹا سیٹ) استعمال کرتے وقت حد معیاری ذرائع کا استعمال کرتے ہوئے ڈیٹاسیٹس کے درمیان تعلق کی نشاندہی کرنے کا کوئی طریقہ نہیں ہے۔ اگر آپ ڈیٹاسیٹس کو مربوط کرنے کے لیے کام کاج کا استعمال کرتے ہیں، تو یہ کارکردگی کو بہت متاثر کرے گا۔ ہمارے معاملے میں، ہم نے پہلے سے منتخب کردہ فلٹرز کو محفوظ رکھتے ہوئے ہر مطلوبہ ویو سیکشن میں ڈیٹا کو میٹریلائز کرنے اور ان میٹریلائزڈ ڈیٹاسیٹس پر سوئچ کرنے کے آپشن پر غور کیا - ٹیبلاؤ میں ایسا کرنا ناممکن ثابت ہوا۔
- ٹیبلو میں متحرک پیرامیٹرز بنانا ممکن نہیں ہے۔ آپ کسی ایسے پیرامیٹر کو نہیں بھر سکتے جو ڈیٹاسیٹ کو فلٹر کرنے کے لیے استعمال کیا جاتا ہے یا لائیو کنیکٹ کے دوران ڈیٹاسیٹ سے کسی اور انتخاب کے نتیجے یا کسی اور SQL استفسار کے نتیجے میں، صرف مقامی صارف کا ان پٹ یا مستقل۔
- OLAP|PivotTable عناصر کے ساتھ ڈیش بورڈ بنانے سے وابستہ حدود۔
MSTR، SAP SAC، SAP Analysis میں، اگر آپ کسی رپورٹ میں ڈیٹا سیٹ شامل کرتے ہیں، تو اس پر موجود تمام اشیاء بطور ڈیفالٹ ایک دوسرے سے متعلق ہوتی ہیں۔ ٹیبلو میں یہ نہیں ہے؛ کنکشن کو دستی طور پر ترتیب دیا جانا چاہیے۔ یہ شاید زیادہ لچکدار ہے، لیکن ہمارے تمام ڈیش بورڈز کے لیے یہ عناصر کے لیے ایک لازمی ضرورت ہے - اس لیے یہ اضافی لیبر لاگت ہے۔ مزید برآں، اگر آپ متعلقہ فلٹرز بناتے ہیں تاکہ، مثال کے طور پر، کسی علاقے کو فلٹر کرتے وقت، شہروں کی فہرست صرف اس خطے کے شہروں تک محدود ہو، آپ کو ڈیٹا بیس یا ایکسٹریکٹ کے لیے یکے بعد دیگرے سوالات کے ساتھ فوری طور پر ختم کر دیا جاتا ہے، جو نمایاں طور پر سست ہو جاتا ہے۔ ڈیش بورڈ - افعال میں حدود۔ بڑے پیمانے پر تبدیلیاں یا تو نچوڑ پر نہیں کی جا سکتی ہیں یا خاص طور پر، Live-connecta کے ڈیٹا سیٹ پر۔ یہ ٹیبلیو پریپ کے ذریعے کیا جا سکتا ہے، لیکن یہ اضافی کام ہے اور سیکھنے اور برقرار رکھنے کا ایک اور ٹول ہے۔ مثال کے طور پر، آپ ڈیٹا کو منتقل نہیں کر سکتے یا اسے اپنے ساتھ شامل نہیں کر سکتے۔ انفرادی کالموں یا فیلڈز پر تبدیلیوں کے ذریعے کیا بند ہوتا ہے، جسے کیس یا اگر کے ذریعے منتخب کیا جانا چاہیے، اور یہ بہت پیچیدہ SQL سوالات پیدا کرتا ہے، جس میں ڈیٹا بیس اپنا زیادہ تر وقت استفسار کے متن کو مرتب کرنے میں صرف کرتا ہے۔ ٹول کی ان لچک کو شوکیس کی سطح پر حل کرنا پڑا، جو زیادہ پیچیدہ اسٹوریج، اضافی ڈاؤن لوڈز اور تبدیلیوں کا باعث بنتا ہے۔
ہم نے ٹیبلو کو ترک نہیں کیا ہے۔ لیکن ہم ٹیبلاؤ کو صنعتی ڈیش بورڈ بنانے کے قابل ایک ٹول اور کمپنی کے پورے کارپوریٹ رپورٹنگ سسٹم کو تبدیل کرنے اور ڈیجیٹلائز کرنے کا ایک ٹول نہیں سمجھتے۔
اب ہم ایک دوسرے ٹول میں اسی طرح کے ڈیش بورڈ کو فعال طور پر تیار کر رہے ہیں اور ساتھ ہی ٹیبلاؤ میں ڈیش بورڈ کے فن تعمیر کو مزید آسان بنانے کی کوشش کر رہے ہیں۔ اگر کمیونٹی دلچسپی رکھتی ہے، تو ہم آپ کو نتائج کے بارے میں بتائیں گے۔
ہم آپ کے خیالات یا مشورے کا بھی انتظار کر رہے ہیں کہ Tabeau میں آپ ڈیٹا کی اتنی بڑی مقدار پر فوری ڈیش بورڈز کیسے بنا سکتے ہیں، کیونکہ ہمارے پاس ایک ویب سائٹ ہے جہاں ریٹیل سے کہیں زیادہ ڈیٹا موجود ہے۔
ماخذ: www.habr.com