খুচরো মূকনাট্য, সত্যিই?

এক্সেলে রিপোর্ট করার সময় দ্রুত অদৃশ্য হয়ে যাচ্ছে - তথ্য উপস্থাপন ও বিশ্লেষণের জন্য সুবিধাজনক টুলের দিকে প্রবণতা সব ক্ষেত্রেই দৃশ্যমান। আমরা দীর্ঘদিন ধরে প্রতিবেদনের ডিজিটালাইজেশন নিয়ে অভ্যন্তরীণভাবে আলোচনা করছি এবং মূকনাট্য ভিজ্যুয়ালাইজেশন এবং স্ব-পরিষেবা বিশ্লেষণ পদ্ধতি বেছে নিয়েছি। M.Video-Eldorado গ্রুপের বিশ্লেষণাত্মক সমাধান এবং রিপোর্টিং বিভাগের প্রধান আলেকজান্ডার বেজুগলি, একটি যুদ্ধ ড্যাশবোর্ড তৈরির অভিজ্ঞতা এবং ফলাফল সম্পর্কে কথা বলেছেন।

আমি এখনই বলব যে পরিকল্পনা করা সমস্ত কিছু বাস্তবায়িত হয়নি, তবে অভিজ্ঞতাটি আকর্ষণীয় ছিল, আমি আশা করি এটি আপনার জন্যও কার্যকর হবে। এবং যদি কারো কোন ধারণা থাকে যে এটি কীভাবে আরও ভাল করা যায়, আমি আপনার পরামর্শ এবং ধারণার জন্য খুব কৃতজ্ঞ থাকব।

আমরা কি সম্মুখীন হয়েছি এবং আমরা কি শিখেছি সে সম্পর্কে কাটা নীচে রয়েছে।

আমরা কোথা থেকে শুরু করলাম

M.Video-Eldorado-এর একটি সু-উন্নত ডেটা মডেল রয়েছে: প্রয়োজনীয় স্টোরেজ গভীরতা সহ কাঠামোগত তথ্য এবং বিপুল সংখ্যক স্থায়ী-ফর্ম রিপোর্ট (আরো বিশদ বিবরণ দেখুন এই নিবন্ধটি) এগুলি থেকে, বিশ্লেষকরা হয় পিভট টেবিল বা এক্সেলের ফর্ম্যাট করা নিউজলেটার বা শেষ ব্যবহারকারীদের জন্য সুন্দর পাওয়ারপয়েন্ট উপস্থাপনা তৈরি করে।

প্রায় দুই বছর আগে, ফিক্সড-ফর্ম রিপোর্টের পরিবর্তে, আমরা SAP বিশ্লেষণে (একটি এক্সেল অ্যাড-অন, মূলত OLAP ইঞ্জিনের উপর একটি পিভট টেবিল) বিশ্লেষণাত্মক প্রতিবেদন তৈরি করা শুরু করেছিলাম। কিন্তু এই টুলটি সমস্ত ব্যবহারকারীর চাহিদা মেটাতে সক্ষম ছিল না; বেশিরভাগই বিশ্লেষকদের দ্বারা প্রক্রিয়াকৃত তথ্য ব্যবহার করতে থাকে।

আমাদের শেষ ব্যবহারকারীরা তিনটি বিভাগে পড়ে:

শীর্ষ ব্যবস্থাপনা. একটি ভাল-উপস্থাপিত এবং স্পষ্টভাবে বোধগম্য পদ্ধতিতে তথ্যের অনুরোধ করে।

মধ্যম ব্যবস্থাপনা, উন্নত ব্যবহারকারী। ডেটা অন্বেষণে আগ্রহী এবং টুল উপলব্ধ থাকলে স্বাধীনভাবে প্রতিবেদন তৈরি করতে সক্ষম। তারা SAP বিশ্লেষণে বিশ্লেষণাত্মক প্রতিবেদনের মূল ব্যবহারকারী হয়ে উঠেছে।

ব্যাপক ব্যবহারকারী. তারা স্বাধীনভাবে ডেটা বিশ্লেষণে আগ্রহী নয়; তারা এক্সেলের নিউজলেটার এবং পিভট টেবিলের বিন্যাসে সীমিত মাত্রার স্বাধীনতা সহ রিপোর্ট ব্যবহার করে।

