پرچون ۾ ٽيبلائو، واقعي؟

ايڪسل ۾ رپورٽنگ جو وقت تيزي سان غائب ٿي رهيو آهي - معلومات پيش ڪرڻ ۽ تجزيو ڪرڻ لاءِ آسان اوزارن جو رجحان سڀني علائقن ۾ نظر اچي رهيو آهي. اسان اندروني طور تي بحث ڪيو ويو آهي رپورٽنگ جي ڊجيٽلائيزيشن تي هڪ ڊگهي وقت تائين ۽ چونڊيو ويو آهي ٽيبليو بصري ۽ خود سروس اينالائيٽڪس سسٽم. اليگزينڊر بيزگلي، تجزياتي حل ۽ رپورٽنگ ڊپارٽمينٽ جو سربراهه M.Video-Eldorado گروپ، هڪ جنگي ڊيش بورڊ ٺاهڻ جي تجربن ۽ نتيجن بابت ڳالهايو.

مان فوري طور تي چوندس ته هر شي جيڪا رٿابندي ڪئي وئي هئي سا محسوس نه ڪئي وئي، پر تجربو دلچسپ هو، اميد اٿم ته اهو توهان لاء پڻ ڪارائتو هوندو. ۽ جيڪڏهن ڪنهن وٽ ڪا به راءِ آهي ته اهو ڪيئن بهتر ٿي سگهي ٿو، آئون توهان جي مشوري ۽ خيالن جو تمام گهڻو شڪرگذار آهيان.

هيٺ ڏنل ڪٽ جي باري ۾ آهي ته اسان ڇا ڪيو ۽ اسان ڇا سکيو.

اسان ڪٿان شروع ڪيو؟

M.Video-Eldorado وٽ هڪ سٺي ترقي يافته ڊيٽا ماڊل آهي: منظم معلومات گهربل اسٽوريج جي کوٽائي سان ۽ مقرر ٿيل فارم رپورٽن جي وڏي تعداد سان (وڌيڪ تفصيل ڏسو هي آرٽيڪل). انهن مان، تجزيه نگار يا ته پيوٽ ٽيبل ٺاهيندا آهن يا ايڪسل ۾ فارميٽ ٿيل نيوز ليٽر، يا آخري استعمال ڪندڙن لاءِ خوبصورت پاور پوائنٽ پيشيون.

اٽڪل ٻه سال اڳ، مقرر ٿيل فارم رپورٽن جي بدران، اسان SAP تجزيي ۾ تجزياتي رپورٽون ٺاهڻ شروع ڪيون (هڪ ايڪسل اضافو، بنيادي طور تي OLAP انجڻ تي هڪ پائوٽ ٽيبل). پر هي اوزار سڀني استعمال ڪندڙن جي ضرورتن کي پورو ڪرڻ جي قابل نه هو؛ اڪثريت تجزيه نگارن پاران اضافي طور تي پروسيس ڪيل معلومات استعمال ڪرڻ جاري رکي.

اسان جا آخري استعمال ڪندڙ ٽن ڀاڱن ۾ اچي وڃن ٿا:

اعلي انتظام. معلومات کي چڱي طرح پيش ڪيل ۽ واضح طور تي سمجھڻ واري انداز ۾ درخواست ڪري ٿو.

وچولي انتظام، ترقي يافته استعمال ڪندڙ. ڊيٽا جي ڳولا ۾ دلچسپي ۽ آزاد طور تي رپورٽون ٺاهڻ جي قابل آهن جيڪڏهن اوزار موجود آهن. اهي SAP تجزيي ۾ تجزياتي رپورٽن جا اهم صارف بڻجي ويا.

وڏي تعداد ۾ استعمال ڪندڙ. اهي ڊيٽا جي آزاديءَ سان تجزيو ڪرڻ ۾ دلچسپي نٿا رکن؛ اهي رپورٽون استعمال ڪندا آهن محدود حد تائين آزاديءَ سان، خبرن جي شڪل ۾ ۽ Excel ۾ pivot جدولن جي شڪل ۾.

