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

Là phần cuối cùng của loạt bài viết hướng dẫn sử dụng DirectQuery trong Power BI. Đừng quên xem lại hai phần trước để không bỏ lỡ các kiến thức quan trọng về DirectQuery.

Tham khảo:

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

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

1. Tùy chọn số lượng kết nối tối đa cho DirectQuery

Bạn có thể thiết lập số lượng kết nối tối đa DirectQuery mở cho mỗi nguồn dữ liệu cơ bản, điều này kiểm soát số lượng truy vấn được gửi đồng thời đến mỗi nguồn dữ liệu.

DirectQuery mở số lượng tối đa mặc định là 10 kết nối đồng thời. Bạn có thể thay đổi số lượng cho tệp hiện tại trong Power BI Desktop. Đi đến File > Options and Settings > Options. Trong phần Current File ở bên trái, chọn DirectQuery.

Cài đặt chỉ khởi động khi có ít nhất một nguồn DirectQuery trong báo cáo hiện tại. Giá trị áp dụng với tất cả nguồn DirectQuery và với bất kỳ nguồn DirectQuery nào được thêm vào cùng báo cáo.

Tăng tối đa kết nối trên mỗi nguồn dữ liệu (Maximum connections per data source) đảm bảo có thể gửi nhiều truy vấn hơn, lên đến số lượng tối đa được chỉ định, đến nguồn dữ liệu cơ bản. Cách tiếp cận này hữu ích khi nhiều trực quan nằm trên cùng một trang hoặc nhiều người dùng truy cập vào một báo cáo cùng lúc. Khi đạt đến số lượng kết nối tối đa, các truy vấn khác sẽ được xếp hàng đợi cho đến khi có kết nối. Việc tăng giới hạn này dẫn đến tải nhiều hơn trên nguồn cơ bản, do đó, cài đặt không được đảm bảo để cải thiện hiệu suất tổng thể.

Khi một báo cáo được xuất bản, số lượng truy vấn đồng thời tối đa được gửi đến nguồn dữ liệu cơ bản cũng phụ thuộc vào các giới hạn cố định. Các giới hạn phụ thuộc vào môi trường mục tiêu mà báo cáo được xuất bản. Các môi trường khác nhau như Power BI, Power BI Premium hoặc Power BI Report Server có thể áp đặt các giới hạn khác nhau.

Lưu ý: Số lượng cài đặt kết nối DirectQuery tối đa áp dụng cho tất cả các nguồn DirectQuery khi siêu dữ liệu nâng cao (enhanced metadata) được bật, đây là cài đặt mặc định cho tất cả các kiểu máy được tạo trong Power BI Desktop kể từ tháng 10 năm 2020.

2. Chẩn đoán các vấn đề về hiệu suất

Bạn nên chuẩn đoán các vấn đề về hiệu suất trên Power BI Desktop thay vì Power BI service. Các vấn đề về hiệu suất thường dựa trên hiệu suất của nguồn cơ bản. Bạn có thể dễ dàng xác định và chẩn đoán sự cố trong môi trường tách biệt của Power BI Desktop. Cách tiếp cận này ban đầu sẽ loại bỏ một số thành phần nhất định như cổng Power BI. Nếu vấn đề hiệu suất không có trong Power BI Desktop, hãy điều tra các chi tiết cụ thể của báo cáo trong Power BI service.

Trước tiên, bạn nên cố tách mọi vấn đề với một trực quan riêng lẻ thay vì nhiều trực quan trên một trang. Giả sử các bước trong giai đoạn trước trong phần này đã được thực hiện. Bây giờ, chúng ta có một trực quan duy nhất trên trang Power BI Desktop vẫn còn chậm. Sử dụng bộ phân tích hiệu suất để xác định các truy vấn mà Power BI Desktop gửi đến nguồn cơ bản. Cũng có thể xem các dấu vết và thông tin chẩn đoán có thể được phát ra bởi nguồn dữ liệu cơ bản. Dấu vết cũng có thể chứa các chi tiết hữu ích về cách thực thi và cải thiện truy vấn.

