DirectQuery در Power BI service

DirectQuery در سرویس Power BI

تمام منابع داده DirectQuery از Power BI Desktop پشتیبانی می‌شوند و برخی از منابع نیز مستقیماً از داخل سرویس Power BI در دسترس هستند. یک کاربر تجاری می‌تواند از Power BI برای اتصال به داده‌های خود در Salesforce استفاده کند، به عنوان مثال، و بلافاصله بدون استفاده از Power BI Desktop، یک داشبورد دریافت کند.

فقط دو منبع زیر که DirectQuery در آنها فعال است، مستقیماً در سرویس Power BI در دسترس هستند:

• Spark
• Azure Synapse Analytics (که قبلاً SQL Data Warehouse نام داشت)

حتی برای این دو منبع، هنوز هم بهتر است استفاده از DirectQuery را در Power BI Desktop شروع کنید. اگرچه ایجاد اتصال اولیه در سرویس Power BI آسان است، اما محدودیت‌هایی برای بهبود بیشتر گزارش حاصل وجود دارد. به عنوان مثال، در این سرویس امکان ایجاد هیچ محاسباتی یا استفاده از بسیاری از ویژگی‌های تحلیلی یا به‌روزرسانی فراداده برای انعکاس تغییرات در طرحواره اصلی وجود ندارد.

عملکرد یک گزارش DirectQuery در سرویس Power BI به میزان بار وارد شده بر روی منبع داده اصلی بستگی دارد. بارگزاری به موارد زیر بستگی دارد:

• تعداد کاربرانی که گزارش و داشبورد را به اشتراک می‌گذارند.
• پیچیدگی گزارش.
• آیا گزارش، امنیت سطح ردیف را تعریف می‌کند یا خیر.

رفتار گزارش در سرویس Power BI

وقتی گزارشی را در سرویس Power BI باز می‌کنید، تمام تصاویر موجود در صفحه فعلی قابل مشاهده، رفرش می‌شوند. هر تصویر حداقل به یک پرس‌وجو به منبع داده اصلی نیاز دارد. برخی از تصاویر ممکن است به بیش از یک پرس‌وجو نیاز داشته باشند. به عنوان مثال، یک تصویر ممکن است مقادیر تجمیعی را از دو جدول واقعیت مختلف نشان دهد، یا حاوی یک معیار پیچیده‌تر باشد، یا شامل مجموع یک معیار غیرجمعی مانند Count Distinct باشد. انتقال به یک صفحه جدید، آن تصاویر را رفرش می‌کند. رفرش، مجموعه‌ای جدید از پرس‌وجوها را به منبع اصلی ارسال می‌کند.

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

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

برای خرید لایسنس نرم افزار Power BI ، می‌توانید از خدمات ما استفاده نموده و درخواست خود را از طریق فرم زیر ثبت نمایید.

فرم درخواست لایسنس Power BI

 

استفاده از DirectQuery محدودیت‌های مهمی را در برخی از قابلیت‌هایی که سرویس Power BI برای گزارش‌های منتشر شده ارائه می‌دهد، اعمال می‌کند:

• بینش‌های سریع پشتیبانی نمی‌شوند: بینش‌های سریع Power BI زیرمجموعه‌های مختلف مدل معنایی شما را جستجو می‌کنند و در عین حال مجموعه‌ای از الگوریتم‌های پیچیده را برای کشف بینش‌های بالقوه جالب اعمال می‌کنند. از آنجا که بینش‌های سریع نیاز به پرس‌وجوهای با کارایی بالا دارند، این ویژگی در مدل‌های معنایی که از DirectQuery استفاده می‌کنند، در دسترس نیست.
• استفاده از Explore در Excel منجر به عملکرد ضعیف می‌شود: می‌توانید با استفاده از قابلیت Explore در Excel، یک مدل معنایی را کاوش کنید، که به شما امکان می‌دهد جداول محوری و نمودارهای محوری را در Excel ایجاد کنید. این قابلیت برای مدل‌های معنایی که از DirectQuery استفاده می‌کنند پشتیبانی می‌شود، اما عملکرد آن کندتر از ایجاد تصاویر در Power BI است. اگر استفاده از اکسل برای سناریوهای شما مهم است، این موضوع را در تصمیم‌گیری برای استفاده از DirectQuery در نظر بگیرید.
• اکسل سلسله مراتب را نشان نمی‌دهد: برای مثال، وقتی از Analyze در اکسل استفاده می‌کنید، اکسل هیچ سلسله مراتبی را که در مدل‌های Azure Analysis Services یا مدل‌های معنایی Power BI که از DirectQuery استفاده می‌کنند تعریف شده باشد، نشان نمی‌دهد.

