Hi，大家好！我是祝威廉，本来微博也想叫祝威廉的，可惜被人占了，于是改名叫·祝威廉二世。然后总感觉哪里不对。目前在乐视云数据部门里从事实时计算，数据平台、搜索和推荐等多个方向。曾从事基础框架，搜索研发四年，大数据平台架构、推荐三年多，个人时间现专注于集群自动化部署，服务管理，资源自动化调度等方向。
今天会和大家分享三个主题。 不过限于时间，第三个只是会简单提及下， 等未来有机会可以更详细的分享。
- 如何基于Spark做机器学习（Spark-Shell其实也算的上即席查询了）
- 基于Spark做新词发现（依托Spark的强大计算能力）
- 基于Spark做智能问答（Spark上的算法支持）
其中这些内容在我之前写的一篇描述工作经历的文章
我的工作都有提及到，当然，可能不如今天分享的这么详细。
如何基于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以及重合子串。算法自然是参考论文的，凝固度、自由度的概念来源于这里(
http://www.matrix67.com/blog/archives/5044) 重合子串能修正一类的问题，但我感触比较深的是，通常某篇论文只会在一个视角去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数目了。我之前做这个的时候，会开的比较大，如果集群规模比较小，可能会影响别人，而且用完要赶紧释放，但释放了重新再起，也还是很麻烦的，现在好很多了。
很好，实现了算法后得到了结果，可人家没告诉你，他贴出来的结果都是好看的，那是因为他是按频次排的，但如果你拉到最后看，结果就不太好看了。这个时候你就需要观察数据了，然后提出新的规则，比如最后得到的中文词结果，我用了一些简单规则过滤下，都是哪些呢？凡是词里面包含‘或’的，或者'就'的或者上面罗列的，我都认为这个词是没有意义的，经过这个简单规则一过滤，效果好非常多，很多没什么意义的生活词，或者不成词的词就被去掉了。中文，英文，中英文混合，我都加了很多这种规则，最终才过滤出了八万计算机词汇。
重合子串，是这个算法的一个比较大的问题，比如 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维度的，然后试试那个效果好。
