如何增加大数据方面的经验

Posted 2023-03-02 测试那些事

首先获得这方面的工作机会：

我这个人是主张工作驱动技术成长的类型。选定一个方向，然后拼命的学习这个方向的知识，之后不管是求是骗还是去忽悠都要进入做这个方向的公司去锻炼，任何一公司都需要初级人员来打杂的，我们争的就是这个机会。技能的增长不是一厢情愿的事，我再之前写的一篇文章中写到过。没上过战场的士兵就算在训练中再优秀也是菜鸟。我们需要真正的战场磨炼我们的技能。所以自学到一定程度以后一定要去实际去用，如果你的公司没有这种业务环境，那么就跳槽。这时候别犹豫，你必须要有一个环境来做你想做的事情，如果这个时候拖下去，自学而来的东西会很快的被忘掉，之后你面试的时候可能什么都答不上来了。这时候争的就是一个机会，一个跑到对方公司打杂的机会。

然后想尽所有办法找应用场景：

当有环境以后剩下的就是自我驱动。主动去挖掘我们学到的知识的运用场景。测试应用这边咱们确实空白很多，我几乎找不到多少可以跟我一起聊分布式计算的测试同行。所以自己要善于发现和思考。

大数据方面的实际测试是什么样子的

先举个数据测试的例子，常出现在做BI和机器学习的公司。你可以参考我在测试大会上的演讲稿，这类型的业务每天都会有很大的数据被采集过来，我们需要测试这些数据，由于数据大，对测试速度要求高。所以也必然要使用spark，mr，hbase这些大数据处理框架去扫描数据。这个更详细内容你可以去看我的演讲稿。关于数据统计分析类的工作也跟这个差不多。

然后是造数， 大数据相关产品，尤其是to b业务的产品要给客户提供一个比较专业的性能测试报告。在各种数据量，数据分布，数据类型下产品的计算性能是什么样的需要有一个量化指标。而客户的数据是不会给你的， 所以我们要开发一个工具能够生成大数据量的，各种不同数据类型，各种不同数据分布的造数工具。还是由于数据量大，同样需要用大数据处理技术去做。我再演讲稿里也有提到过。

再举一个yarn集群管理的例子

一切都始于我们的UI自动化，我们的产品是做机器学习的么，产品要把计算任务放到hadoop集群上运行，而集群是用yarn管理的。当我们case越来越多，我的UI自动化也就必须用分布式的方式来执行(浏览器的分布式属于docker+k8s的范畴这里我不跟你说了，目前我们启动了30个浏览器)，当初我们发现在测试集群上15个小任务的并发能力就是极限了，多了就得排队，连20个浏览器的并发都支撑不起来，更不要说集群不只是给自动化测试用的，开发，产品，测试用的集群都是一个。所以对集群的调参是必要的，只是大家都不熟悉，测试环境的事也不爱管，这事就没有人搞。所以我买了hadoop技术内幕中的yarn的那一本开始啃。之后在测试集群上各种折腾，更换公平调度器，重设vcore，提高AM限制， 分队列，分用户，设定资源抢占，队列权重等等等等。一套下来现在集群抗个百十个小任务并发是没问题的。所以这方面的工作又多了一个测试集群管理。

很多建立在大数据基础上的产品都跟hadoop深度耦合，尤其是TO B业务的产品，要测试到hadoop的各种情况。各种hadoop的版本与产品的兼容是不是好的(很多客户有自己的hadoop), 以及hadoop的各种配置是不是与产品兼容的。例如我们曾经出现的问题是在jdk1.8下的hadoop2.7.2版本在我们的产品中会出现虚拟内存计算不正确的情况，而测试集群是开了虚拟内存check的，所以某一个算子运行失败。这是jdk1.8的一个bug，需要我们在该算子的配置中增加内存参数绕过去。再比如hadoop集群的多租户实现，很多地方是用yarn的fair调度器或者capacity调度器中的queue的概念去做，那么产品如何跟hadoop的配置协调? 假如产品提交到错的queue上去了? 假如产品提交到了不存在的queue? 产品使用了hadoop不存在的user?这些东西我们就会要测试到。其实不仅仅是多租户，产品跟hadoop集群耦合的地方都要测试。因为我们是做产品，而不是自家公司自己用，任何与hadoop的配置冲突的地方产品都应该做出相应的处理。

应该还有一些场景，只是我们的业务暂时没碰到，看看之后有没有同学补充一下。

区别大数据测试和运维的角色

别再纠结纯运维和纯测试了，devops流行的今天，开发，运维和测试这三个职位都互相渗透了。互相都干了以前对方的活是很常见的。

总结

建议大家去TO B的公司看看，现在做大数据的还是TO B的比较多。互联网里能接触到这些的公司不多。对于投向这方面的学习我觉得也是不亏的。不论是BI 还是 现在非常火的人工智能。大数据都是基础。这方面的平台和产品也越来越多。而这些行业的测试门槛还都很高，所以如果你再这方面有经验，都不用多厉害，就可以找到一个不错的工作。