本文讲了一种针对元数据服务MetaStore的简易性能测试方法。
1 背景
如果说Hive Cli客户端,HiveServer2以及MetaStore是Hive的三驾马车的话,该如何看待这三者的主次关系以及未来影响力?我们先从两大服务说起:HiveServer2 和 MetaStore。这两个都是采取集中式Thrift服务的方式,便于我们做一些全局性的管控,比如权限,服务的透明升级等等。但也凸显了很多缺陷:
首先集中式的服务要求高保障的稳定性。而HiveServer2抛开自身的一些内存泄漏等等bug外,单就开放自由的用户自定义udf,就完全可以摧毁公司整个数仓Hive服务体系。我们曾经踩过的坑1:用户在自定义UDF中调用 System.exit(1)
,完全可以导致整个HS2服务进程退出,而且也很难排查;坑2:用户在自定义UDF中起独立线程且函数调用结束后,线程未关闭。曾经就有用户在UDF中起了独立线程且该线程无限循环输出日志,导致HS2服务日志打满。最终在反编译用户UDF代码才最终定位,也是满脸辛酸泪。总之,用户之间的任务在HS2中无法隔离,存在相互干扰的情况,HS2稳定性保障具有极大的挑战。有解决方案吗?有,那就是回归Hive Cli客户端。同样面临的问题:升级无法做到用户透明,如何做集中式鉴权?福音也是有的,那就是引擎迁向Spark。当然,如果数仓业务严重依赖Hive且推动迁移阻力巨大的话(有两个方面:一是增加数仓用户工作量,不想迁;二是HiveSql和Spark Sql的兼容性问题),可以自研Distribute HiveServer2(DHS),整体思路借鉴Spark,由集中式的服务改为通过Yarn在集群上拉起独立的HS2进程,优点类似于Spark的Driver,从而实现用户间的干扰隔离,这里就不展开了。
其次,Hive的bug修完一波又一波,维护成本太高。曾有段时间,几乎每周都在做HS2和MS的bugfix以及线上变更。这无疑增加了太高的额外成本。社区高版本的升级存在诸多兼容性问题,对于想从Hive低版本升级到高版本的用户而言,望而却步。而不升级,又面临着各种bugfix大量的backport。
还有一点致命的痛点便是MS的元数据存储mysql单点问题。随着业务的增长,mysql的存储压力越来越大,尤其是分区表partition的数据量一度高达5亿+,这无疑严重影响MS服务的稳定性。除了做元数据管理(定期清理无用的元数据),业界也有一些解决方案,如嘀嘀提出的基于Waggle-dance实现元数据服务的Federation方案等等。
聊了这么多,作为当前数仓领域不可或缺的大数据工具Hive,近年来唱衰的论调不断。的确,Spark优越的计算性能远远狂甩Hive几条街。总的来看,有这么几个方面:
- Hive计算性能差。说白了就是慢。虽然也挣扎过,Hive on Spark,Hive on tez,但从活跃度和用户体量来看,前景堪忧。
- Hive目前社区活跃度远低于Spark社区活跃度。社区的活跃度就是稳定性的保障。
业界,尤其是大厂早已推动数仓离线领域针对Hive Sql向Spark Sql的迁移工作。据了解,目前美团已经完全弃用了Hive Sql,所有离线计算引擎都迁移至Spark Sql。而嘀嘀也在紧锣密鼓地推进中,预计近年也会完成Hive Sql 至 Spark Sql的迁移工作。
但因为业务的历史原因,暂时还无法甩掉Hive这个包袱,尤其是MetaStore元数据服务。现在终于回归正题,既然甩不掉,我们就得努力提高MS的稳定性。面临一个问题便是:如何感知MS实例不足以提供线上服务,需要扩容呢?所以我们需要了解MS能够提供多大的服务能力。
2 测试方案
业界有Jmeter压测工具,有兴趣可以调研下,当然有一定的学习成本,这里简易实现一种压测方案:利用多线程模拟高并发请求。
1 | package org.jeff.r.test; |
封装一个启动脚本:ms-testing.sh
1 | !/usr/bin/env bash |
3 测试步骤
MS实例配置:
1 | 实例内存 -Xms12g -Xmx12g |
分三个并发维度测试:200并发,500并发,800并发。
1 | MS服务地址:thrift://127.0.0.1:9083 |
4 测试结果
(鉴于安全考虑,CPU等性能图就不贴了,简要说下测试结果)
1 | Qps可以达到5k+,CPU可以打到50~60%。 |
本文链接: https://stefanxiepj.github.io/archives/6287413c.html
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!
![知识共享许可协议](https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png)