我有个问题想请教一下， 对于spark处理小文件，有没有什么优化方法

可参考 Spark 小文件合并优化实践

spark只一个开源项目，不会考虑这些碎片文件问题，建议平台，这样在spark 任务运行完以后做自己想要做的事情，例如合并碎皮文件，获取数据血缘信息等。![image] 有需要可以联系我。(https://yqfile.alicdn.com/0702bce22ca8bf9f381a2860b1aa8f1232cf0534.png)

spark只一个开源项目，不会考虑这些碎片文件问题，建议平台，这样在spark 任务运行完以后做自己想要做的事情，例如合并碎皮文件，获取数据血缘信息等。![image] 有需要可以联系我。

可以异步合并，小文件想解决还是合并，落地前合并，处理后合并。在write后repartition一下就可以设置文件数量，在你预估一个分区或处理文件的大小时可以把数量做成参数，比上blockSize生成一个合理的数字。也可以在落地后合并，这样不影响落地的效率不过两种方法都行，落地后就比如shuffle默认200个，那么就有200个小文件，那么可以在不使用这份数据的时候进行离线的合并，合并的方法有很多，基本上就是读出来再写进去，有几个点要注意：把合并后的文件放进原目录中前要删除之前读出来的那些文件避免数据重复，但不能全部删除，合并生成大文件过程中是否有其他程序写入新文件，文件中是否有tmp、success，文件存储格式要统一。

你是问关于 delta 的小文件，还是 spark sql 自己的一些小文件？还是什么？sparksql目前应该没有这个功能，我们这边可以看一下需求

如果是 hive 的事务表，hive 有合并小文件的功能。spark 方面开源是没有的。spark sql 开启事务之后，delete update 都会产生小文件。处理思路是一样的，定期合并。备注：开源 spark 没有事务支持。emr spark 的事务支持目前还比较薄弱。如果大家有需求，欢迎提出。

sparksql生成的数据小文件真的多，咱们可以通过元数据库，获取每个表下面每个分区下面的数据大小和文件个数，看看是要合并小文件还是要拆分大文件，然后sparksql读出来，然后再写进去，设置一下partition number

你们是用 spark streaming 处理数据最后实时写为 parquet 文件，然后推荐系统会用这些实时处理的数据，是这样的吧？（是的，需求是这样）那推荐系统怎么用这些数据，具体是用什么工具知道吗？（实时读取hdfs文件，spark ML）
了解了。看到你们这个主要还是 spark 的技术栈，应用场景是 data pipeline。databricks 前一段时间开源的 delta 正是解决这一类场景。