اسان جو خيال سڀني صارفين جي ضرورتن کي ڍڪڻ ۽ انهن کي هڪ واحد، آسان اوزار ڏيڻ هو. اسان اعلي انتظام سان شروع ڪرڻ جو فيصلو ڪيو. انهن کي اهم ڪاروباري نتيجن جو تجزيو ڪرڻ لاءِ استعمال ڪرڻ ۾ آسان ڊيش بورڊ جي ضرورت هئي. تنهن ڪري، اسان ٽيبلائو سان شروع ڪيو ۽ پهريان ٻه هدايتون چونڊيون: پرچون ۽ آن لائين سيلز اشارن سان محدود کوٽائي ۽ تجزيي جي وسعت سان، جيڪي مٿين انتظاميا پاران درخواست ڪيل ڊيٽا جي لڳ ڀڳ 80٪ کي ڍڪيندا.

جيئن ته ڊيش بورڊ جا استعمال ڪندڙ اعلي انتظام هئا، پيداوار جو هڪ ٻيو اضافي KPI ظاهر ٿيو - جواب جي رفتار. ڊيٽا کي اپڊيٽ ٿيڻ لاءِ ڪو به 20-30 سيڪنڊن جو انتظار نه ڪندو. نيويگيشن 4-5 سيڪنڊن اندر ٿيڻ گهرجي، يا اڃا بهتر، فوري طور تي ڪيو وڃي. ۽ اسان، افسوس، هن کي حاصل ڪرڻ ۾ ناڪام ٿي ويا.

هي آهي جيڪو اسان جي مکيه ڊيش بورڊ جي ترتيب وانگر نظر اچي ٿو:

اهم خيال مکيه KPI ڊرائيورن کي گڏ ڪرڻ آهي، جن مان مجموعي طور تي 19 هئا، کاٻي پاسي ۽ انهن جي متحرڪ ۽ بريڪ ڊائون کي ساڄي پاسي مکيه خاصيتن ذريعي پيش ڪن ٿا. ڪم سادو لڳي ٿو، نقشو منطقي ۽ سمجھڻ وارو آھي، جيستائين توھان تفصيلن ۾ ٻڏل نه ڪريو.

تفصيل 1. ڊيٽا حجم

سالياني سيلز لاءِ اسان جي مکيه جدول لڳ ڀڳ 300 ملين قطارون لڳن ٿيون. جيئن ته اهو ضروري آهي ته گذريل سال ۽ سال اڳ جي متحرڪات کي ظاهر ڪرڻ لاء، صرف حقيقي سيلز تي ڊيٽا جو مقدار اٽڪل 1 بلين لائينون آهي. منصوبابندي ڪيل ڊيٽا تي معلومات ۽ آن لائن سيلز بلاڪ پڻ الڳ الڳ ذخيرو ٿيل آهن. تنهن ڪري، جيتوڻيڪ اسان ڪالمن ان-ميموري DB SAP HANA استعمال ڪيو، فلائي تي موجوده اسٽوريج مان هڪ هفتي لاءِ سڀني اشارن جي چونڊ سان سوال جي رفتار 15-20 سيڪنڊن جي باري ۾ هئي. هن مسئلي جو حل پاڻ کي ٻڌائي ٿو - ڊيٽا جي اضافي materialization. پر ان ۾ پڻ نقصان آهن، انهن بابت وڌيڪ هيٺ.

تفصيل 2. غير اضافي اشارا

اسان جا ڪيترائي KPIs رسيدن جي تعداد سان ڳنڍيل آهن. ۽ هي اشارو قطارن جي تعداد جي COUNT DISTINCT جي نمائندگي ڪري ٿو (هيڊر چيڪ ڪريو) ۽ ڏيکاري ٿو مختلف مقدارن تي منحصر ڪري ٿو چونڊيل خاصيتن تي. مثال طور، ڪيئن هن اشارو ۽ ان جي نڪتل حساب ڪرڻ گهرجي:

توهان جي حسابن کي درست ڪرڻ لاء، توهان ڪري سگهو ٿا:

