通过Trino写大数据是个好主意吗？

Question

我和我的团队正在创建一个新的大数据引擎，从 Kafka（和其他来源）读取大量数据，对数据执行一些操作，最后以 Iceberg 格式写入 S3 兼容存储（例如 MinIO）（所有这些都在阿帕奇火花）。从那里可以查询数据，例如通过外部服务使用 Trino。

我的同事提出了一个想法，即通过 Trino 写入所有数据（Spark -> Trino API -> Storage），因为如果我们必须切换，例如从 Iceberg 到 Hudi（例如功能或许可相关问题），我们可以轻松做到这一点（我猜您所要做的就是更改 Trino 连接器）。

我有点担心/怀疑，因为在我看来，Trino 更多地被宣传为“读取”解决方案（用于快速数据提取查询），而不完全是用于转换/写入数据。两个主要问题是：

1. 网上这种架构的资源/例子并不多，感觉每个人都直接加入 Spark + Iceberg（感觉这个解决方案几乎是设计来直接相互协作的），这可能会显着延长我们的开发时间（这非常有限）。
2. 性能，这是大数据解决方案中非常重要的因素。很难预测将 Trino 放在“写入端”后我们的性能会受到多大影响。

你们看到将 Trino 放在解决方案的“写入端”有什么真正的好处吗？

您会在自己的架构中采用类似的方法还是坚持使用 Spark 和 Iceberg 之间的标准、直接方法？

Answer 1

正如您所知，

trino

和

spark

都是查询引擎。

只能使用 Spark 作业中的

trino

写入

spark-jdbc

。 JDBC 连接（与许多其他数据库一样）对使用 JDBC 的允许连接数有限制。使用 jdbc 编写重型数据帧可能需要在 Spark 作业和 trino 引擎方面进行大量优化和调整。

而使用 Spark 提供的连接器或使用 Spark 引擎在大多数情况下不会达到这些限制，直到达到底层存储/数据库的限制。使用 Spark 引擎进行编写还为开发人员提供了使用分区、执行器核心和实例的灵活性，以获得所需的性能。

从标准化的角度来看，有人可能会说，使用

trino

作为SQL接口来交互所有底层数据库是标准的，因此当底层存储/数据库发生变化时，代码不需要改变，但对于spark-sql和/也可以这样说或数据帧或数据集 Spark API。

从现有存储更改为 Hudi 或 Cassandra（另一个数据库示例）仅需要一组特定于数据库的属性为

options

或

sparkConf

。