Parquet vs Cassandra使用Spark和DataFrames

Question

我已陷入这种困境，我无法选择哪种解决方案对我更好。我有一个非常大的表（几个100GB）和几个较小的（几个GB）。为了在Spark中创建我的数据管道并使用spark ML，我需要加入这些表并执行几个GroupBy（聚合）操作。那些操作对我来说真的很慢，所以我选择了这两个中的一个：

• 使用Cassandra并使用索引来加速GoupBy操作。
• 根据数据布局使用Parquet和Partitioning。

我可以说Parquet分区的工作速度更快，可扩展性更高，而且Cassandra使用的内存开销更少。所以问题是：

如果开发人员推断并了解数据布局及其使用方式，那么使用Parquet会不会更好，因为您可以更好地控制它？我为什么要为Cassandra带来的开销付出代价？

Answer 1

Cassandra也是分析用例的一个很好的解决方案，但另一方面。在建模键空间之前，您必须知道如何读取数据。您也可以使用where和range查询，但是以严格限制的方式。有时你会讨厌这个限制，但这些限制有理由。 Cassandra不像Mysql。在MySQL中，性能不是关键特性。它更多的是灵活性和一致性。 Cassandra是一个高性能的读/写数据库。写作比阅读更好。 Cassandra还具有线性可扩展性。

好的，关于你的用例：Parquet是你的最佳选择。这就是为什么：

• 您可以在非常大且未拆分的数据集上聚合原始数据
• 您的Spark ML工作听起来像是预定的，而不是长期工作。 （每周一次，一天？）

这更适合Parquet的使用案例。 Parquet是ad-hoc分析，过滤分析的解决方案。如果您需要每月运行一次或两次查询，Parquet非常好。如果营销人员想知道一件事并且响应时间不那么重要，Parquet也是一个很好的解决方案。简单和简短：

• 如果您知道查询，请使用Cassandra。
• 如果查询将用于日常业务，请使用Cassandra
• 如果Realtime很重要，请使用Cassandra（我谈论最多30秒的延迟，来自客户做出行动，我可以在我的仪表板中看到结果）
• 如果Realtime无关紧要，请使用Parquet
• 如果查询不会每天执行100次，请使用Parquet。
• 如果要进行批处理，请使用Parquet

Answer 2

这取决于你的用例。 Cassandra使用（有限的）伪SQL访问您的数据变得更容易（也在Spark之外）。这使其非常适合在其上构建在线应用程序（例如，在UI中显示数据）。

如果您必须处理更新，Cassandra也会更容易，这不仅会在您的数据管道中提取新数据（例如日志），而且您还必须关注更新（例如，系统必须处理数据更正） ）

如果您的用例是使用Spark进行分析（并且您不关心上述主题），那么使用Parquet / HDFS应该是可行且相当便宜的 - 如您所述。使用HDFS，您还可以使用Spark实现数据本地化，如果您正在读取大量数据，则可能具有分析性Spark应用程序更快的优势。