تابلو در خرده فروشی، واقعا؟

زمان گزارش دهی در اکسل به سرعت در حال ناپدید شدن است - گرایش به ابزارهای مناسب برای ارائه و تجزیه و تحلیل اطلاعات در همه زمینه ها قابل مشاهده است. ما مدت زیادی است که به صورت داخلی در مورد دیجیتالی شدن گزارش بحث می کنیم و سیستم تجزیه و تحلیل تصویری و سلف سرویس Tableau را انتخاب کرده ایم. الکساندر بزوگلی، رئیس بخش راه حل های تحلیلی و گزارش گروه M.Video-Eldorado در مورد تجربه و نتایج ساخت داشبورد رزمی صحبت کرد.

من بلافاصله می گویم که هر آنچه که برنامه ریزی شده بود تحقق نیافته است ، اما تجربه جالب بود ، امیدوارم که برای شما نیز مفید باشد. و اگر کسی ایده ای در مورد اینکه چگونه می توان آن را بهتر انجام داد، بسیار سپاسگزار خواهم بود برای مشاوره و ایده های شما.

در زیر برش در مورد آنچه که ما با آن مواجه شدیم و چیزهایی که در مورد آن آموختیم است.

از کجا شروع کردیم؟

M.Video-Eldorado یک مدل داده به خوبی توسعه یافته دارد: اطلاعات ساختاریافته با عمق ذخیره سازی مورد نیاز و تعداد زیادی گزارش با فرم ثابت (به جزئیات بیشتر مراجعه کنید اینجا این مقاله است). از اینها، تحلیلگران یا جداول محوری یا خبرنامه های قالب بندی شده در اکسل، یا ارائه های پاورپوینت زیبا برای کاربران نهایی می سازند.

حدود دو سال پیش، به‌جای گزارش‌های با فرم ثابت، شروع به ایجاد گزارش‌های تحلیلی در SAP Analysis کردیم (یک افزونه اکسل، اساساً جدول محوری بر روی موتور OLAP). اما این ابزار قادر به پاسخگویی به نیازهای همه کاربران نبود، اکثریت همچنان از اطلاعات پردازش شده توسط تحلیلگران استفاده می کردند.

کاربران نهایی ما به سه دسته تقسیم می شوند:

مدیریت ارشد. اطالعات را به روشی خوب و واضح و قابل فهم درخواست می کند.

مدیریت میانی، کاربران پیشرفته علاقه مند به کاوش داده ها است و در صورت وجود ابزار می تواند به طور مستقل گزارش بسازد. آنها به کاربران اصلی گزارش های تحلیلی در SAP Analysis تبدیل شدند.

کاربران انبوه. آنها علاقه ای به تجزیه و تحلیل مستقل داده ها ندارند، آنها از گزارش ها با درجه آزادی محدود، در قالب خبرنامه و جداول محوری در اکسل استفاده می کنند.

ایده ما این بود که نیازهای همه کاربران را پوشش دهیم و به آنها یک ابزار واحد و راحت ارائه دهیم. تصمیم گرفتیم با مدیریت ارشد شروع کنیم. آنها برای تجزیه و تحلیل نتایج کلیدی کسب و کار به داشبوردهایی با کاربری آسان نیاز داشتند. بنابراین ، ما با Tableau شروع کردیم و ابتدا دو جهت را انتخاب کردیم: شاخص های فروش خرده فروشی و آنلاین با عمق و وسعت و وسعت تجزیه و تحلیل ، که تقریباً 80 ٪ از داده های درخواست شده توسط مدیریت عالی را پوشش می دهد.

از آنجایی که کاربران داشبورد مدیریت ارشد بودند، KPI اضافی دیگری از محصول ظاهر شد - سرعت پاسخ. هیچ کس 20 تا 30 ثانیه صبر نمی کند تا داده ها به روز شوند. ناوبری باید در عرض 4-5 ثانیه یا بهتر است فورا انجام شود. و افسوس که نتوانستیم به این مهم برسیم.

طرح داشبورد اصلی ما به این صورت است:

ایده کلیدی این است که درایورهای اصلی KPI را که در مجموع 19 مورد از آنها وجود دارد، در سمت چپ ترکیب کنید و پویایی و تفکیک آنها را بر اساس ویژگی های اصلی در سمت راست ارائه کنید. کار ساده به نظر می رسد، تجسم منطقی و قابل درک است، تا زمانی که در جزئیات فرو بروید.

جزئیات 1. حجم داده

