一、Impala基础知识

最新推荐文章于 2023-07-04 23:25:01 发布

斗罗昊天锤

最新推荐文章于 2023-07-04 23:25:01 发布

阅读量2.8k

点赞数 2

分类专栏： # Impala组件文章标签： impala

本文链接：https://blog.csdn.net/xuanalex/article/details/105294613

版权

Impala组件专栏收录该内容

5 篇文章 3 订阅

订阅专栏

一、Impala组件插入数据

1、连接：

impala-shell -i "10.7.67.103:21000" -u edq -q "CREATE DATABASE IF NOT EXISTS SHDATA"
## 插入单条数据
INSERT OVERWRITE TABLE TABLEINFO.TD_IMPALA_TYPE VALUES(CAST("BIGINT" AS VARCHAR(20)), 
CAST("BIGINT" AS VARCHAR(20)));
## 插入多条数据，使用逗号分开
INSERT OVERWRITE TABLE TABLEINFO.TD_IMPALA_TYPE VALUES(CAST("BIGINT" AS VARCHAR(20)), 
CAST("BIGINT" AS VARCHAR(20))),(CAST("BIGINT" AS VARCHAR(20)), CAST("BIGINT" AS VARCHAR(20)));

2、静态插入指定分区

INSERT OVERWRITE TABLE TDSHDATA.IDA_CD_INDIV_TXN_AMT_STAS 
PARTITION(TXN_DT = CAST('2017-01-01' AS ARCHAR(50))) 
SELECT AGMT_BELONG_ORG_NUM,BRIF_INFO_CD,BRIF_INFO_DESC,TXN_NET_AMT 
FROM DSDATA.IDA_CD_INDIV_TXN_AMT_STAS;

3、添加分区

ALTER TABLE TDSHDATA.IDA_CD_INDIV_TXN_AMT_STAS 
ADD IF NOT EXISTS PARTITION(TXN_DT = CAST('2017-01-01' AS VARCHAR(50)));

4、动态分区插入数据

INSERT OVERWRITE TABLE TDSHDATA.IDA_CD_INDIV_TXN_AMT_STAS PARTITION(TXN_DT) 
SLECT AGMT_BELONG_ORG_NUM,BRIF_INFO_CD,BRIF_INFO_DESC,TXN_NET_AMT,TXN_DT 
FROM TDSDATA.IDA_CD_INDIV_TXN_AMT_STAS;

5、清空表数据

TRUNCATE TABLE IF EXISTS TABLENAME;

6、refresh刷新分区信息 – 注：分区规范必须包含所有分区键列。

创建分区表：

CREATE TABLE IF NOT EXISTS TDSHDATA.T03_AGREEMENT (`AGMT_NUM` CHAR(40) COMMENT '协议号'
,`AGMT_MODIFIER_NUM` CHAR(8) COMMENT '协议修饰符'
,`AGMT_CATEG_CD` CHAR(2) COMMENT '协议类别代码'
,`ETL_PROC_DT` TIMESTAMP COMMENT 'ETL首次插入日期') 
-- COMMENT '协议表' （Hive的写法，写在这里声明表的中文名）
PARTITIONED BY(`AGMT_SRC_SYS_ID` CHAR(4) COMMENT '协议来源系统编号')  
-- COMMENT '协议表' （Impala的写法，写在这里声明表的中文名）
STORED AS parquet;

刷新表信息：

REFRESH TABLENAME PARTITION (PARTITION_COLUMN_NAME = CAST('VALUES' AS TYPE));

7、可以设置同一张表的不同分区的文件格式

CREATE TABLE TEST(NAME STRING) PARTITIONED BY(YEAR SMALLINT);
ALTER TABLE TEST ADD PARTITION(YEAR=2012); --- Text Format;
ALTER TABLE TEST ADD PARTITION(YEAR=2013);
ALTER TABLE TEST PARTITION(YEAR=2013) SET FILEFORMAT PARTQUET;

8、查看表的状态或者字段状态

SHOW TABLE STATS TABLENAME;  示例： SHOW TABLE STATS TDSHDATA.T03_AGREEMENT;
SHOW COLUMN STATS TABLENAME;  示例：SHOW COLUMN STATS TDSHDATA.T03_AGREEMENT;

9、执行SQL文件

impala-shell -i "10.7.67.103:21000" -u edq -f "impala_create_table.sql"

10、导出数据到指定的文件

impala-shell -i "ip:21000" -q "SQL 语句" -B -o /tmp/data.txt

二、Impala减少小文件

1、解决办法

通过设置：NUM_NODES=1，强制Impala使用一个节点Daemon来处理真个Query，因此最终只会输出一个文件到HDFS。
缺点：这样会导致单个主机的资源利用率增加，SQL运行缓慢，超出内存限制或查询挂起等。

三、Impala使用的一些技巧

3.1、物理和Schema设计 – 数据类型

3.1.1、使用数值类型而不是String类型

1.1、尽量避免使用String类型
1.2、String类型更高的内存消耗，更多的存储，更慢的计算（比数值类型慢80%）

