Sử dụng composite models trong Power BI Desktop (Phần 2)

Nếu bạn chưa biết đến khái niệm composite models trong Power BI Desktop hãy xem lại phần đầu tiên của bài viết ngay dưới đây. Trong phần này, chúng ta sẽ tiếp tục với những chủ đề còn lại.

Tham khảo: Sử dụng composite models trong Power BI Desktop (Phần 1)

1. Đặt chế độ lưu trữ

Mỗi bảng trong một composite model có một storage mode (chế độ lưu trữ) để cho biết bảng dựa trên DirectQuery hay nhập. Chế độ lưu trữ có thể được xem và chỉnh sửa trong thanh Property. Để hiển thị chế độ lưu trữ, nhấp chuột phải vào một bảng trong danh sách Fields và sau đó chọn Properties. Dưới đây là ảnh hiển thị chế độ lưu trữ cho bảng SalesTargets.

Chế độ lưu trữ có thể xem trên tooltip của mỗi bảng:

Đối với bất kỳ tệp Power BI Desktop (.pbix) nào chứa nhiều bảng từ DirectQuery và các bảng nhập, thanh trạng thái hiển thị chế độ lưu trữ là Mixed. Bạn có thể nhấn vào cụm từ đó trên thanh trạng thái để chuyển tất cả các bảng thành nhập.

Lưu ý: Bạn có thể dùng chế độ lưu trữ Mix cho cả Power BI Desktop và Power BI service.

2. Calculated tables

Bạn có thể thêm các calculated tables vào một model sử dụng DirectQuery. DAX (Data Analysis Expressions) xác định calculated table có thể tham chiếu đến bảng được nhập hoặc bảng DirectQuery hoặc kết hợp của cả hai.

Calculated tables luôn được nhúng và dữ liệu của chúng được tự động làm mới khi bạn làm mới các bảng. Nếu 1 calculated tables tham chiếu đến một DirectQuery, các trực quan tham chiếu đến bảng DirectQuery luôn hiển thị các giá trị mới nhất trong nguồn cơ bản. Ngoài ra, các trực quan tham chiếu đến calculated table sẽ hiển thị các giá trị tại thời điểm calculated table được làm mới.

3. Security implications

Các Composite models có một vài hàm bảo mật. Một truy vấn được gửi đến một nguồn dữ liệu có thể bao gồm các giá trị dữ liệu đã được truy xuất từ một nguồn khác. Trong ví dụ trước đó, trực quan hiển thị số tiền bán hàng (Sales Amount) do Product Manager gửi một truy vấn SQL đến cơ sở dữ liệu quan hệ Sales. Truy vấn SQL đó có thể chứa tên của Product Managers và các sản phẩm (Products) liên quan đến họ.

Do đó, thông tin được lưu trữ trong spreadsheet được đưa vào một truy vấn được gửi đến cơ sở dữ liệu quan hệ. Nếu thông tin này là bảo mật, bạn nên xem xét các tác động bảo mật ở một số điểm sau:

• Bất kỳ quản trị viên cơ sở dữ liệu nào có thể xem dấu vết hoặc nhật ký kiểm tra (audit logs) đều có thể xem thông tin này, ngay cả khi không có quyền đối với dữ liệu trong nguồn ban đầu của nó. Trong ví dụ này, quản trị viên sẽ cần quyền đối với tẹp Excel.
• Cài đặt mã hóa cho mỗi nguồn cần được xem xét. Bạn muốn tránh truy xuất thông tin từ một nguồn bằng kết nối được mã hóa và sau đó vô tình thêm nó vào một truy vấn được gửi đến một nguồn khác bằng một kết nối không được mã hóa.

Để cho phép xác nhận rằng bạn đã xem xét bất kỳ tác động bảo mật nào, Power BI Desktop hiển thị thông bao cảnh báo khi bạn tạo mô hình tổng hợp.

Vì những lý do tương tự, hãy cẩn thận khi mở tệp Power BI Desktop được gửi từ nguồn không đáng tin cậy. Nếu tệp chứa Composite models, thông tin mà ai đó truy xuất từ một nguồn bằng cách sử dụng thông tin đăng nhập của người dùng mở tệp sẽ được gửi đến nguồn dữ liệu khác như một phần của truy vấn. Thông tin có thể được xem bởi tác giả “độc hại” của tệp Power BI Desktop. Khi bạn lần đầu mở tệp Power BI Desktop chứa nhiều nguồn, Power BI Desktop sẽ hiển thị cảnh báo, tương tự như khi bạn mở tệp chứa các truy vấn SQL gốc.

4. Ý nghĩa về hiệu suất

Khi bạn dùng DirectQuery, hãy xem xét hiệu suất để đảm bảo nguồn back-end đủ tài nguyên cung cấp trải nghiệm tốt cho người dùng. Một trải nghiệm tốt có nghĩa là hình ảnh làm mới sau 5 giây hoặc ít hơn.

Việc sử dụng composite models sẽ bổ sung thêm các cân nhắc về hiệu suất. Một hình ảnh trực quan có thể dẫn đến việc gửi các truy vấn đến nhiều nguồn, thường chuyển kết quả từ một truy vấn sang nguồn thứ hai. Các hình thức thực hiện có thể được dẫn đến:

• Một truy vấn SQL bao gồm số lượng lón các giá trị: Ví dụ, trực quan yêu cầu tổng số tiền bán hàng (total Sale Amount) cho một nhóm Product Managers được chọn. Trước tiên sẽ cần tìm sản phẩm (Products) nào được quản lý bởi những managers đó. Trình từ này phải xảy ra trước khi trực quan gửi một truy vấn SQL bao gồm tất cả các ID sản phẩm trong mệnh đề WHERE.
• Một truy vấn SQL ở mức độ chi tiết thấp hơn, với dữ liệu sau đó được tổng hợp cục bộ: Khi số lượng sản phẩm (Product) đáp úng tiêu chí bộ lọc trên Product Manager ngày càng lớn, việc đưa tất cả vào mệnh đề WHERE có thể trở nên kém hiệu quả hoặc không khả thi. Thay vào đó, bạn có thể truy vấn nguồn quan hệ ở cấp sản phẩm thấp hơn và sau đó tổng hợp kết quả cục bộ. Nếu số lượng sản phẩm vượt quá 1 triệu, truy vấn không thành công.
• Nhiều truy vấn SQL, mỗi truy vấn trên một nhóm theo giá trị: Khi tập hợp sử dụng DistinctCount và được nhóm theo cột từ một nguồn khác và nếu nguồn bên ngoài không hỗ trợ truyền hiệu quả nhiều giá trị theo nghĩa đen xác định nhóm, cần phải gửi một truy vấn SQL cho mỗi nhóm theo giá trị.

Hình ảnh trực quan yêu cầu số lượng CustomerAccountNumber riêng biệt từ bảng SQL Server theo Product Managers được nhập từ spreadsheet sẽ cần phải chuyển chi tiết từ bảng Product Managers trong truy vấn được gửi đến SQL Server. Ví dụ, trên các nguồn khác, Redshift, hành động này là không khả thi. Thay vào đó, sẽ có một truy vấn SQL được gửi cho mỗi Sales Manager, lên đến một số giới hạn thực tế, tại thời điểm đó truy vấn sẽ không thành công

Mỗi trường hợp này có ý nghĩa riêng về hiệu suất và các chi tiết chính xác khác nhau đối với từng nguồn dữ liệu. Mặc dù, số lượng cột được sử dụng trong mối quan hệ kết hợp hai nguồn vẫn thấp, một vài nghìn, hiệu suất sẽ không bị ảnh hưởng. Khi bản số này phát triển, bạn nên chú ý nhiều hơn đến tác động đến hiệu suất kết quả.

Ngoài ra, việc sử dụng mối quan hệ many-to-many có nghĩa là các truy vấn riêng biệt phải được gửi đến nguồn cơ bản cho mỗi cấp tổng hoặc tổng, thay vì tổng hợp các giá trị chi tiết cục bộ. Một hình ảnh bảng đơn giản với các tổng sẽ gửi hai truy vấn SQL thay vì một.

5. Giới hạn và cân nhắc

Việc phát hành composite models này có một số hạn chế:

Hiện nay, tính năng làm mới gia tăng chỉ được hỗ trợ cho các mô hình tổng hợp kết nối các nguồn dữ liệu SQL, Oracle và Teradata.

Không thể sử dụng các nguồn đa chiều Live-Connect sau đây với các composite models:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services
• Power BI datasets
• Azure Analysis Services

Khi bạn kết nối đến các nguồn đa chiều này bằng cách dùng DirectQuery, bạn không thể kết nối đến các nguồn DirectQuery khác hoặc kết hợp nó với dữ liệu nhập.

Các hạn chế hiện có của DirectQuery vẫn áp dụng khi bạn sử dụng composite models. Nhiều hạn chế trong số này là trên mỗi bảng, tùy thuộc vào chế độ lưu trữ của bảng. Ví dụ, cột được tính toán trên bảng nhập có thể tham chiếu đến các bảng khác nhưng cột được tính trên bảng DirectQuery vẫn có thể chỉ tham chiếu đến các cột trên cùng một bảng. Các giới hạn khác áp dụng cho toàn bộ mô hình, nếu bất kỳ bảng nào trong mô hình là DirectQuery. Ví dụ, các tính năng QuickInsights và Q&A không có sẵn trên một mô hình nếu bất kỳ bảng nào trong đó có chế độ lưu trữ DirectQuery.

Như vậy là chúng ta đã kết thúc bài viết về cách sử dụng composite models trong Power BI Desktop. Mong rằng những thông tin được BAC chia sẻ trên đây sẽ hữu ích với bạn đọc. Ngoài ra, hiện nay các bạn có thể tham gia khóa học Power BI tại BAC để được trang bị 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.