phoenix调优小记

从17年调优到了18年，数据从100机器每天1200万，不到两星期累加到了小2个亿数据。

数据插入和查询效率都很低。

1.5 15:52
0: jdbc:phoenix:localhost:2181> select count(*) from METRIC_RECORD;
+-----------+
| COUNT(1)  |
+-----------+
| 34244885  |
+-----------+
1 row selected (116.131 seconds)

大小6g左右。

一。统计数据

17年1228统计数据，数据数目1亿5千万，机器92台，40%入库时间超过10s，3%查询时间超过5s。

17年1229统计数据，数据数目1亿6千万，机器120台，50%入库时间超过10s，10%查询时间超过20s。

18年0102统计数据，数据数目3千万(增加ttl)，机器150台，1%入库时间超过500ms，1%查询时间大于1000ms，聚合大部分失效(聚合超时60s)。

18年0103-4region统计数据，数据数目3千万，机器174台，1%入库时间超过500ms,1%查询时间大于1000ms，40%聚合超时60s

18年0103-8region统计数据，数据数目3千万，机器174台，20%聚合超时60s。

18年0104-8region统计数据，数据数目3千万，机器174台，10%入库时间超过2s，10%查询时间超过2s，10%聚合超时60s。

18年0105统计数据，数据数目3千万，机器174台，10%入库时间超过2s，10%查询时间超过2s，。

18年0106统计数据，数据数目3千万，机器174台，1%入库时间超过1s，10%查询时间超过500ms，60s，5%聚合超过60s。

18年0107统计数据，数据数目3千万，机器174台，聚合时间10%大于50s，5%大于60s

二。重大优化点：

1.1229增加ttl，数据会定期失效，减少总的数据量。

2.0102拆分region，初始拆分成4份。

3.0103 18：27再度拆分，拆分成8份。

4.0105 10：30-11：00 迁移regionserver，每台regionsever 4个region，共2台regionserver

5.0105 11：20-11：23 迁移regionserver，每台regionsever 2个region，共4台regionserver

    hadoop069 两个
    hadoop070 两个
    hadoop071 两个
    hadoop072 两个

6. 诡异现象，从0106开始，yarnmetric查询延时从10s降到1s以内；聚合失败率从10%降到了5%以下，甚至更低。

     初步推测为region迁移带来的性能提升。

三。分析：

1.ttl效果明显，数据由线性增长，稳定在3000w(170机器)

2.拆分region，有效降低插入和查询时间。

3.拆分region，可以相对有效减少聚合时间，但还是10%聚合失效，如扩展到500台，压力还是很大。

4.迁移region，减少regionserver压力，0105中午迁移后，插入延时缩减明显，写入压力被有效分散了；但是yarnmetric查询延时还是很高。

5.看了下region的本地化率，因为原来都是hadoop069，所以数据基本都在hadoop069；yarnmetric相关的region被分配到了hadoop071节点，导致本地化率很低，低于1%。

因为yarnmetric数据量较大，且查询方式比较特殊，涉及到跨region查询，所以怀疑本地化率过低导致数据查询缓慢。
再次调整region所在regionserver，将yarnmetric相关region挪回hadoop069,其他指标相关region挪到其他regionserver。
迁移后，yarn相关region本地化率95以上，但是查询速度还是很慢。

四。todo：

1.确认性能提升原因

2.0105 排查到yarnmetric查询因为没有host字段，查询与其他指标查询不一样，

测试结果反映当查询语句包含host is null时，查询速度有近10倍的提升，查询延时500ms。
当查询语句包含host = ”无法查询到有效结果。

此结果

3.rowkey优化，appid过长

4.去掉冗余监控指标