Hive小文件问题

Hive小文件问题,第1张

最近发现离线任务对一个增量Hive表查询越来越慢,推测是由小文件产生的

取HDFS查看确实存在480个小文件

于是合并小文件

这里采用distribute by进行小文件合并,通过rand()*5,保存从map端输出的文件最多输出到5个reducer,现在只剩下3个文件

小文件合并后同样的查询速度提升非常多。

因为此表格每天有数据进去,增量数据会单独生成一个小文件,日积月累生成大量小文件。小文件对Namenode内存造成压力,对map端文件合并也有很大压力

1.动态分区插入数据,会产生大量小文件

2.数据源本来就含有大量小文件

3.数据增量导入,如Sqoop数据导入,增量insert导入数据等

4.分桶表

5.可以修改的表,此种表有一个快照,随时间增加数据越来越大

1.给NameNode内存中fsImage合并造成压力

2.未开启小文件合并,每个文件一个MapTask,集群资源浪费

3.Map端设置小文件合并,单小文件 太多查询缓慢

Hive已经对小文件做了许多优化,只需修改配置文件即可

如果原表有大量小文件,在导入目标表的时候也会产生大量小文件。如果有分区如dt、hour,可以使用 distribute by dt,hour,

保证每小时数据在一个reduce里面

类似于增量导入数据,会存在小文件,需要进行一天或者一周的定时文件合并

将test表中的数据查询出来,在overwrite覆盖表test,不必担心失败数据没有,这里面是有事务保证的。

若是分区表则加上partitiom,标识对分区进行overwrite

ORC格式的表可以使用

进行小文件合并,这种方法仅适用于ORC格式存储的表

使用函数concat

select concat(a,'-',b) from就可以实现了。

hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的sql查询功能,可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具,可以用来进行数据提取转化加载(ETL),这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言,称为 HQL,它允许熟悉 SQL 的用户查询数据。同时,这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

Hive 是一种底层封装了Hadoop 的数据仓库处理工具,使用类SQL 的HiveQL 语言实现数据查询,所有Hive 的数据都存储在Hadoop 兼容的文件系统(例如,Amazon S3、HDFS)中。Hive 在加载数据过程中不会对数据进行任何的修改,只是将数据移动到HDFS 中Hive 设定的目录下,因此,Hive 不支持对数据的改写和添加,所有的数据都是在加载的时候确定的。Hive 的设计特点如下。

● 支持索引,加快数据查询。

● 不同的存储类型,例如,纯文本文件、HBase 中的文件。

● 将元数据保存在关系数据库中,大大减少了在查询过程中执行语义检查的时间。

● 可以直接使用存储在Hadoop 文件系统中的数据。

● 内置大量用户函数UDF 来 *** 作时间、字符串和其他的数据挖掘工具,支持用户扩展UDF 函数来完成内置函数无法实现的 *** 作。

● 类SQL 的查询方式,将SQL 查询转换为MapReduce 的job 在Hadoop集群上执行。

最近在做项目的时候需要对数据组埋点得到的数据进行合并:

1.原始数据我需要拿到post_id,district_id字段,而一个post可能投放到同一城市的多个district,而在后期使用数据时,需要的数据形式是同一个post_id的记录不可以因为多个district产生多条记录,因此需要将多个district合并为一个值;

2.而在原始表中,district_id的值是INT类型;

3.需要对字段进行去重。

因此,我进行了如下 *** 作:

select

        post_id,

        concat_ws(',',collect_set(string(district_id))) district_id

from

        ods.ods_jz_post_address

group by post_id

***若不需要去重,可选择collect_list()函数代替collect_set(),具体语法请自行查找***


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/tougao/7950238.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-11
下一篇 2023-04-11

发表评论

登录后才能评论

评论列表(0条)

保存