جدول اصلی ما برای فروش سالانه حدود 300 میلیون ردیف را اشغال می کند. از آنجا که لازم است پویایی برای سال گذشته و سال قبل منعکس شود ، حجم داده های مربوط به فروش واقعی به تنهایی حدود 1 میلیارد خط است. اطلاعات مربوط به داده های برنامه ریزی شده و بلوک فروش آنلاین نیز به طور جداگانه ذخیره می شود. بنابراین ، حتی اگر ما از ستونی در حافظه DB SAP HANA استفاده کردیم ، سرعت پرس و جو با انتخاب همه شاخص ها به مدت یک هفته از ذخیره فعلی در پرواز حدود 15-20 ثانیه بود. راه حل این مشکل خود را نشان می دهد - تحقق اضافی داده ها. اما مشکلاتی نیز دارد که در ادامه در مورد آنها توضیح خواهیم داد.

جزئیات 2. شاخص های غیرافزودنی

بسیاری از KPIهای ما به تعداد دریافت‌ها مرتبط هستند. و این شاخص نشان دهنده تعداد متمایز از تعداد ردیف ها (هدر چک) است و بسته به ویژگی های انتخاب شده ، مقادیر مختلفی را نشان می دهد. به عنوان مثال، چگونه این شاخص و مشتق آن باید محاسبه شود:

برای درست کردن محاسبات خود می توانید:

• چنین شاخص هایی را در هنگام پرواز در انبار محاسبه کنید.
• محاسبات را روی کل حجم داده در Tableau انجام دهید، یعنی. در صورت درخواست در Tableau، تمام داده ها را با توجه به فیلترهای انتخاب شده در دانه بندی موقعیت دریافت ارائه دهید.
• یک ویترین واقعی ایجاد کنید که در آن همه شاخص‌ها در همه گزینه‌های نمونه که نتایج غیرافزودنی متفاوتی ارائه می‌دهند، محاسبه شوند.

واضح است که در مثال UTE1 و UTE2 ویژگی های مادی هستند که سلسله مراتب محصول را نشان می دهند. این یک چیز ثابت نیست؛ مدیریت درون شرکت از طریق آن صورت می گیرد، زیرا مدیران مختلف مسئول گروه های مختلف محصول هستند. ما در هنگام تغییر روابط ، هنگامی که یک گروه از یک گره به گره دیگر منتقل شدند ، ما در این سلسله مراتب بسیاری از این سلسله مراتب ، هنگامی که همه سطوح تغییر کردند و تغییر نقطه ثابت تغییر کرد ، داشتیم. در گزارش های متعارف ، همه اینها در پرواز از ویژگی های ماده محاسبه می شود ؛ در صورت تحقق این داده ها ، لازم است مکانیسمی برای ردیابی چنین تغییراتی و بارگیری مجدد داده های تاریخی ایجاد شود. یک کار بسیار بی اهمیت

جزئیات 3. مقایسه داده ها

این نقطه مشابه مورد قبلی است. نکته آخر این است که هنگام تجزیه و تحلیل یک شرکت ، مرسوم است که چندین سطح مقایسه با دوره قبلی را تشکیل دهیم:

مقایسه با دوره قبل (روز به روز، هفته به هفته، ماه به ماه)

در این مقایسه ، فرض بر این است که بسته به دوره انتخاب شده توسط کاربر (به عنوان مثال ، هفته 33 سال) ، باید دینامیک را تا هفته 32 نشان دهیم ؛ اگر داده ها را برای یک ماه انتخاب کردیم ، به عنوان مثال ، ممکن است ، سپس این مقایسه پویایی را تا آوریل نشان می دهد.

مقایسه با سال گذشته

نکته اصلی در اینجا این است که هنگام مقایسه بر اساس روز و هفته، شما همان روز سال گذشته را در نظر نمی گیرید، یعنی. شما نمی توانید سال جاری را منهای یک قرار دهید. باید به روز هفته ای که مقایسه می کنید نگاه کنید. برعکس، هنگام مقایسه ماهها، باید دقیقاً همان روز تقویم سال گذشته را انتخاب کنید. تفاوت های ظریف با سال های کبیسه نیز وجود دارد. در مخازن اصلی، تمام اطلاعات به صورت روز توزیع می شود؛ هیچ فیلد جداگانه ای با هفته، ماه یا سال وجود ندارد. بنابراین ، برای به دست آوردن یک مقطع تحلیلی کامل در پانل ، شما باید یک دوره را به عنوان مثال در هفته ، بلکه 4 هفته حساب کنید و سپس این داده ها را با یکدیگر مقایسه کنید ، پویایی ، انحراف را منعکس کنید. بر این اساس، این منطق برای ایجاد مقایسه در دینامیک نیز می تواند در Tableau یا در سمت فروشگاه پیاده سازی شود. بله ، و البته ما در مرحله طراحی این جزئیات را می دانستیم و فکر می کردیم ، اما پیش بینی تأثیر آنها بر عملکرد داشبورد نهایی دشوار بود.

