实时数据处理架构
Real Time data processing architecture
我正在考虑构建以下架构，并想看看其他人对此有何看法。
假设系统运行对收集到的每个用户的数据使用一些非平凡的算法（因此它不仅仅是某些东西的总和等）。有些用户会有 10 行数据，有些会有几万行。随着时间的推移，数据将是用户的地理位置。将有超过 10-100M 的用户，并且许多用户的数据每天都在传入，对于某些用户来说可能是每分钟。
每隔一段时间（1/5/15 分钟，基本上尽快），我想 运行 每个用户数据的非平凡算法，它会吐出几个数字然后会报告出来。
一种建模方法是存储在 NoSQL 数据库中并在 Akka 集群上处理每个用户数据。对数据库有什么建议吗？
这里的用户数据基本上是一个追加日志，一旦添加，数据就不会改变——但它一直在增长，一些用户拥有的数据比其他用户多得多。为了处理每个用户的数据，所有数据都需要加载到内存中的某个地方，所以最好的情况是所有数据都在内存中并每隔一分钟重新处理一次——缺点是我需要 TB 的数据RAM 来执行此操作，如果内存服务器出现故障，所有数据都需要重新加载，这需要一段时间。
我目前正在处理类似的问题。我的系统大约有 3500 万 "records"，每条记录中大约有 4-5 个值。我目前能够在单个中端台式机（6 核 AMD，带旋转盘片）上大约 20 小时内处理它们（非常重要的处理）。
对于存储，我几乎尝试了一切，从 Postgres 开始，转移到 Cassandra，Hypertable。然后我意识到，我的用例只涉及按顺序重放数据，不需要在写入或读取中进行随机访问。我找到了 Chronicle，这正是我要找的。由于我没有足够的 RAM 来存储所有数据，我需要从磁盘读取所有内容，使用 Chronicle，我每秒可以读取大约 800.000 条记录。
我不知道 Chronicle 的当前版本，但我使用的版本创建了一个 "index" 文件，我发现该文件是多余的。从那时起，我使用自己的代码，基本上是没有索引文件的 Chronicle（内存映射文件），这让我在我相当平均的 30 MB/sec 旋转磁盘上达到 1.300.000 条记录/秒。
存储的另一点是压缩数据。它制造了巨大的差异。我为我的数据编写了一个 bit 对齐的压缩（当我将一个值压缩为 3 位时，它实际上只写入 3 位，而不是 8 位）。我发现使用字节边界进行压缩要差 30-40%（在我的数据上）。例如，我希望来自一个人的 GPS 数据不会快速变化，因此每个连续的数据点可能只需要几位。
因为我不需要像你一样的实时处理，所以我的主要 objective 是在一台（或至少几台）机器上尽可能多的处理性能。我尝试了 Akka，Hadoop（这只是一个 PITA，不会推荐它），围绕着 Apache Spark 进行了游戏。我的问题是，其中大部分在大型集群中被设为 运行，并且在单台机器上没有我想要的那么快（或者至少，我不能让它们像我想要的那样快） .
我最终自己实现了一个处理链，正如我所说，每秒处理约 500.000 条记录I/O。由于我的数据很容易分成独立的碎片，我可以横向扩展而无需协调节点。
如果你有更多的数据，并且需要实时处理，你可能需要比我做更多的横向扩展，然后个人性能可能不是最重要的部分。
无论如何，我希望这对您有所帮助。
我正在考虑构建以下架构，并想看看其他人对此有何看法。
假设系统运行对收集到的每个用户的数据使用一些非平凡的算法（因此它不仅仅是某些东西的总和等）。有些用户会有 10 行数据，有些会有几万行。随着时间的推移，数据将是用户的地理位置。将有超过 10-100M 的用户，并且许多用户的数据每天都在传入，对于某些用户来说可能是每分钟。
每隔一段时间（1/5/15 分钟，基本上尽快），我想 运行 每个用户数据的非平凡算法，它会吐出几个数字然后会报告出来。
一种建模方法是存储在 NoSQL 数据库中并在 Akka 集群上处理每个用户数据。对数据库有什么建议吗？
这里的用户数据基本上是一个追加日志，一旦添加，数据就不会改变——但它一直在增长，一些用户拥有的数据比其他用户多得多。为了处理每个用户的数据，所有数据都需要加载到内存中的某个地方，所以最好的情况是所有数据都在内存中并每隔一分钟重新处理一次——缺点是我需要 TB 的数据RAM 来执行此操作，如果内存服务器出现故障，所有数据都需要重新加载，这需要一段时间。
我目前正在处理类似的问题。我的系统大约有 3500 万 "records"，每条记录中大约有 4-5 个值。我目前能够在单个中端台式机（6 核 AMD，带旋转盘片）上大约 20 小时内处理它们（非常重要的处理）。
对于存储，我几乎尝试了一切，从 Postgres 开始，转移到 Cassandra，Hypertable。然后我意识到，我的用例只涉及按顺序重放数据，不需要在写入或读取中进行随机访问。我找到了 Chronicle，这正是我要找的。由于我没有足够的 RAM 来存储所有数据，我需要从磁盘读取所有内容，使用 Chronicle，我每秒可以读取大约 800.000 条记录。
我不知道 Chronicle 的当前版本，但我使用的版本创建了一个 "index" 文件，我发现该文件是多余的。从那时起，我使用自己的代码，基本上是没有索引文件的 Chronicle（内存映射文件），这让我在我相当平均的 30 MB/sec 旋转磁盘上达到 1.300.000 条记录/秒。
存储的另一点是压缩数据。它制造了巨大的差异。我为我的数据编写了一个 bit 对齐的压缩（当我将一个值压缩为 3 位时，它实际上只写入 3 位，而不是 8 位）。我发现使用字节边界进行压缩要差 30-40%（在我的数据上）。例如，我希望来自一个人的 GPS 数据不会快速变化，因此每个连续的数据点可能只需要几位。
因为我不需要像你一样的实时处理，所以我的主要 objective 是在一台（或至少几台）机器上尽可能多的处理性能。我尝试了 Akka，Hadoop（这只是一个 PITA，不会推荐它），围绕着 Apache Spark 进行了游戏。我的问题是，其中大部分在大型集群中被设为 运行，并且在单台机器上没有我想要的那么快（或者至少，我不能让它们像我想要的那样快） .
我最终自己实现了一个处理链，正如我所说，每秒处理约 500.000 条记录I/O。由于我的数据很容易分成独立的碎片，我可以横向扩展而无需协调节点。
如果你有更多的数据，并且需要实时处理，你可能需要比我做更多的横向扩展，然后个人性能可能不是最重要的部分。
无论如何，我希望这对您有所帮助。