به‌روزرسانی داشبورد

در سرویس Power BI، می‌توانید تصاویر تکی یا کل صفحات را به عنوان کاشی به داشبوردها سنجاق کنید. کاشی‌هایی که مبتنی بر مدل‌های معنایی DirectQuery هستند، با ارسال کوئری‌ها به منابع داده‌ی زیربنایی طبق یک برنامه، به‌طور خودکار به‌روزرسانی می‌شوند. به‌طور پیش‌فرض، مدل‌های معنایی هر ساعت به‌روزرسانی می‌شوند، اما می‌توانید فواصل زمانی به‌روزرسانی را بین هفتگی و هر ۱۵ دقیقه به‌عنوان بخشی از تنظیمات مدل معنایی پیکربندی کنید.

اگر هیچ امنیت سطح ردیفی در مدل تعریف نشده باشد، هر کاشی یک بار به‌روزرسانی می‌شود و نتایج در بین همه کاربران به اشتراک گذاشته می‌شود. اگر از امنیت سطح ردیفی استفاده می‌کنید، هر کاشی برای ارسال به منبع زیربنایی به کوئری‌های جداگانه برای هر کاربر نیاز دارد.

می‌تواند یک اثر ضریب بزرگ وجود داشته باشد. یک داشبورد با ۱۰ کاشی، که با ۱۰۰ کاربر به اشتراک گذاشته شده است و بر روی یک مدل معنایی با استفاده از DirectQuery با امنیت سطح ردیفی ایجاد شده است، منجر به ارسال حداقل ۱۰۰۰ کوئری به منبع داده‌ی زیربنایی برای هر به‌روزرسانی می‌شود. به استفاده از امنیت سطح ردیفی و پیکربندی برنامه‌ی به‌روزرسانی توجه دقیقی داشته باشید.

زمان انتظار برای کوئری‌ها

زمان انتظار چهار دقیقه‌ای برای کوئری‌های تکی در سرویس Power BI اعمال می‌شود. کوئری‌هایی که بیش از چهار دقیقه طول بکشند، با شکست مواجه می‌شوند. این محدودیت برای جلوگیری از مشکلات ناشی از زمان اجرای بیش از حد طولانی در نظر گرفته شده است. شما باید فقط برای منابعی که می‌توانند عملکرد کوئری تعاملی ارائه دهند، از DirectQuery استفاده کنید.

هنگامی که به محدودیت زمان انتظار برسید، تصاویر با خطای زیر بارگیری نمی‌شوند:The query has exceeded the available resources. Try filtering to decrease the amount of data requested. The XML for Analysis request timed out before it was completed. Timeout value: 225 sec.

 

تشخیص عملکرد

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

تشخیص مشکلات عملکرد را در Power BI Desktop، به جای سرویس Power BI، شروع کنید. مشکلات عملکرد اغلب بر اساس عملکرد منبع اصلی هستند. شما می‌توانید مشکلات را در محیط Power BI Desktop که ایزوله‌تر است، راحت‌تر شناسایی و تشخیص دهید.

این رویکرد در ابتدا اجزای خاصی مانند دروازه Power BI را حذف می‌کند. اگر مشکلات عملکرد در Power BI Desktop رخ ندهد، می‌توانید جزئیات گزارش را در سرویس Power BI بررسی کنید.

