Trino SQL Bài học 1: Giới thiệu tổng quan về Trino và kiến trúc phân tán

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

• Hiểu rõ Trino là gì và giải quyết bài toán nào trong thế giới dữ liệu.

• Nắm bắt sự khác biệt cốt lõi giữa Trino và các hệ quản trị cơ sở dữ liệu truyền thống (RDBMS).

• Nắm vững kiến trúc phân tán của Trino (Coordinator, Worker, Connector).

• Hiểu được vòng đời của một câu lệnh SQL khi chạy qua hệ thống Trino.

1. Trino là gì? Đôi nét về lịch sử

Trino là một công cụ truy vấn SQL phân tán mã nguồn mở (Distributed SQL Query Engine), được thiết kế để chạy các truy vấn phân tích siêu tốc độ trên những tập dữ liệu khổng lồ (từ Gigabytes đến Petabytes).

Lịch sử ra đời: Trino ban đầu có tên là Presto (PrestoSQL), được phát triển tại Facebook vào năm 2012 bởi Martin Traverso, Dain Sundstrom, David Phillips, và Eric Hwang. Mục tiêu khi đó là tạo ra một công cụ thay thế Apache Hive chậm chạp để truy vấn lượng dữ liệu khổng lồ của Facebook bằng chuẩn SQL. Đến năm 2020, do những bất đồng về định hướng phát triển, những nhà sáng lập ban đầu đã tách dự án ra và đổi tên thành Trino.

Đặc điểm cốt lõi: Trino KHÔNG PHẢI là một cơ sở dữ liệu (Database). Nó phân tách hoàn toàn tầng tính toán (Compute) và tầng lưu trữ (Storage). Trino không tự lưu trữ dữ liệu, nó chỉ làm nhiệm vụ kết nối đến các kho chứa dữ liệu của bạn, đọc dữ liệu lên bộ nhớ và tính toán bằng SQL.

2. Tại sao lại chọn Trino? (Use Cases)

Trong một hệ thống phức tạp, dữ liệu thường nằm rải rác ở nhiều nơi: thông tin người dùng ở MySQL, log hệ thống ở Elasticsearch hoặc Kafka, dữ liệu lịch sử ở S3/HDFS.

Thay vì phải viết code ETL (Extract, Transform, Load) phức tạp để gom tất cả về một nơi rồi mới query được, Trino mang đến một phép màu gọi là Federated Queries (Truy vấn liên kết đa nguồn).

Những ưu điểm nổi bật:

1. Truy vấn đa nguồn: Bạn có thể viết một câu lệnh SQL duy nhất để JOIN bảng users từ MySQL với bảng logs từ Elasticsearch.

2. Tốc độ In-Memory: Trino xử lý dữ liệu chủ yếu trên RAM (in-memory) thay vì ghi xuống đĩa cứng tại mỗi bước trung gian như MapReduce/Hive, giúp tốc độ truy vấn có thể nhanh hơn từ 10x đến 100x.

3. Chuẩn ANSI SQL: Hỗ trợ chuẩn SQL quen thuộc. Bất kỳ ai biết SQL đều có thể dùng Trino mà không cần học một ngôn ngữ mới.

4. Khả năng mở rộng (Scalability): Có thể dễ dàng thêm hoặc bớt các node tính toán tùy theo khối lượng dữ liệu mà không làm gián đoạn hệ thống.

3. Kiến trúc phân tán của Trino (Core Architecture)

Kiến trúc của Trino hoạt động theo mô hình Master - Slave (hoặc Leader - Follower), bao gồm 3 thành phần chính:

A. Coordinator (Não bộ điều phối)

Thường có một Coordinator duy nhất trong một cụm Trino (Cluster).

• Nhiệm vụ: Là điểm giao tiếp với người dùng (Client/BI Tool). Nó nhận câu lệnh SQL, phân tích cú pháp (Parse), lập kế hoạch thực thi (Plan), tối ưu hóa (Optimize) và phân chia công việc cho các Workers.

• Đặc điểm: Không trực tiếp xử lý dữ liệu để tránh làm quá tải bộ não.

B. Worker (Cơ bắp tính toán)

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

• Nhiệm vụ: Nhận các nhiệm vụ (Tasks) từ Coordinator, kết nối trực tiếp với nguồn dữ liệu để đọc thông tin, thực hiện các phép toán (lọc, JOIN, gom nhóm) trên bộ nhớ (RAM), và trả kết quả trung gian về cho nhau hoặc về Coordinator.

C. Connectors (Những cây cầu kết nối)

Đây là "vũ khí bí mật" của Trino. Trino giao tiếp với các hệ thống lưu trữ bên ngoài thông qua kiến trúc Plugin gọi là Connectors.

• Nhiệm vụ: Dịch các yêu cầu từ Trino thành ngôn ngữ/API mà Data Source (MySQL, PostgreSQL, MongoDB, Kafka, S3...) có thể hiểu được.

• Ví dụ: Trino có mysql connector, hive connector, kafka connector, v.v.

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

Khi bạn gõ SELECT * FROM mysql.sales.orders và nhấn Enter, điều gì xảy ra bên dưới?

1. Parse & Analyze: Client gửi SQL đến Coordinator. Coordinator kiểm tra ngữ pháp SQL và xác thực xem bảng orders có tồn tại hay không, bạn có quyền truy cập không.

2. Plan & Optimize: Trino vạch ra một cây kế hoạch thực thi. Nó cố gắng tối ưu bằng cách đẩy các phép lọc (WHERE) xuống tận Data Source (Predicate Pushdown) để giảm thiểu dữ liệu phải kéo qua mạng.

3. Schedule: Kế hoạch được chia nhỏ thành nhiều Stages và Tasks. Coordinator ra lệnh cho các Workers: "Worker 1 đọc nửa đầu của bảng, Worker 2 đọc nửa sau".

4. Execute: Các Workers dùng Connector để lấy dữ liệu, tính toán in-memory.

5. Return: Kết quả được gộp lại và trả về cho Client.

5. Khi nào KHÔNG NÊN dùng Trino?

Trino rất mạnh, nhưng không phải là "viên đạn bạc" cho mọi thứ. Bạn không nên dùng Trino cho:

• Hệ thống OLTP (Online Transaction Processing): Trino không được thiết kế cho các truy vấn thêm/sửa/xóa (INSERT/UPDATE/DELETE) diễn ra liên tục với độ trễ tính bằng mili-giây như MySQL hay PostgreSQL.

• Lưu trữ dữ liệu: Như đã nói, khởi động lại cụm Trino không làm mất dữ liệu của bạn, vì dữ liệu nằm ở chỗ khác. Nhưng bạn không thể "INSERT" vào Trino nếu không có Connector nối với một nơi lưu trữ cụ thể.

Tiểu kết: Trino là một Query Engine mạnh mẽ giúp phá vỡ các "ốc đảo dữ liệu" (Data Silos), cho phép bạn dùng SQL để phân tích mọi thứ ở bất cứ đâu.