Trino 8 — Triển khai, vận hành & use case

Bảy bài trước đi từ tổng quan, kiến trúc, connectors, SQL liên hợp, truy vấn lakehouse, tuning hiệu năng đến bảo mật & quản trị. Bài cuối này khép series bằng phần "khó nhằn nhưng quyết định thành bại": đưa Trino vào production, vận hành ổn định, và biết khi nào nên dùng Trino thay vì công cụ khác.

Trino chạy demo trên laptop thì dễ; nuôi một cụm phục vụ hàng trăm analyst NCB truy vấn data lake mỗi ngày mới là chuyện thật. Ta sẽ nói về hình dạng cụm, cấu hình, triển khai trên Kubernetes, giám sát, xử lý sự cố và tối ưu chi phí — rồi kết bằng các use case ngân hàng đã gặp xuyên suốt series.

Hình dạng một cụm Trino

Một cụm Trino chỉ có hai vai trò tiến trình (cùng một binary, khác cấu hình):

• Coordinator: nhận SQL, phân tích/lập kế hoạch, điều phối, chạy Web UI, giữ metadata phiên. Một cụm có đúng một coordinator active (có thể thêm coordinator dự phòng ở bản thương mại).
• Worker: thực thi task, đọc dữ liệu qua connector, làm join/aggregate, trao đổi dữ liệu trung gian với nhau. Càng nhiều worker càng nhiều throughput.

Client (BI tool, trino-cli, JDBC) chỉ nói chuyện với coordinator. Worker không lộ ra ngoài.

Cấu hình cốt lõi (file, không phải UI)

Trino cấu hình bằng file text trong thư mục etc/. Ba nhóm quan trọng:

config.properties — vai trò node và tài nguyên truy vấn:

# coordinator node
coordinator=true
node-scheduler.include-coordinator=false   # coordinator không tự chạy task
http-server.http.port=8080
discovery.uri=http://trino-coordinator:8080
query.max-memory=200GB            # tổng RAM tối đa 1 query dùng trên toàn cụm
query.max-memory-per-node=8GB     # RAM tối đa 1 query dùng trên 1 worker

Worker dùng file tương tự nhưng coordinator=false.

jvm.config — tham số JVM. Trino là ứng dụng Java, heap là biến sống còn:

-Xmx24G
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+ExitOnOutOfMemoryError     # OOM thì thoát để orchestrator restart, tránh treo

Quy tắc kinh nghiệm: đặt -Xmx khoảng 70–80% RAM node, chừa phần cho hệ điều hành và bộ nhớ ngoài heap.

