聚合时间序列数据并将结果存储到DynamoDB中的最佳大数据解决方案

Question

我正在研究不同的大数据解决方案，并没有找到明确的答案或文档，说明什么是解决我的大数据用例的最佳方法和框架/服务。

我的用例：

• I有一个数据生成程序，它将每天将大约12亿个事件发送到流。
• 需要将这些数据存储在某个数据湖/数据仓库中，进行聚合，然后加载到DynamoDB中，以便我们的服务在其业务逻辑中使用聚合数据。
• ，DynamoDB表需要每小时更新一次。(每小时不是一项困难的要求，但我们希望DynamoDB尽快更新，如果需要的话，每天更新的间隔最长)
• 事件模式类似于: customerId、deviceId、countryCode、时间戳
• 聚合模式类似于: customerId、deviceId、countryCode (在过去29天中，聚集在customerId/deviceId的MAX(countryCode)上)，在过去的29天里，最大的( countryCode )总体上是这样的。
• 只有与上一次聚合(从一小时前)相比countryCode发生变化的CustomerIds/deviceIds才应该写入DynamoDB，以使所需的写入容量单位保持在较低的水平。数据湖/数据仓库中存储的原始数据需要在30天后删除。

我提出的解决办法：

将数据传递到红移暂存表(默认情况下使用table

• Creates作为中间存储，然后使用复制命令将数据加载到红移)

• a

• S3的每小时Glue作业：

1. 删除30天前的时间序列表，并在Redshift中为今天创建一个新的时间序列表，如果这是新的
2. 运行的第一次任务，将数据从暂存表加载到适当的时间序列
3. ，在过去29天的时间序列的顶部，视图由customerId，deviceId，date，和MAX(CountryCode)
4. Then聚合由customerId、deviceId、MAX(countryCode)
5. Writes将聚合结果聚合到一个S3 bucket
6. Checks --上一个小时Glue作业的运行聚合结果与当前运行的聚合结果--查找有其countryCode change
7. Writes的customerIds/deviceIds --有其countryCode更改为DynamoDB

的customerIds/deviceIds行。

我的问题：

1. 是这里最好的存储选择吗？我还考虑使用S3作为存储，并使用Glue作业直接从S3查询数据，尽管我喜欢完全管理的数据--我们的数据有30天的固定保留期，AWS文档：https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-time-series-tables.html建议对需要删除的旧数据使用时间序列表和运行拖放表。还有其他方法(除Redshift之外)可以使数据生命周期管理更容易吗？拥有暂存表、创建和加载新的时间序列表、删除旧的时间序列表、更新视图以包含新的时间序列表(而不是删除的时间序列表)可能容易出错。
2. ，找到自上次聚合以来发生countryCode更改的行(customerId/deviceId组合)的最佳方法是什么？我认为Glue作业可以从前面的运行聚合结果S3文件创建一个表，从当前运行的聚合结果S3文件中创建另一个表，运行完全外部联接的一些变化，以查找具有不同countryCodes的行。这里有没有我不知道的更好的方法？

我是一个新手，当谈到大数据和大数据解决方案，所以任何和所有的输入都是非常感谢的！

Answer 1

tldr:使用step函数，而不是Glue。在S3中使用红移谱和数据。否则，你的整体结构就会走上正轨。

你在正确的轨道上，IMHO，但有一些事情，可以更好。红移对于筛选大量数据并对其进行分析是很好的。但是，如果您所做的只是构建要加载到DDB中的聚合，我不确定您想要将数据复制到Redshift中。您是否有其他的分析工作负载可以证明将数据存储在Redshift中是合理的？在暂存表和时间序列事件表之间是否正在进行大量转换？如果不是，您可能希望使用红移谱将时间序列表从S3中直接从外部读取。这可能是一个巨大的胜利，因为最初的数据分组和聚合是在S3的频谱层进行的。这样，就不必移动原始数据。

接下来，我建议您不要使用Glue，除非您需要(转换)在其他地方很难完成。我发现Glue需要一些专业知识来做你想做的事情，听起来你只是在用它来做一个数据运动的策划者。如果这种印象是正确的，那么使用step函数甚至数据管道会更好。)我浪费了太多的时间试图让Glue做一些简单的事情。这是一个强大的工具，但要确保你会从花在它上的时间中得到价值。)

如果您只使用Redshift来进行这些聚合，并且沿着上面的频谱路径，您将希望得到尽可能小的集群。红移可能是昂贵的，如果你不使用它的力量，没有成本效益。在这种情况下，您只能在需要时运行集群，但是Redshift启动时间不快，最小的集群也不昂贵。因此，这是一种可能性，但只有在适当的情况下才有可能。根据你所做的聚合有多困难，你可能想看看雅典娜。如果您只是每小时运行几个聚合查询，那么这可能是最具成本效益的方法。

检查最后一个小时的聚合只是一个比较新聚合与旧聚合的问题，而旧聚合是S3中的。这是很容易完成的红移光谱或雅典娜，因为他们可以使文件(或一组文件)为一个表的来源。然后，它只是运行查询。

在我看来，Glue是一个可以进行高功率转换的ETL工具。它可以做很多事情，但不是我的第一(或第二)选择。它很敏感，需要大量的配置才能做更多的基础工作，并且需要许多数据组不具备的专业知识。如果你是胶专家，那就自作自受吧；如果不是，我会避免的。

至于数据管理，是的，您不希望从Redshift中的表开头删除大量行。它产生了大量的数据重组工作。因此，在Redshift中，将数据存储在“月份”表中并使用视图是正确的方法。丢桌子并不能创造出这样的家务。也就是说，如果您将数据组织在S3中的“月份”文件夹中，那么不需要删除数月的数据就可以删除这些文件夹。

至于查找更改的国家代码，这在SQL中应该很容易做到。由于您正在将聚合数据与聚合数据进行比较，这也不会太昂贵。同样，红移光谱或雅典娜是允许您在S3数据上执行此操作的工具。

作为一个大数据新手，不用担心，我们都是从那里开始的。与其他领域最大的区别在于，移动数据的次数最少，这是多么重要。听起来，当你说“Redshift是这里最好的存储选择吗？”时，你似乎明白这一点。您似乎认识到了数据所在位置的重要性，wrt是目标上的计算元素。如果您需要Redshift的马力，并且将一次又一次地访问数据，那么Redshift是最好的选择--数据被移动一次到分析需要运行的地方。然而，Redshift是一种昂贵的存储解决方案--这不是它应该做的。红移谱是非常有趣的，因为数据的初始聚合是在S3中完成的，并且大部分的部分结果被发送到红移以完成。S3是一种便宜得多的存储解决方案，如果您的工作负载可以与频谱的功能匹配，这将是一个明显的赢家。

我想要明确的是，您只描述了需要解决方案的区域，并且我假设您没有其他对在相同数据上运行的Redshift集群的需求。这将改变优化点。