Presto/Trino、StarRocks FE、Amazon Athena 和 SparkSQL 架构及联邦查询对比分析

1. 底层架构与联邦查询原理

• Presto/Trino：基于经典 MPP 架构，由一个**协调节点（Coordinator）和多个工作节点（Workers）**组成。查询提交到协调节点，生成执行计划并划分为许多任务（splits）分派给工作节点并行执行。Presto/Trino 本身不存储数据，采用“共享数据”架构，所有数据一般以文件形式存储在分布式文件系统或云存储上，工作节点无状态地远程读取数据。Presto 最初由 Facebook 于 2012 年开发并开源，针对大规模（数百 PB）HDFS/S3 等异构存储进行快速 SQL 查询；2019 年原作者创建了 Trino（原名 PrestoSQL）分支，专注云端和湖仓场景优化。

• StarRocks FE：StarRocks（原名 Apache Doris）采用 MPP 架构，节点分为**前端（FE）和后端（BE）/计算（CN）**两种。FE 负责元数据管理和查询规划，BE（或 CN）负责数据存储和执行查询。StarRocks 支持两种部署模式：共享无（Shared-Nothing）和共享存储（Shared-Data）。共享无模式下，数据预先加载到 BE 节点本地磁盘；共享存储模式下，数据直接保留在外部存储（如对象存储、HDFS）上，BE 作为计算节点（CN）执行查询。StarRocks 后端可通过多副本保障高可用。整体而言，StarRocks 不依赖外部组件、易水平扩展，可弹性增减节点。

• Amazon Athena：Athena 是 AWS 提供的完全托管型服务，本质上运行 Trino/Presto 引擎。用户无需搭建集群，Athena 自动弹性扩展计算资源。查询通过 Web 控制台或 JDBC/ODBC 提交，Athena 调用 Trino/Presto 协调者和工作者在底层处理查询。Athena 依赖 AWS Glue Data Catalog 存储元数据，可以直接查询 S3 上的多种数据格式（CSV、JSON、Parquet、ORC、Avro 等），并且支持 联邦查询：通过预置的 Glue 连接器，可在单个 SQL 中查询并关联 S3 以外的数据源。

• SparkSQL：作为 Apache Spark 的组件，SparkSQL 用于 SQL 查询，底层由 Spark 的 Driver（驱动程序）和多个 Executor（执行器）组成。Driver 类似协调者，负责解析 SQL、创建执行计划；Executors 在集群节点上并行执行任务，并可通过 Spark 的 RDD/DataFrame 分区机制读写数据。Spark 既可以访问 HDFS/S3 等分布式文件系统，也能通过 JDBC、Hive Metastore、Kafka、Cassandra、HBase 等多种连接器获取外部数据。SparkSQL 同样支持集群水平扩展（通过 YARN、Kubernetes 等），并可缓存中间数据以提升重用效率。

2. 查询优化方式

• Presto/Trino：采用基于规则和成本模型（Cost-Based Optimization, CBO）的优化器，根据表统计信息进行查询改写和查询计划选择。支持谓词下推和列裁剪：查询中过滤条件会尽量下推到数据源层面（如果连接器支持），列裁剪在读取列存储格式时只读取必要列。连接上常见的优化还包括连接重排序和多种连接策略（例如当表小于一定阈值时可广播哈希连接，否则使用分区哈希/排序合并连接）。资源组机制可用于控制并发和资源配额。指出，Presto/Trino 支持谓词下推和连接重排序，但在复杂大表连接时优化有限，需要人工提示或重写。

• StarRocks：拥有全新的 CBO 优化器（基于 Cascades 和 ORCA），支持子查询重写、CTE 重用、Lateral Join、连接重排、多种分布式连接策略选择等。优化过程包括列裁剪、谓词下推和推导全局运行时过滤器等。此外，StarRocks 自动利用物化视图加速查询，并可动态选择使用预聚合表。其执行引擎为全向量化 C++ 实现，配合多副本机制和数据布局加速读写。

• Amazon Athena：继承了 Trino/Presto 的优化机制，包括谓词下推、列裁剪、连接重排等。注意：Athena 的联邦连接器能力受所用连接器支持程度影响，对不支持下推的源，在大数据量过滤时可能效率低或超时。例如文档指出部分第三方连接器缺乏下推时，大数据量查询性能显著下降。

