Đã đăng vào khoảng 4 giờ trước 7 phút đọc

Greenplum Database Bài học 12: Data Skew (Lệch dữ liệu): Cách phát hiện các Segment bị quá tải và kỹ thuật xử lý triệt để

Qua các bài học trước, chúng ta đã biết sức mạnh của kiến trúc MPP đến từ việc chia nhỏ dữ liệu và tính toán song song trên hàng chục Segment. Tuy nhiên, sức mạnh đó đi kèm với một quy luật khắc nghiệt nhất trong thế giới tính toán phân tán:

"Tốc độ của toàn bộ câu truy vấn trên cụm Greenplum luôn bằng tốc độ của Segment chạy CHẬM NHẤT."

Hiện tượng một hoặc một vài Segment ôm đồm quá nhiều dữ liệu hoặc gánh chịu khối lượng tính toán khổng lồ trong khi các Segment khác rảnh rỗi được gọi là Data Skew (Lệch dữ liệu) — hay còn được ví như "căn bệnh ung thư" làm tê liệt mọi hệ thống Data Warehouse. Trong bài học này, chúng ta sẽ cùng mổ xẻ nguyên nhân, cách phát hiện chính xác và các kỹ thuật xử lý triệt để căn bệnh này.

1. Hai dạng Data Skew phổ biến trong Greenplum

Khi nói đến Data Skew, các DBA thường chia thành hai loại chính:

┌────────────────────────────────────────────────────────────────────────┐
│                        HAI DẠNG DATA SKEW PHỐ BIẾN                       │
└───────────────────────────┬────────────────────────┬───────────────────┘
                            │                        │
               1. STORAGE SKEW (Lệch lưu trữ)    2. COMPUTATIONAL SKEW (Lệch tính toán)
               • Dữ liệu trên đĩa bị dồn cục     • Dữ liệu rải đều nhưng câu truy vấn
                 vào một vài Segment.              gom nhóm (GROUP BY) vào các giá trị hot.

1.1. Storage Skew (Lệch dữ liệu lưu trữ)

Biểu hiện: Dung lượng ổ cứng và số lượng dòng dữ liệu trên Segment 0 là 50 GB, trong khi Segment 1 chỉ có 2 GB.
Nguyên nhân: Chọn sai khóa phân phối (DISTRIBUTED BY).
- Ví dụ thực tế: Bạn tạo bảng users và chọn cột country_code làm khóa phân phối. Nếu 95% khách hàng của bạn đến từ Việt Nam (VN), toàn bộ dữ liệu của khách hàng Việt Nam sẽ bị băm và dồn sạch vào cùng một Segment, khiến các Segment khác trống trơn.

1.2. Computational Skew (Lệch tải tính toán)

Biểu hiện: Dữ liệu trên các Segment rất đều nhau, nhưng khi bạn chạy câu lệnh SELECT status, COUNT(*) FROM orders GROUP BY status, câu truy vấn chạy mãi không xong.
Nguyên nhân: Giá trị của cột mang tính chất "tập trung" (Ví dụ: 99% đơn hàng có trạng thái completed, chỉ có 1% đơn hàng nằm ở các trạng thái khác). Khi thực hiện GROUP BY status, tiến trình trên Segment chứa dữ liệu completed phải gánh 99% khối lượng tính toán của toàn hệ thống.

2. Cách phát hiện Data Skew trên hệ thống Production

Đừng đợi đến khi hệ thống sập mới đi tìm nguyên nhân. Hãy sử dụng các câu lệnh SQL kiểm tra định kỳ sau đây:

2.1. Kiểm tra sự chênh lệch số dòng trên từng Segment

Bạn có thể viết một đoạn truy vấn nhanh để xem bảng của mình có đang bị lệch dữ liệu hay không:

SQL

SELECT 
    gp_segment_id, 
    COUNT(*) AS so_dong,
    ROUND(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM fact_transactions), 2) AS ty_le_phan_tram
FROM fact_transactions
GROUP BY gp_segment_id
ORDER BY gp_segment_id;

