本文主要是介绍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.去掉冗余监控指标
这篇关于phoenix调优小记的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
