无人值守时代,运维如何保障发布质量?

摘要: 阿里巴巴千亿交易背后,如何尽量避免发布故障?在面对实际运维过程中遇到的问题该如何解决?阿里巴巴运维技术专家少荃,给我们带来了解决方案和思路。

导读:阿里巴巴千亿交易背后,如何尽量避免发布故障?在面对实际运维过程中遇到的问题该如何解决?近日,在GOPS大会上,阿里巴巴运维技术专家少荃,给我们带来了解决方案和思路。

图片描述

作者:陆叶平(花名少荃),阿里巴巴研发效能事业部技术专家。目前从事运维中台(阿里内部叫诺曼底)建设方面的工作,是集团内最大的应用发布系统(海狼)负责人。

前言

近几年,我们在发布效率和稳定性方面做了不少工作,其中效率简单的说就是发布耗时,一个是发布的速度,比如一个应用是1个小时发布完成,还是5分钟发布完成?另一个是人员介入,开发在发布过程中是否需要介入处理各种发布过程中出现的问题?这两者都做好了,才能说是发布效率提升了。稳定性最基础的是系统的稳定性,保障系统的可用,而最关键的是要保障通过系统来进行发布的应用的稳定性,不会因为发布而导致服务不可用等故障出现。

效率这块我们在集团内比较受好评的产品是SP2P的文件分发系统,叫做蜻蜓,我们根据阿里自身的一些特点,实现了一套安全高效的P2P分发,同时在P2P的协议上引入了超级节点,就是S,提升了P2P网络的启动速度,目前已经开源。稳定性这块我们去年做了一个产品,叫做无人值守发布,对发布进行检测,看看发布是否会引起问题,来提升发布的可靠性,今天就和大家一起交流下这方面的心得。

线上发布之痛

我们为什么要在稳定性方面投入大量精力呢?先让我们来看一个笑话。

变更故障

图片描述

这个笑话可能没那么好笑,但是它真真切切的说明了一个问题:理想和现实的差异,你以为是有四个单身狗陪你,但是实际却是另外两对情侣。这个和我们做生产环境的发布是一样的,我们以为凭借我们出色的逻辑思维能力,已经把所有场景都想到了,测试也做的很充分了,但是,发布上线后,经常会遇到实际结果和预期不一致,故障发生了。我们针对阿里的故障产生原因做了统计,其中很大一部分都是线上变更引起的,相信在座各位也会遇到或者制造过故障,开发和运维的同学对故障都是很敬畏的。

故障大家都遇到过,但是故障的影响差异会比较大。有些故障可能是故障发现后处理了一会就恢复了,有些故障则可能会导致严重的后果。所以我们需要尽量避免变更带来的故障。

业务挑战:阿里的特殊业务场景

回到阿里,我们都知道,去年双11的成交额已经达到了1682亿,想象下,这么大的交易额下,如果出现了故障,那会怎么样?

阿里现在的业务多样化发展,新零售、线下支付等一些新的业务场景,要求我们对故障更加敏感,要能够更好地避免故障,更快地发现和处理故障。想一下,如果是线下场景,比如用支付宝坐地铁,如果出现几分钟的服务不可用,那会怎么样?

如何才能有效的避免故障发生呢?

那么,如何才能在发布的时候有效的避免故障发生呢?

靠“蒙”?大家知道肯定不行。可是细想一下,很多时候确实或多或少在“蒙”。我个人是有过类似感受的。我们虽然不会随便到不经过测试就进行线上发布,但是虽然已经经过了多轮测试,肯定还是没有办法覆盖线上各种复杂多样的场景的,而这些没有办法覆盖的场景,就只能靠运气去”蒙”了,运气好的,这些场景没有问题,运气不好,刚好就其中一个场景出问题,出现故障了。

图片描述

通常来讲,为了尽可能不要去“蒙”,我们会对上线流程加入各种验证环节,来保证发布尽可能可靠。例如发布前,我们会通过各种测试来验证功能是否ok,包括单元测试、集成测试等,发布过程中,我们会通过一些发布策略,例如先预发(预发布是一种特殊的线上环境,和线上使用同样的资源,比如数据库等,但是不会有用户流量进来)、然后灰度、然后分批滚动发布等方式,逐步将变更更新到线上,发布完成后,又会借助一些故障预警系统,例如像阿里有GOC来尽早的发现故障,进行处理,这些环节的这些手段都已经有成熟的系统来进行支持,但是发布的时候,我们常常还是心里没有底。

“人工智能”的解决方案

那么,还有什么办法能够帮助我们尽可能地保障发布质量呢?大家可能都已经在做了:就是”人工”智能的发布保障。

图片描述

在发布过程中,盯着各种屏幕,去看各种数据,来人肉的判断本次发布有没有问题。在阿里,这些屏幕包括:监控、发布单、机器、GOC故障预警等。监控能够反映出来当前系统的一些状况,例如机器的负载是否上去了,接口的成功率是否下降了,发布单则能让我们了解当前的发布情况,有多少机器已经更新到新版本了,有多少还在跑旧版本,有多少机器启动又遇到异常了等等,盯着机器则可以看一些日志信息,是否有一些新的异常出现了,异常的量是否很大等等,GOC让我们在故障发生的第一时间就能知道,结合自己发布的内容判断是否是本次发布引起,需要进行处理。

这种方式相比之前让人放心多了,是因为现在我们看到的是最真实的线上环境的情况,而不是单单的测试数据。但是这种人肉盯屏的方式也存在着很大的问题,首先是成本太高了,发布过程中需要有熟练工盯着各种屏幕去看,片刻不离,其次是人的因素太大了,同样的发布情况,不同的人分析出来的结果可能完全是不一样的,即使是同一个人,因为状态或者其他方面的原因,针对同样的一些数据,可能分析出来的结果也不一样,另外,人也有局限性,各种数据刷新很快,肉眼分析的方式根本都来不及看。

既然这种盯屏的方式被证明是有效的,但是存在一些问题,那么我们就考虑通过系统化来解决这些问题,所以,就有了”无人值守发布”。

无人值守发布

无人值守发布主要是把上述过程自动化、智能化。通过自动化采集这些实时的线上核心数据,进行智能化分析,迅速对发布状况进行判断,是否有故障发生,有的话则立即终止当前发布。

无人值守发布的两大核心能力,一个是故障检测,一个是异常推荐。故障检测主要是发现现在的问题。异常推荐主要是防范于未然,是指发布出现了问题,但是不一定会引起故障,这些异常给开发的同学透明出来,需要开发注意,比较常见的是出现了一些异常,这些异常从绝对数量或者涨幅来看没有非常明显,但可能是需要处理的。

什么是无人值守发布

图片描述

首先是发布单详情页面中的无人值守信息展示,发布单详情页面是发布过程中最常会去看的页面,所以我们选择把无人值守检测出来的一些信息展示到这个页面,在一个页面中把可以做的事情都做掉。当然,并不是说开发同学一定要自己去刷这个页面才能够知道当前发布是否有异常,当发布出现异常的情况下,系统会先自动暂停当前的发布,然后通过钉钉等一些通知方式,告知开发的同学,你的某个发布出现了异常,需要你去看下。

这些展示的信息包括了左侧的当前发布是否有异常的概要信息,通过概要信息,可以知道当前发布有没有问题,如果有问题,可以看右侧的问题分类,是基础监控指标出问题了,还是业务指标出问题了,或者是日志出问题了,日志出问题具体是哪个日志有问题了,在这里都可以看到。

如果这里的信息还不够来判断是否发布有问题,那么点击查看详情,可以看到更加详细明确的异常信息,来进行判断。

无人值守发布的时候需要应用接入到无人值守发布系统,当然大部分情况下这是一个自动化的过程,系统会判断应用是否符合接入标准,如果符合,会自动接入,但是也有一些情况会导致应用无法自动接入,这种情况下,也会告知用户当前应用是否接入了,如果未接入,需要做一些配置或者改造来接入。

无人值守发布详情

图片描述

这个是无人值守发布信息展示的详情页面,在这个上面,可以看到更加明细的一些信息,比如异常数量的发布前后趋势对比,业务监控各个指标的变化情况等。通过这个页面,开发的同学基本上有足够的信息来判断本次拦截是否有效,是否需要进行回滚等操作。

无人值守接入

图片描述

这个是应用接入无人值守发布的一个页面,主要需要配置业务监控指标、日志路径等。

无人值守的实战案例

图片描述

这是一个典型的案例,其中一些数据做了隐藏或者处理。发布过程中日志中某个异常出现了大幅度增长,我们可以从左侧看到异常的数量,点击异常信息还可以看到更加明确的异常堆栈信息,右侧可以看到异常数量出现了明显增加,下面可以看到这个检测被用户判断为确实有问题,最终执行了关闭发布单进行回滚的操作。

用户反馈

图片描述

这些是用户的一些反馈。应用接入无人值守发布,对提升发布的稳定性起了立竿见影的效果。

指标

上面这些案例都代表了一部分用户的感受和反馈,那么整体效果怎么样,还是要拿数据来说话。

图片描述

业界对于异常检测这块有两个主要的指标:一个是召回率,一个是准确率。

召回率主要用来反映漏报的情况,准确率主要用来反馈误报的情况。漏报和误报的概念比较好理解。漏报就是本来有10个故障,系统报了9个,那么漏报了1个,召回率是90%,误报就是只有10个故障,报了20个出来,多出来的10个就属于误报,那么准确率就是50%。

目前准确率方面,我们已经做到了60%左右,也就是说差不多每报2次,就有一次确实是有问题的,这种体验应该算还不错。

召回率方面,我们已经做到了90%,这个90%是指出现了一次故障我们没有报出来,我们有效拦截了9次,这9次中可能会引起故障,也可能只是有问题,但是不会造成故障,但是因为及时发现了,都没有造成故障,很难明确说这9次里面到底有多少是会造成故障的,所以计算召回率的时候没有单独计算故障的召回率,而是把故障和异常一起计算进去了。

关于先重点抓哪个指标,我们也经历过一些波折。一开始的目标是拦截尽可能多的故障,所以比较注重召回率,导致长期一段时间内,准确率很低,拦是拦了不少,但是误报相当多,报10次里面可能只有一次是有效的,如果我们是用户,可能几次误报以后,就对这个产品失去信心了,这个导致我们不敢大面积推广。后来调整策略,优先解决准确率的问题,反正没我们系统之前这些故障也是存在,有了系统,能减少一些就是好的,所以先不追求召回率,把准确率做上去后,可以大面积进行推广了,受益面大了,避免的故障也自然多了。当然,后面还是继续抓了召回率的。

无人值守发布实现

前面说了不少,但是都没有提到系统的具体实现,接下来我们看是怎么去实现无人值守发布的?

首先看下我们的产品分层和业务流程。

产品架构和业务流程

图片描述

我们的系统大致分了三层,最上面一层是发布系统层,我们的产品叫海狼,主要是发布单的提交、执行以及无人值守信息的展示和反馈,这一层是可以扩展的,除了发布系统外,也可以对接其他的一些变更系统。

中间是无人值守的核心系统,根据收集到的分析任务,采集对应的数据,进行分析检测。

最下面一层是离线分析层,主要用来做一些算法的训练、回放验证等,后面再具体介绍。

图片描述

大致的业务过程是,用户在发布系统中提交了一个发布计划,这个时候会通过Normandy(诺曼底)这个平台进行发布(海狼是诺曼底平台的一部分,负责发布的执行),海狼开始执行发布单后,无人值守系统就会收到发布单执行的事件,然后开始分析,分析的时候会利用离线算出来的一些特征集,然后和当前的指标进行比较检测,如果有异常,那么会通过海狼的接口进行暂停发布单的操作,用户可以在发布单页面看到对应信息,然后进行一些判断后提交反馈,是有效拦截,还是误报等。

两个阶段

上述是一个大致的过程,具体实现方面,我们经过了两个大的版本迭代,下面针对两个版本分别介绍下。

1.0实现

图片描述

通过前面的介绍,应该大致了解,无人值守发布就是分析发布过程中各种指标数据,来判断发布是否有异常,那么具体有哪些指标数据可以用来分析呢?大致总结了下,有以下几类:

首先是业务指标,这个最直接反应当前发布有没有问题,如果影响到了业务,那么基本上就是有问题的。如果业务指标能够覆盖所有的故障场景,那么理论上只要分析业务指标就行了,但是现实往往是很多业务指标的完善都跟不上业务发展的,业务上去了,指标还没上,这是很现实的事情。

其次是一些基础指标,例如机器的内存使用情况,cpu使用率,load情况,磁盘io等,这些指标一般在发布过程中不太会发生明显的变化,但是一旦发生了明显变化,就可能有问题了。

还有些中间件的指标,阿里内部广泛使用的hsf、tair、metaq等,都有相应的qps、rt、成功率等指标,如果发布后成功率突然跌的比较明显或者qps跌0等,那么也很有可能是有问题了。

还有一个比较关键的是日志,阿里比较多的应用是java的,我们会在日志中把一些异常的堆栈信息都打印出来,这些异常信息反映了代码运行过程中的一个不正常状态,所以是一个很宝贵的指标数据。通过分析这些异常的出现情况、涨幅情况、或者是否出现了一些常见的容易引起故障的异常,例如ClassNotFound等,我们可以做出足够有用的判断。

指标和算法选取

指标这么多,我们一开始应该从哪入手呢?

第一个版本的时候,我们选择了基础监控和日志这两方面入手。原因比较简单,基础监控的覆盖率够高,有足够多的数据可以让我们分析,而日志根据经验则非常重要。至于业务监控和中间件指标,由于数据方面等一些问题,第一个版本我们没有去考虑。

那怎么对基础监控和日志的指标进行分析呢?我们采用的是使用一些简单的规则加上复杂的算法共用的方式,针对一些情况,例如出现了前面提到的危险异常等,采用规则的方式,直接进行拦截,针对异常的涨幅变化等,则采用算法来评判这个涨幅是否在合理范围内。

如何实现

确定好了指标和分析思路,我们再看看需要做哪些事情。首先要做的是数据采集,我们面临的问题是需要采集哪些数据,怎么尽快地采集这些数据。其次是对数据进行处理,原始的数据中会有一些干扰的数据,干扰的来源可能是多方面的,可能是数据采集系统本身的问题,也可能是与业务自身的特点有关,需要把这些干扰的数据能够剔除掉。然后就是针对采集和处理后的这些数据,制定什么样的规则,使用什么样的算法,来对它们进行分析,尽可能准确的判断出发布后的数据是否有问题。

数据如何采集

首先我们来看看数据怎么采集?

采集之前,先明确检测的大致思路:发布前和发布后的指标进行对比,已发布和未发布的机器进行对比。所以,我们要采集的是时间序列的数据,也就是每个时间点某个指标是什么样的一个数据,例如某个时间点,系统的load是多少,某个时间点,某类异常出现了多少次等。

具体要采集哪些指标,上面已经明确了,只要把这些指标再做一个分析,把最重要最能反映故障情况的一些指标挑选出来,采集过来就行。

而从哪些机器上采集指标呢?前面提到,我们检测思路中有一条是已发布和未发布的机器进行对比,所以我们为每个应用设置了两组机器,一个是发布组,一个是参照组,只采集这两组机器的数据,而不是所有机器的数据都采集。至于采集时间,也不用采集所有数据,只要采集发布前后一段时间内的数据就可以。

采集到数据以后,接下来就需要对数据进行一些处理,除了前面提到的一些干扰数据剔除外,我们还需要进行一些维度的聚合,因为拿到的是一些单机数据,所以需要针对已发布未发布等一些维度进行数据聚合合并,最终生成了可以分析的数据。

数据分析方法

数据分析的方法,我们采用的是改进型的funnel检测模型,它有这些优点:可以满足针对不同的指标,采用不同的算法的需求,不同的指标有各自的特点,使用同一个算法显然不大合适;其次它的计算需要的资源少,同时检测的速度又够快,还支持很多指标一起分析。

图片描述

通过上述这些工作,我们大致就把一个检测系统建立run起来了,这第一个版本在准确率方面表现不是很好,离线跑的时候能够有30%、40%,但是线上实际跑的时候只有10%上下的准确率,所以我们需要去提升准确率,那怎么提升呢?

答案是不断的分析误报和漏报数据,然后对算法做一些微调。不停的微调算法又带来了一个新的问题,针对这些误报的数据,可能新的算法不会报出来了,但是之前的那些没报的数据呢,用新的算法会不会又报出来了?之前那些报出来的有效拦截,会不会新的算法中就不报出来了?

于是我们又搭建了之前产品架构中提到的离线回放系统,用来对算法进行回放验证,从之前的误报、有效拦截、未拦截等数据中抽取部分数据,每次算法调整后,通过回放系统对这些数据重新进行检测分析,看看准确率和召回率是怎么变化的,误报的是否还在误报,有效拦截的是否漏报了等等。

无人值守回放系统

图片描述

整个无人值守回放系统大致过程如下:录制模块会将线上检测过的发布单的相关数据录制到回放db,然后需要回放的时候,通过回放触发接口,触发无人值守进行检测,检测时候会调用回放系统提供的指标mock接口,从回放db获取数据,而不是从实际的数据源获取数据,将回放检测的结果进行保存,产出回放结果报表。

算法的困境

通过无人值守回放系统,我们建立了可靠的算法验证机制,通过不断的微调算法来提升召回率和准确率。但是,还是遇到了一些问题。

首先是需要不断的去分析检测数据,然后调整算法,这个过程是相当耗费精力的,并且不一定能够有相应的回报。还有很重要的一点是,在实践过程中,我们发现一些明显的误报信息在重复的误报。

所以我们需要去探索一个能够解决这些问题的方案。于是,第二个版本,我们就采用了基于机器学习的方式在原来的基础上做了一些改进。

机器学习的大概过程

图片描述

首先会有一个离线学习的过程,通过一些历史的发布单的指标数据和拦截数据,以及用户反馈的一些数据,计算出来应用发布时候的一个特征库,发布的时候,会首先采用一些算法来检测出可疑指标,然后对可疑指标和特征库进行比较,如果发现这个可疑指标落在正常的特征库里,那么忽略掉,否则,就认为发布出现了异常进行拦截,拦截完成后,会根据发布单最终的结果和用户的反馈行为将这次拦截是否有效等数据保存起来,作为下次离线计算的一个输入数据。

三大要素

机器学习也面临几个问题需要去解决,首先是去学习什么样的数据,其次是要通过什么样的方法去学习产出什么样的结果,还有一个就是怎么样把这个学习的结果用到后面的发布检测中去。

样本

我们首先看下样本问题,就是学什么数据。我们有的数据大致有这些:发布单数据、发布过程中的指标数据、拦截是否有效的数据、用户反馈的一些数据。

这些数据看起来很多,每天的发布单有好几万,每个发布单又有大量的指标数据,但是实际上,每个应用的特征都是不一样的,所以学习的时候一定是基于应用的维度去学习的,而每个应用的发布数据就很少了,如何从这不多的数据去计算应用的发布特征呢?

计算的思路也有两个,一个是算异常的,比较自然的想法,找出异常的特征,下次如果匹配了异常特征,那么就可以判断发布有问题,一个是算正常的,而应用维度异常的发布往往远少于正常发布,甚至可能都从来没有过异常发布,所以基于异常的维度去计算,也不大靠谱,相对比较靠谱点的,只能是通过正常的发布单数据去计算出应用发布的正常发布特征。

样本中的一个挑战是如何来判断一个发布真正是有问题的,我们采取的是发布单行为和用户反馈相结合的方式,如果发布单被回滚了,那么就认为是异常的,如果用户反馈说有异常,那么也认为是异常的。

关键和不靠谱是用来描述用户反馈数据的两个特点的,关键是指用户反馈数据非常重要,是最能够帮助我们去了解应用的各个指标对异常检测是否有帮助的,但是用户反馈数据又具有主观性,发布过程中出现了某个异常,A开发同学可能会反馈认为没有问题,而B同学比较谨慎可能就会反馈认为确实是有问题,如何去平衡这两个特点也是比较棘手的。

图片描述

这个就是刚才提到的用户反馈数据,通过这个反馈数据,我们可以明确的知道某个指标虽然异常了,但是对这个应用来说,可能是完全没有用的,根本不需要作为检测的依据,那么下次检测的时候就可以忽略掉该指标。

这个反馈数据的采集看似很容易,但是据我所知,在不少公司里,采集这个数据阻力都是比较大的,开发同学不愿意去填写反馈这些信息,比较幸运的是,我们通过一系列方式优化,尽可能地减少这个反馈对开发的干扰,把这个反馈给强制开启来了,采集到的数据对我们的帮助确实相当大。

算法

样本数据有了,接下来就要根据样本数据计算出应用的发布特征了,我们采用的是简单的分类的方法,最初的想法是分成正常、异常、未分类三大类,正常比较好理解,异常是指每次出现都会导致故障的,未分类则是一些新增的或者之前出现过没有变化的一些指标,后面考虑到上面说的异常样本非常小的问题,就把这三类统一成一类了,就是只计算应用发布时候各个指标的一个正常阈值,如果下次发布的时候,指标的值超过了这个阈值,那么可能就是有问题。

具体学习的过程比较简单,总结起来一句话就是:找到正常发布单中指标的最大值,作为应用的正常指标阈值。具体过程是:首先是发布过程中如果出现了异常指标,那么会去看这次发布最终是否是有问题的发布(通过发布单的行为是否回滚以及用户的反馈等),如果是正常发布,那么和之前的正常阈值进行比较,如果比之前的正常阈值要小,那么忽略,如果比之前的阈值大,那么就更新正常阈值,而如果这次发布是异常发布,那么理论上应该去判断这次的指标是否比正常阈值小,如果小,那么要更新正常阈值,但是实际上,这次发布的问题可能并不一定是这个指标引起的,而且如果确实是这个指标引起的话,那么之前指标比这个值更大的发布应该也是异常的,考虑到这两点,我们现阶段采取的是忽略异常发布单的方式,只针对正常的发布单进行阈值计算。

