Greenplum Database - Bài học 2: Giải phẫu kiến trúc MPP (Massively Parallel Processing): Cách Greenplum chia để trị hàng tỷ bản ghi

Ở Bài học 1, chúng ta đã biết một máy chủ PostgreSQL đơn lẻ dù mạnh đến đâu cũng sẽ gục ngã trước bức tường băng thông ổ cứng (Disk I/O) khi phải quét hàng chục Terabyte dữ liệu. Để vượt qua giới hạn vật lý đó, Greenplum sử dụng kiến trúc MPP (Massively Parallel Processing — Xử lý song song quy mô lớn).

Vậy bên dưới nắp capo, kiến trúc MPP thực sự hoạt động như thế nào? Nó khác gì so với các kiến trúc phân tán khác, và một câu lệnh SQL bình thường sẽ được "băm nhỏ" để chạy trên hàng chục máy chủ ra sao? Hãy cùng mổ xẻ chi tiết trong bài học này.

1. Ba mô hình kiến trúc xử lý dữ liệu đa máy chủ

Khi một máy chủ không còn đủ sức gánh vác công việc, ngành khoa học máy tính có 3 hướng tiếp cận chính để ghép nhiều máy chủ (hoặc nhiều bộ vi xử lý) lại với nhau:

1. SHARED-MEMORY (SMP)          2. SHARED-DISK                  3. SHARED-NOTHING (MPP)
┌─────┐ ┌─────┐ ┌─────┐         ┌──────┐ ┌──────┐ ┌──────┐      ┌──────┐ ┌──────┐ ┌──────┐
│CPU 1│ │CPU 2│ │CPU 3│         │Node 1│ │Node 2│ │Node 3│      │Node 1│ │Node 2│ │Node 3│
└──┬──┘ └──┬──┘ └──┬──┘         │CPU/RM│ │CPU/RM│ │CPU/RM│      │CPU/RM│ │CPU/RM│ │CPU/RM│
   └───────┼───────┘            └──┬───┘ └──┬───┘ └──┬───┘      ├──────┤ ├──────┤ ├──────┤
           ▼                       └────────┼────────┘          │Disk 1│ │Disk 2│ │Disk 3│
    ┌─────────────┐                         ▼                   └──┬───┘ └──┬───┘ └──┬───┘
    │ Shared RAM  │              ┌─────────────────────┐           └────────┼────────┘
    ├─────────────┤              │  Shared Storage SAN │                    ▼
    │ Shared Disk │              └─────────────────────┘        [ High-Speed Interconnect ]
    └─────────────┘

Tại sao Greenplum chọn kiến trúc Shared-Nothing (MPP)? Bởi vì không có điểm nghẽn dùng chung (No Contention). Khi bạn tăng gấp đôi số lượng máy chủ từ 10 Node lên 20 Node, bạn tăng gấp đôi số lượng CPU, gấp đôi dung lượng RAM, và quan trọng nhất là tăng gấp đôi tổng băng thông đọc/ghi ổ cứng (Disk I/O). Hiệu năng của cụm Greenplum tăng trưởng gần như tuyến tính (Linear Scalability) theo số lượng máy chủ bạn lắp thêm.

2. Giải phẫu bên trong một cụm Greenplum MPP

Một cụm (Cluster) Greenplum chuẩn bao gồm 3 thành phần cốt lõi phối hợp chặt chẽ với nhau theo mô hình "Chỉ huy và Quân đoàn":

2.1. Master Host (Coordinator) — "Tổng tư lệnh"

• Là cửa ngõ duy nhất (Single Entry Point) mà ứng dụng Backend, công cụ BI (Tableau, PowerBI, Metabase) hay DBA kết nối vào thông qua cổng chuẩn PostgreSQL (thường là 5432).

• Điểm đặc biệt: Master KHÔNG lưu trữ bất kỳ một dòng dữ liệu người dùng (User Data) nào.

• Nhiệm vụ của Master:

  • Xác thực kết nối (Authentication) và kiểm tra quyền hạn.

  • Lưu trữ System Catalog (Metadata): Thông tin về cấu trúc bảng, tên cột, phân quyền, và bản đồ vị trí các Segment.

  • Phân tích câu lệnh SQL, sử dụng bộ tối ưu hóa GPORCA để lập Kế hoạch thực thi phân tán (Distributed Query Plan).

  • Gửi lệnh xuống các máy con (Segments), điều phối quá trình chạy và tổng hợp kết quả cuối cùng trả về cho Client.

2.2. Segment Hosts & Segment Instances — "Đội quân công nhân"

