Chọn chế độ kết nối Power BI: Import, DirectQuery hay Direct Lake?

Chọn chế độ kết nối Power BI không đơn thuần là chọn “nhanh” hay “real-time”. Đó là quyết định kiến trúc ảnh hưởng đến hiệu suất, chi phí, bảo mật, refresh và khả năng vận hành lâu dài.

Trong phần lớn dự án, Import vẫn là điểm bắt đầu hợp lý. DirectQuery, composite model, hybrid table và Direct Lake chỉ nên được chọn khi bài toán thực sự cần.

Trước hết: kết nối dữ liệu và storage mode không hoàn toàn giống nhau

Power BI có nhiều connector để truy cập SQL Server, SAP, Excel, API, data warehouse hoặc lakehouse. Connector trả lời câu hỏi “Power BI kết nối đến nguồn nào?”. Storage mode trả lời câu hỏi khác: “Dữ liệu của từng bảng được lưu và truy vấn như thế nào?”.

Trong Power BI Desktop và Power BI Service, ba nhóm semantic model phổ biến là Import, DirectQuery và Composite. Ngoài ra còn có live connection đến một semantic model hoặc Analysis Services đã tồn tại, hybrid table và Direct Lake trong Microsoft Fabric.

Việc gọi tất cả là “chế độ kết nối” giúp trao đổi nhanh, nhưng khi thiết kế hệ thống cần phân biệt rõ để tránh chọn sai công nghệ.

Import mode — lựa chọn mặc định cho phần lớn báo cáo

Với Import mode, dữ liệu được nạp vào semantic model, nén và tối ưu bởi VertiPaq. Khi người dùng mở báo cáo, phần lớn truy vấn được xử lý trong bộ nhớ thay vì gửi lại về hệ thống nguồn.

Ưu điểm chính:

• Hiệu suất tương tác tốt khi mô hình và measure được thiết kế đúng.
• Hỗ trợ đầy đủ hơn cho Power Query, DAX, calculated table và calculated column.
• Giảm tải truy vấn trực tiếp lên ERP hoặc database vận hành.
• Có thể tích hợp dữ liệu từ nhiều loại nguồn vào cùng một semantic model.

Đổi lại: dữ liệu chỉ mới đến thời điểm refresh gần nhất; refresh tiêu thụ tài nguyên; kích thước model và bộ nhớ capacity phải được quản lý.

Import phù hợp với báo cáo doanh thu, tồn kho, tài chính và ngân sách khi độ trễ vài phút, vài giờ hoặc một ngày vẫn đáp ứng nhu cầu quản trị. Với dữ liệu lớn, hãy tối ưu từ mô hình ngôi sao, loại bỏ cột không dùng, giảm cardinality và cân nhắc incremental refresh trước khi vội chuyển sang DirectQuery.

DirectQuery — dữ liệu gần nguồn hơn, nhưng không mặc nhiên nhanh hơn

DirectQuery không nhập dữ liệu nghiệp vụ vào semantic model theo cách của Import. Khi người dùng tương tác với visual, Power BI tạo truy vấn gửi về nguồn dữ liệu và xử lý kết quả trả về.

DirectQuery thường được cân nhắc khi:

• Khối lượng dữ liệu quá lớn để nhập hoặc refresh trong thời gian chấp nhận được.
• Báo cáo cần dữ liệu gần thời gian thực hơn giới hạn refresh thông thường.
• Chính sách quản trị yêu cầu dữ liệu phải nằm tại hệ thống nguồn.

Nhưng DirectQuery chuyển áp lực sang database, gateway và mạng. Mỗi slicer hoặc visual có thể tạo một hay nhiều truy vấn. Khi nhiều người cùng sử dụng, một thiết kế thiếu kiểm soát dễ làm chậm cả báo cáo lẫn hệ thống nguồn.

