طراوت افزایشی و داده های زمان واقعی برای مجموعه داده ها

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

با تجدید افزایشی و داده های زمان واقعی:

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

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

با تجدید افزایشی ، سرویس به صورت پویا تقسیم می شود و داده هایی را که باید به طور مکرر از داده هایی که می توانند به طور مکرر تازه شوند ، جدا می کنند. داده های جدول با استفاده از پارامترهای تاریخ/زمان Query Power با نام های رزرو شده ، حساس به مورد Rangestart و Rangeend فیلتر می شوند. هنگامی که شما در دسک تاپ قدرت BI را تنظیم می کنید ، این پارامترها فقط برای فیلتر کردن دوره کمی از داده ها که در مدل بارگذاری شده است ، استفاده می شود. هنگامی که Power BI Desktop گزارش را به سرویس Power BI منتشر می کند ، با اولین عملیات تازه سازی ، سرویس باعث ایجاد تازه سازی و پارتیشن های تاریخی می شود و به صورت اختیاری یک پارتیشن مستقیم در زمان واقعی بر اساس تنظیمات سیاست های افزایشی افزایشی. این سرویس سپس مقادیر پارامتر را برای فیلتر کردن و پرس و جو برای هر پارتیشن بر اساس مقادیر تاریخ/زمان برای هر سطر غلبه می کند.

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

زیبایی تازه سازی افزایشی این است که این سرویس بر اساس سیاست های تازه سازی افزایشی که شما تعریف می کنید ، تمام آن را برای شما انجام می دهد. در حقیقت ، فرآیند و پارتیشن های ایجاد شده از آن در سرویس قابل مشاهده نیست. در بیشتر موارد ، یک سیاست تازه سازی افزایشی به خوبی تعریف شده ، تمام آنچه برای بهبود چشمگیر عملکرد تازه سازی مجموعه داده ها لازم است. با این حال ، پارتیشن DirectQuery در زمان واقعی فقط برای مجموعه داده ها در ظرفیت های حق بیمه پشتیبانی می شود. Power Bi Premium همچنین پارتیشن پیشرفته تر و سناریوهای تازه تر را از طریق XML برای نقطه پایانی تجزیه و تحلیل (XMLA) امکان پذیر می کند.

الزامات

بخش های بعدی برنامه ها و منابع داده پشتیبانی شده را شرح می دهد.

برنامه های پشتیبانی شده

تازه سازی افزایشی برای Power BI Premium ، حق بیمه در هر کاربر ، Power BI Pro و Power BI تعبیه شده پشتیبانی می شود.

دریافت آخرین داده ها در زمان واقعی با DirectQuery فقط برای Power BI Premium ، حق بیمه برای هر کاربر و مجموعه داده های تعبیه شده Power BI پشتیبانی می شود.

منابع داده پشتیبانی شده

REFRESH افزایشی و داده های زمان واقعی برای منابع داده های ساخت یافته و رابطه ای مانند پایگاه داده SQL و Azure Synapse بهترین کار را می کند ، اما می تواند برای سایر منابع داده نیز کار کند. در هر صورت ، منبع داده شما باید از موارد زیر پشتیبانی کند:

فیلتر تاریخ - منبع داده باید از مکانیسم برای فیلتر کردن داده ها تا تاریخ پشتیبانی کند. برای یک منبع رابطه ، این معمولاً یک ستون تاریخ از تاریخ/زمان یا نوع داده عدد صحیح در جدول هدف است. پارامترهای Rangestart و Rangeend ، که باید از نوع داده تاریخ/زمان ، داده های جدول فیلتر بر اساس ستون تاریخ باشد. برای ستون های تاریخ کلیدهای جانشین عدد صحیح به شکل Yyyymmdd ، می توانید تابعی را ایجاد کنید که مقدار تاریخ/زمان را در پارامترهای Rangestart و Rangeend تبدیل کند تا با کلیدهای جانشین عدد ستون تاریخ مطابقت داشته باشد. برای کسب اطلاعات بیشتر ، به پیکربندی Refresh افزایشی مراجعه کنید - DateTime را به عدد صحیح تبدیل کنید.

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

let strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]), strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]), Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps//query", [Query=[#"query"="traces | where timestamp>= DateTime ("& Strrangestart &") |جایی که Timestamp, <<"string", Text.Type>, <"int", Int32.Type>, <"long", Int64.Type>, <"real", Double.Type>, <"timespan", Duration.Type>, <"datetime", DateTimeZone.Type>, <"bool", Logical.Type>, <"guid", Text.Type>, <"dynamic", Text.Type>>), DataTable = Source[tables], Columns = Table.FromRecords(DataTable[columns]), ColumnsWithType = Table.Join(Columns, , TypeMap , ), Rows = Table.FromRows(DataTable[rows], Columns[name]), Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => )) روی میز 

هنگامی که Refresh افزایشی پیکربندی می شود ، یک عبارت پرس و جو که شامل یک فیلتر تاریخ/زمان بر اساس پارامترهای Rangestart و Rangeend است ، در برابر منبع داده اجرا می شود. اگر فیلتر در یک مرحله پرس و جو پس از پرس و جو منبع اولیه مشخص شود ، مهم است که پرس و جو تاشو مرحله پرس و جو اولیه را با مراحل ارجاع پارامترهای Rangestart و Rangeend ترکیب کند. به عنوان مثال ، در بیان پرس و جو زیر ، جدول. selectrows برابر خواهد شد زیرا بلافاصله مرحله sql. database را دنبال می کند ، و سرور SQL از تاشو پشتیبانی می کند:

let Source = Sql.Database("dwdev02","AdventureWorksDW2017"), Data = Source[Data], #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey]>= int32. from (dateTime. Totext (Rangestart ، [format = "Yyyymmmdd"]))) ، #"Rows Filtered Rows1" = Table. Selectrows ( #"ردیف های فیلتر شده" ، هر [OrderDateKey] 

هیچ الزامی برای تاشو پشتیبانی نهایی پرس و جو وجود ندارد. به عنوان مثال در عبارت زیر ، ما از یک بومی غیرقانونی استفاده می کنیم اما پارامترهای Rangestart و Rangeend را مستقیماً در SQL ادغام می کنیم:

let Query = "select * from dbo.FactInteetSales where OrderDateKey>= '"& text. from (int32. from (dateTime. Totext (Rangestart ،" Yyyymmdd ")))) و" "و OrderDateKey<'"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ", Source = Sql.Database("dwdev02","AdventureWorksDW2017"), Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false]) in Data 

با این حال ، اگر خط مشی تجدید افزایشی شامل دریافت داده های در زمان واقعی با DirectQuery باشد ، از تحولات غیر تاشو استفاده نمی شود. اگر این یک خط مشی حالت واردات خالص و بدون داده در زمان واقعی باشد ، موتور Query Mashup ممکن است فیلتر را به صورت محلی جبران و اعمال کند ، که نیاز به بازیابی همه ردیف ها برای جدول از منبع داده دارد. این می تواند باعث کندی افزایشی کند و روند کار می تواند از منابع یا در سرویس Power BI یا در یک دروازه داده در محل خارج شود - به طور موثری هدف از تجدید افزایشی را شکست دهد.

از آنجا که پشتیبانی از تاشو پرس و جو برای انواع مختلف منابع داده متفاوت است ، باید تأیید صحت انجام شود تا اطمینان حاصل شود که منطق فیلتر در نمایش داده شدگان در مقابل منبع داده قرار دارد. در بیشتر موارد ، Power BI Desktop سعی می کند هنگام تعریف خط مشی تازه سازی افزایشی ، این تأیید را برای شما انجام دهد. برای منابع داده مبتنی بر SQL مانند پایگاه داده SQL ، Azure Synapse ، Oracle و Teradata ، این تأیید قابل اعتماد است. با این حال ، سایر منابع داده ممکن است بدون ردیابی نمایش داده ها نتوانند تأیید کنند. اگر دسک تاپ Power BI نتواند نمایش داده ها را تأیید کند ، هشدار در گفتگوی پیکربندی خط مشی تازه سازی افزایشی نشان داده شده است.

