和impala_Impala最佳实践之一：Schema设计和物理设计

Schema设计

1

数据类型

◉使用的数值类型

尽量避免使用string类型string意味着更多的存储，更高的内存消耗，更慢的计算(比数值型慢80%)，例如日期类型“20201212”或者unix时间“1456754566”切换为bigint

◉Decimal vs Float/Double

Decimal更容易推理，目前不要将Decimal作为分区键或在UDF中使用

◉可以使用string的情况

• Hbase row key - string是推荐的类型

• TImestamp - 可以使用string，但也可以考虑使用数值型；

◉优先使用strng而不是Char/varchar(除了SAS)

1

分区设计

◉设计三原则

1. 分区键的选择需要根据用例的场景或者你的SQL来判断，比如最常用的条件。

2. 评估总的分区数(最好<100k)

3. 如果需要，减少分区数

◉估计分区数

• 结合需要存储的时间周期估计分区键的Distinct值(NDV)

• 总的分区数等于各级分区的NDV乘积

• 确保总分区数<=100k

◉分区数太多？

• 移除一些不重要的分区。如果一个分区键经常不使用也不影响服务等级协议(SLA)，移除它

• 可以使用月份作为分区而不是日期

• 人为创建store_group来分组stores

• 技术上使用前缀或Hash

1

Schema设计

◉字段的个数-2K Max

• 不是硬限制；Impala和Parquet可以处理更多。

• 会降低HIve Metasotre的更新和检索速度。

• 会导致大量的字段的统计信息元数据(stats metadata)，尤其是增量统计信息(incremental stats)。

◉TImestamp/Date

• 使用timestamp代替Date

• Date作为分区字段：使用string或int(20201112 as integerl)

◉BLOG/CLOG - 使用String

◉String size 

• 没有确定的上限，但是1MB是比较 合适的值

• 太大的string会导致impala的Crush

物理设计

1

文件格式

◉Parquet/Snappy

• 可以长期使用的存储格式

• 读取非常的快

• 写入非常的慢(比Avro慢10x)

◉Snappy VS Gzip

• Snappy通常是在要比和CPU之间一种合适的折中选择，但是还是基于你的实际情况运行一下benchmark再确认

◉Text

• 对于那些读一次写一次的临时表，考虑使用text，因为text的写入更快，无论读写impala也都支持text

1

Block Size

◉Block的数量决定了并发量

• 这一点同时适用于MR和impala，每个Block会被一个单独的CPU核处理。为了利用整个集群的CPU,num blocks >= num core

◉较大的block size意味着跟好的压缩和IO吞吐，但是会造成较少的block数，会减少并发数

◉较小的block size意味着更高的并发，但会减少IO吞吐，会造成元数据膨胀，以及造成HDFS Namenode，HIve Metastore和Impala catalog service的瓶颈

◉对于Parquet文件 256MB是比较好的选择，不要超过1GB，也不要小于64MB，除非你需要更高的并发

◉定期压缩表，以控制每个分区的文件数量，提高扫描和压缩的效率

Winter

2020