Hơn nữa, ngay cả khi không có các dấu vết như vậy từ nguồn, vẫn có thể xem các truy vấn được gửi bởi Power BI, cùng với thời gian thực thi của chúng như được mô tả trong phần tiếp theo.

2.1. Xác định các truy vấn đã được gửi bởi Power BI Desktop

Mặc định, Power BI Desktop ghi lại các sự kiện trong một phiên (session) nhất định vào một tệp theo dõi có tên FlightRecorderCurrent.trc.

Đối với một số nguồn DirectQuery, nhật ký này bao gồm tất cả truy vấn được gửi đến nguồn dữ liệu cơ bản. Các nguồn DirectQuery còn lại sẽ được đưa vào trong tương lai. Các nguồn sau gửi truy vấn đến nhật ký:

• SQL Server
• Azure SQL Database
• Azure SQL Data warehouse
• Oracle
• Teradata
• SAP HANA

Tệp theo dõi có thể tìm thấy trong thư mụcAppData cho người dùng hiện tại:

<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

Để truy cập thư mục này trong Power BI Desktop, chọn File > Options and Settings > Options và sau đó chọn Diagnostics. Hộp thoại sau xuất hiện:

Khi bạn chọn Open crash dump/traces folder, bên dưới Diagnostic Options, thư mục sau sẽ mở: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Điều hướng đến thư mục mẹ của thư mục đó sẽ hiển thị thư mục chứa AnalysisServicesWorkspaces, thư mục này sẽ chứa một thư mục workspace cho mọi phiên bản Power BI Desktop đang mở. Các thư mục này được đặt tên bằng hậu tố số nguyên như AnalysisServicesWorkspace2058279583.

Bên trong thư mục đó là thư mục \Data, nó chứa tệp theo dõi FlightRecorderCurrent.trc cho phiên Power BI hiện tại. Thư mục workspace tương ứng sẽ bị xóa khi phiên Power BI Desktop được liên kết kết thúc.

Các tệp theo dõi có thể được đọc bằng công cụ SQL Server Profile. Tải xuống nó như một phần của SQL Server Management Studio tải xuống miễn phí.

Sau khi bạn tải xuống và cài đặt SQL Server Management Studio, hãy chạy SQL Server Profiler.

Để mở tệp theo dõi, thực hiện các bước sau:

• Bước 1: Trong SQL Server Profiler, chọn File > Open > Trace file.
• Bước 2: Nhập đường dẫn đến tệp theo dõi cho phiên Power BI đang mở như:

C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.

• Bước 3: Mở FlightRecorderCurrent.trc.

Tất cả sự kiện từ phiên hiện tại được hiển thị. Một ví dụ có chú thích được hiển thị ở đây, làm nổi bật các nhóm sự kiện, mỗi nhóm có các sự kiện sau:

• Sự kiện Query Begin và Query End, đại diện cho sự bắt đầu và kết thúc của truy vấn DAX được tạo bởi giao diện người dùng. Ví dụ, từ hình ảnh trực quan hoặc từ việc điền danh sách các giá trị trong giao diện người dùng bộ lọc.
• Một hoặc nhiều cặp sự kiện DirectQuery Begin và DirectQuery End, đại diện cho một truy vấn được gửi đến nguồn dữ liệu cơ bản như một phần của việc đánh giá truy vấn DAX.

Nhiều truy vấn DAX có thể chạy song song, do đó các sự kiện từ các nhóm khác nhau có thể được xen kẽ. Giá trị của ActivityID có thể được sử dụng để xác định những sự kiện nào thuộc cùng một nhóm.

Các cột quan tâm khác như sau:

• Text Data: Các chi tiết văn bản của sự kiện, đối với các sự kiện Query Begin/ End, chi tiết là truy vấn DAX. Đối với các sự kiện DirectQuery Begin/End, chi tiết là truy vấn SQL được gửi đến nguồn cơ bản. Dữ liệu văn bản (Text Data) cho sự kiện hiện được chọn cũng được hiển thị trong vùng dưới cùng.
• EndTime: Thời gian khi sự kiện hoàn tất.
• Duration: Thời lượng, tính bằng mili giây để thực thi truy vấn DAX hoặc SQL.
• Error: Cho biết nếu có lỗi xảy ra, trong trường hợp đó sự kiện cũng được hiển thị bằng màu đỏ.

Trong bảng trên, một số cột ít được quan tâm đã được thu hẹp, để cho phép các cột khác có thể dễ nhìn hơn.

Bạn có thể dùng các phương pháp sau để ghi lại dấu vết để giúp chuẩn đoán các vấn đề hiệu suất tìm ẩn:

• Mở một phiên Power BI Desktop duy nhất để tránh nhầm lẫn giữa nhiều thư mục workspace.
• Thực hiện một tập hợp các hành động quan tâm trong Power BI Desktop. Bao gồm một số hành động bổ sung để đảm bảo rằng các sự kiện quan tâm được chuyển vào tệp theo dõi.
• Mở SQL Server Profiler và kiểm tra dấu vết như mô tả trước đó. Hãy nhớ rằng việc đóng Power BI Desktop sẽ xóa tệp theo dõi. Ngoài ra, các tác vụ khác trong Power BI Desktop không xuất hiện ngay lập tức. Tệp theo dõi phải được đóng và mở lại để xem các sự kiện mới.
• Giữ các phiên riêng lẻ ở mức độ nhỏ vừa phải, có thể là 10 giây hành động, không phải hàng trăm. Cách tiếp cận này giúp việc giải thích tệp theo dõi dễ dàng hơn. Cũng có một giới hạn về kích thước của tệp theo dõi. Đối với các phiên dài, có khả năng các sự kiện sớm bị bỏ qua.

2.2. Hiểu dạng truy vấn được gửi bởi Power BI Desktop

Định dạng chung của các truy vấn được tạo và gửi bởi Power BI Desktop sử dụng các lựa chọn con cho mỗi bảng được tham chiếu. Query Editor truy vấn xác định lựa chọn con (subselect). Ví dụ, giả sử các bảng TPC-DS sau trong SQL Server.

Xem xét truy vấn sau:

Truy vấn dẫn đến trực quan sau:

Làm mới trực quan đó sẽ dẫn đến truy vấn SQL được hiển thị ở đây. Như bạn có thể nói, có ba subselect cho Web Sales, Item và Date_dim, mỗi danh sách trả về tất cả các cột trên bảng tương ứng, mặc dù chỉ có bốn cột thực sự được tham chiếu bằng hình ảnh. Các truy vấn này trong các subselect được tô bóng (shade) chính xác là kết quả của các truy vấn được xác định trong Query Editor. Cho đến nay, việc sử dụng các subselect theo cách này không ảnh hưởng đến hiệu suất của các nguồn dữ liệu được hỗ trợ cho DirectQuery. Cách nguồn dữ liệu như SQL Server tối ưu hóa loại bỏ các tham chiếu đến các cột khác.

Power BI sử dụng mẫu này vì truy vấn SQL được dùng có thể được cung cấp trực tiếp bởi nhà phân tích. Nó được sử dụng như được cung cấp mà không cố gắng viết lại nó.

Như vậy, chúng ta đã hoàn tất hướng dẫn sử dụng DirectQuery thành công trong Power BI. Hy vọng bài viết đã cung cấp những thông tin hữu ích dành cho bạn đọc. Đừng quên theo dõi các nội dung mới nhất tại website bacs.vn và tham gia khóa học Power BI tại BAC để trang bị cho mình những kiến thức nền tảng về phân tích và trực quan dữ liệu.

Nguồn tham khảo:

https://docs.microsoft.com/

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.