اگر این هشدار را می بینید و می خواهید تأیید کنید که تاشو پرس و جو لازم در حال وقوع است ، با استفاده از ابزاری که توسط منبع داده ، مانند SQL Profiler پشتیبانی می شود ، از ویژگی تشخیص Power Query یا نمایش داده های ردیابی استفاده کنید. اگر تاشو پرس و جو اتفاق نیفتد ، تأیید کنید که منطق فیلتر در پرس و جو که به منبع داده منتقل می شود ، گنجانده شده است. اگر اینگونه نباشد ، احتمالاً پرس و جو شامل تحولی است که از تاشو جلوگیری می کند.

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

منبع داده

هنگامی که شما با استفاده از دسک تاپ Power BI ، تنظیمات تازه سازی و در زمان واقعی را پیکربندی می کنید ، یا با استفاده از زبان برنامه نویسی مدل جدول (TMSL) یا مدل شیء جدولی (TOM) از طریق نقطه پایانی XMLA ، تمام پارتیشن ها ، چه واردات یا کارگردانی ، یک راه حل پیشرفته را پیکربندی می کنید. باید داده ها را از یک منبع واحد پرس و جو کنید.

سایر انواع منبع داده

با استفاده از توابع پرس و جو سفارشی تر و منطق پرس و جو ، اگر فیلترهای مبتنی بر Rangestart و Rangeend بتوانند در یک پرس و جو واحد ، مانند منابع داده ای مانند پرونده های کتاب کار Excel که در یک پوشه ذخیره شده اند ، با انواع دیگر منابع داده استفاده شود. پرونده ها در SharePoint و فیدهای RSS. به خاطر داشته باشید که این سناریوهای پیشرفته ای هستند که نیاز به شخصی سازی و آزمایش بیشتر فراتر از آنچه در اینجا توضیح داده می شود. حتماً بخش جامعه را بعداً در این مقاله بررسی کنید.

محدودیت های زمانی

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

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

از آنجا که Refresh افزایشی عملیات تازه سازی را در سطح پارتیشن در مجموعه داده بهینه می کند ، می توان مصرف منابع را به میزان قابل توجهی کاهش داد. در عین حال ، حتی با تجدید افزایشی ، مگر اینکه از نقطه پایانی XMLA عبور کنند ، عملیات تازه سازی با همان محدودیت های دو ساعته و پنج ساعته محدود می شود. یک سیاست تازه سازی افزایشی مؤثر نه تنها میزان داده های پردازش شده با یک عمل تازه را کاهش می دهد ، بلکه میزان داده های تاریخی غیر ضروری ذخیره شده در مجموعه داده شما را نیز کاهش می دهد.

نمایش داده ها همچنین می توانند با محدودیت زمانی پیش فرض برای منبع داده محدود شوند. اکثر منابع داده رابطه ای اجازه می دهند محدودیت زمان اصلی در بیان پرس و جو M. به عنوان مثال ، عبارت زیر از تابع ACCESS Data SQL Server استفاده می کند تا CommandTimeOut را به 2 ساعت تنظیم کند. هر دوره تعریف شده توسط محدوده خط مشی ، یک پرس و جو را مشاهده می کند که تنظیمات زمان فرمان را مشاهده می کند:

let Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]), dbo_Fact = Source[Data], #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate]>= Rangestart و [OrderDate] 

