📚 课程目录第4章 Trino安装与部署

4. Trino安装与部署

Trino 的部署形态直接决定了查询性能、可用性与运维成本。在金融湖仓场景中，同一套 SQL 引擎可能既要支撑分析师的即席查询，又要承载监管报送的批处理任务，因此理解四种部署方式的适用边界，比记住安装命令更重要。本节从部署形态的架构差异入手，逐层拆解配置文件，并给出面向金融生产环境的落地建议。

一、四种部署形态的架构差异

Trino 采用 Coordinator 与 Worker 分离的 MPP 架构。Coordinator 负责解析 SQL、生成分布式执行计划、调度 Stage 与 Task；Worker 负责实际的数据读取与算子执行。单机部署把两种角色压缩在同一进程，Docker 部署将其封装为镜像，Kubernetes 部署则把 Worker 变成可弹性伸缩的 Pod。理解这一条主线，就能判断每种方式的取舍。

二、单机与集群部署的关键步骤

单机部署适合开发验证与功能测试。下载 trino-server 压缩包后解压，创建 etc 目录并写入最小配置即可启动。核心是 node.properties 中的 node.environment 与 node.data-dir，以及 config.properties 中的角色声明。

# etc/config.properties（单机）
coordinator=true
node-scheduler.include-coordinator=true
http-server.http.port=8080
query.max-memory=4GB
query.max-memory-per-node=1GB
discovery.uri=http://localhost:8080

# 启动
bin/launcher start
bin/launcher status
tail -f var/log/server.log

集群部署时，Coordinator 与 Worker 使用同一份 config.properties 模板，仅角色参数不同。Worker 必须设置 coordinator=false 且 node-scheduler.include-coordinator=false，并通过 discovery.uri 指向 Coordinator。生产集群建议 Coordinator 不承担计算任务，避免调度与执行争抢资源。

金融场景中，Coordinator 节点应独立部署并配置较高内存，Worker 节点按数据本地性靠近 HDFS DataNode 或对象存储网关，减少跨机房流量。

三、Docker 与 Kubernetes 部署要点

Docker 部署的价值在于环境一致性与快速交付。官方镜像 trinodb/trino 默认读取 /etc/trino 目录，因此只需挂载配置目录与数据目录即可。多容器场景下，Coordinator 与 Worker 通过自定义网络互通，Worker 的 discovery.uri 指向 Coordinator 的服务名。

docker run -d --name trino-coordinator \
  -p 8080:8080 \
  -v ./etc-coordinator:/etc/trino \
  -v ./data:/data/trino \
  trinodb/trino:latest

Kubernetes 部署通常使用 Helm Chart，将 Coordinator 与 Worker 拆分为不同 Deployment。Worker 可配置 HPA 按 CPU 或查询队列长度弹性伸缩。需要注意的是，Trino Worker 是有状态计算节点，缩容时应等待运行中查询结束，否则会触发查询失败重试。

# Helm 安装示例
helm repo add trino https://trinodb.github.io/charts
helm install finance-trino trino/trino \
  --set coordinator.resources.requests.memory=16Gi \
  --set worker.replicas=6 \
  --set worker.resources.requests.memory=32Gi \
  --set additionalCatalogs.hive=hive.properties

四、配置文件详解与金融生产环境建议

配置文件是 Trino 稳定运行的核心。下表汇总了金融生产环境最常调整的参数及其影响。

配置文件	关键参数	金融生产建议
config.properties	query.max-memory、query.max-memory-per-node	按单查询上限设置，防止大查询拖垮集群；建议单查询不超过集群总内存的 30%
config.properties	query.max-execution-time	设置超时阈值，避免监管报送窗口被长查询阻塞
jvm.config	-Xmx、-XX:+UseG1GC	堆内存不超过物理内存 70%，启用 G1 降低大堆 GC 停顿
node.properties	node.data-dir	指向独立高速盘，避免与日志盘争抢 IO
catalog/hive.properties	hive.metastore.uri、hive.s3.endpoint	Metastore 高可用，S3 端点走内网并启用 TLS
resource-groups.properties	resource-groups.config-file	按部门或业务线划分资源组，实现多租户隔离

常见误区：把 node-scheduler.include-coordinator=true 带入生产集群，导致 Coordinator 同时承担调度与计算，查询高峰期调度延迟飙升。另一个误区是 Worker 内存配置超过物理内存，触发 OOM Killer 后节点频繁掉线。

金融生产环境还需关注安全与审计。建议启用 HTTPS 与 LDAP/Kerberos 认证，开启查询审计日志，并将 http-server.process-forwarded 与代理层配合使用。对于跨机房联邦查询，应评估网络带宽与延迟，必要时在靠近数据源的机房部署独立 Trino 集群，通过视图或物化结果做逻辑汇聚，而不是让单集群跨广域网拉取海量数据。

复盘一个典型场景：某银行初期用单机 Trino 支撑报表，随着 Iceberg 表数据量增长到百 TB 级，单机内存与并发成为瓶颈。迁移到 Kubernetes 集群后，通过资源组隔离了即席查询与批处理任务，并将 Worker 按数据本地性调度，查询 P95 延迟下降约 60%。这说明部署形态的选择必须与数据规模、并发模式和 SLA 要求同步演进。