هنگام پیاده سازی داشبورد، مسیر طولانی Agile را دنبال کردیم. وظیفه ما ارائه یک ابزار کاری با داده های لازم برای آزمایش در سریع ترین زمان ممکن بود. بنابراین، ما به سرعت رفتیم و از به حداقل رساندن کار در کنار ذخیره سازی فعلی شروع کردیم.

قسمت 1: ایمان به تابلو

برای ساده‌سازی پشتیبانی فناوری اطلاعات و اجرای سریع تغییرات، تصمیم گرفتیم منطق محاسبه شاخص‌های غیرافزودنی و مقایسه دوره‌های گذشته را در Tableau ایجاد کنیم.

مرحله 1. همه چیز زنده است، هیچ تغییری در پنجره وجود ندارد.

در این مرحله، تابلو را به ویترین های فعلی وصل کردیم و تصمیم گرفتیم ببینیم تعداد دریافتی های یک ساله چگونه محاسبه می شود.

یافته ها:

پاسخ ناامیدکننده بود - 20 دقیقه. انتقال داده از طریق شبکه، بار بالا در Tableau. ما متوجه شدیم که منطق با شاخص های غیرافزودنی باید روی هانا پیاده سازی شود. این خیلی ما را نترساند، ما قبلاً تجربه مشابهی با BO و Analysis داشتیم و می‌دانستیم که چگونه ویترین‌های سریعی را در HANA بسازیم که شاخص‌های غیرافزودنی درست محاسبه شده را تولید می‌کنند. اکنون تنها چیزی که باقی مانده بود این بود که آنها را با تابلو تنظیم کنیم.

مرحله 2. صفحه نمایش را تنظیم می کنیم، بدون تحقق، همه چیز در حال پرواز است.

ما یک ویترین جدید جداگانه ایجاد کردیم که داده های مورد نیاز را برای TABLEAU در حال پرواز تولید می کرد. به طور کلی، ما نتیجه خوبی گرفتیم؛ زمان تولید همه شاخص ها را در یک هفته به 9-10 ثانیه کاهش دادیم. و ما صادقانه انتظار داشتیم که در Tableau زمان پاسخ داشبورد در اولین دهانه 20-30 ثانیه و سپس به دلیل حافظه نهان از 10 تا 12 باشد که به طور کلی برای ما مناسب است.

یافته ها:

اولین داشبورد باز: 4-5 دقیقه
هر کلیک: 3-4 دقیقه
هیچ کس انتظار چنین افزایش اضافی در کار ویترین را نداشت.

قسمت 2. شیرجه رفتن به تابلو

مرحله 1. تجزیه و تحلیل عملکرد تابلو و تنظیم سریع

ما شروع به تجزیه و تحلیل کردیم که Tableau بیشتر وقت خود را در کجا می گذراند. و ابزارهای بسیار خوبی برای این کار وجود دارد که البته از مزایای Tableau است. مشکل اصلی که ما شناسایی کردیم پرس و جوهای SQL بسیار پیچیده ای بود که Tableau در حال ساخت آن بود. آنها در درجه اول با:

- انتقال داده ها از آنجا که Tableau ابزاری برای انتقال مجموعه داده ها ندارد ، برای ساختن سمت چپ داشبورد با نمایش دقیق همه KPI ها ، ما مجبور شدیم با استفاده از یک مورد یک جدول ایجاد کنیم. اندازه پرس و جوهای SQL در پایگاه داده به 120 کاراکتر رسید.

- انتخاب دوره زمانی چنین پرس و جو در سطح پایگاه داده زمان بیشتری برای کامپایل نسبت به اجرای آن طول کشید:

آن ها پردازش درخواست 12 ثانیه + 5 ثانیه اجرا.

ما تصمیم گرفتیم منطق محاسبات را در سمت Tableau ساده کنیم و بخشی دیگر از محاسبات را به سطح فروشگاه و پایگاه داده منتقل کنیم. این نتایج خوبی به همراه داشت.