Đây là nơi lưu trữ dữ liệu thực tế và gánh vác 99% sức nặng tính toán (CPU/RAM/Disk I/O).

• Segment Host: Là một máy chủ vật lý (hoặc máy ảo).

• Segment Instance (gọi tắt là Segment): Là một tiến trình cơ sở dữ liệu PostgreSQL độc lập chạy trên Segment Host, có thư mục lưu trữ dữ liệu (PGDATA) và cổng lắng nghe (port) riêng.

• Tại sao một máy chủ vật lý lại chạy nhiều Segment? Một máy chủ hiện đại thường có rất nhiều nhân CPU (ví dụ: 64 Cores, 256GB RAM, 8 ổ NVMe). Vì một tiến trình PostgreSQL đơn lẻ khi xử lý một phần câu truy vấn thường chưa tận dụng hết toàn bộ 64 Cores và băng thông của 8 ổ đĩa, người ta thường cấu hình từ 4 đến 8 Primary Segments trên mỗi máy chủ vật lý. Nhờ đó, toàn bộ phần cứng của máy chủ được vắt kiệt công suất song song.

2.3. Interconnect — "Hệ thần kinh tốc độ cao"

• Là tầng mạng nội bộ (thường sử dụng chuẩn 10GbE, 25GbE hoặc 100GbE) kết nối Master với các Segments và kết nối các Segments với nhau.

• Mặc định, Greenplum không dùng TCP truyền thống (vốn tốn tài nguyên quản lý kết nối khi có hàng ngàn luồng) mà sử dụng giao thức UDPIFC (UDP có kiểm soát luồng và sửa lỗi riêng ở tầng Application). Điều này giúp việc bắn hàng triệu bản ghi qua lại giữa các máy chủ khi thực hiện phép JOIN diễn ra với tốc độ cực cao và độ trễ thấp nhất.

3. Cách Greenplum "Chia để trị" (Divide and Conquer) hàng tỷ bản ghi

Sự kỳ diệu của MPP nằm ở hai giai đoạn: Chia dữ liệu lúc ghi (Data Distribution) và Chia việc lúc đọc (Parallel Query Execution).

Giai đoạn 1: Chia nhỏ dữ liệu (Data Sharding / Distribution)

Khi bạn tạo một bảng transactions có 1 tỷ bản ghi trên cụm Greenplum gồm 100 Segments:

• Người dùng nhìn vào Master vẫn chỉ thấy một bảng transactions duy nhất.

• Nhưng ở bên dưới, dựa vào khóa phân phối (Distribution Key — ví dụ user_id hoặc transaction_id), Greenplum băm (Hash) từng dòng dữ liệu và rải đều chúng xuống 100 Segments.

• Kết quả: Mỗi Segment chỉ phải lưu trữ và quản lý đúng 10 triệu bản ghi (1/100 tổng dung lượng).

Giai đoạn 2: Hành trình thực thi một câu lệnh SQL song song

Giả sử bạn chạy câu truy vấn thống kê tổng doanh thu theo từng cửa hàng trong năm 2026 trên bảng 1 tỷ dòng đó:

SQL

SELECT store_id, COUNT(*), SUM(amount)
FROM transactions
WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01'
GROUP BY store_id;

Dưới đây là 5 bước diễn ra bên trong Greenplum chỉ trong tích tắc:

[Client] ──(1. Gửi SQL)──► [ Master Node ] ──(5. Trả kết quả cuối)──► [Client]
                                  │
                  (2. Lập Query Plan & Dispatch)
                                  │
         ┌────────────────────────┼────────────────────────┐
         ▼                        ▼                        ▼
┌─────────────────┐      ┌─────────────────┐      ┌─────────────────┐
│   Segment 1     │      │   Segment 2     │      │  Segment 100    │
│ (Quét 10M dòng) │      │ (Quét 10M dòng) │ ...  │ (Quét 10M dòng) │ ◄─ (3. Local Scan
│ Lọc & Gom cục bộ│      │ Lọc & Gom cục bộ│      │ Lọc & Gom cục bộ│     & Pre-Aggregation)
└────────┬────────┘      └────────┬────────┘      └────────┬────────┘
         │                        │                        │
         └────────────────────────┼────────────────────────┘
                                  ▼
                (4. Gather Motion / Final Aggregation)
                          [ Master Node ]

1. Parse & Optimize (Tại Master): Master nhận câu lệnh SQL, kiểm tra cú pháp và dùng bộ tối ưu hóa GPORCA để biên dịch thành một cây kế hoạch thực thi phân tán (gồm các mảnh nhỏ gọi là Slices).

