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

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