معرفی SSAS Tabular

مقدمه

در سیستم مایکروسافت، مبحث هوش تجاری یک مبحث تک محصوله نیست و مجموعه‌ای از خصوصیات و ویژگی‌ها روی محصولات متنوع توزیع شده‌اند. دو نگرش عمده مایکروسافت در تولید مدل‌های معنایی که به واسطه دو سرویس SSAS نیز ارائه می‌شوند مدل‌های Tabular و Multidimensional هستند.
مدل معنایی Tabular از سال ۲۰۱۲ به محصولات مایکروسافت اضافه شد. بالاترین مفهوم شیئی در این مدل Database هست. مفاهیم مورد استفاده در مدلسازی تبولار بسیار شبیه به مفاهیم Database رابطه‌ای در SQL Server می‌باشند. هر Instance از SSAS Tabular می‌تواند شامل چندین دیتابیس باشد و هر دیتابیس تبولار شامل مجموعه‌ای از اشیا و داده‌هاست که فقط به یک Business Solution مربوط می‌شوند. اگر زمان گزارش سازی نیاز به چند دیتابیس پیدا کردید حتما جایی در طراحی خود اشتباه کرده اید! چون هر آنچه که نیاز دارید باید در دل یک دیتابیس وجود داشته باشد. اگر با چنین شرایطی مواجه شدید باید مدل جدیدی ایجاد کنید و تمامی مفاهیم مدل‌های دیگر که پراکنده هستند در این مدل مجتمع کنید.همانند مدل Multidimensional، برای طراحی مدل تبولار از قابلیت‌های SSDT و افزونه‌های مربوطه در محیط Visual Studio استفاده می‌شود. یک پروژه SSDT معادل یک دیتابیس در SSAS هست و پس از اتمام طراحی باید پروژه را روی Instance SSAS ، Deploy کنید. و مثل مدل Multidimensional می‌توانید بوسیله SSMS روی این مدل کوئری بزنید، دیتابیس‌ها را مدیریت کنید.
هر دیتابیس شامل چندین جدول از دیتاهاست، همونطور که گفته شد کاملا شبیه دیتابیس‌های رابطه‌ایست. هر جدول تعداد محدود و ثابتی ستون که در مرحله طراحی تعریف شده اند دارد و شامل میزان متغیری از سطرهاست. هر ستون Data Type مشخصی دارد که بارگزاری دیتا روی جداول با عمل Processing انجام می‌شود.
می‌توانید در زمان طراحی روابط جداول را تعریف کنید و روابط بین این جداول را به حالت فعال یا غیر فعال در بیاورید و دقت کنید که در زمان کوئری زدن به شکل پیشفرض از روابط فعال استفاده خواهد شد. تمام روابط می‌تواند بشکل یک به یک یا یک به چند و در نسخه اخیر ۲۰۱۹ حتی چند به چند تعریف شوند ولی فقط می‌توانند شامل یک ستون از هر طرف باشند. و البته فیلتری که بر اساس این روابط ایجاد می‌شود می‌تواند یک طرفه یا دو طرفه باشد. و نکته بسیار مهم این هست که بر خلاف Multidimensional شما اینجا نمی‌توانید از خاصیت جداول Self Reference استفاده کنید!!