• SparkSQL：Spark 采用 Catalyst 优化器，对逻辑计划进行规则和成本优化。支持谓词下推（例如针对 JDBC 源、Parquet/ORC 文件等）和列裁剪，筛选条件尽量在数据源层面提前过滤。Spark 在联邦查询时一般通过 DataSource API 读取外部表，再进行 DataFrame 局部运算。连接策略方面，Spark 可自动选择广播哈希连接（小表）或大表的Shuffle连接（排序合并或哈希），用户也可通过 Hint 控制连接类型。Spark 另有动态分区剪裁、成本模型(CBO)等特性（部分需要配置开启）来提升多表连接性能。

3. 性能表现与适用数据量级

• Presto/Trino：设计用于低延迟的交互式分析，能够在几十到上百台集群上对 TB-PB 级数据并行查询。Facebook 的 Presto 集群每天处理约 1PB 数据，支持成千上万用户查询。它适合 OLAP 查询、复杂聚合和多表联查，对实时性要求较高的场景表现良好。但在极大规模或极复杂的查询下（如超大 join、深度子查询）性能和稳定性需要人工调优。

• StarRocks：专为实时 OLAP 和高并发而优化。其矢量化 C++ 执行引擎和局部副本机制，使单表扫描和聚合极为高效，适合毫秒级响应的用户分析场景。StarRocks 官方称在相同硬件下，其查询性能可比 Trino 快 3–10 倍。通常用于数十 TB 到 PB 级仓库数据的分析。对于仪表盘、用户画像等场景的查询，StarRocks 提供亚秒级响应。

• Amazon Athena：底层自动并行执行，理论上可对 PB 级 S3 数据进行查询。Athena 自动扩展计算资源，因此规模受限于 AWS 帐户默认配额和并行度。查询延迟取决于扫描数据量：小数据集可在数秒内返回，大规模查询可能要几十秒甚至几分钟。因计费按扫描量付费，查询复杂度与成本成正比。Athena 适合偶尔使用、快速查询，而非持续性高频实时场景。

• SparkSQL：设计为通用计算引擎，能够处理极大规模（PB 级）数据。SparkSQL 在批量 ETL、机器学习管道等场景中表现强劲，但单纯作为交互式查询引擎启动开销较大，初次查询延迟比 Presto/Athena 更高。Spark 的吞吐非常高，适合深度挖掘和长时间复杂查询任务，但对于毫秒级查询延迟要求较难满足。

4. 开源情况及社区活跃度

• Presto/Trino：均为开源项目。Presto 最初由 Facebook 开源，后在 2023 年演变为 Presto Software Foundation 下的 PrestoDB 项目；Trino 由原 PrestoSQL 团队于 2019 年分支并继续发展。两者均有活跃社区和企业支持（如 Starburst）。全球大公司（Facebook/Meta、Netflix、Airbnb、Atlassian、Nasdaq 等）投入使用并贡献代码。Trino/Presto 社区文档、会议较多，生态成熟。
• StarRocks FE：开源遵循 Apache 2.0 许可证。项目于 2020 年发布，社区发展迅速，尤其在中国厂商中获得广泛关注（百度、字节等）。虽然起步晚于 Spark/Presto，但拥有专门的论坛、Slack 群组和文档，社区活动逐年增加。
• Amazon Athena：非开源，完全由 AWS 管理。用户无法访问底层源代码，社区活跃度仅体现在 AWS 官方论坛和博客等文档层面。故社区贡献和定制能力有限。
• SparkSQL：作为 Apache Spark 的一部分，完全开源（Apache 许可证）。Spark 是数据处理领域最活跃的项目之一，拥有庞大社区、众多贡献者和生态合作伙伴。Spark 社区每年发布新版本，生态工具和库丰富（如 Spark MLlib、Spark Streaming 等）。

5. 多数据源连接能力（支持的主流源）

