『壹』 大数据专业主要学习什么语言
大数据是近五年兴起的行业，发展迅速，很多技术经过这些年的迭代也变得比较成熟了，同时新的东西也不断涌现，想要保持自己竞争力的唯一办法就是不断学习。但是，大数据需要学习什么？1 思维导图下面的是我之前整理的一张思维导图，内容分成几大块，包括了分布式计算与查询，分布式调度与管理，持久化存储，大数据常用的编程语言等等内容，每个大类下有很多的开源工具。2大数据需要的语言javajava可以说是大数据最基础的编程语言，据我这些年的经验，我接触的很大一部分的大数据开发都是从Jave Web开发转岗过来的（当然也不是绝对我甚至见过产品转岗大数据开发的，逆了个天）。一是因为大数据的本质无非就是海量数据的计算，查询与存储，后台开发很容易接触到大数据量存取的应用场景二就是java语言本事了，天然的优势，因为大数据的组件很多都是用java开发的像HDFS,Yarn,Hbase,MR,Zookeeper等等，想要深入学习，填上生产环境中踩到的各种坑，必须得先学会java然后去啃源码。说到啃源码顺便说一句，开始的时候肯定是会很难，需要对组件本身和开发语言都有比较深入的理解，熟能生巧慢慢来，等你过了这个阶段，习惯了看源码解决问题的时候你会发现源码真香。Scalascala和java很相似都是在jvm运行的语言，在开发过程中是可以无缝互相调用的。Scala在大数据领域的影响力大部分都是来自社区中的明星Spark和kafka,这两个东西大家应该都知道（后面我会有文章多维度介绍它们），它们的强势发展直接带动了Scala在这个领域的流行。Python和Shellshell应该不用过多的介绍非常的常用，属于程序猿必备的通用技能。python更多的是用在数据挖掘领域以及写一些复杂的且shell难以实现的日常脚本。3分布式计算什么是分布式计算？分布式计算研究的是如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多服务器进行处理，最后把这些计算结果综合起来得到最终的结果。举个栗子，就像是组长把一个大项目拆分，让组员每个人开发一部分，最后将所有人代码merge，大项目完成。听起来好像很简单，但是真正参与过大项目开发的人一定知道中间涉及的内容可不少。分布式计算目前流行的工具有：离线工具Spark，MapRece等实时工具Spark Streaming，Storm，Flink等这几个东西的区别和各自的应用场景我们之后再聊。4分布式存储传统的网络存储系统采用的是集中的存储服务器存放所有数据，单台存储服务器的io能力是有限的，这成为了系统性能的瓶颈，同时服务器的可靠性和安全性也不能满足需求，尤其是大规模的存储应用。分布式存储系统，是将数据分散存储在多台独立的设备上。采用的是可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。上图是hdfs的存储架构图，hdfs作为分布式文件系统，兼备了可靠性和扩展性，数据存储3份在不同机器上（两份存在同一机架，一份存在其他机架）保证数据不丢失。由NameNode统一管理元数据，可以任意扩展集群。主流的分布式数据库有很多hbase，mongoDB，GreenPlum，redis等等等等，没有孰好孰坏之分，只有合不合适，每个数据库的应用场景都不同，其实直接比较是没有意义的，后续我也会有文章一个个讲解它们的应用场景原理架构等。5分布式调度与管理现在人们好像都很热衷于谈"去中心化"，也许是区块链带起的这个潮流。但是"中心化"在大数据领域还是很重要的，至少目前来说是的。分布式的集群管理需要有个组件去分配调度资源给各个节点，这个东西叫yarn;需要有个组件来解决在分布式环境下"锁"的问题，这个东西叫zookeeper；需要有个组件来记录任务的依赖关系并定时调度任务，这个东西叫azkaban。当然这些“东西”并不是唯一的，其实都是有很多替代品的，本文只举了几个比较常用的例子。
『贰』 大数据需要学习什么样的知识
看从事大数抄据的哪个部分。
大数据分三个部分，数据分析、大数据平台的中台和大数据底层处理。
数据分析：统计专业+一门实际业务+计算机数据分析工具。可以参考研究生BA专业。
数据中台：CS专业+大数据方向的算法 （并行计算、机器学习一类的）。研究生起步。
数据底层处理：一定的软件基础+数据库应用。本科即可。
本科不要学大数据专业，四年学不出来，干啥啥不行。
『叁』 为什么说Lucene不好
在Lingway公司，我们使用了Lucene至进今已有好几年时间。对那些刚接触Lucene的人来说，这里是使用它的关键：Apache Lucene是一个由java编写的高性能，全方位的单词搜索引擎库。
在批评它之前，我必须承认Lucene是一个高性能的划词搜索引擎。几年来，Lucene已经被看作是用java编写的嵌入式搜索引擎中的一等公民。它的声誉每日剧增，并且仍然是开源java搜索引擎中的最佳。每个人都在说：“Doug Cutting做了一项伟大的工作”。然而，最近的几个月内，开发的进程变得缓慢，我认为Lucene将不会满足现代的文档处理需求。不要把东西搞糟：我不是搜索引擎开发者，我只是个开发者，使用搜索引擎，来提供合适信息的检索科技。
Lucene不是最好选择，至少对我们而言如此，并且情况并没有得到改变。我们列出Lucene的局限性：Lingway公司基于语意来生成复杂的查询。例如当你正在查找关于“中东地区冲突”的文章，你也许还需要找关于“伊拉克战争”文章。在上面这个用例中，“战争”和“伊拉克”分别是“冲突”和“中东”的扩展。我们使用一种技术能分析你的查询，产生相应的最合适的扩展，为它们生成查询。然而，为了得到相关的结果，这些还是不够的：通过Lucene实现的类似Google的等级或是经常变化积分的并不能满足语意级别积分。例如，一个包含“中”和“东”短语，但是被超过一个以上的单词隔开，这种情况并不是我们想要查找的。更重要的是，相对常规的单词，我们应该给扩展更低的分数。比如，我们应该给“中东地区冲突”这个短语更高的分数，而不是“伊拉克战争”。
在Lingway公司，我们认为这种文章相关性技术是一种未来的搜索引擎。Google在文章搜索上做的很出色。但我们想要的却是最相关的文章。但是，大部分的当代搜索引擎都没有对这样复杂查询做相关的设计…Lucene被wikipedia使用，如果你注意到当你查询查过一个单词时，大多数的查询结果并不是由关联的…
为了演示需求，这里有一个Lingway公司即将上线的KM3.7产品的界面截图。这里我们用法语写一个查询，用来查找那些同样主题，而用英语写的文章。注意，这可不仅仅是简简单单的翻译，我们称之为语言交叉模式：
注意到那些绿色的匹配:chanteur变成了singer,但是我们也发现singing被匹配了。同样情况流行乐成为蓝调的扩展。
6大理由不选用Lucene
6. 没有对集群的内置支持。
如果你创建集群，你可以写出自己对Directory的实现，或是使用Solr或者使用Nutch+Hadoop。Solr和Nutch都支持Lucene，但不是直接的替代。Lucene是可嵌入的，而你必须支持Solr和Nutch..我认为Hadoop从Lucene团队中产生并不惊讶:Lucene并不是通用的。它的内在性决定了对大多数场合来说它是非常快速的，但是对大型文档集合时,你不得不排除Lucene。因为它在内核级别上并没有实现集群，你必须把Lucene转换到别的搜索引擎，这样做并不直接。转换到Solr或者Nutch上的问题会让你遇到许多不必要的麻烦:Nutch中的集成crawling和Solr中的检索服务。
5.跨度查询太慢
这对Lingway公司来说可能是个特殊的问题。我们对跨度查询有很强要求,Lucene检索结构已经开始添加这一细节，但它们当初可没这么想。最基础的实现导致了复杂的算法并且运行缓慢，尤其是当某些短语在一份文档中重复了许多次出现。这是为什么我倾向说Lucene是一个高性能的划词检索引擎当你仅仅使用基本的布尔查询时。
4.积分不能被插件化
Lucene有自己对积分算法的实现,当条件增加时使用Similarity类。但很快它显示出局限性当你想要表示复杂的积分,例如基于实际匹配和元数据的查询。如果你这样做，你不得不继承Lucene的查询类。因为Lucene使用类似tf/idf的积分算法，然而在我们遇到的场合，在语意上的积分上Lucene的积分机制并不合适。我们被迫重写每一个Lucene的查询类使得它支持我们自定义的积分。这是一个问题。
3.Lucene并非良好设计
作为一个系统架构师，我倾向认为(1)Lucene有一个非常糟糕的OO设计。虽然有包，有类的设计，但是它几乎没有任何设计模式。这让我想起一个由C(++)开发者的行为，并且他把坏习惯带到了java中。这造成了，当你需要自定义Lucene来满足你的需求(你将来必定会遇到这样的需求)，你必须面对这样的问题。例如：
<!--[if !supportLists]--> <!--[endif]-->几乎没有使用接口。查询类（例如BooleanQuery,SpanQuery,TermQuery…）都是一个抽象类的子类。如果你要添加其中的一个细节，你会首先想到写一个接口来描述你扩展的契约，但是抽象的Query类并没有实现接口，你必须经常的变化自己的查询对象到Query中并在本地Lucene中调用。成堆的例子如(HitCollecor,…)这对使用AOP和自动代理来说也是一个问题.
<!--[if !supportLists]--> <!--[endif]-->别扭的迭代实现.没有hasNext()方法,next()方法返回布尔类型并刷新对象内容.这对你想要保持对迭代的元素跟踪来说非常的痛苦.我假定这是故意用来节省内存但是它又一次导致了算法上的杂乱和复杂.
2.一个关闭的API使得继承Lucene成为痛苦
在Lucene的世界中,它被称之为特性。当某些用户需要得到某些细节，方针是开放类。这导致了大多数的类都是包保护级别的，这意味着你不能够继承他们（除非在你创建的类似在同一个包下，这样做会污染客户代码）或者你不得不复制和重写代码。更重要的是，如同上面一点提到的，这个严重缺乏OO设计的结构，一些类应该被设为内部类却没有，匿名类被用作复杂的计算当你需要重写他们的行为。关闭API的理由是让代码在发布前变得整洁并且稳定。虽然想法很光荣，但它再一次让人感到痛苦。因为如果你有一些代码和Lucene的主要思路并不吻合，你不得不经常回归Lucene的改进到你自己的版本直到你的补丁被接受。
然而当开发者开始越来越长的限制API的更改，你的补丁很少有机会被接受。在一些类和方法上加上final修饰符会让你遇到问题。我认为如果Spring框架有这样的限制，是觉不会流行起来。
<!--[if !supportLists]-->1. Lucene搜索算法不适合网格计算<!--[endif]-->
Lucene被写出来的时候硬件还没有很大的内存，多处理器也不存在。因此，索引结构是被设计成使用线性的内存开销很小的方式。我花了很长的时间来重写跨度查询算法，并使用多线程内容（使用双核处理器），但是基于迭代器的目录读取算法几乎不能实现。在一些罕见的场合你能做一些优化并能迭代一个索引通过并行方式，但是大多数场合这是不可能的。我们遇到的情况是，当我们有一个复杂的，超过50+的内嵌跨度查询，CPU还在空闲但I/O却一直忙�担踔猎谑褂昧薘AMDirectory.
有没有替代品？
我认为最后一个观点充满疑问:Lucene到达了它的极限当它在现在硬件基础的条件下，检索大型数据集合时。那就是我为什么寻找下一个可以替代Lucene的出现。在阅读了博客目录和 Wikia的讨论后，我发现并没有很多的替代品。然而我最后推荐一个有希望的方案：MG4J。它有一个良好的面向对象设计，性能良好的检索（索引比Lucene慢），内存开销上也很小，达到10倍于Lucene速度的跨度查询，在我的跨度查询基准上，并且是原生上支持集群。同样它也内置了负载平衡，而Lucene最近才加入这项功能并且还是实验性质的。然而MG4J仍然缺少一些特性例如简单的索引指数，文档移除和更简单的使用索引处理。让我感到高兴的是我可以自定义Lucene上的功能在MG4J上只需花几个小时，而在Lucene上却需要数天。
我认为对开源的搜索引擎来说仍然有发展空间，它不是通过单台电脑用有限的内存来索引批量文档，而是通过透明的分布式索引来提供对大型数据集合检索更为快捷的答案。你不必利用应用来获得集群特性。Lucene对第一类搜索引擎有了很好的实现，单我认为它并不符合我们的需求：在一个合理的时间内找到最佳的答案。基于tf/idf的搜索算法和google的等级并不是未来搜索引擎的趋势。实现对原数据和语义的复杂查询并找出相关的信息，这是Lingway公司(通过Lucene和其他搜索引擎技术)所作的，不过它要求有更多支持新硬件的新技术。
使用Lucene的一个好理由
无论我如何指责Lucene,它仍然是java开源解决方案中的最佳实现。
『肆』 elasticsearch映射的数据类型有哪些
es支持大多数java里面的数据类型：
（一）核心数据类型：
（1）string： 默认会被分词，一个完整示例如下
"status": {
"type": "string", //字符串类型
"index": "analyzed"//分词，不分词是：not_analyzed ，设置成no，字段将不会被索引
"analyzer":"ik"//指定分词器
"boost":1.23//字段级别的分数加权
"doc_values":false//对not_analyzed字段，默认都是开启，分词字段不能使用，对排序和聚合能提升较大性能，节约内存
"fielddata":{"format":"disabled"}//针对分词字段，参与排序或聚合时能提高性能，不分词字段统一建议使用doc_value
"fields":{"raw":{"type":"string","index":"not_analyzed"}} //可以对一个字段提供多种索引模式，同一个字段的值，一个分词，一个不分词
"ignore_above":100 //超过100个字符的文本，将会被忽略，不被索引
"include_in_all":ture//设置是否此字段包含在_all字段中，默认是true，除非index设置成no选项
"index_options":"docs"//4个可选参数docs（索引文档号） ,freqs（文档号+词频），positions（文档号+词频+位置，通常用来距离查询），offsets（文档号+词频+位置+偏移量，通常被使用在高亮字段）分词字段默认是position，其他的默认是docs
"norms":{"enable":true,"loading":"lazy"}//分词字段默认配置，不分词字段：默认{"enable":false}，存储长度因子和索引时boost，建议对需要参与评分字段使用 ，会额外增加内存消耗量
"null_value":"NULL"//设置一些缺失字段的初始化值，只有string可以使用，分词字段的null值也会被分词
"position_increament_gap":0//影响距离查询或近似查询，可以设置在多值字段的数据上火分词字段上，查询时可指定slop间隔，默认值是100
"store":false//是否单独设置此字段的是否存储而从_source字段中分离，默认是false，只能搜索，不能获取值
"search_analyzer":"ik"//设置搜索时的分词器，默认跟ananlyzer是一致的，比如index时用standard+ngram，搜索时用standard用来完成自动提示功能
"similarity":"BM25"//默认是TF/IDF算法，指定一个字段评分策略，仅仅对字符串型和分词类型有效
"term_vector":"no"//默认不存储向量信息，支持参数yes（term存储），with_positions（term+位置）,with_offsets（term+偏移量），with_positions_offsets(term+位置+偏移量) 对快速高亮fast vector highlighter能提升性能，但开启又会加大索引体积，不适合大数据量用
}
（2）数字类型主要如下几种：
long：64位存储
integer：32位存储
short：16位存储
byte：8位存储
double：64位双精度存储
float：32位单精度存储
支持参数：
coerce：true/false 如果数据不是干净的，将自动会将字符串转成合适的数字类型，字符串会被强转成数字，浮点型会被转成整形，经纬度会被转换为标准类型
boost：索引时加权因子
doc_value：是否开启doc_value
ignore_malformed：false（错误的数字类型会报异常）true（将会忽略）
include_in_all：是否包含在_all字段中
index:not_analyzed默认不分词
null_value：默认替代的数字值
precision_step：16 额外存储对应的term，用来加快数值类型在执行范围查询时的性能，索引体积相对变大
store：是否存储具体的值
（3）复合类型
数组类型：没有明显的字段类型设置，任何一个字段的值，都可以被添加0个到多个，要求，他们的类型必须一致：
对象类型：存储类似json具有层级的数据
嵌套类型：支持数组类型的对象Aarray[Object]，可层层嵌套
（4）地理类型
geo-point类型： 支持经纬度存储和距离范围检索
geo-shape类型：支持任意图形范围的检索，例如矩形和平面多边形
（5）专用类型
ipv4类型：用来存储IP地址，es内部会转换成long存储
completion类型：使用fst有限状态机来提供suggest前缀查询功能
token_count类型：提供token级别的计数功能
mapper-murmur3类型：安装sudo bin/plugin install mapper-size插件，可支持_size统计_source数据的大小
附件类型：需要 https://github.com/elastic/elasticsearch-mapper-attachments开源es插件支持，可存储office，html等类型
（6）多值字段：
一个字段的值，可以通过多种分词器存储，使用fields参数，支持大多数es数据类型
『伍』 如何用Python玩转TF-IDF之寻找相似文章并生成摘要
应用1：关键词自动生成
核心思想是对于某个文档中的某个词，计算其在这个文档中的标准化TF值，然后计算这个词在整个语料库中的标准化IDF值。在这里，标准化是说对原始的计算公式进行了一些变换以取得更好的衡量效果，并避免某些极端情况的出现。这个词的TF-IDF值便等于TF*IDF。对于这个文档中的所有词计算它们的TF-IDF值，并按照由高到低的顺序进行排序，由此我们便可以提取我们想要的数量的关键词。
TF-IDF的优点是快捷迅速，结果相对来说比较符合实际情况。缺点是当一篇文档中的两个词的IDF值相同的时候，出现次数少的那个词有可能更为重要。再者，TF-IDF算法无法体现我词的位置信息，出现位置靠前的词与出现位置靠后的词，都被视为重要性相同，这是不正确的。存在的解决办法是对文章的第一段和每段的第一句话给予比较大的权重。
应用2：计算文本相似度
明白了对于每个词，如何计算它的TF-IDF值。那么计算文本相似度也轻而易举。我们已经计算了文章中每个词的TF-IDF值，那么我们便可以将文章表征为词的TF-IDF数值向量。要计算两个文本的相似度，只需要计算余弦即可，余弦值越大，两个文本便越相似。
应用3：自动摘要
2007年，美国学者的论文<A Survey on Automatic Text Summarization>总结了目前的自动摘要算法，其中很重要的一种就是词频统计。这种方法最早出自1958年IBM公司一位科学家的论文<The Automatic Creation of Literature Abstracts>。这位科学家认为，文章的信息都包含在句子中，有的句子包含的信息多，有的句子包含的信息少。自动摘要就是找出那些包含信息最多的句子。那么句子的信息量怎么衡量呢？论文中采用了关键词来衡量。如果包含的关键词越多，就说明这个句子越重要，这位科学家提出用Cluster的来表示关键词的聚集。所谓簇，就是包含多个关键词的句子片段。
以第一个图为例，其中的cluster一共有7个词，其中4个是关键词。因此它的重要性分值就等于(4*4)/7=2.3。然后，找出包含cluster重要性分值最高的句子（比如5句），把它们合在一起，就构成了这篇文章的自动摘要。具体实现可以参见<Mining the Social Web: Analyzing Data from Facebook, Twitter, LinkedIn, and Other Social Media Sites>（O'Reilly, 2011）一书的第8章，Python代码见github。这种算法后来被简化，不再区分cluster，只考虑句子包含的关键词。伪代码如下。
Summarizer(originalText,maxSummarySize):
//计算文本的词频，生成一个列表，比如[(10,'the'),(3,'language'),(8,'code')...]
wordFrequences=getWordCounts(originalText)
//过滤掉停用词，列表变成[(3,'language'),(8,'code')...]
contentWordFrequences=filtStopWords(wordFrequences)
//按照词频的大小进行排序，形成的列表为['code','language'...]
contentWordsSortbyFreq=sortByFreqThenDropFreq(contentWordFrequences)
//将文章分成句子
sentences=getSentences(originalText)
//选择关键词首先出现的句子
setSummarySentences={}
:
firstMatchingSentence=search(sentences,word)
setSummarySentences.add(firstMatchingSentence)
ifsetSummarySentences.size()=maxSummarySize:
break
//将选中的句子按照出现顺序，组成摘要
summary=""
foreachsentenceinsentences:
:
summary=summary+""+sentence
returnsummary
类似的算法已经被写成了工具，比如基于Java的Classifier4J库的SimpleSummariser模块、基于C语言的OTS库、以及基于classifier4J的C#实现和python实现。