برای مجموعه داده های بسیار بزرگ در ظرفیت های حق بیمه که احتمالاً حاوی میلیاردها ردیف هستند ، می توان عملکرد تازه سازی اولیه را بوت کرد. Bootstrapping به سرویس اجازه می دهد تا جدول و اشیاء پارتیشن را برای مجموعه داده ایجاد کند ، اما داده ها را در هیچ یک از پارتیشن ها بارگیری و پردازش نمی کند. با استفاده از استودیوی مدیریت SQL Server ، می توانید پارتیشن ها را به صورت جداگانه ، پی در پی یا به طور موازی پردازش کنید تا هر دو میزان داده های برگشتی را در یک پرس و جو واحد کاهش دهند و همچنین محدودیت زمانی پنج ساعته را دور بزنید. برای کسب اطلاعات بیشتر ، به تازه سازی افزایشی پیشرفته مراجعه کنید - از مدت زمان بندی در تازه کردن کامل اولیه جلوگیری کنید.

تاریخ و زمان فعلی

تاریخ و زمان فعلی بر اساس تاریخ سیستم در زمان تازه سازی است. اگر Refresh برنامه ریزی شده برای مجموعه داده در سرویس فعال باشد ، هنگام تعیین تاریخ و زمان فعلی ، منطقه زمانی مشخص شده در نظر گرفته می شود. هر دو طراوت فردی و برنامه ریزی شده از طریق سرویس در صورت وجود منطقه زمانی را مشاهده می کنند. به عنوان مثال ، یک تازه کردن که در ساعت 8 بعد از ظهر اقیانوس آرام (ایالات متحده و کانادا) با یک منطقه زمانی مشخص شده ، تاریخ و زمان فعلی را بر اساس زمان اقیانوس آرام تعیین می کند ، زمان جهانی هماهنگ (UTC) را تعیین می کند ، که روز بعد باز می گردد. عملیات تازه ای که از طریق سرویس Power BI ، مانند فرمان TMSL Refresh ، فراخوانی نشده است ، منطقه زمانی تازه سازی برنامه ریزی شده را در نظر نگیرید.

تنظیمات افزایشی و در زمان واقعی را پیکربندی کنید

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

پیکربندی Refresh افزایشی در دسک تاپ Power BI انجام می شود. برای اکثر مدل ها ، فقط چند کار لازم است. با این حال ، نکات زیر را در خاطر داشته باشید:

• پس از انتشار به سرویس Power BI ، شما نمی توانید دوباره همان مدل را از Power BI Desktop منتشر کنید. بازنویسی هر پارتیشن و داده های موجود را که قبلاً در مجموعه داده ها حذف می کند ، حذف می کند. اگر در حال انتشار با ظرفیت حق بیمه هستید ، می توان با ابزارهایی مانند ابزار ALM منبع باز یا با استفاده از TMSL ، تغییرات طرحواره ای ابرداده بعدی ایجاد کرد. برای کسب اطلاعات بیشتر ، به Refresh Advanced افزایشی - استقرار فقط ابرداده مراجعه کنید.
• پس از انتشار به سرویس Power BI ، نمی توانید مجموعه داده ها را به عنوان یک . pbix به Power BI Desktop بارگیری کنید. از آنجا که مجموعه داده های موجود در این سرویس می توانند بسیار بزرگ شوند ، بارگیری و باز کردن آنها در یک رایانه رومیزی معمولی غیر عملی است.
• هنگام دریافت داده های زمان واقعی با DirectQuery ، نمی توانید مجموعه داده را به یک فضای کاری غیر PREMIUM منتشر کنید. تازه سازی افزایشی با داده های زمان واقعی فقط با Power BI Premium پشتیبانی می شود.

پارامترهایی ایجاد کنید

