我正在考虑实施Lambda架构以处理由多个设备传输的事件。 在大多数情况下（平均值等），它似乎符合我的要求。但是，我很难尝试为特定用例建模。简而言之......
每个设备都有 device_id 。每台设备每秒发出1个事件。每个活动的 event_id 范围为{0 - > 10}。
event_id为0表示START＆amp; event_id为10表示END
START＆amp;之间的所有事件END应分组为一个组（event_group）。 这将产生event_groups的元组，即 {0,2,2,2,5,10} ，（0,4,2,7，... 5,10），（0,10） 这个（event_group）可能很小，即10分钟或非常大，比如3小时。
根据Lambda Architecture，每个设备传输的这些事件都是我的主数据集＆＃34;。 目前，这些事件被发送到HDFS＆amp;风暴使用卡夫卡（加缪，卡夫卡喷口）。
在Streaming进程中，我按照device_id进行分组，并根据每次event_id = 0到达时生成的密钥，使用Redis在内存中维护一组传入事件。 问题在于HDFS。假设我每小时保存一个包含所有传入事件的文件。有没有办法区分这些（group_events）？
使用Hive我可以以相同的方式对元组进行分组。但是，每个文件也会包含＆＃34;破坏＆＃34; event_groups
所以我需要将它们基于device_id合并到（0,2,2,3,4,3,5,6,7,8,10）（多个文件）
Lambda架构是否适合这种情况？或者流媒体流程应该是唯一的事实来源？即写入hbase，hdfs本身不会影响整体延迟。
答案 0 :(得分：1)
据我了解您的流程，我没有看到任何问题，因为Lambda Architecure的原则是在批处理模式下定期重新处理所有数据。 （顺便说一下，不是所有数据，而是时间范围，通常大于速度层窗口）
如果您为批处理模式选择足够大的时间窗口（假设您的聚合窗口为+3小时，为了包括最长的事件组），您的地图缩减程序将能够计算您的所有事件组所需的聚合窗口，无论文件区分事件（Hadoop shuffle magic！）
底层文件不是问题的一部分，但用于选择要处理的数据的时间窗口是。