商业活动的网站建设,企业门户网站的建设费用,前端做学校网站教务,深圳设计品牌网站上一篇介绍了小文件出现的原因以及为什么治理小文件问题迫在眉睫#xff0c;本篇将为读者讲述在不同阶段下小文件治理的最佳手段以及如何针对性的解决小文件过多的问题。
小文件过多如何解决、治理方法
小文件是特别常见的现象#xff0c;解决小文件问题迫在眉睫#xff0…上一篇介绍了小文件出现的原因以及为什么治理小文件问题迫在眉睫本篇将为读者讲述在不同阶段下小文件治理的最佳手段以及如何针对性的解决小文件过多的问题。
小文件过多如何解决、治理方法
小文件是特别常见的现象解决小文件问题迫在眉睫
一般来说一个任务是由几个步骤组成的而小文件的产生也来自任务的各个流程和步骤
上游 本地文件系统 HDFS Map Reduce FileSink
所以解决小文件问题就是需要从最前面的步骤中入手。而且解决小文件的隐患肯定也是越早越好就像过滤下推能尽早做的过滤条件一定是尽早过滤。
因此能在本地文件系统解决的问题没必要放到HDFS上解决。就像前面章节的内容所述HDFS本身就不适合存储大量小文件小文件过多会导致namenode元数据特别大, 占用太多内存严重影响HDFS的性能。
当前治理小文件的现有手段主要有以下几种
1SQL端规范
治理小文件的最优解一定是从源头集群规划设计和搭建开始就进行规范管理。比如在表结构和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代替ORSQL语句的WHERE子句中应尽可能将字段放在等式左边将计算操作放在等式的右边SQL语句的操作符两边类型应相同禁止潜在的数据类型转换建议用户在执行计算前通过类型转换使各操作数的类型匹配或者建表时尽可能的把字段安排成相同的数据类型。
2存储端合并
存储端合并主要是合并已经写入到存储的文件当表中有小文件或者小文件过多时可以使用下述存储端合并的方式进行合并以达到减少文件数量、降低存储开销提高数据读写效率的目的。存储端合并的方式主要适用于以下原因导致的小文件问题
频繁的写入数据torc表compact多次合并失败后进入黑名单导致小文件不再继续合并历史数据流程导致小文件问题这些数据一般是从别的数据库迁移过来后续没有进行治理
需要注意的是不同表格式如.TORC事务表、RCfile/ORC/Text等非事务表、星环自研Holodesk表的合并方式并不相同。
下一篇将介绍下星环不同表格式的合并方式即将发布
归档分区
除了针对上述表实现合并机制外星环分布式分析型数据库ArgoDB在6.0及后续版本中引入了归档分区的功能用户可以跨分区进行合并。归档分区的实现手段是用范围分区去表示单值分区适用于分区字段为离散类型的单值分区如日期 暂不支持时间戳类型、整数的场景。
通过分区归档合并功能可以将大量小文件归档前的单值分区合并成较大的文件归档后的范围分区从而减少存储开销、元数据管理的开销以及处理时的任务调度开销。
创建归档分区表
归档分区表的本质为范围分区表所以创建语句与创建范围分区表一致只需额外设置表参数archive_partitiontrue 来区分为归档分区表。支持直接创建归档分区表和修改普通范围分区表为归档分区两种方式。
分区合并
命令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语句的规范编写每一步都有可能减少后续小文件的产生。
以上就是有关小文件治理系列的全部内容希望对您针对小文件问题的规避及治理思路有所帮助有更多想要了解的内容欢迎随时留言谢谢阅读。