برای پیکربندی Refresh افزایشی در دسک تاپ Power BI ، ابتدا دو پارامتر تاریخ/زمان پرس و جو با نام های رزرو شده ، حساس به مورد Rangestart و Rangeend ایجاد می کنید. این پارامترها ، که در گفتگوی مدیریت پارامترها در ویرایشگر Power Query تعریف شده است ، در ابتدا برای فیلتر کردن داده های بارگذاری شده در جدول مدل دسک تاپ Power BI استفاده می شود تا فقط آن ردیف ها را با تاریخ/زمان در آن دوره شامل شود. Rangestart نمایانگر قدیمی ترین یا اولین تاریخ/زمان است و Rangeend نمایانگر جدیدترین یا آخرین تاریخ/زمان است. پس از انتشار این مدل به سرویس ، Rangestart و Rangeend به طور خودکار توسط سرویس برای پرس و جو از داده های تعریف شده توسط دوره تازه سازی مشخص شده در تنظیمات خط مشی تازه سازی افزایش می یابد.

به عنوان مثال ، جدول منبع داده Factinteetsales به طور متوسط 10،000 ردیف جدید در روز است. برای محدود کردن تعداد ردیف های موجود در ابتدا در مدل در دسک تاپ Power BI ، یک دوره دو روزه بین Rangestart و Rangeend مشخص کنید.

داده های فیلتر

با استفاده از پارامترهای Rangestart و Rangeend ، فیلترهای تاریخ سفارشی را در ستون تاریخ جدول خود اعمال می کنید. فیلترهایی که اعمال می کنید ، زیر مجموعه ای از داده ها را انتخاب کنید که هنگام انتخاب Apply در مدل بارگذاری شده است.

با مثال Factinteetsales ما ، پس از ایجاد فیلترها بر اساس پارامترها و اعمال مراحل ، دو روز داده (تقریباً 20،000 ردیف) در مدل بارگیری می شوند.

خط مشی را تعریف کنید

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

جدول

جدول انتخاب جدول لیست را به جدول انتخابی که در نمایش داده انتخاب کرده اید ، پیش فرض می کند. با کشویی ، تازه سازی افزایشی را برای جدول فعال کنید. اگر بیان پرس و جو برای جدول شامل فیلتر مبتنی بر پارامترهای Rangestart و Rangeend نباشد ، ضامن در دسترس نیست.

تنظیمات مورد نیاز

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

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

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

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

به عنوان مثال ، اگر یک دوره تازه سازی سه روز را مشخص کنید ، با هر عملیات تازه سازی ، این سرویس پارامترهای Rangestart و Rangeend را نادیده می گیرد تا یک پرس و جو برای ردیف ها با تاریخ/زمان در یک دوره سه روزه ایجاد شود ، با شروع و پایان آن وابسته است. در تاریخ و زمان فعلیردیف هایی با تاریخ/زمان در سه روز گذشته تا زمان کارآزمایی فعلی تازه می شوند. با این نوع خط مشی ، می توانید انتظار داشته باشید که جدول مجموعه داده های Factinteetsales ما در این سرویس ، که به طور متوسط 10،000 ردیف جدید در روز است ، انتظار داشته باشید که تقریباً 30،000 ردیف را با هر عملیات تازه سازی تازه کنید.

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

تنظیمات اختیاری

دریافت آخرین داده ها در زمان واقعی با تنظیمات DirectQuery (فقط حق بیمه) باعث می شود آخرین تغییرات از جدول انتخاب شده در منبع داده فراتر از دوره تازه سازی افزایشی با استفاده از DirectQuery را بدست آورید. تمام ردیف ها با تاریخ/زمان دیرتر از دوره تازه سازی افزایشی در یک پارتیشن DirectQuery گنجانده شده و از منبع داده با هر پرس و جو مجموعه داده می شوند.

به عنوان مثال ، اگر این تنظیم فعال باشد ، با هر عملیات تازه سازی ، این سرویس همچنان پارامترهای Rangestart و Rangeend را نادیده می گیرد تا یک پرس و جو برای ردیف ها با تاریخ/زمان بعد از دوره تازه سازی ایجاد شود ، با شروع به تاریخ و زمان فعلی. ردیف هایی با تاریخ/زمان پس از زمان کارآزمایی فعلی نیز گنجانده شده است. با این نوع خط مشی ، جدول مجموعه داده های Factinteetsales در این سرویس شامل آخرین به روزرسانی داده ها است.