ابتدا، جابه‌جایی را به سرعت انجام دادیم، طبق این رویکرد که در ویکی توضیح داده شد، آن را از طریق یک اتصال کامل بیرونی در مرحله نهایی محاسبه VIEW انجام دادیم. Transpose - ویکی پدیا، دانشنامه آزاد и ماتریس ابتدایی - ویکی پدیا، دانشنامه آزاد.

یعنی ما یک جدول تنظیم - یک ماتریس جابجایی (21x21) درست کردیم و همه شاخص ها را به صورت ردیف به ردیف دریافت کردیم.

این بود:


تبدیل شده است:


تقریباً هیچ زمانی برای انتقال خود پایگاه داده صرف نمی شود. درخواست برای همه شاخص های هفته در حدود 10 ثانیه ادامه یافت. اما از سوی دیگر، انعطاف پذیری در ساخت داشبورد بر اساس یک شاخص خاص، یعنی. برای سمت راست داشبورد که در آن پویایی و تفکیک دقیق یک نشانگر خاص ارائه شده است، قبلاً صفحه نمایش در 1-3 ثانیه کار می کرد، زیرا درخواست بر اساس یک اندیکاتور بود و اکنون پایگاه داده همیشه همه اندیکاتورها را انتخاب کرده و قبل از برگرداندن نتیجه به Tableau نتیجه را فیلتر می کند.

در نتیجه سرعت داشبورد تقریباً 3 برابر کاهش یافت.

یافته ها:

1. 5 ثانیه - تجزیه داشبورد، تجسم
2. 15-20 ثانیه - آماده سازی برای کامپایل کوئری ها با انجام محاسبات پیش در Tableau
3. 35-45 ثانیه - کامپایل پرس و جوهای SQL و اجرای موازی متوالی آنها در هانا
4. 5 ثانیه - پردازش نتایج، مرتب‌سازی، محاسبه مجدد تجسم‌ها در Tableau
5. البته چنین نتایجی برای کسب و کار مناسب نبود و ما بهینه سازی را ادامه دادیم.

مرحله 2. حداقل منطق در Tableau، تحقق کامل

ما فهمیدیم که ساختن داشبوردی با زمان پاسخگویی چند ثانیه در ویترین فروشگاهی که 10 ثانیه کار می کند غیرممکن است و گزینه هایی را برای تحقق داده ها در سمت پایگاه داده به طور خاص برای داشبورد مورد نیاز در نظر گرفتیم. اما ما با یک مشکل جهانی که در بالا توضیح داده شد روبرو شدیم - شاخص های غیرافزودنی. ما نتوانستیم مطمئن شویم که هنگام تغییر فیلترها یا دریل داون ها، Tableau به طور انعطاف پذیری بین ویترین های مختلف و سطوح از پیش طراحی شده برای سلسله مراتب محصولات مختلف جابجا می شود (در مثال، سه پرس و جو بدون UTE، با UTE1 و UTE2 نتایج متفاوتی ایجاد می کنند). بنابراین، تصمیم گرفتیم داشبورد را ساده کنیم، سلسله مراتب محصول را در داشبورد رها کنیم و ببینیم که در یک نسخه ساده شده چقدر می تواند سریع باشد.

بنابراین، در این مرحله آخر، ما یک مخزن جداگانه جمع آوری کردیم که در آن همه KPI ها را به شکل جابجایی اضافه کردیم. در سمت پایگاه داده، هر درخواست برای چنین فضای ذخیره سازی در 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 اضافی برای به دست آوردن مقادیر فیلتر مربوطه (برند، بخش، شهر، فروشگاه)، تجزیه نتایج

به طور خلاصه آن را جمع بندی کنم

ما ابزار Tableau را از منظر تجسم دوست داشتیم. در مرحله نمونه سازی، عناصر تجسم مختلفی را در نظر گرفتیم و همه آنها را در کتابخانه ها یافتیم، از جمله تقسیم بندی پیچیده چند سطحی و آبشار چند راننده.

هنگام پیاده سازی داشبوردهایی با شاخص های کلیدی فروش، با مشکلات عملکردی مواجه شدیم که هنوز نتوانسته ایم بر آن ها غلبه کنیم. ما بیش از دو ماه وقت گذاشتیم و داشبوردی از نظر عملکردی ناقص دریافت کردیم که سرعت پاسخگویی آن در مرز قابل قبول است. و برای خودمان نتیجه گرفتیم:

