请选择 进入手机版 | 继续访问电脑版
楼主: CDA网校
887 0

基于Spark的机器学习经验——CDA人工智能学院 [推广有奖]

管理员

大师

61%

还不是VIP/贵宾

-

威望
3
论坛币
29523 个
通用积分
3001.1581
学术水平
259 点
热心指数
267 点
信用等级
234 点
经验
194171 点
帖子
5074
精华
19
在线时间
3682 小时
注册时间
2019-9-13
最后登录
2024-4-16

初级热心勋章

CDA网校 学生认证  发表于 2020-12-29 10:20:51 |显示全部楼层 |坛友微信交流群
相似文件 换一批

+2 论坛币
k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群
赵安豆老师微信:zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

感谢您参与论坛问题回答

经管之家送您两个论坛币!

+2 论坛币
CDA人工智能学院致力于以优质的人工智能在线教育资源助力学员的DT职业梦想!课程内容涵盖数据分析机器学习深度学习人工智能tensorFlowPyTorch、知识图谱等众多核心技术及行业案例,让每一个学员都可以在线灵活学习,快速掌握AI时代的前沿技术。PS:私信我即可获取CDA会员1个月免费试听机会

如何基于spark做机器学习

Spark发展到1.5版本,算是全平台了,实时批计算,批处理,算法库,SQL,hadoop能做的,基本他都能做,而且做的比Hadoop好。

当然,这里我要提及的是,Spark依然是Hadoop生态圈的一员,他替换的也仅仅是MR的计算模型而已。资源调度依赖于Yarn,存储则依赖于HDFS,是hadoop生态圈的一颗新星(其实算是老星啦)。

我 之前写文章说,Spark-Shell是个伟大的创新,加上牛逼的Scala语言,写spark程序就和写普通的shell脚本(或者类似python程序)一样容易。问题是,原来的shell,python只能在单机工作,现在你写的每一行代码,都被放到了一个几百台,几千台的规模上去做了。

以前的统计/机器学习依赖于数据抽样,抽样从统计的角度来看,如果足够随机,其实可以很精准的反应全集的结果,但事实上往往很难做好随机,所以通常做出来也会很不准。现在大数据解决了这个问题,但不是通过优化抽样的随机来解决,而是通过全量数据来解决。

要解决全量的就需要有强大的处理能力,spark首先具备强大的处理能力,其次SparkShell带来了传说中的即席查询。做算法的工程师,以前经常是在 小数据集上跑个单机,然后看效果不错,一到全量上,就歇菜了,和单机效果很不一样。虽然是小数据,但是在你的笔记本上跑你几个小时,也是很正常的。

但 是有了spark后,不一样了,尤其是有了spark-shell。 我后面的两个例子,都完全是在spark-shell上写就的。边写代码,边运行,边看结果。我研究的CSDN几百万博文的时候,就是直接拿全量数据跑,直接看效果。spark 抽样也很方便,一个sample函数,你想要多少就多少。

几 十个G的博文数据,count一下也就十几秒,cache了之后几秒就count完了。所以说,如果docker颠覆了部署,那么spark-shell也应该颠覆算法工程师的日常工作。我现在会和一个百度的朋友比,哇,最近我们spark集群内存有9个T了,对方鄙视的看我一眼:百T的飘过…..

目前Spark已经提供的算法,我用的最多的是贝叶斯,word2vec,线性回归等。所以这里,作为算法工程师,或者分析师,一定要学会用spark-shell。

基于Spark做新词发现

新词发现是一个非常有意思的领域,用途非常多。譬如可以构建垂直领域词库,自动发现新热门词汇。词库的重要性我不用强调了。基于Spark强大的计算能力,我直接对200万+的博文进行了分析,得到大概八万词,包含中文、英文、中英文混合词。

通过凝固度、自由度、词频、idf以及重合子串(比如 c1c2c3..cN c2c3..cN-1 这种形态的,我们认为是重合子串,如果词频一样,则都过滤掉,否则留词频高的)五个维度进行阈值设置和过滤。

事实上,中间结果可以到几百亿,一个不小心就可以把Spark跑死,但是也在这个过程中慢慢对Spark有了更深的理解。 最终效果还是不错的,现在它已经作为我们的基础词库了。

基 本上就是用spark计算出词的五个属性: 凝固度、自由度、词频、idf以及重合子串。算法自然是参考论文的,凝固度、自由度的概念来源于这里重合子串能修正一类的问题,但我感触比较深的是,通常某篇论文只会在一个视角去focus某件事情,所以你需要参考多篇,从不同角度去理解这件事情的解决方式,最后通过实验综合,得到一个更好解决方案。

我参考了两篇论文,比如凝固度,自由度是出自一篇论文,而重合子串则来自另外一篇论文,然后自己观察实际数据,添加了很多规则,才得到最后的结果。

