关闭

解析IBM SQL-on-Hadoop的优化思路

标签: SQLhadoop大数据
303人阅读 评论(0) 收藏 举报
分类:
SQL-on-Hadoop

对于Big SQL的优化,您需要注意以下六个方面:

1.平衡的物理设计

在进行集群的物理设计需要考虑数据节点的配置要一致,避免某个数据节点性能短板而影响整体性能。而对于管理节点,它虽然不保存业务数据,但作为管理服务和BigSQL系统包空间的存储,也需要配置一定数量的磁盘。另外,CPU/内存/磁盘的配比要合理,用户可以参考以下配置作为物理设计的基础:

CPU:16核

内存:128GB

硬盘:600GB * 2块(系统使用),数据节点3TB * 12块/管理节点3TB* 12块

2. 并行的I/O

为了达到更高的I/O吞吐量,您需要尽量将数据分到多块磁盘上。具体来说,您需要这样的设置:

  • dfs.data.dir=/data1/hdfs,/data2/hdfs,/data3/hdfs,/data4/hdfs
  • bigsql_db_dir=/data1/bigsql,/data2/bigsql,/data3/bigsql,/data4/bigsql

注意bigsql_db_dir 目录在Big SQL的Head Node和Worker Node都需要具体同样的路径。

3. 合适的存储格式

Big SQL支持多种格式,包括TEXT、SEQUENCE、RC、PARQUET、Avro、ORC等存储格式。BigSQL会自动根据文件格式选择相应的Reader以求最佳性能。选择存储格式需要在加载速度/压缩比/查询性能/收集统计信息速度之间折中。不同的存储格式之间对比请参考《BigSQL支持的存储格式和对应的建表语句》。

对于Big SQL,Parquet通常是最优的存储格式。

4. 合理的内存分配

每个节点上Big SQL所需内存等同于DB2的INSTANCE_MEMORY,推荐的取值范围是系统可用内存的25%~75%。需要注意的是Big SQL和MapReduce之间是共用系统内存的,如果Big SQL分配内存较多,那么MapReduce可用内存就少了,就有可能影响MR作业的性能。

Big SQL的Buffer pool只用于缓存临时数据而不缓存用户数据,这点与DB2有很大差异,对于排序堆相关的管理则与DB2一致。建议开启STMM(自调优内存管理器)运行一段时间,然后在工作负载和STMM调优的参数稳定之后再关闭。

5. 高效的执行计划

Big SQL沿用了DB2的SQL重写和基于成本的优化等功能。对于优化器选择成本最低的执行计划,统计信息起到关键作用。因此,每次数据发生较大变化时需要及时收集对应表的统计信息。

另外,Big SQL自身不管理用户数据,因此也不支持创建和维护索引。但是,Big SQL支持创建Primary Key,Foreign Key等约束。在不用考虑Index的时候,尽可能为数据表指定PK,FK等,这些约束有助于优化器对SQL的优化。

6. 其它建议

考虑对数据量大,具有合适的分区键(如查询条件中需要使用“日期”字段)的表使用Range Partition。

选择合适的数据类型,特别注意需要将Hive的string类型默认映射到Big SQL是VARCHAR(32,672),加上其它字段绝大多数情况都会超过32K的PageSize,从而导致性能下降。建议将Hive的string显式地转成较小的VARCHAR (n)。

如果并发查询很多导致了CPU和内存过分竞争和系统性能下降,则要考虑使用WLM(Workload Management)对并发的查询数据进行限制。

via:本文转载自华南IBM大数据技术支持团队
1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:121337次
    • 积分:3146
    • 等级:
    • 排名:第11413名
    • 原创:194篇
    • 转载:23篇
    • 译文:0篇
    • 评论:5条
    最新评论