指标使用

正常阈值的使用也比较简单。发布过程中,如果发现了异常指标,那么会找到该指标对应的正常阈值做比较,如果小于正常阈值,那么忽略掉,如果超过了正常阈值,那么作为可疑指标,在一个窗口期内进行多轮检测,窗口期会根据检测的结果做一些动态调整,如果在窗口期内多次被判定为可疑指标,并且达到了一定比例,那么最终会被判定为异常指标,对发布进行拦截。

整个机器学习的改进过程大致就是这样,通过这个改进,我们一方面解决了之前遇到的一些问题,提升了召回率和准确率,尤其是准确率方面有了显著提升。另外一方面,也释放了大量精力出来,可以更好的优化这个学习的算法。

原文链接

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258950

无人值守时代,运维如何保障发布质量?

摘要: 阿里巴巴千亿交易背后,如何尽量避免发布故障?在面对实际运维过程中遇到的问题该如何解决?阿里巴巴运维技术专家少荃,给我们带来了解决方案和思路。

导读:阿里巴巴千亿交易背后,如何尽量避免发布故障?在面对实际运维过程中遇到的问题该如何解决?近日,在GOPS大会上,阿里巴巴运维技术专家少荃,给我们带来了解决方案和思路。

图片描述

作者:陆叶平(花名少荃),阿里巴巴研发效能事业部技术专家。目前从事运维中台(阿里内部叫诺曼底)建设方面的工作,是集团内最大的应用发布系统(海狼)负责人。

前言

近几年,我们在发布效率和稳定性方面做了不少工作,其中效率简单的说就是发布耗时,一个是发布的速度,比如一个应用是1个小时发布完成,还是5分钟发布完成?另一个是人员介入,开发在发布过程中是否需要介入处理各种发布过程中出现的问题?这两者都做好了,才能说是发布效率提升了。稳定性最基础的是系统的稳定性,保障系统的可用,而最关键的是要保障通过系统来进行发布的应用的稳定性,不会因为发布而导致服务不可用等故障出现。

效率这块我们在集团内比较受好评的产品是SP2P的文件分发系统,叫做蜻蜓,我们根据阿里自身的一些特点,实现了一套安全高效的P2P分发,同时在P2P的协议上引入了超级节点,就是S,提升了P2P网络的启动速度,目前已经开源。稳定性这块我们去年做了一个产品,叫做无人值守发布,对发布进行检测,看看发布是否会引起问题,来提升发布的可靠性,今天就和大家一起交流下这方面的心得。

线上发布之痛

我们为什么要在稳定性方面投入大量精力呢?先让我们来看一个笑话。

变更故障

图片描述

这个笑话可能没那么好笑,但是它真真切切的说明了一个问题:理想和现实的差异,你以为是有四个单身狗陪你,但是实际却是另外两对情侣。这个和我们做生产环境的发布是一样的,我们以为凭借我们出色的逻辑思维能力,已经把所有场景都想到了,测试也做的很充分了,但是,发布上线后,经常会遇到实际结果和预期不一致,故障发生了。我们针对阿里的故障产生原因做了统计,其中很大一部分都是线上变更引起的,相信在座各位也会遇到或者制造过故障,开发和运维的同学对故障都是很敬畏的。

故障大家都遇到过,但是故障的影响差异会比较大。有些故障可能是故障发现后处理了一会就恢复了,有些故障则可能会导致严重的后果。所以我们需要尽量避免变更带来的故障。

业务挑战:阿里的特殊业务场景

回到阿里,我们都知道,去年双11的成交额已经达到了1682亿,想象下,这么大的交易额下,如果出现了故障,那会怎么样?

阿里现在的业务多样化发展,新零售、线下支付等一些新的业务场景,要求我们对故障更加敏感,要能够更好地避免故障,更快地发现和处理故障。想一下,如果是线下场景,比如用支付宝坐地铁,如果出现几分钟的服务不可用,那会怎么样?

如何才能有效的避免故障发生呢?

那么,如何才能在发布的时候有效的避免故障发生呢?

靠“蒙”?大家知道肯定不行。可是细想一下,很多时候确实或多或少在“蒙”。我个人是有过类似感受的。我们虽然不会随便到不经过测试就进行线上发布,但是虽然已经经过了多轮测试,肯定还是没有办法覆盖线上各种复杂多样的场景的,而这些没有办法覆盖的场景,就只能靠运气去”蒙”了,运气好的,这些场景没有问题,运气不好,刚好就其中一个场景出问题,出现故障了。

图片描述

通常来讲,为了尽可能不要去“蒙”,我们会对上线流程加入各种验证环节,来保证发布尽可能可靠。例如发布前,我们会通过各种测试来验证功能是否ok,包括单元测试、集成测试等,发布过程中,我们会通过一些发布策略,例如先预发(预发布是一种特殊的线上环境,和线上使用同样的资源,比如数据库等,但是不会有用户流量进来)、然后灰度、然后分批滚动发布等方式,逐步将变更更新到线上,发布完成后,又会借助一些故障预警系统,例如像阿里有GOC来尽早的发现故障,进行处理,这些环节的这些手段都已经有成熟的系统来进行支持,但是发布的时候,我们常常还是心里没有底。

“人工智能”的解决方案

那么,还有什么办法能够帮助我们尽可能地保障发布质量呢?大家可能都已经在做了:就是”人工”智能的发布保障。

图片描述

在发布过程中,盯着各种屏幕,去看各种数据,来人肉的判断本次发布有没有问题。在阿里,这些屏幕包括:监控、发布单、机器、GOC故障预警等。监控能够反映出来当前系统的一些状况,例如机器的负载是否上去了,接口的成功率是否下降了,发布单则能让我们了解当前的发布情况,有多少机器已经更新到新版本了,有多少还在跑旧版本,有多少机器启动又遇到异常了等等,盯着机器则可以看一些日志信息,是否有一些新的异常出现了,异常的量是否很大等等,GOC让我们在故障发生的第一时间就能知道,结合自己发布的内容判断是否是本次发布引起,需要进行处理。

这种方式相比之前让人放心多了,是因为现在我们看到的是最真实的线上环境的情况,而不是单单的测试数据。但是这种人肉盯屏的方式也存在着很大的问题,首先是成本太高了,发布过程中需要有熟练工盯着各种屏幕去看,片刻不离,其次是人的因素太大了,同样的发布情况,不同的人分析出来的结果可能完全是不一样的,即使是同一个人,因为状态或者其他方面的原因,针对同样的一些数据,可能分析出来的结果也不一样,另外,人也有局限性,各种数据刷新很快,肉眼分析的方式根本都来不及看。

既然这种盯屏的方式被证明是有效的,但是存在一些问题,那么我们就考虑通过系统化来解决这些问题,所以,就有了”无人值守发布”。

无人值守发布

无人值守发布主要是把上述过程自动化、智能化。通过自动化采集这些实时的线上核心数据,进行智能化分析,迅速对发布状况进行判断,是否有故障发生,有的话则立即终止当前发布。

无人值守发布的两大核心能力,一个是故障检测,一个是异常推荐。故障检测主要是发现现在的问题。异常推荐主要是防范于未然,是指发布出现了问题,但是不一定会引起故障,这些异常给开发的同学透明出来,需要开发注意,比较常见的是出现了一些异常,这些异常从绝对数量或者涨幅来看没有非常明显,但可能是需要处理的。

什么是无人值守发布

图片描述

首先是发布单详情页面中的无人值守信息展示,发布单详情页面是发布过程中最常会去看的页面,所以我们选择把无人值守检测出来的一些信息展示到这个页面,在一个页面中把可以做的事情都做掉。当然,并不是说开发同学一定要自己去刷这个页面才能够知道当前发布是否有异常,当发布出现异常的情况下,系统会先自动暂停当前的发布,然后通过钉钉等一些通知方式,告知开发的同学,你的某个发布出现了异常,需要你去看下。

这些展示的信息包括了左侧的当前发布是否有异常的概要信息,通过概要信息,可以知道当前发布有没有问题,如果有问题,可以看右侧的问题分类,是基础监控指标出问题了,还是业务指标出问题了,或者是日志出问题了,日志出问题具体是哪个日志有问题了,在这里都可以看到。

如果这里的信息还不够来判断是否发布有问题,那么点击查看详情,可以看到更加详细明确的异常信息,来进行判断。

无人值守发布的时候需要应用接入到无人值守发布系统,当然大部分情况下这是一个自动化的过程,系统会判断应用是否符合接入标准,如果符合,会自动接入,但是也有一些情况会导致应用无法自动接入,这种情况下,也会告知用户当前应用是否接入了,如果未接入,需要做一些配置或者改造来接入。

无人值守发布详情

图片描述

这个是无人值守发布信息展示的详情页面,在这个上面,可以看到更加明细的一些信息,比如异常数量的发布前后趋势对比,业务监控各个指标的变化情况等。通过这个页面,开发的同学基本上有足够的信息来判断本次拦截是否有效,是否需要进行回滚等操作。

无人值守接入

图片描述

这个是应用接入无人值守发布的一个页面,主要需要配置业务监控指标、日志路径等。

无人值守的实战案例

图片描述

这是一个典型的案例,其中一些数据做了隐藏或者处理。发布过程中日志中某个异常出现了大幅度增长,我们可以从左侧看到异常的数量,点击异常信息还可以看到更加明确的异常堆栈信息,右侧可以看到异常数量出现了明显增加,下面可以看到这个检测被用户判断为确实有问题,最终执行了关闭发布单进行回滚的操作。

用户反馈

图片描述

这些是用户的一些反馈。应用接入无人值守发布,对提升发布的稳定性起了立竿见影的效果。

指标

上面这些案例都代表了一部分用户的感受和反馈,那么整体效果怎么样,还是要拿数据来说话。

图片描述

业界对于异常检测这块有两个主要的指标:一个是召回率,一个是准确率。

召回率主要用来反映漏报的情况,准确率主要用来反馈误报的情况。漏报和误报的概念比较好理解。漏报就是本来有10个故障,系统报了9个,那么漏报了1个,召回率是90%,误报就是只有10个故障,报了20个出来,多出来的10个就属于误报,那么准确率就是50%。

目前准确率方面,我们已经做到了60%左右,也就是说差不多每报2次,就有一次确实是有问题的,这种体验应该算还不错。

召回率方面,我们已经做到了90%,这个90%是指出现了一次故障我们没有报出来,我们有效拦截了9次,这9次中可能会引起故障,也可能只是有问题,但是不会造成故障,但是因为及时发现了,都没有造成故障,很难明确说这9次里面到底有多少是会造成故障的,所以计算召回率的时候没有单独计算故障的召回率,而是把故障和异常一起计算进去了。

关于先重点抓哪个指标,我们也经历过一些波折。一开始的目标是拦截尽可能多的故障,所以比较注重召回率,导致长期一段时间内,准确率很低,拦是拦了不少,但是误报相当多,报10次里面可能只有一次是有效的,如果我们是用户,可能几次误报以后,就对这个产品失去信心了,这个导致我们不敢大面积推广。后来调整策略,优先解决准确率的问题,反正没我们系统之前这些故障也是存在,有了系统,能减少一些就是好的,所以先不追求召回率,把准确率做上去后,可以大面积进行推广了,受益面大了,避免的故障也自然多了。当然,后面还是继续抓了召回率的。

无人值守发布实现

前面说了不少,但是都没有提到系统的具体实现,接下来我们看是怎么去实现无人值守发布的?

首先看下我们的产品分层和业务流程。

产品架构和业务流程

图片描述

我们的系统大致分了三层,最上面一层是发布系统层,我们的产品叫海狼,主要是发布单的提交、执行以及无人值守信息的展示和反馈,这一层是可以扩展的,除了发布系统外,也可以对接其他的一些变更系统。

中间是无人值守的核心系统,根据收集到的分析任务,采集对应的数据,进行分析检测。

最下面一层是离线分析层,主要用来做一些算法的训练、回放验证等,后面再具体介绍。

图片描述

大致的业务过程是,用户在发布系统中提交了一个发布计划,这个时候会通过Normandy(诺曼底)这个平台进行发布(海狼是诺曼底平台的一部分,负责发布的执行),海狼开始执行发布单后,无人值守系统就会收到发布单执行的事件,然后开始分析,分析的时候会利用离线算出来的一些特征集,然后和当前的指标进行比较检测,如果有异常,那么会通过海狼的接口进行暂停发布单的操作,用户可以在发布单页面看到对应信息,然后进行一些判断后提交反馈,是有效拦截,还是误报等。

两个阶段

上述是一个大致的过程,具体实现方面,我们经过了两个大的版本迭代,下面针对两个版本分别介绍下。

1.0实现

图片描述

通过前面的介绍,应该大致了解,无人值守发布就是分析发布过程中各种指标数据,来判断发布是否有异常,那么具体有哪些指标数据可以用来分析呢?大致总结了下,有以下几类:

首先是业务指标,这个最直接反应当前发布有没有问题,如果影响到了业务,那么基本上就是有问题的。如果业务指标能够覆盖所有的故障场景,那么理论上只要分析业务指标就行了,但是现实往往是很多业务指标的完善都跟不上业务发展的,业务上去了,指标还没上,这是很现实的事情。

其次是一些基础指标,例如机器的内存使用情况,cpu使用率,load情况,磁盘io等,这些指标一般在发布过程中不太会发生明显的变化,但是一旦发生了明显变化,就可能有问题了。

还有些中间件的指标,阿里内部广泛使用的hsf、tair、metaq等,都有相应的qps、rt、成功率等指标,如果发布后成功率突然跌的比较明显或者qps跌0等,那么也很有可能是有问题了。

还有一个比较关键的是日志,阿里比较多的应用是java的,我们会在日志中把一些异常的堆栈信息都打印出来,这些异常信息反映了代码运行过程中的一个不正常状态,所以是一个很宝贵的指标数据。通过分析这些异常的出现情况、涨幅情况、或者是否出现了一些常见的容易引起故障的异常,例如ClassNotFound等,我们可以做出足够有用的判断。

指标和算法选取

指标这么多,我们一开始应该从哪入手呢?

第一个版本的时候,我们选择了基础监控和日志这两方面入手。原因比较简单,基础监控的覆盖率够高,有足够多的数据可以让我们分析,而日志根据经验则非常重要。至于业务监控和中间件指标,由于数据方面等一些问题,第一个版本我们没有去考虑。

那怎么对基础监控和日志的指标进行分析呢?我们采用的是使用一些简单的规则加上复杂的算法共用的方式,针对一些情况,例如出现了前面提到的危险异常等,采用规则的方式,直接进行拦截,针对异常的涨幅变化等,则采用算法来评判这个涨幅是否在合理范围内。

如何实现

确定好了指标和分析思路,我们再看看需要做哪些事情。首先要做的是数据采集,我们面临的问题是需要采集哪些数据,怎么尽快地采集这些数据。其次是对数据进行处理,原始的数据中会有一些干扰的数据,干扰的来源可能是多方面的,可能是数据采集系统本身的问题,也可能是与业务自身的特点有关,需要把这些干扰的数据能够剔除掉。然后就是针对采集和处理后的这些数据,制定什么样的规则,使用什么样的算法,来对它们进行分析,尽可能准确的判断出发布后的数据是否有问题。

数据如何采集

首先我们来看看数据怎么采集?

采集之前,先明确检测的大致思路:发布前和发布后的指标进行对比,已发布和未发布的机器进行对比。所以,我们要采集的是时间序列的数据,也就是每个时间点某个指标是什么样的一个数据,例如某个时间点,系统的load是多少,某个时间点,某类异常出现了多少次等。

具体要采集哪些指标,上面已经明确了,只要把这些指标再做一个分析,把最重要最能反映故障情况的一些指标挑选出来,采集过来就行。

而从哪些机器上采集指标呢?前面提到,我们检测思路中有一条是已发布和未发布的机器进行对比,所以我们为每个应用设置了两组机器,一个是发布组,一个是参照组,只采集这两组机器的数据,而不是所有机器的数据都采集。至于采集时间,也不用采集所有数据,只要采集发布前后一段时间内的数据就可以。

采集到数据以后,接下来就需要对数据进行一些处理,除了前面提到的一些干扰数据剔除外,我们还需要进行一些维度的聚合,因为拿到的是一些单机数据,所以需要针对已发布未发布等一些维度进行数据聚合合并,最终生成了可以分析的数据。

数据分析方法

数据分析的方法,我们采用的是改进型的funnel检测模型,它有这些优点:可以满足针对不同的指标,采用不同的算法的需求,不同的指标有各自的特点,使用同一个算法显然不大合适;其次它的计算需要的资源少,同时检测的速度又够快,还支持很多指标一起分析。

图片描述

通过上述这些工作,我们大致就把一个检测系统建立run起来了,这第一个版本在准确率方面表现不是很好,离线跑的时候能够有30%、40%,但是线上实际跑的时候只有10%上下的准确率,所以我们需要去提升准确率,那怎么提升呢?

答案是不断的分析误报和漏报数据,然后对算法做一些微调。不停的微调算法又带来了一个新的问题,针对这些误报的数据,可能新的算法不会报出来了,但是之前的那些没报的数据呢,用新的算法会不会又报出来了?之前那些报出来的有效拦截,会不会新的算法中就不报出来了?

于是我们又搭建了之前产品架构中提到的离线回放系统,用来对算法进行回放验证,从之前的误报、有效拦截、未拦截等数据中抽取部分数据,每次算法调整后,通过回放系统对这些数据重新进行检测分析,看看准确率和召回率是怎么变化的,误报的是否还在误报,有效拦截的是否漏报了等等。

无人值守回放系统

图片描述

整个无人值守回放系统大致过程如下:录制模块会将线上检测过的发布单的相关数据录制到回放db,然后需要回放的时候,通过回放触发接口,触发无人值守进行检测,检测时候会调用回放系统提供的指标mock接口,从回放db获取数据,而不是从实际的数据源获取数据,将回放检测的结果进行保存,产出回放结果报表。

算法的困境

通过无人值守回放系统,我们建立了可靠的算法验证机制,通过不断的微调算法来提升召回率和准确率。但是,还是遇到了一些问题。

首先是需要不断的去分析检测数据,然后调整算法,这个过程是相当耗费精力的,并且不一定能够有相应的回报。还有很重要的一点是,在实践过程中,我们发现一些明显的误报信息在重复的误报。

所以我们需要去探索一个能够解决这些问题的方案。于是,第二个版本,我们就采用了基于机器学习的方式在原来的基础上做了一些改进。

机器学习的大概过程

图片描述

首先会有一个离线学习的过程,通过一些历史的发布单的指标数据和拦截数据,以及用户反馈的一些数据,计算出来应用发布时候的一个特征库,发布的时候,会首先采用一些算法来检测出可疑指标,然后对可疑指标和特征库进行比较,如果发现这个可疑指标落在正常的特征库里,那么忽略掉,否则,就认为发布出现了异常进行拦截,拦截完成后,会根据发布单最终的结果和用户的反馈行为将这次拦截是否有效等数据保存起来,作为下次离线计算的一个输入数据。

三大要素

机器学习也面临几个问题需要去解决,首先是去学习什么样的数据,其次是要通过什么样的方法去学习产出什么样的结果,还有一个就是怎么样把这个学习的结果用到后面的发布检测中去。

样本

我们首先看下样本问题,就是学什么数据。我们有的数据大致有这些:发布单数据、发布过程中的指标数据、拦截是否有效的数据、用户反馈的一些数据。

这些数据看起来很多,每天的发布单有好几万,每个发布单又有大量的指标数据,但是实际上,每个应用的特征都是不一样的,所以学习的时候一定是基于应用的维度去学习的,而每个应用的发布数据就很少了,如何从这不多的数据去计算应用的发布特征呢?

计算的思路也有两个,一个是算异常的,比较自然的想法,找出异常的特征,下次如果匹配了异常特征,那么就可以判断发布有问题,一个是算正常的,而应用维度异常的发布往往远少于正常发布,甚至可能都从来没有过异常发布,所以基于异常的维度去计算,也不大靠谱,相对比较靠谱点的,只能是通过正常的发布单数据去计算出应用发布的正常发布特征。

样本中的一个挑战是如何来判断一个发布真正是有问题的,我们采取的是发布单行为和用户反馈相结合的方式,如果发布单被回滚了,那么就认为是异常的,如果用户反馈说有异常,那么也认为是异常的。

关键和不靠谱是用来描述用户反馈数据的两个特点的,关键是指用户反馈数据非常重要,是最能够帮助我们去了解应用的各个指标对异常检测是否有帮助的,但是用户反馈数据又具有主观性,发布过程中出现了某个异常,A开发同学可能会反馈认为没有问题,而B同学比较谨慎可能就会反馈认为确实是有问题,如何去平衡这两个特点也是比较棘手的。

图片描述

这个就是刚才提到的用户反馈数据,通过这个反馈数据,我们可以明确的知道某个指标虽然异常了,但是对这个应用来说,可能是完全没有用的,根本不需要作为检测的依据,那么下次检测的时候就可以忽略掉该指标。

这个反馈数据的采集看似很容易,但是据我所知,在不少公司里,采集这个数据阻力都是比较大的,开发同学不愿意去填写反馈这些信息,比较幸运的是,我们通过一系列方式优化,尽可能地减少这个反馈对开发的干扰,把这个反馈给强制开启来了,采集到的数据对我们的帮助确实相当大。

算法

