Microsoft vừa phát hành chính thức (GA) một stored procedure tích hợp mới cho SQL analytics endpoint trong Microsoft Fabric mang tên sp_get_table_health_metrics. Tính năng này cung cấp cho các kỹ sư dữ liệu một phương pháp gốc T-SQL để kiểm tra “sức khỏe” cấu trúc của các bảng trong Lakehouse. Qua đó, doanh nghiệp có thể đưa ra quyết định bảo trì sáng suốt, tránh lãng phí tài nguyên và đảm bảo hiệu năng truy vấn trước khi người dùng cuối bị ảnh hưởng.
Thách thức: Bảo trì “mù quáng” và xử lý sự cố thụ động
Khi sử dụng các bảng Lakehouse thông qua SQL analytics endpoint, nhiều doanh nghiệp nhận thấy các truy vấn dần chậm lại theo thời gian. Các dashboard bị trễ và người dùng báo cáo hiệu năng giảm sút dù dữ liệu logic không thay đổi. Nguyên nhân gốc rễ thường nằm ở tầng vật lý: các file Parquet theo thời gian bị phân mảnh thành bố cục không tối ưu, ảnh hưởng đến hiệu năng truy vấn.
Cho đến nay, việc chẩn đoán vấn đề này đòi hỏi phải thoát hoàn toàn khỏi môi trường T-SQL. Các kỹ sư phải mở Spark notebook, kiểm tra Delta log, xem xét kích thước file thủ công, hoặc nhờ đến sự hỗ trợ của Microsoft. Điều này gây gián đoạn luồng công việc và tốn nhiều giờ cho một tác vụ chẩn đoán lẽ ra phải rất nhanh.
Khi không có công cụ chẩn đoán, nhiều đội ngũ chọn giải pháp chạy lệnh OPTIMIZE (một hoạt động của Spark giúp nén các file nhỏ và cải thiện bố cục dữ liệu) theo một lịch trình cố định, bất kể bảng có thực sự cần hay không. Cách làm này gây lãng phí tài nguyên tính toán và các capacity unit cho những bảng đang ở trạng thái tốt, trong khi các bảng thực sự cần chú ý lại có thể bị bỏ sót.
Giải pháp: Chẩn đoán sức khỏe trước, quyết định sau
sp_get_table_health_metrics cung cấp một phương pháp đơn giản, ngay trong T-SQL, để đánh giá tình trạng của bảng trước khi hành động. Chỉ với một lệnh duy nhất, người dùng có được cái nhìn toàn diện về sức khỏe lưu trữ của bảng. Stored procedure này trả về các chỉ số bất thường và các số liệu lưu trữ quan trọng giúp xác định rủi ro về hiệu năng.
Thủ tục này trả về các thông tin chính:
- Phát hiện bất thường: Các cột
PotentialAnomalyTypevàPotentialAnomalyDescriptioncho biết liệu có vấn đề gì cần chú ý hay không, ví dụ như ‘Quá nhiều file nhỏ’, ‘Quá nhiều dòng đã xóa’, ‘Không có checkpoint gần đây’, hoặc ‘None’ nếu không có bất thường nào. - Phiên bản Snapshot và Checkpoint: Giúp xác định xem việc tạo checkpoint có cần thiết hay không.
- Số dòng vật lý và số dòng đã xóa: Cung cấp cái nhìn về số lượng file đang được lưu trữ vật lý trong bảng.
- Phân bổ kích thước file: Cho thấy bảng có đang gặp vấn đề file nhỏ hay không.
- Phân bổ số lượng dòng: Tiết lộ sự phân mảnh của file và phân phối dữ liệu không đồng đều.
- Phân bổ dòng đã xóa: Cho biết bảng đang “gánh” bao nhiêu dữ liệu thừa.
Đây chính là bước chẩn đoán còn thiếu trong quy trình bảo trì. Giờ đây, thay vì chạy OPTIMIZE một cách mù quáng, doanh nghiệp có thể kiểm tra sức khỏe của bảng trước và quyết định xem việc tối ưu hóa có thực sự cần thiết hay không.
Tích hợp vào pipeline dữ liệu của bạn
Sức mạnh thực sự của sp_get_table_health_metrics là khả năng tích hợp một cách tự nhiên vào các pipeline dữ liệu hiện có. Vì sử dụng T-SQL tiêu chuẩn, bạn có thể gọi nó từ Fabric pipelines, Azure Data Factory, dbt, hoặc bất kỳ công cụ điều phối nào dựa trên SQL.
Doanh nghiệp có thể chạy sp_get_table_health_metrics như một phần của pipeline ETL hoặc ELT. Nếu phát hiện có bất thường, pipeline sẽ chạy OPTIMIZE; ngược lại, nó sẽ bỏ qua bước bảo trì và tiết kiệm capacity unit. Điều này có thể được dàn dựng dễ dàng trong một Pipeline đơn giản trên Fabric chỉ với hai hoạt động.
Khi pipeline chạy, điều kiện “if” sẽ đánh giá kết quả từ stored procedure. Nếu một bất thường được phát hiện, nó sẽ kích hoạt một notebook để tối ưu hóa bảng.
Mô hình “kiểm tra rồi hành động” (check-then-act) này đảm bảo rằng bạn chỉ thực hiện bảo trì khi thực sự cần thiết. Theo thời gian, điều này giúp giảm chi tiêu cho tài nguyên tính toán trong khi vẫn giữ hiệu năng truy vấn ở mức cao và ổn định.
Ý nghĩa đối với người dùng SQL analytics endpoint
SQL analytics endpoint là một điểm cuối chỉ đọc (read-only) và không thể trực tiếp thực hiện các tác vụ bảo trì. Việc tối ưu hóa phải được thực hiện thông qua Spark hoặc Lakehouse engine. Tuy nhiên, SQL engine lại có cái nhìn đầy đủ về các đặc điểm hiệu năng truy vấn. Thủ tục này giúp hiển thị thông tin chi tiết đó, giúp bạn xác định khi nào cần bảo trì và hành động nên được thực hiện ở đâu.
sp_get_table_health_metrics đưa kiến thức đó đến với người dùng bằng ngôn ngữ họ đã quen thuộc: T-SQL. Nó thu hẹp khoảng cách giữa nơi vấn đề có thể nhìn thấy (SQL engine) và nơi thực hiện việc sửa lỗi (Spark). Điều này đặc biệt quan trọng đối với các mô hình nơi dữ liệu được nạp và chuẩn bị trong Lakehouse, nhưng được phục vụ thông qua SQL analytics endpoint.
Bắt đầu ngay hôm nay
Tính năng sp_get_table_health_metrics hiện đã khả dụng cho mọi bảng Lakehouse có thể truy cập thông qua SQL analytics endpoint của bạn. Việc bảo trì hiệu quả bắt đầu từ chẩn đoán chính xác. Bằng cách nắm rõ tình trạng các bảng và chỉ tối ưu hóa khi cần, doanh nghiệp có thể giữ cho các truy vấn luôn nhanh chóng và sử dụng tài nguyên một cách hiệu quả.
Để tìm hiểu cách tích hợp vào pipeline, hãy tham khảo hướng dẫn Tối ưu hóa bảng Lakehouse dựa trên kiểm tra sức khỏe và tài liệu tham khảo cú pháp tại sys.sp_get_table_health_metrics (Transact-SQL).