تنها تنظیم روزهای کامل ، تضمین می کند که تمام ردیف ها برای کل روز در عملیات تازه سازی گنجانده شده اند. این تنظیم اختیاری است ، مگر اینکه بتوانید آخرین داده ها را در زمان واقعی با تنظیم DirectQuery (فقط حق بیمه) دریافت کنید. به عنوان مثال ، بگویید که تازه کردن شما قرار است هر روز صبح ساعت 4 صبح اجرا شود. اگر ردیف های جدید داده ها در جدول منبع داده در طی این چهار ساعت بین نیمه شب و 4:00 صبح ظاهر می شوند ، نمی خواهید آنها را حساب کنید. برخی از معیارهای تجاری مانند بشکه در روز در صنعت نفت و گاز با روزهای جزئی معنی ندارد. مثال دیگر ، طراوت داده ها از یک سیستم مالی است که داده های ماه قبل در روز تقویم دوازدهم ماه تصویب شده است. شما می توانید دوره تازه سازی را به یک ماه تنظیم کرده و برنامه ریزی برای تازه کردن در روز دوازدهم ماه را برنامه ریزی کنید. با انتخاب این گزینه ، به عنوان مثال ، داده های ژانویه را در 12 فوریه تازه می کند.

به خاطر داشته باشید ، مگر اینکه Refresh برنامه ریزی شده برای یک منطقه زمانی غیر UTC پیکربندی شود ، عملیات تازه در سرویس تحت UTC زمان اجرا می شود ، که می تواند تاریخ مؤثر و دوره های کامل را تعیین کند.

تنظیم تغییر داده های Detect باعث می شود که حتی انتخابی تر انتخاب شود. شما می توانید یک ستون تاریخ/زمان استفاده شده برای شناسایی و تازه کردن فقط در آن روزهایی که داده ها تغییر کرده اند انتخاب کنید. این تنظیم فرض می کند چنین ستونی در منبع داده وجود دارد ، که به طور معمول برای اهداف حسابرسی است. این ستون نباید همان ستون باشد که برای تقسیم داده ها با پارامترهای Rangestart و Rangeend استفاده می شود. حداکثر مقدار این ستون برای هر یک از دوره ها در محدوده افزایشی ارزیابی می شود. اگر از آخرین تازه سازی تغییر نکرده باشد ، نیازی به تازه کردن دوره نیست ، که به طور بالقوه می تواند روزهای افزایشی را از سه به یک کاهش دهد.

طرح فعلی مستلزم آن است که ستون برای تشخیص تغییرات داده ها همچنان ادامه داشته و به حافظه ذخیره شود. از تکنیک های زیر می توان برای کاهش کاردینال بودن و مصرف حافظه استفاده کرد:

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

در بعضی موارد ، امکان تغییر داده های Detect Data * می تواند بیشتر افزایش یابد. به عنوان مثال ، شما ممکن است بخواهید از ادامه یک ستون به روزرسانی در حافظه نهان در حافظه خودداری کنید ، یا سناریوهایی را فعال کنید که در آن یک جدول پیکربندی/دستورالعمل با استفاده از فرآیندهای عصاره-انتقال-بار (ETL) برای پرچم گذاری فقط آن دسته از پارتیشن هایی که نیاز دارند تهیه می شودتازه شوددر مواردی از این دست ، برای ظرفیت های حق بیمه ، از TMSL و/یا TOM برای غلبه بر رفتار تغییر داده ها استفاده کنید. برای کسب اطلاعات بیشتر ، به Refresh Advanced افزایشی - نمایش داده شدگان سفارشی برای تشخیص داده ها مراجعه کنید.

انتشار

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

مجموعه داده هایی با یک سیاست تازه سازی افزایشی برای به دست آوردن آخرین داده ها در زمان واقعی با DirectQuery فقط می تواند در یک فضای کاری پریمیوم منتشر شود.