样本数据有了,接下来就要根据样本数据计算出应用的发布特征了,我们采用的是简单的分类的方法,最初的想法是分成正常、异常、未分类三大类,正常比较好理解,异常是指每次出现都会导致故障的,未分类则是一些新增的或者之前出现过没有变化的一些指标,后面考虑到上面说的异常样本非常小的问题,就把这三类统一成一类了,就是只计算应用发布时候各个指标的一个正常阈值,如果下次发布的时候,指标的值超过了这个阈值,那么可能就是有问题。

具体学习的过程比较简单,总结起来一句话就是:找到正常发布单中指标的最大值,作为应用的正常指标阈值。具体过程是:首先是发布过程中如果出现了异常指标,那么会去看这次发布最终是否是有问题的发布(通过发布单的行为是否回滚以及用户的反馈等),如果是正常发布,那么和之前的正常阈值进行比较,如果比之前的正常阈值要小,那么忽略,如果比之前的阈值大,那么就更新正常阈值,而如果这次发布是异常发布,那么理论上应该去判断这次的指标是否比正常阈值小,如果小,那么要更新正常阈值,但是实际上,这次发布的问题可能并不一定是这个指标引起的,而且如果确实是这个指标引起的话,那么之前指标比这个值更大的发布应该也是异常的,考虑到这两点,我们现阶段采取的是忽略异常发布单的方式,只针对正常的发布单进行阈值计算。

指标使用

正常阈值的使用也比较简单。发布过程中,如果发现了异常指标,那么会找到该指标对应的正常阈值做比较,如果小于正常阈值,那么忽略掉,如果超过了正常阈值,那么作为可疑指标,在一个窗口期内进行多轮检测,窗口期会根据检测的结果做一些动态调整,如果在窗口期内多次被判定为可疑指标,并且达到了一定比例,那么最终会被判定为异常指标,对发布进行拦截。

整个机器学习的改进过程大致就是这样,通过这个改进,我们一方面解决了之前遇到的一些问题,提升了召回率和准确率,尤其是准确率方面有了显著提升。另外一方面,也释放了大量精力出来,可以更好的优化这个学习的算法。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258949

阿里云Redis混合存储典型场景:如何轻松搭建视频直播间系统

摘要: 本文主要介绍视频直播间系统,以及如何使用阿里云Redis混合存储实例方便快捷的构建大数据量,低延迟的视频直播间服务。

背景

视频直播间作为直播系统对外的表现形式,在整个系统中处于核心地位。通常除了视频直播窗口外,直播间还包含在线用户,礼物,评论,点赞,排行榜等信息。直播间消息,时效性高,互动性强,对系统时延有着非常高的要求,非常适合使用Redis等缓存服务来处理。

直播信息

实时排行信息

实时排行信息包含直播间在线用户列表,各种礼物排行榜,弹幕消息(可以理解为按消息维度的消息排行榜)等信息,适合使用Redis中的SortedSet结构进行存储。

例如,以unix timestamp+毫秒数为分值,记录user55的直播间增加的5条弹幕

redis> ZADD user55:_danmu 1523959031601166 message111111111111
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959031601266 message222222222222
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959088894232 message33333
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959090390160 message444444
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959092951218 message5555
(integer) 1

返回最新的3条弹幕信息:

redis> ZREVRANGEBYSCORE user55:_danmu +inf -inf LIMIT 0 3
1) "message5555"
2) "message444444"
3) "message33333"

返回指定时间段内的3条弹幕信息:

redis> ZREVRANGEBYSCORE user55:_danmu 1523959088894232 -inf LIMIT 0 3
1) "message33333"
2) "message222222222222"
3) "message111111111111"

计数类信息

计数类信息以用户维度为例,有未读消息数,关注数,粉丝数,经验值等等。这类消息适合以Redis中的Hash结构进行存储。

redis> HSET user:55 follower 5
(integer) 1
redis> HINCRBY user:55 follower 1 //关注数+1
(integer) 6 
redis> HGETALL user:55
1) "follow"
2) "6"

时间线信息

时间线信息是以时间为维度的信息列表,典型的比如主播动态,新帖。这类信息排序方式是固定的时间顺序,可以考虑使用List或者SortedSet来存储。

redis> LPUSH user:55_recent_activitiy  '{datetime:201804112010,type:publish,title:开播啦,content:加油}'
(integer) 1
redis> LPUSH user:55_recent_activitiy '{datetime:201804131910,type:publish,title:请假,content:抱歉,今天有事鸽一天}'
(integer) 2
redis> LRANGE user:55_recent_activitiy 0 10
1) "{datetime:201804131910,type:publish,title:\xe8\xaf\xb7\xe5\x81\x87\",content:\xe6\x8a\xb1\xe6\xad\x89\xef\xbc\x8c\xe4\xbb\x8a\xe5\xa4\xa9\xe6\x9c\x89\xe4\xba\x8b\xe9\xb8\xbd\xe4\xb8\x80\xe5\xa4\xa9}"
2) "{datetime:201804112010,type:publish,title:\xe5\xbc\x80\xe6\x92\xad\xe5\x95\xa6,content:\xe5\x8a\xa0\xe6\xb2\xb9}"

阿里云Redis优势

  • 阿里云主从版Redis提供10万的QPS,读写分离版本Redis提供60万QPS最大力度支持系统的高并发需求。
  • 资深专家团队深度开发维护Redis源码,经千万服务考验,超高稳定性和安全性。
  • 双机热备架构,故障秒级自动迁移,全力保障订单数据。
  • 一键创建,一键扩容,全方位智能监控运维平台。请求量,活跃度一眼就能看清。
  • 专业服务团队,实时监控可用性,7 x 24小时在线咨询。

使用Redis混合存储实例存储信息

阿里云Redis混合存储产品完全兼容Redis协议,用户无需修改任何代码,以低成本的NVMe盘存储不常访问的直播间数据,可以突破内存容量限制,单实例最高可支持TB级别的数据容量。

图片描述

  1. 当Redis混合存储实例内存可以存储所有直播间数据时,访问所有直播间数据均可享受极致性能。
  2. 当直播间数据越来越多,快要超过实例内存限制时,Redis混合存储实例会自动从访问频率,访问时间等维度选择冷门的直播间数据,后台将其Value存储到磁盘上;
  3. 热门直播间数据仍然保留在内存中,性能不受任何影响;
  4. 当访问到磁盘上的冷门直播间数据时,数据会自动从后台加载到内存中,所有IO操作都经过阿里云自研的新一代存储引擎Fusion Engine极致优化,4K数据加载速度在20us左右;
  5. 通过将部分冷数据存储到磁盘的方式,有效降低了用户成本并突破内存对单实例容量的限制。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258923

Python数据挖掘与机器学习技术入门实战

摘要: 什么是数据挖掘?什么是机器学习?又如何进行Python数据预处理?本文将带领大家一同了解数据挖掘和机器学习技术,通过淘宝商品案例进行数据预处理实战,通过鸢尾花案例介绍各种分类算法。

课程主讲简介:
韦玮,企业家,资深IT领域专家/讲师/作家,畅销书《精通Python网络爬虫》作者,阿里云社区技术专家。

以下内容根据主讲嘉宾视频分享以及PPT整理而成。

本次课程包含了五个知识点:
1.数据挖掘与机器学习技术简介
2.Python数据预处理实战
3.常见分类算法介绍
4.对鸢尾花进行分类案例实战
5.分类算法的选择思路与技巧

一、数据挖掘与机器学习技术简介

什么是数据挖掘?数据挖掘指的是对现有的一些数据进行相应的处理和分析,最终得到数据与数据之间深层次关系的一种技术。例如在对超市货品进行摆放时,牛奶到底是和面包摆放在一起销量更高,还是和其他商品摆在一起销量更高。数据挖掘技术就可以用于解决这类问题。具体来说,超市的货品摆放问题可以划分为关联分析类场景。

在日常生活中,数据挖掘技术应用的非常广泛。例如对于商户而言,常常需要对其客户的等级(svip、vip、普通客户等)进行划分,这时候可以将一部分客户数据作为训练数据,另一部分客户数据作为测试数据。然后将训练数据输入到模型中进行训练,在训练完成后,输入另一部分数据进行测试,最终实现客户等级的自动划分。其他类似的应用例子还有验证码识别、水果品质自动筛选等。

那么机器学习技术又是什么呢?一言以蔽之,凡是让机器通过我们所建立的模型和算法对数据之间的关系或者规则进行学习,最后供我们利用的技术都是机器学习技术。其实机器学习技术是一个交叉的学科,它可以大致分为两类:传统的机器学习技术与深度学习技术,其中深度学习技术包含了神经网络相关技术。在本次课程中,着重讲解的是传统的机器学习技术及各种算法。

由于机器学习技术和数据挖掘技术都是对数据之间的规律进行探索,所以人们通常将两者放在一起提及。而这两种技术在现实生活中也有着非常广阔的应用场景,其中经典的几类应用场景如下图所示:

图片描述

1、分类:对客户等级进行划分、验证码识别、水果品质自动筛选等

机器学习和数据挖掘技术可以用于解决分类问题,如对客户等级进行划分、验证码识别、水果品质自动筛选等。

以验证码识别为例,现需要设计一种方案,用以识别由0到9的手写体数字组成的验证码。有一种解决思路是,先将一些出现的0到9的手写体数字划分为训练集,然后人工的对这个训练集进行划分,即将各个手写体映射到其对应的数字类别下面,在建立了这些映射关系之后,就可以通过分类算法建立相应的模型。这时候如果出现了一个新的数字手写体,该模型可以对该手写体代表的数字进行预测,即它到底属于哪个数字类别。例如该模型预测某手写体属于数字1的这个类别,就可以将该手写体自动识别为数字1。所以验证码识别问题实质上就是一个分类问题。

水果品质的自动筛选问题也是一个分类问题。水果的大小、颜色等特征也可以映射到对应的甜度类别下面,例如1这个类别可以代表甜,0这个类别代表不甜。在获得一些训练集的数据之后,同样可以通过分类算法建立模型,这时候如果出现一个新的水果,就可以通过它的大小、颜色等特征来自动的判断它到底是甜的还是不甜的。这样就实现了水果品质的自动筛选。

2、回归:对连续型数据进行预测、趋势预测等

除了分类之外,数据挖掘技术和机器学习技术还有一个非常经典的场景——回归。在前文提到的分类的场景,其类别的数量都有一定的限制。比如数字验证码识别场景中,包含了0到9的数字类别;再比如字母验证码识别场景中,包含了a到z的有限的类别。无论是数字类别还是字母类别,其类别数量都是有限的。

现在假设存在一些数据,在对其进行映射后,最好的结果没有落在某个0、1或者2的点上,而是连续的落在1.2、1.3、1.4…上面。而分类算法就无法解决这类问题,这时候就可以采用回归分析算法进行解决。在实际的应用中,回归分析算法可以实现对连续型数据进行预测和趋势预测等。

3、聚类:客户价值预测、商圈预测等

什么是聚类?在上文中提过,要想解决分类问题,必须要有历史数据(即人为建立的正确的训练数据)。倘若没有历史数据,而需要直接将某对象的特征划分到其对应的类别,分类算法和回归算法无法解决这个问题。这种时候有一种解决办法——聚类,聚类方法直接根据对象特征划分出对应的类别,它是不需要经过训练的,所以它是一种非监督的学习方法。

在什么时候能用到聚类?假如数据库中有一群客户的特征数据,现在需要根据这些客户的特征直接划分出客户的级别(如SVIP客户、VIP客户),这时候就可以使用聚类的模型去解决。另外在预测商圈的时候,也可以使用聚类的算法。

4、关联分析:超市货品摆放、个性化推荐等

关联分析是指对物品之间的关联性进行分析。例如,某超市内存放有大量的货品,现在需要分析出这些货品之间的关联性,如面包商品与牛奶商品之间的关联性的强弱程度,这时候可以采用关联分析算法,借助于用户的购买记录等信息,直接分析出这些商品之间的关联性。在了解了这些商品的关联性之后,就可以将之应用于超市的商品摆放,通过将关联性强的商品放在相近的位置上,可以有效提升该超市的商品销量。
此外,关联分析还可以用于个性化推荐技术。比如,借助于用户的浏览记录,分析各个网页之间存在的关联性,在用户浏览网页时,可以向其推送强关联的网页。例如,在分析了浏览记录数据后,发现网页A与网页C之间有很强的关联关系,那么在某个用户浏览网页A时,可以向他推送网页C,这样就实现了个性化推荐。

5、自然语言处理:文本相似度技术、聊天机器人等

除了上述的应用场景之外,数据挖掘和机器学习技术也可以用于自然语言处理和语音处理等等。例如对文本相似度的计算和聊天机器人。

二、Python数据预处理实战

在进行数据挖掘与机器学习之前,首先要做的一步是对已有数据进行预处理。倘若连初始数据都是不正确的,那么就无法保证最后的结果的正确性。只有对数据进行预处理,保证其准确性,才能保证最后结果的正确性。

数据预处理指的是对数据进行初步处理,把脏数据(即影响结果准确率的数据)处理掉,否则很容易影响最终的结果。常见的数据预处理方法如下图所示:

图片描述

1、缺失值处理

缺失值是指在一组数据中,某行数据缺失的某个特征值。解决缺失值有两种方法,一是将该缺失值所在的这行数据删除掉,二是将这个缺失值补充一个正确的值。

2、异常值处理

异常值产生的原因往往是数据在采集时发生了错误,如在采集数字68时发生了错误,误将其采集成680。在处理异常值之前,自然需要先发现这些异常值数据,往往可以借助画图的方法来发现这些异常值数据。在对异常值数据处理完成之后,原始数据才会趋于正确,才能保证最终结果的准确性。

3、数据集成

相较于上文的缺失值处理和异常值处理,数据集成是一种较为简单的数据预处理方式。那么数据集成是什么?假设存在两组结构一样的数据A和数据B,且两组数据都已加载进入内存,这时候如果用户想将这两组数据合并为一组数据,可以直接使用Pandas对其进行合并,而这个合并的过程实际上就是数据的集成。

接下来以淘宝商品数据为例,介绍一下上文预处理的实战。

在进行数据预处理之前,首先需要从MySQL数据库中导入淘宝商品数据。在开启MySQL数据库之后,对其中的taob表进行查询,得到了如下的输出:

图片描述

可以看到,taob表中有四个字段。其中title字段用于存储淘宝商品的名称;link字段存储淘宝商品的链接;price存储淘宝商品的价格;comment存储淘宝商品的评论数(一定程度上代表商品的销量)。

那么接下来如何将这些数据导入进来?首先通过pymysql连接数据库(如果出现乱码,则对pymysql的源码进行修改),连接成功后,将taob中的数据全部检索出来,然后借助pandas中的read_sql()方法便可以将数据导入到内存中。read_sql()方法有两个参数,第一个参数是sql语句,第二个参数是MySQL数据库的连接信息。具体代码如下图:

图片描述

1、缺失值处理实战

对缺失值进行处理可以采用数据清洗的方式。以上面的淘宝商品数据为例,某件商品的评论数可能为0,但是它的价格却不可能为0。然而实际上在数据库内存在一些price值为0的数据,之所以会出现这种情况,是因为对部分数据的价格属性没有爬到。

那么如何才能判断出这些数据出现了缺失值呢?可以通过以下的方法来进行判别:首先对于之前的taob表调用data.describe()方法,会出现如下图所示的结果:

图片描述

如何看懂这个统计结果?第一步要注意观察price和comment字段的count数据,如果两者不相等,说明一定有信息缺失;如果两者相等,则暂时无法看出是否有缺失情况。例如price的count为9616.0000,而comment的count为9615.0000,说明评论数据至少缺失了一条。

其他各个字段的含义分别为:mean代表平均数;std代表标准差;min代表最小值;max代表最大值。

那么如何对这些缺失数据进行处理?一种方法是删掉这些数据,还有一种方法是在缺失值处插入一个新值。第二种方法中的值可以是平均数或者中位数,而具体使用平均数还是中位数需要根据实际情况来决定。例如年龄这个数据(1到100岁),这类平稳、变化的级差不大的数据,一般插入平均数,而变化的间隔比较大的数据,一般插入中位数。

处理价格的缺失值的具体操作如下:

图片描述

2、异常值处理实战

跟缺失值的处理过程类似,想要处理异常值,首先要发现异常值。而异常值的发现往往是通过画散点图的方法,因为相似的数据会在散点图中集中分布到一块区域,而异常的数据会分布到远离这块区域的地方。根据这个性质,可以很方便的找到数据中的异常值。具体操作如下图:

图片描述

首先需要从数据中抽出价格数据和评论数据。通常的做法可以借助循环去抽取,但是这种方法太复杂,有一种简单的方法是这个数据框进行转置,这时候原先的列数据就变成了现在的行数据,可以很方便的获取价格数据和评论数据。接下来通过plot()方法绘制散点图,plot()方法第一个参数代表横坐标,第二个参数代表纵坐标,第三个参数代表图的类型,”o”代表散点图。最后通过show()方法将其展现出来,这样就可以直观的观测到离群点。这些离群点对数据的分析没有帮助,在实际操作中往往需要将这些离群点代表的数据删除或者转成正常的值。下图是绘制的散点图:

图片描述

根据上图所示,将评论大于100000,价格大于1000的数据都处理掉,就可以达到处理异常值的效果。而具体的两种处理方法的实现过程如下:

第一种是改值法,将其改为中位数、平均数或者其他的值。具体操作如下图所示:

图片描述

第二种是删除处理法,即直接删除这些异常数据,也是推荐使用的一种方法。具体操作如下图所示:

图片描述

3、分布分析

分布分析是指对数据的分布状态进行分析,即观察其是线性分布还是正态分布。一般采用画直方图的方式来进行分布分析。直方图的绘制有以下几个步骤:计算极差、计算组距和绘制直方图。具体的操作如下图所示:

图片描述

其中,借助arrange()方法来制定样式,arrange()方法第一个参数代表最小值,第二个参数代表最大值,第三个参数代表组距,接下来使用hist()方法来绘制直方图。
taob表中的淘宝商品价格直方图如下图所示,大致上符合正态分布:

图片描述

taob表中的淘宝商品评论直方图如下图所示,大致上是递减的曲线:

图片描述

4、词云图的绘制

有的时候常常需要根据一段文本信息来进行词云图的绘制,绘制的具体操作如下图:

图片描述

实现的大致流程是:先使用cut()对文档进行切词,在切词完成之后,将这些词语整理为固定格式,然后根据所需的词云图的展现形式读取相应的图片(下图中的词云图是猫的形状),接着使用wc.WordCloud()进行词云图的转换,最后通过imshow()展现出相应的词云图。例如根据老九门.txt文档绘制的词云图效果如下图所示:

图片描述

三、常见分类算法介绍

常见的分类算法有很多,如下图所示:

图片描述

其中KNN算法和贝叶斯算法都是较为重要的算法,除此之外还有其他的一些算法,如决策树算法、逻辑回归算法和SVM算法。Adaboost算法主要是用于弱分类算法改造成强分类算法。

四、对鸢尾花进行分类案例实战

假如现有一些鸢尾花的数据,这些数据包含了鸢尾花的一些特征,如花瓣长度、花瓣宽度、花萼长度和花萼宽度这四个特征。有了这些历史数据之后,可以利用这些数据进行分类模型的训练,在模型训练完成后,当新出现一朵不知类型的鸢尾花时,便可以借助已训练的模型判断出这朵鸢尾花的类型。这个案例有着不同的实现方法,但是借助哪种分类算法进行实现会更好呢?

1、KNN算法

(1)、KNN算法简介

首先考虑这样一个问题,在上文的淘宝商品中,有三类商品,分别是零食、名牌包包和电器,它们都有两个特征:price和comment。按照价格来排序,名牌包包最贵,电器次之,零食最便宜;按照评论数来排序,零食评论数最多,电器次之,名牌包包最少。然后以price为x轴、comment为y轴建立直角坐标系,将这三类商品的分布绘制在坐标系中,如下图所示:

图片描述

显然可以发现,这三类商品都集中分布在不同的区域。如果现在出现了一个已知其特征的新商品,用?表示这个新商品。根据其特征,该商品在坐标系映射的位置如图所示,问该商品最有可能是这三类商品中的哪种?

这类问题可以采用KNN算法进行解决,该算法的实现思路是,分别计算未知商品到其他各个商品的欧几里得距离之和,然后进行排序,距离之和越小,说明该未知商品与这类商品越相似。例如在经过计算之后,得出该未知商品与电器类的商品的欧几里得距离之和最小,那么就可以认为该商品属于电器类商品。

(2)实现方式

上述过程的具体实现如下:

图片描述

当然也可以直接调包,这样更加简洁和方便,缺点在于使用的人无法理解它的原理:

图片描述

(3)使用KNN算法解决鸢尾花的分类问题

首先加载鸢尾花数据。具体有两种加载方案,一种是直接从鸢尾花数据集中读取,在设置好路径之后,通过read_csv()方法进行读取,分离数据集的特征和结果,具体操作如下:

图片描述

还有一种加载方法是借助sklearn来实现加载。sklearn的datasets中自带有鸢尾花的数据集,通过使用datasets的load_iris()方法就可以将数据加载出来,随后同样获取特征和类别,然后进行训练数据和测试数据的分离(一般做交叉验证),具体是使用train_test_split()方法进行分离,该方法第三个参数代表测试比例,第四个参数是随机种子,具体操作如下:

图片描述

在加载完成之后,就可以调用上文中提到的KNN算法进行分类了。

2、贝叶斯算法

(1)、贝叶斯算法的介绍

首先介绍朴素贝叶斯公式:P(B|A)=P(A|B)P(B)/P(A)。假如现在有一些课程的数据,如下表所示,价格和课时数是课程的特征,销量是课程的结果,若出现了一门新课,其价格高且课时多,根据已有的数据预测新课的销量。