2. Dispatch (Phát lệnh): Master gửi kế hoạch thực thi này xuống tất cả 100 Segments cùng một lúc qua mạng Interconnect.

3. Local Scan & Pre-Aggregation (Tại các Segments):

   • Cả 100 Segments đồng loạt đọc 10 triệu dòng trên ổ cứng của riêng mình (không ai chờ ai).

   • Mỗi Segment tự lọc điều kiện WHERE created_at... và tự tính nháp COUNT(*), SUM(amount) gom nhóm theo store_id trên tập dữ liệu cục bộ của mình.

   • Giả sử hệ thống chỉ có 500 cửa hàng (store_id), thì từ 10 triệu dòng ban đầu, mỗi Segment rút gọn xuống chỉ còn tối đa 500 dòng kết quả tạm.

4. Motion & Final Aggregation (Gom kết quả):

   • Thay vì phải đẩy hàng tỷ dòng qua mạng về Master, mỗi Segment chỉ gửi 500 dòng kết quả đã tính nháp về Master (hoặc gom qua một bước trung gian tùy theo Distribution Key).

   • Master (hoặc các Segment) cộng dồn các con số nháp này lần cuối để ra tổng doanh thu chính xác của 500 cửa hàng.

5. Return (Trả kết quả): Master trả bảng kết quả 500 dòng về cho Client.

Góc nhìn Kiến trúc sư: Hãy chú ý vào Bước 3 và Bước 4. Thay vì kéo 1 tỷ dòng dữ liệu về một chỗ để tính toán (Moving Data to Compute), Greenplum đẩy phép tính toán xuống tận nơi chứa dữ liệu (Pushing Compute to Data). Lượng dữ liệu phải di chuyển qua mạng chỉ là kết quả đã được rút gọn hàng triệu lần!

4. Cạm bẫy lớn nhất trong kiến trúc MPP: Hiệu ứng "Chiếc thùng gỗ" (Data Skew)

Kiến trúc MPP mạnh mẽ vì mọi Segment cùng làm việc song song. Nhưng điều đó cũng dẫn đến một quy luật khắc nghiệt:

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!

Hãy tưởng tượng bạn chia 1 tỷ bản ghi cho 100 công nhân (Segments), nhưng do chọn sai khóa phân phối (Distribution Key):

• 99 công nhân đầu tiên chỉ nhận mỗi người 1 triệu bản ghi (xử lý mất 0.5 giây là xong rồi ngồi chơi chờ đợi).

• Công nhân thứ 100 bị dồn tới 901 triệu bản ghi (xử lý mất 450 giây, tràn cả RAM ra ổ cứng).

• Kết quả: Master phải chờ đủ cả 100 công nhân báo cáo mới trả kết quả về cho bạn. Câu truy vấn của bạn vẫn mất 450 giây, và 99% tài nguyên của cụm máy chủ bị bỏ phí!

Hiện tượng này trong Greenplum gọi là Data Skew (Lệch dữ liệu lưu trữ) hoặc Computational Skew (Lệch tải tính toán). Đây là nguyên nhân số 1 khiến các hệ thống Greenplum thiết kế tồi chạy chậm như rùa bò — và chúng ta sẽ có hẳn các bài học chuyên sâu ở Phần 2 để trị tận gốc căn bệnh này.

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

• Kiến trúc Shared-Nothing (MPP) giúp Greenplum mở rộng quy mô tuyến tính (Scale-Out) bằng cách cho mỗi Node sở hữu CPU, RAM, Disk độc lập, triệt tiêu hoàn toàn điểm nghẽn tranh chấp tài nguyên.

• Cụm Greenplum gồm 3 phần: Master (Chỉ huy, giữ Metadata, không giữ dữ liệu bảng), Segments (Lưu dữ liệu băm nhỏ và trực tiếp tính toán song song) và Interconnect (Mạng nội bộ UDP tốc độ cao).

• Nguyên lý "Chia để trị": Dữ liệu được chia nhỏ khi lưu xuống các Segments; khi truy vấn, mỗi Segment tự quét và tính toán cục bộ trên phần dữ liệu của mình trước khi gộp kết quả cuối cùng.

• Quy tắc sống còn: Câu truy vấn chỉ nhanh khi dữ liệu và khối lượng tính toán được chia ĐỀU cho tất cả các Segments.

Ở bài học tiếp theo (Bài học 3), chúng ta sẽ đi sâu vào bộ não của toàn bộ cụm: Master Node (Coordinator) & Standby Master để hiểu cách nó quản lý System Catalog, điều phối Transaction toàn cục (Distributed Transaction) và cơ chế dự phòng khi Master gặp sự cố.