一说到算法,大概很多人心里就是想着,恩,我把数据转化为算法需要的格式,然后丢给现成的算法跑,跑着就出结果,或者出模型,然后反复尝试,直到得到你认为 能接受的或者最优的结果。我一开始也是这么想的,可是如果你真的做这件事情,就发现完全不是那样子啊,需要注意的细节太多了。

新词发现没有现成的工具包,所以完全自己写了。第一步,你要获取语料。这容易,基于现有的平台,我从我们资源中心挑出了200万篇文章id,然后根据id到数据网关获取title,body字段。这个基于现有的平台,也就一个SQL + 几行Scala代码就搞定的事情。

SQL 其实就是用Hive 生成一个200万博文id列表。Scala代码也就几行。

因为我们的新词发现是没有词典的,需要枚举所有组合,然后通过一定的规则判定这是不是一个词。比如 ‘我是天才’,就这四个字, 组合有,‘我是’,‘我是天’,‘我是天才’,‘是天’,‘是天才’,‘天才’ 。

你想想,200万篇文章,这种组合得多夸张,问题是你还要接着给这些组合做计算呢。这个算法可没告诉你怎么处理的,你只能自己去想办法。看到了,真正你做算法的过程中,不只是实现,你需要面对的问题特别多,我是怎么做的呢?

将所有html标签替换成空格。

通过小空格将一个大文本切分成无数小文本块。

我们认为一个词的长度最长不能超过5个字。
对每个小文本块再抽取出中文,中英文,英文。
将一些特殊字符,类似“!¥……()+{}【】的呀啊阿哎吧和与兮呃呗咚咦喏啐喔唷嗬嗯嗳你们我他她,这是由于” 这些不可能成词的字符先去掉。处理的过程中,你可能需要写中文,英文,中英文的抽取方法。

通过上面的五个处理,你计算规模会小非常多。如果不这样处理,估计再大内存都能让你歇菜。接着就是按论文里的规则做计算了,比如算词的凝固度,算重合子串。 这里面还会遇到很多性能,或者内存的坑,比如Spark里的groupByKey,reduceByKey。我一开始省事,用了groupByKey,歇 菜了,内存直接爆了,为啥,你要去研究groupByKey到底是怎么实现的,一个词出现几十万次,几百万次都很正常啊,groupByKey受不了这种 情况。所以你得用reduceByKey。

在spark 1.5里,已经支持动态调整worker数目了。我之前做这个的时候,会开的比较大,如果集群规模比较小,可能会影响别人,而且用完要赶紧释放,但释放了重新再起,也还是很麻烦的,现在好很多了。

很好,实现了算法后得到了结果,可人家没告诉你,他贴出来的结果都是好看的,那是因为他是按频次排的,但如果你拉到最后看,结果就不太好看了。这个时候你就需要观察数据了,然后提出新的规则,比如最后得到的中文词结果,我用了一些简单规则过滤下,都是哪些呢?

凡是词里面包含‘或’的,或者’就’的或者上面罗列的,我都认为这个词是没有意义的,经过这个简单规则一过滤,效果好非常多,很多没什么意义的生活词,或者不成词的词就被去掉了。中文,英文,中英文混合,我都加了很多这种规则,最终才过滤出了八万计算机词汇。

我 在做上面的方案时,基本上就是在spark-shell中完成的。其实有点像ngram,就是对所有字符串做所有枚举,只是会限制最终成词的长度。我这里 中文是最长五个字,英文是四个字,中英文一块的是五个字,接着要算出每个词左右连接字。

重合子串,是这个算法的一个比较大的问题,比如 c1c2c3…cN c2c3…cN-1,因为是从统计的方案做的,c1c2c3…cN c2c3…cN-1 他们两算出来的分数可能就是一样的,所以如果我们发现他们的分值或者出现频率是一样的,就可以直接排除掉了。

基于Spark做智能问答

其实我做的智能问答算不上智能问答,但是内部一开始这么叫的,所以也就这么顺带叫下来了。 其实做的事情非常简单:

比较两个标题的相似度

如果我们能知道两个句子说的其实是一件事情,那么就能打通各产品的互通鸿沟了。之前试水的项目是打通问答到博客的通道。具体效果大家可以看看CSDN的问答产品,里面的机器人,背后用的算法就是这套。

当用户问一个问题,机器人就会到博客里去找有没有这个问题的答案,或者有没有可以做参考的。 比较神奇的是,之前有个在问答活跃的人也特别喜欢贴博客链接作为回答,我们对比了机器人和他的结果,发现机器人和他贴的差不多。

对于拥有内容的网站来说,这个技术还是非常重要的,比如CSDN,有论坛,博客,资讯,杂志等等,都是内容的载体。用户在问答频道里问的一个问题,其实在博客,在论坛早就已经有答案了。具体做法是透过word2vec解决一意多词的问题。接着将词转换为句子向量。这样任何一个问题都可以转换为一个向量。同理任何一篇博文的标题也可以转化为一个向量。