1. Tableau نمی تواند با حجم زیاد داده کار کند. اگر در مدل داده اصلی بیش از 10 گیگابایت داده (تقریباً 200 میلیون ردیف 50 10 XNUMX) داشته باشید ، داشبورد به طور جدی کند خواهد شد - از XNUMX ثانیه به چند دقیقه برای هر کلیک. ما هم با اتصال زنده و هم با استخراج آزمایش کردیم. سرعت عملیات قابل مقایسه است.
2. محدودیت در استفاده از ذخیره سازی های متعدد (مجموعه داده ها). هیچ راهی برای نشان دادن رابطه بین مجموعه داده ها با استفاده از ابزار استاندارد وجود ندارد. اگر از راه‌حل‌هایی برای اتصال مجموعه داده‌ها استفاده می‌کنید، این کار به شدت بر عملکرد تأثیر می‌گذارد. در مورد ما، ما گزینه ای را در نظر گرفتیم که داده ها را در هر بخش نمای مورد نیاز انجام دهیم و روی این مجموعه داده های تحقق یافته با حفظ فیلترهای انتخاب شده قبلی، سوئیچ ایجاد کنیم - انجام این کار در Tableau غیرممکن بود.
3. امکان ایجاد پارامترهای پویا در Tableau وجود ندارد. شما نمی توانید پارامتری را که برای فیلتر کردن یک مجموعه داده در یک استخراج یا در طول اتصال زنده استفاده می شود، با نتیجه انتخاب دیگری از مجموعه داده یا نتیجه پرس و جوی SQL دیگر، فقط ورودی کاربر بومی یا یک ثابت پر کنید.
4. محدودیت های مرتبط با ساخت داشبورد با عناصر OLAP|PivotTable.
   در MSTR، SAP SAC، SAP Analysis، اگر مجموعه داده ای را به یک گزارش اضافه کنید، تمام اشیاء روی آن به طور پیش فرض به یکدیگر مرتبط هستند. Tableau این را ندارد؛ اتصال باید به صورت دستی پیکربندی شود. این احتمالاً انعطاف‌پذیرتر است، اما برای همه داشبوردهای ما این یک الزام اجباری برای عناصر است - بنابراین این هزینه اضافی کار است. علاوه بر این ، اگر فیلترهای مرتبط را ایجاد می کنید به گونه ای که ، به عنوان مثال ، هنگام فیلتر کردن یک منطقه ، لیست شهرها فقط به شهرهای این منطقه محدود می شود ، شما بلافاصله با پرس و جوهای پی در پی به پایگاه داده یا استخراج می شوید ، که به طور قابل توجهی کند می شود داشبورد.
5. محدودیت در عملکردها تبدیل‌های انبوه را نمی‌توان بر روی استخراج یا، به‌ویژه، روی مجموعه داده Live-connecta انجام داد. این را می توان از طریق Tableau Prep انجام داد، اما کار اضافی و ابزار دیگری برای یادگیری و نگهداری است. برای مثال، نمی‌توانید داده‌ها را جابه‌جا کنید یا آن‌ها را به خودش بپیوندید. آنچه از طریق تبدیل‌های روی ستون‌ها یا فیلدهای منفرد بسته می‌شود، که باید از طریق case یا if انتخاب شوند، و این پرس‌وجوهای SQL بسیار پیچیده را ایجاد می‌کند، که در آن پایگاه داده بیشتر وقت خود را صرف کامپایل متن پرس و جو می‌کند. این انعطاف ناپذیری ابزار باید در سطح ویترین حل می شد، که منجر به ذخیره سازی پیچیده تر، بارگیری های اضافی و تغییرات می شود.

ما از Tableau دست نکشیده ایم. اما ما Tableau را ابزاری نمی‌دانیم که قادر به ساخت داشبوردهای صنعتی و ابزاری برای جایگزینی و دیجیتالی کردن کل سیستم گزارش‌دهی شرکتی است.

ما اکنون به طور فعال داشبورد مشابهی را در ابزار دیگری توسعه می‌دهیم و در همان زمان، سعی می‌کنیم معماری داشبورد را در Tableau اصلاح کنیم تا آن را حتی بیشتر ساده‌سازی کنیم. اگر جامعه علاقه مند باشد، نتایج را به شما خواهیم گفت.

ما همچنین منتظر ایده‌ها یا توصیه‌های شما هستیم که چگونه در Tabeau می‌توانید داشبوردهای سریعی را روی چنین حجم زیادی از داده بسازید، زیرا ما وب‌سایتی داریم که در آن داده‌های بسیار بیشتری نسبت به خرده‌فروشی وجود دارد.

منبع: www.habr.com