DirectQuery cũng có giới hạn về transformation và DAX vì nhiều biểu thức phải chuyển được thành truy vấn mà nguồn dữ liệu hiểu. Cache của visual, tile hoặc kết quả còn có thể khiến chữ “real-time” bị hiểu quá mức: người dùng đôi khi vẫn cần refresh để lấy trạng thái mới nhất.

Nguyên tắc thực tế: Không chọn DirectQuery chỉ vì dữ liệu “lớn”. Trước hết hãy đo kích thước model sau nén, thời gian refresh, concurrency, độ trễ cần thiết và năng lực của hệ thống nguồn.

Live connection — báo cáo dùng lại semantic model trung tâm

Live connection thường xuất hiện khi Power BI report kết nối đến một semantic model đã được công bố hoặc một mô hình Analysis Services. Report tái sử dụng tables, relationships, measures, RLS và business logic do đội dữ liệu trung tâm quản lý.

Cách làm này phù hợp với mô hình self-service BI có quản trị: một semantic model “single source of truth” phục vụ nhiều báo cáo. Người dùng không cần lặp lại định nghĩa doanh thu, giá vốn hoặc tồn kho khả dụng trong từng file PBIX.

Tuy nhiên, live connection không đồng nghĩa nguồn dữ liệu gốc luôn được truy vấn trực tiếp. Semantic model trung tâm có thể dùng Import, DirectQuery, Direct Lake hoặc cấu hình kết hợp. Tốc độ và độ mới của dữ liệu phụ thuộc vào model đó.

Trong một số trường hợp, người thiết kế report có thể tạo local model và kết nối DirectQuery đến semantic model hiện có để bổ sung bảng hoặc logic cục bộ. Khi đó giải pháp đã chuyển sang composite model và cần được quản trị cẩn thận.

Composite model và Dual mode — linh hoạt ở cấp độ bảng

Composite model cho phép một semantic model có các bảng dùng storage mode khác nhau, chẳng hạn fact table lớn ở DirectQuery trong khi dimension được Import hoặc đặt ở Dual mode.

Dual mode cho phép Power BI quyết định dùng dữ liệu trong bộ nhớ hoặc đi theo nhánh DirectQuery tùy truy vấn. Cấu hình phổ biến là:

• Fact giao dịch lớn: DirectQuery.
• Dimension như Date, Product, Customer: Dual.
• Bảng tham số hoặc mapping nhỏ: Import.

Composite model không phải “lấy ưu điểm của mọi mode mà không có nhược điểm”. Relationship giữa các nhóm nguồn, limited relationship, query folding, data privacy và consistency đều cần được kiểm thử. Một visual kết hợp nhiều storage mode có thể phát sinh truy vấn phức tạp và khó tối ưu.

Hybrid table — lịch sử trong bộ nhớ, dữ liệu mới qua DirectQuery

Hybrid table là một fact table có nhiều partition Import và một partition DirectQuery. Dữ liệu lịch sử được truy vấn nhanh từ bộ nhớ, còn phần dữ liệu mới nhất được lấy từ nguồn.

Cách triển khai phổ biến là cấu hình incremental refresh và bật tùy chọn lấy dữ liệu mới nhất bằng DirectQuery. Tính năng này phụ thuộc vào capacity và điều kiện cấp phép phù hợp; không nên mô tả như một chế độ có sẵn cho mọi workspace.

Hybrid table phù hợp với dữ liệu giao dịch theo thời gian: phần lớn lịch sử ít thay đổi, nhưng doanh nghiệp vẫn cần theo dõi các giao dịch vừa phát sinh. Dimension liên quan thường được đặt ở Dual mode để Power BI tạo truy vấn hiệu quả hơn cho partition DirectQuery.

Direct Lake — hướng tiếp cận dành cho Microsoft Fabric

Direct Lake là storage mode của semantic model trong Microsoft Fabric, được tối ưu để phân tích lượng dữ liệu lớn từ các Delta table trong OneLake. Dữ liệu không phải được nhập vào model theo quy trình Import truyền thống và cũng không nhất thiết gửi truy vấn SQL về nguồn cho mỗi tương tác như DirectQuery.

