Trino SQL Bài học 45: Tổng kết - Kiến trúc phân tán của Trino và khái niệm Connector

Mục tiêu bài học:

• Đóng gói toàn bộ kiến thức SQL bằng việc thấu hiểu "động cơ" (Engine) chạy bên dưới các dòng code của bạn.

• Nắm vững triết lý thiết kế "Tách biệt Tính toán và Lưu trữ" (Compute vs. Storage).

• Phân biệt vai trò của Bộ não (Coordinator) và Cơ bắp (Worker).

• Hiểu sự thần kỳ của Connector - chìa khóa giúp Trino truy vấn được mọi thứ từ Kafka, PostgreSQL đến Amazon S3.

1. Bức tranh toàn cảnh: Tách biệt Tính toán và Lưu trữ

Trong các cơ sở dữ liệu truyền thống (như MySQL, PostgreSQL, Oracle), năng lực Tính toán (CPU/RAM để chạy SQL) và năng lực Lưu trữ (Ổ cứng SSD chứa dữ liệu) bị trói chặt vào cùng một máy chủ. Khi hết ổ cứng, bạn phải mua thêm máy chủ mới dù CPU vẫn đang rảnh rỗi.

Trino (và các công cụ Big Data hiện đại) áp dụng triết lý ngược lại:

• Dữ liệu được vứt xuống một kho lưu trữ cực rẻ, dung lượng vô hạn (Data Lake như Amazon S3, HDFS).

• Trino là một cụm máy chủ (Cluster) hoàn toàn trống rỗng, chỉ có CPU và RAM.

• Khi bạn chạy SQL, Trino "thò tay" xuống S3 lấy dữ liệu lên RAM, xử lý xong thì trả kết quả rồi quên luôn.

Nhờ triết lý này, Trino có thể mở rộng tài nguyên tính toán (Scale out) cực kỳ linh hoạt mà không cần quan tâm đến việc di chuyển dữ liệu.

2. Kiến trúc MPP: Bộ não (Coordinator) và Cơ bắp (Worker)

Trino hoạt động theo mô hình Massively Parallel Processing (MPP) - Xử lý song song cường độ cao. Một cụm (Cluster) Trino luôn có hai loại máy chủ đóng vai trò khác biệt:

• Coordinator (Bộ não / Người quản lý):

  • Chỉ có 1 máy duy nhất đóng vai trò này.

  • Khi bạn gõ lệnh SQL trên DBeaver hoặc DataGrip, lệnh đó sẽ bay đến Coordinator.

  • Nó phân tích cú pháp SQL (Parsing), lập kế hoạch thực thi tối ưu (Planning - Bài 39), và băm câu lệnh đó ra thành hàng trăm nhiệm vụ nhỏ (Tasks).

  • Nó hoàn toàn không tự tay đọc dữ liệu.

• Worker (Cơ bắp / Công nhân):

  • Có thể có hàng chục đến hàng nghìn máy Worker trong một cụm.

  • Nhận lệnh từ Coordinator, các Worker sẽ đồng loạt lặn xuống Data Lake, song song vớt dữ liệu lên, lọc (WHERE), gom nhóm (GROUP BY), và nối bảng (JOIN) trực tiếp trên RAM của chúng.

  • Sau khi tính xong, chúng ném mảnh kết quả về lại cho Coordinator để ghép lại và gửi cho bạn.

3. Connector: Chìa khóa vạn năng của Trino

Vì Trino không tự lưu trữ dữ liệu, làm sao nó biết cách nói chuyện với MySQL, lúc khác lại đọc file Parquet trên S3, hay thậm chí đọc luồng dữ liệu thời gian thực từ Kafka?

Bí mật nằm ở Connector (Bộ kết nối).

Connector trong Trino hoạt động giống hệt như Driver của máy in trong máy tính. Bạn có hệ điều hành (Trino), bạn cắm máy in HP hay Canon (MySQL hay S3) vào, chỉ cần cài đúng Driver (Connector) là hệ điều hành có thể in được.

Trino sở hữu một hệ sinh thái Connector khổng lồ.

Siêu năng lực của Trino (Federated Query): Bằng cách cài đặt nhiều Connector, bạn có thể viết MỘT câu SQL duy nhất để JOIN bảng khách hàng nằm trong PostgreSQL với bảng log hành vi đang nằm dưới S3, và bảng thanh toán thời gian thực nằm trong Kafka. Trino sẽ đóng vai trò trung gian "điều đạo" dữ liệu giữa các hệ thống này trong chớp mắt.

4. Vòng đời của một câu truy vấn (Life of a Query)

Hãy ráp tất cả những gì bạn đã học trong 45 bài vào một dòng chảy duy nhất:

1. Khách hàng (Bạn): Gửi câu lệnh SELECT ... LEFT JOIN ... WHERE ... đến máy chủ Trino Coordinator.

2. Coordinator (Phân tích): Kiểm tra xem bạn có quyền truy cập bảng không (Bài 44 - GRANT). Phân tích cú pháp xem có lỗi không.

3. Coordinator (Lập kế hoạch): Gọi xuống các Connector (ví dụ Hive Connector) để hỏi: "Bảng này có bao nhiêu dòng? Nằm ở file nào?". Dựa vào đó, nó lập ra một Distributed Query Plan (Bài 39 - EXPLAIN).

4. Coordinator (Giao việc): Chia Plan thành các Tasks và phát lệnh cho dàn máy Worker.

5. Worker (Thực thi): Kéo dữ liệu qua Connector lên RAM. Thực hiện băm dữ liệu (Hash Join), tính toán Window Functions (Bài 26), hoặc bung mảng (Bài 31 - UNNEST).

6. Trả kết quả: Worker gửi dữ liệu đã xử lý về Coordinator, Coordinator hiện lên màn hình của bạn. Giao dịch kết thúc.