• Presto/Trino：内置丰富连接器，能直接访问多种数据源，包括 Hadoop/HDFS、Amazon S3、Hive Metastore、Kafka、Cassandra、MongoDB、HBase、MySQL、PostgreSQL、Amazon Redshift、SQL Server、Teradata 等。每个数据源对应一个 Catalog，可在单个查询中跨 Catalog 联合查询，实现真正的联邦查询。
• StarRocks FE：通过外部 Catalog 支持多种外部表。官方文档列举了 Iceberg、Hudi、Hive、Delta Lake、Paimon、Elasticsearch 等作为外部目录，同时支持任何通过 JDBC 连接的数据库（MySQL、PostgreSQL 等）。也可以在 SQL 中跨 Catalog 进行联查。目前支持的主要源包括 Hive 元数据仓库、关系型数据库和部分 NoSQL。
• Amazon Athena：主要针对 S3 数据，但借助联邦查询可接入其它源。AWS 提供多种预构建连接器：关系型（MySQL、PostgreSQL、Oracle、SQL Server、Amazon RDS、Redshift）、非关系（DynamoDB、DocumentDB、HBase）、消息/日志（Kafka、CloudWatch）、第三方云服务（Google BigQuery、Azure Data Lake）等。使用时需在 AWS Glue 中配置连接，并可能需要运行在 VPC 中。也可通过 Athena 直接查询兼容 Glue 的目录（如 Hive Metastore）。
• SparkSQL：支持最广泛的数据源。通过内置或外部 DataSource，Spark 可读取 HDFS/S3 上的多种格式（Parquet、ORC、JSON、CSV、Avro 等），连接 Hive Metastore 表，使用 JDBC 访问各类关系数据库；借助 Spark Connector 可访问 Cassandra、Redis、Elasticsearch、HBase、Kafka、Couchbase 等。Spark 生态中许多第三方库进一步拓展了支持的数据源，使其几乎能对接任何常见存储和消息系统。

6. 优势与局限

• Presto/Trino 优势：采用分离式架构（无存储层）易扩展，可在现有集群/云资源上部署，交互式查询延迟低，SQL 支持全面（ANSI SQL、窗口函数等），内置丰富连接器实现无数据复制的跨源分析。Presto 在大规模生产环境已得到广泛验证，能高效处理 PB 级数据量。资源组等功能可以对用户和查询进行精细限流。
  局限：协调节点本身是单点，尽管支持部署多个 coordinator，但复杂性增加。Java 内存密集型，对于超大查询可能需要进行中间结果落盘，否则易 OOM。缺少开箱即用的本地磁盘缓存（需借助 Alluxio 等）；内置安全认证等企业级特性相对有限。复杂查询优化依赖统计信息和手工调优。另外，Trino/Presto 本身只读，不支持数据写入 ACID 操作。

• StarRocks 优势：面向 OLAP 优化，高度矢量化的 C++ 执行引擎在单机上利用 CPU 的效率远超 JVM，能提供极低的查询延迟。自动使用物化视图和增量刷新，提高了重复查询的速度。支持列级高效压缩和索引、运行时过滤（runtime filter），适合多维分析场景。对于高并发、多用户访问，StarRocks 具有成熟的并发控制和本地副本保障；同时支持 “共享存储” 模式，可直接查询湖仓外部数据，无需将数据全量导入。
  局限：相比 Presto，外部数据源连接器数量仍少（主要围绕 Hive、关系库等），多源联邦能力还在持续扩展。虽然开源，但社区相对年轻，需要自行承担基础设施搭建和调优。对于需要频繁写入的场景，常用的是批量或流式加载，而非内部事务处理。对比专门的批处理框架，Spark 在通用性和可编程性上更强。

• Amazon Athena 优势：无服务器架构，用户无需维护任何集群或集群配置。开箱即用，只需在控制台定义表即可查询；自动弹性扩缩容，查询并行执行无需手动干预。与 AWS 生态深度集成（Glue、QuickSight 等），支持标准 SQL 访问广泛数据格式；联邦查询功能使得对非 S3 数据的访问也更容易。计费灵活（按扫描量付费或预留容量）。适合快速做临时查询、报表分析，无需前期集成成本。
  局限：运行成本按查询扫描 TB 计费（例如美国区约 $5/TB），对于大规模查询成本高昂。对数据量敏感：部分连接器缺少谓词下推时，大数据集上的查询可能超时或非常缓慢。查询延迟依赖 AWS 内部队列和资源调度，通常高于自建 Presto 集群。功能受限于 AWS 提供的服务更新速度，灵活性不及开源引擎。

• SparkSQL 优势：通用性最强，集成 SQL、批处理、流处理、机器学习等多种工作负载。可用 Scala/Python/Java/R 等多语言编写任务。Spark SQL 支持复杂查询、用户自定义函数和高阶分析操作（MLlib 等），生态丰富，可无缝嵌入数据管道。其 DataFrame 抽象和缓存机制使迭代计算高效。对于需要自定义数据处理逻辑或 ETL 的场景，Spark 无可替代。
  局限：启动和优化开销大，不适合低时延交互查询。需要管理和调整 Spark 作业（如分区数、内存设置等），对普通 BI 用户不够友好。相比纯粹的 SQL 引擎（如 Presto、StarRocks），单查询执行速度通常慢，且对实时查询或高度并发支持相对欠佳。

