trinodb/trino

当数据已经分散在多个系统里、又不想先做大规模搬迁时，Trino 值得认真评估。它是查询引擎而不是数仓本身，这个区别决定了下面大部分取舍。

解决什么问题

你想回答一个横跨多个数据源的问题：Hive 表、对象存储、关系数据库，也许还有流式数据。没有联邦 SQL 层时，常见做法是把每个源抽出来、落到同一个存储、重新建模，然后才能查询；每出现一种新的数据源组合，就要再建一条管道，而且副本会与原数据逐渐不一致。Trino 改变的是中间这一步：为每个数据源配置连接器，让一个 SQL 客户端指向引擎，由引擎规划并执行跨源的连接和聚合。你不需要先拼出一份新副本，就能拿到结果。

有什么不同

Trino 是用 Java 编写的分布式查询引擎：客户端查询被解析、规划后拆分到多个工作节点执行，README 把整个项目定位为面向大数据的快速分析查询，而不是事务型负载。实际好处是数据可以留在原团队已有的存储里，同时给分析人员一个统一的 SQL 入口；项目 topics 中列出的湖仓格式和 Hadoop 风格存储都有对应连接器。它还提供 JDBC，现有 SQL 工具和看板可以直接接入，不必自写客户端。

代价在于 Trino 是需要自行运行和集成的系统设施，而不是引入即用的库。仓库里主要看到的是引擎和插件生态；部署路径走用户手册和下载页，而不是一条安装命令。计算资源需要自己规划，查询性能也取决于各连接器能否把计算下推到源端。连接器行为并不一致，同一条查询在一个源上很便宜，在另一个源上可能很贵。部分连接器是仓库之外的第三方项目。

谁值得试

适合已经有数据湖或多个分析存储、需要跨源 SQL 的团队，尤其是仓库整合推进缓慢或阻力很大的场景。平台团队为多个分析小组评估统一查询层，是最典型的好例子：引擎成为统一访问点，各数据源仍由原团队负责。

不适合需要低延迟点查或事务写入的应用，也不适合只有一个数据集、单个数据库就能回答所有查询的情况。如果手头没有现成的分布式存储或连接器支持的数据源，搭建成本很难换来相应收益。规划之前，请先确认你需要的每个数据源都有可用连接器。

使用条件与边界

从源码构建需要 macOS 或 Linux、JDK 25.0.1+ 和 Docker；README 特别说明在 Apple Silicon 上，构建 Web UI 用的部分 npm 包仅支持 x86，因此需要安装 Rosetta 2。首次 Maven 构建会下载全部依赖，耗时较长，之后重建会快一些。文档中的构建命令默认跳过完整的测试套件，这些测试在 CI 中运行；README 建议本地只跑改动相关区域的测试，这对提交补丁的人尤其重要。

开发环境下，官方路径是使用带 TPCH 连接器的 TpchQueryRunner 测试服务器，或者通过 IDE 运行配置启动完整的 DevelopmentServer，再用仓库自带的 CLI 连接。部署和最终用户文档见用户手册，版本发布见下载页，构建与发布流程见开发指南。日常维护主要是插件和 catalog 配置：启用哪些连接器、各自的属性，以及各数据源如何支持下推。升级时，服务端与连接器的版本对齐需要留意。

HotRepo 点评

HotRepo 目前只有一个有日期的观察：2026-10-27 当天仓库显示 13,374 星、日增 6 星，进入日榜。单一的日榜样本不足以判断关注度是在上升、回落还是平稳，因此趋势尚无法评判，既不宜当作利好，也不宜当作劝退。就项目本身而言，决策取决于你是否真的需要跨源 SQL，并且愿意为此运维一套分布式引擎和它的连接器；在正式投入前，先查阅你最看重的数据源对应的连接器文档。