神刀安全网

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

解析IBM 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)对并发的查询数据进行限制。

更多大数据与分析相关行业资讯、解决方案、案例、教程等请点击查看>>>

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 解析IBM SQL-on-Hadoop的优化思路

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址