• اسٽوريج ۾ اڏام تي اهڙن اشارن جو حساب ڪريو؛
• Tableau ۾ ڊيٽا جي پوري مقدار تي حساب ڪتاب ڪريو، يعني. ٽيبلائو ۾ درخواست تي، رسيد جي پوزيشن جي گرينولرٽي ۾ چونڊيل فلٽرن جي مطابق سڀ ڊيٽا مهيا ڪريو؛
• ھڪڙي مادي نمائش ٺاھيو جنھن ۾ سڀني اشارن کي سڀني نمونن جي اختيارن ۾ شمار ڪيو ويندو جيڪي مختلف غير اضافو نتيجا ڏين ٿا.

اهو واضح آهي ته مثال ۾ UTE1 ۽ UTE2 مادي خاصيتون آهن جيڪي پيداوار جي درجه بندي جي نمائندگي ڪن ٿيون. هي هڪ جامد شيء ناهي؛ ڪمپني جي اندر انتظاميه ان جي ذريعي ٿيندي آهي، ڇاڪاڻ ته مختلف مينيجر مختلف پراڊڪٽ گروپن جا ذميوار آهن. اسان وٽ هن درجي بندي جا ڪيترائي عالمي تجديد هئا، جڏهن سڀئي سطحون تبديل ٿي ويون، جڏهن رشتا تبديل ڪيا ويا، ۽ مسلسل نقطي تبديليون، جڏهن هڪ گروهه هڪ نوڊ کان ٻئي ڏانهن منتقل ٿيو. روايتي رپورٽنگ ۾، اهو سڀ ڪجهه مواد جي خاصيتن مان پرواز تي حساب ڪيو ويندو آهي؛ هن ڊيٽا جي مادي ٿيڻ جي صورت ۾، اهڙين تبديلين کي ٽريڪ ڪرڻ ۽ تاريخي ڊيٽا کي خودڪار طور تي ٻيهر لوڊ ڪرڻ لاء هڪ ميکانيزم تيار ڪرڻ ضروري آهي. هڪ تمام غير معمولي ڪم.

تفصيل 3. ڊيٽا جو مقابلو

هي نقطو اڳئين هڪ سان ملندڙ جلندڙ آهي. هيٺيون لڪير اهو آهي ته جڏهن هڪ ڪمپني جو تجزيو ڪيو وڃي، اهو رواج آهي ته اڳئين دور سان مقابلي جي ڪيترن ئي سطحن کي ٺاهيو وڃي:

پوئين دور سان مقابلو (ڏينهن کان ڏينهن، هفتي کان هفتي، مهيني کان مهيني)

هن مقابلي ۾، اهو فرض ڪيو ويو آهي ته صارف پاران چونڊيل مدت جي لحاظ سان (مثال طور، سال جو 33 هفتي)، اسان کي 32 هين هفتي تائين متحرڪ ڏيکارڻ گهرجي؛ جيڪڏهن اسان هڪ مهيني لاء ڊيٽا چونڊيو، مثال طور، مئي. ، پوءِ هي مقابلو اپريل تائين متحرڪ ڏيکاريندو.

گذريل سال جي مقابلي ۾

هتي بنيادي اهميت اها آهي ته جڏهن ڏينهن ۽ هفتي جي ڀيٽ ۾، توهان گذريل سال جو ساڳيو ڏينهن نه وٺي رهيا آهيو، يعني. توهان صرف موجوده سال مائنس ون نٿا رکي سگهو. توھان کي ھفتي جي ڏينھن کي ڏسڻ گھرجي جنھن جو توھان مقابلو ڪري رھيا آھيو. مھينن جي مقابلي ۾، ان جي ابتڙ، توھان کي وٺڻ جي ضرورت آھي بلڪل ساڳئي ڪئلينڊر جو گذريل سال جو ڏينھن. ليپ سالن سان گڏ nuances به آهن. اصل ذخيرن ۾، سموري معلومات ڏينهن جي حساب سان ورهائي ويندي آهي؛ هفتو، مهينن يا سالن سان الڳ الڳ شعبا نه هوندا آهن. تنهن ڪري، پينل ۾ هڪ مڪمل تجزياتي ڪراس-سيڪشن حاصل ڪرڻ لاء، توهان کي هڪ مدت نه ڳڻڻ جي ضرورت آهي، مثال طور هڪ هفتي، پر 4 هفتا، ۽ پوء انهن ڊيٽا کي موازنہ ڪريو، متحرڪات، انحراف کي ظاهر ڪن ٿا. ان جي مطابق، متحرڪ ۾ موازن پيدا ڪرڻ لاء هي منطق پڻ لاڳو ٿي سگھي ٿو يا ته ٽيبلو ۾ يا اسٽور فرنٽ جي پاسي تي. ها، ۽ يقيناً اسان ڄاڻون ٿا ۽ انهن تفصيلن بابت ڊزائين اسٽيج تي سوچيو، پر حتمي ڊيش بورڊ جي ڪارڪردگي تي انهن جي اثر جي اڳڪٿي ڪرڻ ڏکيو هو.

جڏهن ڊيش بورڊ کي لاڳو ڪرڻ، اسان ڊگهي Agile رستي جي پيروي ڪئي. اسان جو ڪم هو هڪ ڪم ڪندڙ اوزار مهيا ڪرڻ لاء ضروري ڊيٽا سان گڏ جيترو جلدي ممڪن ٿي سگهي. تنهن ڪري، اسان اسپرنٽ ۾ ويا ۽ موجوده اسٽوريج جي پاسي تي ڪم کي گھٽائڻ کان شروع ڪيو.

حصو 1: ٽيبلائو ۾ ايمان

آئي ٽي سپورٽ کي آسان ڪرڻ ۽ تبديلين کي تڪڙو لاڳو ڪرڻ لاءِ، اسان فيصلو ڪيو ته غير اضافي اشارن کي ڳڻڻ ۽ ٽيبلائو ۾ گذريل دورن جي مقابلي لاءِ منطق.

اسٽيج 1. هر شيءِ لائيو آهي، ونڊو ۾ ڪا به ترميم ناهي.

هن مرحلي تي، اسان ٽيبلو کي موجوده اسٽور فرنٽ سان ڳنڍيو ۽ اهو ڏسڻ جو فيصلو ڪيو ته هڪ سال جي رسيدن جو تعداد ڪيئن ڳڻيو ويندو.

نتيجو

جواب مايوس ڪندڙ هو - 20 منٽ. نيٽ ورڪ تي ڊيٽا جي منتقلي، ٽيبل تي اعلي لوڊ. اسان محسوس ڪيو ته HANA تي غير اضافي اشارن سان منطق کي لاڳو ڪرڻ جي ضرورت آهي. اهو اسان کي گهڻو خوفزده نه ڪيو، اسان اڳ ۾ ئي BO ۽ تجزيي سان ساڳيو تجربو ڪيو هو ۽ اسان ڄاڻون ٿا ته HANA ۾ تيز نمائش ڪيئن ٺاهي سگهون ٿا جيڪي صحيح حساب سان غير اضافو اشاري پيدا ڪن ٿا. هاڻي باقي بچيو هو ته انهن کي ٽيبلو ۾ ترتيب ڏيو.

اسٽيج 2. اسان ڊسپلي ڪيسن کي ٽيون ڪريون ٿا، ڪابه مادي نه آهي، هر شي اڏامي تي.

اسان ھڪ الڳ نئون شوڪيس ٺاھيو آھي جنھن تيار ڪيو گھربل ڊيٽا TABLEAU لاءِ پرواز تي. عام طور تي، اسان سٺو نتيجو حاصل ڪيو؛ اسان هڪ هفتي ۾ سڀني اشارن کي 9-10 سيڪنڊن ۾ پيدا ڪرڻ جو وقت گھٽائي ڇڏيو. ۽ اسان ايمانداري سان توقع ڪئي ته ٽيبلو ۾ ڊيش بورڊ جو جوابي وقت 20-30 سيڪنڊ هوندو پهرين افتتاح تي ۽ پوءِ 10 کان 12 تائين ڪيش جي ڪري، جيڪو عام طور تي اسان لاءِ مناسب هوندو.

نتيجو

پهريون اوپن ڊيش بورڊ: 4-5 منٽ
ڪو به ڪلڪ ڪريو: 3-4 منٽ
ڪنهن کي به توقع نه هئي ته اسٽور فرنٽ جي ڪم ۾ اهڙي اضافي اضافو.

حصو 2. ٽيبلائو ۾ غوطا

اسٽيج 1. ٽيبلائو ڪارڪردگي جو تجزيو ۽ تڪڙي ٽيوننگ

اسان تجزيو ڪرڻ شروع ڪيو جتي ٽيبلو گهڻو وقت گذاريندو آهي. ۽ هن لاء ڪافي سٺا اوزار آهن، جيڪي، يقينا، ٽيبلو جو هڪ پلس آهي. بنيادي مسئلو جنهن جي اسان نشاندهي ڪئي هئي تمام پيچيده SQL سوالون جيڪي ٽيبلو ٺاهي رهيا هئا. اهي بنيادي طور تي لاڳاپيل هئا:

- ڊيٽا جي منتقلي. جيئن ته Tableau وٽ ڊيٽا سيٽن کي منتقل ڪرڻ لاءِ اوزار نه آهن، ڊيش بورڊ جي کاٻي پاسي کي سڀني KPIs جي تفصيلي نمائندگي سان گڏ ڪرڻ لاءِ، اسان کي هڪ ڪيس استعمال ڪندي ٽيبل ٺاهڻو پوندو. ڊيٽابيس ۾ SQL سوالن جي ماپ 120 اکرن تائين پهچي وئي.

- وقت جي چونڊ. ڊيٽابيس جي سطح تي اهڙي سوال تي عمل ڪرڻ جي ڀيٽ ۾ مرتب ڪرڻ ۾ وڌيڪ وقت ورتو:

اهي. درخواست پروسيسنگ 12 سيڪنڊ + 5 سيڪنڊ عملدرآمد.

اسان فيصلو ڪيو ته حساب ڪتاب جي منطق کي جدول جي پاسي تي آسان بڻايو وڃي ۽ حساب جي ٻئي حصي کي اسٽور فرنٽ ۽ ڊيٽابيس جي سطح تي منتقل ڪيو وڃي. اهو سٺو نتيجا کڻي آيو.

پهرين، اسان اڏام تي منتقلي ڪئي، اسان ان کي مڪمل ٻاهرئين جوڙ ذريعي ڪيو VIEW حساب ڪتاب جي آخري مرحلي ۾، وڪي تي بيان ڪيل هن طريقي جي مطابق. ٽرانسپوز - وڪيپيڊيا، آزاد انسائيڪلوپيڊيا и ايليمينٽري ميٽرڪس - وڪيپيڊيا، آزاد انسائيڪلوپيڊيا.

اهو آهي، اسان هڪ سيٽنگ ٽيبل ٺاهيو - هڪ ٽرانسپشن ميٽرڪس (21x21) ۽ سڀني اشارن کي قطار جي قطار جي ڀڃڪڙي ۾ حاصل ڪيو.

هو:


اهو ٿيو:


تقريبن ڪو به وقت ڊيٽابيس جي منتقلي تي خرچ نه ڪيو ويو آهي. هفتي لاءِ سڀني اشارن جي درخواست تقريباً 10 سيڪنڊن ۾ جاري رهي. پر ٻئي طرف، هڪ مخصوص اشاري جي بنياد تي ڊيش بورڊ ٺاهڻ جي لحاظ کان لچڪ وڃائي وئي آهي، يعني. ڊيش بورڊ جي ساڄي پاسي لاءِ جتي هڪ مخصوص اشاري جي متحرڪ ۽ تفصيلي بريڪ ڊائون پيش ڪيو ويو آهي، اڳ ۾ ڊسپلي ڪيس 1-3 سيڪنڊن ۾ ڪم ڪندو هو، ڇاڪاڻ ته درخواست هڪ اشاري تي ٻڌل هئي، ۽ هاڻي ڊيٽابيس هميشه سڀني اشارن کي چونڊيو ۽ نتيجو کي ٽيبليو ڏانهن موٽڻ کان اڳ نتيجو فلٽر ڪيو.