আমাদের ধারণা ছিল সমস্ত ব্যবহারকারীর চাহিদা পূরণ করা এবং তাদের একটি একক, সুবিধাজনক টুল দেওয়া। আমরা শীর্ষ ব্যবস্থাপনা দিয়ে শুরু করার সিদ্ধান্ত নিয়েছি। মূল ব্যবসায়িক ফলাফল বিশ্লেষণ করতে তাদের সহজে ব্যবহারযোগ্য ড্যাশবোর্ডের প্রয়োজন ছিল। সুতরাং, আমরা মূকনাট্য দিয়ে শুরু করেছি এবং প্রথমে দুটি দিক বেছে নিয়েছি: সীমিত গভীরতা এবং বিশ্লেষণের প্রস্থ সহ খুচরা এবং অনলাইন বিক্রয় সূচক, যা শীর্ষ ব্যবস্থাপনার অনুরোধকৃত ডেটার প্রায় 80% কভার করবে।

যেহেতু ড্যাশবোর্ডের ব্যবহারকারীরা শীর্ষ পরিচালন ছিল, পণ্যটির আরেকটি অতিরিক্ত কেপিআই উপস্থিত হয়েছিল - প্রতিক্রিয়া গতি। ডেটা আপডেট হওয়ার জন্য কেউ 20-30 সেকেন্ড অপেক্ষা করবে না। নেভিগেশন 4-5 সেকেন্ডের মধ্যে করা উচিত ছিল, বা আরও ভাল, তাত্ক্ষণিকভাবে করা উচিত। এবং আমরা, হায়, এটি অর্জন করতে ব্যর্থ হয়েছে.

আমাদের প্রধান ড্যাশবোর্ডের লেআউটটি দেখতে এইরকম ছিল:

মূল ধারণাটি হল প্রধান কেপিআই ড্রাইভারগুলিকে একত্রিত করা, যার মধ্যে মোট 19টি ছিল, বাম দিকে এবং ডানদিকে প্রধান বৈশিষ্ট্যগুলির দ্বারা তাদের গতিশীলতা এবং ভাঙ্গন উপস্থাপন করা। কাজটি সহজ বলে মনে হচ্ছে, ভিজ্যুয়ালাইজেশনটি যৌক্তিক এবং বোধগম্য, যতক্ষণ না আপনি বিশদ বিবরণে ডুব দেন।

বিস্তারিত 1. ডেটা ভলিউম

বার্ষিক বিক্রয়ের জন্য আমাদের প্রধান টেবিলে প্রায় 300 মিলিয়ন সারি রয়েছে। যেহেতু গত বছর এবং আগের বছরের জন্য গতিশীলতা প্রতিফলিত করা প্রয়োজন, শুধুমাত্র প্রকৃত বিক্রয়ের ডেটার পরিমাণ প্রায় 1 বিলিয়ন লাইন। পরিকল্পিত ডেটা এবং অনলাইন বিক্রয় ব্লকের তথ্যও আলাদাভাবে সংরক্ষণ করা হয়। অতএব, যদিও আমরা কলামার ইন-মেমরি ডিবি এসএপি হানা ব্যবহার করেছি, ফ্লাইতে বর্তমান স্টোরেজ থেকে এক সপ্তাহের জন্য সমস্ত সূচক নির্বাচনের সাথে প্রশ্নের গতি ছিল প্রায় 15-20 সেকেন্ড। এই সমস্যার সমাধান নিজেই পরামর্শ দেয় - ডেটার অতিরিক্ত বাস্তবায়ন। তবে এর ক্ষতিও রয়েছে, নীচে সেগুলি সম্পর্কে আরও।

বিস্তারিত 2. নন-অ্যাডিটিভ সূচক

আমাদের অনেক কেপিআই প্রাপ্তির সংখ্যার সাথে আবদ্ধ। এবং এই সূচকটি সারির সংখ্যার COUNTটি আলাদা প্রতিনিধিত্ব করে (চেক হেডার) এবং নির্বাচিত বৈশিষ্ট্যগুলির উপর নির্ভর করে বিভিন্ন পরিমাণ দেখায়। উদাহরণস্বরূপ, কীভাবে এই সূচক এবং এর ডেরিভেটিভ গণনা করা উচিত:

আপনার গণনা সঠিক করতে, আপনি করতে পারেন:

• সঞ্চয়স্থানে উড়তে এই ধরনের সূচকগুলি গণনা করুন;
• মূকনায় ডেটার সম্পূর্ণ ভলিউমের উপর গণনা সম্পাদন করুন, যেমন মূকনামে অনুরোধের ভিত্তিতে, রসিদ অবস্থানের গ্রানুলারিটিতে নির্বাচিত ফিল্টার অনুসারে সমস্ত ডেটা সরবরাহ করুন;
• একটি বস্তুগত শোকেস তৈরি করুন যেখানে সমস্ত সূচকগুলি সমস্ত নমুনা বিকল্পগুলিতে গণনা করা হবে যা বিভিন্ন অ-সংযোজন ফলাফল দেয়৷

এটা স্পষ্ট যে উদাহরণে UTE1 এবং UTE2 হল উপাদানের গুণাবলী যা পণ্যের শ্রেণিবিন্যাসের প্রতিনিধিত্ব করে। এটি একটি স্থির জিনিস নয়; কোম্পানির মধ্যে ব্যবস্থাপনা এটির মাধ্যমে সঞ্চালিত হয়, কারণ বিভিন্ন ম্যানেজার বিভিন্ন পণ্য গ্রুপের জন্য দায়ী। আমাদের এই অনুক্রমের অনেকগুলি বিশ্বব্যাপী সংশোধন ছিল, যখন সমস্ত স্তর পরিবর্তিত হয়, যখন সম্পর্কগুলি সংশোধন করা হয়, এবং ধ্রুবক বিন্দু পরিবর্তন হয়, যখন একটি গ্রুপ এক নোড থেকে অন্য নোডে চলে যায়। প্রচলিত প্রতিবেদনে, এই সমস্ত উপাদানের বৈশিষ্ট্যগুলি থেকে ফ্লাইতে গণনা করা হয়; এই ডেটার বাস্তবায়নের ক্ষেত্রে, এই জাতীয় পরিবর্তনগুলি ট্র্যাক করার এবং স্বয়ংক্রিয়ভাবে ঐতিহাসিক ডেটা পুনরায় লোড করার জন্য একটি প্রক্রিয়া বিকাশ করা প্রয়োজন। একটি খুব অ তুচ্ছ কাজ.

বিস্তারিত 3. ডেটা তুলনা

এই বিন্দু আগের এক অনুরূপ. নীচের লাইন হল যে একটি কোম্পানি বিশ্লেষণ করার সময়, এটি পূর্ববর্তী সময়ের সাথে তুলনা করার বিভিন্ন স্তর গঠন করার প্রথাগত:

পূর্ববর্তী সময়ের সাথে তুলনা (দিন থেকে দিন, সপ্তাহ থেকে সপ্তাহ, মাস থেকে মাসে)

এই তুলনাতে, এটি ধরে নেওয়া হয় যে ব্যবহারকারীর দ্বারা নির্বাচিত সময়ের উপর নির্ভর করে (উদাহরণস্বরূপ, বছরের 33 তম সপ্তাহ), আমাদের 32 তম সপ্তাহের মধ্যে গতিশীলতা দেখাতে হবে; যদি আমরা এক মাসের জন্য ডেটা নির্বাচন করি, উদাহরণস্বরূপ, মে , তাহলে এই তুলনা এপ্রিলের মধ্যে গতিশীলতা দেখাবে।

গত বছরের সাথে তুলনা

এখানে প্রধান সূক্ষ্মতা হল যে দিন এবং সপ্তাহ দ্বারা তুলনা করার সময়, আপনি গত বছরের একই দিন নিচ্ছেন না, অর্থাৎ আপনি শুধু বর্তমান বছরকে বিয়োগ করতে পারবেন না। আপনি তুলনা করছেন সপ্তাহের দিন দেখতে হবে. মাসের তুলনা করার সময়, বিপরীতে, আপনাকে গত বছরের ঠিক একই ক্যালেন্ডার দিন নিতে হবে। অধিবর্ষের সাথে সূক্ষ্মতাও রয়েছে। মূল সংগ্রহস্থলগুলিতে, সমস্ত তথ্য দিনে বিতরণ করা হয়; সপ্তাহ, মাস বা বছর সহ কোনও পৃথক ক্ষেত্র নেই। অতএব, প্যানেলে একটি সম্পূর্ণ বিশ্লেষণাত্মক ক্রস-সেকশন পেতে, আপনাকে একটি সময়কাল গণনা করতে হবে না, উদাহরণস্বরূপ এক সপ্তাহ, কিন্তু 4 সপ্তাহ, এবং তারপরে এই ডেটা তুলনা করুন, গতিবিদ্যা, বিচ্যুতিগুলি প্রতিফলিত করুন। তদনুসারে, গতিবিদ্যায় তুলনা তৈরির জন্য এই যুক্তিটি মূকনাট্যে বা স্টোরফ্রন্টের দিকেও প্রয়োগ করা যেতে পারে। হ্যাঁ, এবং অবশ্যই আমরা ডিজাইন পর্যায়ে এই বিবরণগুলি সম্পর্কে জানতাম এবং ভেবেছিলাম, কিন্তু চূড়ান্ত ড্যাশবোর্ডের কার্যকারিতার উপর তাদের প্রভাব ভবিষ্যদ্বাণী করা কঠিন ছিল।

ড্যাশবোর্ড বাস্তবায়ন করার সময়, আমরা দীর্ঘ চটপটে পথ অনুসরণ করেছি। আমাদের কাজটি ছিল যত তাড়াতাড়ি সম্ভব পরীক্ষার জন্য প্রয়োজনীয় ডেটা সহ একটি কার্যকরী সরঞ্জাম সরবরাহ করা। অতএব, আমরা স্প্রিন্টে গিয়েছিলাম এবং বর্তমান স্টোরেজের পাশে কাজ কম করা থেকে শুরু করেছি।

পার্ট 1: মূকনায় বিশ্বাস

আইটি সমর্থনকে সহজ করার জন্য এবং দ্রুত পরিবর্তনগুলি বাস্তবায়ন করার জন্য, আমরা অ-সংযোজন সূচকগুলি গণনা করার জন্য এবং মূকনায় অতীতের সময়কালের তুলনা করার জন্য যুক্তি তৈরি করার সিদ্ধান্ত নিয়েছি।

পর্যায় 1. সবকিছুই লাইভ, কোন উইন্ডো পরিবর্তন নেই।

এই পর্যায়ে, আমরা বর্তমান স্টোরফ্রন্টগুলির সাথে মূকনাটক সংযুক্ত করেছি এবং এক বছরের জন্য প্রাপ্তির সংখ্যা কীভাবে গণনা করা হবে তা দেখার সিদ্ধান্ত নিয়েছি।

ফলাফল:

উত্তরটি হতাশাজনক ছিল - 20 মিনিট। নেটওয়ার্কের উপর ডেটা স্থানান্তর, মূকনাট্যে উচ্চ লোড। আমরা বুঝতে পেরেছি যে HANA-তে নন-অ্যাডিটিভ সূচক সহ যুক্তি প্রয়োগ করা দরকার। এটি আমাদের খুব বেশি ভয় দেখায়নি, আমাদের ইতিমধ্যেই BO এবং বিশ্লেষণের অনুরূপ অভিজ্ঞতা ছিল এবং আমরা জানতাম কীভাবে HANA-তে দ্রুত শোকেস তৈরি করতে হয় যা সঠিকভাবে গণনা করা অ-সংযোজন সূচক তৈরি করে। এখন যা বাকি ছিল তা হল মূকনাটকের সাথে সামঞ্জস্য করা।

পর্যায় 2. আমরা ডিসপ্লে কেসগুলিকে টিউন করি, কোন বস্তুনিষ্ঠতা নেই, সবকিছুই উড়ছে।

আমরা একটি পৃথক নতুন শোকেস তৈরি করেছি যা ফ্লাইতে টেবিলের জন্য প্রয়োজনীয় ডেটা তৈরি করে। সাধারণভাবে, আমরা একটি ভাল ফলাফল পেয়েছি; আমরা এক সপ্তাহের মধ্যে সমস্ত সূচক তৈরি করার সময় 9-10 সেকেন্ডে কমিয়েছি। এবং আমরা সততার সাথে আশা করেছিলাম যে ট্যাবলোতে ড্যাশবোর্ডের প্রতিক্রিয়ার সময়টি প্রথম খোলার সময় 20-30 সেকেন্ড হবে এবং তারপর 10 থেকে 12 পর্যন্ত ক্যাশের কারণে, যা সাধারণভাবে আমাদের জন্য উপযুক্ত।

