Cassandra + Solr/Hadoop/Spark - 选择正确的工具答案

【问题标题】：Cassandra + Solr/Hadoop/Spark - Choosing the right toolsCassandra + Solr/Hadoop/Spark - 选择正确的工具
【发布时间】：2014-05-09 19:54:24
【问题描述】：

我目前正在研究如何存储和分析基于时间的丰富数据，每行最多包含 1000 列。目前，Cassandra 以及 Datastax Enterprise 提供的 Solr、Hadoop 或 Spark 似乎可以满足我的粗略要求。但魔鬼在细节中。

在 1000 列中，大约 60 列用于类似实时的查询（网络前端、用户发送表单并期望快速响应）。这些查询或多或少是 GROUPBY 语句，其中计算了次数或出现次数。

由于 Cassandra 本身不提供所需的分析功能（没有 GROUPBY），我只剩下以下替代方案：

第一种方法看起来很麻烦并且容易出错……Solr 确实有一些分析功能，但没有多字段分组，我会被枢轴所困。我不知道这是一个好的还是高性能的方法……最后但并非最不重要的还有 Hadoop 和 Spark，之前的已知不是最好的实时查询，后来很新，可能还没有准备好生产。

那么走哪条路呢？这里没有万能的，但在我通过一种方式之前，我想得到一些反馈。也许我的想法很复杂，或者我的期望太高了：S

提前致谢，

阿曼

【问题讨论】：

您好，我只是想知道您最后是否使用了任何特殊策略，好吗？谢谢。
不幸的是，没有。部分原因是项目中途发生了变化……自从我在这里发帖以来，Solr 和 Spark 收到了许多更新。 Solr 方式工作正常，当索引完好无损时，这很难......另一方面，Spark 应该比 Hadoop 做得更好，但我没有时间检查它。

【解决方案1】：

我会推荐 Spark，如果你在 list of companies using it 上抢购一票，你会看到 Amazon、eBay 和 Yahoo! 之类的名字。此外，正如您在评论中指出的那样，它正在成为一个成熟的工具。

您已经提出反对 Cassandra 和 Solr 的论据，所以我将重点解释为什么 Hadoop MapReduce 在实时查询方面不如 Spark。

Hadoop 和 MapReduce 被设计为利用硬盘，假设大数据的 IO 可以忽略不计。因此，数据至少被读取和写入两次——在映射阶段和归约阶段。这使您可以从故障中恢复，因为部分结果是安全的，但在针对实时查询时这是不希望的。

Spark 不仅旨在修复 MapReduce 的缺点，它还专注于交互式数据分析，这正是您想要的。这个目标主要是通过利用 RAM 实现的，结果令人惊讶。 Spark 作业通常比 MapReduce 等效作业快 10-100 倍。

唯一需要注意的是您拥有的内存量。很可能您的数据可能会存储在 RAM 中，您可以提供 或者您可以依赖采样。通常在以交互方式处理数据时，实际上不需要使用 MapReduce，您的情况似乎就是这样。

【讨论】：

【解决方案2】：

在我现在工作的一个地方，我们有一组类似的技术要求，一个解决方案是 Cassandra-Solr-Spark，完全按照这个顺序。

因此，如果查询可以被 Cassandra 索引“覆盖”——很好，如果不是——它会被 Solr 覆盖。用于测试和不太频繁的查询 - Spark（Scala，由于它的旧版本没有 SparkSQL - 它是一家银行，一切都应该经过测试和成熟，从干邑白兰地到软件，啊）。

一般来说我同意这个解决方案，虽然有时我觉得一些客户的请求根本不应该被认真对待，从而使我们免于大量奇怪的查询:)

【讨论】：