catalog/*.properties — mỗi file là một catalog (một kết nối tới một nguồn). Ví dụ catalog/core.properties:

connector.name=postgresql
connection-url=jdbc:postgresql://core-db:5432/bank
connection-user=trino_ro
connection-password=${ENV:CORE_DB_PW}

Đây chính là cơ chế đã dùng suốt series: mỗi nguồn (data lake, Postgres core, MySQL CRM) là một catalog. Chi tiết connector xem lại Trino 3.

Triển khai: VM/bare-metal vs Kubernetes

Trên VM/bare-metal

Cách truyền thống: cài Trino lên vài máy, một máy làm coordinator, còn lại làm worker, cùng trỏ về một discovery.uri. Quản lý bằng systemd/Ansible. Ưu điểm: đơn giản, kiểm soát phần cứng; nhược: thêm/bớt worker thủ công, khó autoscale.

Trên Kubernetes (khuyến nghị cho môi trường động)

Trino chạy rất hợp với Kubernetes vì worker là stateless — mất một worker chỉ làm fail các query đang chạy trên nó, không mất dữ liệu. Hai đường phổ biến:

• Helm chart chính thức của Trino (trino/trino): deploy coordinator (1 pod) + workers (Deployment nhiều replica), cấu hình catalog qua values.yaml/Secret.
• Trino Operator (CRD): mô tả cụm bằng một custom resource, operator lo vòng đời.

Ví dụ trích values.yaml (minh hoạ, KHÔNG phải SQL):

server:
  workers: 6
coordinator:
  jvm:
    maxHeapSize: "24G"
worker:
  jvm:
    maxHeapSize: "48G"
  resources:
    requests: { cpu: "8", memory: "56Gi" }
autoscaling:
  enabled: true
  minReplicas: 4
  maxReplicas: 20
  targetCPUUtilizationPercentage: 70
additionalCatalogs:
  core: |
    connector.name=postgresql
    connection-url=jdbc:postgresql://core-db:5432/bank

Autoscale workers qua HPA (Horizontal Pod Autoscaler) theo CPU/query queue là điểm mạnh: giờ cao điểm phình ra 20 worker, đêm co còn 4. Lưu ý cần cấu hình graceful shutdown để worker đang chạy task được rút êm, không kill giữa query. Chi tiết vận hành K8s xem k8s-08-production-ops.

Tách môi trường

Nên tách dev / staging / prod thành các cụm (hoặc namespace) riêng, mỗi cụm có catalog trỏ tới nguồn tương ứng. Không cho analyst truy vấn thẳng vào cụm dùng chung với ETL nặng — dễ nghẽn lẫn nhau.

Sizing & mở rộng

Trino mở rộng chủ yếu theo chiều ngang (scale out — thêm worker), không phải chiều dọc:

• Throughput / độ song song: thêm worker → nhiều task chạy song song → query nhanh hơn và cụm gánh nhiều query đồng thời hơn. Đây là đòn bẩy chính.
• Bộ nhớ theo query: query có join/aggregate lớn cần nhiều RAM. Nếu hay OOM, tăng RAM mỗi worker (heap) và/hoặc nới query.max-memory-per-node, hoặc bật spill-to-disk cho query lớn.
• Số worker theo tải: ước lượng từ số query đồng thời và lượng dữ liệu quét. Bắt đầu nhỏ (4–8 worker), đo bằng metrics rồi tăng dần. Quy tắc: coordinator không cần to bằng worker (nó không xử lý dữ liệu), nhưng cần đủ RAM cho việc lập kế hoạch query phức tạp.

Đừng quên: Trino không có "storage" để mở rộng — dữ liệu ở nguồn. Mở rộng Trino là mở rộng năng lực tính toán.

Một điểm dễ bỏ sót: coordinator là điểm nghẽn tiềm ẩn. Khi số query đồng thời tăng cao, coordinator phải lập kế hoạch, điều phối và giữ trạng thái cho tất cả — CPU và RAM của nó có thể cạn trước worker. Nếu Web UI phản hồi chậm hay query xếp hàng dù worker còn rảnh, thủ phạm thường là coordinator thiếu tài nguyên, không phải thiếu worker.

Phiên bản & bản phân phối

Điểm cần nhớ: Athena chính là Presto/Trino chạy serverless — cùng phương ngữ SQL bạn đã học suốt series, chỉ khác cách vận hành và mô hình tính phí (theo TB quét).

Giám sát & vận hành

Trino phơi metrics rất phong phú qua JMX (Java Management Extensions). Bộ công cụ vận hành điển hình:

• JMX → Prometheus: dùng catalog jmx hoặc JMX exporter đẩy metrics (số query active, memory pool, task fail, CPU) vào Prometheus, dựng dashboard Grafana. Nền tảng observability xem obs-01-overview.
• Web UI (cổng 8080 trên coordinator): xem query đang chạy, giai đoạn (stages), lượng dữ liệu quét, worker nào chậm. Công cụ chẩn đoán nhanh số một.
• Query history / event listener: cấu hình event-listener để ghi mọi query (người chạy, thời lượng, bytes quét, lỗi) vào Kafka/DB — phục vụ audit và phân tích chi phí. Kết hợp với governance ở Trino 7.
• Resource groups: định nghĩa nhóm tài nguyên (theo user/nguồn) với hạn mức concurrency và bộ nhớ, để query ad-hoc của analyst không cướp tài nguyên của báo cáo định kỳ.

Xử lý sự cố thường gặp

Chi tiết tuning và pushdown đã bàn kỹ ở Trino 6.

Nâng cấp

Trino ra bản mới liên tục (đánh số tăng dần). Nâng cấp cần: đọc release note (đôi khi có breaking change ở connector/cú pháp), nâng ở dev trước, và vì worker stateless nên có thể rolling upgrade trên K8s — thay từng pod, giữ cụm phục vụ liên tục. Coordinator và worker nên cùng phiên bản.

Tối ưu chi phí

Vì Trino tách tính toán khỏi lưu trữ, chi phí gần như toàn bộ nằm ở compute — có nhiều đòn bẩy:

• Autoscale + tắt ngoài giờ: co worker về tối thiểu (hoặc 0 với cụm dev) ngoài giờ hành chính. Analyst NCB chủ yếu làm việc 8h–18h.
• Spot instances cho worker: worker stateless nên chịu được bị thu hồi — dùng máy spot/preemptible giảm 60–80% chi phí; giữ coordinator trên máy on-demand để cụm không sập.
• Kiểm soát dữ liệu quét: partition pruning và cột định dạng cột (Parquet/ORC) giảm bytes đọc — với Athena, bytes quét chính là hoá đơn.

Nguyên tắc FinOps: đo bytes quét theo query (event listener) để tính "ai tốn nhất". Xem thêm góc chi phí ở snow-06-cost-management.

Chọn Trino, warehouse hay Spark?

Tóm gọn: Trino để hỏi, warehouse để phục vụ báo cáo ổn định, Spark để biến đổi. Chúng thường sống chung: Spark dựng lakehouse (data-engineering-07-lakehouse), Trino truy vấn tương tác trên đó, warehouse phục vụ các mart trọng yếu.

Use case thực tế

Bối cảnh NCB: Khối Phân tích cần một "cửa SQL" duy nhất truy cập cả data lake (giao dịch lịch sử, Parquet trên S3), core banking (PostgreSQL) và CRM (MySQL), phục vụ ~80 analyst và các dashboard Superset. Trước đây mỗi nguồn một công cụ, báo cáo gộp phải chờ ETL đêm.

Triển khai: Dựng cụm Trino trên Kubernetes bằng Helm — 1 coordinator (24GB heap) + 6 worker (48GB heap) chạy trên spot, HPA autoscale 4→20 theo CPU. Ba catalog lake / core / crm. Bật resource group tách nhóm analyst (concurrency 30) và report (concurrency 5, ưu tiên bộ nhớ). Event listener đẩy query log vào Kafka; JMX → Prometheus/Grafana. Superset và Metabase kết nối qua JDBC vào coordinator để dựng BI.

Kết quả sau 3 tháng: báo cáo federated (gộp giao dịch lake + hồ sơ khách core + phân khúc CRM) từ "chờ tới sáng hôm sau" xuống còn dưới 1 phút; analyst tự khám phá data lake không cần data engineer bê bảng; nhờ spot + tắt worker ngoài giờ, chi phí compute giảm ~55% so với ước tính cụm on-demand chạy 24/7. Các use case xuyên suốt series hội tụ ở đây: lớp SQL thống nhất trên lake + DB nghiệp vụ, ad-hoc analytics, phục vụ BI, và federated report gộp nhiều nguồn.

Một truy vấn analyst điển hình — tổng hợp chi tiêu theo khách hàng, ghép chuỗi customers → accounts → transactions trong một câu (ANSI SQL, đúng khoá join):

-- ▶ Chạy được
SELECT c.full_name,
       c.city,
       a.currency,
       COUNT(t.id)   AS so_giao_dich,
       SUM(t.amount) AS tong_tien
FROM customers c
JOIN accounts a      ON a.customer_id = c.id
JOIN transactions t  ON t.account_id = a.id
WHERE t.created_at >= TIMESTAMP '2026-01-01 00:00:00'
GROUP BY c.full_name, c.city, a.currency
ORDER BY tong_tien DESC
LIMIT 50;

Trên cụm thật, mỗi bảng có thể nằm ở một catalog khác nhau (lake.transactions, core.customers...) — cú pháp giống hệt, chỉ thêm tiền tố catalog. Câu tổng hợp lương phòng ban (employees JOIN departments qua department_id) là một truy vấn độc lập khác trên cùng cụm.

Ghi nhớ

• Cụm Trino = 1 coordinator + nhiều worker cùng binary, khác cấu hình; client chỉ nói với coordinator, worker stateless.
• Cấu hình bằng file: config.properties (vai trò/RAM query), jvm.config (heap ~70–80% RAM node), catalog/*.properties (mỗi nguồn một catalog).
• Kubernetes + Helm/Operator hợp nhất với Trino vì worker stateless: HPA autoscale, rolling upgrade, graceful shutdown; tách dev/staging/prod.
• Mở rộng theo chiều ngang (thêm worker tăng throughput); tăng RAM worker khi query OOM; Trino không mở rộng storage — dữ liệu ở nguồn.
• Chọn bản: OSS (tự chủ) / Starburst (enterprise, hỗ trợ) / Athena (Trino serverless của AWS, tính theo TB quét) / EMR.
• Giám sát: JMX → Prometheus, Web UI, event listener cho query history, resource groups chia tài nguyên theo nhóm.
• Sự cố hay gặp: OOM (thêm filter/spill/RAM), worker chết (auto-restart + retry), skew (đổi join/broadcast/tách key nóng).
• Tối ưu chi phí: spot cho worker, autoscale + tắt ngoài giờ, giảm bytes quét (partition + cột hoá).
• Định vị: Trino để hỏi (federated, tương tác), warehouse để phục vụ báo cáo ổn định, Spark để transform/ML — thường dùng chung.