3.1.2、Double VS Float/Double

1.1、Decimal类型更容易推理
1.2、目前不要把Decimal作为分区键或者UDF中使用

3.1.3、以下情况可以使用String

1.1、HBase Row key -- String 是推荐的类型
1.2、TimeStamp -- 可以使用String，但是也可以考虑使用数值类型

3.2、分区设计

3.2.1、评估总的分区数最好 小于 100K!
3.2.2、移除一些不重要的分区（如果一个分区不经常使用，然后也不影响SLA，移除它）。
3.2.3、Create partition "buckets" and specify bucket id in downstream select queries.
	  （在下游选择查询中创建分区“桶”并指定桶id。）
	1.1、使用月份做分区，而不是日期
	1.2、人为创建store_group来分组stores
	1.3、技术上：使用前缀或者Hash
		1.3.1、Hash(store_id)%store_group size => hash it to store_group
		1.3.2、Substring(store_id,0,2) => 使用前两位作为创建的store_group
		例如：select …… from TBNAME where store_id = 5 and store_group = store_id%50

3.3、Schema设计 – 常见问题

3.3.1、字段个数 --2K max

缺点：太多的字段会降低Hive Metastore的更新和检索速度。

3.3.2、Timestamp/Date

1.1、使用Timestamp替代Date
1.2、Date作为分区字段，使用Sting或Int

3.3.3、BLOB/CLOB — 使用String

1.1、String size没有确定上限，1MB还是可以，太大会有问题
缺点：太大String 会导致Impala的Crash
解决办法：可以将太大的String类型字段分开，最后在拼接起来

3.4、物理设计 – 文件格式

3.4.1、Parquet/Snappy — Parquet

优点：可以长期使用的文件格式，读取非常快。
缺点：写入非常慢，比Avro慢十倍

3.4.2、Snappy/Gzip — Snappy

Snappy通常是在压缩比与CPU之间更好的一中折中

3.4.3、对于读写一次的ETL临时表，可以考虑使用 TEXT 格式

优点：写入快，无论读写Impala都支持

3.5、物理设置 – Block Size – 256MB

四、Impala的性能调优

注：根据你运行的查询，知道如何使其更快运行以及消耗更少的资源;

总是使用Compute Stats;
检查查询的逻辑;

使用Explain Plan进行验证：
在这里插入图片描述
运行分析：使用Query Profile识别瓶颈和倾斜

使用summary查看运行瓶颈：

4.1、查询调优基础知识 – 更多关于 Compute Stats（统计元数据）

1.1、只有数据发生较大变化（超过30%）时才重新执行统计信息;
1.2、Compute Stats基于表执行，而不是视图。

4.2、查询调优基础知识 – Incremental Stats Maintenance（增量数据维护）

1.1、Compute Stats非常慢，而且Impala2.0之前不支持Incremental Stats;
1.2、Column Stats(distinct值，min,max)可以不用频繁的使用Compute Stats来更新，除非超过30%修改了;
1.3、当增加一个新的分区，可以基于分区运行Count(*), 然后把这个结果通过Alter Table手动更新到Partition row count stats;
	语法：COMPUTE INCREMENTAL STATS [DB_NAME.]TABLENAME [PARTITION(PARTITION_SPEC)]
		  PARTITION_SPEC :: = PARTITION_COL=CONSTANT_VALUE
	例如：COMPUTE INCREMENTAL STATS TABLENAME PARTITION(TXN_DT = '2018-09-21');
		  COMPUTE INCREMENTAL STATS TEST PARTITION(X < 100);
		  COMPUTE INCREMENTAL STATS TEST PARTITION(X in(100,200,300));
		  COMPUTE INCREMENTAL STATS TEST PARTITION(X between 100 and 175);
		  COMPUTE INCREMENTAL STATS TEST PARTITION(X != 100);
		  COMPUTE INCREMENTAL STATS TEST PARTITION(X < 100 or X != 200);
1.4、也可以通过Alter Table手动更新column stats。
1.5、Impala2.1及以后的版本支持”Compute Incremental Stats“,但请仅在以下情况下使用：
	1.1、对于那些所有使用Incremental stats 的表，∑（num columns * num partitions） < 650000;
	1.2、整个集群少于50个节点;
	1.3、对于每个表，num columns * num partitions * 400B < 200MB。

4.3、查询调优基础知识 – 检查查询逻辑

1.1、有时查询中有多余的joins，distinct，group by， order by（迁移中很常见）移除它;
1.2、对于常见的一些join，考虑预join这些表;
1.3、使用join例如：select fact.col, max(dim2.col) from fact,dim1,dim2
								where fact.key = dim1.key and fact.key2 = dim2.key;
								dim1上的join应该是一个semi-join!

4.4、查询调优基础知识 – 通过Explain Plan验证

4.4.1、关键点：

