巨大的倾斜数据，需要分区并转换为拼花答案

【问题标题】：Huge skewed data, Need to partition and convert to parquet巨大的倾斜数据，需要分区并转换为拼花
【发布时间】：2020-03-19 14:51:03
【问题描述】：

我在一个关系数据库中有非常大的数据（几乎 70TB 未压缩），需要在 s3 中加载并转换为 parquet 并按年月、col1 和 col2 对数据进行分区。

这将是日常工作，我有 70Node 集群，每个集群有 256GB Ram，每个集群有 64Vcores。我们正在尝试使用 spark 使用属性连接器转储数据，并且转储数据非常快。它基本上以多个块的 CSV 格式转储到 S3 中的临时位置。数据以 1M 块 64mb csv 文件的形式转储。

在不进行分区的情况下，将数据转换为镶木地板需要 3 小时，包括数据的卸载。

问题陈述：

根据分区的要求，我的数据高度偏斜，因为近年来 70% 的数据是这样，其中每个 col1 和 col2 也非常偏斜。

当我在没有分区的情况下将文件转换为镶木地板时，我得到了数千个小文件，并且多个任务因 s3-slowdown 请求率错误而失败。如果我尝试合并或重新分区数据，我会遇到重新洗牌/内存中断问题。我试图避免在多次迭代中读取数据，因为转储的数据是未分区的，我可能最终每次都读取整个 1M 文件进行过滤。

有没有办法在分区后重新分区（合并）文件？

【问题讨论】：

您的问题的一个观察结果是您的内存与 cpu 的比率非常低，约为每 cpu 4gb。您可以尝试的一件事是在转储数据后，从特定分区读取并尝试合并到另一个位置。接下来我可能会尝试编写一个函数来合并这些 parquet 文件，但这需要了解 parquet 文件格式。
为什么每天都加载完整的历史记录？几个月前的数据仍然变化真的很普遍吗？考虑一个更高级的工作流程，避免大部分繁重的工作。
@DennisJaheruddin 是的，这就是最终目标，但直到我们达到理解源和目标之间的 500 个工作（其中大部分是截断和加载）的那个点，我们正试图提出这个解决方案。
您是否将repartition 方法与作者的partitionBy 方法混淆了？请向我们展示您的代码。

【解决方案1】：

感谢所有 cmets。我能够解决问题并能够达到要求。

我已将 Redshift 中的提取物分离到一个单独的进程中。由于 Redshift 的 JDBC 驱动程序存在多个问题。我在当前支持 Parquet 格式的 redshift 上使用了本机卸载命令。因此以 parquet 格式提取数据并写入 s3。它已将我的数据大小从 60TB 减少到 9TB。
编写了一个自定义分区器（加盐）方法，并提出了一种可以平均分配数据的算法。（至少是相等的，并将大分区分成相等的块）。
在写入之前，我正在使用自定义分区器重新分区数据并写入数据。

现在整个过程在 4-5 小时内完成。

【讨论】：