Giới thiệu về cách sử dụng DirectQuery trong Power BI (Phần 3)

Qua hai phần đầu tiên của bài viết về cách sử dụng DirectQuery trong Power BI, BAC đã giới thiệu đến bạn các chế độ kết nối và khi nào thì nên sử dụng DirectQuery, bạn có thể xem lại ngay dưới đây. Nội dung lần này, chúng ta sẽ tiếp tục tìm hiểu về các hàm ý của việc sử dụng DirectQuery.

Tham khảo:

Giới thiệu về cách sử dụng DirectQuery trong Power BI (Phần 1)

Giới thiệu về cách sử dụng DirectQuery trong Power BI (Phần 2)

Việc sử dụng DirectQuery có thể có những tác động tiêu cực, một số hạn chế sẽ phụ thuộc vào nguồn chính xác được sử dụng.

1. Hiệu suất và tải trên nguồn cơ bản

Khi dùng DirectQuery, trải nghiệm tổng thể sẽ phụ thuộc rất nhiều vào hiệu suất của nguồn dữ liệu cơ bản. Nếu làm mới mỗi trực quan:

Ví dụ: sau khi thay đổi giá trị slicer, mất vài giây (thường dưới 5 giây), trải nghiệm sẽ hợp lý.

Trải nghiệm có thể chậm hơn so với phản hồi tức thì khi nhập dữ liệu vào Power BI. Nếu sự chậm chạp của nguồn khiến cho từng trực quan riêng mất hàng chục giây, trải nghiệm sẽ trở nên cực kỳ kém và các truy vấn hết thời gian chờ (time out).

Cùng với hiệu suất của nguồn cơ bản, hãy chú ý đến tải đặt trên nguồn, tải sẽ tác động đến hiệu suất. Mỗi người dùng mở một báo cáo (report) được chia sẻ và mỗi dashboard tile được làm mới (refresh), sẽ gửi ít nhất một truy vấn trên mỗi trực quan đến nguồn cơ bản. Điều này thực tế yêu cầu nguồn có thể xử lý truy vấn như vậy, trong khi vẫn duy trì hiệu suất hợp lý.

2. Ý nghĩa bảo mật khi kết hợp các nguồn dữ liệu

Có thể sử dụng nhiều nguồn dữ liệu trong một mô hình DirectQuery, giống như khi bạn nhập dữ liệu bằng cách dùng tính năng Composite models. Khi bạn sử dụng nhiều nguồn dữ liệu, điều quan trọng là phải hiểu cách dữ liệu được di chuyển qua lại giữa các nguồn dữ liệu cơ bản và các tác động bảo mật mà nó mang lại.

3. Những hạn chế chuyển đổi dữ liệu

Có những hạn chế trong việc chuyển đổi dữ liệu có thể áp dụng trong Query Editor. Với dữ liệu được nhúng (import), bạn có thể dễ dàng áp dụng một tập hợp các phép biến đổi phức tạp để làm sạch và định hình lại dữ liệu trước khi sử dụng nó để tạo trực quan, chẳng hạn như khi phân tích cú pháp JSON documents hoặc xoay vòng dữ liệu từ dạng cột sang dạng hàng. Những chuyển đổi đó bị hạn chế trong DirectQuery.

Đầu tiên, khi kết nối với nguồn OLAP như SAP Business Warehouse, không có chuyển đổi nào có thể được xác định và toàn bộ mô hình bên ngoài được lấy từ nguồn. Đối với các nguồn quan hệ, như SQL Server, vẫn có thể xác định một tập hợp các chuyển đổi cho mỗi truy vấn nhưng các phép chuyển đổi đó bị giới hạn vì lí do hiệu suất.

Bất kỳ chuyển đổi nào như vậy sẽ cần được áp dụng trên mọi truy vấn tới nguồn cơ bản, thay vì một lần khi làm mới dữ liệu, vì vậy chúng bị giới hạn ở những chuyển đổi có thể được dịch một cách hợp lý thành một truy vấn gốc. Nếu bạn sử dụng một phép chuyển đổi quá phức tạp, bạn sẽ bị lỗi phải xóa nó đi hoặc chuyển mô hình sang import.

