-
如何优化分布式系统的性能和响应速度?
-
想知道modelarts是否支持多卡npu/gpu的推理,如果支持,是怎么实现的呢?
-
一、Feign是什么? Feign是Spring Cloud提供的一个声明式的伪Http客户端,它使得调用远程服务就像调用本地服务一样简单,只需要创建一个接口并添加一个注解即可。 Nacos注册中心很好的兼容了Feign,Feign默认集成了Ribbon,所以在Nacos下使用Fegin默认就实现了负载均衡的效果。 二、Dubbo是什么? Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。 Spring-cloud-alibaba-dubbo是基于SpringCloudAlibaba技术栈对dubbo技术的一种封装,目的在于实现基于RPC的服务调用。 三、对比 Feign和Dubbo都可以实现远程调用,他们都依赖注册中心,他们都支持负载均衡,服务熔断。 然而Feign是基于Http协议。服务提供者需要对外暴露Http接口供消费者调用(例如我们用@openFeign注解来标识远程调用服务的接口时,需要加@RequestMapping)服务粒度是http接口级的。通过短连接的方式进行通信,不适合高并发的访问。Feign追求的是简洁,少侵入(因为就服务端而言,在SpringCloud环境下,不需要做任何额外的操作,而Dubbo的服务端需要配置开放的Dubbo接口)。 至于Dubbo,Dubbo支持多传输协议(Dubbo、Rmi、http、redis等等),可以根据业务场景选择最佳的方式,非常灵活。默认的Dubbo协议:利用Netty,TCP传输,单一、异步、长连接,适合数据量小、高并发和服务提供者远远少于消费者的场景。Dubbo通过TCP长连接的方式进行通信,服务粒度是方法级的。 从协议层选择看,Dubbo是配置化的,更加灵活。Dubbo协议更适合小数据高并发场景。 欸,不要急,肯定有人看到这里会有问题,长连接和短连接区别是什么,为什么基于短连接的Feign就不适合高并发的访问呢,为什么长连接的Dubbo就可以。 四、长连接和短连接 说到长连接和短连接,很多人都会想到Http长连接和短连接的相关知识,例如Http1.0默认使用短连接,Http1.1默认使用长连接呀之类的,但经过笔者学习和阅读一些文章之后,实际上Http根本不分长连接和短连接,或者说“ Http的长短连接,其实是在Tcp连接中实现的 ”。 HTTP协议的长连接和短连接,本质上是TCP协议的长连接和短连接。HTTP属于应用层协议,在传输层使用TCP协议,在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠地传递数据包,使得网络上接收端收到发送端所发出的所有包,并且接受顺序与发送顺序一致。TCP协议是可靠的、面向连接的。TCP才负责连接,只有负责传输的这一层才需要建立连接!!!!! 在HTTP/1.0中默认使用短连接。也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像文件、CSS文件等),每遇到这样一个Web资源,浏览器就会重新建立一个HTTP会话。 而从HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头加入这行代码(但要服务器和客户端都设置):Connection:keep-alive 那么综合长短连接来说呢,Feign是短连接的,那我们面对高并发的请求的时候,每请求一次数据都要建立一次连接,那肯定就不适用了。所以,Feign和Dubbo都能实现远程调用的功能,但是要看我们具体的需求去使用哪个。 补充一点: 在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的TCP连接。也就是说在长连接情况下,多个HTTP请求可以复用同一个TCP连接,这就节省了很多TCP连接建立和断开的消耗。 Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。 五、长轮询,短轮询 既然前面已经提到了长连接和短连接,那么其实我们在实际应用开发的过程中,还会碰到长轮询和短轮询的选择,所以在这里也一并进行学习和记录啦。 首先我们想象一个业务场景,现在有一个商品正在销售(正常网购场景,并非秒杀)。商品的旁边要显示它的库存量,并且这个库存量是要时实变化的,那我们该怎么处理。 首先短轮询的方法,我们可以去编写一个JS函数,每一秒就去查询一次数据,然后把得到的结果在界面中渲染,进行刷新。我们使用短轮询的方法,所以每次去请求一次数据,都会建立一个连接,请求完毕再关闭连接,再请求,再建立,再关闭。 这种短轮询肯定是会造成网络资源的浪费的,因为如果有几万个用户,他就是在浏览界面,然后忘了关闭,也不下单,那就同时有几个万个请求在创建连接,关闭连接。。。 长轮询这个时候就出现了,其实长轮询和短轮询最大的区别是,短轮询去服务端查询的时候,不管库存量有没有变化,服务器就立即返回结果了。而长轮询则不是,在长轮询中,服务器如果检测到库存量没有变化的话,将会把当前请求挂起一段时间(这个时间也叫作超时时间,一般是几十秒)。在这个时间里,服务器会去检测库存量有没有变化,检测到变化就立即返回,否则就一直等到超时为止。 而对于客户端来说,不管是长轮询还是短轮询,客户端的动作都是一样的,就是不停的去请求,不同的是服务端,短轮询情况下服务端每次请求不管有没有变化都会立即返回结果,而长轮询情况下,如果有变化才会立即返回结果,而没有变化的话,则不会再立即给客户端返回结果,直到超时为止。 这样一来,客户端的请求次数将会大量减少(这也就意味着节省了网络流量,毕竟每次发请求,都会占用客户端的上传流量和服务端的下载流量),而且也解决了服务端一直疲于接受请求的窘境。 但是长轮询也是有坏处的,因为把请求挂起同样会导致资源的浪费,假设还是1000个人停留在某个商品详情页面,那就很有可能服务器这边挂着1000个线程,在不停检测库存量,这依然是有问题的。 因此,从这里可以看出,不管是长轮询还是短轮询,都不太适用于客户端数量太多的情况,因为每个服务器所能承载的TCP连接数是有上限的,这种轮询很容易把连接数顶满。哪怕轮询解决不了获取库存这个问题,但只要大家明白了长短轮询的区别,这就足够了。 六、Feign和Dubbo其他方面的区别 好了,言归正传,最后再介绍一些Feign和Dubbo在其他方面的区别。 负载均衡方面: Feign默认使用Ribbon作为负载均衡的组件。 Dubbo和Ribbon(Feign默认集成Ribbon)都支持负载均衡策略,但是Dubbo支持的更灵活。 Dubbo和Ribbon对比: Ribbon的负载均衡策略:随机、规则轮询、空闲策略、响应时间策略。 Dubbo的负载均衡策略:Dubbo支持4种算法,随机、权重轮询、最少活跃调用数、一致性Hash策略。而且算法里面引入权重的概念。 Dubbo可以使用路由策略,然后再进行负载均衡。 Dubbo配置的形式不仅支持代码配置,还支持Dubbo控制台灵活动态配置。 Dubbo负载均衡的算法可以精准到某个服务接口的某个方法,而Ribbon的算法是Client级别的。Ribbon需要进行全局配置,个性化配置比较麻烦。 容错机制方面: Feign默认使用Hystix作为服务熔断的组件。Hystix提供了服务降级,服务熔断,依赖隔离,监控(Hystrix Dashboard)等功能。Feign是利用熔断机制来实现容错的,与Dubbo处理的方式不一样。 Dubbo支持多种容错策略,FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking策略等,以及Mock。也引入了retry次数,timeout等配置参数。Dubbo自带了失败重试的功能。 总结 Dubbo支持更多功能、更灵活、支持高并发的RPC框架。 SpringCloud全家桶里面(Feign、Ribbon、Hystrix),特点是非常方便。Ribbon、Hystrix、Feign在服务治理中,配合Spring Cloud做微服务,使用上有很多优势,社区也比较活跃,看将来更新发展。 业务发展影响着架构的选型,当服务数量不是很大时,使用普通的分布式RPC架构即可,当服务数量增长到一定数据,需要进行服务治理时,就需要考虑使用流式计算架构。Dubbo可以方便的做更精细化的流量调度,服务结构治理的方案成熟,适合生产上使用,虽然Dubbo是尘封后重新开启,但这并不影响其技术价值。 如果项目对性能要求不是很严格,可以选择使用Feign,它使用起来更方便。 如果需要提高性能,避开基于Http方式的性能瓶颈,可以使用Dubbo。 Dubbo Spring Cloud的出现,使得Dubbo既能够完全整合到Spring Cloud的技术栈中,享受Spring Cloud生态中的技术支持和标准化输出,又能够弥补Spring Cloud中服务治理这方面的短板。 原文链接:https://blog.csdn.net/weixin_56032340/article/details/123619132
-
Java中的锁主要包括synchronized锁和JUC包中的锁,这些锁都是针对单个JVM实例上的锁,对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上,锁的竞争者通常是一些不同的线程,而在分布式环境中,锁的竞争者通常是一些不同的线程或者进程。目前主要有三种方式实现分布式系统中的锁方式:分布式锁的实现方式基于数据库唯一索引基于缓存Redis基于Zookeeper1.基于数据库唯一索引方式主要利用数据库唯一索引的排他性实现,同一个业务id如果能插入数据成功就认为是获得了锁,插入失败就是锁被占用,释放锁就是删除数据。虽然实现方式简单但是因为数据库的可承载并发量有限所以性能方面并不好,并且可能会造成死锁等问题。2.基于缓存Redis的方式理论上来说借助于Redis实现的分布式锁效率最好,主要借助于Redis的Setnx命令同一个业务id如果已经存在就返回0,不存在就返回1并设置成功。因为Redis是纯内存操作所以效率最高,结合Redis的失效时间等方式可以很大程度的避免死锁问题。借助于Redisson工具可以很好的实现分布式锁方式。3.基于Zookeeper方式Zookeeper一般作为配置中心和注册中心,借助于Zookeeper创建临时节点的排他性并且在断开连接时自动销毁临时节点的特性可以实现分布式锁。加锁就是创建节点,释放锁就是断开连接,但因为牵涉到Zookeeper牵涉到文件存储所以效率没有Redis高。Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。
-
分布式事务 在微服务项目开发过成功各个模块之间是隔离的,如果在链式调用过程中由于某个模块没有执行成功会造成数据不一致的问题,因此我们需要在链式调用过程中使用分布式事务组件实现统一的提交和异常回滚保证数据的一致性。 Spring cloud alibaba 分布式事务组件 Seata Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。。 使用@GlobalTransactional注解来实现一个分布式事务。具体的业务就是,我们自己有一个事务管理,当我们的业务在保存的时候出现问题,我们单据就会回滚,不会保存,然后我们会调用流程平台的代码(也就是Activiti),然后问题出现了,在调用的时候出现了问题,流程没有取到数据,我们因为因为出错所以就回滚了,但是Activiti捕捉了这个异常,并且成功发起的流程,这就导致了单据显示在用户的我发起的和代办中,我们就换一个注解实现全局事务GlobalTransactional。 官网文档:cid:link_0 Spring cloud 项目集成 Seata组件 1.下载Seata服务 从 https://github.com/seata/seata/releases,下载服务器软件包,将其解压缩 2.修改配置 打开conf/file.conf文件 修改service 节点目录内容如下: service { #vgroup->rgroup vgroup_mapping.my_test_tx_group = "default" #only support single node default.grouplist = "127.0.0.1:8091" #degrade current not support enableDegrade = false #disable disable = false #unit ms,s,m,h,d represents milliseconds, seconds, minutes, hours, days, default permanent max.commit.retry.timeout = "-1" max.rollback.retry.timeout = "-1" } 3.启动Seata服务 到bin目录下执行脚本启动seata server端,注:windows下执行seata-server.bat启动;linux下执行seata-server.sh启动 ### 4.引入依赖 ``` <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>最新版</version> </dependency> <!--不使用注册中心、配置中心不加--> <dependency> <groupId>com.alibaba.nacos</groupId> <artifactId>nacos-client</artifactId> <version>1.2.0及以上版本</version> </dependency> ``` ### 5.application.yml配置 ``` seata: enabled: true enable-auto-data-source-proxy: false application-id: ${spring.application.name} tx-service-group: my_tx_group service: vgroup-mapping: my_tx_group: default # 不使用注册中心和配置中心不加以下配置 config: type: nacos nacos: server-addr: 127.0.0.1:8848 group: "SEATA_GROUP" namespace: "seata" dataId: "seataServer.properties" username: "" password: "" registry: type: nacos nacos: application: seata-server server-addr: 127.0.0.1:8848 group: "SEATA_GROUP" namespace: "seata" username: "" password: "" ``` ### 6.数据库中添加回滚日志表 数据源连接的每个数据库中添加 undo_log 表 ``` CREATE TABLE `sys_seata_undo_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `branch_id` bigint(20) NOT NULL, `xid` varchar(100) NOT NULL, `context` varchar(128) NOT NULL, `rollback_info` longblob NOT NULL, `log_status` int(11) NOT NULL, `log_created` datetime NOT NULL, `log_modified` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; ``` ### 7.客户端application.yml配置 ``` seata: tx-service-group: default_tx_group service: vgroup-mapping: default_tx_group: default ``` ### 8.在分布式事务控制方法上添加注解@GlobalTransactional ``` @GlobalTransactional public void purchase(String userId, String commodityCode, int orderCount) { ...... } ```
-
信创型号千万多,哪个最棒
-
↵运行环境NPU:Ascend-910(32GB)CPU:ARM 24 核Memory:96GB镜像:Ascend-Powered-Engine | mindspore_1.7.0-cann_5.1.0-py_3.7-euler_2.8.3-aarch64错误描述多卡分布式训练时,任何Tensor.asnumpy的调用都会报错。报错信息- Case 1[ERROR] DEVICE(222,ffffb7464010,python):2022-11-17-17:25:09.728.545 [mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_kernel_runtime.cc:626] TaskFailCallback] Execute TaskFailCallback failed. task_fail_info or current_graph_ is nullptr[ERROR] DEVICE(222,ffffb7464010,python):2022-11-17-17:25:09.738.262 [mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_kernel_runtime.cc:1116] SyncStream] Call runtime rtStreamSynchronize error.[CRITICAL] DEVICE(222,ffffb7464010,python):2022-11-17-17:25:09.738.349 [mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_device_address.cc:202] SyncStream] Sync stream error!Traceback (most recent call last):无论File "/home/ma-user/modelarts/user-job-dir/Code/train.py", line 406, inMonitorCallBack(model, datasets, Logs_dict)]File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 906, in trainsink_size=sink_size)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 87, in wrapperfunc(self, *args, **kwargs)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 548, in _trainself._train_dataset_sink_process(epoch, train_dataset, list_callback, cb_params, sink_size)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 642, in _train_dataset_sink_processlist_callback.epoch_end(run_context)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/callback/_callback.py", line 216, in epoch_endcb.epoch_end(run_context)File "/home/ma-user/modelarts/user-job-dir/Code/train.py", line 73, in epoch_endCM = self.model.eval(dataset)["CM"]File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 1090, in evalreturn self._eval_dataset_sink_process(valid_dataset, list_callback, cb_params)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 982, in _eval_dataset_sink_processself._update_metrics(outputs)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 358, in _update_metricsmetric.update(*outputs)File "/home/ma-user/modelarts/user-job-dir/Code/train.py", line 269, in updatecm = np.bincount(self.n_class * Label + Prediction, minlength=self.n_class*self.n_class).reshape(self.n_class, self.n_class)File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/numpy/math_ops.py", line 4652, in bincountlength = int(maximum(F.reduce_max(x.astype(mstype.float32)), minlength - 1).asnumpy()) + 1File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/common/tensor.py", line 523, in asnumpyreturn Tensor_.asnumpy(self)RuntimeError: mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_device_address.cc:202 SyncStream] Sync stream error!报错信息- Case 2[ERROR] DEVICE(220,ffffb0498010,python):2022-11-17-16:55:40.054.814 [mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_kernel_runtime.cc:626] TaskFailCallback] Execute TaskFailCallback failed. task_fail_info or current_graph_ is nullptr [ERROR] DEVICE(220,ffffb0498010,python):2022-11-17-16:55:40.055.902 [mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_kernel_runtime.cc:1116] SyncStream] Call runtime rtStreamSynchronize error. [CRITICAL] DEVICE(220,ffffb0498010,python):2022-11-17-16:55:40.055.970 [mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_device_address.cc:202] SyncStream] Sync stream error! Traceback (most recent call last): File "/home/ma-user/modelarts/user-job-dir/Code/train.py", line 402, in <module> MonitorCallBack(model, datasets, Logs_dict)] File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 906, in train sink_size=sink_size) File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 87, in wrapper func(self, *args, **kwargs) File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 548, in _train self._train_dataset_sink_process(epoch, train_dataset, list_callback, cb_params, sink_size) File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 642, in _train_dataset_sink_process list_callback.epoch_end(run_context) File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/callback/_callback.py", line 216, in epoch_end cb.epoch_end(run_context) File "/home/ma-user/modelarts/user-job-dir/Code/train.py", line 72, in epoch_end CM = self.model.eval(dataset)["CM"] File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 1090, in eval return self._eval_dataset_sink_process(valid_dataset, list_callback, cb_params) File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 982, in _eval_dataset_sink_process self._update_metrics(outputs) File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/train/model.py", line 358, in _update_metrics metric.update(*outputs) File "/home/ma-user/modelarts/user-job-dir/Code/train.py", line 208, in update Label = data[1].copy().asnumpy().astype(int).flatten() File "/home/ma-user/anaconda/lib/python3.7/site-packages/mindspore/common/tensor.py", line 523, in asnumpy return Tensor_.asnumpy(self) RuntimeError: mindspore/ccsrc/plugin/device/ascend/hal/device/ascend_device_address.cc:202 SyncStream] Sync stream error!
-
一、Hadoop常见的三种运行模式1、单机模式(独立模式)(Local或Standalone Mode) 默认情况下Hadoop就是处于该模式,用于开发和调式。不对配置文件进行修改。使用本地文件系统,而不是分布式文件系统。 Hadoop不会启动NameNode、DataNode、JobTracker、TaskTracker等守护进程,Map()和Reduce()任务作为同一个进程的不同部分来执行的。 用于对MapReduce程序的逻辑进行调试,确保程序的正确。2、伪分布式模式(Pseudo-Distrubuted Mode) Hadoop的守护进程运行在本机机器,模拟一个小规模的集群,在一台主机模拟多主机。 Hadoop启动NameNode、DataNode、JobTracker、TaskTracker这些守护进程都在同一台机器上运行,是相互独立的Java进程。 在这种模式下,Hadoop使用的是分布式文件系统,各个作业也是由JobTraker服务,来管理的独立进程。在单机模式之上增加了代码调试功能,允许检查内存使用情况,HDFS输入输出,以及其他的守护进程交互。类似于完全分布式模式,因此,这种模式常用来开发测试Hadoop程序的执行是否正确。3、全分布式集群模式(Full-Distributed Mode) Hadoop的守护进程运行在一个集群上 Hadoop的守护进程运行在由多台主机搭建的集群上,是真正的生产环境。下载并解压Hadoop、JDK安装包并配置好环境变量、节点域名解析、防火墙、端口等组成相互连通的网络。进入Hadoop的解压目录,编辑hadoop-env.sh文件(注意不同版本后配置文件的位置有所变化)编辑Hadoop中配置文件core-site.xml(Hadoop集群的特性,作用于全部进程及客户端)、hdfs-site.xml(配置HDFS集群的工作属性)、mapred-site.xml(配置MapReduce集群的属性)、yarn-site.xml四个核心配置文件配置ssh,生成密钥,使到ssh可以免密码连接localhost,把各从节点生成的公钥添加到主节点的信任列表。格式化HDFS后 使用./start-all.sh启动Hadoop集群二、Hadoop常见组件Hadoop由HDFS、Yarn、Mapreduce三个核心模块组成,分别负责分布式存储、资源分配和管理、分布式计算。1、Hadoop-HDFS模块HDFS:是一种分布式存储系统,采用Master和Slave的主从结构,主要由NameNode和DataNode组成。HDFS会将文件按固定大小切成若干块,分布式存储在所有DataNode中,每个文件块可以有多个副本,默认副本数为3。NameNode: Master节点,负责元数据的管理,处理客户端请求。DataNode: Slave节点,负责数据的存储和读写操作。2、Hadoop-Yarn模块Yarn:是一种分布式资源调度框架,采用Master和Slave的主从结构,主要由ResourceManager . ApplicationMaster和NodeManager组成,负责整个集群的资源管理和调度。ResourceManager:是一个全局的资源管理器,负责整个集群的资源管理和分配。ApplicationMaster:当用户提交应用程序时启动,负责向ResourceManager申请资源和应用程序的管理。NodeManager:运行在Slave节点,负责该节点的资源管理和使用。Container: Yarn的资源抽象,是执行具体应用的基本单位,任何一个Job或应用程序必须运行在一个或多个Container中。3、Hadoop-Mapreduce模块Mapreduce:是一种分布式计算框架,主要由Map和Reduce两个阶段组成。支持将一个计算任务划分为多个子任务,分散到各集群节点并行计算。Map阶段:将初始数据分成多份,由多个map任务并行处理。Reduce阶段:收集多个Map任务的输出结果并进行合并,最终形成一个文件作为reduce阶段的结果。全分布式集群模式(Full-Distributed Mode)搭建【基本环境】三台鲲鹏km1.2xlarge.8内存优化型 8vCPUs | 64GB CentOS 7.6 64bit with ARM CPU:Huawei Kunpeng 920 2.6GHz其中jack20节点作为NameNode, Node1、 Node2作为DataNode,而Node1也作为辅助NameNode ( Secondary NameNode )。【基本流程】下载并解压Hadoop、JDK安装包并配置好环境变量、节点域名解析、防火墙、端口进入Hadoop的解压目录,编辑hadoop-env.sh文件(注意不同版本后配置文件的位置有所变化)编辑Hadoop中配置文件core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml四个核心配置文件配置ssh,生成密钥,使到ssh可以免密码连接localhost 格式化HDFS后 使用./start-all.sh启动Hadoop集群关闭防火墙和selinux(1)各个节点都执行命令关闭防火墙:systemctl stop firewalldsystemctl disable firewalldsystemctl status firewalld(2)关闭selinux进入selinux的config文件,将selinux原来的强制模式(enforcing)修改为关闭模式(disabled)setenforce 0getenforcesed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/sysconfig/selinuxgrep SELINUX=disabled /etc/sysconfig/selinuxcat /etc/sysconfig/selinux1.安装openJDK-1.8.01.1. 下载安装openJDK-1.8.0下载openJDK-1.8.0并安装到指定目录(如“/home”)。进入目录:cd /home下载openJDK-1.8.0并安装:wget https://sandbox-experiment-resource-north-4.obs.cn-north-4.myhuaweicloud.com/hadoop-performance-tuning/OpenJDK8U-jdk_aarch64_linux_hotspot_8u252b09.tar.gz#解压tar -zxf OpenJDK8U-jdk_aarch64_linux_hotspot_8u252b09.tar.gz1.2. 配置环境变量执行如下命令,打开/etc/profile文件:vim /etc/profile点击键盘"Shift+g"移动光标至文件末尾,单击键盘“i”键进入编辑模式,在代码末尾回车下一行,添加如下内容:export JAVA_HOME=/home/jdk8u252-b09export PATH=$JAVA_HOME/bin:$PATHexport CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar添加完成,单击键盘ESC退出编辑,键入“:wq”回车保存并退出。 1.3. 环境变量生效使环境变量生效:source /etc/profile验证openJDK-1.8.0安装是否成功:java -version1.4.配置域名解析vim /etc/hosts2.安装dstat资源监控工具yum install dstat-0.7.2-12.el7 -y验证dstat是否安装成功:dstat -V3. 部署hadoop-3.1.13. 1. 获取hadoop-3.1.1软件包①下载hadoop-3.1.1安装包到/home目录下:cd /homewget https://sandbox-experiment-resource-north-4.obs.cn-north-4.myhuaweicloud.com/hadoop-performance-tuning/hadoop-3.1.1.tar.gz#解压hadoop-3.1.1tar -zxvf hadoop-3.1.1.tar.gz②建立软链接ln -s hadoop-3.1.1 hadoop③配置hadoop环境变量,打开/etc/profile文件:vim /etc/profile点击键盘"Shift+g"移动光标至文件末尾,单击键盘“i”键进入编辑模式,在代码末尾回车下一行,添加如下内容:export HADOOP_HOME=/home/hadoopexport PATH=$HADOOP_HOME/bin:$PATH添加完成,单击键盘ESC退出编辑,键入“:wq”回车保存并退出。④使环境变量生效:source /etc/profile⑤验证hadoop安装是否成功:hadoop version执行结果如下图所示,表示安装成功:3.2. 修改hadoop配置文件hadoop所有的配置文件都在$HADOOP_HOME/etc/hadoop目录下,修改以下配置文件前,需要切换到"$HADOOP_HOME/etc/hadoop"目录。cd $HADOOP_HOME/etc/hadoop/①修改hdfs-env.xml打开hadoop-env.sh文件:vim hadoop-env.sh找到hadoop-env.sh的第54行中的java目录(在命令模式下输入“:set nu”,查看行数),输入java的安装目录(),然后删除行左端“#”取消注释,并保存退出② 修改core-site.xml打开core-site.xml文件vim core-site.xml在标签之间添加如下代码并保存退出 fs.defaultFS hdfs://jack20:9000/ 设定NameNode的主机名及端口 hadoop.tmp.dir /home/hadoop/tmp/hadoop-${user.name} 指定hadoop 存储临时文件的目录 hadoop.proxyuser.hadoop.hosts * 配置该superUser允许通过代理的用户 hadoop.proxyuser.hadoop.groups * 配置该superUser允许通过代理用户所属组 ③ 修改hdfs-site.xml,打开hdfs-site.xml文件vim hdfs-site.xml在标签之间添加如下代码并保存退出 dfs.namenode.http-address jack20:50070 NameNode 地址和端口 dfs.namenode.secondary.http-address node1:50090 Secondary NameNode地址和端口 dfs.replication 3 设定 HDFS 存储文件的副本个数,默认为3 dfs.namenode.name.dir file:///home/hadoop/hadoop3.1/hdfs/name NameNode用来持续存储命名空间和交换日志的本地文件系统路径 dfs.datanode.data.dir file:///home/hadoop/hadoop3.1/hdfs/data DataNode在本地存储块文件的目录列表 dfs.namenode.checkpoint.dir file:///home/hadoop/hadoop3.1/hdfs/namesecondary 设置 Secondary NameNode存储临时镜像的本地文件系统路径。如果这是一个用逗号分隔的文件列表,则镜像将会冗余复制到所有目录 dfs.webhdfs.enabled true 是否允许网页浏览HDFS文件 dfs.stream-buffer-size 1048576 默认是4 KB,作为Hadoop缓冲区,用于Hadoop读HDFS的文件和写HDFS的文件, 还有map的输出都用到了这个缓冲区容量(如果太大了map和reduce任务可能会内存溢出) ④修改mapred-site.xml打开mapred-site.xml文件:vim mapred-site.xml在标签之间添加如下代码并保存退出 mapreduce.jobhistory.address jack20:10020 指定历史服务器端地址和端口 mapreduce.jobhistory.webapp.address jack20:19888 历史服务器web端地址和端口 mapreduce.application.classpath /home/hadoop/etc/hadoop, /home/hadoop/share/hadoop/common/*, /home/hadoop/share/hadoop/common/lib/*, /home/hadoop/share/hadoop/hdfs/*, /home/hadoop/share/hadoop/hdfs/lib/*, /home/hadoop/share/hadoop/mapreduce/*, /home/hadoop/share/hadoop/mapreduce/lib/*, /home/hadoop/share/hadoop/yarn/*, /home/hadoop/share/hadoop/yarn/lib/* mapreduce.map.memory.mb 6144 map container配置的内存的大小(调整到合适大小防止物理内存溢出) mapreduce.reduce.memory.mb 6144 reduce container配置的内存的大小(调整到合适大小防止物理内存溢出) yarn.app.mapreduce.am.env HADOOP_MAPRED_HOME=/home/hadoop mapreduce.map.env HADOOP_MAPRED_HOME=/home/hadoop mapreduce.reduce.env HADOOP_MAPRED_HOME=/home/hadoop ⑤修改yarn-site.xml打开yarn-site.xml文件:vim yarn-site.xml在标签之间添加如下代码并保存退出 yarn.resourcemanager.hostname jack20 指定ResourceManager的主机名 yarn.nodemanager.resource.memory-mb 53248 NodeManager总的可用物理内存。 注意:该参数是不可修改的,一旦设置,整个运行过程中不可动态修改。 该参数的默认值是8192MB,即使你的机器内存不够8192MB,YARN也会按照这些内存来使用, 因此,这个值通过一定要配置。 yarn.nodemanager.aux-services mapreduce_shuffle 指定MapReduce走shuffle yarn.nodemanager.aux-services.mapreduce.shuffle.class org.apache.hadoop.mapred.ShuffleHandler yarn.resourcemanager.address jack20:8032 指定ResourceManager对客户端暴露的地址和端口,客户端通过该地址向RM提交应用程序,杀死应用程序等 yarn.resourcemanager.scheduler.address jack20:8030 指定ResourceManager对ApplicationMaster暴露的访问地址。ApplicationMaster通过该地址向RM申请资源、释放资源等 yarn.resourcemanager.resource-tracker.address jack20:8031 指定ResourceManager对NodeManager暴露的地址。NodeManager通过该地址向RM汇报心跳,领取任务等 yarn.resourcemanager.admin.address jack20:8033 指定ResourceManager 对管理员暴露的访问地址。管理员通过该地址向RM发送管理命令等 yarn.resourcemanager.webapp.address jack20:8088 指定ResourceManager对外web UI地址。用户可通过该地址在浏览器中查看集群各类信息 yarn.log-aggregation-enable true 开启日志聚集功能 yarn.log.server.url http://jack20:19888/jobhistory/logs 设置日志聚集服务器地址 yarn.log-aggregation.retain-seconds 604800 设置日志保留时间为7天 ⑥将各个节点加入到workersecho jack20 > workersecho node1 > workersecho node2 > workers⑦修改dfs和yarn的启动脚本,添加root用户权限(1)打开start-dfs.sh和stop-dfs.sh文件:vim /home/hadoop/sbin/start-dfs.shvim /home/hadoop/sbin/stop-dfs.sh单击键盘“i”键进入编辑模式,在两个配置文件的第一行添加并保存退出:HDFS_DATANODE_USER=rootHDFS_DATANODE_SECURE_USER=hdfsHDFS_NAMENODE_USER=rootHDFS_SECONDARYNAMENODE_USER=root(2)打开start-yarn.sh 和 stop-yarn.sh文件vim /home/hadoop/sbin/start-yarn.shvim /home/hadoop/sbin/stop-yarn.sh单击键盘“i”键进入编辑模式,在两个配置文件的第一行添加并保存退出:YARN_RESOURCEMANAGER_USER=rootHADOOP_SECURE_DN_USER=yarnYARN_NODEMANAGER_USER=root4.集群配置&节点间免密登录(1)连通性测试(2)从主节点同步各个节点域名解析文件scp /etc/hosts node1:/etc/hostsscp /etc/hosts node2:/etc/hosts(3) 配置各节点间SSH免密登录分别在三台服务器中输入命令生成私钥和公钥(提示输入时按回车即可):ssh-keygen -t rsajack20:node1:node2:然后分别在三台服务器上输入命令以复制公钥到服务器中:ssh-copy-id -i ~/.ssh/id_rsa.pub root@jack20ssh-copy-id -i ~/.ssh/id_rsa.pub root@node1ssh-copy-id -i ~/.ssh/id_rsa.pub root@node2①继续连接:输入“yes”回车;②输入密码(输入密码时,命令行窗口不会显示密码,输完之后直接回车)查看所有协商的秘钥SSH免密登录测试:Jack20->node1->node2->jack20->node2->node1->jack20(4) 复制hadoop到各datanode并修改把jack20的hadoop目录、jdk目录、/etc/hosts、/etc/profile复制到node1,node2节点cd $HADOOP_HOME/..#hadoop目录scp -r hadoop node1:/homescp -r hadoop node2:/home #java目录scp -r jdk8u252-b09 node1:/homescp -r jdk8u252-b09 node2:/home登录修改各服务器java和haoop环境变量vim /etc/profile点击键盘"Shift+g"移动光标至文件末尾,单击键盘“i”键进入编辑模式,在代码末尾回车下一行,添加如下内容并保存退出:export JAVA_HOME=/home/jdk8u252-b09export PATH=$JAVA_HOME/bin:$PATHexport CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jarexport HADOOP_HOME=/home/hadoopexport PATH=$HADOOP_HOME/bin:$PATH使环境变量生效:source /etc/profile5.启动hadoop注意:如果启动报错,请检查hadoop配置文件是否配置有误。第一次启动前一定要格式化HDFS:hdfs namenode -format注意:提示信息的倒数第2行出现“>= 0”表示格式化成功,如图。在Linux中,0表示成功,1表示失败。因此,如果返回“1”,就应该好好分析前面的错误提示信息,一 般来说是前面配置文件和hosts文件的问题,修改后同步到其他节点上以保持相同环境,再接着执行格式化操作执行脚本命令群起节点cd /home/hadoop/sbin#群起节点./start-all.sh 启动HDFS后,可以发现jack20节点作为NameNode, Node1、 Node2作为DataNode,而Node1也作为辅助NameNode ( Secondary NameNode )。可以通过jps命令在各节点上验证HDFS是否启动。jps 也是Windows中的命令,表示开启的Java进程如果出现下图所示的结果,就表示验证成功。客户端Web访问测试:(1)RMwebUI界面http://IP:8088(2)NameNode的webUI界面http://IP:500706.集群基准测试(1)使用Hadoop自带的WordCount例子/share/Hadoop/mapredu icehadoop-mapreduce-examples-3.1.1.jar验证集群#创建目录,目录/data/wordcount用来存储Hadoop自带的WordCount例子的数据文件,运行这个MapReduce任务的结果输出到目录中的/output/wordcount文件中hdfs dfs -mkdir -p /data/wordcounthdfs dfs -mkdir -p /output/ #将本地文件上传到HDFS中(这里上传一个配置文件),执行如下命令hdfs dfs -put /home/hadoop/etc/hadoop/core-site.xml /data/wordcount可以查看,上传后的文件情况,执行如下命令hdfs dfs -ls /data/wordcount下面运行WordCount案例,执行如下命令hadoop jar /home/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.1.jar wordcount /data/wordcount /output/wordcount(2)DFSIO测试使用hadoop的DFSIO写入50个文件,每个文件1000Mhadoop jar /home/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.1-tests.jar TestDFSIO -write -nrFiles 50 -filesize 1000可以在RMwebUI界面查看当前任务的基本情况,包括内存使用量,CPU使用量等在NameNode的webUI界面查看刚刚DFSIO测试的各个节点HDFS占用情况(3)计算圆周率的大小hadoop jar /home/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.1-tests.jar pi 20 20静静等待结果就可以~
-
【Document Link】/【文档链接】 cid:link_0 【Issues Section】/【问题文档片段】 在ModelArts上对bert进行分布式训练,按照文档上所描述方式b进行设置 【Existing Issues】/【存在的问题】 ModelArts设置如下: 但是ModelArts训练结果显示系统jobstart_hccl.json不匹配。 系统jobstart_hccl.json如下所示 【Expected Result】【预期结果】 希望搞清楚hccl.json格式为何不匹配,在modelarts上进行分布式训练这个报错如何解决
-
摘要:全场景可扩展的分布式协同AI基准测试项目 Ianvs(雅努斯),能为算法及服务开发者提供全面开发套件支持,以研发、衡量和优化分布式协同AI系统。 本文分享自华为云社区《KubeEdge|分布式协同AI基准测试项目Ianvs:工业场景提升5倍研发效率》,作者 华为云|郑子木。 在边缘计算的浪潮中,AI是边缘云乃至分布式云中最重要的应用。随着边缘设备的广泛使用和性能提升,将人工智能相关的部分任务部署到边缘设备已经成为必然趋势。KubeEdge-Sedna子项目,作为业界首个分布式协同AI框架,基于KubeEdge提供的边云协同能力,支持现有AI类应用无缝下沉到边缘,降低分布式协同机器学习服务构建与部署成本、提升模型性能、保护数据隐私等。本篇文章为大家阐释分布式协同AI技术背景,研发落地三大生态挑战和社区调研报告,并对全新社区SIG AI子项目(于KubeEdge Summit 2022 重磅发布):全场景可扩展的分布式协同AI基准测试项目 Ianvs(雅努斯),进行介绍。该项目能为算法及服务开发者提供全面开发套件支持,以研发、衡量和优化分布式协同AI系统。欢迎关注Ianvs项目,持续获得第一手独家公开数据集与完善基准测试配套。开源项目GitHub地址:cid:link_101 分布式协同AI技术背景随着边侧算力逐步强化,时代也正在见证边缘AI往分布式协同AI的持续演变。分布式协同AI技术是指基于边缘设备、边缘服务器、云服务器利用多节点分布式乃至多节点协同方式实现人工智能系统的技术。虽然还在发展初期,分布式协同AI成为必然趋势的驱动力主要有二。第一,由于数据首先在边缘产生,有大量数据处理需要在边侧运行。第二,由于边侧逐步具备AI能力,高阶数据处理需要在边侧运行。在实际应用场景中,以往常见的是云上训练、边侧推理模式,现在在各个场合已经频繁听到边云协同推理、边云协同增量学习、边云协同终身学习、联邦学习等协同模式,可以看到边缘AI向边云协同乃至分布式协同的演进正在发生。上述这些都使得我们有理由相信,分布式协同AI是大势所趋。关于分布式协同AI的产业发展形态,根据Research Dive Analysis预测,全球边缘AI乃至分布式协同AI软件(算法、平台等)市场规模将从2019年的4.36亿美元增长到2023年的30.93亿美元。分布式协同AI解决方案市场规模比例显著大于服务。也就是说,与直接提供通用服务相比,结合行业解决方案可能是分布式协同AI商业变现的主要途径。至于与行业解决方案结合的话,据麦肯锡预测,边缘AI乃至分布式协同AI至少覆盖12个行业。可以看到,相关行业解决方案的市场领域多样化,通过产业链聚拢乃至垄断方式来收割商业价值无疑存在规模复制挑战。因此,从产业发展形态出发考虑,一家企业独大并不可取,与生态伙伴同行才有可能走得更远。鉴于上述分布式协同AI技术趋势和产业发展形态,KubeEdge社区基于CNCF成熟治理模式,成立了KubeEdge SIG AI。其工作目标是基于 KubeEdge 的边云协同能力,提供具有低成本、高性能、易用性、隐私保护等优势的边缘智能平台。SIG AI工作范围包括:1、 构建分布式协同AI框架,高效合理利用端、边、云的各类资源,并能根据负载和应用类型实时地进行模型调度,实现高性能和低成本兼备的边缘AI系统。2、 构建分布式协同AI基准测试,识别AI系统中重要指标,帮助用户评估边缘AI系统的功能和性能,以衡量和优化分布式协同AI系统,揭露各应用场景的最佳实践。 3、积极与周边AI平台、边缘智能硬件厂商等伙伴开展合作,实现自动化的异构资源匹配,减少用户管理异构资源的工作量,提升AI 应用的部署管理维护效率。02 分布式协同AI应用落地挑战调研报告KubeEdge SIG AI及整个行业各个技术方案落地与成果转化到产业的进程正在紧锣密鼓地进行,大家也经常提到sedna进入质检、卫星和园区的案例。但仅凭技术是不足够完成落地和产业转化的。当前学界业界很多团队已经遇到各式各样的困难。社区从算法开发者、服务开发者和技术布道者三种边缘AI研发角色的需求出发,启动了边缘AI研发落地生态挑战问卷调研,希望进一步了解边缘AI方案落地与产业转化过程中遇到的,诸如研发资源难获取、工具链不完备等主要依赖社区分工与共享的生态挑战。截止2021年9月20日已回收有效答卷180份。调研结果发现了20+生态挑战,问卷开放选项采集到49条补充意见和8条补充建议。• 调研对象职业主要是工业界从业者(53.45%),其次是在校学生(31.03%)和学术界研究者(25.86%)。• 调研对象的技术方向主要是边缘AI及其应用(55.75%)、AI及其应用(49.43%)、边缘计算及其应用(42.53%)。也有约四分之一的方向为云计算及其应用(25.86%),以及少量的其它方向(13.22%)。基于调研结果已发布业界首份边缘AI落地生态挑战调研报告,可通过下方二维码扫描获取。我们也绘制了三种不同角色所反馈的生态挑战词云。报告的重点内容简要介绍如下:• 对于算法开发者排名第一的挑战是实际业务数据集及配套算法难以获取,排名第二的挑战是重复部署整套端边云系统过于沉重。从中我们可以对于算法开发总结出研发资源支持少的生态挑战。• 对于服务开发者排名第一的挑战是通用方案整体性能不一定满足特定业务需求,排名第二的挑战是自研业务算法和系统方案周期长成本高。从中我们可以针对服务开发总结出方案选型成本高的生态挑战。• 对于技术布道者排名第一的挑战是缺乏商业成功案例,排名第二的挑战是缺乏与现有方案系统对比,包括成本、部署要求。从各挑战中可以针对技术布道者总结出价值呈现晦涩理解难的生态挑战。基于本次调研,我们从刚刚提到的几个挑战出发,进一步了解这个领域各位开发者的心声和行业痛点,探索可能的解决方案。核心痛点 I:业务数据集及其配套算法难以获取在调研过程,算法开发者跟社区反馈得最多的还是业务数据集机器配套算法难以获取• 正在打造边缘AI算法利器,有什么实际业务可以练兵吗,在哪找?• 我认识一家边缘计算公司在做工业质检,质检靠谱数据有吗?可以先试一试。• 公开数据集太多,大海捞针翻到头都秃了。• 数据集要么质量不太高,或者要么跟具体业务不太匹配……• 真实、好用的数据集说起来轻巧,但新业务数据集找起来太累了吧。• 也不知道找哪家公司合适;自己去买设备采集?从中可总结出核心痛点:业务数据集及其配套算法难以获取,同时封闭测试环境难以跟上各类新业务孵化。同时看到第一个需求:分布式协同AI标准数据集和配套算法管理与下载,快速上手真实业务。核心痛点 II:通用方案不满足特定需求在调研过程,服务开发者跟社区反馈得最多的则是通用方案不一定满足特定业务需求。• 业务问题多得很……一宿一宿睡不着,天天挨客户骂,现场各种安抚疲于奔命。顶会论文?真的没有时间看。• 现有测试数据和指标要求与实际业务差距过大。听说算法进展很快,但调研大半年,尝试很多算法,要真正能做进客户心窝里还是很困难的。• 新业务不断产生,现有测试需要对应改进。但现有测试都是那几个玩具数据集和指标,基准固化后还不能改。亟需针对特定场景个性化配置。• 场景很多,问题更多。针对不同场景甚至相同场景的不同算法范式要针对不同架构、接口和参数使用不同测试工具。这导致在不同边侧场景,进行各种测试实验非常繁琐。要规模化被迫采用简单技术。• 自研人力物力成本高,比如设备贵、人才高薪。挑战复杂难题?中小企业试试就逝世,不如交给大企业或者高校(躺)。从中可总结出核心痛点:全场景多范式测试成本高、个性化场景的测试用例准备繁琐。同时看到第二个需求:个性化、全场景测试乃至自动化测试,对症下药并降低研发成本。03 分布式协同AI基准测试Ianvs项目开源发布针对上述痛点和挑战,KubeEdge SIG AI也为大家带来了一个全新的社区子项目 全场景可扩展的分布式协同AI基准测试工具 Ianvs来解决以上问题。借助单机就可以完成分布式协同AI前期研发工作。项目地址:cid:link_1全场景可扩展的分布式协同AI基准测试工具 Ianvs1、 针对业务数据集难以获取,数据采集与处理成本高的痛点,ianvs提供丰富AI生态,做到开箱即用。ianvs开源数据集与5+配套算法,覆盖预处理、预训练、训练、推理、后处理全流程,零改造开箱即用。2、 针对封闭测试环境难跟上各类新业务孵化的痛点,ianvs提供可扩展开放工具链。测试环境管理实现自定义动态配置测试数据集、指标,告别封闭守旧的测试环境。3、 针对全场景多范式测试成本高的痛点,ianvs提供全场景灵活切换。ianvs测试用例管理统一不同场景及其AI算法架构与接口,能用一套工具同时兼容多种AI范式。4、 针对个性化场景的测试用例准备繁琐的痛点,ianvs提供低代码生成测试用例。ianvs测试用例管理基于网格搜索等辅助生成测试用例,比如一个配置文件即可实现多个超参测试,降低超参搜索时的繁琐重复编程。Ianvs同步发布一个新的工业质检数据集PCB-AoI。PCB-AoI 数据集是开源分布式协同 AI 基准测试项目 KubeEdge-Ianvs 的一部分。 Ianvs 很荣幸成为第一个发布此数据集的站点,Ianvs 项目相关社区成员将PCB-AoI 公共数据集同时也放在 Kaggle和云服务上方便各位下载。PCB-AoI工业质检公开数据集下载链接请参见:https://ianvs.readthedocs.io/en/latest/proposals/scenarios/industrial-defect-detection/pcb-aoi.htmlPCB-AoI数据集由KubeEdge SIG AI 来自中国电信和瑞斯康达的成员发布。在这个数据集中,收集了 230 多个板,图像数量增加到 1200 多个。具体来说,数据集包括两部分,即训练集和测试集。训练集包括 173 个板,而测试集包括 60 个板。也就是说,就 PCB 板而言,train-test 比率约为 3:1。进行了数据增强,将图像方面的训练测试比率提高到 1211:60(约 20:1)。 train_data 和 test_data 的两个目录都包含索引文件,用于关联原始图像和注释标签。这里同步展示一个Ianvs在工业场景的案例。本案例是基于PCB-AoI数据集的工业质检。该案例基于工业视觉AoI设备输出视频图片,检测PCB板是否存在贴装异常。案例提供了单任务学习和边云协同增量学习两种范式。在本案例的单任务学习范式中,数据全部上云,在训练阶段获得所有数据。在本案例的边云协同增量学习范式中,数据部分上云,训练数据分两轮提供。Ianvs除算法指标外,还可监控系统指标,如样本上云比例指标。测试的基础模型选用特征图金字塔网络FPN(Feature Pyramid Networks)。基准测试结果显示,待测FPN算法F1性能在0.84-0.95波动。边云协同增量学习可节省近50%的上云数据量,同时获得10%以上的精度提升。如下图所示,增量前1处漏检:仅检出7处,增量后全部检出:检出全部8处缺陷。Ianvs将提供开箱即用的数据集与配套算法,借助支持多场景范式切换和易扩展的工具链,以及测试用例的低代码自动生成能力,来降低开发者在分布式协同AI应用开发测试时的门槛,技术验证时间半年降低到1个月,提升5倍研发效率。Ianvs发布之际在此也特别感谢社区10+初创单位。社区也持续募集在Ianvs项目上的合作伙伴,共同孵化开源项目、研究报告及行业标准等。KubeEdge-Ianvs 初创单位04 Ianvs未来工作展望对于未来工作上,Ianvs项目希望进一步解决各位社区用户的问题。首先,算法开发者们投票第二位的挑战是重复部署端边云系统费时费力的问题• 只是想聚焦系统上的分布式调度而已,需要自己把迁移学习、增量学习、联邦学习算法啥的协同机器学习算法学一遍很痛苦• 想聚焦系统上的AI算法而已,真需要写那么多系统代码,把整一套边云协同系统自己搭起来非常不友善• 费力气搭系统,也不足以落地应用到工业界……工业界有些系统机制,包括模型管理和维护等,能为模型上线护航• 好了,组里花大钱搭起来,系统和算法终于能用了,但眼看着一年过去,马上毕业来不及科研……AI系统的构建对于高校团队来说费时过长成本过高,简直大坑• 很多公司已经有了,重复造轮子感觉憋屈。想在巨人肩膀上实现系统突破,搞大事情因此第一项未来工作可以是实现工业级分布式协同系统仿真,提升方案研发效率。另外一个未来工作,可以是关于技术布道者和最终用户的价值呈现问题• 缺乏与先前方案的对比。受众不明白什么是边缘,跟以前有什么区别• 客户有数据,伙伴有研发,但因数据使用协议,数据无法出边缘,经常需要驻场调整• 没有界面,缺乏demo,方案不直观,客户看不懂,没有吸引力因此第二项未来工作可以是算法/范式测试排行与最佳方案展示,做好价值呈现。Ianvs项目规划路标如下图。欢迎关注Ianvs项目,持续获得第一手独家公开数据集与完善基准测试配套。社区也持续募集在Ianvs项目上的合作伙伴,共同孵化开源项目、研究报告及行业标准等。开源项目GitHub地址:cid:link_1Ianvs 项目路标
-
我这边在做一个模型输入比较动态的强化学习算法,无法转换成静态图,然后在官方文档上看到“使用分布式训练需要指定运行模式为图模式(PyNative模式不支持并行)”这样的描述,有点不理解。不考虑模型并行或者混合并行之类的复杂方案,简单数据并行不就是把各个节点的梯度做allreduce求平均么,为啥不支持PyNative模式呢?PyTorch、TF之类的Eager模式也没听说有这个限制。
-
物理环境为一台裸机,8张Ascend 910卡,MindSpore 1.7,并行模式是半自动并行。任务启动后,查看各device中训练日志发现报错:然而在本机上执行python中import pcl_pangu.context并未出错,怀疑是各个device上环境变量设置出错,查看env0.log如下:可以看到python路径和相关库的路径都在其中,在本环境下执行MindSpore分布式训练样例pytest成功,但执行python就会出现此情况。为什么会出现这种情况?附上执行脚本截图:代码部分截图:
-
Q1:Ability page slice三者之间的关系是什么?A1:Ability是统称 , PageAbility是其中一种, Slice是PageAbility里的一个展示单元。Q2:创建和使用Data的一般步骤包括什么?A2:定义自己的Data类,继承Ability类。实现自定义的Data类,对内实现数据访问,对外提供功能API接口。在config.json中,配置Ability的类型为Data,配置权限等。使用者通过URI访问自定义Data。Q3:Page生命周期是Page对象从创建到销毁的过程,期间会经历哪些哪些状态转换回调方法?A3:onStart()、onActive()、onInActive()、onBackground()、onForeground()、onStop() 6)onStart()
-
# 一、问题描述 生产环境,执行update/delete相关业务操作时,业务报错: ERROR: dn_6003_6004: Lock wait timeout: thread 139858583217920 on node dn_6003_6004 waiting for ShareLock on transaction 55363311 after 120000.061 ms # 二、问题背景 并发操作列存表 # 三、问题分析 分布式环境下,列存表的最小存储单位是CU,如果并发操作同一个CU时,可能会产生等锁报错; # 四、问题解决 对并发操作进行串行: 原业务语句: ``` start transaction; delete from TARGET_A where xxx='xxx’; ........ update TARGET_A where xxx='xxx’…… end transaction; ``` 修改后 在update语句前增加一个select语句,在每一个业务操作前,修改如下: ``` start transaction; select name from CONTROL_TABLE where name = 'target_a' for update; delete from TARGET_A where xxx='xxx’; ........ update TARGET_A where xxx='xxx’…… end transaction; ``` control_table为新建行存表,只有一个字段,字段的取值为要更新的目标表名。 # 五、问题总结 并发update/delete在分布式环境比较常见,如果业务不想产生等锁报错可以串行执行。 在并发更新同一张目标表时,首先会利用这张表获取对应记录的行级锁,其他并发任务等待行级锁释放;等到前序事务提交完成后,释放control_table的行级锁,后续事务获取行存表的行锁后,再提交update列存表语句。通过这种方式实现delete/update语句的串行执行,避免并发更新的锁超时报错。
推荐直播
-
华为AI技术发展与挑战:集成需求分析的实战指南
2024/11/26 周二 18:20-20:20
Alex 华为云学堂技术讲师
本期直播将综合讨论华为AI技术的发展现状,技术挑战,并深入探讨华为AI应用开发过程中的需求分析过程,从理论到实践帮助开发者快速掌握华为AI应用集成需求的框架和方法。
去报名 -
华为云DataArts+DWS助力企业数据治理一站式解决方案及应用实践
2024/11/27 周三 16:30-18:00
Walter.chi 华为云数据治理DTSE技术布道师
想知道数据治理项目中,数据主题域如何合理划分?数据标准及主数据标准如何制定?数仓分层模型如何合理规划?华为云DataArts+DWS助力企业数据治理项目一站式解决方案和应用实践告诉您答案!本期将从数据趋势、数据治理方案、数据治理规划及落地,案例分享四个方面来助力企业数据治理项目合理咨询规划及顺利实施。
去报名
热门标签