1

我正在考虑实施 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 架构是否适合这种情况？还是流式处理应该是唯一的事实来源？即写入 hbase，hdfs 本身不会影响整体延迟。

4

1 回答 1

1

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

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

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

于 2014-09-30T10:26:20.287 回答