Direct Lake phù hợp khi doanh nghiệp đã xây dựng dữ liệu trên Fabric Lakehouse hoặc Warehouse và có Fabric capacity tương ứng. Đây không phải lựa chọn thay thế trực tiếp cho mọi dự án Power BI đang lấy dữ liệu từ SQL Server, Excel hoặc SAP Business One.

Kiến trúc Direct Lake còn có các điều kiện, giới hạn và hành vi fallback khác nhau giữa Direct Lake on OneLake và Direct Lake on SQL. Vì vậy, cần đối chiếu tài liệu Microsoft theo đúng loại semantic model đang triển khai.

So sánh nhanh các phương án

Một số ví dụ doanh nghiệp thực tế

Báo cáo tài chính và quản trị từ SAP Business One

Nếu số liệu được chốt theo ngày hoặc theo giờ, Import thường hợp lý hơn DirectQuery. Doanh nghiệp có thể đưa dữ liệu qua staging hoặc data warehouse, chuẩn hóa business logic rồi refresh theo lịch. Cách này giảm tải database vận hành và kiểm soát tốt hơn định nghĩa KPI.

Dashboard sản xuất cần theo dõi gần thời gian thực

DirectQuery có thể phù hợp nếu MES hoặc warehouse phục vụ phân tích được tối ưu cho concurrency. Không nên cho hàng chục dashboard truy vấn trực tiếp database giao dịch mà chưa đánh giá index, workload isolation, gateway và số lượng visual.

Tập đoàn có semantic model dùng chung

Các phòng ban có thể xây thin report bằng live connection đến semantic model trung tâm. Measure, RLS và định nghĩa KPI được quản lý một lần. Khi cần bổ sung dữ liệu cục bộ, hãy đánh giá composite model thay vì sao chép toàn bộ model sang một PBIX mới.

Checklist chọn storage mode cho Power BI

• Người dùng chấp nhận dữ liệu trễ bao lâu: một ngày, một giờ hay vài phút?
• Dữ liệu sau khi loại cột và nén bằng VertiPaq còn lớn đến mức nào?
• Refresh hoàn tất trong bao lâu và có ảnh hưởng hệ thống nguồn không?
• Có bao nhiêu người dùng đồng thời và mỗi trang có bao nhiêu visual?
• Nguồn DirectQuery có được tối ưu cho workload phân tích không?
• Gateway, network và credential được vận hành bởi ai?
• Model có cần calculated table, transformation phức tạp hoặc DAX khó chuyển thành native query không?
• Giải pháp có phụ thuộc Premium/Fabric capacity hoặc tính năng cấp phép cụ thể không?
• RLS và quyền truy cập dữ liệu được thực thi ở lớp nào?

Nếu chưa trả lời được các câu hỏi này, quyết định storage mode vẫn đang dựa trên cảm giác thay vì kiến trúc.

Kết: Bắt đầu từ yêu cầu vận hành, không bắt đầu từ tên công nghệ

Import, DirectQuery, live connection, composite model, hybrid table và Direct Lake đều giải quyết những lớp bài toán khác nhau. Không có mode tốt nhất cho mọi doanh nghiệp.

Với đa số báo cáo quản trị, hãy bắt đầu bằng Import và một semantic model được thiết kế đúng. Chỉ chuyển sang DirectQuery hoặc mô hình lai khi có yêu cầu rõ về khối lượng, độ trễ hoặc quản trị dữ liệu — và sau khi đã đo hiệu suất thực tế.

Một dashboard nhanh không đến từ việc chọn đúng một nút trong Power BI. Nó đến từ cả chuỗi kiến trúc: hệ thống nguồn, ETL/ELT, mô hình dữ liệu, DAX, capacity, gateway và cách người dùng tương tác với báo cáo.

Tài liệu Microsoft tham khảo

• Semantic model modes in the Power BI service.
• Use composite models in Power BI Desktop.
• Direct Lake overview in Microsoft Fabric.