نتيجي طور، ڊيش بورڊ جي رفتار تقريبا 3 ڀيرا گھٽجي وئي.

نتيجو

1. 5 سيڪنڊ - ڊيش بورڊ پارس ڪرڻ، بصريات
2. 15-20 سيڪنڊ - ٽيبلائو ۾ اڳڪٿي ڪرڻ سان گڏ سوالن کي گڏ ڪرڻ جي تياري
3. 35-45 سيڪنڊ - SQL سوالن جو تاليف ۽ هانا ۾ انهن جي متوازي ترتيب واري عمل
4. 5 سيڪنڊ - نتيجن جي پروسيسنگ، ترتيب ڏيڻ، ٽيبليو ۾ تصورات کي ٻيهر ڳڻڻ
5. يقينا، اهڙا نتيجا ڪاروبار لاء مناسب نه هئا، ۽ اسان اصلاح جاري رکي.

اسٽيج 2. ٽيبلائو ۾ گھٽ ۾ گھٽ منطق، مڪمل مواد سازي

اسان سمجھيو ته ڊش بورڊ ٺاھڻ ناممڪن آھي جنھن جي جوابي وقت سان ھڪ اسٽور فرنٽ تي ڪيترن ئي سيڪنڊن جو جيڪو 10 سيڪنڊن تائين ھلندو آھي، ۽ اسان خاص طور تي گهربل ڊيش بورڊ لاءِ ڊيٽابيس جي پاسي ڊيٽا کي مادي ڪرڻ لاءِ اختيارن تي غور ڪيو. پر اسان مٿي بيان ڪيل هڪ عالمي مسئلي کي منهن ڏنو - غير اضافي اشارا. اسان پڪ ڪرڻ کان قاصر هئاسين ته جڏهن فلٽر يا ڊرل ڊائونز تبديل ڪري رهيا هئاسين، ٽيبلو لچڪدار طور تي مختلف اسٽور فرنٽ ۽ ليولز جي وچ ۾ مختلف پراڊڪٽ جي درجي بندي لاءِ اڳ ۾ ٺهيل آهي (مثال طور، UTE کان سواءِ ٽي سوال، UTE1 ۽ UTE2 سان مختلف نتيجا پيدا ڪن ٿا). تنهن ڪري، اسان ڊيش بورڊ کي آسان ڪرڻ جو فيصلو ڪيو، ڊيش بورڊ ۾ پراڊڪٽ جي درجه بندي کي ڇڏي ڏيو ۽ ڏسو ته اهو ڪيترو تيز ٿي سگهي ٿو هڪ آسان ورزن ۾.

تنهن ڪري، هن آخري مرحلي تي، اسان هڪ الڳ مخزن کي گڏ ڪيو جنهن ۾ اسان سڀني KPIs کي منتقلي فارم ۾ شامل ڪيو. ڊيٽابيس جي پاسي تي، اهڙي اسٽوريج جي ڪنهن به درخواست تي عمل ڪيو ويندو آهي 0,1 - 0,3 سيڪنڊن ۾. ڊيش بورڊ ۾ اسان ھيٺ ڏنل نتيجا حاصل ڪيا.

پهريون افتتاح: 8-10 سيڪنڊ
ڪو به ڪلڪ ڪريو: 6-7 سيڪنڊ

Tableau پاران خرچ ڪيل وقت تي مشتمل آهي:

