实时数据处理体系结构

Question

我正在为下面的内容构建架构，并希望了解其他人对它的看法。

假设系统正在运行一些非平凡的算法(所以它不是简单的某物之和等等)。在每个用户上收集的数据。一些用户将拥有10行数据，有些用户将拥有数万行数据。随着时间的推移，数据将是用户地理位置。用户数量将超过1,000万-1亿，而且许多用户的数据每天都在输入，有些用户可能每分钟都会收到。

每隔一段时间(1/5/15分钟，基本上是尽快)，我想对每个用户的数据运行一个非平凡的算法，它会吐出几个数字，然后再报告出来。

一种建模方法是将数据存储在NoSQL db中，并在Akka集群上处理每个用户的数据。对移民局有什么建议吗？

这里的用户数据基本上是一个附加日志，一旦添加，数据就不会改变--但是它一直在增长，一些用户比其他用户拥有更多的数据。为了处理每个用户的数据，所有的数据都需要加载到内存中的某个地方，所以最好的情况是，所有数据都在内存中，并在一分钟的间隔内重新处理--缺点是，我需要to的RAM才能做到这一点，如果内存中的服务器出现故障，那么所有的数据都需要重新加载，这需要一段时间。

Answer 1

我目前正在处理一个类似的问题。我的系统大约有3500万条“记录”，每条记录中大约有4-5个值。我目前能够处理他们(一个非平凡的处理)约20个小时，在一个中型桌面(6核心AMD，旋转盘)。

为了存储，我尝试了几乎所有的东西，从Postgres开始，搬到了Hypertable的Cassandra。然后我意识到，我的用例只涉及按顺序重放数据，而不需要在写或读中随机访问。我找到了纪事，这正是我要找的。由于我没有足够的内存来存储所有的数据，所以我需要从磁盘上读取所有的数据，而使用“纪事报”，我的记录达到了每秒800.000条左右。

我不知道“纪事”的当前版本，但我使用的版本创建了一个“索引”文件，我发现这个文件是多余的。从那时起，我使用了自己的代码，基本上是没有索引文件的纪事(内存映射文件)，这使我在大约30 MB/秒的旋转磁盘上的记录达到1.300.000个/秒。

存储的另一点是压缩数据。这会带来很大的不同。我为我的数据编写了一个对齐的压缩(当我将一个值压缩为3位时，它实际上只写了3位，而不是8位)。我发现使用字节边界压缩会比(对我的数据)差30%-40%。例如，我预计来自一个人的GPS数据不会迅速变化，因此每个连续的数据点可能只需要几个比特。

因为我不像您那样需要实时处理，所以我的主要目标是在一台(或至少几台)机器上尽可能地提高处理性能。我试了Akka，Hadoop (这只是一个皮塔，不推荐它)，周围玩的Apache火花。我的问题是，其中大多数都是在一个大型集群中运行的，而且在一台机器上没有我想要的那么快(或者至少，我无法使它们达到我想要的速度)。

最后，我自己实现了一个处理链，就像我说的那样，使用I/O处理大约500.000条记录/秒，因为我的数据很容易被分割成独立的碎片，所以我可以不需要协调节点就可以扩展。

如果您有更多的数据，并且需要实时处理，您可能需要比我更多的扩展，那么个人的性能可能不是最重要的部分。

不管怎么说，我希望这能帮上忙。