我陷入了一个两难的境地，我无法选择哪种解决方案对我来说更好。我有一个非常大的表（几个100GB）和几个更小的表（几个GB）。为了在Spark中创建我的数据管道并使用SparkML我需要连接这些表并执行几个GroupBy（聚合）操作。这些操作对我来说真的很慢，所以我选择了以下两个操作之一：
我可以说Parquet分区的工作速度更快，可扩展性更强，内存开销更小。所以问题是这样的：
如果开发人员推断并理解数据布局和它将被使用的方式，那么仅仅使用Parquet不是更好吗？因为你将对它有更多的控制权？为什么我要为Cassandra造成的开销付出代价？
Cassandra对于分析用例也是一个很好的解决方案，但在另一方面。在对键空间进行建模之前，您必须知道需要如何读取数据。您也可以使用where和range查询，但以严格限制的方式。有时您会讨厌这种限制，但这些限制是有原因的。Cassandra不像Mysql。在MySQL中，性能不是关键特性。它更多的是灵活性和一致性。Cassandra是一个高性能的写/读数据库。写比读更好。Cassandra还具有线性可扩展性。
好吧，关于你的用例：Parquet对你来说是更好的选择。这就是为什么：
这更适合Parquet的用例。Parquet是一个临时分析、过滤分析的解决方案。如果您需要每月运行1到2次查询，Parquet非常好。如果营销人员想知道一件事，响应时间并不那么重要，Parquet也是一个很好的解决方案。简单而简短：
>
如果实时很重要，请使用Cassandra（我说最多30秒延迟，从客户执行操作，我可以在仪表板中看到结果）
如果实时不重要，请使用Parquet
这取决于您的使用情况。Cassandra使使用（有限的）伪SQL访问您的数据变得更加容易（也在Spark之外）。这使得它非常适合在它的顶部构建在线应用程序（例如，在UI中显示数据）。
此外，如果您必须处理更新，Cassandra会更容易，这不仅是要在数据管道中摄取的新数据（例如日志），而且您还必须关心更新（例如系统必须处理数据的更正）
当你的用途是使用Spark进行分析时（你不关心上面提到的主题），使用Parquet/HDFS应该是可行的，而且便宜得多——正如你所说的。有了HDFS，你还可以用Spark实现数据局部性，如果你正在读取大块数据，你的分析Spark应用程序可能会更快。