1. 0,3 سيڪنڊ - ڊيش بورڊ جي تجزيي ۽ SQL سوالن جي تاليف
2. 1,5-3 سيڪنڊ - بنيادي تصورن لاءِ هانا ۾ SQL سوالن جو عمل (قدم 1 سان متوازي هلندو آهي)
3. 1,5-2 سيڪنڊ - ڏيکاءُ، تصويرن جي ٻيهر ڳڻپ
4. 1,3 سيڪنڊ - لاڳاپيل فلٽر ويلز (برانڊ، ڊويزن، شهر، اسٽور) حاصل ڪرڻ لاءِ اضافي SQL سوالن تي عمل ڪرڻ، نتيجن کي پارس ڪرڻ

ان کي مختصر ڪرڻ لاء

اسان کي پسند ڪيو ٽيبلائو ٽول هڪ بصري نقطه نظر کان. پروٽوٽائپنگ اسٽيج تي، اسان مختلف بصري عناصر تي غور ڪيو ۽ انهن سڀني کي لئبرري ۾ مليو، جنهن ۾ پيچيده ملٽي ليول سيگمينٽيشن ۽ ملٽي ڊرائيور آبشار شامل آهن.

اهم سيلز اشارن سان ڊيش بورڊز کي لاڳو ڪرڻ دوران، اسان کي ڪارڪردگي جي مشڪلاتن کي منهن ڏيڻو پيو، جيڪي اسان اڃا تائين قابو نه ڪري سگهيا آهيون. اسان ٻن مهينن کان وڌيڪ گذاريو ۽ هڪ فنڪشنل طور تي نامڪمل ڊيش بورڊ حاصل ڪيو، جنهن جي جواب جي رفتار قابل قبول آهي. ۽ اسان پاڻ لاءِ نتيجو ڪڍيو:

1. Tableau ڊيٽا جي وڏي مقدار سان ڪم نٿو ڪري سگهي. جيڪڏهن اصل ڊيٽا ماڊل ۾ توهان وٽ 10 GB کان وڌيڪ ڊيٽا آهي (تقريبن 200 ملين X 50 قطارون)، ته پوءِ ڊيش بورڊ سنجيده سست ٿي ويندو - هر ڪلڪ لاءِ 10 سيڪنڊن کان ڪيترن منٽن تائين. اسان ٻنهي لائيو-ڪنيڪٽ ۽ ڪڍڻ سان تجربو ڪيو. آپريٽنگ جي رفتار برابر آهي.
2. حدون جڏهن استعمال ڪندي گھڻن اسٽوريج (ڊيٽا سيٽ). معياري وسيلا استعمال ڪندي ڊيٽا سيٽ جي وچ ۾ تعلق ظاهر ڪرڻ جو ڪو طريقو ناهي. جيڪڏهن توهان ڊيٽا سيٽن کي ڳنڍڻ لاءِ ڪم ڪارون استعمال ڪندا آهيو، اهو ڪارڪردگي تي تمام گهڻو اثر انداز ٿيندو. اسان جي صورت ۾، اسان ڊيٽا کي مادي ڪرڻ جي اختيار تي غور ڪيو ھر گھربل ڏسڻ واري حصي ۾ ۽ انھن مادي ٿيل ڊيٽا سيٽن تي سوئچ ڪرڻ جي دوران اڳي چونڊيل فلٽرن کي محفوظ ڪندي - اھو ممڪن ٿي ويو ٽيبلائو ۾ ڪرڻ ناممڪن.
3. ٽيبلائو ۾ متحرڪ پيٽرولر ٺاهڻ ممڪن ناهي. توهان هڪ پيٽرول کي نه ڀري سگهو ٿا جيڪو ڊيٽا سيٽ کي فلٽر ڪرڻ لاءِ استعمال ڪيو ويو آهي اقتباس ۾ يا هڪ لائيو-ڪنيڪٽ دوران ڊيٽا سيٽ مان ڪنهن ٻئي چونڊ جي نتيجي سان يا ڪنهن ٻئي SQL سوال جي نتيجي ۾، صرف اصلي صارف ان پٽ يا هڪ مستقل.
4. OLAP|PivotTable عناصر سان ڊيش بورڊ ٺاهڻ سان لاڳاپيل حدون.
   MSTR، SAP SAC، SAP Analysis ۾، جيڪڏھن توھان ھڪڙي ڊيٽا سيٽ کي ھڪڙي رپورٽ ۾ شامل ڪريو، پوء ان تي سڀ شيون ھڪڙي ٻئي سان ڊفالٽ سان لاڳاپيل آھن. Tableau ۾ هي نه آهي؛ ڪنيڪشن کي دستي طور تي ترتيب ڏيڻ گهرجي. اهو شايد وڌيڪ لچڪدار آهي، پر اسان جي سڀني ڊيش بورڊن لاءِ اهو عنصرن لاءِ لازمي گهربل آهي - تنهنڪري هي اضافي مزدورن جي قيمت آهي. ان کان علاوه، جيڪڏهن توهان لاڳاپيل فلٽر ٺاهيندا آهيو ته جيئن، مثال طور، هڪ علائقي کي فلٽر ڪرڻ وقت، شهرن جي فهرست صرف هن علائقي جي شهرن تائين محدود آهي، توهان فوري طور تي ڊيٽابيس ڏانهن لڳاتار سوالن سان ختم ڪيو يا ڪڍيو، جيڪو خاص طور تي سست ٿئي ٿو. ڊيش بورڊ.
