本文主要是介绍小文件过多的解决方法（不同阶段下的治理手段，SQL端、存储端以及计算端），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
上一篇介绍了小文件出现的原因以及为什么治理小文件问题迫在眉睫，本篇将为读者讲述在不同阶段下小文件治理的最佳手段以及如何针对性的解决小文件过多的问题。
小文件过多如何解决、治理方法
小文件是特别常见的现象，解决小文件问题迫在眉睫！！！
一般来说，一个任务是由几个步骤组成的，而小文件的产生也来自任务的各个流程和步骤：
上游 => 本地文件系统 => HDFS => Map => Reduce => FileSink
所以解决小文件问题就是需要从最前面的步骤中入手。而且解决小文件的隐患，肯定也是越早越好，就像过滤下推，能尽早做的过滤条件一定是尽早过滤。
因此，能在本地文件系统解决的问题，没必要放到HDFS上解决。就像前面章节的内容所述，HDFS本身就不适合存储大量小文件，小文件过多会导致namenode元数据特别大, 占用太多内存，严重影响HDFS的性能。
当前治理小文件的现有手段主要有以下几种：
1）SQL端规范
治理小文件的最优解一定是从源头（集群规划设计和搭建）开始就进行规范管理。比如在表结构和SQL语句方面进行规范，特别是分桶个数，分区类型的选择，范围分区跨度的选择。如果从初期就开始重视，确保不会出现小文件过多以及合并完成后还是小文件的问题，可以最大程度的减少后续因该问题引发的集群异常、性能下降和宕机的可能，进一步达到治理小文件的目的。
SQL端规范适用于以下原因导致的小文件问题：
- 表结构不合理，设置分桶数过大，数据平均分布，小文件过多；
- 分桶字段不合理，导致数据倾斜，产生大量小文件；
- 单值分区设置不合理，导致单分区数据量小，产生大量小文件；
表结构
分桶表
为了更细粒度地管理和优化数据存储与访问，数据分桶（Bucketing）技术逐渐受到了关注，即对指定列的哈希值将其分配到固定数量的子集中（桶），保障数据的均匀分布，从而为复杂查询提供了更高效的处理方式。
分桶表表结构创建之前需要对表的数据分布情况及数据特征进行大致的分析，一般遵循以下原则：
- 选择离散度高的字段进行分桶，避免选择decimal类型的字段做为分桶键，一般选择表的主键等字段，包括账号，客户号，证件号码等；
- 分桶个数选择非31的质数，减少潜在的哈希冲突；
- 分桶字段在选择时，注意尽量使记录分布均匀，以避免数据倾斜；
- 设计表结构时首先要预估该表的数据量和数据文件的大小，按照每个桶文件100-200M的大小来设置分桶个数；
- 另外，在考虑分桶个数的时候，同时要考虑是否已经分过区。对于已经分过区的表，要按照单分区的大小进行桶数的估计，而不是依照原始表。推荐单个分区中，每个桶文件为 50~100 MB，既可以避免文件过小触发小文件合并，给文件管理带来额外开销，同时也避免了 Block 文件数过多导致查询启动的 task 数过多影响执行和并发效率。
更多有关分桶策略及实践最佳案例可参考：【性能优化】表分桶实践最佳案例
分区表
表分区是一种在数据库中组织和存储数据的技术，其核心思想是将数据按照某个特定的标准分成多个物理块，每个物理块即为一个分区，从而使数据的存储和管理更加高效。
分区表表结构创建之前需要综合分析查询需求，重点关注经常被查询的数据的过滤条件，以选择适当的分区键。建议创建范围分区表，不推荐使用二级分区，分区字段选择上一般选择时间，区域等字段，推荐使用 STRING 或时间类型的列作为分区键，可以帮助在数据均衡和分区数量上取得较好的平衡。
此外，需要权衡分区规模。常规情况下，单个分区的数据量控制在 500GB 内，如果集群的 CPU 核数较多，可适当提升。同时，也需要关注数据的增长趋势，根据每天和每月增量的大小来界定每个分区的范围。如果一个分区数据量太大，可以考虑创建分区分桶表，并合理的设置分桶键和分桶个数。
更多有关分区策略及实践最佳案例可参考：【性能优化】表分区实践最佳案例
不规范表结构改造
对于由于表结构原因导致小文件过多的表，建议是重建表结构，一般具体流程为：备份表和数据-->重建表结构-->回填表数据-->验证表数据和文件-->删除备份表。
注意：对于分区表、分桶表、分区分桶表，回填数据时，可以sort by备份表的分区键、分桶键来提升表的查询效率。
SQL语句规范
规范的SQL语句可以帮助优化数据查询和处理过程，减少不必要的数据扫描和计算，从而降低小文件的产生。通过合理地设计和优化SQL语句，可以有效地治理小文件问题，提高数据处理的效率和性能。
可以遵循以下规则进行规范：
- 必须尽量避免大表与大表直接JOIN，执行之前要检查分析一下SQL，如果有小表，先用小表或是过滤率较高的表过滤大表，即尽可能先做与小表有关的 JOIN，再使大表参与进来；
- 大表与小表JOIN 时，可以采用MapJoin，减少Shuffle过程；
- 两张大表关联时，使用 Bucketed Join；
- 小表 Join 大表时，使用 Lookup Join；；
- 数据倾斜导致 Join 性能地下时，使用 SKEWJOIN；
- 注意笛卡尔积等数据翻倍情况的出现；
- 减少INNER JOIN的中间量，在多表进行连接时，JOIN之间的连接顺序将极大影响SQL的执行效率。应尽量优先执行过滤高的JOIN，以提高SQL的整体执行速度；
- 先INNER JOIN后OUTER JOIN，当一条语句中的INNER JOIN与OUTER JOIN顺序执行且关联，并都涉及同一张表时，执行顺序通常也可满足交换律。一般情况下，由于带过滤条件的INNER JOIN会减少记录数，而OUTER JOIN不会减少记录数，所以建议用户先执行INNER JOIN；
- 添加手工推导的过滤规则，即在原有SQL的基础上手动的添加额外的过滤条件，这些过滤条件仅仅以优化为目的，不会影响查询返回结果。它们是通过表与表之间的关系推导得到的，是以正确分析两表或多表之间存在的关联信息为前提的，最重要的是能够根据一张表的结果锁定结果所在范围；
- 用GROUP BY实现DISTINCT，在DISTINCT可以用GROUP BY去重表达时，尽量用GROUP BY；
- 尽量返回更少的数据。在编写SQL语句时，通过明确指定查询字段去除不必要的返回字段，以减少不必要的查询时间；
- 多表关联时，使用SQL92标准写法，目的是更能体现表与表之间的关联关系，杜绝使用 Right 连接、非SQL92标准的"(+)左连接"；
- 如果业务逻辑允许的情况下，尽量用UNION ALL代替UNION，用UNION ALL代替OR；
- SQL语句的WHERE子句中应尽可能将字段放在等式左边，将计算操作放在等式的右边；
- SQL语句的操作符两边类型应相同，禁止潜在的数据类型转换，建议用户在执行计算前通过类型转换，使各操作数的类型匹配，或者建表时尽可能的把字段安排成相同的数据类型。
2）存储端合并
存储端合并主要是合并已经写入到存储的文件，当表中有小文件或者小文件过多时，可以使用下述存储端合并的方式进行合并以达到减少文件数量、降低存储开销提高数据读写效率的目的。存储端合并的方式主要适用于以下原因导致的小文件问题：
- 频繁的写入数据；
- torc表compact多次合并失败后进入黑名单，导致小文件不再继续合并；
- 历史数据流程导致小文件问题，这些数据一般是从别的数据库迁移过来，后续没有进行治理；
需要注意的是，不同表格式（如.TORC事务表、RCfile/ORC/Text等非事务表、星环自研Holodesk表）的合并方式并不相同。
下一篇将介绍下星环不同表格式的合并方式（即将发布）
归档分区
除了针对上述表实现合并机制外，星环分布式分析型数据库ArgoDB在6.0及后续版本中引入了归档分区的功能，用户可以跨分区进行合并。归档分区的实现手段是用范围分区去表示单值分区，适用于分区字段为离散类型的单值分区，如日期 （暂不支持时间戳类型）、整数的场景。
通过分区归档合并功能，可以将大量小文件（归档前的单值分区）合并成较大的文件（归档后的范围分区），从而减少存储开销、元数据管理的开销以及处理时的任务调度开销。
创建归档分区表
归档分区表的本质为范围分区表，所以创建语句与创建范围分区表一致，只需额外设置表参数"archive_partition"="true" 来区分为归档分区表。支持直接创建归档分区表和修改普通范围分区表为归档分区两种方式。
分区合并
命令：ALTER TABLE TBL_NAME MERGE FROM PARTITION (values_start) TO PARTITION (values_end) INTO PARTITION <partition_name>;
3）计算端合并
计算端合并分为两个阶段：map端合并和reduce端合并，适用于因为不规范的sql语句，导致的小文件问题。
正如前面所说，小文件的产生来自任务的各个流程和步骤，越早解决对业务的影响越小。如果在前期无法解决的情况下，可以考虑在以下两个阶段进行合并：
maptask阶段合并
Maptask阶段合并可以使用automerge功能，在map端控制map task的数目，它可以根据每个partition (数据块) 所在的位置及大小将多个partitions交给一个task去完成；
在星环TDH9.3及后续版本中，产品引入了改进后的automergeV2功能，V2版本在性能方面有很大提升，并且解决了有关automerge可能存在的一些问题。
由于篇幅原因，有关automerge功能及优化后的automergeV2功能如何使用，情参考：https://community.transwarp.cn/article/250
Reduce 阶段合并
当小文件过多引起后续reduce任务数量暴增到一定值的情况下，引擎出于自我保护会中断任务并返回一些报错提醒，因此可以设置合理的reduce个数（mapred.reduce.tasks），以保证单reduce处理合适的数据量。
设置mapred.reduce.tasks数可以增加初始化性能，建议 500w数据量设置一个tasks。同时也可以按照文件的大小来设置tasks数据，如果小于500M，则设置为5，如果大于500M，则是文件大小/300M设置，根据hdfs上文件总大小合理控制。也可以将reduce数设定为集群vcore的一半，既保证vcore被充分利用，又不影响其他程序的工作。但是最终的mapred.reduce.tasks尽量小于1000。
总结
总的来说，在生产上小文件一直以来都是很棘手的问题，从上游到下游的各个步骤都有可能产生小文件问题，虽然技术上星环针对此类问题做了很多处理机制，但是如果要彻底预防和根治此类问题，还是需要尽可能从源头开始规范管理。从集群规划搭建，到各个业务系统表的设计，再到日常使用过程中SQL语句的规范编写，每一步都有可能减少后续小文件的产生。
以上就是有关小文件治理系列的全部内容，希望对您针对小文件问题的规避及治理思路有所帮助，有更多想要了解的内容，欢迎随时留言，谢谢阅读。
这篇关于小文件过多的解决方法（不同阶段下的治理手段，SQL端、存储端以及计算端）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
