1

我目前的项目存在架构困境，即近乎实时地处理大量数据。因此，这是当前架构的示意图：

在此处输入图像描述

这是对我的想法的解释，这使我想到了那张照片：

当 API 网关接收到请求时，它会被放入流中（这是因为我的应用程序的性质——“即发即弃）”这就是我得出这个结论的方式。输入数据根据特定请求在分片中分离属性保证我正确的顺序。

然后我有一个 lambda，它负责验证输入和异常检测。因此，它是一种抽象，可以为下一层（数据丰富）保持数据清洁。所以这个 lambda 将数据发送到 kinesis firehose，因为它可以备份“原始”数据（我绝对想要拥有的东西）并附加一个转换 lambda 来进行丰富 - 所以我不在乎保存数据在 S3 中，它将开箱即用。所以一切都很好，直到我需要保留接收数据的顺序（丰富器正在进行会话化），这在 firehose 中丢失了，因为那里没有数据分离，因为它在 kinesis 流中。

所以我唯一能想到的就是 - 在第一个 lambda 中移动 sissionization，这将打破我的抽象，因为它会开始关心数据丰富，而更大的缺点是备份数据将包含丰富的数据，这也在打破架构。而这一切之所以发生，是因为消防软管中缺少分片概念。

那么有人能在不丢失 aws 为我们提供的开箱即用功能的情况下想出解决该问题的方法吗？

4

1 回答 1

0

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

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

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

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

如果会话在业务级别不是事务性的，则会话的定义是过度或未指定的。如果是这种情况，您将退出流处理业务并进入批处理，您需要将状态扩展到可能的同时交错会话的数量及其最大持续时间 - 查询整个事件语料库以将会话括起来希望可以管理的持续时间。

于 2017-05-19T15:36:21.933 回答