بعبارتی شما در این مدل محدودیت‌هایی روی روابط دارید! اول اینکه نمی‌توانید بیشتر از یک ستون از طرفین را در رابطه دخیل کنید و دوم اینکه Recursive Relationship در این مدل تعریف نشده است و کسانی که با مدل Multidimensional و ساختار درختی آن کار کردند متوجه می‌شوند که اینجا چه تفاوتی وجود دارد. اما در نسخه‌های اخیر Tabular که توسط مایکروسافت بشدت در حال توسعه می‌باشد توابع و ابزارهای خوبی برای پردازش درختواره‌ها ایجاد شده است.
تبولار از یک Engine اساسا بر پایه Memory استفاده می‌کند که فقط یک کپی از دیتای آن را روی دیسک نگه می‌دارد تا در صورت Restart شدن دیتایی از دست نرود و بر خلاف Multidimensional که از این نظر دیتای اصلی آن روی Disk قرار دارد و برای کارایی بهتر باید Cache Warming صورت بپذیرد عمل می‌کند. و باز هم بر خلاف محیط Multidimensional که شبیه بسیاری از دیتابیس‌های رابطه‌ای دیتا را به شکل Row Based ذخیره می‌کند در سرویس تبولار از دیتابیس Column Oriented استفاده می‌شود. پس اینجا ما با ساختاری طرف هستیم که هم ستونها را بطور مجزا نگهداری می‌کند یعنی Column Store بوده و هم آنها را روی RAM نگهداری می‌کند! و این می‌تواند تاثیر بسزایی در کارایی کوئریها داشته باشد. علاوه بر اینکه از شیوه هایی برای Compress کردن دیتا استفاده میکند که این نیز در افزایش کارایی بسیار موثر است. مایکروسافت نام این انجین را xVelocity In-Memory analytics Engine قرار داد. (این انجین با نام VertiPaq که در Power Pivot مورد استفاده بود نیز در منابع موجود است و البته در زمان استفاده از پروفایلر هم با این نام روبرو خواهید شد.)
کوئری‌ها و عبارات در این مدل با زبان DAX تعریف می‌شوند، زبان اصلی مدل‌هایی که در Tabular، Power Pivot، Power BI استفاده می‌شوند.
ابزارهای سمت Client می‌توانند DAX یا MDX تولید کنند تا از مدل‌های معنایی دیتا بگیرند بدون در نظر گرفتن اینکه مدل تبولار هست یا Multidimensional. این یعنی Tabular با بسیاری از ابزارهای تولید گزارش که با محیط Multidimensional کار می‌کردند و MDX تولید می‌کنند نظیر Excel و گزارش‌های مبتنی بر Reporting Service سازگاری دارد. البته که مدل‌های Multidimensional هم با ابزارهای جدیدی چون Power BI که کوئری‌های DAX تولید می‌کنند سازگاری دارد.(هرچند محدودیت‌هایی نیز وجود دارد)
در مدل تبولار شما میتوانید ستون‌هایی را به جداول اضافه کنید که با نام Calculated Columns شناخته می‌شوند، این ستونها می‌توانند بواسطه عبارات DAX مقادیری را برای هر سطر از جدول بر اساس دیتای موجود در سایر ستون‌های جدول جاری و یا جداول دیگر دیتابیس تولید کنند. در این مدل شما می‌توانید جداولی هم برای مدل از داده‌های موجود در دیتابیس جاری مشتق کنید که به آنها Calculated Table می‌گویند. این دو در زمان Process مقادیرشان محاسبه و تامین می‌شود و پس از پردازش کاملا شبیه جداول دیگر و ستون‌های دیگر فضای مورد نیاز خود را روی حافظه اصلی اشغال خواهند کرد.

همچنین می‌توانید بوسیله DAX سنجه‌هایی (Measures) در این مدل تعریف کنید که درواقع محاسباتی است بر اساس دیتای موجود از یک یا چند ستون. در این محیط می‌توانید KPI تعریف کنید که بسیار شبیه به سنجه بوده ولی با این تفاوت که برای آن هدفی مشخص تعریف شده است و تحلیل ما بر اساس میزان اختلاف بین مقدار این سنجه با هدفیست که برای آن در بیزینس در نظر گرفته شده است.
شما می‌توانید همانند تصویر زیر در یک جدول ساختاری درختی ایجاد کنید و یک Drill path از پیش تعیین شده ارائه دهید.
با تعریف Perspective می‌توانید قسمت‌های خاصی از یک مدل پیچیده را Hide کنید و با Security roles می‌توانید دسترسی به سطرهای خاصی را برای کاربران تنظیم کنید. البته که نباید مفهوم Perspective و Security را با هم اشتباه گرفت.

چرا دو مدل داریم؟

