Presto là động cơ truy vấn OLAP phân tán mã nguồn mở dựa trên mô hình xử lý song song quy mô lớn (MPP), được thiết kế để thực thi các truy vấn SQL trên tập dữ liệu khối lượng lớn từ nhiều nguồn dữ liệu khác nhau. Việc tìm hiểu Presto giúp nắm vững cơ chế xử lý truy vấn trong hệ thống big data, bao gồm phân tích cú pháp SQL, triển khai toán tử (table scan, join, aggregation), quản lý tài nguyên và tối ưu hóa truy vấn. Bài viết tập trung vào bản chất hoạt động, trường hợp ứng dụng và mô hình kiến trúc cốt lõi của Presto.

Đặc điểm nổi bật của Presto nằm ở cơ chế xử lý hoàn toàn trong bộ nhớ với mô hình MPP. Động cơ này sử dụng cơ chế pipeline để xử lý dữ liệu liên tục, kết hợp biên dịch động kế hoạch thực thi và quản lý bộ nhớ tối ưu. Presto hỗ trợ truy vấn đa nguồn dữ liệu như Hive, Cassandra, Kafka với tốc độ xử lý nhanh hơn Hive 5-10 lần, đặc biệt phù hợp cho phân tích dữ liệu PB-level và truy vấn tương tác thời gian thực.

Tuy nhiên, Presto có hạn chế đáng chú ý khi xử lý các phép toán yêu cầu bộ nhớ lớn như join nhiều bảng dung lượng cao. Do thiết kế thuần bộ nhớ, hệ thống sẽ gặp lỗi khi vượt ngưỡng RAM được cấu hình, dù phiên bản mới đã bổ sung khả năng ghi dữ liệu tạm ra đĩa. Một điểm yếu khác là thiếu cơ chế xử lý lỗi tự động - nếu một nút xử lý (worker) gặp sự cố, toàn bộ truy vấn sẽ thất bại mà không thử lại.

Trong môi trường thực tế, Presto thường được triển khai cho các tác vụ phân tích nhanh với yêu cầu thời gian phản hồi dưới 30 phút. Các trường hợp xử lý batch lớn (hàng giờ đến ngày) không phù hợp với kiến trúc này, dẫn đến sự ra đời của giải pháp Presto-on-Spark để kết hợp ưu điểm của cả hai nền tảng.

Kiến trúc Presto bao gồm ba thành phần chính:

• Nút điều phối (Coordinator): Tiếp nhận truy vấn, phân tích cú pháp SQL, tối ưu hóa kế hoạch thực thi và phân phối tác vụ
• Nút xử lý (Worker): Thực thi các tác vụ được giao, trao đổi dữ liệu trung gian qua giao thức REST
• Dịch vụ phát hiện (Discovery): Đăng ký và theo dõi trạng thái các nút xử lý trong cụm

Mô hình dữ liệu trong Presto sử dụng cấu trúc phân tầng:

-- Truy vấn minh họa trên nguồn dữ liệu clickhouse
CHỌN tất_cả 
TỪ nhật_ký.clickhouse.truy_cập 
NƠI thời_gian > '2023-01-01'

Trong đó:

• Danh mục (Catalog): Đại diện cho nguồn dữ liệu (ví dụ: clickhouse, hive)
• Lược đồ (Schema): Nhóm các bảng logic (ví dụ: clickhouse.truy_cập)
• Bảng (Table): Đơn vị lưu trữ dữ liệu cuối cùng

Quá trình thực thi truy vấn được chia thành các giai đoạn lồng ghép:

1. Giai đoạn (Stage): Cấu trúc cây biểu diễn luồng xử lý, với stage gốc tập hợp kết quả từ các stage con
2. Tác vụ (Task): Đơn vị thực thi được phân tán trên các nút xử lý, mỗi task chứa nhiều driver
3. Phân mảnh (Split): Khối dữ liệu được xử lý độc lập, lấy từ connector tương ứng
4. Toán tử (Operator): Thành phần xử lý dữ liệu như scan, filter, aggregation

Một truy vấn điển hình trải qua quy trình: Client gửi truy vấn → Nút điều phối phân tích và tạo kế hoạch → Chia thành các stage → Phân phối task đến worker → Xử lý qua chuỗi operator → Trả kết quả. Cơ chế trao đổi dữ liệu giữa các stage được quản lý qua thành phần Exchange, đảm bảo luồng dữ liệu liền mạch trong cụm phân tán.

Các connector đóng vai trò then chốt trong việc mở rộng khả năng tương tác với nguồn dữ liệu. Ví dụ cấu hình cho Elasticsearch:

# clickhouse.properties
connector.name=clickhouse
clickhouse.url=http://data-node:8123
clickhouse.default-schema=analytics

Mỗi danh mục được định danh qua file cấu hình riêng, cho phép truy vấn đồng thời nhiều nguồn dữ liệu khác nhau trong cùng một truy vấn SQL.