Ngoài ra, truy vấn là kết quả từ hộp thoại Get Data hoặc Query Editor sẽ được sử dụng trong một lựa chọn phụ (subselect) trong các truy vấn được tạo và gửi để truy xuất dữ liệu cần thiết cho trực quan. Truy vấn được xác định trong Query Editor phải hợp lệ trong ngữ cảnh này. Đặc biệt, không thể sử dụng truy vấn dùng Common Table Expressions cũng như Stored Procedures.

4. Giới hạn mô hình hóa

Thuật ngữ mô hình hóa (modeling) trong ngữ cảnh này có nghĩa là hành động tinh chỉnh và làm giàu dữ liệu thô như một phần của việc tạo báo cáo bằng cách sử dụng nó. Ví dụ như:

• Xác định mối quan hệ giữa các bảng
• Thêm các phép tính mới (calculated columns và measures)
• Đổi tên và ẩn các cột và measures
• Xác định cấu trúc phân cấp
• Xác định định dạng, tóm tắt mặc định và thứ tự sắp xếp cho một cột
• Nhóm hoặc nhóm các giá trị

Khi dùng DirectQuery, nhiều mô hình trong này có thể được làm giàu và chắc chắn có nguyên tắc là dữ liệu thô được làm giàu để cải thiện mức tiêu thụ sau này. Tuy nhiên, có một số khả năng mô hình hóa không khả dụng hoặc bị hạn chế khi dùng DirectQuery. Các giới hạn thường được áp dụng để tránh các vấn đề về hiệu suất. Tập hợp các giới hạn chung cho tất cả các nguồn DirectQuery được liệt kê ở đây.

• Không có phân cấp ngày tháng cài sẵn: Khi nhập dữ liệu, mọi cột date hoặc datetime cũng sẽ có phân cấp ngày tích hợp sẵn. Ví dụ: nếu nhập một bảng đơn đặt hàng gồm một cột OrderDate, khi dùng OrderDate trong trực quan, nó sẽ có thể chọn cấp độ (năm, tháng, ngày) để dùng. Hệ thống phân cấp ngày tích hợp này không có sẵn trong DirectQuery. Nếu có sẵn bảng Date trong nguồn cơ bản, thì các hàm DAX Time Intelligence có thể dùng bình thường.
• Chỉ hỗ trợ ngày giờ chính xác đến giây: Khi sử dụng cột thời gian trong tập dữ liệu của bạn, Power BI chỉ đưa ra các truy vấn đến nguồn bên dưới ở cấp độ chi tiết từng giây. Các truy vấn không được gửi đến nguồn DirectQuery trong mili giây. Xóa phần thời gian này khỏi các cột nguồn của bạn.
• Hạn chế trong calculated columns: Calculated columns bị giới hạn là trong hàng, vì chúng chỉ có thể tham chiếu đến các giá trị của cột khác trong cùng bảng mà không dùng bất kì hàm tổng hợp nào. Ngoài ra, các hàm DAX vô hướng như LEFT (), được cho phép, bị giới hạn ở những hàm có thể được đẩy đến nguồn cơ bản. Các hàm khác nhau tùy thuộc vào khả năng chính xác của nguồn. Các hàm không được hỗ trợ sẽ không được liệt kê trong chế độ tự động khi tạo DAX cho một calculated column và xảy ra lỗi nếu sử dụng.
• Không hỗ trợ hàm DAX parent-child: Khi ở chế độ DirectQuery, không thể sử dụng các hàm họ DAX PATH () thường xử lý cấu trúc Parent-Child như biểu đồ tài khoản hoặc phân cấp nhân viên.
• Calculated table không được hỗ trợ: Khả năng xác định một calculated table sử dụng một hàm DAX không được hỗ trợ trong chế độ DirectQuery.
• Lọc mối quan hệ: Bạn có thể tải tài liệu về Bidirectional cross-filtering (lọc chéo hai chiều) tại đây.
• Không phân cụm: Khi dùng DirectQuery, không thể sử dụng tính năng phân cụm để tự động tìm các nhóm.

Đến đây bài viết đã khá dài, chúng ta sẽ tiếp tục khám phá những hàm ý của việc sử dụng DirectQuery trong phần sau. Đừng quên theo dõi các nội dung mới nhất sẽ được cập nhật tại website bacs.vn.

Nguồn tham khảo:

https://docs.microsoft.com/

Đọc tiếp phần 4 tại đây nhé: Giới thiệu về cách sử dụng DirectQuery trong Power BI (Phần 4)

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.