繁体   English   中英

使用kinesis流和firehose对流数据进行排序

[英]Ordering of streaming data with kinesis stream and firehose

我目前的项目存在架构困境,即近实时处理大量数据。 所以这是当前架构的图表:

在此输入图像描述

以下是我的想法的解释,这让我想到了这张照片:

当API网关收到一个请求时,它被放入流中(这是因为我的应用程序的性质 - “火与忘记”) 这就是我得出的结论 。输入数据根据特定请求在分片中分离属性,保证我正确的顺序。

然后我有一个lambda,它关心验证输入和异常检测。 因此,它是一种抽象,可以保持下一层数据的清洁 - 数据丰富。 所以这个lambda将数据发送到kinesis firehose,因为它可以备份“原始”数据(我绝对想要的东西),还附加一个转换lambda,它将进行浓缩 - 所以我不关心保存数据在S3中,它将开箱即用。 所以一切都很好,直到我需要保存的接收数据排序(富集程序正在进行会话化),这在firehose中丢失,因为在kinesis流中没有数据分离。

所以我唯一能想到的就是 - 在第一个lambda中移动sissionization,这将破坏我的抽象,因为它将开始关注数据丰富,更大的缺点是备份数据将丰富其中的数据,也打破了架构。 所有这一切都在发生,因为在消防中缺少分片概念。

那么有人可以想到解决这个问题而不会失去aws为我们提供的开箱即用功能吗?

我认为会话化和数据丰富是两种不同的抽象,需要在lambda之间进行分割。

会话是受目的或任务限制的时间限制,严格排序的事件流。 您只在第一个lambda阶段(来自kinesis流分类)拥有该信息,并且应该在源处标记具有会话上下文的流并且可以限制会话。

如果在备份中存储会话信息是一个问题,则可能是会话的定义没有很好地指定或者需要重新定义。 如果会话将来重新进行,则可以忽略已经计算的会话数据,只要有足够的详细信息记录了足够的额外数据以告知可能会话的不可预测的未来概念。

提供业务上下文(也称为外部可识别数据)的附加富集应在先前记录的边界内以事务方式处理会话。

如果会话在业务级别不是事务性的,则会话的定义超出或低于指定。 如果是这种情况,您就不在流处理业务和批处理中,您需要将状态扩展到可能的同时交错会话的数量及其最大持续时间 - 查询整个事件语料库以支持会话希望可以控制的持续时间。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM