Power BI chạy tốt với dữ liệu nhỏ nhưng refresh có thể chậm dần khi lịch sử tăng. Incremental refresh giúp chỉ làm mới phần dữ liệu cần thiết, nhưng hiệu quả phụ thuộc lọc ngày, query folding và thiết kế nguồn.
Một dashboard Power BI có thể chạy ổn trong năm đầu tiên. Dữ liệu ERP mới vài trăm nghìn dòng, refresh mất vài phút. Nhưng Sales, Inventory, Purchase và Finance tiếp tục phát sinh mỗi ngày; lịch sử giao dịch ngày càng dài trong khi phần lớn dữ liệu cũ không còn thay đổi.
Tại sao mỗi sáng Power BI phải đọc lại dữ liệu của ba hoặc năm năm trước? Đây là bài toán mà Incremental Refresh Power BI được thiết kế để giải quyết.
Trả lời nhanh
Incremental Refresh cho phép giữ dữ liệu lịch sử nhưng chỉ làm mới những khoảng cần thiết theo policy. Sau khi semantic model được publish và refresh trên Power BI Service, dịch vụ quản lý dữ liệu theo partition. Cách này đặc biệt hữu ích với Fact table lớn, tăng theo thời gian và có lịch sử tương đối ổn định.
Vì sao Power BI càng chạy lâu càng dễ refresh chậm?
Một bảng Sales Transaction có thể tăng từ 500.000 dòng lên hàng triệu dòng sau vài năm. Nếu Power Query yêu cầu nguồn trả lại toàn bộ lịch sử trong mỗi lần refresh, khối lượng đọc, truyền và xử lý dữ liệu sẽ tiếp tục tăng.
Trong thực tế, hóa đơn ba năm trước phần lớn đã đóng; dữ liệu hôm nay hoặc tháng này mới thường xuyên phát sinh và điều chỉnh. Full refresh vì thế có thể tiêu tốn tài nguyên để đọc lại phần dữ liệu vốn không thay đổi.
Khi Power BI trở thành một phần của hệ thống BI doanh nghiệp, refresh còn liên quan đến database nguồn, gateway, network, capacity và thời điểm dữ liệu sẵn sàng. Bài Power BI cho doanh nghiệp nhỏ trình bày kiến trúc tổng thể từ nguồn đến semantic model và report.
Incremental Refresh hoạt động như thế nào?
Microsoft sử dụng hai parameter DateTime có tên chính xác là RangeStart và RangeEnd. Chúng được dùng trong Power Query để lọc table theo cột thời gian phù hợp.
Sau đó, người thiết kế cấu hình policy: chẳng hạn lưu năm năm lịch sử nhưng chỉ refresh dữ liệu gần đây. Policy thực sự được áp dụng sau khi model được publish lên Power BI Service và thực hiện refresh.
Nguồn ERP/SQL
↓
RangeStart / RangeEnd
↓
Incremental Refresh Policy
↓
Partitions trên Power BI Service
↓
Chỉ làm mới vùng cần thiết
Archive period và refresh period khác nhau ra sao?
Archive period: cần giữ lịch sử bao lâu?
Đây là phạm vi dữ liệu lưu trong semantic model, ví dụ năm năm gần nhất. Dữ liệu được lưu không có nghĩa toàn bộ năm năm đều phải đọc lại mỗi lần.
Refresh period: dữ liệu cũ bao lâu vẫn có thể thay đổi?
Nếu ERP cho phép điều chỉnh giao dịch trong 30 ngày gần nhất, refresh một ngày có thể quá ngắn. Ngược lại, nếu dữ liệu sau khóa sổ hầu như không đổi, refresh lại cả năm có thể dư thừa.
Incremental Refresh không bắt đầu từ nút cấu hình Power BI. Nó bắt đầu từ câu hỏi: dữ liệu của doanh nghiệp còn có thể thay đổi trong bao lâu?
RangeStart và RangeEnd: ranh giới phải rõ
Power Query cần lọc table bằng RangeStart và RangeEnd. Một thực hành quan trọng là thiết kế điều kiện để một record không đồng thời thuộc hai partition, chẳng hạn lớn hơn hoặc bằng RangeStart và nhỏ hơn RangeEnd.
Ví dụ FactSales dùng PostingDate để phân vùng. Cần kiểm tra kiểu DateTime, múi giờ và các record đúng ranh giới ngày hoặc tháng để tránh trùng hoặc thiếu dữ liệu.
Query Folding là điểm cần kiểm tra sớm
Có RangeStart và RangeEnd không đồng nghĩa nguồn chắc chắn chỉ trả về đúng khoảng cần thiết. Với nguồn hỗ trợ query folding, Power Query có thể đẩy điều kiện lọc xuống database thay vì kéo toàn bộ bảng về rồi mới lọc.
Nếu một bước transformation làm mất query folding trước bước lọc, lượng dữ liệu phải xử lý có thể vẫn rất lớn. Vì vậy, với ERP hoặc SQL, nên lọc sớm khi hợp lý và kiểm tra query folding trước khi thêm nhiều bước biến đổi.
Nếu cần nền tảng Power Query và Data Model, hãy đọc Tự học Power BI từ A–Z.
Đừng tối ưu refresh trước khi hiểu dữ liệu ERP
Ngày dùng để phân vùng và ngày dữ liệu thực sự thay đổi có thể không phải cùng một cột. Invoice có PostingDate từ tháng trước nhưng hôm nay được cập nhật trạng thái hoặc phát sinh Credit Memo liên quan. Nếu policy chỉ refresh vài ngày dựa vào PostingDate, dashboard có thể bỏ sót thay đổi.
Hãy làm rõ vòng đời transaction, kỳ khóa sổ, khả năng ghi lùi ngày và các nghiệp vụ điều chỉnh trước khi chọn archive period và refresh period.
Detect data changes dùng khi nào?
Detect data changes cho phép chỉ định một cột DateTime để Power BI xác định khoảng có thay đổi. Cột này thường mang ý nghĩa audit hoặc thời điểm record được cập nhật và có thể khác cột dùng để phân vùng.
Tính năng này không thể sửa một nguồn không lưu ModifiedDate đáng tin cậy. Nếu thay đổi nghiệp vụ không cập nhật cột audit, policy vẫn có nguy cơ bỏ sót dữ liệu.
Table nào phù hợp với Incremental Refresh?
| Loại dữ liệu | Mức phù hợp | Lý do |
|---|---|---|
| Sales transaction nhiều năm | Cao | Tăng liên tục theo thời gian |
| Inventory movement | Cao | Lịch sử giao dịch thường lớn |
| Customer master | Thấp hơn | Nhỏ hơn và record cũ vẫn có thể đổi |
| Calendar | Không cần | Nhỏ và dễ tạo lại |
Incremental Refresh không tự làm visual chạy nhanh, không sửa Star Schema sai và không thay thế tối ưu nguồn. Bài Power BI là gì? giải thích vai trò của Power Query, Data Model, DAX và Service.
Quy trình triển khai thực tế
- Xác định Fact table lớn: xem số dòng, dung lượng và tốc độ tăng.
- Hiểu vòng đời transaction: xác định dữ liệu cũ bao lâu vẫn có thể sửa.
- Chọn cột thời gian: bảo đảm kiểu dữ liệu và ý nghĩa nghiệp vụ phù hợp.
- Tạo RangeStart và RangeEnd: dùng đúng tên và kiểu DateTime.
- Áp dụng filter: kiểm tra query folding khi nguồn hỗ trợ.
- Thiết lập policy: xác định thời gian lưu lịch sử và vùng làm mới.
- Publish và refresh: theo dõi lần đầu và các lần tiếp theo trên Service.
- Đối soát: so sánh với ERP, nhất là ranh giới partition và giao dịch sửa muộn.
Refresh nhanh hơn nhưng số liệu sai không phải là tối ưu. Thiết kế dashboard vẫn phải bắt đầu từ câu hỏi quản trị, như phân tích trong bài Dashboard không nên bắt đầu từ biểu đồ.
Checklist trước khi bật Incremental Refresh
- Table có đủ lớn để tính năng mang lại giá trị?
- Dữ liệu có tăng tự nhiên theo thời gian?
- Cột ngày phân vùng có đáng tin cậy?
- Dữ liệu lịch sử có thể được cập nhật muộn?
- Refresh period đã bao phủ các ngoại lệ nghiệp vụ?
- RangeStart và RangeEnd đã lọc đúng ranh giới?
- Query folding còn hoạt động tại bước filter?
- ModifiedDate có đáng tin nếu dùng Detect data changes?
- Đã test record ở ranh giới ngày hoặc tháng?
- Đã đối soát với nguồn sau khi publish?
Câu hỏi thường gặp
Incremental Refresh Power BI là gì?
Đây là cơ chế giữ dữ liệu lịch sử nhưng chỉ làm mới các khoảng cần thiết theo policy. Power BI Service quản lý dữ liệu thành partition thay vì mỗi lần xử lý toàn bộ table.
RangeStart và RangeEnd dùng để làm gì?
Đây là hai parameter DateTime dùng để lọc table theo khoảng thời gian, làm cơ sở để Power BI Service quản lý các partition lịch sử và vùng cần refresh.
Incremental Refresh có làm report chạy nhanh hơn?
Không trực tiếp. Tính năng chủ yếu giảm dữ liệu cần xử lý khi refresh. Tốc độ tương tác còn phụ thuộc semantic model, relationship, cardinality, DAX, chế độ lưu trữ và thiết kế visual.
Query Folding có bắt buộc không?
Tùy nguồn, nhưng với nguồn hỗ trợ query folding, việc đẩy filter xuống nguồn rất quan trọng. Nếu nguồn vẫn trả lượng dữ liệu lớn rồi Power Query mới lọc, lợi ích có thể giảm đáng kể.
Có nên dùng cho mọi table?
Không. Nên ưu tiên table lớn, tăng theo thời gian và có lịch sử ít thay đổi. Dimension nhỏ thường không cần thêm độ phức tạp.
Kết luận
Incremental Refresh Power BI phù hợp khi dữ liệu doanh nghiệp có lịch sử đủ dài và phần gần đây mới thường xuyên thay đổi. Giá trị không chỉ nằm ở nút cấu hình mà ở việc hiểu vòng đời transaction, chọn đúng cột ngày, giữ query folding và đối soát sau khi partition được tạo.
Trước khi bật Incremental Refresh, hãy xác định rõ dữ liệu ERP có thể thay đổi trong bao lâu và kiểm tra lại số liệu nguồn sau khi publish.
Nguồn kỹ thuật: Microsoft Learn – Configure incremental refresh for Power BI semantic models.