B站工作内容总结

最新推荐文章于 2024-10-01 18:51:18 发布

璇转的鱼

最新推荐文章于 2024-10-01 18:51:18 发布

阅读量640

点赞数

文章标签： java

本文链接：https://blog.csdn.net/weixin_44315471/article/details/120946806

版权

B站工作内容总结

1. 实习概况

从2021.6.24 到 2021.9.15 在b站数据平台部-OLAP交互式分析组（目前部门该名：基础架构部）实习了3个月的时间。实习期间主要负责：数据平台部内部的ClickHouse监控管理平台的开发；主要的职责为：负责ClickHouse监控管理平台的前端以及后端相关模块的开发工作；主要完成的开发任务：KillQuery模块、Monitor模块、Overview模块、Query模块的前后端开发，其中前三个模块完全独立的开发完成前后端的功能，而Query模块是在原本的基础上进行添加新功能。接下来会针对实习期间完成的4个模块进行详细描述。（另外附上两张b站公司的图片！环境还是很棒的！）

b站办公楼
公司内部
上面两张图显示了b站总部的一些外观信息，b站的二次元氛围很浓重（非常浓重），主楼也是一些b站知名up主经常聚集的地方，工作环境挺不错的。另外就是，实习所在的部门以及OLAP组内成员都非常的友善，有问题都是会耐心帮我解答，工作氛围也非常不错，没有遇到过pua等等。总的来说，b站对于有二次元信仰的人来说是个非常不错的选择呢（可惜我对二次元不感兴趣！！！）。

2. KillQuery模块（大致描述）

开发背景及意义：ClickHouse引擎主要用来进行分析的，所以处理速度非常快，基本能在秒级甚至亚秒级进行响应，因此对于一条查询来说，如果它一直长时间的执行，一方面会危害到集群，造成集群本身的不稳定性，另一方面，也违反了ClickHouse快速响应的要求，这些超时查询基本上没有什么作用，因此需要对超时查询进行Kill，以增加集群自身稳定性。

主要完成的任务：

配置文件配置超时阈值，读取配置文件获取ClickHouse集群中查询的超时阈值，启动定时任务，定时搜索ClickHouse数据库processes_dst表，找出超时查询并进行Kill操作，记录Kill的时间
搜索ClickHouse的query_log_dst表，对Kill的查询信息进行一些字段补充，将被Kill的查询记录到缓存的同时，持久化到本地表和分布式表
将Kill操作和持久化操作分离，以多线程方式，一个线程负责扫描集群数据库获取超时查询并执行Kill，并将其加入阻塞队列，由另一个线程去队列取查询进行持久化，使用ConcurrentHashMap优化Kill查询入队的一些细节
对被Kill掉的查询进行告警处理，将被Kill的查询信息发送到企业微信群，并通知ClickHouse的用户
编写KillQuery模块的前端界面显示功能，对Kill的查询信息进行显示，方便组内成员从监控管理平台直接可以查看到Kill的信息

部分功能截图：

总体KillQuery模块流程图：

总结：这个模块第一个开发完成的模块，也是接手项目后第一个做的模块。期间遇到过很多困难，比如从最开始接手时，对整个项目采用的JdbcTemplete模块不熟悉（没有实战过），对代码里面用的lambda表达式也不熟悉，部分代码甚至都看不懂。最大的困难就是对ClickHouse不熟悉，之前根本就没接触过，所以对一些代码中的逻辑操作不懂，对操作的system库的各个表的字段也完全不懂。为了完成任务，开始对不懂的地方进行一一突破，最终成功完成了第一代版本。后续对这个模块不断的进行了优化，比如添加阻塞队列分离Kill和持久化操作（原本没有分离），添加ConcurrentHashMap等进行出入队逻辑细节上的优化，对反复Kill不掉的任务进行企业微信群告警处理等等，优化了很多细节。总的来说，这是我做的第一个模块，万事开头难，大概用了一个月才完成这个模块的开发，接下的模块的开发就顺利了很多，自学能力也得到了锻炼，学习了解了ClickHouse等原本不了解的东西。

3. Monitor模块（大致描述）

开发背景及意义：通过监控ClickHouse的一些指标来判断是否需要对某些操作进行优化，比如：ClickHouse本身在插入操作时，单次批插入的越多，性能越好，越快，如单次批插入10000条数据；可以通过 cur_insert_into_rows[TOP20 ASC] 指标来查看当日插入行数顺序前20条数据，看看这些操作插入了多少行数据，由此判断是否需要优化，比如一次多插入点数据。

16个明细监控指标为：

主要完成的任务：

编写调试16个监控指标的相关的ClickHouse查询的SQL语句，针对各个集群进行查询，查询出各个集群中的指标信息，方便排除问题，或者进行优化查询等操作
Monitor后端16个指标接口的代码编写，完成相应指标的查询功能，通过接口测试工具swagger进行初步测试
Monitor前端界面的开发：对16个指标根据选择的集群，分别进行显示

