每天更新云中20-30亿行数据集中的1亿行

Question

这是一个和时间一样古老的故事。企业希望获取数十亿行(20-30亿)，将它们从Oracle流式传输到云(在我们的案例中是AWS)。到目前一切尚好。然后他们想要在云中处理它们，在这里仍然可以。

然后，他们希望每天更新大约5%(称为1.25亿)的行的子集，并再次处理数据。

我不是说这是不合理的，我只是不确定解决这个问题的最有效的方法。对于一些背景，我是一名高级全栈开发人员，有丰富的AWS和巨型数据集工作经验，但绝不是大数据专家。此外，如今云中的大数据选择如此之多，很难知道从哪里开始。

所以，问题是：

是否有针对此用例而构建的产品(最好是在AWS中)？

由于它是以每天为基础的，我们将需要能够有效地(快速)更新所有行，并且能够在第二天到来之前进行处理，并且该过程将重新开始。

这里的关键是更新的效率。像Glue这样的东西之所以会崩溃，是因为数据会有太多的分区(例如，一个表中有大约5,000-1亿个分区)。

Answer 1

我会关注Redshift，主要是因为对大多数人来说，SQL比Spark更熟悉。假设您正在将数据上传到S3，upsert过程如下所示(全部在单个事务中)：

• 使用COPY命令将数据从S3上的临时区域插入到临时表中。
• 如果您实际上正在执行更新(而不是追加)，请从基表中删除所有行。
• 将临时表中的行插入到基表

中

我会将其实现为AWS批处理作业，但如果您使用Airflow或类似的协调框架，它也可以工作。对于更新的大小，Lambda可能会超时。确保Redshift配置为自动真空。

如果它们设置为使用Glue，我会采用一种使用“版本”数据的方法，这样您就可以始终存储最新的数据。假设每晚都有一个作业，它将如下所示( S3上的文件夹名称是由用户自己组成的)：

从两个数据集的s3://yourbucket/complete/YYYY/MM/D0

• Read s3://yourbucket/updates/YYYY/MM/D1

• Combine s3://yourbucket/complete/YYYY/MM/D1

• Do

1. 中读取基本数据集，为每个键值选择最新的行。
2. 写出新数据集以根据新数据集进行处理。

在S3上使用生命周期规则来修剪旧的数据集。

我认为你会发现仅仅从基础数据集开始并应用完整的更新历史记录太慢了。尤其是因为您每天要更改5-10%的行。

而且你肯定不想按主键分区，因为Glue在处理大量小文件时性能不是很好(这在AWS文档中有讨论，但我找不到链接自动柜员机)。如果你每次运行都要更新5-10%的数据，那么只更新那些已经改变的文件并不能节省太多的资源。

要对数据集进行分区以提高并行性，您可以对主键进行散列，然后使用散列的某个子集来创建分区(例如，对散列进行十六进制并使用前几个十六进制字符作为分区键)。

Answer 2

这是我在@Parsifal推荐Redshift时遇到的。我将再次使用Redshift来完成这项工作，并添加一些其他可能性。

您没有提到将如何使用此数据集。我猜你想把它放在带有合理分区的S3中，但这并不清楚。是否希望能够对此数据运行SQL分析？因此最优解存在一定的不确定性。

首先，Redshift可能会变得昂贵，特别是当它只是闲置的时候。因此，如果你只需要每晚处理数据，没有其他事情，你会想要在不需要的时候关闭Redshift。如果您可以全天候使用Redshift的分析能力，那么您将获得更高的性能。

Next Redshift早餐吃掉了数十亿行数据集。它与S3有并行连接，因此可以从那里快速读取。然而，它是一个作为集群实现的柱状数据仓库，虽然在大多数(像几乎所有)操作上都很快，但有些算法在这种架构上不能很好地工作。( map-reduce的出现是有原因的)因此，请确保您需要进行的数据处理将映射到传统数据库。如果你不确定，就去寻求帮助。

红移光谱是一套功能，允许红移操作的S3文件作为一个“外部表”。这可以极大地简化S3作为数据存储的使用，但这也有一些限制-你不能从Redshift内部修改这些S3文件，但你可以将内容更改后的新文件写入S3。使用S3作为数据存储可能会对数据处理造成一些影响(在某些情况下还会提高速度)。如果存在问题，您可能希望对表使用原生Redshift存储。它不会给您的处理增加大量的复杂性。

可以对Redshift数据库进行“快照”，然后关闭。第二天，你可以从这个快照创建一个新的Redshift数据库，然后你就可以开始运行了。数据库通常在10到20分钟内可用，因此您可能希望在日常处理中需要它之前启动它。

对于您的情况，我会考虑Redshift，但有关如何使用if的很多信息将取决于您在此处理步骤之外如何使用数据的因素。

Answer 3

有多种选择，云很好，你可以尝试看看哪一个最适合你，而不需要花费大量的时间和金钱在不可行的工具上。

这里唯一的评论是，操作大约1亿行，可能值得看看ETL (AWS )或使用更新的值创建临时表(甲骨文有INSERT FROM SELECT，AWS有CREATE TABLE AS SELECT)

有一些常见的选项和工具可以加载/操作大量数据：

• AWS Glue - ETL和数据目录。这是一个很好的工具，可以在加载到另一个数据repository
• Maybe之前/同时准备数据。根据您拥有的数据和“过程数据”的含义，RDS将是足够好的。在我的经验中，对于基本的分析和数据操作来说，一个扩展良好的数据库在90%的情况下都足够好。
• RedShift是一个分析引擎，可以处理DB级的数据，但它并不真正适合data manipulation
• AWS EMR管理的Spark/Presto/HBase群集，可以非常强大假设您可以正确使用它
• AWS管理的无服务器EMR/Presto接口，它有一个简单易用的类似SQL的界面

注意：

• 如果您在迁移到亚马逊网络服务时压缩数据，请考虑使用BZIP2，因为其格式是“可拆分的”和一些工具(雅典娜、glue。)可以从S3并行加载大型files
• processing大型数据集，创建专用s3链接以限制从公共端点

的过高出口成本

像Glue这样的

会因为数据有太多的分区而崩溃

有趣的是，也许您可以直接将aws与用例联系起来