• مدل Multidimensional در زمانی ارائه شد که سرورها هنوز روی نسخه ۳۲ بیتی بودند و با یک یا دو پردازنده و حافظه اصلی کمتر از یک گیگابایت کار می‌کردند، زمانی که دیتابیس‌ها تنها گزینه‌ای که برای ذخیره اطلاعات داشتند Disk ها بود. به هرحال با توسعه و پیشرفت سخت افزارها و نسل جدید ساختارهای دیتابیس‌های columnar و Memory-Based استانداردهای جدیدی برای کارایی در حوزه تحلیل دیتا پدید آمد و سرویس‌های آنالیز آنلاین هم باید خود را با این شرایط جدید وفق می‌دادند. ساختار جدید با مدل Multidimensional موجود چندان قابل تطبیق نبود و لازم بود برای بهره گیری مناسب از xVelocity engine مدل جدید Tabular معرفی گردد.
• برخلاف موفقیت‌هایی که Multidimensional SSAS داشت همواره این موضوع مطرح بود که یادگیری مفاهیم موجود در آن سخت است. بسیاری از افراد حرفه‌ای در زمینه دیتابیس به مدل‌های رابطه‌ای عادت داشتند و چالش درک مفاهیم چند بعدی همیشه وجود داشته است. بنابراین مایکروسافت برای اینکه BI را به دست افراد بیشتری برساند تصمیم به ساده سازی روند توسعه آن گرفت.
• مایکروسافت متوجه شد که Self-Service BI پتانسیل خوبی برای رشد دارد که حاصل آن ارائه Power Pivot و Power BI برای این بازار بود. بنابراین نیاز به یکپارچگی بین محصولات Self-Service مایکروسافت با ابزارهای enterprise BI tools مایکروسافت احساس میشد. در نتیجه برای توسعه پلتفرمی که از تجربه طراحی در محیط‌های Power Pivot و Power BI استفاده کند تا در صورت نیاز یک پروژه Self Service BI بتواند به راحتی به پروژه‌ای بزرگتر آپگرید شود اقدام کرد.
• برخی از انواع داده‌ها و بیزینس‌ها راحتتر به وسیله مدل‌های Multidimensional طراحی می‌شوند و برخی راحتتر با مدل‌های تبولار قابل پیاده سازی هستند مایکروسافت قابلیت انتخاب را به توسعه دهندگان داده است تا در صورت نیاز از هر کدام به تناسب پروژه‌ی تعریفی استفاده کنند.

همانطور که در مورد سوم اشاره کردیم ، سازگاری تبولار با Power Pivot و اینکه می‌توان یک مدل از Power Pivot را به تبولار ایمپورت کرد از دیگر امتیازات محیط تبولار است و اینکه شما براحتی می‌توانید Self Service BI را به سرعت به یک Enterprise Solution توسعه دهید . مایکروسافت هنوز برای Import مدل از Power BI به محیط Tabular اقدامی نکرده است اما بعید نیست بزودی شاهد چنین امکانی در این محیط باشیم که اگر این اتفاق صورت بگیرد می‌توانید در همین مسیری که برای Import کردن مدل از Power Pivot مشاهده می‌کنید برای Power BI گزینه‌ای را ببینید. (البته برای این منظور راهکارهایی وجود دارد که از مسیرهای دیگری می‌توان مدل را از Power BI Desktop به SSAS Tabular ایمپورت کرد.)

کارایی گزارشات

از نظر کارایی مدل تبولار نسبت به Multidimensional روی سناریوهای خاصی برتری محسوس دارد. مثلا محاسباتی نظیر Distinct count و یا روی گزارشاتی که Granularity آنها به رکوردهای Fact نزدیکتر است عملکرد بهتری دارد ولی در مورد محاسبات پیچیده نمی‌شود به قطعیت تعیین کرد عملکرد کدام مدل بهتر هست و نیاز به تخمین‌ها و ثبت اطلاعات بیشتری برای سنجش کارایی آنها داریم.

کارایی پردازش Processing

امتیازاتی که در این مرحله تبولار نسبت به محیط Multidimensional دارد به قرار زیر است:

