故障现象：
用户反馈分析看板加载速度慢，在业务高峰期，看板页面还会有加载异常的情况。报表列表加载速度慢，严重时无法加载。用户在进行一些选项配置时，还会有一些加载超时或接口报错的情况。
前期处理：出现该问题后，用户侧运维认为是集群资源不足导致，遂进行了CDH集群节点资源扩容。扩容后集群负载如图，仅有一定程度的改善。节点CPU load在业务高峰期仍然处于打满的状态。问题未能得以解决。
排查思路：
通过检查CDH集群的计算节点，发现用户侧在管理集群时将hdfs的DataNode与kudu服务的Tablet Server一直混合部署在相同的节点上。hive组件与kudu组件的数据均通过Impala来进行驱动。虽然用户扩容了两台节点，也通过haproxy对Impalad进行了负载均衡。但是当查询处于高峰期时，混布了DataNode与Tablet Server的节点的CPU均被打满。造成大量请求超时，而新扩容的两台节点负载与资源使用率均不高。
混布了DN与TS服务的节点通过对数据库中各个表的排查与分析。用户配置的报表所涉及使用到的的数据表大多以kudu作为存储引擎。少量报表数据用于离线任务统计。会提交较为消耗资源的hive SQL任务。进一步加剧了节点资源的消耗。同时kudu与Impala的部分参数设置的不合理。导致请求大量积压排队。
解决方案：
- 在kudu中，每张数据表在创建时都会被分为若干个Tablet进行存储。当我们对数据查询时，本质上会去Tablet中检索数据。所以我们首先对tabletserver服务进行拆分，让Tablet Server角色分布到新加入集群的节点中。
- 通过reblance命令将Tablet分配至新扩容的节点上，让kudu在Tablet Server节点之间重新平衡Tablet。让tablet搬迁至新加入集群的节点中。以此让新加入集群的节点共同Impala对kudu数据请求任务。
- 对impala服务的并发参数进行调整，提高查询的并行度，同时根据节点内存资源消耗情况，调整default_pool_mem_limit的额度，避免在查询高峰期由于内存额度限制，导致查询请求排队或超时。以便更加充分的利用集群资源，更好的响应业务查询请求。
在重新调整优化后：
我们能够看到新加入集群的节点的磁盘，已经有kudu数据进行存储。在进行查询请求时，原有节点的资源使用率显著下降，集群节点整体负载趋于平稳。
用户侧的报表与看板也恢复正常。
后期规划：
- 推进集群存算分离架构的演化，将数据存储节点与计算节点彻底切分。避免在出现类似由于混布场景与参数不合理导致的集群异常，进而影响线上业务。
- 优化业务设计，尽量使用中间层来缓存计算任务的结果数据。避免每次刷新报表或看板都需要重新想集群提交查询计算任务，加重集群负担。
我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！
