Lambda 架构建模问题

Question

我正在考虑实施 Lambda 架构以处理由多个设备传输的事件。 在大多数情况下（平均值等），它似乎符合我的要求。但是，我一直在尝试为特定用例建模。总之……

每个设备都有一个device_id。每个设备每秒发出 1 个事件。每个事件都有一个 event_id，范围为 {0-->10}。

event_id 为 0 表示开始，event_id 为 10 表示结束

START 和 END 之间的所有事件应归为一个组 (event_group)。 这将产生 event_groups 的元组，即 {0,2,2,2,5,10}, (0,4,2,7,...5,10), (0,10) 这个 (event_group) 可能很小，即 10 分钟或非常大，例如 3 小时。

根据 Lambda 架构，每台设备传输的这些事件都是我的“主数据集”。 目前，事件使用 Kafka（Camus，Kafka Spout）发送到 HDFS 和 Storm。

在 Streaming 过程中，我按 device_id 分组，并使用 Redis 在内存中维护一组传入事件，基于每次 event_id=0 到达时生成的键。 问题在于 HDFS。假设我每小时保存一个包含所有传入事件的文件。有没有办法区分这些（group_events）？

使用 Hive，我可以以相同的方式对元组进行分组。但是，每个文件也将包含“损坏”的 event_groups

• (0,2,2,3) 先前的计算（文件）
• (4,3,) 先前的计算（文件）
• (5,6,7,8,10) 当前计算（文件）

这样我需要根据 device_id 将它们合并到 (0,2,2,3,4,3,5,6,7,8,10)（多个文件）中

Lambda 架构是否适合这种情况？还是流式处理应该是唯一的事实来源？ IE。写入 hbase，hdfs 本身不会影响整体延迟。

Answer 1

据我了解您的流程，我认为没有任何问题，因为 Lambda 架构的原则是以批处理模式定期重新处理您的所有数据。 （顺便说一下，不是你所有的数据，而是一个时间范围，通常比速度层窗口大）

如果您为批处理模式选择了足够大的时间窗口（假设您的聚合窗口 + 3 小时，以便包括最长的事件组），您的 map reduce 程序将能够计算您的所有事件组所需的聚合窗口，无论存储不同事件的文件是什么（Hadoop shuffle magic！）

底层文件不是问题的一部分，而是用于选择要处理的数据的时间窗口。