0

问题如下。我们实时收集一些数据，比如说每秒 100 个条目。我们希望有实时报告。报告应按小时显示数据。我们要做的就是创建一些传入数据的总和并进行一些智能索引，以便我们可以轻松地提供查询，例如“给我 value2 for featureA = x, and featureB = y, for 2012-01-01 09:00 - 10:00"

为了避免过多的 I/O 操作，我们在内存中聚合数据（这意味着我们将它们相加），然后将它们刷新到数据库中。假设它每 10 秒左右发生一次，这对于我们的实时报告来说是可以接受的延迟。

所以基本上，用 SQL 术语来说，我们最终会得到 20 个（或更多）这样的表（好吧，我们可以通过组合 sum 来减少它们，但这并没有太大区别）：

  1. 时间、特征A、特征B、特征C、值1、值2、值3
  2. 时间、特征A、特征D、值4、值5
  3. 时间、特征C、特征E、值6、值7
  4. 等等

（我并不是说解决方案必须是 SQL，我只是为了解释手头的问题。） Time 列是时间戳（具有小时精度），Feature 列是系统实体的一些 id，值是整数值（算）。

所以现在问题来了。由于数据的本质，即使我们聚合它们，这些聚合表仍然有（太多）插入。这是因为一些数据是稀疏的，这意味着对于每 100 个条目，我们在某些聚合表中有 50 个条目。我知道我们可以通过升级硬件来继续前进，但我觉得我们可以通过更智能的存储机制做得更好。例如，我们可以使用 SQL 数据库，但我们不需要它的大部分功能（事务、连接等）。

因此，鉴于这种情况，我的问题如下。你们如何处理大流量的实时报告？谷歌以某种方式为网络分析做到了这一点，所以这毕竟是可能的。这里有什么秘密武器吗？我们对任何解决方案持开放态度——无论是 Hadoop & Co、NoSQL、集群还是其他任何解决方案。

4

1 回答 1

2

除了拆分收集和报告/分析的存储需求外，我们过去经常做的一件事是查看值发生重大变化的频率，以及如何使用数据。

不知道您的数据是什么样的，但报告和分析通常会寻找重要的模式。以容不下，反之亦然，尤其是振荡。现在，虽然收集“无限”数量的数据以防万一您想分析它可能是值得称赞的，但当您遇到实施的有限限制时，必须做出选择。

我在制造环境中做过这种事情。我们有两个层次的分析。一种用于控制粒度尽可能高的地方。然后随着过去数据的进一步增长，我们将其汇总以进行报告。

我遇到过你似乎不止几次的问题，虽然数据丢失令人遗憾，但关于它会花费多少的抱怨声要响亮得多。

所以我不会从简单的技术角度来看这个问题，而是从实际的商业角度来看。从企业认为自己能负担得起多少开始，看看你能为他们付出多少。

于 2012-09-18T15:29:55.887 回答