• هیچ Aggregationای در محیط تبولار موجود نمی‌باشد. این به این معنیست که یک عمل زمانبر در حین پردازش از تبولار کم شده است.
• پردازش یک جدول در تبولار تاثیر مستقیمی روی جداول دیگر ندارد. برخلاف محیط Multidimensional که پردازش یک دایمنشن تاثیرات اساسی دارد. پردازش کامل یک دایمنشن به این معنیست که تمام Cube‌هایی که از این دایمنشن استفاده می‌کنند باید بطور کامل پردازش شوند. و حتی اگر یک Update Process روی دایمنشن داشته باشیم، نیاز هست که Cube‌هایی که از این دایمنشن استفاده کرده‌اند برای بازسازی Aggregation‌های خود Process Index انجام بدهند.
  البته در مدل تبولار هم مشکلات پرفرمنسی در زمان پردازش داریم نظیر Calculated Column، که برای دیتاهای سنگین بهتر است از این ستون‌های محاسباتی استفاده نگردد.

خصوصیات سخت افزار

همانطور که پیشتر هم گفته شد دیتابیس‌های تبولار In-Memory هستند و برای این منظور اهمیت زیادی دارد که سرور میزبان دارای RAM مناسب برای این سرویس باشد. برعکس در مدل Multidimensional اهمیت با دیسک‌های پرسرعت است و RAM با اینکه در موضوع Caching اهمیت دارد ولی پاشنه آشیل نبوده و وجود میزان معقولی از منابع RAM برای سرور میزبان کفایت می‌کند. پس چنانچه پروژه‌ی بزرگی دارید که خصوصا جداول Fact آن بشدت در حال رشد است و چندین ترابایت دیتا را باید پوشش بدهید انتخاب مدل Multidimensional منطقیست.

Real Time BI

برای حالتی که بخواهیم گزارشاتی با کمترین زمان به حالت جاری بیزینس خود ببینیم در محیط Multidimensional دو حالت را می‌توان پیاده سازی کرد.

• MOLAP: به گونه‌ای که پردازش بشکل Incremental باشد و البته که مدل باید برای این حالت درست طراحی شده باشد و یا میتوان پارتیشن بندی مناسبی در مدل در نظر گرفت فرضا تاریخ و صرفا پارتیشن آخر را پردازش کرد که به سرعت پردازش اتمام یابد و گزارش آماده ارائه باشد. این مورد زمانی که خصوصا دایمنشن‌ها پی در پی در حال بروزرسانی هستند پیاده سازی سختی خواهد داشت و همانطور که پیشتر گفته شد پردازش دایمنشن تاثیرات اساسی بر بقیه مفاهیم موجود در مدل دارد.
• ۲- ROLAP: که در این حالت Caching وجود نداشته و هر گزارشی که بارگزاری می‌شود یک کوئری به سمت سرویس SQL ارسال می‌گردد. ممکن است در حجم بالای اطلاعات اجرای کوئری‌هایی که سمت SQL می‌روند طولانیتر از زمان پردازش مدل باشند! (البته با وجود امکاناتی که سال‌های اخیر مایکروسافت ارائه داده است وضعیت بمراتب از گذشته بهتر است)

در مدل تبولار هم ما چنین امکاناتی را داریم. در حالتی که بخواهیم مدل را پردازش کنیم و داده را در In-Memory Engine داشته باشیم به جهت اینکه پردازش هر جدول مستقل است و تاثیری بر بقیه ندارد پردازش بسیار سریعتر است و در حالتی که بخواهیم مدلی شبیه به ROLAP را داشته باشیم در تبولار با مفهوم Direct Query می‌توانیم چنین شرایطی را پیاده سازی کنیم. (هرچند محدودیت‌هایی را تحمیل خواهد کرد)

برخی از محدودیت‌هایی که تبولار در مقایسه با Multidimensional

