从0开始学人工智能测试节选:Spark -- 结构化数据领域中测试人员的万金油技术(三)

本文主要是介绍从0开始学人工智能测试节选:Spark -- 结构化数据领域中测试人员的万金油技术(三),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

分布式计算原理

分布式计算的原理总结一句话就是:分而治之。

  1. 把数据分片,存在不同的机器中,解决数据存储的压力。
  2. 客户端和服务端之间通过相关协议来自动的完成在不同的机器之间进行数据的存取,用户并不感知数据的物理存储结构。 用户面对的只有hdfs://xxx/user/xx.txt这样的路径地址。 其余的都由客户端和服务端自动完成。

所有的分布式软件都是分而治之的思路, 当数据量大到了单机无法承载的时候, 那么就利用上面的原理 ,把数据分布到不同的机器中。 这样的架构也就可以支持横向扩展,也就是当存储软件的性能或者磁盘空间不够用时, 只要加机器就可以了。

下面是HDFS(一个分布式文件系统,属于hadoop生态)的架构图:

  1. DataNode:真正存储数据的节点
  2. NameNode:元数据服务器,存储所有数据的元信息,比如数据存储在哪些机器中的哪些路径。
  3. NameNode(standby):NameNode的备用节点,当主NameNode故障后,该服务会接替成为NameNode
  4. Hdfs client会负责查询NameNode获取数据分片信息并处理后返回给用户,用户不感知数据分布情况。

在HDFS中, NameNode负责存储所有文件的元数据, 实际上所有的分布式文件存储软件都有一个类似NameNode的角色,毕竟数据分散在N个不同的机器中, 为了不让用户感知到这复杂的文件分布, 所以需要有这样的一个角色来保存这些文件的元数据,这样客户端才可以跟服务端交互自动的完成文件的整合工作,用户也可以在不感知的前提下读写文件, 大大降低了使用的复杂度。

需要注意的是对于HDFS来说, 可以支持的文件数量都是有限的,并且对于小文件的存储非常的不友好。 因为HDFS是基于数据都是大数据的前提下进行设计的,所以它在文件切片并保存在不同的机器上的时候,是默认128M为一个block(块)进行存储,即便文件不足128M也会按128M进行保存。 也就是如果一个小文件只有28M,那么在HDFS中也会占用128的存储空间, 这100M就是浪费的。 并且对于HDFS来说,我们可以看到它的设计里虽然可以有多个NameNode,但在同一个时间内只能有一个NameNode对外提供服务。 这是出于高可用的考虑(简化元数据在多个namenode同步的问题,因为只有一个namenode在线, 所以剩下了很多数据一致性的问题),但它的缺点就是它没有负载均衡的能力,当文件数量过多时,就会对NameNode产生很大的压力, 使得集群整体的性能受到影响。所以我们在测试分布式存储软件本身的时候,也需要测试它能够承载的文件数量。 所以一般在分布式存储软件中,或者大数据系统中, 一般测试人员都会测试海量小文件的场景 -- 构造海量的小文件并保存在存储系统中,验证它的各项性能指标。 后面讲到造数工具的时候, 会演示如何在短时间内构造这样大批量的数据。

分布式计算

分布式计算的原理也是一样的,都是分而治之:

数据存储的时候可以把数据分布在不同的机器中, 那么在计算时也可以把一个大的任务拆分成N个小任务在调度到不同的机器中来完成。 它的大概过程是这样的:

  1. 计算任务分布在不同的节点中,各自掌握一段数据分片
  2. 每个计算任务各自计算自己掌握的数据
  3. 各个任务计算完毕后进行汇总并返回给客户端

shuffle与数据倾斜