图片描述

显然这个问题属于分类问题。先对表格进行处理,将特征一与特征二转化成数字,即0代表低,1代表中,2代表高。在进行数字化之后,[[t1,t2],[t1,t2],[t1,t2]]——[[0,2],[2,1],[0,0]],然后对这个二维列表进行转置(便于后续统计),得到[[t1,t1,t1],[t2,t2,t2]]——-[[0,2,0],[2,1,0]]。其中[0,2,0]代表着各个课程价格,[2,1,0]代表各个课程的课时数。

而原问题可以等价于求在价格高、课时多的情况下,新课程销量分别为高、中、低的概率。即P(C|AB)=P(AB|C)P(C)/P(AB)=P(A|C)P(B|C)P(C)/P(AB)=》P(A|C)P(B|C)P(C),其中C有三种情况:c0=高,c1=中,c2=低。而最终需要比较P(c0|AB)、P(c1|AB)和P(c2|AB)这三者的大小,又
P(c0|AB)=P(A|C0)P(B|C0)P(C0)=2/4*2/4*4/7=1/7
P(c1|AB)=P(A|C1)P(B|C1)P(C1)=0=0
P(c2|AB)=P(A|C2)P(B|C2)P(C2)=0=0
显然P(c0|AB)最大,即可预测这门新课的销量为高。

(2)、实现方式

跟KNN算法一样,贝叶斯算法也有两种实现方式,一种是详细的实现:

图片描述

图片描述

另一种是集成的实现方式:

图片描述

3、决策树算法

决策树算法是基于信息熵的理论去实现的,该算法的计算流程分为以下几个步骤:
(1)先计算总信息熵
(2)计算各个特征的信息熵
(3)计算E以及信息增益,E=总信息熵-信息增益,信息增益=总信息熵-E
(4)E如果越小,信息增益越大,不确定因素越小

决策树是指对于多特征的数据,对于第一个特征,是否考虑这个特征(0代表不考虑,1代表考虑)会形成一颗二叉树,然后对第二个特征也这么考虑…直到所有特征都考虑完,最终形成一颗决策树。如下图就是一颗决策树:

图片描述

决策树算法实现过程为:首先取出数据的类别,然后对数据转化描述的方式(例如将“是”转化成1,“否”转化成0),借助于sklearn中的DecisionTreeClassifier建立决策树,使用fit()方法进行数据训练,训练完成后直接使用predict()即可得到预测结果,最后使用export_graphviz进行决策树的可视化。具体实现过程如下图所示:

图片描述

4、逻辑回归算法

逻辑回归算法是借助于线性回归的原理来实现的。假如存在一个线性回归函数:y=a1x1+a2x2+a3x3+…+anxn+b,其中x1到xn代表的是各个特征,虽然可以用这条直线去拟合它,但是由于y范围太大,导致其鲁棒性太差。若想实现分类,需要缩小y的范围到一定的空间内,如[0,1]。这时候通过换元法可以实现y范围的缩小:
令y=ln(p/(1-p))
那么:e^y=e^(ln(p/(1-p)))
=> e^y=p/(1-p)
=>e^y*(1-p)=p => e^y-p*e^y=p
=> e^y=p(1+e^y)
=> p=e^y/(1+e^y)
=> p属于[0,1]

这样y就降低了范围,从而实现了精准分类,进而实现逻辑回归。

逻辑回归算法对应的实现过程如下图所示:

图片描述

5、SVM算法

SVM算法是一种精准分类的算法,但是其可解释性并不强。它可以将低维空间线性不可分的问题,变为高位空间上的线性可分。SVM算法的使用十分简单,直接导入SVC,然后训练模型,并进行预测。具体操作如下:

图片描述

尽管实现非常简单,然而该算法的关键却在于如何选择核函数。核函数可分为以下几类,各个核函数也适用于不同的情况:
(1)线性核函数
(2)多项式核函数
(3)径向基核函数
(4)Sigmoid核函数
对于不是特别复杂的数据,可以采用线性核函数或者多项式核函数。对于复杂的数据,则采用径向基核函数。采用各个核函数绘制的图像如下图所示:

图片描述

5、Adaboost算法

假如有一个单层决策树的算法,它是一种弱分类算法(准确率很低的算法)。如果想对这个弱分类器进行加强,可以使用boost的思想去实现,比如使用Adaboost算法,即进行多次的迭代,每次都赋予不同的权重,同时进行错误率的计算并调整权重,最终形成一个综合的结果。

Adaboost算法一般不单独使用,而是组合使用,来加强那些弱分类的算法。

五、分类算法的选择思路与技巧

首先看是二分类还是多分类问题,如果是二分类问题,一般这些算法都可以使用;如果是多分类问题,则可以使用KNN和贝叶斯算法。其次看是否要求高可解释性,如果要求高可解释性,则不能使用SVM算法。再看训练样本数量、再看训练样本数量,如果训练样本的数量太大,则不适合使用KNN算法。最后看是否需要进行弱-强算法改造,如果需要则使用Adaboost算法,否则不使用Adaboost算法。如果不确定,可以选择部分数据进行验证,并进行模型评价(耗时和准确率)。

综上所述,可以总结出各个分类算法的优缺点为:
KNN:多分类,惰性调用,不宜训练数据过大
贝叶斯:多分类,计算量较大,特征间不能相关
决策树算法:二分类,可解释性非常好
逻辑回归算法:二分类,特征之间是否具有关联无所谓
SVM算法:二分类,效果比较不错,但可解释性欠缺
Adaboost算法:适用于对弱分类算法进行加强

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258932

融合非负矩阵分解和图全变分的歌曲推荐算法

摘要: Kirell Benzi, Vassilis Kalofolias, Xavier Bresson and Pierre Vandergheynst Signal Processing Laboratory 2 (LTS2), Swiss Federal Institute of Technology (EPFL)

Kirell Benzi,

Vassilis Kalofolias,

Xavier Bresson and Pierre Vandergheynst

Signal Processing Laboratory 2 (LTS2),

Swiss Federal Institute of Technology (EPFL)

代码参见:https://github.com/hxsylzpf/recog

摘 要

本文正式地形式化一个全新的的歌曲推荐算法,其将歌曲推荐的问题转化为矩阵补全的问题来考虑,并通过基于非负矩阵分解(non-negative matrix factorization, NMF)的协同过滤算法以及图上的结合图的全变分(total variation, TV)的基于内容的过滤方法相结合来解决这个问题。相关的图通过使用音频、元数据以及社交特征等丰富的信息的结合,对歌单的邻接信息以及歌曲的相似度信息进行编码。我们证明,我们提出的这个融合了几种知名的方法的混合推荐系统,有着广阔的应用前景,并在效果上超过融合的相关算法。通过在真实数据上进行的实验,我们证实了我们的模型能仅仅根据低秩矩阵的信息或者基于图的信息以及两者的结合进行歌曲的推荐。

关键字:推荐系统,图,非负矩阵分解,全变分,音频特征

一 引言

在 Netflix上推荐电影,在Facebook上推荐好友,或者在LinkedIn上推荐工作等任务在过去几年中吸引了越来越多的关注。大部分Netflix奖的获得者喜爱用的著名的低秩矩阵分解算法需要明确的用户评级作为输入。一些其他相似的方法则通过用户对物品的操作来反映用户对物品的偏好,以致力于解决用户的不明确的反馈问题。具体到歌曲和歌单推荐问题,也已经有了各种不同的方法,其中既有单纯的基于内容的方法,也有各种混合的模型。最近,图的正则化被提出,用来提高矩阵补全算法的效果。

本文的主要贡献在以下几个方面:

l 设计并实现了一个数学上的融合协同过滤以及内容过滤的声音混合系统;

l 介绍了一个新的图正则化项(TV),在推荐系统的背景下,其效果要优于广泛应用的 Tikhonov 正则化;

l 一个良好定义的基于近端分裂方法的迭代优化模式。

大量的实验证明我们提出的推荐系统具有很好的表现。

二 本文的歌曲推荐算法

1. 歌曲推荐算法

假设我们有n个歌单,每个列表都包含m首歌中的其中一部分。我们定义矩阵C∈{0,1}n×m,矩阵中的元素 Cij 为 1 则表示歌单 i 中包含歌曲 j,否则为 0。我们再定义一个权重矩阵Ω∈{0,1}n×m,当输入的 Cij 可能为 1 时,Ωij=1,否则等于一个很小的值 ε(我们使用的 ε=0.1)。这里应用了不明确反馈问题的思路。在矩阵 C 中一个元素为 0 不代表这首歌与这个歌单无关,而是更可能不相关。

训练阶段的目标是找到一个近似的低秩表示,使AB ≈ C,其中A ∈ R+n×r,B ∈R+r×m都是非负的,且 r 很小。这个问题被称为非负矩阵分解(NMF),并引起了广泛的关注。相比其他的矩阵分解方法,NMF 由于只使用了加性因子,能够学习到物体(本文中即为歌单)的各个部分。NMF 的方法的缺点是其为 NP-hard。所以对于找到一个局部最小点来说正则化使很重要的。在我们的问题中,我们使用歌曲和歌单的图来确定因子 A 和 B。我们模型的公式计算如下:

          (1)

其中(∘)代表点级别的乘法运算符,θA, θB∈R+。我们使用一个加权 KL 散度作为 C 和 AB 之间距离的衡量,有研究表明对于不同的 NMF 设置,这比Frobenius 范式更为准确。公式中的第二项是歌单图中 A 的行的全变分,所以对其进行惩罚就提升了分段恒定信号。公式中的第三项与第二项类似,是 B 的列的全变分。最终我们提出的模型利用了参考文献[9, 16],并利用 TV 半范式将其扩展到图。

1.1 利用全变分进行图的正则化

在我们基于 NMF 的推荐系统中,每个歌单 i 都被矩阵 A 中的第 i 行 Ai 投影到一个低维空间。为了学习到歌单 Ai 的低秩的表示,我们通过歌单的低秩表示,定义歌单之间成对的相似度ωAii’。我们可以从 TV 正则化项的定义中推导出,

‖A‖TVA= ∑i∑i’~ iωAii’‖Ai-Ai’‖1所以当两个歌单 i 和 i’是相似的,那么它们在图中则是连通的,且连接这两个歌单的边的权值ωAii’很大(这里ωAii’≈ 1)。另外,相应的低维向量表示(Ai,Ai’)间的距离过大就会被惩罚,这使得在低维空间中,(Ai,Ai’)的距离会保持较近。同理,每首歌 j 都由矩阵 B 中的一列 Bj 表示到一个低维空间。如果两首歌(j,j’)很接近(ωBii’′≈ 1),那么(Bj,Bj’)以及图的正则化‖B‖则遵循上述的规律。

参考文献[10]的思路与本文相似,通过 Tikhonov 正则化将图的信息引入到模型中,例如通过 Dirichlet 能量项1/2∑i∑i’~ iωAii’‖Ai-Ai’‖22。然而这种方法促进了A 的列之间平滑的变化,而本文的方法图的 TV 项的惩罚则促进了在列 Ai 和 Ai’间具有潜在的突变边缘的分段恒定信号。这对于需要寻找多个类别的任务是有益的,例如聚类,或者本文中的推荐系统所涉及的相似歌单属于不同的目录的情况。

我们在第 4 部分会详细分析,歌曲和歌单的图的使用可以显著的提升推荐效果,且 TV 项的表现要比 Tikhonov 正则化更好。

1.2 原始-对偶优化

对于矩阵 A 和 B 来说,优化问题是全局非凸,但是各自凸的。一个常用的方法是固定 A 去优化 B,然后再固定 B 去优化 A,反复直到收敛。我们这里以固定 A 而优化 B 为例来描述上述优化方法。相同的方法可以在固定 B 时应用于A。我们将上述问题重新写为如下形式:

F(AB) + G(KBB) (2)

其中

