透過資料流，你可以將大量資料帶入 Power BI 或組織提供的儲存空間。 然而，在某些情況下，每次刷新都更新完整原始資料並不實際。 一個不錯的替代方案是 增量刷新，為資料流帶來以下好處：
- 刷新速度較快：只有變更過的資料需要重新整理。 例如，僅重新整理過去十年的資料流中最後五天的資料。
- 刷新更可靠：例如，不需要維持與易失源系統的長時間連線。
- 資源消耗減少：需要刷新的資料減少，整體記憶體及其他資源的消耗也會降低。
增量刷新可在 Power BI 建立的資料流及 Power Apps 中建立的資料流中提供。 本文展示了 Power BI 的畫面，但這些指示適用於在 Power BI 或 Power Apps 中建立的資料流。
備註
當分析資料流中某個資料表的結構變更時，會進行完整刷新，以確保所有產生的資料與新架構相符。 因此，任何以增量方式儲存的資料都會被刷新，有時如果來源系統沒有保留歷史資料，就會遺失。
在 Power BI 建立的資料流中使用增量刷新，需要資料流位於 Premium 容量的工作區中。 Power Apps 的增量刷新需要 Power Apps 的每個應用程式或每位使用者的方案，且僅適用於以 Azure Data Lake Storage 為目的地的資料流。
在 Power BI 或 Power Apps 中，使用增量刷新要求資料流中擷取的原始資料必須有一個 DateTime 欄位，以供增量刷新過濾。
為資料流設定增量刷新
資料流可以包含多個資料表。 增量刷新是在資料表層級設定的，允許一個資料流同時存放完全刷新的資料表與增量更新的資料表。
要建立增量刷新的資料表，請先按照配置其他資料表的方式來配置你的資料表。
資料流建立並儲存後，請在表格視圖中選擇 增量刷新
，如下圖所示。
當你選擇圖示時，會顯示 增量刷新設定 視窗。 開啟增量刷新。
以下清單說明了 增量刷新設定 視窗中的設定。
增量刷新開關：開啟或關閉該表格的增量刷新政策。
篩選欄位下拉選單：選擇用於篩選表格以便進行增量的查詢欄位。 此欄位僅包含 DateTime 欄位。 如果你的表格沒有 DateTime 欄位，就不能使用增量刷新。
這很重要
選擇一個不變的日期欄位作為增量刷新過濾器。 若欄位值改變（例如 已修改日期 欄位），此變更可能因資料中的重複值導致刷新失敗。
儲存/刷新過去的資料列：前一張圖片中的範例說明了接下來的幾個設定。
在此範例中，我們定義了一個更新政策，總共儲存五年的資料，並逐步刷新 10 天的資料。 假設資料表每日更新，每次刷新操作會執行以下動作：
新增一天的數據。
更新資料至最近 10 天，直至當前日期。
移除比當前日期超過五年的曆年。 例如，如果目前日期是2019年1月1日，則會移除2013年。
第一次資料流更新可能需要一段時間才能匯入全部五年，但後續更新通常會更快完成。
偵測資料變更：10天的增量刷新比五年的全面更新更有效率，但你可能能做得更好。 當你選擇「 偵測資料變更 」勾選框時，可以選擇日期/時間欄位，只識別並刷新資料變更的日期。 此假設來源系統中存在此類欄位，而來源系統通常用於稽核目的。 會評估此資料行在累加式範圍之每個週期的最大值。 如果這些資料自上次刷新以來沒有變動，就不需要重新整理該期間。 在這個例子中，這可能進一步將逐步刷新的天數從10天減少到大約2天。
小提示
目前的設計要求用來偵測資料變更的欄位必須被持久化並快取到記憶體中。 你或許可以考慮以下技術之一，以減少基數和記憶體使用量：
- 在刷新時，僅維持該欄位的最大值，或許可使用 Power Query 函式。
- 把精度降低到符合你刷新頻率需求的可接受水平。
只刷新完整周期：想像你的刷新排程在每天凌晨4點執行。 如果資料在當天的前四小時內出現在來源系統中，你可能會選擇不將其納入考量。 有些商業指標，例如油氣產業的每日桶數，並不實際或合理，無法僅以部分天數來計算。
另一個只適合刷新完整期間的例子是從金融系統更新資料。 想像一個金融系統，上個月的資料在當月的第12個日曆日被核准。 你可以將增量範圍設為一個月，並排程在每月 12 日執行刷新。 選擇此選項後，系統將於2月12日刷新1月資料（最近完整的月度期間）。
備註
資料流增量刷新依照以下邏輯決定日期：若排程刷新，資料流的增量刷新會使用刷新政策中定義的時區。 若無刷新排程，增量刷新會使用執行刷新的電腦時間。
設定好增量刷新後，資料流會自動修改你的查詢，加入依日期篩選。 如果資料流是在 Power BI 中建立的，你也可以使用 Power Query 的進階編輯器來編輯自動產生的查詢，來微調或自訂你的刷新。 請閱讀以下章節，了解更多關於增量刷新及其運作方式。
備註
當你編輯資料流時，Power Query 編輯器會直接連接到資料來源，並且在增量刷新策略處理資料流後，不會顯示快取或已篩選的資料。 要檢查資料流中快取的資料，請在設定增量刷新政策並刷新資料流後，從 Power BI Desktop 連接到資料流。
增量刷新與連結資料表與計算資料表的比較
對於 連結 資料表，則會以增量刷新方式更新來源資料表。 由於連結資料表只是指向原始資料表的指標，增量刷新對連結資料表沒有影響。 當來源資料表依其定義的刷新政策被刷新時，任何連結資料表都應假設原始資料已被刷新。
計算 表是基於在資料存放庫上執行的查詢，而資料存放庫也可以是另一種資料流程。 因此，計算出的表格與連結表格的行為相同。
由於計算資料表與連結資料表的行為相似，兩者的需求與設定步驟相同。 其中一個差異是，對於計算資料表，在某些配置中，增量刷新無法以最佳化方式執行，這是因為分割區的建構方式。
在增量刷新與全刷新之間切換
資料流支援在增量與完整刷新間調整刷新政策。 當變動發生在任一方向（從滿到增量或增量到滿）時，該變更會影響下一次刷新後的資料流。
當你將資料流從完全刷新改為增量更新時，新的刷新邏輯會依照增量刷新設定中的刷新視窗和增量來更新資料流。
當你將資料流從增量式重新整理到完整刷新時，增量式重新整理中累積的所有資料都會覆蓋完整重新整理時所定義的政策。 你必須批准這個行動。
增量刷新中的時區支援
資料流的增量刷新取決於執行時間。 查詢的過濾取決於執行日期。
為了因應這些依賴性並確保資料一致性，資料流的增量刷新實作了以下的啟發式情境以因應 立即刷新：
若系統中定義了排程刷新，增量刷新則使用排程刷新區段的時區設定。 這個過程確保無論刷新資料流的人身處何時區，都與系統定義一致。
若未定義排程刷新，資料流則使用執行刷新使用者電腦的時區。
增量刷新也可透過 API 來呼叫。 在這種情況下，API 呼叫可以保留一個時區設定，用於刷新。 使用 API 對於測試和驗證的目的很有幫助。
增量刷新實作細節
資料流使用分割來進行增量刷新。 資料流中的增量刷新會保留最少的分割區數量以符合刷新政策的要求。 舊分割區若超出範圍會被刪除，這會維持一個滾動視窗。 分割區會被機會性地合併，減少所需分割區的總數。 這個最小分割區數提升了壓縮效率，在某些情況下還能提升查詢效能。
本節範例共享以下刷新政策：
- 過去一季的商店行列
- 過去 10 天的刷新列
- 偵測資料變更 = 否
- 僅刷新完整天數 = 為真
合併分割區
在這個例子中，日分割在超出增量範圍後會自動合併到月份層級。 增量範圍內的分區需要以每日的詳細程度來維護，以便僅刷新那些特定的日期。 以 Run Date 12/11/2016 進行刷新操作會合併 11 月份的天數，因為它們不在增量範圍內。
刪除舊分割區
超出總範圍的舊分割區會被移除。 使用 執行日期 2017 年 1 月 2 日 的刷新操作會丟棄 2016 年第三季的分割區，因為該分割區超出了整體範圍。
從長期故障中恢復
此範例模擬系統如何從長時間故障中優雅復原。 假設因為資料來源憑證過期，刷新無法成功執行，問題需要 13 天才解決。 增量範圍只有10天。
下一次成功的刷新操作，運行日期為 2017/1/15，需要補填缺失的 13 天並重新整理。 它也需要重新整理過去九天的資料，因為他們沒有按照正常的時間表重新整理。 換句話說，增量間隔從10天延長到22天。
下一次刷新作業，運行日期為 2017 年 1/16 日，藉此機會將 2016 年第四季的 12 月與月份合併。
資料流增量刷新與資料集
資料流增量刷新與資料集增量更新設計成協同運作。 在資料流中有一個增量刷新的資料表，且完全載入資料集，或是資料流中一個已完全載入的資料表，並以增量方式載入資料集，是可以接受且被支援的。
兩種方法都依照你在刷新設定中指定的定義運作。 更多資訊： Power BI Premium 的增量更新
相關內容
本文描述了資料流的增量刷新。 以下是一些可能有用的文章：
- 自助數據準備在 Power BI 中
- 在數據流中建立計算數據表
- 為數據流連接數據來源
- 數據流之間的鏈接資料表
- 在Power BI 中建立和使用數據流
- 使用本地資料來源的資料流
- Power BI 資料流開發者資源
如需 Power Query 和排程重新整理的詳細資訊，您可以閱讀下列文章：
欲了解更多關於 Common Data Model 的資訊，請參閱其概述文章：