Hướng dẫn sử dụng DirectQuery trong Power BI (Phần 2)

Trong phần trước BAC đã hướng dẫn cách thiết kế mô hình (model design), nội dung lần này, chúng ta sẽ tiếp tục với báo cáo (report). Hãy chắc chắn bạn không bỏ lỡ phần đầu tiên bằng cách xem lại ngay dưới đây trước khi bắt đầu.

Tham khảo: Hướng dẫn sử dụng DirectQuery trong Power BI (Phần 1)

Khi tạo một báo cáo bằng cách sử dụng một kết nối DirectQuery, hãy thực hiện theo hướng dẫn sau:

• Cân nhắc việc dùng các tùy chọn Query Reduction: Power BI cung cấp các tùy chọn trong báo cáo để gửi ít truy vấn hơn và vô hiệu hóa một số tương tác nhất định có thể dẫn đến trải nghiệm kém nếu các kết quả truy vấn mất nhiều thời gian để chạy. Để truy cập các tùy chọn này trong Power BI Desktop, đi đến File > Options and settings > Options và chọn Query reduction.

Các lựa chọn hộp kiểm trên Query reduction cho phép bạn tắt đánh dấu chéo trên toàn bộ báo cáo. Bạn cũng có thể hiển thị nút Apply cho các slicers hoặc tùy tùy chọn bộ lọc. Cách tiếp cận này cho phép bạn sau đó tạo nhiều slicers và các tùy chọn bộ lọc trước khi áp dụng. Không có truy vấn nào được gửi cho đến khi bạn chọn nút Apply trên slicer. Các lựa chọn của bạn sau đó có thể được dùng để lọc dữ liệu.

Các tùy chọn này áp dụng cho báo cáo của bạn khi bạn tương tác với nó trong Power BI Desktop. Các tùy chọn này cũng áp dụng khi người dùng của bạn sử dụng báo cáo trong Power BI service.

• Áp dụng bộ lọc trước: Luôn áp dụng bất kỳ bộ lọc phù hợp nào khi bắt đầu xây dựng trực quan. Ví dụ, thay vì kéo TotalSalesAmount và ProductName, sau đó lọc cho một năm cụ thể, hãy áp dụng bộ lọc vào Year ngay từ đầu. Mỗi bước xây dựng trực quan sẽ gửi một truy vấn. Mặc dù, sau đó có thể thực hiện một thay đổi khác trước khi truy vấn đầu tiên hoàn thành nhưng cách tiếp cận này vẫn để lại tải không cần thiết cho nguồn cơ bản. Bằng cách áp dụng bộ lọc sớm, nó thường làm cho các truy vấn trung gian đó ít tốn kém hơn. Ngoài ra, việc không áp dụng bộ lọc sớm có thể dẫn đến việc đạt đến giới hạn 1 triệu hàng.
• Giới hạn số lượng trực quan trên một trang: Khi bạn mở một trang hoặc thay đổi slicers hay bộ lọc cấp độ trang, tất cả trực quan trên trang sẽ tự động làm mới (refresh). Cũng có giới hạn về số lượng truy vấn được gửi song song. Khi số lượng trực quan tăng lên, một số trực quan sẽ được làm mới theo cách nối tiếp, tăng thời gian làm mới toàn trang. Vì lý do này, bạn nên giới hạn số lượng trực quan trên một trang và thay vào đó hãy có nhiều trang đơn giản hơn.
• Xem xét việc tắt tương tác giữa các trực quan: Mặc định, các trực quan trên một trang báo cáo có thể được dùng để lọc chéo (cross-filter) và đánh dấu chéo (cross-highlight) các trực quan khác trên trang. Ví dụ, đã chọn năm 1999 trên biểu đồ hình tròn, biểu đồ cột được đánh dấu chéo để hiển thị doanh số theo danh mục cho năm 1999.

Lọc chéo và đánh dấu chéo trong DirectQuery yêu cầu các truy vấn phải được gửi đến nguồn cơ bản. Tương tác sẽ bị tắt nếu thời gian thực hiện để phản hồi lựa chọn của người dùng kéo dài một cách bất hợp lý, bạn có thể tắt tương tác này. Tắt tương tác cho toàn bộ báo cáo, như đã mô tả trước đó đối với các tùy chọn giảm truy vấn hoặc tùy theo từng trường hợp.

Ngoài các đề xuất trước đó, mỗi khả năng báo cáo sau đây có thể gây ra các vấn đề về hiệu suất:

• Bộ lọc measures: Các trực quan chứa các measures hoặc tổng hợp của các cột, có thể chứa các bộ lọc trong các measures đó. Ví dụ, đồ họa sau đây biểu diễn SalesAmount by Category nhưng chỉ bao gồm những danh mục có hơn 20 triệu doanh số bán hàng.

