用于聚合时间序列数据并将结果存储到 DynamoDB 的最佳大数据解决方案
Optimal Big Data solution for aggregating time-series data and storing results to DynamoDB
我正在研究不同的大数据解决方案，但未能找到明确的答案或文档来说明什么是最佳方法，frameworks/services 可用于解决我的大数据用例。
我的用例：
- 我有一个数据生成器，它将发送大约 1-20 亿个事件到
每日 Kinesis Data Firehose 传输流。
- 这些数据需要存储在一些数据湖/数据仓库中，聚合，然后
加载到 DynamoDB 以便我们的服务使用聚合数据
在其业务逻辑中。
- DynamoDB table 需要每小时更新一次。 （每小时不是一个硬性要求，但我们希望 DynamoDB 尽快更新，如果需要的话，每天更新的时间间隔最长）
- 事件架构类似于：customerId、deviceId、countryCode、timestamp
- 聚合架构类似于：customerId、deviceId、countryCode（聚合在过去 29 天的每一天的 customerId's/deviceId's MAX(countryCode) 上，然后是 MAX(国家代码）过去 29 天的总体情况。
- 只有 CustomerIds/deviceId 的国家/地区代码在上次聚合（一小时前）发生变化后才应写入 DynamoDB，以保持所需的写入容量单位较低。
- 存储在数据湖/数据仓库中的原始数据需要在30天后删除。
我提出的解决方案：
- Kinesis Data Firehose 将数据传送到 Redshift staging table（默认情况下使用 S3 作为中间存储，然后使用 COPY 命令加载到 Redshift）
- 每小时 Glue 工作：
- 删除 30 天前的时间序列 table 并为今天在 Redshift 中创建一个新的时间序列 table 如果这是新一天的第一份工作 运行
- 将暂存 table 中的数据加载到适当的时间序列 table
- 在过去 29 天的时间序列之上创建视图 tables
- 按客户 ID、设备 ID、日期和 MAX（国家/地区代码）聚合
- 然后按 customerId、deviceId、MAX(countryCode) 聚合
- 将聚合结果写入 S3 存储桶
- 检查前一个每小时 Glue 作业的 运行 聚合结果与当前 运行s 聚合结果，以找到 customerIds/deviceIds 的 countryCode 发生变化
- 将国家/地区代码更改的 customerIds/deviceIds 行写入 DynamoDB
我的问题：
- Redshift 是这里最好的存储选择吗？我也在考虑使用 S3 作为存储并使用 Glue 作业直接从 S3 查询数据，尽管我喜欢完全托管的数据仓库的想法。
- 由于我们的数据有 30 天的固定保留期，AWS 文档：https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-time-series-tables.html 建议使用时间序列 tables 和 运行ning DROP TABLE在需要删除的旧数据上。是否有其他方法（在 Redshift 之外）可以使数据生命周期管理更容易？进行暂存 table，创建并加载到新的时间序列 tables，删除旧的时间序列 tables，更新视图以包含新的时间序列 table 而不是被丢弃的那个可能容易出错。
- 查找自上次聚合以来国家/地区代码发生变化的行（customerId/deviceId 组合）的最佳方法是什么？我在想 Glue 作业可以从之前的 运行s 聚合结果 S3 文件创建一个 table，并从当前 运行s 聚合结果 S3 文件创建另一个 table，运行 FULL OUTER JOIN 的一些变体，用于查找具有不同国家/地区代码的行。这里有没有我不知道的更好的方法？
我是大数据和大数据解决方案方面的新手，因此欢迎任何和所有意见！
tldr：使用步进函数，而不是 Glue。将 Redshift Spectrum 与 S3 中的数据结合使用。否则你的整体结构看起来正轨。
恕我直言，您走在正确的轨道上，但有一些地方可以做得更好。 Redshift 非常适合筛选大量数据并对其进行分析。但是，如果您所做的只是构建要加载到 DDB 中的聚合，我不确定是否要将数据复制到 Redshift 中。您是否正在完成其他分析工作负载以证明将数据存储在 Redshift 中是合理的？在暂存 table 和时间序列事件 table 之间是否进行了大量转换？如果不是，您可能希望将时间序列 tables 设为外部 - 使用 Redshift Spectrum 直接从 S3 读取。这可能是一个巨大的胜利，因为初始数据分组和聚合是在 S3 的 Spectrum 层中完成的。这样就不必移动原始数据。
接下来，我建议不要使用 Glue，除非您有无法在其他地方轻松完成的需求（转换）。我发现 Glue 需要一些专业知识才能做你想做的事，听起来你只是将它用于数据移动协调器。如果这种印象是正确的，那么使用阶跃函数甚至数据管道会更好。 （我浪费了太多时间试图让 Glue 做一些简单的事情。它是一个强大的工具，但要确保你会从花在它上面的时间中获得价值。）
如果您只使用 Redshift 进行这些聚合，并且您选择上面的 Spectrum 路线，您将希望获得尽可能小的集群。 Redshift 可能很贵，如果您不使用它的功能，则不符合成本效益。在这种情况下，您可以 运行 仅根据需要创建集群，但 Redshift 启动时间并不快，而且最小的集群也不贵。所以这是一种可能性，但只有在适当的情况下。根据聚合的难度，您可能需要查看 Athena。如果您只是 运行每小时进行一些聚合查询，那么这可能是最具成本效益的方法。
检查过去一小时的聚合只是将新聚合与 S3 中的旧聚合进行比较。使用 Redshift Spectrum 或 Athena 可以轻松完成此操作，因为它们可以将文件（或文件集）作为 table 的源。然后就是 运行查询。
在我看来，Glue 是一种可以进行高功率转换的 ETL 工具。它可以做很多事情，但不是我的第一（或第二）选择。它很敏感，需要大量配置才能完成比基础更多的工作，并且需要许多数据组不具备的专业知识。如果您是 Glue 专家，请自我淘汰；如果没有，我会避免。
至于数据管理，是的，您不想在 Redshift 中从 table 开头删除大量行。它创建了大量的数据重组工作。因此，将数据存储在“月”tables 中并使用视图是进入 Redshift 的正确方法。删除 tables 不会创建此内务处理。也就是说，如果您将 S3 中的数据组织在“月份”文件夹中，那么不需要删除几个月的数据就可以删除这些文件夹。
至于查找不断变化的国家/地区代码，这在 SQL 中应该很容易做到。由于您正在将聚合数据与聚合数据进行比较，因此这也不应该很昂贵。同样，Redshift Spectrum 或 Athena 是允许您对 S3 数据执行此操作的工具。
作为一个大数据新手，不用担心，我们都是从那里开始的。与其他领域的最大区别在于以最少的次数移动数据是多么重要。当您说“Redshift 是这里最好的存储选择吗？”时，您似乎理解了这一点。您似乎认识到数据所在位置对目标计算元素的重要性。如果您需要 Redshift 的强大功能并且将一遍又一遍地访问数据，那么 Redshift 是最佳选择 - 数据一次移动到分析需要 运行 的地方。然而，Redshift 是一种昂贵的存储解决方案——这不是它的本意。 Redshift Spectrum 非常有趣，因为数据的初始聚合是在 S3 中完成的，并且大量减少的部分结果被发送到 Redshift 以完成。 S3 是一种便宜得多的存储解决方案，如果您的工作负载可以与 Spectrum 的功能进行模式匹配，那么这将是一个明显的赢家。
我想明确一点，您只描述了您需要解决方案的领域，我假设您对在相同数据上运行的 Redshift 集群没有其他需求。这将改变优化点。
我正在研究不同的大数据解决方案，但未能找到明确的答案或文档来说明什么是最佳方法，frameworks/services 可用于解决我的大数据用例。
我的用例：
- 我有一个数据生成器，它将发送大约 1-20 亿个事件到 每日 Kinesis Data Firehose 传输流。
- 这些数据需要存储在一些数据湖/数据仓库中，聚合，然后 加载到 DynamoDB 以便我们的服务使用聚合数据 在其业务逻辑中。
- DynamoDB table 需要每小时更新一次。 （每小时不是一个硬性要求，但我们希望 DynamoDB 尽快更新，如果需要的话，每天更新的时间间隔最长）
- 事件架构类似于：customerId、deviceId、countryCode、timestamp
- 聚合架构类似于：customerId、deviceId、countryCode（聚合在过去 29 天的每一天的 customerId's/deviceId's MAX(countryCode) 上，然后是 MAX(国家代码）过去 29 天的总体情况。
- 只有 CustomerIds/deviceId 的国家/地区代码在上次聚合（一小时前）发生变化后才应写入 DynamoDB，以保持所需的写入容量单位较低。
- 存储在数据湖/数据仓库中的原始数据需要在30天后删除。
我提出的解决方案：
- Kinesis Data Firehose 将数据传送到 Redshift staging table（默认情况下使用 S3 作为中间存储，然后使用 COPY 命令加载到 Redshift）
- 每小时 Glue 工作：
- 删除 30 天前的时间序列 table 并为今天在 Redshift 中创建一个新的时间序列 table 如果这是新一天的第一份工作 运行
- 将暂存 table 中的数据加载到适当的时间序列 table
- 在过去 29 天的时间序列之上创建视图 tables
- 按客户 ID、设备 ID、日期和 MAX（国家/地区代码）聚合
- 然后按 customerId、deviceId、MAX(countryCode) 聚合
- 将聚合结果写入 S3 存储桶
- 检查前一个每小时 Glue 作业的 运行 聚合结果与当前 运行s 聚合结果，以找到 customerIds/deviceIds 的 countryCode 发生变化
- 将国家/地区代码更改的 customerIds/deviceIds 行写入 DynamoDB
我的问题：
- Redshift 是这里最好的存储选择吗？我也在考虑使用 S3 作为存储并使用 Glue 作业直接从 S3 查询数据，尽管我喜欢完全托管的数据仓库的想法。
- 由于我们的数据有 30 天的固定保留期，AWS 文档：https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-time-series-tables.html 建议使用时间序列 tables 和 运行ning DROP TABLE在需要删除的旧数据上。是否有其他方法（在 Redshift 之外）可以使数据生命周期管理更容易？进行暂存 table，创建并加载到新的时间序列 tables，删除旧的时间序列 tables，更新视图以包含新的时间序列 table 而不是被丢弃的那个可能容易出错。
- 查找自上次聚合以来国家/地区代码发生变化的行（customerId/deviceId 组合）的最佳方法是什么？我在想 Glue 作业可以从之前的 运行s 聚合结果 S3 文件创建一个 table，并从当前 运行s 聚合结果 S3 文件创建另一个 table，运行 FULL OUTER JOIN 的一些变体，用于查找具有不同国家/地区代码的行。这里有没有我不知道的更好的方法？
我是大数据和大数据解决方案方面的新手，因此欢迎任何和所有意见！
tldr：使用步进函数，而不是 Glue。将 Redshift Spectrum 与 S3 中的数据结合使用。否则你的整体结构看起来正轨。
恕我直言，您走在正确的轨道上，但有一些地方可以做得更好。 Redshift 非常适合筛选大量数据并对其进行分析。但是，如果您所做的只是构建要加载到 DDB 中的聚合，我不确定是否要将数据复制到 Redshift 中。您是否正在完成其他分析工作负载以证明将数据存储在 Redshift 中是合理的？在暂存 table 和时间序列事件 table 之间是否进行了大量转换？如果不是，您可能希望将时间序列 tables 设为外部 - 使用 Redshift Spectrum 直接从 S3 读取。这可能是一个巨大的胜利，因为初始数据分组和聚合是在 S3 的 Spectrum 层中完成的。这样就不必移动原始数据。
接下来，我建议不要使用 Glue，除非您有无法在其他地方轻松完成的需求（转换）。我发现 Glue 需要一些专业知识才能做你想做的事，听起来你只是将它用于数据移动协调器。如果这种印象是正确的，那么使用阶跃函数甚至数据管道会更好。 （我浪费了太多时间试图让 Glue 做一些简单的事情。它是一个强大的工具，但要确保你会从花在它上面的时间中获得价值。）
如果您只使用 Redshift 进行这些聚合，并且您选择上面的 Spectrum 路线，您将希望获得尽可能小的集群。 Redshift 可能很贵，如果您不使用它的功能，则不符合成本效益。在这种情况下，您可以 运行 仅根据需要创建集群，但 Redshift 启动时间并不快，而且最小的集群也不贵。所以这是一种可能性，但只有在适当的情况下。根据聚合的难度，您可能需要查看 Athena。如果您只是 运行每小时进行一些聚合查询，那么这可能是最具成本效益的方法。
检查过去一小时的聚合只是将新聚合与 S3 中的旧聚合进行比较。使用 Redshift Spectrum 或 Athena 可以轻松完成此操作，因为它们可以将文件（或文件集）作为 table 的源。然后就是 运行查询。
在我看来，Glue 是一种可以进行高功率转换的 ETL 工具。它可以做很多事情，但不是我的第一（或第二）选择。它很敏感，需要大量配置才能完成比基础更多的工作，并且需要许多数据组不具备的专业知识。如果您是 Glue 专家，请自我淘汰；如果没有，我会避免。
至于数据管理，是的，您不想在 Redshift 中从 table 开头删除大量行。它创建了大量的数据重组工作。因此，将数据存储在“月”tables 中并使用视图是进入 Redshift 的正确方法。删除 tables 不会创建此内务处理。也就是说，如果您将 S3 中的数据组织在“月份”文件夹中，那么不需要删除几个月的数据就可以删除这些文件夹。
至于查找不断变化的国家/地区代码，这在 SQL 中应该很容易做到。由于您正在将聚合数据与聚合数据进行比较，因此这也不应该很昂贵。同样，Redshift Spectrum 或 Athena 是允许您对 S3 数据执行此操作的工具。
作为一个大数据新手，不用担心，我们都是从那里开始的。与其他领域的最大区别在于以最少的次数移动数据是多么重要。当您说“Redshift 是这里最好的存储选择吗？”时，您似乎理解了这一点。您似乎认识到数据所在位置对目标计算元素的重要性。如果您需要 Redshift 的强大功能并且将一遍又一遍地访问数据，那么 Redshift 是最佳选择 - 数据一次移动到分析需要 运行 的地方。然而，Redshift 是一种昂贵的存储解决方案——这不是它的本意。 Redshift Spectrum 非常有趣，因为数据的初始聚合是在 S3 中完成的，并且大量减少的部分结果被发送到 Redshift 以完成。 S3 是一种便宜得多的存储解决方案，如果您的工作负载可以与 Spectrum 的功能进行模式匹配，那么这将是一个明显的赢家。
我想明确一点，您只描述了您需要解决方案的领域，我假设您对在相同数据上运行的 Redshift 集群没有其他需求。这将改变优化点。