Lakehouse Query Engine: “Bộ não” quyết định hiệu năng hệ thống dữ liệu 2026

Trong kiến trúc Data Lakehouse, nếu Object Storage (S3, GCS) được ví như “nhà kho” và Table Format (Iceberg, Delta Lake) là “hệ thống kệ chứa hàng”, thì Query Engine chính là “đội ngũ vận hành” trực tiếp xử lý và phân phối dữ liệu. Một sai lầm kinh điển của các doanh nghiệp khi xây dựng Modern Data Stack là dồn toàn lực vào việc lưu trữ nhưng lại chọn sai công cụ tính toán.

Kết quả là gì? Dashboard “quay đều” hàng phút, chi phí Cloud tăng vọt và đội ngũ Analyst luôn trong tình trạng chờ đợi. Bài viết này sẽ đi sâu phân tích bản chất của Lakehouse Query Engine và cách lựa chọn giữa Trino, Spark, Flink để tối ưu hóa mọi workload.

1. Bản chất của Lakehouse Query Engine: Tại sao nó khác Database truyền thống?

Để hiểu tại sao chúng ta cần một Query Engine riêng biệt, hãy nhìn vào sự tiến hóa của kiến trúc dữ liệu. Trong các Database truyền thống (như SQL Server hay Oracle), bộ máy tính toán và bộ lưu trữ được thiết kế như một “khối hộc” (Monolithic). Bạn không thể nâng cấp CPU mà không tăng thêm dung lượng đĩa cứng.

Lakehouse Query Engine phá vỡ rào cản này bằng triết lý Separation of Compute and Storage (Tách biệt tính toán và lưu trữ).

Cơ chế hoạt động của một External Engine

Không giống như database quản lý dữ liệu vật lý, Query Engine trong Lakehouse là một lớp “phi trạng thái” (stateless). Nó không thực sự sở hữu dữ liệu. Khi bạn chạy một câu lệnh SQL:

1. Metadata Discovery: Engine sẽ hỏi Table Format (ví dụ Iceberg) để biết dữ liệu nằm ở những file nào trên S3.
2. Resource Allocation: Engine tự động huy động các Worker Node trong cụm cluster để chuẩn bị xử lý.
3. Data Ingestion: Dữ liệu được kéo từ Object Storage qua mạng (Network) vào bộ nhớ RAM của Engine để tính toán.

Sự tách biệt này mang lại khả năng linh hoạt tối thượng: Bạn có thể tắt toàn bộ Compute khi không dùng đến để tiết kiệm hàng ngàn USD chi phí Cloud mỗi tháng, trong khi dữ liệu vẫn an toàn ở Storage giá rẻ.

2. Giải mã “Lifecycle” của một truy vấn: Tại sao cùng một câu SQL nhưng tốc độ lại khác nhau?

Nhiều người lầm tưởng SQL chỉ là một ngôn ngữ tiêu chuẩn và engine nào chạy cũng như nhau. Thực tế, sự khác biệt nằm ở Optimizer (Bộ tối ưu hóa).

Logical Plan vs Physical Plan

Mọi engine đều bắt đầu bằng việc tạo ra một Logical Plan (Kế hoạch logic) – mô tả những gì cần làm. Nhưng bước quan trọng nhất là tạo ra Physical Plan (Kế hoạch vật lý) – mô tả cách thức làm việc đó trên phần cứng.

Vai trò của Cost-Based Optimizer (CBO)

Các engine hiện đại như Trino hay Spark SQL sử dụng CBO để ra quyết định dựa trên thống kê (Statistics) dữ liệu:

• Predicate Pushdown: Thay vì kéo 1 tỷ dòng dữ liệu về rồi mới lọc, engine “đẩy” điều kiện lọc xuống tận tầng lưu trữ, chỉ kéo về 100 dòng cần thiết.
• Join Reordering: Nếu bạn Join 3 bảng A, B, C, CBO sẽ tính toán xem nên Join bảng nào trước để tốn ít RAM nhất.
• Column Pruning: Chỉ đọc đúng các cột có trong câu lệnh SELECT, bỏ qua hàng trăm cột khác trong file Parquet.

Một engine có Optimizer thông minh có thể giúp query chạy nhanh gấp 100 lần so với một engine cơ bản, dù dùng chung một cấu hình phần cứng.

3. Phân tích “Tam mã”: Trino vs Spark vs Flink

Không có engine “vạn năng”, chỉ có engine phù hợp nhất cho từng kịch bản. Hãy cùng mổ xẻ “DNA” của ba đại diện ưu tú nhất.