Cách tiếp cận này dẫn đến hai truy vấn được gửi đến nguồn cơ bản:

• Truy vấn đầu tiên truy xuất Categories đáp ứng điều kiện, SalesAmount lớn hơn 20 triệu.
• Sau đó, truy vấn thứ hai truy xuất dữ liệu cần thiết cho trực quan, bao gồm các danh mục đáp ứng điều kiện trong mệnh đề WHERE.

Cách tiếp cận này thường hoạt động tốt nếu có hàng trăm hoặc hàng nghìn danh mục như trong ví dụ này. Hiệu suất có thể giảm nếu số lượng danh mục lớn hơn nhiều. Truy vấn không thành công cho hơn một triệu danh mục đáp ứng điều kiện. Giới hạn 1 triệu hàng đã được thảo luận trước đó.

• Bộ lọc TopN: Bộ lọc nâng cao có thể xác định chỉ lọc các giá trị N trên cùng hoặc dưới cùng được xếp theo một vài measure. Ví dụ, bộ lọc top 10 danh mục hàng đầu trong ví dụ trước. Cách tiếp cận này dẫn đến 2 truy vấn được gửi đến nguồn cơ bản. Tuy nhiên, truy vấn đầu tiên trả về tất cả các danh mục từ nguồn cơ bản và sau đó TopN được xác định dựa trên kết quả trả về. Tùy số lượng cột liên quan, phương pháp này có thể dẫn đến các vấn đề hiệu suất hoặc lỗi truy vấn do giới hạn 1 triệu hàng.
• Median (trung bình): Bất kỳ tổng hợp nào như Sum hoặc Count Distinct được đẩy đến nguồn cơ bản. Tuy nhiên, thực tế này không đúng với trung bình mà tổng hợp này thường không được nguồn cơ bản hỗ trợ. Trong những trường hợp như vậy, dữ liệu chi tiết được truy xuất từ nguồn cơ bản và giá trị trung bình được tính từ kết quả trả về. Cách tiếp cận này là hợp lý khi giá trị trung bình được tính trên một số lượng kết quả tương đối nhỏ. Các vấn đề về hiệu suất hoặc lỗi truy vấn do với hạn 1 triệu dòng xảy ra nếu bản số lớn. Ví dụ, Median Country Population (trung bình dân số quốc gia) có thể hợp lý nhưng Median Sales Price (Giá bán hàng trung bình) có thể không.
• Bộ lọc văn bản nâng cao (chứa và tương tự): Khi lọc trên một cột văn bản, bộ lọc nâng cao cho phép các bộ lọc như chưa và bắt đầu…. Các bộ lọc này chắc chắn có thể làm giảm hiệu suất đối với một số nguồn dữ liệu. Đặc biệt, không nên sử dụng bộ lọc chứa mặc định nếu được yêu cầu một kết quả khớp chính xác. Mặc dù, kết quả có thể giống nhau tùy vào dữ liệu thực tế, hiệu suất có thể khác nhau đáng kể do chỉ mục.
• Nhiều lựa chọn slicers: Mặc định, slicer chỉ cho phép thực hiện một lựa chọn duy nhất. Việc cho phép nhiều lựa chọn trong bộ lọc có thể gây ra một số vấn đề về hiệu suất, vì người dùng sẽ chọn một tập hợp các mục trong slicer. Ví dụ, nếu người dùng chọn 10 sản phẩm quan tâm, mỗi lựa chọn mới sẽ dẫn đến các truy vấn được gửi đến nguồn. Mặc dù, người dùng có thể chọn mục tiếp theo trước khi truy vấn hoàn tất nhưng cách này sẽ dẫn đến tải thêm trên nguồn cơ bản.
• Cân nhắc tắt tổng trên trực quan: Mặc định, bảng và ma trận hiển thị tổng và tổng phụ. Trong nhiều trường hợp, các truy vấn riêng biệt phải được gửi đến nguồn cơ bản để lấy các giá trị cho tổng đó. Thực tế này áp dụng bất cứ khi nào sử dụng DistinctCount hoặc mọi trường hợp khi dùng DirectQuery qua SAP BW hoặc SAP HANA. Các tổng số như vậy nên được tắt bằng thanh Format.

Chúng ta vừa đi qua hướng dẫn thiết kế báo cáo, phần cuối cùng của bài viết hướng dẫn sử dụng DirectQuery thành công trong Power BI sẽ được BAC cập nhật tại website bacs.vn, đừng quên đón đọc.

Nguồn tham khảo:

https://docs.microsoft.com/

Đọc tiếp phần 3 tại đây nhé: Hướng dẫn sử dụng DirectQuery trong Power BI (Phần 3)

Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.