ফলাফল:

প্রথম ড্যাশবোর্ড খুলুন: 4-5 মিনিট
যেকোনো ক্লিক: 3-4 মিনিট
স্টোরফ্রন্টের কাজে এমন অতিরিক্ত বৃদ্ধি কেউ আশা করেনি।

পার্ট 2. মূকনাট্যে ডুব দিন

পর্যায় 1. মূকনাট্য কর্মক্ষমতা বিশ্লেষণ এবং দ্রুত টিউনিং

আমরা বিশ্লেষণ করতে শুরু করেছি যেখানে মূকনাটি তার বেশিরভাগ সময় ব্যয় করে। এবং এই জন্য বেশ ভাল সরঞ্জাম আছে, যা, অবশ্যই, মূকনাট্য একটি প্লাস. মূল সমস্যাটি আমরা চিহ্নিত করেছি খুব জটিল এসকিউএল প্রশ্ন যা মূকনাট্য তৈরি করছিল। তারা প্রাথমিকভাবে এর সাথে যুক্ত ছিল:

- ডেটা স্থানান্তর। যেহেতু ট্যাবেলোতে ডেটাসেট স্থানান্তর করার জন্য সরঞ্জাম নেই, তাই সমস্ত কেপিআইগুলির বিশদ উপস্থাপনা সহ ড্যাশবোর্ডের বাম দিকে তৈরি করতে, আমাদের একটি কেস ব্যবহার করে একটি টেবিল তৈরি করতে হয়েছিল। ডাটাবেসে SQL কোয়েরির আকার 120 অক্ষরে পৌঁছেছে।

- সময়কালের পছন্দ। ডাটাবেস স্তরে এই জাতীয় প্রশ্নটি কার্যকর করার চেয়ে কম্পাইল করতে বেশি সময় নেয়:

সেগুলো. অনুরোধ প্রসেসিং 12 সেকেন্ড + 5 সেকেন্ড এক্সিকিউশন।

আমরা টেবিলের পাশে গণনার যুক্তিকে সরল করার সিদ্ধান্ত নিয়েছি এবং গণনার আরেকটি অংশ স্টোরফ্রন্ট এবং ডাটাবেস স্তরে নিয়ে যাওয়ার সিদ্ধান্ত নিয়েছি। এটি ভাল ফলাফল এনেছে।

প্রথমত, আমরা ফ্লাইতে ট্রান্সপোজিশন করেছি, উইকিতে বর্ণিত এই পদ্ধতি অনুসারে আমরা ভিউ গণনার চূড়ান্ত পর্যায়ে সম্পূর্ণ বাইরের যোগদানের মাধ্যমে এটি করেছি। ট্রান্সপোজ - উইকিপিডিয়া, মুক্ত বিশ্বকোষ и প্রাথমিক ম্যাট্রিক্স - উইকিপিডিয়া, মুক্ত বিশ্বকোষ.

অর্থাৎ, আমরা একটি সেটিং টেবিল তৈরি করেছি - একটি ট্রান্সপোজিশন ম্যাট্রিক্স (21x21) এবং একটি সারি-বাই-সারি ব্রেকডাউনে সমস্ত সূচক পেয়েছি।

ইহা ছিল:


এটা হয়ে ওঠে:


ডাটাবেস ট্রান্সপোজিশনের জন্য প্রায় কোন সময় ব্যয় করা হয় না। সপ্তাহের জন্য সমস্ত সূচকের অনুরোধ প্রায় 10 সেকেন্ডের মধ্যে প্রক্রিয়া করা হতে থাকে। কিন্তু অন্যদিকে, একটি নির্দিষ্ট সূচকের উপর ভিত্তি করে একটি ড্যাশবোর্ড নির্মাণের ক্ষেত্রে নমনীয়তা হারিয়ে গেছে, যেমন ড্যাশবোর্ডের ডান দিকের জন্য যেখানে একটি নির্দিষ্ট সূচকের গতিশীলতা এবং বিস্তারিত ভাঙ্গন উপস্থাপন করা হয়, পূর্বে ডিসপ্লে কেস 1-3 সেকেন্ডের মধ্যে কাজ করত, কারণ অনুরোধটি একটি সূচকের উপর ভিত্তি করে করা হয়েছিল, এবং এখন ডাটাবেস সর্বদা সমস্ত সূচক নির্বাচন করে এবং ফলাফলটি টেবিলে ফেরত দেওয়ার আগে ফলাফলটি ফিল্টার করে।

ফলে ড্যাশবোর্ডের গতি প্রায় তিন গুণ কমে গেছে।

ফলাফল:

1. 5 সেকেন্ড – ড্যাশবোর্ড পার্সিং, ভিজ্যুয়ালাইজেশন
2. 15-20 সেকেন্ড - মূকনায় প্রাক-গণনা সম্পাদনের সাথে প্রশ্ন কম্পাইল করার প্রস্তুতি
3. 35-45 সেকেন্ড - এসকিউএল কোয়েরির সংকলন এবং হানায় তাদের সমান্তরাল-ক্রমিক সম্পাদন
4. 5 সেকেন্ড - ফলাফল প্রক্রিয়াকরণ, বাছাই করা, মূকনাট্যে ভিজ্যুয়ালাইজেশন পুনঃগণনা করা
5. অবশ্যই, এই ধরনের ফলাফল ব্যবসার জন্য উপযুক্ত ছিল না, এবং আমরা অপ্টিমাইজেশন অব্যাহত রেখেছি।

পর্যায় 2. মূকনাট্যে ন্যূনতম যুক্তি, সম্পূর্ণ বাস্তবায়ন

আমরা বুঝতে পেরেছিলাম যে স্টোরফ্রন্টে 10 সেকেন্ডের জন্য চলমান কয়েক সেকেন্ডের প্রতিক্রিয়ার সাথে একটি ড্যাশবোর্ড তৈরি করা অসম্ভব, এবং আমরা বিশেষত প্রয়োজনীয় ড্যাশবোর্ডের জন্য ডাটাবেস সাইডে ডেটা বাস্তবায়িত করার বিকল্পগুলি বিবেচনা করেছি। কিন্তু আমরা উপরে বর্ণিত একটি বৈশ্বিক সমস্যার সম্মুখীন হয়েছি - নন-অ্যাডিটিভ সূচক। আমরা নিশ্চিত করতে পারিনি যে ফিল্টার বা ড্রিলডাউন পরিবর্তন করার সময়, মূকনাটক নমনীয়ভাবে বিভিন্ন স্টোরফ্রন্ট এবং বিভিন্ন পণ্যের শ্রেণিবিন্যাসের জন্য পূর্ব-পরিকল্পিত স্তরের মধ্যে স্যুইচ করে (উদাহরণস্বরূপ, UTE ছাড়া তিনটি প্রশ্ন, UTE1 এবং UTE2 সহ বিভিন্ন ফলাফল তৈরি করে)। অতএব, আমরা ড্যাশবোর্ডকে সরলীকরণ করার সিদ্ধান্ত নিয়েছি, ড্যাশবোর্ডে পণ্যের শ্রেণিবিন্যাস পরিত্যাগ করেছি এবং একটি সরলীকৃত সংস্করণে এটি কত দ্রুত হতে পারে তা দেখুন।

সুতরাং, এই শেষ পর্যায়ে, আমরা একটি পৃথক সংগ্রহস্থল একত্রিত করেছি যেখানে আমরা ট্রান্সপোজড আকারে সমস্ত কেপিআই যুক্ত করেছি। ডাটাবেসের দিকে, এই ধরনের স্টোরেজের জন্য যেকোন অনুরোধ 0,1 - 0,3 সেকেন্ডের মধ্যে প্রক্রিয়া করা হয়। ড্যাশবোর্ডে আমরা নিম্নলিখিত ফলাফল পেয়েছি:

প্রথম খোলা: 8-10 সেকেন্ড
যেকোনো ক্লিক: 6-7 সেকেন্ড

মূকক দ্বারা অতিবাহিত সময় গঠিত:

1. 0,3 সেকেন্ড। — ড্যাশবোর্ড পার্সিং এবং এসকিউএল কোয়েরির সংকলন
2. 1,5-3 সেকেন্ড। — প্রধান ভিজ্যুয়ালাইজেশনের জন্য হানায় এসকিউএল কোয়েরি সম্পাদন (পদক্ষেপ 1 এর সাথে সমান্তরালভাবে চলে)
3. 1,5-2 সেকেন্ড। — রেন্ডারিং, ভিজ্যুয়ালাইজেশনের পুনঃগণনা
4. 1,3 সেকেন্ড। - প্রাসঙ্গিক ফিল্টার মান (ব্র্যান্ড, বিভাগ, শহর, স্টোর), পার্সিং ফলাফল পেতে অতিরিক্ত এসকিউএল কোয়েরি সম্পাদন

সংক্ষেপে এটা সংক্ষেপে

আমরা একটি ভিজ্যুয়ালাইজেশন দৃষ্টিকোণ থেকে মূকনাট্য টুল পছন্দ. প্রোটোটাইপিং পর্যায়ে, আমরা বিভিন্ন ভিজ্যুয়ালাইজেশন উপাদান বিবেচনা করেছি এবং জটিল মাল্টি-লেভেল সেগমেন্টেশন এবং মাল্টি-ড্রাইভার জলপ্রপাত সহ লাইব্রেরিতে সেগুলি খুঁজে পেয়েছি।

মূল বিক্রয় সূচকগুলির সাথে ড্যাশবোর্ডগুলি বাস্তবায়ন করার সময়, আমরা পারফরম্যান্স সংক্রান্ত সমস্যার সম্মুখীন হয়েছি যা আমরা এখনও কাটিয়ে উঠতে পারিনি৷ আমরা দুই মাসেরও বেশি সময় কাটিয়েছি এবং একটি কার্যকরীভাবে অসম্পূর্ণ ড্যাশবোর্ড পেয়েছি, যার প্রতিক্রিয়া গতি গ্রহণযোগ্য হওয়ার দ্বারপ্রান্তে। এবং আমরা নিজেদের জন্য উপসংহার টানা:

1. মূকনাট্য বিপুল পরিমাণ ডেটা নিয়ে কাজ করতে পারে না। যদি আসল ডেটা মডেলে আপনার কাছে 10 গিগাবাইটের বেশি ডেটা থাকে (প্রায় 200 মিলিয়ন X 50 সারি), তাহলে ড্যাশবোর্ডটি গুরুতরভাবে ধীর হয়ে যাবে - প্রতিটি ক্লিকের জন্য 10 সেকেন্ড থেকে কয়েক মিনিট পর্যন্ত। আমরা লাইভ-কানেক্ট এবং এক্সট্র্যাক্ট উভয়ের সাথে পরীক্ষা করেছি। অপারেটিং গতি তুলনীয়।
2. একাধিক স্টোরেজ (ডেটাসেট) ব্যবহার করার সময় সীমাবদ্ধতা। স্ট্যান্ডার্ড উপায় ব্যবহার করে ডেটাসেটের মধ্যে সম্পর্ক নির্দেশ করার কোন উপায় নেই। আপনি যদি ডেটাসেটগুলিকে সংযুক্ত করার জন্য সমাধান ব্যবহার করেন তবে এটি কার্যক্ষমতাকে ব্যাপকভাবে প্রভাবিত করবে। আমাদের ক্ষেত্রে, আমরা পূর্বে নির্বাচিত ফিল্টারগুলি সংরক্ষণ করার সময় প্রতিটি প্রয়োজনীয় ভিউ বিভাগে ডেটা বস্তুগতকরণ এবং এই বস্তুগত ডেটাসেটগুলিতে সুইচ করার বিকল্পটি বিবেচনা করেছি - এটি মূকনায় করা অসম্ভব বলে প্রমাণিত হয়েছিল।
3. মূকনামে গতিশীল পরামিতি তৈরি করা সম্ভব নয়। আপনি একটি প্যারামিটার পূরণ করতে পারবেন না যা একটি নির্যাস বা লাইভ-কানেক্টের সময় ডেটাসেট থেকে অন্য নির্বাচনের ফলাফল বা অন্য SQL কোয়েরির ফলাফলের সাথে একটি ডেটাসেট ফিল্টার করতে ব্যবহৃত হয়, শুধুমাত্র স্থানীয় ব্যবহারকারীর ইনপুট বা একটি ধ্রুবক।
4. OLAP|PivotTable উপাদানগুলির সাথে একটি ড্যাশবোর্ড তৈরির সাথে সম্পর্কিত সীমাবদ্ধতা৷
   MSTR, SAP SAC, SAP বিশ্লেষণে, আপনি যদি একটি রিপোর্টে একটি ডেটাসেট যোগ করেন, তাহলে এটির সমস্ত বস্তু ডিফল্টরূপে একে অপরের সাথে সম্পর্কিত। মূকনামে এটি নেই; সংযোগটি ম্যানুয়ালি কনফিগার করা আবশ্যক। এটি সম্ভবত আরও নমনীয়, তবে আমাদের সমস্ত ড্যাশবোর্ডের জন্য এটি উপাদানগুলির জন্য একটি বাধ্যতামূলক প্রয়োজন - তাই এটি অতিরিক্ত শ্রম খরচ। তদুপরি, আপনি যদি সম্পর্কিত ফিল্টারগুলি তৈরি করেন যাতে, উদাহরণস্বরূপ, একটি অঞ্চল ফিল্টার করার সময়, শহরগুলির তালিকা শুধুমাত্র এই অঞ্চলের শহরগুলির মধ্যে সীমাবদ্ধ থাকে, আপনি অবিলম্বে ডেটাবেস বা এক্সট্র্যাক্টে ক্রমাগত প্রশ্নগুলির সাথে শেষ করেন, যা লক্ষণীয়ভাবে ধীর করে দেয় ড্যাশবোর্ড
