首先让我介绍一下我的使用情况下，我每天收到500万行，像这样：写作大拼花文件（500个百万行/列1000）至S3花费太多时间
ID |分类
1 | cat1，cat2，cat3，...，catn
2 | CAT1，CATX，卡蒂，...，anothercategory
输入数据：50压缩CSV文件，每个文件是250 MB - >总计：12.5 GB的压缩
目的是要回答这样的问题：发现属于所有ID来CATX和卡蒂，找到属于CAT3 ID和不CATY等...：即：IDS在CAT1üCAT2或ID CAT3∩CATX
假设类别动态创建（每天我都有一套新的类别），我的企业想要表达知道所有可能的交叉点和联盟（我们没有固定的一组查询），我想出了以下解决方案：
我写了一个spark工作，将日期转换为fat稀疏矩阵，其中列是所有可能的类别加上列ID，对于每一行和列我设置true属于id属于此类别，如果不属于，则为false：
ID | cat1 | cat2 | cat3 | ... | catn | catx | caty |另一个类别| ....
1 | true | true | true | ... | true | false | false | false | ....
2 | true | false | false | ... | false | true | true |真| ....
SQL可以简单地回答我的问题，例如，如果我想找到属于类CAT1和类别CATX然后所有的ID我运行针对该矩阵下面的SQL查询：
从MyTable中选择id，其中cat1 = true且catx = true;
我选择将这个稀疏矩阵保存为一个压缩的Parquet文件，我对稀疏性和查询性质做了这个选择，我相信柱状存储是最合适的存储格式。
与我的使用情况现在，这里描述的是我的观察，我可能会丢失一些优化点：
- 12.5GB压缩输入数据转换采取〜300GB写这篇稀疏矩阵拼花花费太多时间和后资源，花了2,3个小时spark1.6独立群集6个aws实例r4.4xlarge（我设置了足够的并行化来分配工作并利用我所有的工人）
我结束了太多实木复合地板文件，我越平行最小的地板文件。似乎每个RDD给出一个单一的实木复合地板文件 - >太多的小文件不是最佳扫描，因为我的查询经过所有的列值
我经历了很多帖子，但仍不明白为什么写500百万/ 1000柱压缩拼花地板到S3需要这么多时间，一旦在S3上的小文件总和达到〜35G
展望应用程序主UI，作业挂在写作舞台，转换阶段和洗牌似乎不是资源/时间消耗。
我试图调整parquet参数，如group_size，page_size和disable_dictionnary，但没有看到性能改进。
我试图分区到更大的RDD并将它们写入S3以获得更大的木地板文件，但作业花费了太多时间，最后我杀死了它。
我可以在~1小时内使用spark4.1独立的4个aws类型的r4.16xlarge实例来运行这个工作，我觉得我正在使用一个巨大的集群来实现小改进，唯一的好处是我得到的是运行更多的并行任务。我错过了什么吗？我可以利用〜1来达到更好的效果，并获得更大的镶木地板文件。
对于使用spark在S3上编写大型镶木地板文件，您有任何意见吗？
我想知道你对这个解决方案的意见/评论。
感谢和问候。