Apache spark 巨大的倾斜数据，需要分区并转换为拼花地板

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

这将是日常工作，我有70个节点的集群，每个集群上有256GB的Ram，每个集群上有64V内核。我们正在尝试使用spark使用Property连接器转储数据，转储数据的速度非常快。它基本上以CSV格式以多个块转储到S3中的临时位置。数据转储在1M块64mb CSV文件中

在没有分区的情况下，将数据转换为拼花地板需要3小时，包括数据卸载

问题陈述：

根据分区的要求，我的数据是高度倾斜的，因为70%的数据是最近几年的数据，而且其中的每个col1和col2也是非常倾斜的

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

---

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

谢谢你的评论。我能够解决问题并达到要求

我已经将红移提取液分离成一个单独的过程。因为红移的JDBC驱动程序存在多个问题。我在redshift上使用了一个本地卸载命令，它目前支持拼花地板格式。所以提取拼花地板格式的数据并写入s3。它将我的数据量从60TB减少到9TB

编写了一个自定义分区（salting）方法，并提出了一个平均分配数据的算法（至少是相等的，并将巨大的分区分成相等的块）

在编写之前，我将使用自定义分区器重新分区数据并编写数据

---

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

从您的问题中可以观察到，内存与cpu的比率非常低，约为每个cpu 4gb。您可以尝试的一件事是在转储数据之后，从特定分区读取数据，然后尝试合并到另一个位置。接下来我可能会尝试编写一个函数来合并这些拼花文件，但这需要了解拼花文件的格式。为什么每天都加载完整的历史记录？x个多月前的数据仍然在变化，这真的很普遍吗？考虑一个更先进的工作流程，避免大多数繁重的工作。@丹尼斯贾希尔丁，是的，这是最终的目标，但是直到我们达到了理解源和目标之间的500个任务（其中大部分是截断和加载）的那一点。我们正在尝试提出此解决方案。您是否将

重新分区

方法与编写者的

分区方法相混淆？请出示您的密码。