Hive模式设计

本文讨论了Hive模式设计,强调了分区的重要性和最佳实践。按时间粒度进行分区可以保持数据吞吐量并优化查询效率,但过度分区可能导致大量小文件,影响性能。介绍了避免标准化的原因,主要是为了减少磁盘寻道,提高I/O性能,但可能增加数据重复和不一致性风险。此外,还提及了分桶表作为优化存储的一种策略。
摘要由CSDN通过智能技术生成

Hive模式设计

关于分区

HDFS用于设计存储数百万的大文件,而非数十亿的小文件,使用过多分区可能导致的一个问题就是会床架内大量的非必须的Hadoop文件和文件夹。在 《Hive编程指南》中,之前的解决方案是将数据转存在Amazon S3上。

MapReduce 会将一个任务(job)转换成多个任务(task)。默认情况下,每个task 都是一个新的JVM实例,都需要开启和销毁的开销。对于小文件,每个文件都会对应一个task。
在一些情况下,JVM开启和销毁的时间中销毁可能会比实际处理数据的时间消耗要长!
因此,一个理想的分区方案不应该导致产生太多的分区和文件夹目录,并且每个目录下的文件应该足够得大,应该是文件系统中块大小的若干倍。

按时间分区的优点

按时间范围进行分区的一个好的策略就是按照不同的时间粒度来确定合适大小的数据积累量,而且按照这个时间粒度。随着时间的推移,分区数量的增长是“均匀的”,而且每个分区下包含的文件大小至少是文件系统中块的大小或块大小的数倍。这个平衡可以保持使分区足够大,从而优化一般情况下查询的数据吞吐量。同时有必要考虑这种粒度级别在未来是否是适用的,特别是查询中WHERE子句选择较小粒度的范围的情况;
另一个解决方案是使用两个级别的分区并且使用不同的维度。

例如,第一个分区可能是按照天(day)进行划分的,而二级分区可能通过如州名(state)这样的地理区域进行划分;
然而,由于

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值