3.1. Trino (Tiền thân là PrestoSQL): Vị vua của Interactive Analytics

Trino được thiết kế với mục tiêu duy nhất: Tốc độ truy vấn con người.

• Kiến trúc: MPP (Massively Parallel Processing). Dữ liệu được xử lý hoàn toàn trong bộ nhớ (In-memory) và đẩy trực tiếp giữa các node qua mạng mà không cần ghi xuống đĩa trung gian.
• Điểm mạnh: Độ trễ (Latency) cực thấp. Trino hỗ trợ Federated Query, cho phép bạn Join một bảng từ MySQL với một bảng từ Data Lake Iceberg chỉ bằng một câu lệnh SQL duy nhất.
• Hạn chế: Vì hoạt động hoàn toàn trên RAM, nếu một query quá lớn vượt quá bộ nhớ, nó sẽ bị “kill” (lỗi Out of Memory). Trino không phù hợp cho các batch job chạy hàng giờ đồng hồ.

3.2. Apache Spark (Spark SQL): “Lực sĩ” của Batch Processing

Spark là tiêu chuẩn công nghiệp cho việc xử lý dữ liệu lớn (Big Data).

• Kiến trúc: Dag-based execution với cơ chế Fault Tolerance mạnh mẽ. Nếu một node bị chết giữa chừng, Spark có thể tái tạo lại phần việc đó mà không phải chạy lại từ đầu.
• Điểm mạnh: Throughput (Băng thông xử lý) khổng lồ. Spark cực kỳ bền bỉ với các pipeline ETL phức tạp, yêu cầu nhiều bước Shuffle dữ liệu.
• Hạn chế: Overhead lớn. Việc khởi tạo một Spark Session thường mất vài giây, điều này khiến nó không lý tưởng cho các Dashboard cần phản hồi trong vài mili giây.

3.3. Apache Flink: Tương lai của Real-time Streaming

Flink đi theo triết lý “Everything is a stream”.

• Kiến trúc: Continuous processing. Thay vì đợi gom đủ 1 tiếng dữ liệu rồi mới xử lý (Micro-batch), Flink xử lý từng bản ghi ngay khi nó vừa xuất hiện.
• Điểm mạnh: Độ trễ gần như bằng 0 (Real-time). Flink cực mạnh trong việc tính toán Windowing (ví dụ: tính tổng doanh thu trong 5 phút gần nhất).
• Hạn chế: Độ phức tạp vận hành cao. Việc quản lý State (trạng thái) của Flink đòi hỏi đội ngũ kỹ sư có trình độ chuyên môn sâu.

4. Framework lựa chọn Engine: Đúng người, đúng việc, đúng thời điểm

Để chọn đúng engine, doanh nghiệp cần phân loại workload theo mô hình sau:

Kịch bản 1: Phục vụ BI Dashboard & Ad-hoc Query

• Yêu cầu: User cần xem biểu đồ ngay khi click chuột. Concurrency (số lượng người dùng đồng thời) cao.
• Engine khuyên dùng: Trino.
• Tại sao: Trino tối ưu cho việc trả về kết quả nhanh cho người dùng cuối và không tốn thời gian “warm-up” cụm cluster.

Kịch bản 2: Xây dựng Pipeline ETL/ELT quy mô lớn

• Yêu cầu: Xử lý hàng Terabyte dữ liệu từ Raw sang Silver/Gold layer mỗi đêm. Cần sự ổn định (Reliability).
• Engine khuyên dùng: Spark SQL.
• Tại sao: Spark có khả năng “spill to disk” (đẩy dữ liệu xuống đĩa khi thiếu RAM), giúp các job lớn không bị chết giữa chừng.

Kịch bản 3: Phân tích thời gian thực (Real-time Analytics)

• Yêu cầu: Phát hiện gian lận tài chính hoặc cập nhật tồn kho ngay lập tức.
• Engine khuyên dùng: Flink SQL.
• Tại sao: Khả năng xử lý sự kiện (Event-driven) giúp doanh nghiệp phản ứng với thị trường nhanh hơn đối thủ.

5. Sự kết hợp hoàn hảo: Engine + Table Format

Hiệu năng của Query Engine bị giới hạn bởi khả năng cung cấp thông tin của Table Format.

• Trino + Iceberg: Đây là “cặp bài trùng” cho phân tích hiện đại. Iceberg cung cấp metadata chi tiết giúp Trino thực hiện Data Skipping (bỏ qua các file không chứa dữ liệu cần tìm) cực kỳ hiệu quả.
• Spark + Delta Lake: Cả hai đều thuộc hệ sinh thái của Databricks, mang lại sự tương thích tuyệt đối, hỗ trợ các tính năng như Z-Order Indexing giúp tăng tốc truy vấn Spark lên nhiều lần.

