• [技术干货] 【鲲鹏应用创新大赛】openGauss赛题解读
    【鲲鹏应用创新大赛】openGauss赛题解读鲲鹏创新应用大赛openGauss赛道是openGauss开源数据库社区为开发者准备的大赛,此次直播将围绕特性命题赛的赛题进行解读。直播回放地址:https://bbs.huaweicloud.com/live/kunpeng_live/202106241900.html赛事报名总地址:https://opengauss.org/zh/events/hdc.2021.developer.html大赛简介鲲鹏应用创新大赛·openGauss赛道是openGauss开源数据库社区为开发者准备的大赛。开发者可以通过提交Issue和PR参加任务打榜赛赢得奖励,也可以和导师一起完成特性命题赛,解决openGauss社区中亟待解决的问题。无论你通过那种方式参与openGauss赛道,你都可以获得丰富的物质奖励,你的ID也会永远在 openGauss社区中。openGauss是一款开源关系型数据库管理系统,采用木兰宽松许可证v2发行。openGauss深度融合华为在数据库领域多年的经验,结合企业级场景需求,持续构建竞争力特性。同时openGauss也是一个开源的数据库平台,鼓励社区贡献、合作。
  • [技术干货] “华为云·东吴杯”2021数字化转型创新应用大赛进行大赛解读和答疑
    大赛介绍     “华为云-东吴杯”2021数字化转型创新应用大赛(以下简称“大赛”)是由吴中经济技术开发区管理委员会主办,华为(苏州)DevCloud创新中心、苏州吴中太湖软件产业园发展有限公司承办。以“数聚吴中,智创未来”为主题,是面向全国的数字化转型创新应用交流赛事。大赛旨在促进数字化转型技术与实体产业深度融合,聚焦工业智能化应用落地的全场景创新,提升产业效率,繁荣产业氛围、打造苏州吴中区高新产业高地,传播区内产业政策环境,推动吴中区数字化转型人才集聚、产业集聚。      大赛是面向全国的数字化转型交流赛事,通过以赛促学,产教结合的形式开展,推动云技术在机器人和智能制造、装备制造、工业互联网、人工智能、生物医药等实体行业的应用。通过大赛,搭建一个技术交流、人才培养、机遇共创的开发者平台,汇聚全国数字化转型人才,迸发创新思想。直播回顾查看:https://bbs.huaweicloud.com/live/education_live/202106281430.html参赛地址:https://competition.huaweicloud.com/information/1000041490/introduction一、赛题背景        随着人们生活水平的提高,我国的汽车消费量是世界上排在前列的国家之一。同样,汽车工业也是支持我国实体经济发展的关键产业,与汽车有关的各种产业也多种多样。汽车行业与我们每个人的人身安全息息有关。汽车零部件的质量是整车质量的基础,汽车零件的缺陷检测可以帮助提高汽车的安全性。然而目前人工目视检测的方式不仅存在效率低下,还可能由于人工疲劳造成缺陷零部件流入行业下流,造成潜在的安全风险。因此,为了提高生产效率,发挥人工智能的优势,本赛题旨在鼓励大家研发汽车零部件缺陷自动检测算法。二、赛题说明       本赛题的任务是基于工业相机成像预测三种汽车零部件表面存在多种缺陷。三、数据说明       本次比赛数据来自工业相机成像。分为训练集和测试集。数据集由三种数据构成:轴承、火花塞和摇把。       点击此处下载数据集;点击此处查看baseline,对baseline代码及文档有任何疑问,可直接在baseline帖子回帖。       训练集对参赛选手可见,包括轴承、火花塞和摇把三种汽车零部件。       测试集对参赛选手不可见,包括轴承、火花塞和摇把三种物体。
  • [参赛经验分享] 上海理工大应用开发设计大赛—AppEngine使用
    顺着AppEngine指导教程一步步搞,发现AppEngine很先进的感觉。第一点它是一个云上的,网页上的开发平台,不需要配置复杂的开发环境。第二点就是数据的存储的功能继承在平台里了,功能非常简洁明了。第三点就是前端页面可以拖拽布局,组件还支持MVVM,有着很好的低代码开发体验。总之就是一句话,AppEngine平台的上手真的很简单。开发页面的文件夹起名和MVC模型视图控制思想感觉也很相似,Logic对应着控制,Model就是模型了,Page就是视图,开发页面一上来就有一种亲切感。
  • [参赛经验分享] 上海理工大应用开发设计大赛——来呀一起掉头发呀
    对于一款设计者已经明确其功能需求的轻量级应用,一个月的开发时间加上延期的时间本应是绰绰有余。但团队的两位成员限于知识水平与项目开发经验,真正着手时还是遇到了不少“意料之中”却“难以解决”的困难。比如在页面模型绑定时,绑定何种模型,怎么与脚本关联,脚本变量怎么设置等,我们或许明明知道原理是什么,明明知道应该怎么做,冥冥之中好像也看到了效果,但是——钻了一个月的牛角尖似乎还是没钻出来。加之椅子周围总也扫不干净的头发,两个人都忍不住焦虑起来。队友第N次说要放弃时我都一笑了之,但凡我们之中还有一个在钻牛角尖,另一个总不会甩手不管的。我们也只能珍惜每一次线上答疑的机会小心翼翼地问出自认为很愚蠢的问题,在专家详尽的解答中懵懵懂懂地记录自己也看不懂的笔记。不过有人点拨总比自己瞎摸好一些。比如系统开发之初专家就为我们在对象定义上明确了方向。起初我们将物品根据“丢失物”与“拾获物”区分为两个实体,后来根据指导老师的意见将其统一为一个实体,以属性区分,同时略去了失物招领流程中“人”的实体,将用户个人信息附着于物品属性中,于是最终系统只存在一个“物品”对象,在绑定各类模型以及敲定代码中的变量时减少了不少麻烦。不过真正走上开发之路,还是任虽不重道却险阻啊。目前应用的开发成果未达到预期,但我们在解决诸多问题的过程中也积累了不少经验,也在一次次抓狂中磨练了心性,不论系统最终开发成果如何,本次参赛都是非常难得的经历呢。
  • [参赛经验分享] 上海理工大应用开发设计大赛—参赛心得
    通过这次华为云的比赛,我了解到了许多关于APP CUBE 这个平台的使用方法。对于这个全新的平台,我的感受是非常的容易上手。在一次具体的案例实践中,就能够大概了解完成一个项目的全部过程。让我从中收获了许多经验,学到了很多东西。
  • [参赛经验分享] 上海理工大应用开发设计大赛—App Engine
    爽!从来没有进行过,这么so easy的开发.在App Engine,已经实现了,人人都能成为产品经理的愿景.一个App或者网页的开发,一般需要10W,周期一般为1月.而且,从无到有开发能力弱,开发低效,开发资源不足.而且还要管理数据库.这些种种让我对App以及网页开发,望而止步!学习完一门语言,比如说HTML5,CSS,JS需要1个月,在学习几个框架,2个月可以学完,但是学完就能做完整的开发了吗.就是一个大项目,自己完整的做下来.假设项目出来了,要改变功能,或者出了Bug谁去维护,维护需不需要资金呢.一个软件的开发,前端+后端+维护+更新,这一套下来,欲哭无泪了.例如说,一个厂家E2E独立交付,逐个项目做定制典型案例:XX在IOC场景中,逐个项目定制,苦不堪言传统的软件开发是神圣的,对普通人,农民,高中生,创客,是高高在上的.而App Engine把它拉下了神坛.在App Engine中,组件库和AI辅助让前端开发更为高效,流程编排引擎加速了应用的构建.支持云上云下协同快速开发部署,在线测试,在线发布,在线升级.一个账户就可以快速开发,平台+资质可规模复制,效率大规模提升.
  • [参赛经验分享] 上海理工大应用开发设计大赛—参赛工具使用心得
     因为是第一次接触AppEngine这个平台,所以刚开始使用的时候,就比较生疏,看着主赛题攻略去做也会遇到各种各样的问题。遇到问题的时候我先自己研究研究,然后实在不行就发到了群里,询问大佬,然后自己在思考。慢慢地也就熟悉了这个平台,然后自己也在平台的学习模块,深入了解了一下标准页面的功能,利用平台的教学,完成了我的对数据处理视图的创新,让使用者看数据更加直观。        知道最后结果的时候,其实我是真的很开心,并且也学到了App开发的很多东西,也较为深入地了解了华为AppEngine这个平台,并且我也会一直学习这个平台,然后将来去实现我的想法。通过这个竞赛也告诉我,不要觉得自己不行,不敢尝试,而要大胆地尝试,在竞赛中学习,不断完善自己的能力。当然这个竞赛也让我发现了自身代码能力不足的问题,需要我继续努力学习代码。   对于大一的我来说,有了这样一次做App的竞赛体验是很珍贵的,也鼓励我继续深入学习,以后也会多多参加这样的竞赛,在竞赛中不断学习。这次竞赛也让我结识了很多优秀的同学,我们竞赛结束之后也仍然保持的联系,一起讨论一些问题,一起解决问题和学习。    祝愿AppEngine平台越做越好,我也会更深入的了解平台,也希望华为越来越好!
  • [参赛经验分享] 上海理工大应用开发设计大赛—参赛心得
    通过这比赛我不仅仅收获了知识,还结识了许多跟我一样对未来充满梦想的朋友,在未来的开发和学习当中,互相也可以多交流。这次是我第一次真正的接触到平台开发,也切身的体会到了平台开发的开发周期之短,开发效率之高,让我对软件开发模式的未来发展方式有了更加深刻的认知。我也希望能有更多的开发者能体验到平台开发的优势与乐趣。最后,我真心期待AppEngine能在未来的发展与革新中,带给我更多的惊喜。我也将成为AppEngine的忠实粉丝和用户。
  • [参赛经验分享] 上海理工大应用开发设计大赛—coding
    这场比赛给我最大的感触就是认识到学习软件方面的时候自己应该如何做,这里想起了一位老师的话:“不耻下问,勇于上问”。说实在一点,一定要厚脸皮,厚着脸皮的去问,不要害羞。是的,初次接触平台,真的好多不会,和看天书没什么区别,对着开发指导一步一步的抠,但就是那样还是经常卡住,一开始觉得不好意思,觉得都有开发指导了,再去问别人,岂不是太菜了。但是不问吧,自己是真不知道怎么做,一个按键找了接近一个小时,后来忍不住了,去问了一下,没想到很快就有老师和其他选手给我很详细的解答,哪有什么自己那多余的担心,逐渐的,我问的越来越多越来越多以至于自己都感觉有些不好意思。但是大家还是很耐心的为我解答,我也逐渐融进了这种氛围,接下来有人问问题的时候我也积极的为他人进行解答。再到后来通过解答的方式我自己也差不多把赛题又重新理解了一遍,也感觉到主赛题到附加题到选择题这样的设计逻辑是很有心的,像我这样的小白一开始真的需要主赛题那样一步一步的指导,接着到了附加题的时候,没有详细指导,就要联想并体会主赛题的流程,先做什么后做什么,这一步如果出现出错,那么问题出在了哪个部分,脚本还是界面,真的是只有真正理解了,才能达到条件反射似的看到出错就知道错在哪的地步。再到后来的选做题,是留下上升空间给我们自主探索,而选做题只是这空间的一小部分,更大的空间是给我们自己去发现的。先摹,后临,最后自己创造,突然有那么点顿悟的感觉。
  • [参赛经验分享] 上海理工大应用开发设计大赛—一起加油吧
    这是我第一次接触平台开发,感觉自己做的其实还不错,希望有更多人可以参与到AppEngine平台的开发制作中,和我一起体验平台开发的乐趣。感谢华为的AppEngine平台提供了这次比赛的机会,学习了软件开发知识,如对象的呈现,脚本的构建,页面的构建,报表的呈现等相关知识,结交了好多朋友。通过这次比赛,发现自己存在着太多的不足,一次次失败后的尝试也正是慢慢收获知识的过程,在以后的学习中,我也会像这次比赛一样尽心尽力,强化自己的专业知识,认真地对待生活中遇到的问题。特别期待华为云下次举办的比赛还可以让我像现在一样收获满满!
  • [参赛经验分享] 上海理工大应用开发设计大赛—使用AppCube开发时一些小小的心得
    言关于本次比赛,我只参加了初赛,复赛因为团队原因没有参加,有点遗憾。不过不影响我此次的分享。0x00虽然没参加复赛,但是我体验并使用了AppCube开发应用,我在平台提供的指导书的基础上写了一个摊位管理系统,和啤酒配送系统(正在完善)。通过这些项目我初步体验到了AppCube的魅力,它把前端和后端融合在了一起,写项目更加流畅。脚本使用Typescript,也让我顺便学习到了TS的语法,而不仅仅局限于JS。对node的学习让我对后端有了初步的印象,通过AppCube的体验,让我对后端开发有了进一步的认识。不过平台应该省去了许多后端繁琐的部分,我感觉真正的后端开发可能没这么简单。0x01创建项目后,会有五个目录,主要用到就是前三个,Logic,Model,Page。其中Logic存放后端脚本,Model存放数据对象,Page存放前端页面。具体细节可以参考平台教程:应用魔方 AppCube > 用户指南0x02开发后端脚本的时候,一些修饰符,好像并不是ts的内置语法,应该是对编译器的提示信息在脚本中,@符号代表修饰符,如:@action.object({ type: "param" })@useObject(["beerMgtInfo__CST"])我使用过的就这两个,第一个是定义入参出参的时候使用,第二个是连接数据对象的时候使用。0x03前端页面绑定数据这些都很方便,和vue挺像的。最主要的是,不用自己写CSS!不满意的地方也可以自己重写样式,太省事了!0x04其他的没啥说的了,还有一些细节值得注意:给数据对象(数据模型),添加自定义字段时不要打错字,不然调试代码的时候,难以定位错误。数据对象(数据模型)的名字首字母要大写,这只是一种命名习惯。指导书上的代码,也会有一丢丢的错误,不过可以自己修改,无伤大雅。respect!
  • [参赛经验分享] 【分享有奖】上海理工大学首届智慧校园应用开发设计大赛
    欢迎参加上海理工大学首届智慧校园应用开发设计大赛的童鞋,在论坛中发帖进行互动分享,我们将在所有参与发帖的选手中,进行抽奖~并评选出优秀分享内容获得优秀分享奖~>>大赛链接 根据最终分享内容提交情况,评选出的获奖名单情况如下:(领奖请加QQ群 151534240)1、优秀分享奖,3名,每人200元京东卡获奖者:Sq800、地球人、lyy112、在所有参与发帖分享的同学中抽取5名,每人50元京东卡获奖者:lilycai、Sunforge、h0ss、wyz2019、da1357发帖注意:1、      分享内容:1)参赛心得 2)作品展示 3)讲解视频分享 (可任选或全选进行分享)2、      发帖位置:请在华为云大赛技术圈发布论坛分享,>>华为云大赛技术圈,主题分类选择:参赛经验分享3、      发帖命名:上海理工大应用开发设计大赛—你的参赛心得标题4、   回帖抽奖:请将内容分享帖链接+华为云账号回复在本帖下方,抽奖将在回复的帖子中抽取哦~
  • [参赛经验分享] 华为云DevCloud软件编程大赛·啤酒供需数字化管理系统(赛道二) · 参赛心得分享
    大赛链接>>华为云DevCloud啤酒供需数字化管理系统开发赛分享者昵称:hwChenZh 一、初见        我很高兴再次来到华为云DevCloud软件平台,进行一次系统化开发的实践,几个月之前完成了口罩预约管理系统的开发,这次完成了啤酒供需数字化管理系统的开发。对于系统开发非常感兴趣,能够学习到总体框架知识,所以,我看到了这次比赛,决定继续学习App Engine开发平台的开发,掌握更加深刻的知识。        华为云提供的这次大赛给了我一次很好的实战机会,有老师专业的指导和QQ群里面大家的热情帮助,大赛竞争也比较激烈,大家也非常积极。我觉得在这个比赛过程中,平台提供的开发资源和相互学习交流,这些收获是最大的。下面我分享的是赛道二啤酒供需数字化管理系统开发的整个过程和思路。     二、开发        开发周期短,获得的效果好。这得益于App Engine平台的友好界面和丰富的系统教程,这也是平台很大的优点。        1、主赛题                因为有详细的指导手册,我在较短时间内完成了主赛题的完整开发,这部分我进行比较顺利,让我有更多时间测试系统找出不足之处。其中,第一个Bug是在期望到达时间的Date类型,从预约上面没有错误,在出库时候发现变为了Datetime类型,经过一段时间的观察和修改,解决了这个问题。第二个,接关单按钮不起作用,这个排错需要从模型绑定开始,开始我从自定义JS代码入手,但是没有起效果,后来仔细研究了一番,发现是模型绑定错误,服务模型是takeAndclose而不是editMgtInfo。第三个,接关单对于订单状态没有验证,测试系统过程尝试了不同订单状态的接关单,都可以通过,导致了数据错误问题,后来修改了自定义JS代码,传入订单状态的参数进行判断,符合当前操作才能接关单。这是我开发的系统界面,包括手机端和电脑端        2、附加题        这部分完成了DMAX大屏界面的开发,关键步骤在于与主赛题开发的系统各个接口 进行交互,从接口获取订单数据信息,呈现于大屏的各个统计图上面。    三、总结这次在App Engine平台实践开发确实收获许多,啤酒供需数字化管理系统的开发是一个相对完整的系统开发过程。平台提供了很方便的图形化交互,很大的减少了编写代码的繁琐。另外,在啤酒管理系统的开发中,App Engine将项目合理地呈现处理,包括前端页面设计、模型数据的绑定,后端脚本的逻辑处理,以及各接口的调用。这些对于系统开发都是很重要的因素。我对此赛题的见解,在主赛题有详细的教程,题目更侧重于熟悉平台的各项功能,其中也有需要自己根据前面学习之后,运用到系统开发中,比如接关单功能的数据模型,附加题也是学习之后的一种应用,考验开发者细心和app实现的细节,向优秀学习!最后,贴上我的系统开发二维码。
  • [参赛经验分享] 华为网络人工智能黑客松大赛一等奖方案分享
    比赛页面:https://competition.huaweicloud.com/information/1000029328/introduction?track=111作者:slaine本人代号slaine,有幸在此次华为网络人工智能黑客松大赛的硬盘异常检测赛题中收获第一名的成绩,在这里简单跟大家分享下比赛方案。一、赛题背景硬盘生命周期通常为3-5年,在2-3年后故障率明显升高,导致换盘量陡增。在华为数据中心服务器硬件故障中,硬盘故障占比达到48%+。因此通过机器学习构建硬盘故障预测模型,对数据中心典型硬件进行预测,可以提前感知硬件故障,降低运维成本,显著提升业务体验。此次比赛,非常荣幸能够免费接触和体验到的华为先进的NAIE训练平台。我花了大概一到两天的时间,就能够熟练使用该平台开发模型。二、任务理解本次比赛为典型的二分类问题,根据硬盘当天运行数据及之前的历史记录,判断硬盘未来是否会损坏。此前有不少人误解这个标签指的是硬盘当天损坏与否,但实际上所有的标签都是官方根据硬盘最终是否损坏与否来标注的,标注为0的就是硬盘最终没有坏,标注为1的是该盘最终坏掉了。评分标准官方定义如下:在业务上评价硬盘故障预测算法有两个指标:误报率FAR(False Alarm Rate)和检出率FDR(Fault Detect Rate)。业务目标是在误报率FAR<=0.1%的情况下尽量提高FDR。因此本任务的评价指标为:Score = max(FDR) s.t. FAR≤0.1%,其中,FDR = TP/(TP+FN),FAR = FP/(TN+FP).实质上从数据分析的角度来看,就是在保证准确率的情况下,尽量提高召回率。三、数据理解由于时间有限,本次比赛我没有在可视化分析上花太多时间,所以这里就不作详细地数据分析,重点给大家介绍一下数据里的破题点。此次比赛提供的训练集一共有55w+行数据,特征维度为52,标签值为0或者1,0代表好盘,1代表坏盘,每一条记录对应着一个硬盘某一天的状态信息,原始数据如下:1. 数据组织因为赛题目的是为了根据硬盘当天和历史数据来预测硬盘未来发生损坏的概率,那么数据组织就有至少两种方式:一是对每一个硬盘每一天的数据进行建模,模型输出每个硬盘每天的预测概率,最后对每个硬盘每天的预测概率取平均或者取最大值,作为当前硬盘在未来一段时间内损坏概率的最终预测值;二是对硬盘ID进行聚合分组,对每一个特征按硬盘ID分组计算统计特征,由此建模得到的预测概率就是在未来一段时间内该硬盘的损坏概率。我在这里优先选择了第二种数据组织方式,该方式可以有效回避个别数据异常值的影响,也更便于发现数据里的潜在规律。2. 数据筛选官方将测试集每条硬盘的数据记录数统一截取为20条。如果在构造训练集时不针对性地做出调整,很容易训练出过拟合的模型。所以我在构造训练集时首先删除了数据记录小于20条的硬盘,随后对于记录数大于20条的硬盘,按日期从小到大进行排列,并取最后20条记录来做聚合,从而保证和测试集的一致性,具体操作如下:四、特征工程这里重点讲一下特征处理的一些操作。原始特征训练集中原始的52个特征都是对硬盘当前性能的描述,在度娘上可以很容易找到对应特征的解释,比如所有raw特征均代表着从硬盘上采集到的数据的原始值,而normalized特征是对相应raw特征进行归一化操作的结果,另外各个特征数字代表的含义如下:上图中特征9,241,242等都与硬盘启用时间有强相关,一般而言硬盘工作时间越长,出故障的概率越高,这些与工作时间相关的特征应该具有很强的建模价值,所以我的baseline思路就是对所有的原始特征进行简单的均值、最值统计,具体如下:这样的操作在验证的时候(验证数据日期与训练集数据日期在同一个区间时)很有效,能轻松达到0.97+,但是当在测试集(2019年的数据)上提交时,线上得分却只有0.1不到,这意味着2019年的数据与2018年的数据有严重的不同。2. 特征构造此次比赛还有一个难点就是测试集的特征我们拿不到,这样导致我们不能像往常一样逐特征分析对比训练集和特征集的差异,包括kaggle上一些专门针对特征筛选的trick(比如对抗性验证等等)都无法使用,这时只有通过反复实验来求证(充分体现了数据科学中科学的一面)。尝试一:为了解决过拟合问题,首先想到的是剔除在训练集中表现强劲的特征,也就是我在上面讲到的与硬盘工作时间强相关的特征(9,241,242等等),但是删除这些特征后线上成绩依然没有得到明显提升。尝试二:期间我也尝试过解决训练集和测试集的一致性问题,因为测试集是统一在2019年1月头20天的数据,我便考虑构造训练集在2018年头20天或者最后20天的数据,但是训练集2018年头20天的数据标签全为1,最后20天的标签全为0,显然无法构造二分类。尝试三:前面提到过所有raw特征均代表着从硬盘上采集到的数据的原始值,而normalized特征是对相应raw特征进行归一化操作的结果。如果测试集和训练集硬盘是同一个批次且同一个时期开启使用的,那么由于测试集的时间在训练集之后,测试集硬盘的raw特征取值应该普遍大于训练集,所以我删除了所有raw特征,仅使用normalized特征建模。本来信心满满,结果依然GG。尝试四!!本来已经感觉快山穷水尽时,我做了最后一个灵光一闪的关键尝试,考虑到normalized特征是对raw特征的某种归一化操作的结果,那么两者之间应该有潜在关系可以挖掘,我条件反射地将两者拿来做除法,结果bingo!!此题的magic就这样发现了。通过将原始所有数字特征的normalized特征和raw特征分别做除法操作,线上成绩终于突破了0.1,而随后的上分操作就是一马平川。通过去除时间强相关特征,并加入一些有意义的统计特征,线上单模可以轻松突破0.4,具体操作如下:3. 特征筛选通过上述方法构造出来的特征共100多维,为进一步增强泛化能力,我采用了wrapper(封装式)特征筛选法,以lgb模型作为筛选模型,通过递归特征消除的方式最终筛选得到了最优的特征子集,这样可以有效减小特征维度并增强模型泛化能力。具体来说就是原始特征数为N,每次删除K个特征并检验当前N-K个特征下的模型得分,如果当前得分有所提高,则取当前N-K个特征为最优特征子集,继续下一次循环,再删除k个特征,以此类推,可以求得最优特征子集。五、模型模型方面我采用了简单的lgb和xgb的bagging融合,粗暴的bagging融合就是对lgb和xgb预测值之和取平均,而我稍微做了一些调整,通过遍历两个模型权重来选择最优的融合比例,操作如下:另外lgb和xgb均用了3个不同种子的5折融合,相当于最后一共融合了30个模型的预测结果,这样的操作使最终线上得分突破了0.5。本来我还打算尝试stacking融合,加入NN和逻辑回归增强泛化能力,还好各位大佬手下留情,没有逼我放大招哈哈,开玩笑。六、总结华为的服务还是很到位的,前期熟悉平台遇到的问题都能及时解答或者协助解决,甚至远程视频,诚意满满。NAIE平台本身也不错,JupyterLab特征工程有交互式编码体验,SDK调用代码一键生成,也支持在Jupyter里敲自定义代码,同时还有有强大的图表分析能力,WebIDE提供了强大的云端编码和debug能力。方案写得不怎么样,主要是跟大家分享一下心路历程和踩过的坑,因为是一边加班一边偷偷打比赛,所以过程相当艰辛,还有很多地方可以优化都没有尝试。今年据说华为还有不少比赛,如果工作时间允许还会继续支持参加,要是奖金再高一点就更好了哈哈。原文链接:https://zhuanlan.zhihu.com/p/131272835来源:网络人工智能园地
  • [参赛经验分享] 华为网络人工智能黑客松大赛二等奖方案分享
    比赛页面:https://competition.huaweicloud.com/information/1000029328/introduction?track=111作者:原子弹从入门到精通HDC2020网络人工智能黑客松大赛告一段落,来自深圳福田莲花街道的原子弹从入门到精通同学(也就是我)最终果然没能逆袭成功,线上得分0.4488,排名第二,本文将给出我的赛题解析和方案介绍。一、赛题介绍赛题背景:华为数据中心服务器硬件故障中,硬盘故障占比高达48%。因此构建硬盘故障预测模型,提前感知硬件故障,对于降低数据中心的运维成本,提升业务体验均有着重要意义。赛题数据:比赛提供2017,2018年硬盘最后一次检测前一个月的检测数据进行训练,对未来的硬盘检测数据进行线上预测,评估硬盘未来是否会损坏。模型的开发需要在NAIE服务器中完成。其中训练数据集不可以从云端下载到本地,测试数据无法查看,模型建立完成后需将预测代码打包生成推理服务进行线上测试。评价指标:本次比赛的评价指标如下:FDR = TP/(TP+FN)FAR = FP/(TN+FP)SCORE = max(FDR)  s.t. FAR≤0.1%二、指标分析仔细观察评价指标可以发现,评价指标中的FAR,FDR其实就是AUC曲线中的FPR和TPR。那么把指标翻译成人话就是:在误报率≤千分之一的分数阈值下,坏硬盘的召回率。虽然score与AUC息息相关,但是直接使用AUC作为建模阶段的评价指标会存在一些问题。图1的两个模型从AUC的角度来说显然是model2显著优于model1,然而本题的score是在FPR<0.1%下的max(TPR),也就是图中红色框框这个范围,因此虽然model2的AUC大很多,但是model2的score仅有0.21,而model1的score却有0.42。基于以上分析,在建模的过程中需要针对本题建立一个专属的评价指标,我使用的是LightGBM,建立评价函数my_score_,在调用模型的时候将my_score_传给lgb.train的参数f即可。三、目标分析由于本题线上仅需对每块硬盘的最后一条记录进行预测,因此我的分析也会以最后一条记录为主。首先看一下每个月坏硬盘的分布情况。从图3中我们可以很清楚的看到坏硬盘的数目随着时间的推进呈现震荡下降的趋势。原因可能是华为数据中心在不断优化或坏硬盘的损坏类型在发生变化,这我们不得而知。我们能拿到的是2017年和2018年的坏样本,而线上需要预测的是2019年的坏样本。既然坏样本的分布随着时间逐渐变化,在无法对2019年数据进行分析的情形下,基于图3的趋势,我倾向于相信2019年坏样本的分布与2018年下半年最为接近。因此在建模的时候我选择直接舍弃早期坏样本,把目光集中在2018年下半年,尤其是2018年8月后,因为这段时间的曲线最为平稳。四、数据分析与建模由于训练集中仅有每块样本前30天的记录,而样本变为坏样本后便不再有记录,因此,数据中好样本都集中在2018年12月而坏样本大多在2018年11月之前,如果把时间作为入模变量进行建模,就能在训练集完美区分好坏样本——12月没了记录的就是坏样本,但这显然是过拟合。由于没有2018年11月前的好样本数据,因此这个比赛存在超级难点,即如何判断模型是在识别好坏样本而不是在识别时间的远近。更雪上加霜的是硬盘自身的相关属性本身就会随着时间的增长而改变,如smart9累计通电时间(图4),smart241写入总数/写入剩余寿命(图5),等等。训练集中某变量的有效范围[a,b]在测试集中可能已经偏移到[a+c,b+c],而c是多少,我们并不知道。图6是硬盘的写入总数smart_241_raw在好坏样本上的分布,从图6的好坏样本密度图中我们可以看到在训练集中smart_241_raw这个变量有着非常强的区分能力,写入总数越少的样本坏的比率越高,或者说剩余寿命越长的样本坏的比率越高。但是从业务的角度来说显然剩余寿命越长损坏的几率越小,然而由于数据分布的原因,好样本记录的时间节点比坏样本多了那么一两年,导致分析的结果恰恰相反,得出了剩余寿命越长损坏的几率越大这种结论。这其实是一种不公平比较,好坏样本没能也无法在同一时间切片上进行比较,将这种数据直接扔进模型进行训练,就会造成严重的过拟合,很多同学线上分数无法突破0.1主要就是这个原因。为了解决这个问题,我尝试了很多方法:与时间相关的变量除以通电时间进行标准化处理:尝试将时间相关的变量除以通电时间,即将变量标准化为平均每单位时间,这种操作确实能使得分布看起来比较平滑,但这个操作不仅消除了时间的影响,也消除了大量有效信息,未能带来有效的提升。对所有数据进行归一化处理,但每个数据集仅使用该数据集本身的统计指标进行归一化,比如训练集中变量A的最大值是56而测试集中变量A的最大值是321,那么在训练集中将56设置为1,而在测试集中将321设置为1:理论上树模型仅基于数据的rank,无需做数据的标准化处理,但是在当前赛题下,2018年变量的范围是[a,b],而2019年变量的范围却是[a+c,b+c],两个数据集的取值并不是等价关系,而我希望2019年的b+c等同于2018年的b,因此我想到对2018年和2019年的数据分别做标准化处理,考虑到2019年的标准化可能涉及数据穿越的问题,即20190101的标准化是[20190101,20190120]的数据做出来的,对20190101数据进行标准化的过程中使用到了未来的数据,因此我又考虑每日标准化,即20190101的标准化仅使用当天数据,20190102的标准化也仅使用那一天的数据,以此类推,但一通操作后我发现推理服务中的预测是将测试集数据切分成73份的,所以该想法并不能很好的实现,不过做了这个与所想不符的操作也没有掉分,属实比较奇怪。虽然该操作在NAIE上没能实现,但是我觉得这个操作很骚且疑似很强,不知道隔壁阿里赛道有没有同学使用类似的方法;尽量使用滑窗统计,差分等相对平稳的变量:由于推理服务中有10分钟的限制,并且我在推理服务的predict中使用并行总是无响应,为了避免超时,我最终上线的代码仅开了3,7,15天的窗口。此处仅举例均值滑窗统计及差分的代码,其他统计指标如std,skew,kurt等可直接替换修改:使用无监督模型;经测试,在这道题中使用无监督异常检测算法iForest有着良好的效果,无监督单模型线上分数接近0.4,已经到达奖牌区,无监督的入模变量我选择了对2018年四个季度的坏样本都有效的变量,即使用LightGBM分别对四个季度的坏样本进行训练,取四个集合中都有效的变量作为无监督模型的入模变量。做完以上分析与操作后,把建模样本限制在2018年下半年,线上分数0.3,调整模型参数后线上分数0.3x,进入奖牌区;将样本范围限制在2018年8月及以后,同时将坏样本的倒数第二条记录也作为坏样本加入训练集(一边降低坏样本数,一边增大坏样本数),线上分数提升至0.41,持续一周TOP1后被超越,模型融合后线上分数0.43,短暂TOP1,最终TOP2;直接使用无监督的结果,线上分数接近0.4,无监督单模进入奖牌区,逼近奖金区;无监督做规则模型,结合有监督最强单模,线上分数0.4488,最终TOP2;五、总结这次比赛让我思考了很多以前没有考虑过的问题,对我日常的工作学习还是很有帮助的,但过程中仍有很多不足的地方:我平时经常把无监督的输出作为有监督的入模变量使用,在这题一开始我也是这样操作,但是没有显著的效果,直到最后一天晚上黔驴技穷了才开始尝试无监督直接作为输出结果使用,没想到效果这么好,导致我既没做相关调优,也没做阈值调整,感觉无监督这一块还有很大的开发空间;直到最后我也没能很好的处理变量时间泄露和变量真实效果之间的问题,可能TOP1大佬raw变量除normalized变量的骚操作才是关键吧,不过我觉得大佬上分的核心应该是基于这个衍生变量的统计变量,而不是这个变量本身。六、吐槽1. 本题中训练集的date_g是str格式,而线上测试数据是datetime格式,导致同样的代码在predict的时候总是出错,刚上手NAIE的我debug到脑壳疼;七、鸣谢非常感谢小爱姐,希旭哥,诸葛亮等各位老板在参赛过程中给予的帮助与解答,尤其是希旭哥和小爱姐,总是能够及时地答疑解惑。最后祝华为及NAIE越来越好,向下扎到根,向上捅破天!来源:网络人工智能园地链接:https://zhuanlan.zhihu.com/p/131275558
总条数:625 到第
上滑加载中