实时数据处理体系结构

Question

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

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

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

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

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

Answer 1

这只是一个(分布式的)任务，你可以做异步的。当用户的新数据出现时，将其添加到任务队列中。

检测以前的作业并防止重复工作(

)

当该用户的前一个作业仍然存在时，然后删除旧的作业并放置一个新的作业。或者将新数据添加到现有的数据中。取决于你想怎么处理这件事。

标度

然后，您可以由处理数据和计算的员工进行缩放。在这里，您可以有点聪明:尝试优化您为用户计算数据的时刻和他们想要看到的时刻。

优化历史结果

最好的方法是存储中间结果，这样就不必一次又一次地处理用户的所有数据。取决于您的算法，这可能是最好的优化，因为随着用户获得更多的数据，这些任务在几个月/几年后变得越来越大。

因为工人们总是很忙(可以自动缩放)，并且不断地做同样的工作，所以您可以非常努力地优化这一点。此外，它还减少了工作量的高峰数量，从而降低了容量成本。

平台选择

哪一个特定的数据库/平台是最好的，是不可回答的。这在很大程度上取决于实际数据以及读取和写入的数量以及其他因素。我怀疑余额将有大量的数据在休息，所以只是存储。然后，当用户开始活动并开始交付数据时，您会唤醒他，让他的数据准备就绪，进程就可以开始工作了。

因为您期望很快就会有一个新的请求，所以如果您想要的话，可以将其保存在内存中，所以在下一个请求出现时可以继续。测试将表明这是否真的需要。在您的系统中，为用户加载几个地理点并不是最困难的工作，并且将它们保存在分布式内存中一分钟可能会更昂贵。