1.1、验证Join顺序和Join策略
	1.1.1、Join顺序：RHS比LHS小;
	1.1.2、Join策略 -- BROADCAST：RHS必须能装进内存。
	1.1.3、常见的Join性能问题：
		1.1、Hash Table：
			理想情况下，Join键应均匀分布，只有几行共享来自RHS的相同Join键;
			它是真正的外键Join还是更像是范围Join？
		1.2、错误的Join顺序从执行计划来看，RHS表比LHS表更大;
		1.3、LHS表有太多行。
1.2、验证分区剪裁或HBase Rowkey扫描

4.4.2、即使有stats信息，有时自动的join顺序/策略也可能错误（尤其基于视图）。

解决办法：可以通过STRAIGHT_JOIN强制指定Join顺序。

4.4.3、通过CM监控页面发现查询瓶颈和数据倾斜。

4.4.4、聚合性能调优 – 降低group by 中表达式的复杂度。

4.5、查询调优基础知识 – Codegen

4.5.1、在CDH5.9或者之前的版本，Codegen拥有最小成本（~500ms）.对于简单的短查询（<2s），大部分时间
都用于Codegen的准备和优化，禁用Codegen可以提高更多吞吐。
注：从CDH5.10开始，这个成本被降低到10~20%
4.5.2、可以通过设置查询选项禁用Codegen：set disable_codegen=1;
4.5.3、有一些数据类型不支持（char，timestamp）;

4.6、查询调优基础知识 – Runtime filter and dynamic partition pruning(CDH5.7/impala 2.5 or Higher)

4.6.1、通过减少IO，Hash Join和网络流量，提高非常有选择性的equi-join的查询性能。

1.1、如果Join在分区列上，则Impala可以使用Runtime Filter动态裁剪probe side 分区，跳过整个文件。它不仅
可以提高性能，还可以减少查询资源的使用（内存和CPU）;
1.2、如果Join位于非分区上，则Impala可以生成Bloom过滤器。这可以大大降低probe side的扫描输出和中间结果。

4.6.2、怎样调优它？

1.1、增加RUNTIME_FILTER_WAIT_TIME_MS到5000ms，让Scan Node 03位filter等待更长的时间。
1.2、如果集群相对繁忙，请考虑增加等待时间，以便复杂查询不会错过优化的机会。

4.6.3、支持什么文件格式？

1.1、分区过滤：所有文件格式，只要它是分区表，并且存在分区列的映射。
1.2、行过滤  ---  只使用与Parquet 格式
1.3、Parquet可以最好的利用Runtime Filters。

4.6.4、Runtime Filter Gotcha？

1.1、Runtime Filters对于每台主机需要额外的内存，对于Coordinator有额外的工作。
	例如：on 100-node cluster，one 16MB filter?
	1.1、Memory cost,16MB*100=1.6GB for query
	1.2、Network cost(only for GLOBAL mode) 16MB*100*2=3.2GB network traffic on coordinator,and CPU time to merge and publish filters.
	1.3、更多的filters，更高的成本。
1.2、负面影响：Coordinator会成为瓶颈
1.3、解决方案：
		通过设置MAX_NUM_RUNTIME_FILTERS为一个更低的数值来减少filter的数量，或者通过设置
	DISABLE_ROW_RUNTIME_FILTERING=1禁用行过滤。

4.7、设置Impala运算时内存溢出写入到磁盘运算 – 这个很少使用

设置参数：SET DISABLE_UNSAFE_SPILLS=0/FALSE
注：会减缓SQL运算的效率，不是所有的SQL都会触发写入磁盘操作，比如union all 操作等

4.8、关于一些配置的优化

1、启用block location跟踪：因为Impala在查询的时候会在多个datanode上分布式的读取数据，如果Impala拥
有更多的block信息，将会更高效的获取数据并处理。
2、启用native checksumming：对大量数据计算校验（checksum）会带来巨大的时间损耗，因此采用本地库
（native library）来执行校验，会带来性能上的提升，在CDH上默认是启用了本地校验，如果手动安装Impala
必须手动安装Hadoop本地库libhadoop.so。
3、允许Impala执行shor-circuit read：这意味着Impala会从datanode的本地文件系统直接读取数据，而不用首
先与datanode通信，这肯定会提高性能。

五、安装HAProxy配置Impala负载均衡

5.1、安装步骤：10.7.67.100

1.1、yum安装：yum -y install haproxy
1.2、启动与停止HAProxy服务，并将服务添加到自启动列表
	设置自启：systemctl enable haproxy.service
	启动haproxy：systemctl start haproxy    -- 状态查看：systemctl status haproxy 
	停止haproxy：systemctl stop haproxy
1.3、添加如下配置
	备份原有的配置文件: /etc/haproxy/haproxy.cfg
	在配置文件中添加如下配置：

在这里插入图片描述

1.4、重启服务：systemctl restart haproxy
1.5、页面管理登录页面：http://10.7.67.100:1080/stats
1.6、Shell命令行连接：impala-shell -i 10.7.67.100:25003
	注：HAProxy装载那个节点上就连接那个IP地址，它会通过配置自动负载Impala Daemon连接。