برای مجموعه داده های منتشر شده به مکانهای کاری اختصاص داده شده به ظرفیت های حق بیمه ، اگر فکر می کنید مجموعه داده فراتر از 1 گیگابایت رشد خواهد کرد ، می توانید عملکرد عملکرد تازه را بهبود بخشید و اطمینان حاصل کنید که با فعال کردن قالب بزرگ ذخیره سازی مجموعه داده ها قبل از انجام اولین عملیات تازه سازی ، محدودیت های اندازه را حداکثر نمی کند. در سرویسبرای کسب اطلاعات بیشتر ، به مجموعه داده های بزرگ در Power BI Premium مراجعه کنید.

بعد از اینکه Power BI Desktop مدل را به سرویس منتشر می کند ، نمی توانید آن . pbix را دوباره بارگیری کنید.

تازه کردن

پس از انتشار به سرویس ، شما یک عملیات تازه سازی اولیه را در مجموعه داده انجام می دهید. این تازه سازی باید یک تجدید فردی (دستی) باشد تا بتوانید پیشرفت را کنترل کنید. عملیات تازه سازی اولیه می تواند مدتی طول بکشد. پارتیشن ها باید ایجاد شوند ، داده های تاریخی بارگذاری شده ، اشیاء مانند روابط و سلسله مراتب ساخته شده یا بازسازی شده و اشیاء محاسبه شده محاسبه می شوند.

عملیات تازه سازی بعدی ، چه فردی یا برنامه ریزی شده ، بسیار سریعتر است زیرا فقط پارتیشن های تازه سازی افزایشی تازه می شوند. سایر عملیات پردازش هنوز هم باید مانند ادغام پارتیشن ها و محاسبه مجدد انجام شود ، اما معمولاً زمان بسیار کمتری نسبت به تازه کردن اولیه می گیرد.

گزارش خودکار گزارش

برای گزارش هایی که از یک مجموعه داده با یک سیاست تازه سازی افزایشی برای به دست آوردن آخرین داده ها در زمان واقعی با DirectQuery استفاده می کنند ، ایده خوبی است که بتوانید در یک بازه ثابت یا بر اساس تشخیص تغییر ، تازه سازی صفحه خودکار را فعال کنید تا گزارش ها شامل آخرین داده ها بدون تأخیر باشد. بشربرای کسب اطلاعات بیشتر ، به Refresh Automatic Page In Power BI مراجعه کنید.

تازه سازی افزایشی پیشرفته

اگر مجموعه داده شما با ظرفیت حق بیمه با یک نقطه انتهایی XMLA فعال باشد ، می توان برای سناریوهای پیشرفته ، تجدید افزایشی بیشتر گسترش یافت. به عنوان مثال ، شما می توانید از SQL Server Management Studio برای مشاهده و مدیریت پارتیشن ها ، بوت استرپ عمل تازه سازی اولیه یا تازه کردن پارتیشن های تاریخی با پشتوانه استفاده کنید. برای کسب اطلاعات بیشتر ، با استفاده از نقطه پایانی XMLA ، تازه سازی افزایشی پیشرفته را ببینید.

انجمن

Power BI دارای یک جامعه پر جنب و جوش است که MVPS ، BI Pros و همسالان در گروه های بحث ، فیلم ها ، وبلاگ ها و موارد دیگر تخصص دارند. هنگام یادگیری در مورد تجدید افزایشی ، به این منابع مراجعه کنید:

• جامعه قدرت
• "Power Bi افزایشی" را در بینگ جستجو کنید
• "تازه سازی افزایشی برای پرونده ها" را در بینگ جستجو کنید
• "داده های موجود را با استفاده از تازه سازی افزایشی" در بینگ جستجو کنید

مراحل بعدی

• تنظیم مجدد افزایشی برای مجموعه داده ها
• تازه سازی افزایشی پیشرفته با نقطه پایانی XMLA
• عیب یابی افزایشی افزایشی
• تازه سازی افزایشی برای جریان داده ها