部分功能截图：

总结：这个模块比较简单，只需要编写出SQL语句就行了。后端部分都是重复代码，实现查询。说白了就是单纯的CRUD操作。该模块困难点在于SQL语句的编写（因为是ClickHouse的，和MySQL难免有点区别），需要选择具体集群作为查询的限制条件。另外就是前端的界面展示，由于对ElementUI+VUE不太熟悉，在研究如何布局时，找了ElementUI的一个布局模板，在调试模板时花费了一些时间学习+实践。

4. Overview模块（大致描述）

开发背景及意义：帮助部门成员了解到ClickHouse目前服务了哪些业务，支持了哪些功能，对其他部门的业务产生了哪些帮助，对本部门以及其他部门的使用ClickHouse的性能进行监控，便于即使发现性能低下的操作，及时与相关人员沟通进行优化操作。帮助对ClickHouse的一些全局监控，便于了解到ClickHouse集群的一些相关信息等等。

这个模块就是数据大盘，帮助了解全局以及单个集群信息的。（以下集群维度和全局维度指标是8.25号左右的，目前该wiki页面已经完善）

主要完成的任务：

编写ClickHouse相关的SQL语句：对于集群维度，针对前端所选择的具体集群，获取其下的单副本的逻辑集群，连接上该集群的ClickHouse后进行查询，查询的内容包括：SELECT、INSERT、ALTER三个操作的执行时间的P90 && P99 分位数；近7天内的SELECT、INSERT、ALTER操作的成功率和失败率（多表进行join，查询出成功次数和总次数，查询出失败次数，通过round（）函数计算成功失败率）；近7天内的SELECT、INSERT、ALTER操作的执行次数。对于全局维度，需要统计所有集群的一个整体情况，比如一共有多少分片、节点、表、用户等，数据规模有多大，以及所有集群的整体SELECT、INSERT、ALTER三个操作的P90&&P99分位数、成功失败率以及执行次数
完成Overview模块后端集群维度的所有功能的接口代码编写，完成相应的ClickHouse查询功能。通过swagger进行集群维度的接口测试，由于本地测试集群与线上集群环境不通，因此全局维度无法在本地完成测试（本地idea和datagrip连不上线上集群）因此全局维度在线上进行测试
编写Overview模块前端界面：使用ElementUI的布局管理器组件进行页面的布局，并对原始的布局组件进行改造，使之能同时显示全局维度和集群维度的信息，针对全局维度的数据规模等显示问题，采用弹窗的方式进行显示

部分功能截图：

（截图时间8.25 当时还未完成该模块的开发）

在这里插入图片描述
（截图时间：9.10 目前已完成该模块第一代版本全部功能的开发）

在这里插入图片描述

总结：该模块的全局维度开发难度非常大，一方面需要跨14个集群进行查询，SQL语句非常复杂，查询耗时非常高（基本全局维度弹窗中的指标的查询时间在20s左右），导致用户体验不太好（当然目前只是第一个版本，后续会有优化）；另一方面，调整ElementUI组件的过程出现了一些困难，好在最后都自己解决了；在进行接口测试过程中，由于全局维度设计线上集群环境，本地无法进行测试，存在一些困难。

后续优化：

针对全局维度的一些不会变动的指标：比如节点数量、分片数量等，启动定时任务，每天凌晨出发一次，将查询结果缓存，当天内只从缓存查结果，当缓存结果与数据库结果不一样时，更新缓存
针对全局维度近7天的查询指标：由于前6天的结果已经确定了，故启动定时任务，凌晨触发，将前6天的结果查询一次后加缓存，当天执行查询只差当天的数据，然后拼接前6天进行显示
针对跨集群查询操作，优化SQL语句：取消使用大量JOIN操作，采用多线程执行，按照单集群进行查询，在后端将查询结果整合进对象，提升效率

经过优化，将原来的20s响应时间降到了1-5s内显示，用户体验好，后续还会有一些优化工作。

5. Query模块（大致描述）

开发背景及意义：简化组内成员查询ClickHouse的方式：将原本的手动去连接每一个集群的机器，去机器上登录ClickHouse数据库进行查询的操作，简化为通过前端界面进行设置过滤条件，快速查询显示出query信息，节约操作时间，提高效率。

主要完成的任务：

在原本的基础上针对 current queries 和 history queries 两个方面进行优化，current queries 查询的是processes_dst表， history queries 查询的是query_log_dst 表，两表字段不一样，对这两个方面分别添加更多的查询条件，并且根据具体选择，动态调整过滤框的显示
调整原本的页面布局以及显示
查询出一条查询下发的所有子查询，并在detail中显示
detail中可以对该查询执行explain，并显示explain的结果

部分功能截图：

在这里插入图片描述