F(AB)=KL(Ω∘(C‖AB)) =(−ΩijCij(log)+Ωij(AB)ij (3)

             (4)

其中KB∈Rne×m是图的梯度算子,ne 是图 B 中的边的条数。使用函数 F 和G 的共轭函数 F*和 G*,则等价于鞍点问题:

           (5)

其中Y1 ∈ Rn×m,Y2 ∈ Rne×r。我们定义最近项和时间间隔 σ1,σ2,τ1,τ2:

           (6)

迭代的方式是,当 k≥0 时:

     Y1K+1 = proxσ1F∗(Y1K+ σ1ABK)                  (7)

Y2K+1 = proxσ2G∗(Y2K+ σ2KBBK) (8)

BK+1=(BK-τ1ATY1K+1-(KTBY2K+1)T)+ (9)

其中 prox 是最近算子,(∙)+ = max(∙, 0)。在我们的问题中,我们选择了标准Arrow-Hurwicz 时间间隔σ1 =τ1 = 1⁄‖A‖,σ2 =τ2 = 1⁄‖K‖,其中‖∙‖是算子范数。

则最近解为:

      (10)

其中 shrink 即为软缩减算子。注意到,同样的算法也可以应用于 Tikhonov正则化,例如,通过将上面的第一个式子改为proxσ2G*(Y)=Y,就可以将‖KBB‖1替换为G(KB B) = ‖KBB‖22。在式(10)中的正则化使用的是 KL 散度的一个对称变形,但是与我们使用的这种方法不同的是,Tikhonov 正则化不存在解析解。所以其目标函数并不像我们的一样满足一个有效的原始-对偶优化方法。我们保留这种非对称的 KL 模型,并称其为 GNMF,来将 TV 与 Tikhonov 正则化进行比较。

1.3 推荐歌曲

我们通过式(1)学到矩阵 A 和 B 之后,我们希望已知一些歌曲 cin 时(如图 1-1),能够推荐新的歌单 crec。我们也希望能实现实时的推荐,于是我们定义一个快速推荐

给定一些歌曲 cin,我们先通过解决一个正则最小平方问题来在歌单的低秩空间学习一个好的表示:ain=arg min a∈R1×r||Ωin。(cin-aB)||22+ε||a||22。其解析解ain=(BTΩinB+εI)-1(BTΩincin)当 r 很小时较容易计算(我们令ε = 0.01)。

与给定的歌单有相似表示的歌单也对于我们推荐歌单有益。所以在低维空间中,我们用加权和arec=Σni=1ωiAi/Σni=1ωi来表示被推荐的歌单。这里权重ωi=e-||ain-Ai||22/σ2, 取 决 于 与 其 他 歌 单 的 表 示 的 距 离ain, 且 σ =mean({||ain-Ai||2}ni=1)/4。最终推荐歌单的低秩表示为:

crec=arecB (11)

这里crec并不是二元的,而是一个连续的值,表示歌的排名。

2.歌曲和歌单的图

2.1 歌单的图

歌单的图中包含了歌单间成对的相似度信息。图的节点为歌单,边的权重表示了两个歌单之间的距离,当权重很大时(ωAii’ ≈ 1),表示两个歌单具有很高的相似度。在我们的模型中,歌单图中边的权重的计算不仅与外部信息例如元数据有关,还与内部信息有关,例如歌单中的歌曲信息。我们使用预定义好的 Art of the Mix 歌单分类来标注用户的歌单。则歌单的图中边的权重的计算定义为

        ωAii’=Υ1δcat{i}=cat{i’}+Υ2simcos(Ci,Ci’)

其中 cat 表示歌单的标签,Ci是矩阵 C 的第 i 行simcos(p,q)=

pTq/||p||.||q||是两个歌单的歌曲向量之间的余弦相似度距离。余弦相似度为两首歌相似的比例比上两个歌单长度乘积的均方根。两个正的参数Υ1和Υ2满足Υ1 + Υ2 = 1,用于决定歌单标签的相似度和歌单元素级别的相似度之间的相对重要程度。为了控制每个分类的边缘概率密度并让我们的模型更灵活,我们在同一个分类的节点之间保留 20%的边的一个子集。在实验中我们发现,令Υ2 = 0.3能获得较好的效果。 歌单图的效果通过使用标准 Louvain 方法对图进行分割进行衡量。分块的数目由在模块最大的地方切开形成的模块化系数的树图自动给出。第 4 节使用的图的模块化系数在使用只余弦相似度(Υ2 = 0)时为 0.63。如果我们加入元数据的信息,将每个分类下所有歌单对中的 20%进行连接,并令Υ2 = 0.3,则模块化系数增长到 0.82。

2.2 歌曲的图

我们模型中使用的第二个图是歌曲的相似度图。歌曲的图由从音频信号中抽取的 Echonest 特征与元数据信息结合以及音轨的社会信息混合组成。表 2-1 给出了用于构建歌曲图所使用到的特征。

为了提高我们的音频特征的质量,我们使用从 LastFm 相关标签中抽取的歌曲类型训练了一个大间隔最近邻模型(Large Margin Nearest Neighbors,LMNN)。为了抽取到真实的音乐类型,我们使用了这些标签经过其流行度(根据 LastFm)加权的 Levenshtein 距离以及 ID3 标签中定义的音乐类型。 最终,我们用 k 近邻(k=5)来构建歌曲的图,其中,对于 j 的 k 个最近邻中的一首歌 j’,两首歌 j 和 j’之间的边的权重ωBjj’=exp(-||xj-xj’||1/σ),参数σ是尺度参数,表示 k 个邻居之间距离的平均值。得到的图的模块化系数很高(0.64),使用 k-NN 进行非监督的准确率为 65%左右。

3. 实验结果

在这部分,我们通过在一个真实数据集上进行实验,将我们的模型与其他 3个不同的推荐系统进行比较。我们的测试数据集是从由 McFee 等构建 的 Art of the Mix 语料库中抽取的。我们之前就是在这个数据库中抽取了上述的特征。 评价一个音乐推荐系统是一个众所周知的难题。在本文中,我们使用一个经典的评价使用间接反馈的推荐系统的模型的方法,Mean percentage Ranking(MPR)以及歌单分类准确度,即在查询的分类中,过去已经出现过的歌单中的歌曲的百分比。

3.1 模型

我们先将我们的模型与一个只基于图的方法(我们称为 Cosine only)进行比较。对于给定输入,这个模型使用余弦相似度计算 t 个最接近的歌单(这里 t=50),通过将歌单中的所有歌曲用余弦相似度进行加权从而计算出一个柱状图进行推荐,如式(11)所示。第二个模型是使用了 KL 散度的 NMF,我们成为 NMF。最后一个模型 GNMF 是基于使用了 Tikhonov 正则化的 KL 散度,并应用了我们模型中的图。

3.2 查询

我们用 3 种不同的查询来测试我们的模型。在所有 3 种查询中,一个查询ctest包含 s=3 首歌作为输入,系统以一个歌单的形式返回最相近的 k=30 首歌作为输出。第一种查询为随机查询,从所有类别的歌中随机选择歌曲,其结果仅作为比较的基准。第二种测试查询,在测试集中的一个歌单中随机选择 3 首歌。第三种采样查询,在一个类别下随机选择 3 首歌。这种查询模拟了用户通过歌曲类别查询歌单的推荐系统。

3.3 训练

我们使用从所有歌单中随机选择出 70%的子集作为训练集,由于我们的模型不是联合凸的,初始化可能会对系统的表现产生影响,所以我们使用现在常用的 NNDSVD 技术来得到一个好的近似解。在我们的所有实验中,r=15 的结果很好,这意味着每行都有 5-20 个非零元素。最好的参数θA = 18以及θB= 1使用了网格搜索的方法。为了防止过拟合,我们在验证集的 MPR 刚停止增长的时候就使用提前停止的方法。

3.4 验证集

我们通过人工的在不用的歌单类别中进行查询的方法来构建验证集中的歌单。对于每个类别,我们在之前已经在用户创建的标注了类别的歌单中出现的歌曲中随机的选择 s=3 首歌。

3.5 结果

模型的结果,即不同模型的歌单分类准确率和 MPR 我们列在表 3-1 和表 3-2 中。如我们所预料的,对于随机查询,所有的模型都不能根据输入的歌曲返回歌单,而且使用了协同滤波同时没有假如图信息的 NMF 表现很差。这可以理解为是数据集的稀疏性造成的,数据集每行只含有 5-20 个非零元素,稀疏度只有 0.11-0.46%。协同过滤模型在有越多的观察到的等级时的表现越好,cosine 模型在类别准确率上表现更好,因为它直接使用了输入歌曲和歌单之间的余弦距离。然而,它的 MPR 说明即使状况很复杂,我们的模型在歌曲推荐时表现的更好。

4. 结论

在这篇论文中我们介绍了一个新的灵活的歌曲推荐系统,这个系统结合了歌单的协同过滤信息以及图中包含的歌曲相似度信息。我们使用一个基于原始-对偶的优化模式来得到一个高度并行的、可以用来处理大型数据集的算法。我们选择图的 TV 而不是 Tikhonov 正则化,并通过将我们的系统与 3 个不同的算法在真实的音乐歌单数据集上做比较,展示了我们模型的良好的实验效果。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258926

小白必备!Rust 编程语言入门教程

开发者小伙伴们, Rust 您一定要了解一下
最近的一项 Stack Overflow 调查发现,
近 80% 的受访者
都喜欢或希望使用 Rust 语言进行开发。
这个数字真是令人难以置信!
那么 Rust 有什么益处呢?
今天,我们就来了解一下
这种类似 C 的语言的精彩亮点,
并演示为什么它是您一定要学习的语言。

首先,我们来快速了解一下它的发展历史。相对于前辈产品(最重要的是 C,它比 Rust 早了 38 年),Rust 是一种较新的语言,但它的血统造就了它的多模式方法。Rust 被视为一种类似 C 的语言,但它包含的其他特性带来了相较其前辈产品的优势。

Rust 有许多特性,这些特性让它变得很有用。由于开发人员的需求各不相同,今天,我们先来学习 Rust 的 5 个关键概念,并在 Rust 源代码中展示这些概念:

通过模块实现可重用的代码
执行安全检查来获得更干净的代码
更好的错误处理
对并发性和线程的支持
对复杂数据类型(集合)的支持

即刻点击“阅读原文” 获得完整教程,
快速修炼做全能技术咖!

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258929

Micropython TPYBoard拼插编程之按键控制LED灯

一、什么是TPYBoard开发板
TPYBoard是以遵照MIT许可的MicroPython为基础,由TurnipSmart公司制作的一款MicroPython开发板,它基于STM32F405单片机,通过USB接口进行数据传输。该开发板内置4个LED灯、一个加速传感器,可在3V-10V之间的电压正常工作。TPYBoard开发板让用户可以通过Python代码轻松控制微控制器的各种外设,比如LED等,读取管脚电压,播放歌曲,和其他设备联网等等。TPYBoard开发板支持Python3.0及以上版本的直接运行,支持重力加速度传感器,支持上百周边外设配件,支持SWD烧写固件。零基础也能灵活掌握单片机技术!

二、利用TPYBoard完成按键控制LED灯实验
1、具体要求
通过USR用户按键控制LED的亮灭
2、所需器件
TYBoard开发板 一块

USB数据线 一根

3、USR用户按键功能介绍
通过按键来捕获用户触发事件。
实例化一个Switch对象命名为sw,sw()函数获取按键当前状态,按下返回True,反之False
三、制作主要过程
步骤一:
– 连接pyb开发板,打开网站http://tpyboard.com/pythoneditor/
编写代码:
1.建立变量sw创建按键对象
2.重复直到执行(主循环)
3.建立变量sw_state获取按键状态
4.如果sw_state为‘真’设置LED1打开,否则设置LED1关闭

步骤二:
点击下载python,将下载的文件替换tpyboard里面的main.py文件。
按下RST按键,查看运行效果。
制作图示
图片描述

TPYBoard 技术交流群 :157816561
Micropython玩家公众号:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258935

Python数据挖掘与机器学习技术入门实战

摘要: 什么是数据挖掘?什么是机器学习?又如何进行Python数据预处理?本文将带领大家一同了解数据挖掘和机器学习技术,通过淘宝商品案例进行数据预处理实战,通过鸢尾花案例介绍各种分类算法。

课程主讲简介:
韦玮,企业家,资深IT领域专家/讲师/作家,畅销书《精通Python网络爬虫》作者,阿里云社区技术专家。

以下内容根据主讲嘉宾视频分享以及PPT整理而成。

本次课程包含了五个知识点:
1.数据挖掘与机器学习技术简介
2.Python数据预处理实战
3.常见分类算法介绍
4.对鸢尾花进行分类案例实战
5.分类算法的选择思路与技巧

一、数据挖掘与机器学习技术简介

什么是数据挖掘?数据挖掘指的是对现有的一些数据进行相应的处理和分析,最终得到数据与数据之间深层次关系的一种技术。例如在对超市货品进行摆放时,牛奶到底是和面包摆放在一起销量更高,还是和其他商品摆在一起销量更高。数据挖掘技术就可以用于解决这类问题。具体来说,超市的货品摆放问题可以划分为关联分析类场景。

在日常生活中,数据挖掘技术应用的非常广泛。例如对于商户而言,常常需要对其客户的等级(svip、vip、普通客户等)进行划分,这时候可以将一部分客户数据作为训练数据,另一部分客户数据作为测试数据。然后将训练数据输入到模型中进行训练,在训练完成后,输入另一部分数据进行测试,最终实现客户等级的自动划分。其他类似的应用例子还有验证码识别、水果品质自动筛选等。

那么机器学习技术又是什么呢?一言以蔽之,凡是让机器通过我们所建立的模型和算法对数据之间的关系或者规则进行学习,最后供我们利用的技术都是机器学习技术。其实机器学习技术是一个交叉的学科,它可以大致分为两类:传统的机器学习技术与深度学习技术,其中深度学习技术包含了神经网络相关技术。在本次课程中,着重讲解的是传统的机器学习技术及各种算法。

由于机器学习技术和数据挖掘技术都是对数据之间的规律进行探索,所以人们通常将两者放在一起提及。而这两种技术在现实生活中也有着非常广阔的应用场景,其中经典的几类应用场景如下图所示:

图片描述

1、分类:对客户等级进行划分、验证码识别、水果品质自动筛选等

机器学习和数据挖掘技术可以用于解决分类问题,如对客户等级进行划分、验证码识别、水果品质自动筛选等。

以验证码识别为例,现需要设计一种方案,用以识别由0到9的手写体数字组成的验证码。有一种解决思路是,先将一些出现的0到9的手写体数字划分为训练集,然后人工的对这个训练集进行划分,即将各个手写体映射到其对应的数字类别下面,在建立了这些映射关系之后,就可以通过分类算法建立相应的模型。这时候如果出现了一个新的数字手写体,该模型可以对该手写体代表的数字进行预测,即它到底属于哪个数字类别。例如该模型预测某手写体属于数字1的这个类别,就可以将该手写体自动识别为数字1。所以验证码识别问题实质上就是一个分类问题。

水果品质的自动筛选问题也是一个分类问题。水果的大小、颜色等特征也可以映射到对应的甜度类别下面,例如1这个类别可以代表甜,0这个类别代表不甜。在获得一些训练集的数据之后,同样可以通过分类算法建立模型,这时候如果出现一个新的水果,就可以通过它的大小、颜色等特征来自动的判断它到底是甜的还是不甜的。这样就实现了水果品质的自动筛选。

2、回归:对连续型数据进行预测、趋势预测等

除了分类之外,数据挖掘技术和机器学习技术还有一个非常经典的场景——回归。在前文提到的分类的场景,其类别的数量都有一定的限制。比如数字验证码识别场景中,包含了0到9的数字类别;再比如字母验证码识别场景中,包含了a到z的有限的类别。无论是数字类别还是字母类别,其类别数量都是有限的。

现在假设存在一些数据,在对其进行映射后,最好的结果没有落在某个0、1或者2的点上,而是连续的落在1.2、1.3、1.4…上面。而分类算法就无法解决这类问题,这时候就可以采用回归分析算法进行解决。在实际的应用中,回归分析算法可以实现对连续型数据进行预测和趋势预测等。

3、聚类:客户价值预测、商圈预测等

什么是聚类?在上文中提过,要想解决分类问题,必须要有历史数据(即人为建立的正确的训练数据)。倘若没有历史数据,而需要直接将某对象的特征划分到其对应的类别,分类算法和回归算法无法解决这个问题。这种时候有一种解决办法——聚类,聚类方法直接根据对象特征划分出对应的类别,它是不需要经过训练的,所以它是一种非监督的学习方法。

在什么时候能用到聚类?假如数据库中有一群客户的特征数据,现在需要根据这些客户的特征直接划分出客户的级别(如SVIP客户、VIP客户),这时候就可以使用聚类的模型去解决。另外在预测商圈的时候,也可以使用聚类的算法。

4、关联分析:超市货品摆放、个性化推荐等

关联分析是指对物品之间的关联性进行分析。例如,某超市内存放有大量的货品,现在需要分析出这些货品之间的关联性,如面包商品与牛奶商品之间的关联性的强弱程度,这时候可以采用关联分析算法,借助于用户的购买记录等信息,直接分析出这些商品之间的关联性。在了解了这些商品的关联性之后,就可以将之应用于超市的商品摆放,通过将关联性强的商品放在相近的位置上,可以有效提升该超市的商品销量。
此外,关联分析还可以用于个性化推荐技术。比如,借助于用户的浏览记录,分析各个网页之间存在的关联性,在用户浏览网页时,可以向其推送强关联的网页。例如,在分析了浏览记录数据后,发现网页A与网页C之间有很强的关联关系,那么在某个用户浏览网页A时,可以向他推送网页C,这样就实现了个性化推荐。

5、自然语言处理:文本相似度技术、聊天机器人等

除了上述的应用场景之外,数据挖掘和机器学习技术也可以用于自然语言处理和语音处理等等。例如对文本相似度的计算和聊天机器人。

二、Python数据预处理实战

在进行数据挖掘与机器学习之前,首先要做的一步是对已有数据进行预处理。倘若连初始数据都是不正确的,那么就无法保证最后的结果的正确性。只有对数据进行预处理,保证其准确性,才能保证最后结果的正确性。

数据预处理指的是对数据进行初步处理,把脏数据(即影响结果准确率的数据)处理掉,否则很容易影响最终的结果。常见的数据预处理方法如下图所示:

图片描述

1、缺失值处理

缺失值是指在一组数据中,某行数据缺失的某个特征值。解决缺失值有两种方法,一是将该缺失值所在的这行数据删除掉,二是将这个缺失值补充一个正确的值。

2、异常值处理

异常值产生的原因往往是数据在采集时发生了错误,如在采集数字68时发生了错误,误将其采集成680。在处理异常值之前,自然需要先发现这些异常值数据,往往可以借助画图的方法来发现这些异常值数据。在对异常值数据处理完成之后,原始数据才会趋于正确,才能保证最终结果的准确性。

3、数据集成

相较于上文的缺失值处理和异常值处理,数据集成是一种较为简单的数据预处理方式。那么数据集成是什么?假设存在两组结构一样的数据A和数据B,且两组数据都已加载进入内存,这时候如果用户想将这两组数据合并为一组数据,可以直接使用Pandas对其进行合并,而这个合并的过程实际上就是数据的集成。

接下来以淘宝商品数据为例,介绍一下上文预处理的实战。

在进行数据预处理之前,首先需要从MySQL数据库中导入淘宝商品数据。在开启MySQL数据库之后,对其中的taob表进行查询,得到了如下的输出:

图片描述

可以看到,taob表中有四个字段。其中title字段用于存储淘宝商品的名称;link字段存储淘宝商品的链接;price存储淘宝商品的价格;comment存储淘宝商品的评论数(一定程度上代表商品的销量)。

那么接下来如何将这些数据导入进来?首先通过pymysql连接数据库(如果出现乱码,则对pymysql的源码进行修改),连接成功后,将taob中的数据全部检索出来,然后借助pandas中的read_sql()方法便可以将数据导入到内存中。read_sql()方法有两个参数,第一个参数是sql语句,第二个参数是MySQL数据库的连接信息。具体代码如下图:

图片描述

1、缺失值处理实战

对缺失值进行处理可以采用数据清洗的方式。以上面的淘宝商品数据为例,某件商品的评论数可能为0,但是它的价格却不可能为0。然而实际上在数据库内存在一些price值为0的数据,之所以会出现这种情况,是因为对部分数据的价格属性没有爬到。

那么如何才能判断出这些数据出现了缺失值呢?可以通过以下的方法来进行判别:首先对于之前的taob表调用data.describe()方法,会出现如下图所示的结果:

图片描述

如何看懂这个统计结果?第一步要注意观察price和comment字段的count数据,如果两者不相等,说明一定有信息缺失;如果两者相等,则暂时无法看出是否有缺失情况。例如price的count为9616.0000,而comment的count为9615.0000,说明评论数据至少缺失了一条。

其他各个字段的含义分别为:mean代表平均数;std代表标准差;min代表最小值;max代表最大值。

那么如何对这些缺失数据进行处理?一种方法是删掉这些数据,还有一种方法是在缺失值处插入一个新值。第二种方法中的值可以是平均数或者中位数,而具体使用平均数还是中位数需要根据实际情况来决定。例如年龄这个数据(1到100岁),这类平稳、变化的级差不大的数据,一般插入平均数,而变化的间隔比较大的数据,一般插入中位数。

处理价格的缺失值的具体操作如下:

图片描述

2、异常值处理实战

跟缺失值的处理过程类似,想要处理异常值,首先要发现异常值。而异常值的发现往往是通过画散点图的方法,因为相似的数据会在散点图中集中分布到一块区域,而异常的数据会分布到远离这块区域的地方。根据这个性质,可以很方便的找到数据中的异常值。具体操作如下图:

图片描述

首先需要从数据中抽出价格数据和评论数据。通常的做法可以借助循环去抽取,但是这种方法太复杂,有一种简单的方法是这个数据框进行转置,这时候原先的列数据就变成了现在的行数据,可以很方便的获取价格数据和评论数据。接下来通过plot()方法绘制散点图,plot()方法第一个参数代表横坐标,第二个参数代表纵坐标,第三个参数代表图的类型,”o”代表散点图。最后通过show()方法将其展现出来,这样就可以直观的观测到离群点。这些离群点对数据的分析没有帮助,在实际操作中往往需要将这些离群点代表的数据删除或者转成正常的值。下图是绘制的散点图:

图片描述

根据上图所示,将评论大于100000,价格大于1000的数据都处理掉,就可以达到处理异常值的效果。而具体的两种处理方法的实现过程如下:

第一种是改值法,将其改为中位数、平均数或者其他的值。具体操作如下图所示:

图片描述

第二种是删除处理法,即直接删除这些异常数据,也是推荐使用的一种方法。具体操作如下图所示:

图片描述

3、分布分析

分布分析是指对数据的分布状态进行分析,即观察其是线性分布还是正态分布。一般采用画直方图的方式来进行分布分析。直方图的绘制有以下几个步骤:计算极差、计算组距和绘制直方图。具体的操作如下图所示:

图片描述

其中,借助arrange()方法来制定样式,arrange()方法第一个参数代表最小值,第二个参数代表最大值,第三个参数代表组距,接下来使用hist()方法来绘制直方图。
taob表中的淘宝商品价格直方图如下图所示,大致上符合正态分布:

图片描述

taob表中的淘宝商品评论直方图如下图所示,大致上是递减的曲线:

图片描述

4、词云图的绘制

有的时候常常需要根据一段文本信息来进行词云图的绘制,绘制的具体操作如下图:

图片描述

实现的大致流程是:先使用cut()对文档进行切词,在切词完成之后,将这些词语整理为固定格式,然后根据所需的词云图的展现形式读取相应的图片(下图中的词云图是猫的形状),接着使用wc.WordCloud()进行词云图的转换,最后通过imshow()展现出相应的词云图。例如根据老九门.txt文档绘制的词云图效果如下图所示:

图片描述

三、常见分类算法介绍

常见的分类算法有很多,如下图所示:

图片描述

其中KNN算法和贝叶斯算法都是较为重要的算法,除此之外还有其他的一些算法,如决策树算法、逻辑回归算法和SVM算法。Adaboost算法主要是用于弱分类算法改造成强分类算法。

四、对鸢尾花进行分类案例实战

假如现有一些鸢尾花的数据,这些数据包含了鸢尾花的一些特征,如花瓣长度、花瓣宽度、花萼长度和花萼宽度这四个特征。有了这些历史数据之后,可以利用这些数据进行分类模型的训练,在模型训练完成后,当新出现一朵不知类型的鸢尾花时,便可以借助已训练的模型判断出这朵鸢尾花的类型。这个案例有着不同的实现方法,但是借助哪种分类算法进行实现会更好呢?

1、KNN算法

(1)、KNN算法简介

首先考虑这样一个问题,在上文的淘宝商品中,有三类商品,分别是零食、名牌包包和电器,它们都有两个特征:price和comment。按照价格来排序,名牌包包最贵,电器次之,零食最便宜;按照评论数来排序,零食评论数最多,电器次之,名牌包包最少。然后以price为x轴、comment为y轴建立直角坐标系,将这三类商品的分布绘制在坐标系中,如下图所示:

图片描述

显然可以发现,这三类商品都集中分布在不同的区域。如果现在出现了一个已知其特征的新商品,用?表示这个新商品。根据其特征,该商品在坐标系映射的位置如图所示,问该商品最有可能是这三类商品中的哪种?

这类问题可以采用KNN算法进行解决,该算法的实现思路是,分别计算未知商品到其他各个商品的欧几里得距离之和,然后进行排序,距离之和越小,说明该未知商品与这类商品越相似。例如在经过计算之后,得出该未知商品与电器类的商品的欧几里得距离之和最小,那么就可以认为该商品属于电器类商品。

(2)实现方式

上述过程的具体实现如下:

图片描述

当然也可以直接调包,这样更加简洁和方便,缺点在于使用的人无法理解它的原理:

图片描述

(3)使用KNN算法解决鸢尾花的分类问题

首先加载鸢尾花数据。具体有两种加载方案,一种是直接从鸢尾花数据集中读取,在设置好路径之后,通过read_csv()方法进行读取,分离数据集的特征和结果,具体操作如下:

图片描述

还有一种加载方法是借助sklearn来实现加载。sklearn的datasets中自带有鸢尾花的数据集,通过使用datasets的load_iris()方法就可以将数据加载出来,随后同样获取特征和类别,然后进行训练数据和测试数据的分离(一般做交叉验证),具体是使用train_test_split()方法进行分离,该方法第三个参数代表测试比例,第四个参数是随机种子,具体操作如下:

图片描述

在加载完成之后,就可以调用上文中提到的KNN算法进行分类了。

2、贝叶斯算法

(1)、贝叶斯算法的介绍

首先介绍朴素贝叶斯公式:P(B|A)=P(A|B)P(B)/P(A)。假如现在有一些课程的数据,如下表所示,价格和课时数是课程的特征,销量是课程的结果,若出现了一门新课,其价格高且课时多,根据已有的数据预测新课的销量。

图片描述

显然这个问题属于分类问题。先对表格进行处理,将特征一与特征二转化成数字,即0代表低,1代表中,2代表高。在进行数字化之后,[[t1,t2],[t1,t2],[t1,t2]]——[[0,2],[2,1],[0,0]],然后对这个二维列表进行转置(便于后续统计),得到[[t1,t1,t1],[t2,t2,t2]]——-[[0,2,0],[2,1,0]]。其中[0,2,0]代表着各个课程价格,[2,1,0]代表各个课程的课时数。

而原问题可以等价于求在价格高、课时多的情况下,新课程销量分别为高、中、低的概率。即P(C|AB)=P(AB|C)P(C)/P(AB)=P(A|C)P(B|C)P(C)/P(AB)=》P(A|C)P(B|C)P(C),其中C有三种情况:c0=高,c1=中,c2=低。而最终需要比较P(c0|AB)、P(c1|AB)和P(c2|AB)这三者的大小,又
P(c0|AB)=P(A|C0)P(B|C0)P(C0)=2/4*2/4*4/7=1/7
P(c1|AB)=P(A|C1)P(B|C1)P(C1)=0=0
P(c2|AB)=P(A|C2)P(B|C2)P(C2)=0=0
显然P(c0|AB)最大,即可预测这门新课的销量为高。

(2)、实现方式

跟KNN算法一样,贝叶斯算法也有两种实现方式,一种是详细的实现:

图片描述

图片描述

另一种是集成的实现方式:

图片描述

3、决策树算法

决策树算法是基于信息熵的理论去实现的,该算法的计算流程分为以下几个步骤:
(1)先计算总信息熵
(2)计算各个特征的信息熵
(3)计算E以及信息增益,E=总信息熵-信息增益,信息增益=总信息熵-E
(4)E如果越小,信息增益越大,不确定因素越小

决策树是指对于多特征的数据,对于第一个特征,是否考虑这个特征(0代表不考虑,1代表考虑)会形成一颗二叉树,然后对第二个特征也这么考虑…直到所有特征都考虑完,最终形成一颗决策树。如下图就是一颗决策树:

图片描述

决策树算法实现过程为:首先取出数据的类别,然后对数据转化描述的方式(例如将“是”转化成1,“否”转化成0),借助于sklearn中的DecisionTreeClassifier建立决策树,使用fit()方法进行数据训练,训练完成后直接使用predict()即可得到预测结果,最后使用export_graphviz进行决策树的可视化。具体实现过程如下图所示:

图片描述

4、逻辑回归算法

逻辑回归算法是借助于线性回归的原理来实现的。假如存在一个线性回归函数:y=a1x1+a2x2+a3x3+…+anxn+b,其中x1到xn代表的是各个特征,虽然可以用这条直线去拟合它,但是由于y范围太大,导致其鲁棒性太差。若想实现分类,需要缩小y的范围到一定的空间内,如[0,1]。这时候通过换元法可以实现y范围的缩小:
令y=ln(p/(1-p))
那么:e^y=e^(ln(p/(1-p)))
=> e^y=p/(1-p)
=>e^y*(1-p)=p => e^y-p*e^y=p
=> e^y=p(1+e^y)
=> p=e^y/(1+e^y)
=> p属于[0,1]

这样y就降低了范围,从而实现了精准分类,进而实现逻辑回归。

逻辑回归算法对应的实现过程如下图所示:

图片描述

5、SVM算法

SVM算法是一种精准分类的算法,但是其可解释性并不强。它可以将低维空间线性不可分的问题,变为高位空间上的线性可分。SVM算法的使用十分简单,直接导入SVC,然后训练模型,并进行预测。具体操作如下:

图片描述

尽管实现非常简单,然而该算法的关键却在于如何选择核函数。核函数可分为以下几类,各个核函数也适用于不同的情况:
(1)线性核函数
(2)多项式核函数
(3)径向基核函数
(4)Sigmoid核函数
对于不是特别复杂的数据,可以采用线性核函数或者多项式核函数。对于复杂的数据,则采用径向基核函数。采用各个核函数绘制的图像如下图所示:

图片描述

5、Adaboost算法

假如有一个单层决策树的算法,它是一种弱分类算法(准确率很低的算法)。如果想对这个弱分类器进行加强,可以使用boost的思想去实现,比如使用Adaboost算法,即进行多次的迭代,每次都赋予不同的权重,同时进行错误率的计算并调整权重,最终形成一个综合的结果。

Adaboost算法一般不单独使用,而是组合使用,来加强那些弱分类的算法。

五、分类算法的选择思路与技巧

首先看是二分类还是多分类问题,如果是二分类问题,一般这些算法都可以使用;如果是多分类问题,则可以使用KNN和贝叶斯算法。其次看是否要求高可解释性,如果要求高可解释性,则不能使用SVM算法。再看训练样本数量、再看训练样本数量,如果训练样本的数量太大,则不适合使用KNN算法。最后看是否需要进行弱-强算法改造,如果需要则使用Adaboost算法,否则不使用Adaboost算法。如果不确定,可以选择部分数据进行验证,并进行模型评价(耗时和准确率)。

综上所述,可以总结出各个分类算法的优缺点为:
KNN:多分类,惰性调用,不宜训练数据过大
贝叶斯:多分类,计算量较大,特征间不能相关
决策树算法:二分类,可解释性非常好
逻辑回归算法:二分类,特征之间是否具有关联无所谓
SVM算法:二分类,效果比较不错,但可解释性欠缺
Adaboost算法:适用于对弱分类算法进行加强

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258931

让影视后期在线制作不是问题 Ultrastar® Data60 存储平台取代SAN,实现存储容量的升级

图片描述点击进入
Ultrastar® Data60存储平台采用高密度、可扩展且经济高效的设计,在 4U 机架中装有 60 个 Ultrastar® 3.5 英寸企业级硬盘模块。它提供了 2 × 2 × 4 通道 SAS 12Gb/s 性能、高可用性(HA)和热插拔组件。西部数据公司是硬盘和闪存生产商,品质、可靠度和性价比已得到影视行业客户的一致好评和认同。香港天极影视集团最近也使用了Ultrastar® Data60存储平台解决方案,为负责处理影视节目调色、母片后期处理(mastering) 及文件格式转换(File conversion)的部门赋予新的价值体验。
 关于香港天极影视集团(Digital Magic)
香港天极影视集团自1978成立, 提供影视服务于香港, 大中华, 亚洲, 美洲及世界各地。并与世界各地合作, 为创作者提供各种影视前、 后期制作,内容演出的服务。
包括:
A) 国际外联合拍及摄影器材租赁。含2D, 3D立体, VR, 环幕及航拍摄影系统
B) 电影影视及广告后期制作, 电影修复及调色, 动画特效及音效制作
C) 2D/3D数字影院, 新媒体,2D转3D,裸视3D, 装配各大型环幕及大型高解像展览视听展厅工程及内容制作
D) 电影数字媒体后期, 3D电影后期,VR后期, 电影再版修订, 数字电影的DCP/DCDM改版及KDM世界发行, 电影胶卷数字扫瞄及35MM胶卷输出
E) 8K/6K数字摄影机及3D立体器材销售,大型活动影视技术工程及器材租赁,展厅及工作室的工程整合, 影视技术培训, 高级影像项目技术顾问工作。
图片描述
 目前的存储架构状况:
香港天极影视集团旗下的天极数码 (Digital Magic Ltd.)主要从事高清电视及电影后期制作。专门负责影视节目调色、母片后期处理(mastering) 及文件格式转换(File conversion)的部门目前资料存储架构如下:
• 共享存储方式:SAN (FC: 8Gb/sec)
• SAN 交换机连接:SAN存储数组,1 x data server,1 x Metadata server, 4 x工作站 (1 台用作调色,其余用作mastering及格式转换)。
• 传输速率要求:调色工作站 – 约1000 MB/sec, 其余 3 台工作站约 400MB/sec,
• 操作系统环境: Mac及 PC
目前来看,SAN的传输速度已经开始跟不上业务和数据量的增长,急需对其进行升级。为解决这个问题,公司使用thunderbolt 3.0接口的G-Drive存储装置来连接工作站以减轻SAN的压力。借助于Thunderbolt3.0接口高达1500MB/s的传输速度,解决了传输速度的问题。但是通过DAS连接的这种方式,产生了新的问题:不能共享存储和存储装置的单点故障风险。
 挑战及需求:
现在的影视制作素材量大,制作时间紧迫,加上影视作品的清晰度越来越高,从目前的4K 很快会变成 8K, 如果仅仅通过 DAS 单机制作,而没有一套专业的共享存储系统无法应付日益繁重的工作。为此,天极数码希望建立一套能符合以下要求的存储系统:
1. 能满足存储资源共享及系统分工的要求
2. 极强的扩容性能应付未来3年的业务发展需要
3. 传输速率能满足不同工序的需求
4. 超低的成本
5. 能够在不同的工作平台上共享资源

 解决方案:
图片描述
采用 HGST Ultrastar® Data60 存储平台,并结合微软 Window Server 2012 R2 的 Storage Space 技术,软件定义存储(Software-Defined Storage ,SDS)功能来组建一个多机共享的虚拟集中存储。
工作站通过 10 GbE 或 25 GbE 高速网络连接服务器。有需要的话,可采用 SMB 3.0 的 multi-channel 功能以增加工作站与存储空间的链路速度。

 方案的优点:
• 超高的扩容性 – 一台 Ultrastar Data60存储平台最高可安装 60 x 12TB 硬盘;最高存储量可达 720TB。可以使用菊链 (daisy-chain) 方式串联 4 台 Ultrastar Data60。
• Ultrastar Data60 使用热插入组件 — 双电源(带集成风扇)、硬盘模块和 IO 模块
• 超高传输速度 – 每台 HGST Ultrastar Data60存储平台最高可提供 12个 12×4 mini-SAS HD端口。每台服务器可以有 12 x 4 x 12Gbps 的传输速度。通过高速网络并配合 SMB 3.0 的 multi-channel 功能可以确保工作站与存储空间的传输速度。
• Ultrastar Data60存储平台可混合安装 SSD (最多安装 24 x 6.4TB SSD)及传统硬盘以实现分层存储。
使用Windows Server 2012 R2 SDS或 Window Server 2016 R2 的 S2D (Storage Spaces Direct) 可以达到以下功能:
• 基本的存储虚拟化及管理
• 保护数据 – 通过使用快照和故障转移能力支持存储可用性。存储空间使用数据分段(RAID 0)方式,数据以段方式放在不同的硬盘,整个数组的各个硬盘可同时作读写,从而提高硬盘性能。当硬盘发生问题,可通过备用的存储空间进行重建。定期的后台扫描可以先发制人地检查和纠正硬盘问题,从而增强数据完整性。
• 存储分层 (Tiered Storage)- 允许存储空间使用磁性或固态介质创建虚拟硬盘,然后将数据传送到最适合数据使用模式的介质。例如,经常访问的数据可以动态地定位到一个SSD热存储层,而较少访问的数据定位到使用SAS HDD标准的冷存储层。数据也可以根据数据访问模式的变化而改变存放位置。IT或存储管理员也可以直接将数据放置所需的存储分层。

 HGST Ultrastar 60存储平台简介:
Ultrastar Data60存储平台是下一代分离式存储(disaggregated storage) 及软件定义存储 (SDS) 的主要组成单元。它提供的高密度存储容量及高超的灵活性实现了性能和成本的最佳平衡。
• 高密度存储容量 – 一台可以安装 60 x HGST HelioSeal® HDD,在4U 机箱内提供高达 720TB 的数据储存量
• 灵活性 – 配备 SAS 或 SATA 接口,并提供高达 24 个 SSD 槽位单元以实现数据加速分层管理
• 创新性 – 专利的IsoVibe™ 及 ArcticFlow™ 技术有效地提高性能及散热

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258933

三未信安再度亮相美国RSA 大会

RSA信息安全大会是目前世界上最大的安全会议之一,已连续举办27届。2018年度会议,于4月16日-20日在美国旧金山莫斯康会议中心举行。大会对全球信息安全建设起着重要的促进作用,它提供了安全市场中竞争对手、合作伙伴、客户以及安全社区联系的最佳机会。
图片描述

随着中国信息安全企业的崛起,越来越多的中国企业开始走出国门,走上世界舞台,展示来自中国的安全力量。北京三未信安科技发展有限公司(以下简称三未信安)作为国内知名的密码产品和数据安全解决方案提供商,再度参加大会,展示了高速密码卡、云密码机、密钥管理系统、数据加密方案等最新产品及服务。

三未信安致力于信息安全领域,专注于加密技术,为PKI应用,金融安全,数据保护和云安全领域提供卓越的产品和解决方案。近年来,三未信安不断加强全球化战略部署,产品进行了FIPS 140-2 level3认证,并通过了Bureau Veritas、欧盟CE等一系列国际认证;公司加入了CSA、OASIS等国际化标准组织;逐步开拓国际市场,并已与诸多全球知名企业展开了深入合作,率先成为外企在华拓展的优质服务商。在此次参展RSA 2018的中国企业中,三未信安是国内唯一的HSM(密码设备)厂商,公司也借助本次大会平台,宣传了中国的SMx系列国密算法。

立足中国、走向全球,一直是三未信安的目标和方向。依托自主创新的雄厚技术实力,三未信安将快速推进全球化战略,争做国际知名的信息安全企业。

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258934

融合非负矩阵分解和图全变分的歌曲推荐算法

摘要: Kirell Benzi, Vassilis Kalofolias, Xavier Bresson and Pierre Vandergheynst Signal Processing Laboratory 2 (LTS2), Swiss Federal Institute of Technology (EPFL)

Kirell Benzi,

Vassilis Kalofolias,

Xavier Bresson and Pierre Vandergheynst

Signal Processing Laboratory 2 (LTS2),

Swiss Federal Institute of Technology (EPFL)

代码参见:https://github.com/hxsylzpf/recog

摘 要

本文正式地形式化一个全新的的歌曲推荐算法,其将歌曲推荐的问题转化为矩阵补全的问题来考虑,并通过基于非负矩阵分解(non-negative matrix factorization, NMF)的协同过滤算法以及图上的结合图的全变分(total variation, TV)的基于内容的过滤方法相结合来解决这个问题。相关的图通过使用音频、元数据以及社交特征等丰富的信息的结合,对歌单的邻接信息以及歌曲的相似度信息进行编码。我们证明,我们提出的这个融合了几种知名的方法的混合推荐系统,有着广阔的应用前景,并在效果上超过融合的相关算法。通过在真实数据上进行的实验,我们证实了我们的模型能仅仅根据低秩矩阵的信息或者基于图的信息以及两者的结合进行歌曲的推荐。

关键字:推荐系统,图,非负矩阵分解,全变分,音频特征

一 引言

在 Netflix上推荐电影,在Facebook上推荐好友,或者在LinkedIn上推荐工作等任务在过去几年中吸引了越来越多的关注。大部分Netflix奖的获得者喜爱用的著名的低秩矩阵分解算法需要明确的用户评级作为输入。一些其他相似的方法则通过用户对物品的操作来反映用户对物品的偏好,以致力于解决用户的不明确的反馈问题。具体到歌曲和歌单推荐问题,也已经有了各种不同的方法,其中既有单纯的基于内容的方法,也有各种混合的模型。最近,图的正则化被提出,用来提高矩阵补全算法的效果。

本文的主要贡献在以下几个方面:

l 设计并实现了一个数学上的融合协同过滤以及内容过滤的声音混合系统;

l 介绍了一个新的图正则化项(TV),在推荐系统的背景下,其效果要优于广泛应用的 Tikhonov 正则化;

l 一个良好定义的基于近端分裂方法的迭代优化模式。

大量的实验证明我们提出的推荐系统具有很好的表现。

二 本文的歌曲推荐算法

1. 歌曲推荐算法

假设我们有n个歌单,每个列表都包含m首歌中的其中一部分。我们定义矩阵C∈{0,1}n×m,矩阵中的元素 Cij 为 1 则表示歌单 i 中包含歌曲 j,否则为 0。我们再定义一个权重矩阵Ω∈{0,1}n×m,当输入的 Cij 可能为 1 时,Ωij=1,否则等于一个很小的值 ε(我们使用的 ε=0.1)。这里应用了不明确反馈问题的思路。在矩阵 C 中一个元素为 0 不代表这首歌与这个歌单无关,而是更可能不相关。

训练阶段的目标是找到一个近似的低秩表示,使AB ≈ C,其中A ∈ R+n×r,B ∈R+r×m都是非负的,且 r 很小。这个问题被称为非负矩阵分解(NMF),并引起了广泛的关注。相比其他的矩阵分解方法,NMF 由于只使用了加性因子,能够学习到物体(本文中即为歌单)的各个部分。NMF 的方法的缺点是其为 NP-hard。所以对于找到一个局部最小点来说正则化使很重要的。在我们的问题中,我们使用歌曲和歌单的图来确定因子 A 和 B。我们模型的公式计算如下:

          (1)

其中(∘)代表点级别的乘法运算符,θA, θB∈R+。我们使用一个加权 KL 散度作为 C 和 AB 之间距离的衡量,有研究表明对于不同的 NMF 设置,这比Frobenius 范式更为准确。公式中的第二项是歌单图中 A 的行的全变分,所以对其进行惩罚就提升了分段恒定信号。公式中的第三项与第二项类似,是 B 的列的全变分。最终我们提出的模型利用了参考文献[9, 16],并利用 TV 半范式将其扩展到图。

1.1 利用全变分进行图的正则化

在我们基于 NMF 的推荐系统中,每个歌单 i 都被矩阵 A 中的第 i 行 Ai 投影到一个低维空间。为了学习到歌单 Ai 的低秩的表示,我们通过歌单的低秩表示,定义歌单之间成对的相似度ωAii’。我们可以从 TV 正则化项的定义中推导出,

‖A‖TVA= ∑i∑i’~ iωAii’‖Ai-Ai’‖1所以当两个歌单 i 和 i’是相似的,那么它们在图中则是连通的,且连接这两个歌单的边的权值ωAii’很大(这里ωAii’≈ 1)。另外,相应的低维向量表示(Ai,Ai’)间的距离过大就会被惩罚,这使得在低维空间中,(Ai,Ai’)的距离会保持较近。同理,每首歌 j 都由矩阵 B 中的一列 Bj 表示到一个低维空间。如果两首歌(j,j’)很接近(ωBii’′≈ 1),那么(Bj,Bj’)以及图的正则化‖B‖则遵循上述的规律。

参考文献[10]的思路与本文相似,通过 Tikhonov 正则化将图的信息引入到模型中,例如通过 Dirichlet 能量项1/2∑i∑i’~ iωAii’‖Ai-Ai’‖22。然而这种方法促进了A 的列之间平滑的变化,而本文的方法图的 TV 项的惩罚则促进了在列 Ai 和 Ai’间具有潜在的突变边缘的分段恒定信号。这对于需要寻找多个类别的任务是有益的,例如聚类,或者本文中的推荐系统所涉及的相似歌单属于不同的目录的情况。

我们在第 4 部分会详细分析,歌曲和歌单的图的使用可以显著的提升推荐效果,且 TV 项的表现要比 Tikhonov 正则化更好。

1.2 原始-对偶优化

对于矩阵 A 和 B 来说,优化问题是全局非凸,但是各自凸的。一个常用的方法是固定 A 去优化 B,然后再固定 B 去优化 A,反复直到收敛。我们这里以固定 A 而优化 B 为例来描述上述优化方法。相同的方法可以在固定 B 时应用于A。我们将上述问题重新写为如下形式:

F(AB) + G(KBB) (2)

其中

F(AB)=KL(Ω∘(C‖AB)) =(−ΩijCij(log)+Ωij(AB)ij (3)

             (4)

其中KB∈Rne×m是图的梯度算子,ne 是图 B 中的边的条数。使用函数 F 和G 的共轭函数 F*和 G*,则等价于鞍点问题:

           (5)

其中Y1 ∈ Rn×m,Y2 ∈ Rne×r。我们定义最近项和时间间隔 σ1,σ2,τ1,τ2:

           (6)

迭代的方式是,当 k≥0 时:

     Y1K+1 = proxσ1F∗(Y1K+ σ1ABK)                  (7)

Y2K+1 = proxσ2G∗(Y2K+ σ2KBBK) (8)

BK+1=(BK-τ1ATY1K+1-(KTBY2K+1)T)+ (9)

其中 prox 是最近算子,(∙)+ = max(∙, 0)。在我们的问题中,我们选择了标准Arrow-Hurwicz 时间间隔σ1 =τ1 = 1⁄‖A‖,σ2 =τ2 = 1⁄‖K‖,其中‖∙‖是算子范数。

则最近解为:

      (10)

其中 shrink 即为软缩减算子。注意到,同样的算法也可以应用于 Tikhonov正则化,例如,通过将上面的第一个式子改为proxσ2G*(Y)=Y,就可以将‖KBB‖1替换为G(KB B) = ‖KBB‖22。在式(10)中的正则化使用的是 KL 散度的一个对称变形,但是与我们使用的这种方法不同的是,Tikhonov 正则化不存在解析解。所以其目标函数并不像我们的一样满足一个有效的原始-对偶优化方法。我们保留这种非对称的 KL 模型,并称其为 GNMF,来将 TV 与 Tikhonov 正则化进行比较。

1.3 推荐歌曲

我们通过式(1)学到矩阵 A 和 B 之后,我们希望已知一些歌曲 cin 时(如图 1-1),能够推荐新的歌单 crec。我们也希望能实现实时的推荐,于是我们定义一个快速推荐

给定一些歌曲 cin,我们先通过解决一个正则最小平方问题来在歌单的低秩空间学习一个好的表示:ain=arg min a∈R1×r||Ωin。(cin-aB)||22+ε||a||22。其解析解ain=(BTΩinB+εI)-1(BTΩincin)当 r 很小时较容易计算(我们令ε = 0.01)。

与给定的歌单有相似表示的歌单也对于我们推荐歌单有益。所以在低维空间中,我们用加权和arec=Σni=1ωiAi/Σni=1ωi来表示被推荐的歌单。这里权重ωi=e-||ain-Ai||22/σ2, 取 决 于 与 其 他 歌 单 的 表 示 的 距 离ain, 且 σ =mean({||ain-Ai||2}ni=1)/4。最终推荐歌单的低秩表示为:

crec=arecB (11)

这里crec并不是二元的,而是一个连续的值,表示歌的排名。

2.歌曲和歌单的图

2.1 歌单的图

歌单的图中包含了歌单间成对的相似度信息。图的节点为歌单,边的权重表示了两个歌单之间的距离,当权重很大时(ωAii’ ≈ 1),表示两个歌单具有很高的相似度。在我们的模型中,歌单图中边的权重的计算不仅与外部信息例如元数据有关,还与内部信息有关,例如歌单中的歌曲信息。我们使用预定义好的 Art of the Mix 歌单分类来标注用户的歌单。则歌单的图中边的权重的计算定义为

        ωAii’=Υ1δcat{i}=cat{i’}+Υ2simcos(Ci,Ci’)

其中 cat 表示歌单的标签,Ci是矩阵 C 的第 i 行simcos(p,q)=

pTq/||p||.||q||是两个歌单的歌曲向量之间的余弦相似度距离。余弦相似度为两首歌相似的比例比上两个歌单长度乘积的均方根。两个正的参数Υ1和Υ2满足Υ1 + Υ2 = 1,用于决定歌单标签的相似度和歌单元素级别的相似度之间的相对重要程度。为了控制每个分类的边缘概率密度并让我们的模型更灵活,我们在同一个分类的节点之间保留 20%的边的一个子集。在实验中我们发现,令Υ2 = 0.3能获得较好的效果。 歌单图的效果通过使用标准 Louvain 方法对图进行分割进行衡量。分块的数目由在模块最大的地方切开形成的模块化系数的树图自动给出。第 4 节使用的图的模块化系数在使用只余弦相似度(Υ2 = 0)时为 0.63。如果我们加入元数据的信息,将每个分类下所有歌单对中的 20%进行连接,并令Υ2 = 0.3,则模块化系数增长到 0.82。

2.2 歌曲的图

我们模型中使用的第二个图是歌曲的相似度图。歌曲的图由从音频信号中抽取的 Echonest 特征与元数据信息结合以及音轨的社会信息混合组成。表 2-1 给出了用于构建歌曲图所使用到的特征。

为了提高我们的音频特征的质量,我们使用从 LastFm 相关标签中抽取的歌曲类型训练了一个大间隔最近邻模型(Large Margin Nearest Neighbors,LMNN)。为了抽取到真实的音乐类型,我们使用了这些标签经过其流行度(根据 LastFm)加权的 Levenshtein 距离以及 ID3 标签中定义的音乐类型。 最终,我们用 k 近邻(k=5)来构建歌曲的图,其中,对于 j 的 k 个最近邻中的一首歌 j’,两首歌 j 和 j’之间的边的权重ωBjj’=exp(-||xj-xj’||1/σ),参数σ是尺度参数,表示 k 个邻居之间距离的平均值。得到的图的模块化系数很高(0.64),使用 k-NN 进行非监督的准确率为 65%左右。

3. 实验结果

在这部分,我们通过在一个真实数据集上进行实验,将我们的模型与其他 3个不同的推荐系统进行比较。我们的测试数据集是从由 McFee 等构建 的 Art of the Mix 语料库中抽取的。我们之前就是在这个数据库中抽取了上述的特征。 评价一个音乐推荐系统是一个众所周知的难题。在本文中,我们使用一个经典的评价使用间接反馈的推荐系统的模型的方法,Mean percentage Ranking(MPR)以及歌单分类准确度,即在查询的分类中,过去已经出现过的歌单中的歌曲的百分比。

3.1 模型

我们先将我们的模型与一个只基于图的方法(我们称为 Cosine only)进行比较。对于给定输入,这个模型使用余弦相似度计算 t 个最接近的歌单(这里 t=50),通过将歌单中的所有歌曲用余弦相似度进行加权从而计算出一个柱状图进行推荐,如式(11)所示。第二个模型是使用了 KL 散度的 NMF,我们成为 NMF。最后一个模型 GNMF 是基于使用了 Tikhonov 正则化的 KL 散度,并应用了我们模型中的图。

3.2 查询

我们用 3 种不同的查询来测试我们的模型。在所有 3 种查询中,一个查询ctest包含 s=3 首歌作为输入,系统以一个歌单的形式返回最相近的 k=30 首歌作为输出。第一种查询为随机查询,从所有类别的歌中随机选择歌曲,其结果仅作为比较的基准。第二种测试查询,在测试集中的一个歌单中随机选择 3 首歌。第三种采样查询,在一个类别下随机选择 3 首歌。这种查询模拟了用户通过歌曲类别查询歌单的推荐系统。

3.3 训练

我们使用从所有歌单中随机选择出 70%的子集作为训练集,由于我们的模型不是联合凸的,初始化可能会对系统的表现产生影响,所以我们使用现在常用的 NNDSVD 技术来得到一个好的近似解。在我们的所有实验中,r=15 的结果很好,这意味着每行都有 5-20 个非零元素。最好的参数θA = 18以及θB= 1使用了网格搜索的方法。为了防止过拟合,我们在验证集的 MPR 刚停止增长的时候就使用提前停止的方法。

3.4 验证集

我们通过人工的在不用的歌单类别中进行查询的方法来构建验证集中的歌单。对于每个类别,我们在之前已经在用户创建的标注了类别的歌单中出现的歌曲中随机的选择 s=3 首歌。

3.5 结果

模型的结果,即不同模型的歌单分类准确率和 MPR 我们列在表 3-1 和表 3-2 中。如我们所预料的,对于随机查询,所有的模型都不能根据输入的歌曲返回歌单,而且使用了协同滤波同时没有假如图信息的 NMF 表现很差。这可以理解为是数据集的稀疏性造成的,数据集每行只含有 5-20 个非零元素,稀疏度只有 0.11-0.46%。协同过滤模型在有越多的观察到的等级时的表现越好,cosine 模型在类别准确率上表现更好,因为它直接使用了输入歌曲和歌单之间的余弦距离。然而,它的 MPR 说明即使状况很复杂,我们的模型在歌曲推荐时表现的更好。

4. 结论

在这篇论文中我们介绍了一个新的灵活的歌曲推荐系统,这个系统结合了歌单的协同过滤信息以及图中包含的歌曲相似度信息。我们使用一个基于原始-对偶的优化模式来得到一个高度并行的、可以用来处理大型数据集的算法。我们选择图的 TV 而不是 Tikhonov 正则化,并通过将我们的系统与 3 个不同的算法在真实的音乐歌单数据集上做比较,展示了我们模型的良好的实验效果。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258928

阿里云Redis混合存储典型场景:如何轻松搭建视频直播间系统

摘要: 本文主要介绍视频直播间系统,以及如何使用阿里云Redis混合存储实例方便快捷的构建大数据量,低延迟的视频直播间服务。

背景

视频直播间作为直播系统对外的表现形式,在整个系统中处于核心地位。通常除了视频直播窗口外,直播间还包含在线用户,礼物,评论,点赞,排行榜等信息。直播间消息,时效性高,互动性强,对系统时延有着非常高的要求,非常适合使用Redis等缓存服务来处理。

直播信息

实时排行信息

实时排行信息包含直播间在线用户列表,各种礼物排行榜,弹幕消息(可以理解为按消息维度的消息排行榜)等信息,适合使用Redis中的SortedSet结构进行存储。

例如,以unix timestamp+毫秒数为分值,记录user55的直播间增加的5条弹幕

redis> ZADD user55:_danmu 1523959031601166 message111111111111
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959031601266 message222222222222
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959088894232 message33333
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959090390160 message444444
(integer) 1
11.160.24.14:3003> ZADD user55:_danmu 1523959092951218 message5555
(integer) 1

返回最新的3条弹幕信息:

redis> ZREVRANGEBYSCORE user55:_danmu +inf -inf LIMIT 0 3
1) "message5555"
2) "message444444"
3) "message33333"

