我目前正在调查如何存储和分析基于每行最多1000列的基于时间的丰富数据。目前，Cassandra与Datastax Enterprise提供的Solr，Hadoop或Spark一起，似乎满足了我对粗糙度的要求。但是魔鬼在细节上。
在1000列中，大约60个用于实时查询（网络前端，用户发送表单并期望快速响应）。这些查询或多或少是GROUPBY语句，其中计算数量或出现次数。
由于Cassandra本身没有提供所需的分析能力（没有GROUPBY），我留下了这些替代方案：
第一种方法看起来很麻烦并且容易出错...... Solr确实有一些分析功能，但是没有多字段分组我会遇到枢轴问题。我不知道这是否是一个好的或高效的方法...最后但并非最不重要的是有Hadoop和Spark，先前已知不是最好的实时查询，后来很新，也许没有生产就绪。< / p>
那么走哪条路？这里没有一个人，但在我走一条路之前，我想得到一些反馈。也许我想复杂或者我的期望太高了：S
提前致谢，
阿尔曼
答案 0 :(得分：3)
在我现在工作的地方，我们有一套类似的技术要求，解决方案是Cassandra-Solr-Spark，完全按照这个顺序。
因此，如果查询可以被覆盖＆＃34;通过Cassandra指数 - 好的，如果不是 - 它被Solr覆盖。用于测试＆amp;更少查询--Spark（Scala，没有SparkSQL，因为它的旧版本 - 它是一个银行，一切都应该经过测试和成熟，从干邑到软件，argh）。
一般来说，我同意这个解决方案，但有时我觉得一些客户的请求根本不应该被认真对待，从而避免了我们的大量奇怪查询：）
答案 1 :(得分：1)
我会推荐Spark，如果你在list of companies using it获取一些战利品，你就可以使用亚马逊，eBay和Yahoo！这样的名字。此外，正如您在评论中所指出的，它正在成为一种成熟的工具。
你已经反对Cassandra和Solr，所以我将重点解释为什么Hadoop MapReduce不能像Spark那样做实时查询。
Hadoop和 MapReduce 旨在利用硬盘，假设大数据IO可以忽略不计。因此，数据被读取和写入至少两次 - 在map阶段和reduce阶段。这允许您从失败中恢复，因为部分结果是安全的，但是在针对实时查询时，您不希望这样。
Spark 不仅旨在解决MapReduce的缺点，还专注于交互式数据分析，这正是您想要的。这个目标主要通过利用RAM 来实现，结果令人惊讶。 Spark作业通常比MapReduce等效强<10>快。
唯一需要注意的是你拥有的记忆量。很可能您的数据可能会在RAM中成为壮举，您可以提供，或者您可以依靠采样。通常在交互式处理数据时，没有必要使用MapReduce，在您的情况下似乎也是如此。