آنالیزور عملکرد Power BI Desktop ابزاری مفید برای شناسایی مشکلات است. سعی کنید هر مشکلی را به یک تصویر، به جای چندین تصویر در یک صفحه، محدود کنید. اگر یک تصویر واحد در صفحه Power BI Desktop کند است، از آنالیزور عملکرد برای تجزیه و تحلیل پرس‌وجوهایی که Power BI Desktop به منبع اصلی ارسال می‌کند، استفاده کنید.

همچنین می‌توانید ردیابی‌ها و اطلاعات تشخیصی را که برخی از منابع داده اصلی منتشر می‌کنند، مشاهده کنید. حتی اگر هیچ اثری از منبع وجود نداشته باشد، فایل ردیابی ممکن است حاوی جزئیات مفیدی در مورد نحوه اجرای یک پرس‌وجو و نحوه بهبود آن باشد. می‌توانید از فرآیند زیر برای مشاهده پرس‌وجوهایی که Power BI ارسال می‌کند و زمان اجرای آنها استفاده کنید.

از SQL Server Profiler برای مشاهده پرس‌وجوها استفاده کنید.

به طور پیش‌فرض، Power BI Desktop رویدادهای یک جلسه معین را در یک فایل ردیابی به نام FlightRecorderCurrent.trc ثبت می‌کند. فایل ردیابی در پوشه Power BI Desktop برای کاربر فعلی، در پوشه‌ای به نام AnalysisServicesWorkspaces قرار دارد.

برای برخی از منابع DirectQuery، این فایل ردیابی شامل تمام پرس‌وجوهای ارسال شده به منبع داده اصلی است. منابع داده زیر پرس‌وجوها را به گزارش ارسال می‌کنند:

• SQL Server
• Azure SQL Database
• Azure Synapse Analytics (قبلاً SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

برای باز کردن فایل ردیابی برای جلسه فعلی:

1. در طول جلسه Power BI Desktop، File > Options and settings > Options را انتخاب کنید و سپس Diagnostics را انتخاب کنید.

2. در زیر Crash Dump Collection، گزینه Open crash dump/traces folder را انتخاب کنید.

پوشه Power BI Desktop\Traces باز می‌شود.

برای خرید لایسنس نرم افزار Power BI ، می‌توانید از خدمات ما استفاده نموده و درخواست خود را از طریق فرم زیر ثبت نمایید.

فرم درخواست لایسنس Power BI

 

3. به پوشه والد و سپس به پوشه AnalysisServicesWorkspaces بروید، که شامل یک پوشه فضای کاری برای هر نمونه باز از Power BI Desktop است. این پوشه‌ها با پسوند عدد صحیح، مانند AnalysisServicesWorkspace2058279583 نامگذاری شده‌اند. پوشه فضای کاری با پایان جلسه مرتبط Power BI Desktop حذف می‌شود.

در داخل پوشه فضای کاری برای جلسه فعلی Power BI، پوشه \Data حاوی فایل ردیابی FlightRecorderCurrent.trc است. مکان آن را یادداشت کنید.

4. SQL Server Profiler را باز کنید و File > Open > Trace File را انتخاب کنید.

5.به فایل ردیابی جلسه فعلی Power BI بروید یا مسیر آن را وارد کنید و FlightRecorderCurrent.trc را باز کنید.

SQL Server Profiler تمام رویدادهای جلسه فعلی را نمایش می‌دهد. تصویر زیر گروهی از رویدادهای یک پرس‌وجو را برجسته می‌کند. هر گروه پرس‌وجو دارای رویدادهای زیر است:

• رویداد Query Begin و Query End، که نشان‌دهنده شروع و پایان یک پرس‌وجوی DAX تولید شده با تغییر یک تصویر یا فیلتر در رابط کاربری Power BI یا از فیلتر کردن یا تبدیل داده‌ها در ویرایشگر Power Query هستند.
• یک یا چند جفت رویداد DirectQuery Begin و DirectQuery End، که نشان‌دهنده پرس‌وجوهای ارسال شده به منبع داده اصلی به عنوان بخشی از ارزیابی پرس‌وجوی DAX هستند.

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

ستون‌های زیر نیز مورد توجه هستند:

• TextData: جزئیات متنی رویداد. برای رویدادهای Query Begin و Query End، جزئیات، کوئری DAX است. برای رویدادهای DirectQuery Begin و DirectQuery End، جزئیات، کوئری SQL ارسال شده به منبع اصلی است. TextData برای رویداد انتخاب شده فعلی نیز در کادر پایین صفحه نمایش داده می‌شود.
• EndTime: زمانی که رویداد تکمیل شده است.
• Duration: مدت زمان اجرای کوئری DAX یا SQL، به میلی ثانیه.
• Error: آیا خطایی رخ داده است، که در این صورت رویداد نیز به رنگ قرمز نمایش داده می‌شود.

برای ثبت یک ردیابی برای کمک به تشخیص یک مشکل عملکردی بالقوه:

1. یک جلسه Power BI Desktop را باز کنید تا از سردرگمی پوشه‌های متعدد فضای کاری جلوگیری شود.

2. مجموعه اقدامات مورد نظر را در Power BI Desktop انجام دهید. چند اقدام دیگر را نیز اضافه کنید تا مطمئن شوید رویدادهای مورد نظر در فایل ردیابی قرار می‌گیرند.

3. SQL Server Profiler را باز کنید و ردیابی را بررسی کنید. به یاد داشته باشید که بستن Power BI Desktop فایل ردیابی را حذف می‌کند. همچنین، اقدامات بیشتر در Power BI Desktop بلافاصله ظاهر نمی‌شوند. برای مشاهده رویدادهای جدید باید فایل ردیابی را ببندید و دوباره باز کنید.

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

 

قالب پرس‌وجوها را درک کنید

قالب کلی پرس‌وجوهای Power BI Desktop از subselectها برای هر جدولی که به آن ارجاع می‌دهند استفاده می‌کند. پرس‌وجوی Power Query Editor پرس‌وجوهای subselect را تعریف می‌کند. برای مثال، فرض کنید جداول TPC-DS زیر را در SQL Server دارید:

اجرای کوئری زیر:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))

by Item[i_category]

for Date_dim[d_year] = 2000

نتایج در تصویر زیر در Power BI نشان داده شده است:

با رفرش کردن آن ویژوال، کوئری SQL تصویر زیر نمایش داده می‌شود. سه کوئری subselect برای Web_Sales، Item و Date_dim وجود دارد که هر کدام تمام ستون‌های جدول مربوطه را برمی‌گردانند، اگرچه ویژوال فقط به چهار ستون اشاره می‌کند.

ویرایشگر پرس‌وجوی پاور (Power Query Editor) پرس‌وجوهای زیرمجموعه‌ای (subselect) را دقیقاً تعریف می‌کند. این استفاده از پرس‌وجوهای زیرمجموعه‌ای، تأثیری بر عملکرد منابع داده‌ای که DirectQuery از آنها پشتیبانی می‌کند، نشان نداده است. منابع داده‌ای مانند SQL Server ارجاعات به ستون‌های دیگر را بهینه می‌کنند.

پاور بی آی (Power BI) از این الگو استفاده می‌کند زیرا تحلیلگر، پرس‌وجوی SQL را مستقیماً ارائه می‌دهد. پاور بی آی از پرس‌وجوی ارائه شده، بدون هیچ تلاشی برای بازنویسی آن، استفاده می‌کند.

برای خرید لایسنس نرم افزار Power BI ، می‌توانید از خدمات ما استفاده نموده و درخواست خود را از طریق فرم زیر ثبت نمایید.

فرم درخواست لایسنس Power BI

 

میتوانید پاور بی آی دسکتاپ رایگان را دانلود کنید : Power BI desktop download