5. ফাংশন মধ্যে সীমাবদ্ধতা. গণ রূপান্তরগুলি নির্যাস বা বিশেষত, লাইভ-কানেক্টার ডেটাসেটে করা যায় না। এটি মূক প্রিপের মাধ্যমে করা যেতে পারে, তবে এটি অতিরিক্ত কাজ এবং শিখতে এবং বজায় রাখার আরেকটি হাতিয়ার। উদাহরণস্বরূপ, আপনি ডেটা স্থানান্তর করতে পারবেন না বা নিজের সাথে যোগ দিতে পারবেন না। পৃথক কলাম বা ক্ষেত্রের রূপান্তরের মাধ্যমে কি বন্ধ করা হয়, যা অবশ্যই কেস বা ইফের মাধ্যমে নির্বাচন করতে হবে এবং এটি খুব জটিল SQL কোয়েরি তৈরি করে, যেখানে ডাটাবেস তার বেশিরভাগ সময় ক্যোয়ারী পাঠ্য সংকলন করতে ব্যয় করে। টুলের এই নমনীয়তা শোকেস স্তরে সমাধান করতে হয়েছিল, যা আরও জটিল স্টোরেজ, অতিরিক্ত ডাউনলোড এবং রূপান্তরের দিকে নিয়ে যায়।

আমরা মূকনাট্যের উপর ছেড়ে দিইনি। কিন্তু আমরা মূককে শিল্প ড্যাশবোর্ড তৈরি করতে সক্ষম একটি টুল এবং একটি কোম্পানির সম্পূর্ণ কর্পোরেট রিপোর্টিং সিস্টেমকে প্রতিস্থাপন এবং ডিজিটালাইজ করার একটি টুল হিসাবে বিবেচনা করি না।

আমরা এখন সক্রিয়ভাবে অন্য একটি টুলে একটি অনুরূপ ড্যাশবোর্ড বিকাশ করছি এবং একই সময়ে, মূকনায় ড্যাশবোর্ড আর্কিটেকচারটিকে আরও সহজ করার জন্য সংশোধন করার চেষ্টা করছি৷ সম্প্রদায় আগ্রহী হলে, আমরা আপনাকে ফলাফল সম্পর্কে বলব।

ট্যাবেউতে আপনি কীভাবে এত বড় ডেটার উপর দ্রুত ড্যাশবোর্ড তৈরি করতে পারেন সে সম্পর্কে আমরা আপনার ধারণা বা পরামর্শের জন্যও অপেক্ষা করছি, কারণ আমাদের একটি ওয়েবসাইট রয়েছে যেখানে খুচরা থেকে অনেক বেশি ডেটা রয়েছে।

উত্স: www.habr.com