HIVE相关问题


1)Hive数据倾斜问题:

倾斜原因: map输出数据按Key Hash分配到reduce中,由于key分布不均匀、或者业务数据本身的特点。】【等原因造成的reduce上的数据量差异过大。
1.1)key分布不均匀
1.2)业务数据本身的特性
1.3)SQL语句造成数据倾斜
解决方案:
1>参数调节:
hive.map.aggr=true
hive.groupby.skewindata=true
有数据倾斜的时候进行负载均衡,当选项设定为true,生成的查询计划会有两个MR Job。第一个MR Job中,Map的输出结果集合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同Group By Key有可能被分发到不同的Reduce中,从而达到负载均衡的目的;第二个MR Job在根据预处理的数据结果按照 Group By Key 分布到Reduce中(这个过程可以保证相同的 Group By Key 被分布到同一个Reduce中),最后完成最终的聚合操作。
2>SQL语句调节:
1)选用join key 分布最均匀的表作为驱动表。做好列裁剪和filter操作,以达到两表join的时候,数据量相对变小的效果。
2)大小表Join: 使用map join让小的维度表(1000条以下的记录条数)先进内存。在Map端完成Reduce。
3)大表Join大表:把空值的Key变成一个字符串加上一个随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终的结果。
4)count distinct大量相同特殊值:count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在做后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union.

2)请说明hive中 sort by ,order by ,cluster by ,distribute by各代表什么意思。

order by :会对输入做全局排序,因此只有一个reducer(多个reducer无法保证全局有序).只有一个reducer,会导致当输入规模较大时,需要较长的计算时间。
sort by :不是全局排序,其在数据进入reducer前完成排序
distribute by :按照指定的字段对数据进行划分输出到不同的reduce中
cluster by :除了具有distribute by 的功能外还兼具sort by 的功能

3)描述数据中的null,在hive底层如何存储

null在hive底层默认是用"\N"来存储的,所以在sqoop到mysql之前需要将为null的数据加工成其他字符,否则sqoop提示错误

4)Hive中 split、coalesce以及collect_list函数的用法 split将字符串转化为数组

coalesce(T v1,T v2,...) 返回参数中的第一个非空值;如果所有值都为null,那么返回null
collect_list列出该字段所有的值,不去重 select collect_list(id) from table;

5)将文件导入到hive表中

load data local inpath ‘/a.txt’ overwrite into table test partition(xx=‘xx’)

6)Hive文件压缩格式有哪些,压缩效率如何 开启压缩

set hive.exec.compress.output=true;
set mapred.output.compress=true;
set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;
set io.compression.codec=org.apache.hadoop.io.compress.GzipCodec;
set mapred.output.compression.type=BLOCK;
TextFile (压缩方式Gzip,Bzip2压缩后不支持split)
SequenceFile
RCFile(存储方式:数据按行分块,每块按列存储。结合了行存储和列存储的优点)
ORCFile

7)Hive的分组方式

row_number() 是没有重复值的排序(即使两天记录相等也是不重复的),可以利用它来实现分页
dense_rank() 是连续排序,两个第二名仍然跟着第三名
rank() 是跳跃排序的,两个第二名下来就是第四名

### Hive 使用问题 Hive 是基于 Hadoop 构建的数据仓库工具,广泛用于大数据的批处理和分析。其使用过程中常见问题包括查询执行缓慢、元数据配置错误以及与 Hadoop 的集成问题等。 - 查询性能低下是 Hive 使用中最常见的问题之一。这通常与 SQL 语句编写方式、分区策略、文件格式选择等因素有关。 - 元数据配置错误可能导致 Hive 表无法访问或元数据丢失,影响任务正常运行。例如,Hive Metastore 配置不正确会导致连接失败[^3]。 - Hive 对接 Hadoop 时路径配置错误也可能导致任务失败,如 `hive-env.sh` 中未正确设置 Hadoop 安装路径[^3]。 ### Hive 配置问题 Hive 的性能和稳定性在很大程度上依赖于合理的配置设置。主要配置包括执行引擎、内存管理、并行执行等。 - 执行引擎可选择 MapReduce、Tez 或 Spark。其中 Tez 提供了更高效的 DAG 执行模型,适用于复杂查询场景[^4]。 - 内存配置方面,可通过 `hive.tez.container.size` 和 `hive.tez.java.opts` 设置容器大小和 JVM 堆内存,提升任务执行效率[^1]。 - 并行执行优化可通过 `hive.exec.parallel=true` 开启,允许多个阶段并发执行,减少整体执行时间[^1]。 此外,`.hiverc` 文件可用于设置默认参数,但会话级别的 `SET` 指令优先级更高[^5]。 ### Hive 错误处理 Hive 的错误类型多样,涉及语法错误、元数据异常、执行失败等多个层面。掌握其核心组件交互流程有助于快速定位问题: - **解析阶段**:SQL 语法错误会在该阶段被检测出。 - **获取元数据阶段**:表不存在、字段名错误等问题在此阶段暴露。 - **生成执行计划与优化阶段**:逻辑计划不合理(如未进行分区剪枝)会导致性能下降。 - **执行引擎(MR/Tez/Spark)阶段**:资源不足、数据倾斜等问题可能引发任务失败[^4]。 对于错误排查,应结合 HiveServer2 日志、YARN 应用日志及 Hive Metastore 日志进行分析。 ### Hive 优化技巧 Hive 查询性能优化需从多个维度入手: #### SQL 优化 - **过滤条件前置**:将 WHERE 条件提前,减少中间结果集大小。 - **分区剪枝**:确保分区字段作为查询条件的一部分,避免全分区扫描。 - **合理使用 Join**:小表驱动大表(Map Join)、避免笛卡尔积、使用 Bucket Map Join 提升 Join 效率。 #### 配置优化 - **启用本地模式**:对于小数据集查询,可开启 `hive.exec.mode.local.auto=true`,避免启动分布式任务带来的开销。 - **压缩输出**:通过 `hive.exec.compress.output=true` 启用中间和最终输出压缩,节省 I/O 资源。 - **调整并行度**:根据集群资源设置 `hive.exec.parallel.threads` 控制并行任务数量[^5]。 #### 资源优化 - **执行引擎选择**:Tez 相较于 MapReduce 更适合复杂 DAG 任务,Spark 则更适合迭代计算。 - **动态分区**:使用 `hive.exec.dynamic.partition.mode=nonstrict` 支持动态插入分区,提高灵活性。 - **分桶与索引**:对高频查询字段建立分桶,可加速采样和 Join 操作;建立索引可加快特定查询速度。 #### 数据存储优化 - **列式存储格式**:使用 ORC、Parquet 等列式存储格式可显著提升查询效率,尤其在只读取部分字段时。 - **合并小文件**:过多小文件会增加 NameNode 压力,可通过 `hive.merge.mapfiles=true` 自动合并输出文件。 ```sql -- 示例:ORC 存储格式建表语句 CREATE TABLE sales ( order_id STRING, customer_id STRING, amount DOUBLE ) STORED AS ORC; ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值