解析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）对并发的查询数据进行限制。
更多大数据与分析相关行业资讯、解决方案、案例、教程等请点击查看>>>
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