当我们了解到分布式计算的基本运算原理后,就可以开始了解在大数据领域中最著名的一个设计, 同样也号称是大数据领域中的头号性能杀手 -- shuffle。 这是从 MapReduce 时代就开始的分布式计算独特的设计理念。 理解好 shuffle 的原理对学习 spark 甚至是任何一门大数据技术都是至关重要的。Shuffle 中文翻译为 “洗牌”,需要 Shuffle 的关键性原因是某种具有共同特征的数据需要最终汇聚到一个 partition 上进行计算。为什么要这么做呢? 因为对于一个分布式计算框架来说,网络通信的开销是十分昂贵的。假设我们有一千个计算节点在并发的执行一个计算任务。它们要聚合,计算,统计。数据在这一千个节点之间流动会造成相当大的网络负担。所以 spark 的设计者们为了减少网络开销而设计了 shuffle。它的原理就是尽量把一个计算任务所要处理的所有数据都聚集在一个 partition 上,这样就节省了很多的网络开销。 例如我们今天学到的 groupByKey() 聚合操作,spark 一旦执行到这一步的时候,会把所有 key 相同的数据分配到同一个 partition 上以供后续操作。例如 key 为 A 的行分配到 X 节点进行计算,key 为 B 的行分配到 Y 节点进行计算,这样在之后的计算中就免去了网络开销。而这个过程就是 shuffle。所谓洗牌就是这个意思了。

我们了解了 shuffle 相关的概念和原理后其实可以发现一个问题,那就是 shuffle 比较容易造成数据倾斜的情况。 例如上面我们看到的图,在这批数据中,hello 这个单词的行占据了绝大部分,当我们执行 groupByKey 的时候触发了 shuffle。这时候大部分的数据 (Hello) 都汇集到了一个 partition 上。这种极端的情况就会造成著名的长尾现象,就是说由于大部分数据都汇集到了一个 partition 而造成了这个 partition 的 task 运行的十分慢。而其他的 task 早已完成,整个任务都在等这个大尾巴task 的结束。 这种现象破坏了分布式计算的设计初衷,因为最终大部分的计算任务都在一个单点上执行了。所以极端的数据分布就成为了机器学习和大数据处理这类产品的劲敌,我跟我司的研发人员聊的时候,他们也觉得数据倾斜的情况比较难处理,当然我们可以做 repartition(重新分片) 来重新整合 parition 的数量和分布等操作,以及避免或者减少 shuffle 的成本,也可以重新分配key来避免数据倾斜,各家不同的业务有不同的做法。在做这类产品的性能测试的时候,也跟我们以往的互联网模式不同,产品的压力不在于并发量上,而在于数据量和数据分布上(大数据产品中,批处理业务很少有极高的并发操作,只有流计算里才会有高并发,而流计算我们放到以后的章节来讲)。

总而言之对于大数据产品来说,数据是否符合真实场景(包括数据的分布,分片,行数,列数等等)就决定性能测试的结果是否准确。 在很多产品中很难从线上直接拉取数据,有些场景是因为线上也没有足够的高质量数据,也有的是因为数据量实在过于庞大, 比如我们曾经测试过百亿,千亿和万亿规模的数据。 即便线上环境有这样庞大的数据, 但要把数据从线上同步到测试环境也会长期占用极其庞大的网络带宽, 这为线上带来了很大的风险。 同时对于很多做TOB类型的大数据产品来说(大数据产品大多都是TOB的,当然不一定是私有云, 也可能是公有云), 客户数据是保密的,我们没有办法直接拿现成客户数据。

所以综上所述, 测试人员需要开发一款造数工具来在短时间内构建海量的数据, 而这部分内容,我将会在下一个章节讲解。

 更多内容欢迎来到我的知识星球:
 

这篇关于从0开始学人工智能测试节选:Spark -- 结构化数据领域中测试人员的万金油技术(三)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1030121

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

字节面试 | 如何测试RocketMQ、RocketMQ?

字节面试:RocketMQ是怎么测试的呢? 答: 首先保证消息的消费正确、设计逆向用例,在验证消息内容为空等情况时的消费正确性; 推送大批量MQ,通过Admin控制台查看MQ消费的情况,是否出现消费假死、TPS是否正常等等问题。(上述都是临场发挥,但是RocketMQ真正的测试点,还真的需要探讨) 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说,就是一个分

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业