5. افعال ۾ حدون. وڏي پئماني تي تبديليون نه ٿي ڪري سگھجن ٿيون يا ته اقتباس تي يا، خاص طور تي، Live-connecta کان ڊيٽا سيٽ تي. اهو ڪري سگهجي ٿو Tableau Prep ذريعي، پر اهو اضافي ڪم آهي ۽ سکڻ ۽ برقرار رکڻ لاءِ هڪ ٻيو اوزار. مثال طور، توهان ڊيٽا کي منتقل نه ڪري سگهو ٿا يا ان کي پاڻ سان شامل نه ٿا ڪري سگهو. انفرادي ڪالمن يا فيلڊز تي تبديلين جي ذريعي ڇا بند ڪيو ويو آهي، جيڪو لازمي طور تي ڪيس يا جيڪڏهن چونڊيو وڃي ٿو، ۽ اهو تمام پيچيده SQL سوالن کي پيدا ڪري ٿو، جنهن ۾ ڊيٽابيس گهڻو وقت خرچ ڪري ٿو سوال جي متن کي گڏ ڪرڻ ۾. اوزار جي ان لچڪ کي شوڪيس سطح تي حل ڪيو وڃي ٿو، جيڪو وڌيڪ پيچيده اسٽوريج، اضافي ڊائون لوڊ ۽ تبديلين جي ڪري ٿي.

اسان ٽيبلائو کي نه ڇڏيو آهي. پر اسان Tableau کي هڪ اوزار نه ٿا سمجهون جيڪو صنعتي ڊيش بورڊ ٺاهڻ جي قابل آهي ۽ هڪ اوزار جنهن سان ڪمپني جي پوري ڪارپوريٽ رپورٽنگ سسٽم کي تبديل ڪرڻ ۽ ڊجيٽلائيز ڪرڻ.

اسان ھاڻي چالو ڪري رھيا آھيون ھڪڙي ساڳي ڊيش بورڊ کي ھڪ ٻئي ٽول ۾ ۽، ساڳئي وقت، ڪوشش ڪري رھيا آھيون ڊيش بورڊ جي فن تعمير کي جدول ۾ ان کي وڌيڪ آسان ڪرڻ لاءِ. جيڪڏهن ڪميونٽي ۾ دلچسپي آهي، اسان توهان کي نتيجن بابت ٻڌائينداسين.

اسان توهان جي خيالن يا مشوري جو پڻ انتظار ڪري رهيا آهيون ته ڪيئن Tabeau ۾ توهان ڊيٽا جي وڏي مقدار تي تڪڙو ڊيش بورڊ ٺاهي سگهو ٿا، ڇاڪاڻ ته اسان وٽ هڪ ويب سائيٽ آهي جتي پرچون جي ڀيٽ ۾ تمام گهڻو ڊيٽا آهي.

جو ذريعو: www.habr.com