将 Spark 用于具有关系非分片数据存储（例如 MySQL）的描述性分析是不是有意义？

Posted 2023-04-18

【中文标题】将 Spark 用于具有关系非分片数据存储（例如 MySQL）的描述性分析是不是有意义？

【英文标题】：Does it makes sense to use Spark for descriptive analytics with a relational non-sharded data store (e.g. MySQL)?将 Spark 用于具有关系非分片数据存储（例如 MySQL）的描述性分析是否有意义？

【发布时间】：2018-03-07 04:58:11

【问题描述】：

正如标题所说，我们的数据存在于托管的 mysql 数据库中，没有分片或集群。

Spark 的架构优势（内存中并行处理、跨多个数据集连接的能力）是否适用于这种情况，或者 MySQL 从 IO 的角度来看是否成为瓶颈，从而使 Spark 的优势无效？

【参考方案1】：

听起来普通的旧 SQL 在您的情况下会更好地工作 - 除非您计划迁移到更多样化的后端和/或迁移出 MySQL

【讨论】：

我故意让我的问题简短而集中，但是是的，未来我们不仅会使用其他后端（例如对象存储、NoSQL），还会应用更高级的分析方法（流式传输、预测分析、分解） .所以 Spark 被认为是对未来的投资，我的问题是要确定我们将不得不通过依赖单一平台支付短期费用的代价有多大。当然，当规模成为问题时，人们总是可以构建多个堆栈或迁移到不同的堆栈。但这还有其他复杂的含义（资金、敏捷性等）

开销取决于您将多少数据推送到 Spark 本身与您在对 MySQL 的查询中投入多少。您在查询中输入的逻辑越多，您对 spark 的使用就越少。同样，除非您在不久的将来有具体计划，否则这听起来像是在浪费精力

了解，但根据我的理解，无论如何，MySQL 中的分析查询和连接功能都受到一定限制，因此大多数处理逻辑（聚合）将存在于 Spark 中，而 MySQL 仅提供数据。类似于将 csv 文件从 S3 加载到 Spark 中，S3 也不执行任何处理逻辑。所以我的理解是 I/O 将由 MySQL 决定/影响，但是一旦数据在 Spark 集群中加载到内存中，查询性能将完全独立于 MySQL。

"o 我的理解是 I/O 将由 MySQL 确定/影响，但一旦数据已加载到 Spark 集群的内存中，查询性能将完全独立于 MySQL。" - 完全正确