word2vec,采用的数据来源,我是用的搜索引擎的数据。大部分内容类的网站,他的PV应该有相当一部分来自搜索引擎,其实搜索引擎对这些网站来说,就是一个大的宝藏。因为搜索的query串,都是用户遇到的问题,然后指向到解决这些问题的内容上。

内容上,所以我直接拿用户的query作为word2vec的语料,得到一些常用的提问词,每个词用一个50维度的向量表示。当然,我们不可能真的让一个问 题和几百万内容直接做比较,一个简单有效的方式是,先通过搜索引擎去搜,然后将搜索得到top100结果做向量计算得到新的得分。 基本相似度大于0.9 的可以算作答案。大于0.7的就可以作为参考答案了。站内搜索服务应该是标配了,所以对大部分网站应该不是问题。

对了,这里有个问题是:word2vec计算出来的是用一个稠密的定长向量表示词,我的做法是直接把一个句子的里的词的向量按位做加法,重新得到一个新的向量作为句子的向量。当然,这种方式也是有缺陷,也就是句子越长,信息损耗越大。但是做这种标题性质的相似度,效果出奇的好,那种句子里很多词汇不相同的,它都能算出他们很相似来,这是因为word2vec可以算出不同词汇之间关系。

好了,具体的内容就分享到这里。

总结

下面是我的几个观点:

作为数据分析师,算法工程师,请好好利用spark-shell。 Spark社区为了满足数据分析师,算法工程师,其实也做了非常多的工作,包括Python, R语言的支持。15年社区努力做的DataFrame其实就是从R里借鉴过来的,也方便R数据科学家方便的迁移过来。我觉得大家都应该与时俱进,不要只玩 单机了。

课程Q&A

Q: 如何从0开始系统学习spark,最后转行?

A: 学会scala就行,scala是一门具有学院派气息的语言,你可以把它写的像python,ruby那样,也可以写的想java那样方方正正,也可以学习python,spark支持python但是可能有些功能用不了,用了一天的时间把Scala的官方教程看了,基本就能上手了。

Q:建议不做RAID的原因是什么?

A: 比如我例子提到的默认HDFS的所有数据都会存三份,可以保证数据位于不同的服务器上,不同的磁盘上,所以无需RAID。

Q:很多没什么意义的生活词,或者不成词的词,这些词是怎样得到的?也是分析出来的?

A: 因为用的都是统计的一些方式,所以肯定会有很多无意义的词汇,假设我们现在得到的词汇几何是A,接着我去爬了一些新闻和生活的类的博客,然后用程序去跑一遍得到一批词汇B,然后A-B 就能得到一拼更纯正的计算机词汇。

Q:内存要调到多大才能不会爆掉?是不是有什么比例?

A: 你不管调到多大,如果用的不好 也都有可能,groupByKey这个会有很大的内存问题,他形成的结构式 key-> value1,value2,value3……valuen,这种是非常消耗存储空间的额,大家使用spark的时候,序列化最好使用kyro,性能确实 好太多,一个worker 会同时配置可以使用的内存和cpu,这个时候一定要搭配好。比如你允许work使用5个cpu,那内存最好能配到10G,如果内存过小,你的cpu会大量 浪费在GC上,我一般是单个worker 12G内存 ,可使用4核。

Q:直接把一个句子的里的词的向量按位做加法,这是如何加?能举个例子不?

A:比如 考虑一个三维向量: A[1,3,5] B[1,3,7],现在有个句子 是AB两个词组成,则对应的向量为A+B=[2,6,12]

Q:还有中文分词是用的什么方法?可否分享代码不啊?

A:这里是无监督分词,所以不用中文分词,按维度叠加,才能保证都是相同长度的向量,而且中文分词这块,我推荐我一个同事的 ansj分词,还是做的不错的。

Q:一些分词方法具有新词发现的功能,比如crf,楼主是比较过效果么?而且我记得matrix67这个算法复杂度还是很高的?

A: matrix67 这个算法复杂度还是非常高的,你实际操作就会发现计算量,内存使用量都很大,crf等据我所知,还都是需要依赖词表的,matrix67的这个方式,完全不需要任何先验的东西。

Q:为什么一个词要用50维度表示? 这能举个例子不? 这里不太明白。

A: 理论上维度越长越好,我当时是随意试了一个值。发现效果其实已经可以了,这是一个可以调整的值,比如你可以分别生成50,150,300维度的,然后试试那个效果好。

29C446FFF799701B5098749DB47B5891.jpg

扫码关注CDA公众号,即可获取最新版数据分析题库大全CDA免费精品课70+


二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

关键词:Spark 人工智能 学习经验 机器学习 Park

您需要登录后才可以回帖 登录 | 我要注册

本版微信群
加JingGuanBbs
拉您进交流群

京ICP备16021002-2号 京B2-20170662号 京公网安备 11010802022788号 论坛法律顾问:王进律师 知识产权保护声明   免责及隐私声明

GMT+8, 2024-4-16 19:02