對(duì)于Big SQL的優(yōu)化，您需要注意以下六個(gè)方面：

1．平衡的物理設(shè)計(jì)

在進(jìn)行集群的物理設(shè)計(jì)需要考慮數(shù)據(jù)節(jié)點(diǎn)的配置要一致，避免某個(gè)數(shù)據(jù)節(jié)點(diǎn)性能短板而影響整體性能。而對(duì)于管理節(jié)點(diǎn)，它雖然不保存業(yè)務(wù)數(shù)據(jù)，但作為管理服務(wù)和BigSQL系統(tǒng)包空間的存儲(chǔ)，也需要配置一定數(shù)量的磁盤。另外，CPU／內(nèi)存／磁盤的配比要合理，用戶可以參考以下配置作為物理設(shè)計(jì)的基礎(chǔ)：

CPU：16核

內(nèi)存：128GB

硬盤：600GB * 2塊（系統(tǒng)使用），數(shù)據(jù)節(jié)點(diǎn)3TB * 12塊/管理節(jié)點(diǎn)3TB* 12塊

2. 并行的I/O

為了達(dá)到更高的I/O吞吐量，您需要盡量將數(shù)據(jù)分到多塊磁盤上。具體來說，您需要這樣的設(shè)置：

• 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. 合適的存儲(chǔ)格式

Big SQL支持多種格式，包括TEXT、SEQUENCE、RC、PARQUET、Avro、ORC等存儲(chǔ)格式。BigSQL會(huì)自動(dòng)根據(jù)文件格式選擇相應(yīng)的Reader以求最佳性能。選擇存儲(chǔ)格式需要在加載速度／壓縮比／查詢性能／收集統(tǒng)計(jì)信息速度之間折中。不同的存儲(chǔ)格式之間對(duì)比請(qǐng)參考《BigSQL支持的存儲(chǔ)格式和對(duì)應(yīng)的建表語句》。

對(duì)于Big SQL，Parquet通常是最優(yōu)的存儲(chǔ)格式。

4. 合理的內(nèi)存分配

每個(gè)節(jié)點(diǎn)上Big SQL所需內(nèi)存等同于DB2的INSTANCE_MEMORY，推薦的取值范圍是系統(tǒng)可用內(nèi)存的25%～75%。需要注意的是Big SQL和MapReduce之間是共用系統(tǒng)內(nèi)存的，如果Big SQL分配內(nèi)存較多，那么MapReduce可用內(nèi)存就少了，就有可能影響MR作業(yè)的性能。

Big SQL的Buffer pool只用于緩存臨時(shí)數(shù)據(jù)而不緩存用戶數(shù)據(jù)，這點(diǎn)與DB2有很大差異，對(duì)于排序堆相關(guān)的管理則與DB2一致。建議開啟STMM（自調(diào)優(yōu)內(nèi)存管理器）運(yùn)行一段時(shí)間，然后在工作負(fù)載和STMM調(diào)優(yōu)的參數(shù)穩(wěn)定之后再關(guān)閉。

5. 高效的執(zhí)行計(jì)劃

Big SQL沿用了DB2的SQL重寫和基于成本的優(yōu)化等功能。對(duì)于優(yōu)化器選擇成本最低的執(zhí)行計(jì)劃，統(tǒng)計(jì)信息起到關(guān)鍵作用。因此，每次數(shù)據(jù)發(fā)生較大變化時(shí)需要及時(shí)收集對(duì)應(yīng)表的統(tǒng)計(jì)信息。

另外，Big SQL自身不管理用戶數(shù)據(jù)，因此也不支持創(chuàng)建和維護(hù)索引。但是，Big SQL支持創(chuàng)建Primary Key，F(xiàn)oreign Key等約束。在不用考慮Index的時(shí)候，盡可能為數(shù)據(jù)表指定PK，F(xiàn)K等，這些約束有助于優(yōu)化器對(duì)SQL的優(yōu)化。

6. 其它建議

考慮對(duì)數(shù)據(jù)量大，具有合適的分區(qū)鍵（如查詢條件中需要使用“日期”字段）的表使用Range Partition。

選擇合適的數(shù)據(jù)類型，特別注意需要將Hive的string類型默認(rèn)映射到Big SQL是VARCHAR(32,672)，加上其它字段絕大多數(shù)情況都會(huì)超過32K的PageSize，從而導(dǎo)致性能下降。建議將Hive的string顯式地轉(zhuǎn)成較小的VARCHAR (n)。

如果并發(fā)查詢很多導(dǎo)致了CPU和內(nèi)存過分競(jìng)爭(zhēng)和系統(tǒng)性能下降，則要考慮使用WLM（Workload Management）對(duì)并發(fā)的查詢數(shù)據(jù)進(jìn)行限制。

詳情請(qǐng)咨詢“”！

客服熱線：023-66090381