6. Tối ưu chi phí TCO: Nghệ thuật vận hành Lakehouse

Chọn engine đúng mới chỉ là một nửa chặng đường. Để không bị “sốc” khi nhận hóa đơn tiền Cloud, bạn cần lưu ý:

1. Auto-scaling: Cấu hình để cụm Trino hoặc Spark tự động giảm số lượng node xuống khi ban đêm không có người dùng.
2. Spot Instances: Sử dụng các máy chủ giá rẻ (Spot/Preemptible) cho các job Spark không quá khẩn cấp để tiết kiệm tới 70% chi phí.
3. Data Layout: Sắp xếp dữ liệu theo các cột thường xuyên được Filter (ví dụ: event_date). Engine giỏi đến mấy cũng sẽ chậm nếu phải scan toàn bộ cái hồ dữ liệu thô.

7. Kết luận: Đừng tìm Engine mạnh nhất, hãy tìm Engine phù hợp nhất

Kiến trúc Data Lakehouse linh hoạt ở chỗ nó cho phép bạn sử dụng đa engine (Multi-engine architecture). Không có lý do gì bạn phải ép Spark làm nhiệm vụ của BI Dashboard, hay ép Trino chạy các job ETL nặng nề suốt 5 tiếng đồng hồ.

Một hệ thống dữ liệu thành đạt là hệ thống biết tận dụng:

• Flink để đón đầu dữ liệu.
• Spark để nhào nặn dữ liệu.
• Trino để trình diễn dữ liệu.

Bằng cách hiểu rõ trade-off (sự đánh đổi) của từng công cụ, bạn không chỉ tối ưu được hiệu năng mà còn xây dựng được một nền tảng dữ liệu bền vững, sẵn sàng cho mọi thử thách của Big Data và AI trong tương lai.

FAQ: Những câu hỏi thường gặp về Lakehouse Engine

1. Tôi có thể dùng một engine cho tất cả mọi việc không?
Có thể, nhưng sẽ cực kỳ tốn kém và hiệu suất kém. Ví dụ, dùng Spark cho BI sẽ làm Analyst khó chịu vì chờ đợi, dùng Trino cho ETL sẽ làm hệ thống thường xuyên bị lỗi RAM.

2. StarRocks hay Doris có phải là Lakehouse Engine không?
Có, đây là các engine mới nổi (mạnh về OLAP) đang thách thức vị thế của Trino bằng cách tối ưu hóa cực sâu vào tầng vectorization. Chúng rất đáng cân nhắc nếu bạn cần tốc độ “sub-second” cho các báo cáo cực kỳ phức tạp.

3. Làm sao để biết engine của tôi đang chạy chậm ở bước nào?
Hãy kiểm tra Query Plan và Execution Timeline. Hầu hết các engine đều có giao diện Web UI để bạn thấy bước nào đang chiếm nhiều thời gian nhất (thường là Data Scanning hoặc Data Shuffling).

INDA Academy tự hào là đơn vị tiên phong trong việc đào tạo phân tích dữ liệu và AI chuyên sâu, đặc biệt cho khối ngành Ngân hàng – Tài chính – Bảo hiểm tại Việt Nam. Sau hơn 12 năm “thực chiến” cùng những dòng chảy dữ liệu khổng lồ, chúng tôi đã xây dựng nên một hệ sinh thái đào tạo toàn diện, giúp hàng nghìn học viên chuyển mình từ người mới bắt đầu trở thành những chuyên gia lành nghề, sẵn sàng đáp ứng tiêu chuẩn khắt khe của các doanh nghiệp lớn.

Điểm khác biệt lớn nhất tại INDA chính là triết lý đào tạo dựa trên các dự án thực tế (Project-based) và lộ trình cá nhân hóa nhờ ứng dụng AI. Chúng tôi không chỉ dạy bạn cách sử dụng công cụ, mà còn truyền tải tư duy khai phá giá trị từ dữ liệu để đưa ra quyết định kinh doanh chính xác.

Tìm hiểu thêm về các khóa học TẠI ĐÂY:
Lộ trình đào tạo Data Engineer
Lộ trình đào tạo Data Analyst
Lộ trình đào tạo Tester
Khóa học Data Engineer nâng cao – Thực chiến 5 dự án doanh nghiệp
Khóa học Data Analyst nâng cao – Thực chiến 5 dự án doanh nghiệp