返回指定时间段内的3条弹幕信息:

redis> ZREVRANGEBYSCORE user55:_danmu 1523959088894232 -inf LIMIT 0 3
1) "message33333"
2) "message222222222222"
3) "message111111111111"

计数类信息

计数类信息以用户维度为例,有未读消息数,关注数,粉丝数,经验值等等。这类消息适合以Redis中的Hash结构进行存储。

redis> HSET user:55 follower 5
(integer) 1
redis> HINCRBY user:55 follower 1 //关注数+1
(integer) 6 
redis> HGETALL user:55
1) "follow"
2) "6"

时间线信息

时间线信息是以时间为维度的信息列表,典型的比如主播动态,新帖。这类信息排序方式是固定的时间顺序,可以考虑使用List或者SortedSet来存储。

redis> LPUSH user:55_recent_activitiy  '{datetime:201804112010,type:publish,title:开播啦,content:加油}'
(integer) 1
redis> LPUSH user:55_recent_activitiy '{datetime:201804131910,type:publish,title:请假,content:抱歉,今天有事鸽一天}'
(integer) 2
redis> LRANGE user:55_recent_activitiy 0 10
1) "{datetime:201804131910,type:publish,title:\xe8\xaf\xb7\xe5\x81\x87\",content:\xe6\x8a\xb1\xe6\xad\x89\xef\xbc\x8c\xe4\xbb\x8a\xe5\xa4\xa9\xe6\x9c\x89\xe4\xba\x8b\xe9\xb8\xbd\xe4\xb8\x80\xe5\xa4\xa9}"
2) "{datetime:201804112010,type:publish,title:\xe5\xbc\x80\xe6\x92\xad\xe5\x95\xa6,content:\xe5\x8a\xa0\xe6\xb2\xb9}"

阿里云Redis优势

  • 阿里云主从版Redis提供10万的QPS,读写分离版本Redis提供60万QPS最大力度支持系统的高并发需求。
  • 资深专家团队深度开发维护Redis源码,经千万服务考验,超高稳定性和安全性。
  • 双机热备架构,故障秒级自动迁移,全力保障订单数据。
  • 一键创建,一键扩容,全方位智能监控运维平台。请求量,活跃度一眼就能看清。
  • 专业服务团队,实时监控可用性,7 x 24小时在线咨询。

使用Redis混合存储实例存储信息

阿里云Redis混合存储产品完全兼容Redis协议,用户无需修改任何代码,以低成本的NVMe盘存储不常访问的直播间数据,可以突破内存容量限制,单实例最高可支持TB级别的数据容量。

图片描述

  1. 当Redis混合存储实例内存可以存储所有直播间数据时,访问所有直播间数据均可享受极致性能。
  2. 当直播间数据越来越多,快要超过实例内存限制时,Redis混合存储实例会自动从访问频率,访问时间等维度选择冷门的直播间数据,后台将其Value存储到磁盘上;
  3. 热门直播间数据仍然保留在内存中,性能不受任何影响;
  4. 当访问到磁盘上的冷门直播间数据时,数据会自动从后台加载到内存中,所有IO操作都经过阿里云自研的新一代存储引擎Fusion Engine极致优化,4K数据加载速度在20us左右;
  5. 通过将部分冷数据存储到磁盘的方式,有效降低了用户成本并突破内存对单实例容量的限制。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258921

​2018 OpenInfra Days China 免费社区演讲征集已经开始!


图片描述

2018 OpenInfra Days China免费社区演讲征集已经开始!

OpenStack Days China是由一群热衷并专注于开源的中国志愿者为中国开源社区组织和举办的年度社区活动。近两年来,志愿者团队成功激起广泛关注,获得了中国各行各业和来自全球开源开发者社区的巨大支持。会议注册人数共计超过 1 万人,参与人数逾 7,000 名。今年,应行业用户建议,志愿者团队决定扩大会议范围,将与基础设施相关的所有开源项目都涵括在内,为中国用户打造一个全方位的开源盛会。因此,今年的大会也将以“OpenInfra Days China”的名称重新亮相。

在今年的OpenInfra Days China上,我们将关注最新开发趋势,支持信息共享,并围绕云、容器平台、边缘计算、人工智能和物联网等领域的多个基础设施相关开源项目展开热烈讨论。

为了让参会者获得更具价值的最佳应用实践,组委会针对OpenStack以及相关云计算项目的热点与趋势,设置了两天总计45场的免费社区分享环节,现向全社会公开征集。

演讲嘉宾征集要求

壹:演讲时长:30分钟,包括Q&A环节

贰:征集议题标准

议题方向:符合大会专题方向,议题需要观点明确,内容新颖,让听众有收获。
实践角度:演讲内容,需要以实践为出发。
内容深度:有深度的演讲稿被采纳的机会更高。
专业声誉:讲师本身的专业经验也会作为评审的参考标准。
没有广告:请不要再演讲时做任何形式的广告。
听众收益:让听众在您得演讲分享获得最大的收益是最重要的。

叁:Track设置


图片描述

肆:截止时间:北京时间2018年5月6日23:59

伍:征集流程

1、官网完整填写征集表格并提交,每个议题最多三个演讲者;
(点击原文进入官网:http://china.openinfradays.org/

2、OpenInfra Days China工作组审核;

3、2018年5月18日起回复征集结果;

4、征集通过者准备演讲PPT,并于2018年6月9日前提交大会工作组进行内容审核。

征集通过者将获得

1、获得OpenInfra Days China上台演讲的机会;

2、优先享有和所有讲师单独沟通的机会或陪同;

3、免费参加大会为演讲嘉宾组织的独享聚会及其他活动;

4、大会午餐;

5、温馨提醒:交通及住宿费用,需自理。

长按识别二维码进入快速报名通道!


图片描述

官网盛典即将开始,限量免费门票现已开放,商务赞助虚位以待!关于本次大会的具体日程和参会指南,欢迎访问2018 OpenInfra Days China官方网站:http://china.openinfradays.org/

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258912

阿里云与WPS深度合作,开放数据处理生态

摘要: 在3月28日举行的2018云栖大会-深圳峰会上,阿里云与金山办公达成深度合作,WPS在线预览与格式转换能力落地阿里云。标志着阿里云存储开放的数据湖体系不但面向计算引擎,还面向应用开放。

在3月28日举行的2018云栖大会-深圳峰会上,阿里云与金山办公达成深度合作,WPS在线预览与格式转换能力落地阿里云。

当前整个企业级数据管理市场面临着数字化转型,如何更好的管理数据、挖掘非结构化数据(专业文档、视频、图像等)的价值是当前企业需要解决的问题。阿里云作为驱动数字中国的核心力量,正与更多的合作伙伴一起来解决这些问题。

图片描述

金山WPS植根中国,拥有30年专注办公领域的经验积累,该项合作为阿里云上的客户提供业内顶尖的文档预览与转换能力。支持实时以及大规模批量文档转换,让办公类业务可以在云端预览文档,无需下载、浏览无痕,全面提升文档的安全性。此次合作改变了传统的软件授权售卖模式,与云结合为客户提供实时、按量软件能力售卖。可以更好服务企业网盘,在线教育,素材交易,即时聊天等领域。

文档处理能力的引入,帮助阿里云完善了针对大型企业数据管理市场的服务体系。

  • 在服务全球化方面:阿里云全球18个数据中心、全球节点无缝覆盖,受到了像新浪微博,映客,陌陌等大型移动互联网APP的青睐,使用阿里云存储向全世界提供服务。
  • 在数据安全性方面:支持客户端、服务端数据加密,客户自定义管理密钥,保护业务核心数据的访问安全。同时提供同城多机房容灾,跨地域数据备份能力,从容应对极端情况下的数据可靠性问题。
  • 在内容管理方面:通过WPS提供在线文档预览能力,同时支持提取文档内容。后续提供的文本检索、翻译等丰富管理能力能够为企业数据管理提供有力工具。

引入文档预览能力的底层依赖产品–对象存储OSS,已经不仅仅是“存储”。依托高性能的阿里云数据中心网络与丰富的开源计算系统,提供了方便、简单、经济的数据分析和加工能力。OSS是中国第一家被官方Hadoop社区接纳为缺省的对象存储文件系统。

此次合作落地,标志着阿里云存储开放的数据湖体系不但面向计算引擎,还面向应用开放。通过阿里云智能媒体管理产品,对象存储OSS面向视频处理应用,图像处理应用,文档处理应用开放了接入能力。目前通过智能媒体管理支持图像识别、人脸检测、视频截帧、图片处理、文档预览、文本检索等多项数据处理能力,为上层应用提供强有力的支持。

未来,阿里云将同更多的软件生态伙伴一起,通过丰富的计算和分析能力,一流的数据中心网络,以及高性能的数据访问,帮助企业用户充分挖掘数据价值。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258905

云HBase小组成功抢救某公司自建HBase集群,挽救30+T数据

摘要: 使用过开源HBase的人都知道,运维HBase是多么复杂的事情,集群大的时候,读写压力大,配置稍微不合理一点,就可能会出现集群状态不一致的情况,糟糕一点的直接导致入库、查询某个业务表不可用, 甚至集群运行不了。

概述

使用过开源HBase的人都知道,运维HBase是多么复杂的事情,集群大的时候,读写压力大,配置稍微不合理一点,就可能会出现集群状态不一致的情况,糟糕一点的直接导致入库、查询某个业务表不可用, 甚至集群运行不了。在早期0.9x版本的时候,HBase的修复工具还有一下bug,使得即使你懂得如何修复的情况下,依然需要多次重复运行命令,绕过那些不合理的修复逻辑,甚至有时候需要自己写代码预先修复某个步骤。

背景

上周五,某公司使用的某DataHup 大数据产品自建一个HBase集群挂了!整个集群有30+T 业务数据,是公司的数据中心,集群直接启动不了。他们也是经历了熬战一天一夜的情况下,依旧没有解决恢复,还曾有过重装集群重导数据念头。最后,通过钉钉HBase技术交流群找到群主——阿里云HBase的封神。随后其立即下达命令,临时成立 HBase抢救小分队,尽力最大的努力,使用最低风险的方式,抢救最完整的集群。
蹭蹭蹭,几个抢救队员集齐,开始救火。

图片描述

救火开始

虽然紧急,但是抢救工作不能乱,我们把救火过程主要分为几步:

图片描述

​1. 定位现象问题所在

首先与用户沟通现场环境情况,以及客户在出问题之前做过哪些重大操作,特别是一些特殊操作,平时没做过的。据用户描述已经远程观察了解到,用户使用开源的某DataHup自建了一个HBase集群, 存储公司的大量的业务,是公司的数据中心。集群有7个RegionServer、2个Master,32核256G的机器配置,业务数据量有30+T。HBase的master已经都挂了,两个RegionServer也挂了,用户使用过“重启大法”,依旧无法正常运行。
​寥寥几句没有更多信息,我们只能上集群开日志,打jstack,观察HBase运行流程为什么中断或者挂掉。

​首先我们先检查HDFS文件系统,fsck发现没有什么异常。其次开始检查HBase,把Debug日志打开,全部关闭HBase集群,为了便于观察现象,只启动一个Master和一个RegionServer。启动后,发现Master 因为fullscan meta表(master启动的一个流程)timeout Abort 终止了。观察meta region分配到的RegionServer也挂了,查看日志并没有异常,貌似是这个开源的DataHup 当RegionServer scan数据操作超时 会被manager kill掉的样子。打jstack发现,Master确实在等待fullscan meta完成,而接管meta region的RegionServer确实一直在忙着scan meta数据,确实有忙不过来超时了。按理说,扫描meta表应该很快的才对。

​检查发现HDFS的HBase meta表有1T多数据!!!进一步查看现象HFile的内容,发现了大量的Delete famly 的cell存在,而且很多是重复的,序列号(没有截图,想象一下)。问题现象定位了,用户使用这个系列的DataHup 的HBase生态时,有组件存在bug往hbase meta表写了大量的这些冗余的delete数据,导致hbase 启动时full scan meta卡着,最终导致整个集群无法正常启动运行服务。

2. 提出解决方案,评估风险

我们很快生成了两个相对较优的方案。第一个是使用离线compaction,把hbase meta表进行一次major compaction把多余的delete family删除,然后再重启即可。第二个方案是,直接移除meta 表的无用hfile, 逆向生成meta 表数据进行修复meta表即可。

第一个方案做离线compaction对集群来说没有什么风险,缺点是离线compaction并不快,因为meta表region只有一个,执行离线meta表compaction时只有一个task,非常的缓慢耗时。

第二个方案是逆向修复meta表信息。看似风险很大,其实实际操作起来,很多风险可以降低。我们可以备份好核心的元数据,只有就可以在恢复失败的时候,还原到原来修复手术的前状态。这样一来,这个修复过程也就风险极大降低了。

​​3. 开始实施

​秉着更安全风险更低的情况下,我们还是先选择了方案一,给meta表做离线major compaction的方案。但最终因为MapReduce和本地模式的compaction都太慢了,开始会oom,调整后,最终因meta的hfile checksum校验失败中断了。meta表的hfile都存在问题,那么这个compaction过程就不能正常进行了。

​我们开始选择方案二,和用户沟通风险后,开始制定操作步骤, 把这个方案的实施带来的风险尽可能降到最低。规避这个方案存在的风险,前提是懂得这个方案会有什么风险。下面我们来分析一下,如图:

图片描述

​可以看到,开源HBase的meta表,是可以逆向生成回来的,但是有可能不同的DataHup生产商可能会有一些额外的信息hack进meta表里,对于这部分信息,在开源的逆向生成过程中是不包含的,存在这个关系数据丢失。但是这些核心的业务数据都存在,只是hack的第三方关联信息不存在了。有人可能会问,会有哪些数据可能hack到这里呢?曾看到过某厂商会在meta表了多加一些额外的字段用来保存virtual hostname信息,还有一些将二级索引相关的信息会保存在tableinfo 文件那里。HBase的开发商越多,什么姿势都可能存在,这个就是可能的风险点。

​接下来我们开始实施,这个问题比较典型,用户的meta表里,有1T多的hfile 数据,检查hfile 发现几乎99%的hfile是delete famly相关的内容,我们就移除这些delete famly的hfile到备份目录,只留下一个正常数据的hfile,而这个hfile也仅仅有30M左右的数据。重启HBase后,正常运行。HBase一致性检查发现很幸运,没有坏文件,也没有丢失的tableinfo、regioninfo、hfile相关的block等。如果发现有文件丢失,corrupt hfile等等问题,逆向生成元数据的修复过程就可能会带来风险,但HBase集群核心业务数据依然可以完整挽救。

4. 用户再自己验证一下是否正常

通知用户验证集群运行,业务运行情况。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258915

技术干货!《阿里技术参考图册》发布,公开600页技术全景图

如果你不甘心一直在写增删改查,希望看到更广的技术世界,阿里技术团队重磅发布的《阿里技术参考图册》,总计600余页,现已开放下载,将为你呈现阿里技术全景,走进各个技术领域的世界。

图片描述

此书邀请了阿里多个重要部门的研究员、资深技术专家、资深算法专家参与撰写。内容分为研发篇、算法篇两册,全面展示了在超大规模的企业级应用需求下,阿里全新升级的大中台、小前台的技术组织架构,以及各个技术领域的突破及创新。

技无止境,阿里技术团队希望将经验分享给更多人。《阿里技术参考图册》现已开放下载,与业界同仁一起探索未来。

下载地址:
《阿里技术参考图册》(算法篇)下载:

https://102.alibaba.com/downloadFile.do?file=1523848064814/AliTech101_Algorithms.pdf

《阿里技术参考图册》(研发篇)下载:

https://102.alibaba.com/downloadFile.do?file=1523962960197/AliTech101_RD.pdf

温馨提醒:

1、每册约300页,30M左右,需一定下载时间,还请耐心耐心耐心等待

2、若导入较慢,请将地址复制到PC浏览器后下载

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258895

PGConfUS 2018 会议Day1速报

图片描述

4月16-20日,第七届Postgres Conference US大会(以下简称“PGConf US”)在美国纽约泽西城召开。PGConf US是美国最大的PostgreSQL教育和宣传平台,每届大会都将安排持续一个周的系列活动,包括培训、主题演讲及分组会议。中国PG分会代表一行赴美参与此次盛会,下面由瀚高软件研发工程师王亮为各位带来首日的会议速报。

图片描述


中国PG分会代表一行与Bruce Momjian合影

在当前企业级数据爆发性增长的环境下,对结构化数据的数据量也在不断的增长,以至简单的单机数据库系统已经难于适应。分布式的数据库系统越来越多地被使用,随之数据库的多节点高可用性也变成了数据库领域最热门的话题之一。

第一天的会议基本上都是围绕着PostgreSQL的多节点用来谈起的。可见多节点下的高可用正在成为数据未来的发展方向之一。其中比较重要的两个内容如下:

01 第一章节

Modern PostgreSQL High Availability

会场现场,来自oneGre的创始人之一Alvaro Hernandez和开发者Pablo González Doval交替进行演讲。

图片描述

Alvaro Hernandez认为当前很多的人对HA认识是错误的,或者说是过时的,甚至有些人认为stream replication就等同于HA。他给出了自己认为的真正的modern HA的概念如下图所示:

图片描述

演讲后半段对PostgreSQL的HA的一些关键配置参数做了实战性的讲解。

图片描述

在网络环境下,同步和异步模式各自面临的主要问题,需要根据自己的业务特点来进行选择。

图片描述

在HA配置中,实际上同时存在着同步和异步的机制,这个也是最大限度的避免上面所说的单纯同步或者异步模式所带来的问题,并且这些问题会随着网络中节点数量的增加而被扩大。PostgreSQL在做replication的时候支持同步反馈节点数量的配置,即只是对配置中的replica接收方进行同步确认,其他的节点的接收反馈会被忽略。

图片描述

PostgreSQL在客户端连接方面,并不支持任何cluster相关的参数,所以不能在客户端方面对PostgreSQL的网络拓扑结构做任何的知晓。

图片描述

在PostgreSQL版本中,客户端的连接请求中加入了多个节点的支持,并且还对每一个节点提供一个读写的说明参数。这里实际上就让客户端在一定程度上面对数据库的网络拓扑情况有了一些认知。

图片描述

在JDBC层面,同样的也提供了多个节点和每个节点的读写参数说明。

图片描述

另外还有一些其他的第三方软件也能够帮助提供一个多节点的能够负载均衡的方案,但是性能上面肯定会受到比较大的影响,这个需要根据各自的需求场景来进行选择。

图片描述

当然要想实现HA系统,自动化工具肯定是必须的,而且我们需要很多切换工作,需要很多的自动化工具来实现这些自动切换。此外固定的虚拟IP也是需要的,否者在切换了之后,原来角色的节点的IP也会改变,这样客户端还是知道的是老的IP,这样会产生很大的问题。

图片描述

在主节点发生故障的时候,我们需要一个STONITH电源管理设备,进行主节点离线处理,否者会有脑裂的后果。

图片描述

应用程序端需要支持对连接的重连,因为有时候正在处理请求的节点由于故障进行了切换,此时之前的连接已经不再存在,这是需要一个重连操作。

图片描述

由于逻辑复制的种种限制,不要在HA的环境中使用逻辑复制。

02 第二章节

Aurora PostgreSQL Tutorial and Extended Deep Dive

https://www.slideshare.net/AmazonWebServices/deep-dive-on-the-amazon-aurora-postgresqlcompatible-edition-dat402-reinvent-2017

图片描述


来自amazon web service 的James Finnerty对amazon的Aurora云数据库产品进行介绍和一部分技术深入。

Aurora数据库不同于现在普通的数据库cluster产品,普通的产品一般是每一个节点都各自拥有自己的存储系统,而Aurora提供了共享存储的节点组织模式,所有的数据库节点共享一份数据内容,这样做的基础实际上也依托了amazon发展了多年的强大的分布式存储平台,大部分关键的工作实际上都被底层文件系统所完成,上层数据库逻辑部分就可以采用更轻量级的方式来处理。

图片描述

图片描述

图片描述

上面三个slide实际上就是说明Aurora用更少的写操作来提升数据库系统的性能,实际上可以认为Aurora就是一个日志存储系统,他对数据的存储只涉及到WAL日志的部分,数据部分都会被底层的文件系统所涵盖。

图片描述

图片描述

Aurora在主节点(读写节点)更新数据的时候,首先更新自己的磁盘数据的日志,然后会使用异步通知的方式通知所有的只读节点,告诉哪一个数据发生了变化,只读节点接收到通知以后查看自己的缓存中是否已经有了该数据,如果没有,那么什么也不会被处理,如果有,那么就会把自己的内存中相应的这个数据换出,然后再从磁盘加载到新的主节点更新完的数据。

图片描述

实际上每一个节点自己还是对应了一个实体的文件系统,只是这个文件系统是一个分布式文件系统的镜像,在写入节点写入数据之后,更新的数据会很快的复制到每一个分布式节点上面。

图片描述

实际上每一个节点自己还是对应了一个实体的文件系统,只是这个文件系统是一个分布式文件系统的镜像,在写入节点写入数据之后,更新的数据会很快的复制到每一个分布式节点上面。

图片描述

图片描述

由于Aurora没有checkpoint机制,所以在vacuum的时候也不需要进行checkpointt操作,大大的提升了vacuum的性能。

03 第三章节

Mastering PostgreSQL Administration

来自 EnterpriseDB的Bruce Momjian进行的演讲,演讲内容主要集中在PostgreSQL的管理操作方面,基本上每一个主要的方面都有涉及,包括配置文件中重要的参数,关键的WAL日志机制,主备流复制机制,备份恢复机制等。因为内容非常详尽,并且演讲内容已经放到网上,可以通过如下地址进行访问:

https://momjian.us/main/writings/pgsql/administration.pdf

会议首日主要是培训课程,以下为主要培训的课程简介:

一、谷歌云上的高可用PostgreSQL和Kubernetes

来自Google公司的两位软件技术人员Alexis Guajardo和Gabi Ferrara,给大家培训了如何通过使用谷歌的 Kubernetes 引擎和Cloud SQL快速开发基于Web的应用程序,并了解容器化应用程序管理和托管数据库服务。 Kubernetes 引擎通过简化应用程序和服务的部署,更新和管理,实现快速应用程序开发和迭代。 Cloud SQL可以让用户轻松设置,管理和管理他们在Google云端平台上的Postgres数据库。这个研讨会将帮助您在开发模因发电机的同时提高您的技能。

二、精通PosgreSQL管理

来自于PG全球开发者组织的联合创始人和核心团队成员Bruce Momjian,1996年开始从事PG方面的工作,2006年受雇于EnterpriseDB(EDB)。他给PG管理员带来了PG管理相关的各个方面,包括:安装,安全,文件结构,配置,报表,备份,日常维护,活动监控,磁盘空间计算和容灾。还介绍了如何控制主机的连通性,配置服务器,查找每个会话执行的查询,和每个数据库使用的磁盘空间。

三、 深入研究PostgreSQL身份验证方法

EDB公司首席架构师Abbas Butt带来了关于PG的身份验证相关的培训,包括访问,授权,身份验证和日志记录,与认证相关的PostgreSQL配置,PAM认证,Kerberos身份验证、LDAP身份验证、RADIUS身份验证等各种认证及加密方式。

四、 Migrating to PostgreSQL 迁移至PosgreSQL

由OpenSCG的CTO Jim Mlodgenski讲解,Jim有着20年对于数据敏感型应用和基础构架的开发经验,在加盟OpenSCG之前,Jim是StormDB(PostgreSQL-XC扩展公有云的解决方案)的CEO,在StormDB期间,Jim负责产品设计和所有的开发工作。现在有很多关键任务数据库迁移到PostgreSQL,这个讲座主要讲授了如何识别差异以及如何成功迁移应用程序,并通过使用包含SCT和DMS以及一些开源工具及AWS工具链进行示例迁移。

五、Patroni管理PostgreSQL集群

来自德国电子商务公司Zalando两位技术人员Alexey Klyukin 和 Alexander Kukushkin对如何使用Patroni管理PG集群进行了培训。Patroni是一个小型的Python守护进程,可以让用户通过几个简单的步骤创建基于热备份和流式复制的高可用性PostgreSQL集群。

六、CockroachDB 基础

纽约的本地公司Cockroach Labs为大家提供了他们公司的产品CockroachDB的培训,包括CockroachDB的设计和架构,涵盖数据分发,分布式事务,地理复制以及部署和操作基础知识。CockroachDB是一个分布式SQL数据库,可以在云-本地环境中运行。 CockroachDB旨在为具有地理分布用户和混合部署的应用提供支持。


更多大会技术干货,敬请期待!

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258873

孙家广院士加盟昆仑数据,锁定首席战略顾问一职

近日,昆仑数据迎来了一位业内重量级大咖的加盟,即孙家广院士。

孙家广院士,作为软件工程与系统及其应用领域的专家,清华大学教授,国家863计划自动化领域专家委主任、首席科学家,1999年就当选为中国工程院院士。

作为中国第一批研究计算机图形学及CAD的专家,被誉为“国内三维设计第一人”,为推动我国制造业信息化、提升软件产业化能力做出了突出贡献。

同时,孙院士也是昆仑数据创始人&CEO陆薇博士,以及联合创始人&CTO王晨博士的博士生导师。

图片描述

从业数十年来,孙院士总能让人联想到如今互联网唯快不破的潮流下,具备更沉稳的心态来做工业才是最可贵的事儿!正式成为昆仑数据首席战略顾问的第一席讲话,更像是一个致力于孵化国产技术促进工业升级的前辈对晚辈们的谆谆教诲。

会上,陆薇首先对孙院士的支持与帮助表示了诚挚的感谢。

这方面,不论是着眼于个人职业生涯的转变,还是助力昆仑数据的更好向前发展,孙院士都在许多需要破冰的转折点上给予了默默的支持以及无私的指导以及帮助。

无论是公司经营战略还是发展方向,陆薇和王晨再忙也总会抽出时间回门拜师,与孙院士恳切沟通。

图片描述

孙家广院士虽然已经多次到访昆仑,但简短的受聘仪式还是让在场所有人感受到孙院士作为制造业升级的前辈对我们的殷切期望,其对中国制造业的情怀令人动容,现场气氛热烈!

仪式中间,他回忆了自己早年科研创业的经历。

当初国际CAD研究领域没有华人,他放弃了美国优越的环境回国开展研究,打破了国外自动化软件的垄断,并推动技术从实验室走向产业化的发展,也正是那个时候与国内众多制造企业结下了不解之缘,所以孙院士对昆仑数据的创业路感同身受。

孙院士加入昆仑数据担任首席战略顾问一职,一方面是对CEO陆薇、CTO王晨以及优秀创业团队的诚恳与投入的认可;另一方面更是因为工业大数据及工业互联网的发展将会对我国工业、对大国重器、对国计民生产生巨大而深远的影响。

会上,他极大肯定了昆仑数据的发展,顺应时代以及政府着力支持的方向,并鼓励昆仑数据与清华大学产学优势相结合。

图片描述

随着各地工业大数据创新中心的建立,昆仑数据的行业影响力正在逐步扩大,与各行业龙头的合作也在加深对垂直领域的渗透力。孙院士也同时表达了对昆仑数据日后更要加强核心产品和服务的竞争力,回馈给产业更多价值的期望。

俗话说,做人要与人为善,做企业就是要帮助客户成长,为其谋求长期价值,企业才有生存立足的根本,昆仑数据正是秉承这个路线不断向前迈进!

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258878

Kubernetes Ingress 高可靠部署最佳实践

摘要: 在Kubernetes集群中,Ingress作为集群流量接入层,Ingress的高可靠性显得尤为重要,今天我们主要探讨如何部署一套高性能高可靠的Ingress接入层。

简介

在Kubernetes集群中,Ingress是授权入站连接到达集群服务的规则集合,为您提供七层负载均衡能力,您可以通过 Ingress 配置提供外部可访问的 URL、负载均衡、SSL、基于名称的虚拟主机等。作为集群流量接入层,Ingress的高可靠性显得尤为重要,今天我们主要探讨如何部署一套高性能高可靠的Ingress接入层。

高可靠部署架构

高可靠性首先要解决的就是单点故障问题,一般常用的是采用多副本部署的方式,我们在Kubernetes集群中部署高可靠Ingress接入层同样采用多节点部署架构,同时由于Ingress作为集群流量接入口,建议采用独占Ingress节点的方式,以避免业务应用与Ingress服务发生资源争抢。

图片描述

如上述部署架构图,由多个独占Ingress实例组成统一接入层承载集群入口流量,同时可依据后端业务流量水平扩缩容Ingress节点。当然如果您前期的集群规模并不大,也可以采用将Ingress服务与业务应用混部的方式,但建议进行资源限制和隔离。

在阿里云容器服务集群中部署高可靠Ingress接入层

部署说明

图片描述

  • Ingress SLB:Ingress接入层前端SLB实例
  • Ingress Node:部署Ingress Pod的集群节点
  • Ingress Pod:Ingress服务实例

这三者之间依据标签node-role.kubernetes.io/ingress=true进行关联:

1.Ingress SLB后端只会挂载打标了node-role.kubernetes.io/ingress=true的集群Node;
2.Ingress Pod只会被部署到打标了node-role.kubernetes.io/ingress=true的集群Node;

开始部署

1、创建 Kubernetes 集群

在创建集群之前,我们需要依据自身具体业务场景来适当规划集群的规模以及集群内各节点角色,比如业务节点数、Ingress节点数等,注意集群默认会初始化3台Master节点来部署集群管控服务。
我们通过阿里云容器服务控制台创建一个Kubernetes集群,这里以创建3台Worker节点集群为例。

图片描述

2、打标 Ingress Node

由于测试集群规模较小,我们暂采用混部的方式:即3台Worker节点既作为业务节点又作为Ingress节点。我们给3台Worker节点同时打标node-role.kubernetes.io/ingress=true,注意不建议将Ingress Pod部署在集群Master节点上,因为Master节点承载着集群的所有管控服务,以避免集群接入流量过高时对管控服务造成影响。

 ~ kubectl label no cn-hangzhou.i-bp1ecwpuisra0y0bizdb node-role.kubernetes.io/ingress=true
node "cn-hangzhou.i-bp1ecwpuisra0y0bizdb" labeled
  ~ kubectl label no cn-hangzhou.i-bp1ecwpuisra0y0bizdc node-role.kubernetes.io/ingress=true
node "cn-hangzhou.i-bp1ecwpuisra0y0bizdc" labeled
  ~ kubectl label no cn-hangzhou.i-bp1ecwpuisra0y0bizdd node-role.kubernetes.io/ingress=true
node "cn-hangzhou.i-bp1ecwpuisra0y0bizdd" labeled
  ~ kubectl get no
NAME                                 STATUS    ROLES     AGE       VERSION
cn-hangzhou.i-bp11psgsvkxklfvb8vvj   Ready     master    1h        v1.9.3
cn-hangzhou.i-bp183t1a82uun0s12ddr   Ready     master    1h        v1.9.3
cn-hangzhou.i-bp1ecwpuisra0y0bizdb   Ready     ingress   56m       v1.9.3
cn-hangzhou.i-bp1ecwpuisra0y0bizdc   Ready     ingress   56m       v1.9.3
cn-hangzhou.i-bp1ecwpuisra0y0bizdd   Ready     ingress   57m       v1.9.3
cn-hangzhou.i-bp1gb2498ykvy23k0jsy   Ready     master    1h        v1.9.3

3、创建 Ingress 服务

集群初始化时默认部署了一个Ingress Controller,具体部署说明请参考。这里我们通过DaemonSet方式将其重新部署到目标Ingress Node上,当然您也可以采用Deployment配合亲和性方式来部署。

~ kubectl -n kube-system delete deploy nginx-ingress-controller
deployment "nginx-ingress-controller" deleted
  ~ kubectl create -f https://acs-k8s-ingress.oss-cn-hangzhou.aliyuncs.com/nginx-ingress-controller-ds.yml
daemonset "nginx-ingress-controller" created
  ~ kubectl -n kube-system get ds | grep nginx-ingress-controller
nginx-ingress-controller   3         3         3         3            3           node-role.kubernetes.io/ingress=true   42s
  ~ kubectl -n kube-system get pod -o wide | grep nginx-ingress-controller
nginx-ingress-controller-57j4l                               1/1       Running   0          1m        172.16.3.2        cn-hangzhou.i-bp1ecwpuisra0y0bizdd
nginx-ingress-controller-d7cxb                               1/1       Running   0          1m        172.16.5.7        cn-hangzhou.i-bp1ecwpuisra0y0bizdc
nginx-ingress-controller-m9w75                               1/1       Running   0          1m        172.16.4.2        cn-hangzhou.i-bp1ecwpuisra0y0bizdb

4、更新 Ingress SLB 服务

集群初始化时默认部署了一个Ingress LoadBalancer Service,具体部署说明请参考,这里需要更新下Ingress LoadBalancer Service,以自动识别挂载打标的Ingress Node。

  ~ kubectl apply -f https://acs-k8s-ingress.oss-cn-hangzhou.aliyuncs.com/nginx-ingress-slb-service.yml
service "nginx-ingress-lb" configured

5、此时具有3个Ingress实例的高可靠接入层部署完成。

快速扩容

随着您的业务流量不断增长,集群规模不断扩大,您只需要简单地通过打标的方式来快速扩容Ingress接入层。

全方位监控

集群Ingress接入层的监控是必不可少的,您可以通过阿里云容器服务监控以及阿里云云监控对Ingress Pod和Ingress Node进行全方位监控。

原文链接

阅读更多干货好文,请关注扫描以下二维码:
图片描述

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258813

家庭新“成员” 腾讯听听智能音箱发布

4月17日,备受行业和消费者关注的腾讯听听音箱正式向媒体揭开神秘面纱,并在京东商城开放预约。据了解,腾讯听听音箱将于4月20日正式上市,并将在腾讯听听官网、京东、苏宁、国美、平安银行、一条等线上线下全渠道首发销售。

图片描述

腾讯听听音箱以9420为唤醒词,主打家庭使用场景,致力于成为”全家人都爱听的智能音箱”,以高品质音质、丰富的内容资源、智能语音互动及可移动等特性满足家庭生活的多样化需求。

出色音质回归音箱本原

媒体品鉴会以音乐鉴赏开场,通过对不同类型音乐的盲听对比,腾讯听听音箱展示出堪比高端HI-FI音箱的音质效果。秉持着”打磨精品”的理念,腾讯听听音箱定位为千元档的产品,将音质作为音箱本质属性,通过高成本的选材及独创的自适应音效技术,凸显出色的音价比。

图片描述

据介绍,腾讯听听音箱采用对称式音腔结构,双全频扬声器与双无源辐射器分别水平对置,同箱体共同组成了一个全封闭的音腔,不仅避免了产生气流声失真,而且有效抑制音腔共振造成的音染,从而提高音乐解析力;双10W的全频扬声器单元可提供更大的音量和动态表现,在水平360度内具有较均匀的声学指向性,满足不同播放空间的同时,实现全角度无差别的音质效果。在选材方面,腾讯听听音箱采用高品质低失真的音频元件,并专门设计了开孔率极高的金属网罩,从上千种面料中挑选取北欧专业录音棚同款声学布料,提高声音还原度,确保音色自然,清晰耐听。

此外,腾讯听听音箱拥有QQ音乐高清正版音源,以独创的自适应音效技术和百余种音乐类型标签,突破了一般音箱单一音效的模式,在播放时可以根据音乐或内容的类型自动切换到合适的音效,无论流行、摇滚,还是古典、人声,都能带来极佳的音效体验。

以全家人使用场景切入市场

在互联网浪潮的席卷下,每个人都是科技创新发展的参与者。当前人工智能已经走入人们的日常生活,AI技术的落地及相关服务的应用也在不断提升人们的生活品质和效率。智能产品方便了人们的生活,但是大多数时候,也拉开了人们的距离。

图片描述

腾讯听听音箱TVC在媒体品鉴会上首发,讲述的是几个真实的家庭在使用音箱时用9420唤醒爱的故事。忙碌的现代人被互联网生活裹挟着前进,儿童成长在智能产品”电子保姆”的关怀下,而老人们也在努力的融入数字生活当中。没有时间表达,或者面对面说不出的爱,或许变成了微信里的一句问候或者一个表情。这也是腾讯听听音箱将”9420就是爱你”作为品牌主张的初衷,让它成为现代家庭传递情感、表达爱的一个媒介与工具,用一个全家人都爱的音箱,拉近家庭成员在时间和空间上的距离。

沿着腾讯”科技+文化”的发展思路,基于对智能硬件市场的思考,和对消费市场的洞察,腾讯听听音箱整合了腾讯多年来深耕的技术实力和海量的内容储备,旨在满足家庭每个成员的使用需求,让人生的每个阶段都更加美好。

不止AI,内容多,可移动,还能发微信

作为一款智能音箱,腾讯听听音箱是腾讯AI场景化、AI产品化的第一款硬件自研产品,是腾讯在AI硬件领域的一次的尝试。腾讯听听音箱也是背靠腾讯AILab的技术支持,语音系统是为音箱专属开发,同时也融合了腾讯云小微和腾讯叮当等内外部合作伙伴的先进技术和内容服务,落地腾讯品牌硬件产品。依托腾讯海量用户和服务经验,腾讯听听音箱能够更精准的洞察用户需求,在自然语义、语音交互等AI领域具备成熟的技术优势,并随着与用户的互动不断学习和成长。

图片描述

结合腾讯的社交和内容优势,腾讯听听音箱重点发力社交场景、内容场景和互联网服务场景的连接。腾讯听听音箱整合了腾讯内外部大量优质内容,包括QQ音乐、腾讯新闻、企鹅FM、阅文集团、喜马拉雅、工程师爸爸等超过1700万首音乐正版曲库,一百万个儿童故事,一亿小时的有声内容,特别包括老年人喜爱的评书、相声、戏曲等,覆盖了家庭生活的大部分场景,可以无缝对接用户多种内容需求。

为了实现多种使用场景的切换,腾讯听听音箱配置充电式锂电池,待机时长可达16小时,WIFI模式持续工作5小时,蓝牙模式持续工作6小时。腾讯听听音箱还是市场上首款采用SMARTLINK&AP双连接方式的智能音箱,联网效率、兼容性、回联率让用户操作简便易懂,同时支持蓝牙、WIFI双模式并存兼语音控制,用户可以自由切换便携使用。

图片描述

备受期待的微信功能,也是基于对家庭用户的洞察,针对老人和儿童手机使用频率低的场景而设置,微信群成员可以通过音箱收发微信留言,上班的父母可以和在家的宝贝远程聊天,在外工作的儿女可以和家乡的父母沟通,脱离开手机这个介质,音箱也能够成为家人情感沟通的桥梁。

腾讯听听音箱所属的腾讯移动互联网事业群智能创新业务部,是腾讯软硬一体落地AI前沿技术的智能硬件团队。团队负责人在品鉴会上表示,这是团队推出的第一款硬件产品,希望这款产品能够让全家人都喜爱,让它给家里的每位成员都带来更好的生活,成为我们表达爱的礼物。这一切仅仅是开始,未来还将会有更多的精彩和想象。

文章来源:http://geek.csdn.net

原文地址:http://geek.csdn.net/news/detail/258860