• Write Back: این امکان در مدل Multidimensional در قسمت پارتیشن‌ها بود که یک جدول به پارتیشن اضافه می‌کرد و بعد کاربر می‌توانست مثلا در ابزاری مثل Excel با زدن دکمه What IF به Measure Group ای که ما به آن خاصیت Write Back را داده بودیم قابلیت نوشتن بدهد. سپس کاربر دیتای مد نظر خود رو وارد می‌کرد و با زدن دکمه Publish نتیجه تغییراتی که داده بود را در سرتاسر ابعاد بررسی میکرد، چنین قابلیتی در تبولار وجود ندارد.(هرچند این خاصیت در محیل Multidimensional هم دارای محدودیت‌هایی بود)
• Dimension security on measures: چنانچه بخواهیم روی یک سنجه (Measure) خاص برای کاربر دسترسی‌هایی را تنظیم کنیم، که تبولار بشکل Built in وجود ندارد.
• Cell security: میشود برای یک سلول خاص از دیتا دسترسی تعریف کرد. شما می‌توانید برای یک مقدار خاصی از دایمنشن‌ها روی سنجه‌ای خاص دسترسی تعیین کنید. چنین موردی در تبولار بشکل Built in وجود ندارد.
• Hierarchy: در زمانی که ساختار درختی را می‌خواهیم تعریف کنیم بسیاری از قابلیت‌های موجود در Multidimensional را نداریم. نظیر جداول Self Reference و پیمایش‌هایی که در ساختار درختی در مدل Multidimensional بسیار متفاوت از مدل تبولار است. هرچند یکی از قابلیت‌های تبولار هم این است که برای روابط چند به چند توانایی ایجاد درخت دارد!! (که البته با مفهوم درخت در تئوری و آنچه که در مدل Multidimensional است بسیار متفاوت است) البته در نسخه‌های اخیر تبولار بر روی ساختارهای درختی اقدامات خوبی انجام داده است.

Tabular Calculation Engine

سرویس تبولار دارای دو انجین اصلی با نام‌های Storage Engine(SE) و Formula Engine(FE) می‌باشد.
سرویس تبولار هر دو زبان MDX و DAX را پردازش میکند و آنها را به پلن اجرایی تبدیل کرده و برای اجرا به Formula Engine میسپارد که توانایی اجرای عملیاتها و توابع هر دو زبان را داراست. برای دریافت داده های مورد نیاز این Engine یک یا چند درخواست را به سمت Storage Engine ارسال میکند که بسته به اینکه مدلی که طراحی کرده ایم میتواند External Relational Database (Direct Query) و یا In-Memory (xVelocity) باشد

نکته حائز اهمیت دانستن این موضوع است که FE بشکل Single Thread (البته بسته به شرایط برای کاربران متفاوت میتواند بشکل پارالل عمل کند) و SE بشکل Multi Thread (معمولا به ازای رکوردهای بالای ۱۶ میلیون) عمل میکنند در بحث بهینه سازی کارایی بسیار اهمیت دارد.

همانطور که پیشتر گفته شد xVelocity Engin دارای ساختاری ستونی، فشرده شده بوسیله الگوریتم‌هایی در RAM است. در این ساختار Indexای وجود ندارد ، به ازای درخواست‌ها اسکن ستون‌ها صورت می‌گیرد. xVelocity Engine دسترسی مستقیم و فیزیکی به داده‌ها داشته و می‌تواند محاسبات پایه، جوین بین جداول و فیلترها را انجام دهد. محاسبات پیچیده‌تر باید بوسیله FE روی داده‌های تامین شده از SE انجام شود ( که میتواند xVelocity یا Direct Query باشد) همانطور که پیشتر گفته شد بدلیل اینکه FE بشکل Single Thread عمل می‌کند در کوئری‌هایی که کند عمل می‌کنند Bottleneck بحساب می‌آید.(البته در حالتی که Direct Query باشد شرایط می‌تواند متفاوت باشد)
شیوه Compress دیتا در xVelocity Engine به سه روش Hash Encoding و Value Encoding و Run-Length Encoding (RLE) میباشد که با شناخت این شیوه ها می‌توانید به طرز موثری در اشغال فضای RAM صرفه جویی کنید و در جهت بهبود عملیات Refresh اقدام کنید.