这是一个古老的故事。该公司希望获得数十亿行(20-30亿行)，将它们从Oracle流式传输到云(在我们的案例中是AWS)。到目前为止还不错。然后他们想在云中处理它们，在这里仍然可以。
然后，他们希望每天更新行的子集~5%(称之为1.25亿)，并再次处理数据。
我并不是说这是不合理的，我只是不确定解决这个问题的最有效方法。出于某种背景，我是一名高级全栈开发人员，在AWS和大型数据集方面有丰富的工作经验，但绝不是大数据专家。此外，如今云计算中有很多大数据的选择，很难知道从哪里开始。
所以，问题是：
有没有为这个用例构建的产品(最好在AWS中)？
由于这是每天都要进行的，我们需要能够高效(快速)更新所有行，并能够在第二天到来之前进行处理，整个过程重新开始。
这里的关键是更新的效率。像Glue这样的东西之所以会崩溃，是因为数据会有太多的分区(即一个表中大约有5000万到1亿个分区)。
我会看看Redshift，主要是因为SQL对大多数人来说比Spark更熟悉。假设您正在将数据上传到S3中，则追加销售过程如下所示(全部在单个事务中)：
- 使用
COPY命令将S3上的临时区域中的数据插入临时表中 - 如果您实际上正在进行更新(相对于追加)，请从基表中删除任何行
- 将临时表中的行插入基表
我会将其作为AWS批处理作业来实现，但如果您使用Airflow或类似的协调框架，它也会起作用。对于更新的大小，Lambda可能会超时。确保Redshift配置为自动真空。
如果他们开始使用Glue，我会采取一种使用"Glue"的方法；版本"；数据，以便您始终存储最新的数据。假设是夜间作业，它看起来是这样的(S3上的文件夹名称是由组成的)：
- 从
s3://yourbucket/complete/YYYY/MM/D0读取基本数据集 - 从
s3://yourbucket/updates/YYYY/MM/D1阅读当天的更新 - 组合两个数据集，为每个键值选择最近的行
- 将新数据集写入
s3://yourbucket/complete/YYYY/MM/D1 - 根据新数据集进行处理
在S3上使用生命周期规则来修剪旧数据集。
我认为，您会发现从基本数据集开始并应用完整的更新历史记录太慢了。尤其是因为你每天要换5-10%的行。
你肯定不想用主键分区，因为Glue对大量小文件的性能不是很好(这在AWS文档中有讨论，但我找不到链接atm)。如果你每次跑步都要更新5-10%的数据，那么只更新那些已经更改的文件不会节省太多。
为了对数据集进行分区以提高并行性，可以对主键进行散列，然后使用散列的某个子集来创建分区(例如，将散列进行hefy，并使用前几个十六进制字符作为分区键)。
这是我的推送，@Parsifal推荐Redshift。我将在这份工作中使用Redshift，并添加一些其他可能性。
您没有提及将如何使用此数据集。我猜你希望S3中有一些合理的分区，但这还不清楚。是否希望能够对此数据运行SQL分析？因此，最优解存在一定的不确定性。
首次推出的Redshift可能会变得昂贵，尤其是当它闲置时。因此，如果你只需要每晚处理数据，而不需要其他任何事情，你会想在不需要的时候关闭Redshift。如果你能使用Redshift全天候的分析马力，那么你将以你的美元获得很多性能。
下一个Redshift早餐吃十亿个行数据集。它与S3有并行连接，因此可以快速读取。然而，它是一个作为集群实现的柱状数据仓库，虽然在大多数(像几乎所有)操作上都很快，但有些算法在这种架构上运行不好。(地图减少是有原因的)因此，请确保您需要进行的数据处理将映射到传统数据库。如果你不确定，请寻求帮助。
Redshift Spectrum是一组允许Redshift在S3文件上操作的功能；外部表"；。这可以极大地简化S3作为数据存储的使用，但这确实有一些限制——你不能从Redshift内部修改这些S3文件，但你可以将内容已更改的新文件写入S3。使用S3作为数据存储可能会有一些数据处理惩罚(在某些情况下还会加快速度)。如果表存在问题，您可能需要使用本机Redshift存储。它不会给您的处理增加很大的复杂性。
Redshift数据库可以是"；快照的"；然后关闭。第二天，你可以从这个快照创建一个新的Redshift数据库，然后你就可以离开并运行了。数据库通常在10到20分钟内即可使用，因此您可能需要在日常处理中需要它之前先启动它。
我会为你的案例查看Redshift，但关于你想如何使用if，很大程度上取决于你在这个处理步骤之外如何使用数据的因素。
有多种选择，云很好，你可以尝试看看什么最适合你，而无需花费大量时间或金钱使用不可行的工具。
这里唯一的注释是，操作大约100M行，可能值得一看ETL(AWS Glue)或创建具有更新值的临时表(Oracle有INSERT FROM SELECT，AWS RedShift有CREATE TABLE AS SELECT)
有一些常用的选项和工具来加载/操作大量数据：
- AWS Glue-ETL和数据目录。这是一个很好的工具，可以在加载到另一个数据存储库之前/同时准备数据
- 也许RDS将足够好，这取决于你拥有什么数据以及"；过程数据"；方法根据我的经验，对于基本的分析和数据操作来说，在90%的情况下，规模良好的数据库就足够了
- AWS RedShift是一个分析引擎，可以处理PB级的数据，但它并不真正适合数据操作
- AWS EMR管理的Spark/Presto/HBase集群，如果你能正确使用它，它会非常强大
- AWS Athena管理的无服务器EMR/Presto接口，它有一个简单易用的类似SQL的接口
注意：
- 如果您在移动到AWS时压缩数据，请考虑使用BZIP2，因为格式是"；可拆分的"；一些工具(athena、glue..)可以使用并行加载大文件
- 处理S3中的大型数据集，创建专用S3链接以限制公共端点的过度出口成本
像Glue这样的东西会崩溃，因为数据会有太多的分区
有趣的是，也许你可以让aws直接参与用例