Dấu hiệu cảnh báo: Nếu tổng số dòng phân bổ đều (Ví dụ cụm có 4 Segment mà mỗi bên chiếm ~25%), bảng của bạn hoàn toàn khỏe mạnh. Nhưng nếu có một Segment chiếm tới 70-80% tổng số dòng, bạn đang đối mặt với Storage Skew nặng nề.

2.2. Sử dụng hệ thống View `gp_toolkit` chuyên dụng

Greenplum tích hợp sẵn một Schema tên là gp_toolkit chứa rất nhiều công cụ chẩn đoán lỗi tuyệt vời. Để kiểm tra toàn bộ các bảng đang bị lệch dữ liệu trong cơ sở dữ liệu, hãy dùng view gp_skew_coefficient:

SQL

SELECT * FROM gp_toolkit.gp_skew_coefficient 
WHERE skcskew > 0.5  -- Ngưỡng cảnh báo độ lệch > 50%
ORDER BY skcskew DESC;

3. Kỹ thuật xử lý và phòng ngừa Data Skew triệt để

Khi phát hiện bảng bị Data Skew, bạn có thể áp dụng các giải pháp kỹ thuật sau từ gốc rễ:

3.1. Thay đổi cột Distribution Key (Giải pháp tối ưu nhất)

Nếu bảng bị lệch do chọn nhầm cột có độ phân tán thấp (như status, gender, province_id), hãy thực hiện lệnh ALTER TABLE để đổi sang cột có tính duy nhất cao hơn như user_id, order_id hoặc tạo cột tổng hợp (Composite Distribution Key):

SQL

-- Chuyển đổi khóa phân phối sang cột có độ phân tán cao hơn
ALTER TABLE fact_transactions SET DISTRIBUTED BY (transaction_id);

3.2. Sử dụng Composite Key (Khóa phân phối kết hợp)

Trong một số trường hợp, nghiệp vụ buộc bạn phải phân phối theo store_id (mã cửa hàng), nhưng công ty lại có một cửa hàng tổng lớn chiếm tới 50% doanh thu cả nước (dẫn đến lệch dữ liệu).

Giải pháp: Kết hợp store_id với một cột có độ phân tán cao hơn như transaction_id hoặc created_date để làm khóa phân phối kép, giúp xé nhỏ cụm dữ liệu của cửa hàng lớn ra nhiều Segment khác nhau.

3.3. Lọc bỏ các giá trị "Null" hoặc giá trị rác trước khi phân phối

Các giá trị NULL hoặc giá trị mặc định (như N/A, 0, Unknown) thường chiếm tỷ trọng lớn và bị băm chung vào một Segment. Nếu các giá trị này không quan trọng trong các phép JOIN, hãy làm sạch dữ liệu hoặc chuyển chúng thành các giá trị phân tán ngẫu nhiên trước khi đưa vào bảng chính.

Tóm tắt Bài học 12

Data Skew là hiện tượng lệch dữ liệu (Storage Skew) hoặc lệch tải tính toán (Computational Skew), làm chậm toàn bộ hệ thống vì quy tắc "chạy chậm nhất".
Phải luôn theo dõi sức khỏe bảng bằng cách kiểm tra cột ẩn gp_segment_id hoặc sử dụng schema gp_toolkit.gp_skew_coefficient.
Cách xử lý triệt để là chọn lại Distribution Key có độ phân tán cao (High Cardinality), dùng Composite Key hoặc làm sạch các giá trị tập trung (NULL, giá trị mặc định).

Ở bài học tiếp theo (Bài học 13), chúng ta sẽ bước sang một khía cạnh phần cứng và lưu trữ cực kỳ quan trọng: Heap Tables vs Append-Optimized (AO) Tables — Chọn mô hình lưu trữ nào cho OLTP hay OLAP?.

Bạn có muốn thử viết một câu lệnh kiểm tra độ lệch dữ liệu trên các bảng hiện tại của mình bằng gp_toolkit không?

cấu hình database