共计 4144 个字符，预计需要花费 11 分钟才能阅读完成。
原文由孙高飞发表于 TesterHome 社区，原文链接
背景
好久没写文章了，自从换工作当前终日就忙着相熟新公司的我的项目了。趁着这两天有工夫我就持续更新一下大数据测试系列。上一次咱们聊过流计算场景个别的测试方法，而流计算是在线业务。那明天咱们聊聊离线业务的场景。不晓得大家有没有接触过大数据平台产品，这类产品以 TO B 公司居多，当然也有一些大厂外部也会有大数据平台去撑持业务线，比方阿里的如同叫 odps 吧（有点忘了），腾讯也有 tbds 这样的大数据产品。或者一些 AI 平台也有着大数据平台的个性。它们的特点是产品属于平台类的，没有本人的业务，或者说他的业务就是提供算力去撑持客户的业务。也就是大数据平台类的产品提供的是一些原始算力，用户须要调用这些算力来满足他们的业务。这就跟互联网不太一样了，接触过大数据的同学比拟相熟的应该还是在业务层的数据处理逻辑，比方测试一些研发提供的 ETL 程序，或者数据组的同学提交的一些 hive sql。这些都是带着强烈的业务属性的，属于业务层的货色。而大数据平台的产品并没有这些属性，能够了解为它属于中台层。
场景举例
下面说的过于形象，咱们用个例子来阐明一下。个别企业在倒退到肯定水平，数据积攒到一定量级都会倒退出数仓（数据仓库）利用，数仓个别用来做相似 BI 的业务帮忙企业剖析数据以做出决策，我用知乎上一个仁兄举的例子来说，比方需要会从最后十分粗放的：“昨天的支出是多少”、“上个月的 PV、UV 是多少”，逐步演变到十分精细化和具体的用户的集群剖析，特定用户在某种应用场景中，例如“20~30 岁女性用户在过来五年的第一季度化妆品类商品的购买行为与公司进行的促销流动计划之间的关系”。这类十分具体，且可能对公司决策起到关键性作用的问题，根本很难从业务数据库从调取进去。次要起因我感觉有 3 点：
- 业务数据库中的数据结构是为了实现交易而设计的，不是为了而查问和剖析的便当设计的。
- 业务数据库大多是读写优化的，即又要读（查看商品信息），也要写（产生订单，实现领取）。因而对于大量数据的读（查问指标，个别是简单的只读类型查问）是反对有余的。
- 咱们须要大量的数据来进行剖析，但这些数据不都是存在关系型数据库中的，数据源可能来自消息中间件也可能来自日志零碎。咱们在剖析的时候须要对接多种数据源
所以综上所述，到了这个阶段的企业不会再用 mysql 这种关系型数据库来构建数据仓库了，而是应用诸如 hive 这样的技术来构建数仓。因为数仓的要求个别为：
- 数据结构为了剖析和查问的便当；
- 只读优化的数据库，即不须要它写入速度如许快，只有做大量数据的简单查问的速度足够快就行了。
个别的大数据平台都会提供数仓的能力。而构建数仓的第一步就是如何从各种数据源中把业务数据导入到数仓中（这其中还须要荡涤过滤数据，多表拼接，标准 schema 等 ETL 流程）。所以很多大数据平台会提供从各种数据源中把数据导入到平台本身零碎存储的性能。并且这些导入性能要保障性能的前提下也要保障性能，一致性，高可用等等。
测试工具
好了，下面说的都是背景，是为了引出咱们的测试需要而存在的。当初咱们晓得了，对于大数据平台类产品来说，个别都得提供从十分多的数据源中导入数据的能力以应答客户的需要。毕竟客户本人应用的数据存储花色层出。那么对于测试来说，如何能保障所有平台反对的数据源都是没有问题的是一个挑战。这外面的难点有二：
- 数据源兼容性：每种数据源都有不同的版本和不同的配置。比方 hdfs 有商业版本的也有开源版本的，有开了 kerbos 平安认证的也有没开的。须要部署装置各种版本的数据源进行测试。当然明天的帖子里不针对这个具体开展了，咱们次要讲上面一个。
- 数据兼容性：我切实不太晓得应该起什么名字了。因为这一条里其实蕴含了性能，性能等各方面的货色，暂且叫数据兼容性。因为测试方法其实就在不同的数据源中构建不同的数据进行测试。你要保障在每个数据源下不同格局，不同构造，不同量级的数据都是能保质保量的导入到产品中的。
专门针对下面第二点说，其实测试就是要保障所有数据源在导入的时候性能和性能都是合格的。所以为了测试这种场景你就须要一个比拟弱小的造数工具，可能有些同学会问干嘛不间接用线上数据。当然如果有线上数据我也偏向于采集线上数据，然而很多大数据平台其实都没有线上这个概念，因为它们都是私有化部署在客户场地内的，客户的数据是不会交给你的。当然不止这一个起因，咱们有时候会碰到各种起因而无奈应用线上数据。所以咱们在有些状况下，是须要这个造数工具的。而这个造数工具有几个难点：
- 构建大数据：造数工具的性能够不够？如果有一个造 10 亿行，1000 列的数据的要求，能不能在短时间内把这些数据造出来。
- 多种数据源：因为咱们要测试所有的数据源，而每种数据源的造数形式那是不一样的。要是每种数据源都写一个造数工具那老本还是十分高的。
- 多种数据格式，散布，类型和构造：造数是个比较复杂的事，除了每个字段的类型要管制，还有文件的类型（txt，csv，parquet 等），还要管制两张表的关系（测试拼表场景），还要控制数据分区和分片（分布式文件数据源的场景）。所以要怎么设计这个造数据工具能满足这些场景。
思考到这 3 个难点，所以咱们在设计造数工具的时候采纳了上面的计划
- spark 自身就是分布式计算框架，把造数工作提交到集群上（k8s，hadoop）减速造数过程可晋升性能。这也是用大数据技术测试大数据的一种体现吧。这就解决了下面说的第一个难点。同样因为 spark 自身就是大数据技术，所以它在造数的时候很不便的就能够反对保留成各种数据类型和文件格式，还能够设置落盘时数据分片的数量来测试海量文件分片的场景。所以第三个难点也就解决了。
- 而针对第二个难点，咱们天然没有精力为每个数据源都写一个造数工具，咱们采纳的是应用 datax 这个开源的数据同步工具，datax 有各种 writer 和 reader 的插件能够在不同的源之间同步数据。所以咱们抉择的是先应用 spark 造数落盘，再把这个数据通过 datax 同步到其余数据源中。
再简单一点的场景
下面说的其实都是结构化数据，那咱们看看更简单的场景，比方咱们把数据仓库扩大成数据湖，数仓的特点是数据都是结构化的，每个字段都是规定好的。在导入数仓的时候就做过一轮解决了。但数据湖的特点是不会对原始数据做解决，而是间接导入零碎中，这些数据可能是结构化的也半结构化的也可能是非结构化的。后续会有各种业务须要这些数据。比方咱们曾经很相熟的 AI 平台。咱们的产品对依据不同的数据提供不同的算子（数据处理程序），有些时候是 ETL 程序，有些时候是机器学习或者深度学习算法，针对机器学习算法来说做性能测试不仅仅要求数据的量级，也要求数据能抽取特色的维度。咱们能够通过在 spark 程序中控制数据散布来达到精准的管制特色维度的目标。比方咱们再造数的时候给某一列调配 1W 个惟一值，也就是不论造多少行，都是在这 1w 值外面取的。那么这一列就是精准的能抽取 1W 维特色进去。所以通过下面的造数工具咱们是能够制订规定来满足这些算法的数据须要以测试其性能的。问题在于非结构化数据，比方图片，音频和视频。咱们如何能在短时间内造出海量的非构造数据呢？比方咱们之前接到过一个需要，客户目前曾经达到了几十亿张图片的量级。尽管前面咱们探讨过后决定只模式 2 亿级别的数据量，但这也是一个很大的挑战。咱们须要学生成一张图片，再依据肯定算法计算出图片的保留门路和其余元数据，再把这些元数据保留到数据库中。在这外面咱们能想到的性能瓶颈在于：
- IO：不论是生成图片，还是把与数据库交互都会耗费网络和磁盘 io，2 亿张图片对于 IO 的考验是比拟大的
- CPU：如果依照传统的思路，为了晋升造数性能，会开很多个线程来并产生成图片，计算元数据和数据交互。但线程开的太多 CPU 的上下文切换也很损耗性能。尤其咱们应用的是 ssd 磁盘，多线程的模式可能是无奈最大化利用磁盘 IO 的。
前面通过探讨，最初的计划是应用 golang 语言，用协程 + 异步 IO 来进行造数：
- 首先 golang 语言的 IO 库都是应用 netpoll 进行优化过的，netpoll 底层用的就是 epoll。这种异步 IO 技术能保障用更少的线程解决更多的文件。对于 epoll 为什么性能好能够参考这篇文章：https://www.cnblogs.com/Hijac… 也能够去查一下同步 IO 和异步 IO 的区别。我大略总结一下就是，传统的多线程 + 同步 IO 模型是开多个线程抗压力，每个线程同一时间只解决一个 IO。一旦 IO 触发开始读写文件线程就会处于阻塞状态，这个线程就会从 CPU 队列中移除也就是切换线程。等 IO 操作完结了再把线程放到 CPU 队列里让线程继续执行上面的操作，而异步 IO 是如果一个线程遇到了 IO 操作，它不会进入阻塞状态，而是持续解决其余的事，等到那个 IO 操作完结了再告诉程序（通过零碎中断），调用回调函数解决前面的事件。这样就保障了异步 IO 的机制下能够用更少的线程解决更多的 IO 操作。这是为什么异步 IO 性能更好的起因，也是为什么异步 IO 能最大化利用磁盘性能。比方在这个造图片的场景里，我在内存中造好图片后，开始写入文件系统，如果是同步 IO 那这时候就要阻塞了，直到文件写入结束线程才会持续解决，但因为我用的异步 IO，调用玩函数让内存中的数据写入到文件就不论了，间接开始造下一张图片，什么时候 IO 完结告诉我我在回过头来解决。所以是能够用更少的线程来实现更多的 IO 操作也就是异步 IO 能很容易的把磁盘性能打满。我本人测试的时候再本人的笔记本上造 100k 的图片，大略是 1s 就能造 1W 张图片
- 其次 golang 的 GMP 模型自身就很高效，编写异步程序也非常简单。我也就花了一上午就把脚本写完了。
- 最初利用 k8s 集群把造数任务调度到集群中，充分利用分布式计算的劣势，在多台机器上启动多个造数工作共同完成。
原谅我懒了，下面这个计划的架构图我切实是不想画了，大家见谅。
结尾
在大数据产品的测试里，常常会有这种造数的需要。当然不是所有场景都是要造数测的。如果大家不是在 TO B 产品中工作并且身处业务层，而不是数据中台层。那么其实更多的就是间接用线上数据了。
播种前沿测试开发技术 · 学习先进品质治理方法 · 结识测试大咖和行业精英 ↓↓↓
