首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    高级数据科学家阿萨姆:如何应对机器学习过程中的多项选择问题?| 分享总结

    AI 研习社按:随着硬件算力的上升、数据量的加大以及各种新算法的浮现,机器学习也变得一天比一天火热。不夸张的说,这是机器学习的时代。然而,机器学习虽然能够给出惊艳的结果,但其有限的解释性也常被人戏称为“黑箱”。而实践者在使用机器学习的过程中往往也会面临各种各样的选择。本文的目的就是帮助实践者在使用机器学习过程中做出正确的选择和判断。文章内容根据知乎人气答主阿萨姆在雷锋网AI研习社上直播分享整理而成。 阿萨姆,普华永道高级数据科学家,负责统计学习模型开发。有丰富的工业及学术经验,擅长将理论知识应用于实践中。曾

    06

    OPPO 大数据诊断平台“罗盘”正式开源

    OPPO 大数据平台目前有 20+个服务组件,数据量超 1EB,离线任务数近百万,实时任务数千,数据开发分析师超千人。这也带来了系统复杂度的问题,一方面是用户经常对自己的任务运行状况“摸不着头脑”,不管是性能问题,还是参数配置问题,甚至是一些常见的权限报错问题,都需要咨询平台给出具体的解决方案;另一方面是平台面对各类繁杂任务,运维人员经常需要对任务故障定位和排除,由于任务链路长,组件日志多,运维压力大。因此急需对任务进行实时监控和诊断,不仅要能够帮助用户快速定位异常问题,还需给出具体的建议和优化方案,同时还能治理各类“僵尸”和不合理任务,从而达到降本增效的目的。据调研,目前业界尚无成熟的开源任务诊断平台。为此我们开发了大数据诊断平台,通过诊断平台周优化任务实例数超2 万,取得了良好的效果。

    02

    ACP互联网架构认证笔记-EDAS企业级分布式应用服务

    EDAS支持语言Java,C++,PHP。EDAS支持Idea,Eclipse;Eclipse插件安装等编译工具。EDAS初级版仅支持应用的部署管理,不支持HSF功能。EDAS基础版不支持RPC框架。 EDAS提供高性能的RPC框架,能构建高可用的分布式系统,考虑各个应用之间的分布式服务发现、服务路由、服务调用以及服务安全等细节。EDAS能单独部署到公司内网(轻量配置中心)。 EDAS HSF服务框架保证用户每次分布式调用的稳定与安全。在服务注册、服务订阅以及服务调用等环节都进行严格的服务鉴权。 HSF设置超时时间 : 通过HSF标签methodSpecials和clientTimeout进行配置,优先级由高到低是 : 客户端methodSpecials>客户端clientTimeout>服务端methodSpecials>服务端clientTimeout EDAS控制台域名 : https://edas.console.aliyun.com EDAS控制台提供日志浏览功能,可查看服务器上所部署的应用运行日志。收敛日志用于将单个应用中类似格式的日志合并和排序。收敛日志配置后需要等待大概5分钟才能生效。 EDAS安装轻量配置中心 : 启动配置中心将会占用此台机器的8080和9600端口,需要在hosts中添加 {轻量配置中心公网 ip} jmenv.tbsite.net。如果此台机器是多网卡的,可启动脚本startup.bat或startup.sh中添加启动参数: -Daddress.server.ip={指定的 IP 地址};通过 -Dhsf.server.ip参数指定要注册服务的IP。 EDAS 服务限流的限流规则(限流规则仅适用于服务提供者)能够从QPS和线程两个维度进行配置。可进行HSF限流和HTTP限流。 EDAS 提供了从响应时间维度对降级规则(降级规则仅仅适合服务消费者)的配置。 EDAS 鹰眼监控系统能够分析分布式系统的每一次系统调用、消息发送和数据库访问。主要包括应用拓扑(可查看调用拓扑和流量QPS),调用链查询(可查看慢业务和出错业务),调用链详情(基于TraceId查询)。 EDAS 提供报警功能,但目前只有短信与邮件通知的方式,报警联系人只能是主账号或者子账号。 EDAS 的应用主要分为两种类型:中间件服务化应用(JAR/WAR包类型的普通应用和Docker应用)和 Kubernetes 应用。Kubernetes应用只支持VPC网络。 EDAS 的应用部署类型有两种 : ECS独占实例(在一台独立的ECS机器上,仅允许部署单独一个应用),Docker实例(单个应用在同一ECS上只能部署一个实例),所以一台ECS可以部署多个实例。 EDAS 能够针对应用的服务调用情况,对服务的QPS、响应时间(RT)和出错率进行全方面的监控。 EDAS 能够针对应用的运行状态,对机器的CPU、内存、负载(Load)、网络和磁盘等基础指标进行详细的监控。EDAS还提供容器监控功能(应用诊断)。基础监控(可提供以应用为维度的数据)面向的是机器,容器监控面向是应用所在的容器。基础监控存在时延,容器监控基本是实时的。 EDAS 提供弹性伸缩功能来根据集群内服务器的CPU、RT和Load三个指标实现自动的扩容或者缩容。 EDAS 对应用的生命周期管理,包括创建、部署、启动/停止和删除(应用删除不可恢复)。可设置JVM参数,Tomcat参数,可对应用的实例分组(可按分组部署应用,添加实例到分组),可配置负载均衡。可配置健康检测URL。 EDAS 包含两种集群:Swarm(部署普通应用和Docker应用)和Kubernetes集群(部署Kubernetes应用)。 EDAS 的配置推送分为全局配置推送和应用内部的配置推送。全局配置推送能操作该用户的所有配置信息,应用内的配置推送只能操作该应用所属的配置信息。一个配置信息由三元组(group、DataId、Content)组成。 EDAS 提供主子账号体系,付费账号都是主账号(拥有EDAS所有资源,所有权限),但不是所有的主账号都是付费账号。1个付费账号最多能绑定5个主账号。RAM子账号由主账号在RAM系统中创建,子账号名要在主账号内唯一。RAM账号有两种授权方式 : RAM授权,EDAS授权(两种方式互斥,有了RAM授权,那么就不能在EDAS中授权),主账号可以对绑定的子账号(用户)进行权限分配、资源分配等。应用的授权只能是主账号对子账号进行授权。 EDAS 的资源主要是指云服务器ECS(Elastic Compute Service)、负载均衡SLB(Server Load Balancer)、专有网络VPC(Virtual Private Cloud)这三类。 VPC环境调用链和监控数据需要有访问请求流量才会产生,如果无客户访问网站,

    07

    【Profinet专栏】关于结构化思维在PROFINET诊断中应用的思考

    【0. 前言】 工业4.0趋势下的机器故障诊断,正在向更智能化的预防性维护系统发展:通过构建覆盖设备上各个部件的传感器与通讯网络,几乎所有电动、气动、液压、机械元件的状态数据都能得到实时监控,由此可结合机器学习与大数据分析,再结合日趋完善的故障处理知识库与决策系统,实现对机器异常状态的实时感知,预测出可能的故障隐患点,第一时间通知用户并提供最优化的维护方案。那么,这是否就意味着,经典的基于人的经验的故障诊断,今后就毫无用武之地了呢? 【1.传统故障诊断的价值与局限性】 尽管拥有了越来越强大的诊断工具,人,依旧是当前故障诊断活动中的核心。因为故障诊断其实是一个非常复杂的活动,不单单面向机器,而且面向各种各样不同知识与社会背景的用户。这就要求诊断者不仅拥有丰富的机器故障处理经验,而且需要具备良好的沟通协作与社交能力,因此体现出一定的服务价值。但同时我们也必须承认,人在当前机器故障诊断中的局限性也越来越明显了,因为机器正变得越来越复杂,哪怕是经验再丰富的诊断者,在面对千奇百怪的疑难杂症时,也难免会遇到自身知识技能的盲点。所以很多长期从事现场诊断的工作者都会有相似的体验:当遇到一个前所未见的故障现象,苦思冥想无果,承受着各方的压力,感觉是苦恼的。这个时候,想要化解被动局面就变得难上加难,而想尽快获得支援也不是一件容易的事情,因为首先你要将这个连你自己都没搞清楚是怎么回事的问题,客观的描述出来,让别人充分了解你所处的困境、异常的内容与背景,才有可能引起对方的重视。那么如何突破这些困局?不妨试试结构化思维的方法。 【2.结构化思维有助于解决传统故障诊断遇到的难题】 在传统的基于人的经验的诊断过程中,除了对诊断者经验的过度依赖,还伴随着跳跃性思维所产生的一些不确定性因素。跳跃性思维,有时候能起到剑走偏锋出其不意的神奇效果,帮助人们在故障诊断中走出一条捷径,但是一旦计划落空其后果也是相当尴尬,可能会使诊断活动陷入停滞甚至混乱。当面对现场出现的疑难杂症,能够保持头脑冷静采用结构化思维,相对来说是个更加稳妥的选择。因为这样就能使我们从多个侧面进行思考,深刻分析导致问题出现的原因,系统性制定行动方案,采取性价比最优的手段,使诊断计划得以高效率开展,有助于使问题得到彻底解决,也有助于形成信息全面逻辑清晰的问题调研报告。下面以典型的工厂自动化项目中PROFINET通讯网络问题诊断为示例,推演结构化思维方法论在机器故障诊断活动的应用思路。 【3.1.结构化诊断步骤1:4W1H,充分理解面临的问题】 WHAT:故障的表面现象是什么?例如:用户看到的是某机电设备无法动作、生产线停机,但是更换备件仍不能修复,那就不是头痛医头脚痛医脚那样简单。搞清楚表象背后的本质是什么?例如:借助各种通讯工具(特别是远程访问软件)与现场联系,了解用户曾经做了什么,获取现场设备与控制器状态的照片与录像,获取报警信息与报错代码,如果发现设备本身功能是正常的,而有证据显示控制器曾经丢失与设备的网络连接与数据交换,那么就可以初步确认故障本质其实是现场总线/以太网通讯控制网络方面,或者是机器设备系统集成方面的问题。搞清楚该机器遵循的是什么行业的什么公司的什么标准?例如:某些重大自动化项目,在规划阶段就已经定义了通讯网络的协议与架构,具体到参数设置固件版本等细节都有明文规定,这些都是标准的一部分,事先需要充分了解。 WHEN:什么时候 / 每隔多长时间发生该故障?例如:长时间关机后再上电时 / 每次开机都有 / 周期性可人为重现 / 偶发但可人为重现 / 偶发且无法人为重现(这是最困难的一种情况,往往重启后又正常了,需要一直等到下一次发生类似故障时,保护好现场,做尽可能完整的故障记录表,才有可能进行下一步的原因分析)。 WHERE:故障点具体在哪里?

    02
    领券