7. 成本控制与资源管理机制

• Presto/Trino：作为开源系统，成本主要来自底层计算集群（本地或云）和运营维护。通常运行在 YARN、Kubernetes 或独立集群上，可以利用云服务自动伸缩（如 AWS EMR、Google Cloud Dataproc）。Presto/Trino 支持 资源组（Resource Groups），可对查询进行队列管理、CPU/内存配额限制，并可设置查询最小工作节点数。在配置了多协调节点（disaggregated coordinators）后，系统对节点故障可更好容忍。若有外部缓存需求，可结合 Alluxio 等加速文件系统层面读取。

• StarRocks：支持前端、后端节点的弹性扩缩容，提供专门的扩缩 API 并可配合 Kubernetes 自动伸缩。共享数据表（非本地存储）部署下，后端节点更容易水平扩展；共享无表则需考虑数据重分布复杂度。StarRocks 自带查询缓存（物化视图）和本地页缓存，可降低重复扫描成本。系统通过多副本保障高可用：FE 节点可多副本部署，BE 节点通过数据副本保证节点故障时业务不中断。负载均衡上，可采用 MySQL 协议层面的均衡器或 StarRocks 提供的集群路由方案。

• Amazon Athena：完全 serverless，无需用户管理资源。AWS 自动提供弹性计算资源，用户仅需关注查询和成本。Athena 按扫描量计费（也可选择预留查询容量付费模式），无查询时不产生费用。AWS 管理底层集群的伸缩和高可用性，用户无需管理节点。可通过节约数据量（压缩、分区、列裁剪等）和合理使用查询来控制成本。查询缓存能力有限，但可以利用 Glue Catalog 与 Athena DataCatalog Cache 等减小元数据延迟。

• SparkSQL：Spark 支持动态资源分配（Dynamic Resource Allocation），可在工作负载变化时自动增减 Executor 数量。通常运行在 YARN、Kubernetes、Mesos 等资源管理器上，自动扩缩容需要额外配置（如 Spark on K8s 可配合 HPA）。Spark 内置缓存机制（persist）允许将中间 DataFrame/RDD 缓存于内存或磁盘，降低反复计算成本。可通过调优并行度（分区数）、内存管理策略和自适应查询执行（AQE）来控制性能。总体来说，Spark 的成本取决于集群规模和使用时长，适合批量长周期任务，弹性控制需要自行编排。

8. 适用场景与推荐使用方式

• Presto/Trino：推荐用于多数据源的交互式联邦分析。对业务分析师友好，可在单点发起复杂 SQL 联结不同源（如 Hive/HDFS、云仓库、关系型库等）的查询。适合 BI 仪表盘、报表和数据探索场景；可以部署在专用集群或云托管服务中。Trino 强调易扩展和企业功能（安全、资源控制），Presto 强调稳定性；两者功能相近，可根据团队社区偏好选择。

• StarRocks FE：适合高并发、低延迟的 OLAP 查询场景，如实时分析和仪表盘、用户画像、数仓加速等。可将核心热点数据加载到 StarRocks 作为分析引擎，同时通过外部表联邦查询湖仓中的数据。其优势在于对低响应时间敏感的应用（如用户侧交互查询）和复杂多维报表。新建数据仓库或扩充现有数据仓库时，可把StarRocks作为前端查询层。

• Amazon Athena：适合 无运维、按需查询 场景。当数据主要存储在 S3 上，且需要偶尔进行 ad hoc 查询（如日志分析、临时报表、数据探索）时最合适。用户无需管理集群，适用于轻量级或不频繁的查询任务。对于已有 AWS 架构且数据量大不愿搭建集群的团队，Athena 是快速启动的解决方案。对于持续复杂分析工作，可能更倾向自建 Presto/EMR 等节省成本。

• SparkSQL：适用于需要通用数据处理能力的场景。除了 SQL 查询，还需要批处理、ETL 流水线、机器学习、流处理等综合场景时使用 Spark 最合适。Spark 的编程模型灵活，适合数据工程和数据科学工作。对于单纯的 BI 查询，可在不介意启动延迟的前提下使用 Spark SQL；但当重点是 SQL 查询性能时，Spark 通常不如专用引擎。

推荐排序（基于湖仓和多源分析需求）：若要求零运维和云友好，优先考虑 Athena（S3 数据）；若要求低时延高并发交互，优先 StarRocks；若要求广泛数据源联邦，优先 Presto/Trino；如需复杂数据处理/机器学习，SparkSQL 更适合。