① ES大数据量下的查询优化
filesystem类似于我们在mysql上建立一层redis缓存；
es的搜索引擎严重依赖于底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的indx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。
两者差距非常大，走磁盘和走systenfile cache的读取的性能差距可以说是秒级和毫秒级的差距了；
要让es性能要好，最佳的情况下，就是我们的机器的内存，至少可以容纳你的数据量的一半
最佳的情况下，是仅仅在es中就存少量的数据，存储要用来搜索的那些索引，内存留给filesystem cache的，如果就100G，那么你就控制数据量在100gb以内，相当于是，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在1秒以内
的少数几个字段就可以了，比如说，就写入es id name age三个字段就可以了，然后你可以把其他的字段数据存在mysql里面，我们一般是建议用 es + hbase 的一个架构。
hbase的特点是适用于海量数据的在线存储，就是对hbase可以写入海量数据，不要做复杂的搜索，就是做很简单的一些根据id或者范围进行查询的这么一个操作就可以了
如果确实内存不足，但是我们又存储了比较多的数据，比如只有30g给systemfile cache，但是存储了60g数据情况，这种情况可以做数据预热；
我们可以将一些高频访问的热点数据（比如微博知乎的热榜榜单数据，电商的热门商品（旗舰版手机，榜单商品信息）等等）提前预热，定期访问刷到我们es里；（比如定期访问一下当季苹果旗舰手机关键词，比如现在的iphone12）
对于那些你觉得比较热的，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，提前访问一下，让数据进入filesystem cache里面去。这样下次别人访问的时候，一定性能会好一些。
我们可以将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在filesystem os cache里，别让冷数据给冲刷掉。
尽量做到设计document的时候就把需要数据结构都做好，这样搜索的数据写入的时候就完成。对于一些太复杂的操作，比如join，nested，parent-child搜索都要尽量避免，性能都很差的。
es的分页是较坑的 ，为啥呢？举个例子吧，假如你每页是10条数据，你现在要查询第100页，实际上是会把 每个shard上存储的前1000条数据都查到 一个协调节点上，如果你有个5个shard，那么就有5000条数据，接着 协调节点对这5000条数据进行一些合并、处理，再获取到最终第100页的10条数据。
因为他是分布式的，你要查第100页的10条数据，你是不可能说从5个shard，每个shard就查2条数据？最后到协调节点合并成10条数据？这样肯定不行，因为我们从单个结点上拿的数据几乎不可能正好是所需的数据。我们必须得从每个shard都查1000条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第100页的数据。
你翻页的时候，翻的越深，每个shard返回的数据就越多，而且协调节点处理的时间越长。非常坑爹。所以用es做分页的时候，你会发现越翻到后面，就越是慢。
我们之前也是遇到过这个问题，用es作分页，前几页就几十毫秒，翻到10页之后，几十页的时候，基本上就要5~10秒才能查出来一页数据了
你系统不允许他翻那么深的页，或者产品同意翻的越深，性能就越差
如果是类似于微博中，下拉刷微博，刷出来一页一页的，可以用scroll api
scroll api1 scroll api2
scroll会一次性给你生成所有数据的一个快照，然后每次翻页就是通过游标移动 ，获取下一页下一页这样子，性能会比上面说的那种分页性能也高很多很多
scroll的原理实际上是保留一个数据快照，然后在一定时间内，你如果不断的滑动往后翻页的时候，类似于你现在在浏览微博，不断往下刷新翻页。那么就用scroll不断通过游标获取下一页数据，这个性能是很高的，比es实际翻页要好的多的多。
缺点：
② ES(六) ElasticSearch搜索原理
关于ES的搜索，小白暂且简单的归纳如下:
新增文档时涉及分词、构建索引
查询时涉及分词、查询索引、相关度评分
那么接下来，小白就从分词、索引、相关度评分三个方面开始瞎掰了...
分词是指将文本转换成一系列单词（term or token）的过程，也可以叫做文本分析，在es里面称为Analysis。
分词机制：
Character Filter：对原始文本进行处理，例如 去除html标签、替换字符等
Tokenizer：将原始文本进行分词，例如 小白最帅 => 小白，最，帅
Token Filters：分词后的关键字进行加工，例如 转小写、删除语气词、近义词和同义词等
在进行Tokenizer之前对对原始文本进行处理，例如 去除html标签、替换字符等
不过进行处理后，会影响后续Tokenizer解析的position和offset
HTML Strip => 去除html标签和转换html实体
Mapping => 字符串替换操作
Pattern Replace => 正则匹配替换
将原始文本进行分词，例如 小白最帅 => 小白，最，帅
Elasticsearch自带的分词器：
【分词器（Analyzer）】 【特点】
standard（es默认） 支持多语言，按词切分并做小写处理
simple 按照非字母切分，小写处理
whitespace 按照空格来切分
stop 去除语气助词，如the、an、的、这等
keyword 不分词
pattern 正则分词，默认\w+,即非字词符号做分割符
language 常见语言的分词器（30+）
常见中文分词器：
【名称】 【介绍】 【特点】
IK 实现中英文单词切分 自定义词库
https://github.com/medcl/elasticsearch-analysis-ik
Jieba python流行分词系统，支持分词和词性标注 支持繁体、自定义、并行分词
http://github.com/sing1ee/elasticsearch-jieba-plugin
Hanlp 由一系列模型于算法组成的java工具包 普及自然语言处理在生产中应用
https://github.com/hankcs/HanLP
THULAC 清华大学中文词法分析工具包 具有中文分词和词性标注功能
https://github.com/microbun/elasticsearch-thulac-plugin
分词后的关键字进行加工，例如 转小写、删除语气词、近义词和同义词等
lowercase => 将所有term转换为小写
stop => 删除stop words
ngram => 和Edge NGram连词分割
synonym => 添加近义词的term
提到ES中的索引，就算没用过，估计也听过，就是倒排索引，当然ES中不可能不涉及正排索引。
通俗地来讲，正排索引是通过key找value，倒排索引则是通过value找key。举个例子，如果要查找图书馆中名为【水浒传】的书籍时，提前建立正排索引会提高查询效率；如果要查找图书馆中所有包含词语【英雄】的书籍时，提前建立倒排索引会提高查询效率，而正排索引需要遍历所有的书籍内容。
记录文档id到文档内容or单词的关联关系，比如：
【DocId】 【content】
1 => 小白最帅（小白、最、帅）
2 => 小黑最帅（小黑、最、帅）
3 => 拳打小白（拳打、小白）
备注：IK分词器中提供了两个分词算法 ik_smart 和 ik_max_word
其中 ik_smart 为最少切分，ik_max_word为最细粒度划分
本小节分词采用的是 ik_smart
记录单词到文档id的关联关系，包含：
1、Term DicTionary（单词词典）：记录所有文档的单词，一般比较大
2、Posting List（倒排链表）：记录单词倒排列表的关联信息
以第1节中文档【小白最帅】和【拳打小白】中的【小白】为例：
Term DicTionary：小白
Posting List：
【DocId】 【TF】 【Position】 【Offset】
1 1 0 <0-2>
3 1 1 <2-4>
DocId：文档id，指向文档的原始信息
TF：单词频率，记录该词在文档中出现的次数，用于后续相关性评分
Position：位置，记录文档中字段分词后，单词所在的位置，从0开始
Offset：偏移量，记录单词在文档中开始和结束位置，用于高亮显示等，从0开始
不是很恰当的说，索引的建立，标志着key的创建，再让key和value之间建立联系，就可以让原本直接查找value，变成了先去查找key，再直接定位到对应的value，属于典型的空间换时间或者说是先栽树、再乘凉。
下面这个数据结构图，不管是java开发还是大数据开发，估计都看烂了。。。
备注：每个文档字段都有自己的倒排索引
相关性描述的是“语句”与“某个文档”匹配的程度。ES 会对每个匹配查询的结果进⾏计算，得出_score，_score 的评分越高，相关度就越高，那这个计算就需要一个算法。在ES5之前默认的算法是TF/IDF，ES5之后默认采用的是BM25，BM25是对TF/IDF的改进，所以这里小白直接以BM25为主来叨叨。
在进行相关度计算之前，会先有一个过程叫Boolean Model，之后再使用TFNORM/IDF算法。
简单来说，Boolean Model就是根据查询条件，对文档进行一个快速的筛选，不涉及相关度计算。
即词频长度(Term Frequency Norm)，单个term在文档中出现的频率，并结合字段长度，出现次数越高，字段长度越低，分越高
计算公式：
tfNorm(t in d) = (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength))
freq：term出现频率
k1 ：这个参数控制着词频结果在词频饱和度中的上升速度 。 默认值为1.2。值越小饱和度变化越快，值越大饱和度变化越慢
b ：这个参数控制着字段长归一值所起的作用 ， 0.0会禁用归一化，1.0会启用完全归一化。默认值为0.75
fieldLength：字段长度
avgFieldLength：平均字段长度
即逆向文档频率(inversed document frequency)，单个term在所有文档里出现的频率，出现次数越高，分越低。
计算公式：
idf(t) = log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5))
docCount ：索引中文档数量
docFreq ：包含该词的文档数
此公式将出现频率较高的词的得分降低。比如，“的”、“了”等词语在各文档中出现频率较高，但是并没有太大的参考意义，所以降低其得分。
然后，将上面两个算法的得分相乘，则是一个term的最终得分。
单个term：_score(单) = idf(t) * tfNorm(t in d)
多个term：_score(多) = 多个_score(单)的和
最后，我们在Kibana中通过explain查询语句来看一哈【所用索引和数据为下一节中的内容】：
ES(五) ElasticSearch+Kibana+IK 安装—ES集群 ES(七) Demo-商品搜索
③ es/logstash/kibana框架是用于什么
ELK 由三部分组成elasticsearch、logstash、kibana，elasticsearch是一个近似实时的搜索平台,它让你以前所未有的速度处理大数据成为可能。
Elasticsearch所涉及到的每一项技术都不是创新或者革命性的，全文搜索，分析系统以及分布式数据库这些早就已经存在了。它的革命性在于将这些独立且有用的技术整合成一个一体化的、实时的应用。Elasticsearch是面向文档(document oriented)的，这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储，还会索引(index)每个文档的内容使之可以被搜索。在Elasticsearch中，你可以对文档（而非成行成列的数据）进行索引、搜索、排序、过滤。这种理解数据的方式与以往完全不同，这也是Elasticsearch能够执行复杂的全文搜索的原因之一。
应用程序的日志大部分都是输出在服务器的日志文件中，这些日志大多数都是开发人员来看，然后开发却没有登陆服务器的权限，如果开发人员需要查看日志就需要到服务器来拿日志，然后交给开发；试想下，一个公司有10个开发，一个开发每天找运维拿一次日志，对运维人员来说就是一个不小的工作量，这样大大影响了运维的工作效率，部署ELKstack之后，开发任意就可以直接登陆到Kibana中进行日志的查看，就不需要通过运维查看日志，这样就减轻了运维的工作。
日志种类多，且分散在不同的位置难以查找：如LAMP/LNMP网站出现访问故障，这个时候可能就需要通过查询日志来进行分析故障原因，如果需要查看apache的错误日志，就需要登陆到Apache服务器查看，如果查看数据库错误日志就需要登陆到数据库查询，试想一下，如果是一个集群环境几十台主机呢？这时如果部署了ELKstack就可以登陆到Kibana页面进行查看日志，查看不同类型的日志只需要电动鼠标切换一下索引即可。
Logstash：日志收集工具，可以从本地磁盘，网络服务（自己监听端口，接受用户日志），消息队列中收集各种各样的日志，然后进行过滤分析，并将日志输出到Elasticsearch中。
Elasticsearch：日志分布式存储/搜索工具，原生支持集群功能，可以将指定时间的日志生成一个索引，加快日志查询和访问。
Kibana：可视化日志Web展示工具，对Elasticsearch中存储的日志进行展示，还可以生成炫丽的仪表盘。
④ 朋友想学习大数据，有哪里可以学习呢
大数据也是最近几年才火起来的学科，之前发展一直是不瘟不火的，可能是和这些年高速发展是互联网有一定的关系的。
目前想要学习大数据建议还是去一线城市进行学习的比较好，大数据是属于高度技术行业，在二三线城市现在发展得还不是很好，大多数的大企业都是在一线城市，所以很多技术都是出现在一线城市的。
选择去北京学习大数据确实非常不错，因为现在大数据发展比较好的地方也就是北上广这样的地方。而且在这里也是大数据培训机构比较集中的地方，这里的机构有很多，其中相对比较专业的机构也有很多，大家可以选择到的几率也比较高。
具体的大家可以通过机构的师资、课程、学习环境以及就业情况等多方面的内容去对比选择，我相信总有一家是比较适合你的。
如果，确定了想要到北京学习大数据技术的话，大家可以到尚硅谷来进行了解一下。
学习大数据之前建议献血好计算机基础知识，否则如同聚沙成塔一般根基不稳。
具体到大数据本身，建议先掌握一些基本的工具，例如hive，Hadoop，hbase，es等，先做一些简单的数据分析。
个人学习经验，如果是我会先选择找一本入门的大数据相关的书籍，通读一遍，建立对大数据的一个概念。然后可以到b站或者慕课网等学习网站找视频资源，这类视频也有深有浅，看自己当时的情况有选择的看。最后，你想要更近一步的探究大数据，就应该找更专业的书籍或论文去研读，这一类论文可以到知网或者谷歌文献去找。
一、如何将商业运营问题转化为大数据挖掘问题
那么，问题来了，我们该如何把上述的商业运营问题转化为数据挖掘问题?可以对数据挖掘问题进行细分，分为四类问题：分类问题、聚类问题、关联问题、预测问题。
1、分类问题
用户流失率、促销活动响应、评估用户度都属于数据挖掘的分类问题，我们需要掌握分类的特点，知道什么是有监督学习，掌握常见的分类方法:决策树、贝叶斯、KNN、支持向量机、神经网络和逻辑回归等。
2、聚类问题
细分市场、细分客户群体都属于数据挖掘的聚类问题，我们要掌握聚类特点，知道无监督学习，了解常见的聚类算法，例如划分聚类、层次聚类、密度聚类、网格聚类、基于模型聚类等。
3、关联问题
交叉销售问题等属于关联问题，关联分析也叫购物篮分析，我们要掌握常见的关联分析算法：Aprior算法、Carma算法，序列算法等。
4、预测问题
我们要掌握简单线性回归分析、多重线性回归分析、时间序列等。
二、用何种工具实操大数据挖掘
能实现数据挖掘的工具和途径实在太多，SPSS、SAS、Python、R等等都可以，但是我们需要掌握哪个或者说要掌握哪几个，才算学会了数据挖掘?这需要看你所处的层次和想要进阶的路径是怎样的。
第一层级：达到理解入门层次
了解统计学和数据库即可。
第二层级：达到初级职场应用层次
数据库+统计学+SPSS(也可以是SPSS代替软件)
第三层级：达到中级职场应用层次
SAS或R
第四层级：达到数据挖掘师层次
SAS或R+Python(或其他编程语言)
三、如何利用Python学习大数据挖掘
只要能解决实际问题，用什么工具来学习数据挖掘都是无所谓，这里首推Python。那该如何利用Python来学习数据挖掘?需要掌握Python中的哪些知识?
1、Pandas库的操作
Panda是数据分析特别重要的一个库，我们要掌握以下三点：
pandas 分组计算;
pandas 索引与多重索引;
索引比较难，但是却是非常重要的
pandas 多表操作与数据透视表
2、numpy数值计算
numpy数据计算主要应用是在数据挖掘，对于以后的机器学习，深度学习，这也是一个必须掌握的库，我们要掌握以下内容：
Numpy array理解;
数组索引操作;
数组计算;
Broadcasting(线性代数里面的知识)
3、数据可视化-matplotlib与seaborn
Matplotib语法
python最基本的可视化工具就是matplotlib。咋一看Matplotlib与matlib有点像，要搞清楚二者的关系是什么，这样学习起来才会比较轻松。
seaborn的使用
seaborn是一个非常漂亮的可视化工具。
pandas绘图功能
前面说过pandas是做数据分析的，但它也提供了一些绘图的API。
4、数据挖掘入门
这部分是最难也是最有意思的一部分，要掌握以下几个部分：
机器学习的定义
在这里跟数据挖掘先不做区别
代价函数的定义
Train/Test/Validate
Overfitting的定义与避免方法
5、数据挖掘算法
数据挖掘发展到现在，算法已经非常多，下面只需掌握最简单的，最核心的，最常用的算法：
最小二乘算法;
梯度下降;
向量化;
极大似然估计;
Logistic Regression;
Decision Tree;
RandomForesr;
XGBoost;
6、数据挖掘实战
通过机器学习里面最著名的库scikit-learn来进行模型的理解。
以上，就是为大家理清的大数据挖掘学习思路逻辑。可是，这还仅仅是开始，在通往数据挖掘师与数据科学家路上，还要学习文本处理与自然语言知识、Linux与Spark的知识、深度学习知识等等，我们要保持持续的兴趣来学习数据挖掘。
网易云课堂
⑤ 大数据时代下的人群透视
人群透视又名人群分析，是按照用户的属性选取特定的人群，利用大数据的相关技术来探索数据背后的本质。常见的分析需求有观察特定地区的购买转化率、指定投放渠道新增用户数和转化率、发生业务行为的留存率等等。
我们先来看一个简单的例子，我们为昨天的活跃用户创建了一个指定的人群。产品人员想分析出用户中男性比例是否高于女性，利用相关的分析技术得到分布图。
未知是有些用户没有填写性别资料（利用身份证信息也可以自动补全或者通过其他的规则和模型识别）
读到这，想必大家对什么是人群透视有了一定的了解。那为什么要做人群透视？我先给大家描述一个场景，运营人员发送某个月的用户留存突然大幅降低了，看到这个数据后，接下来应该马上去找到是什么原因导致的。首先，运营人员会确认各个渠道的留存率情况（按照引流渠道进行人群的划分），发现某个渠道的新用户注册迅速增加，但留存率急剧下降；最后发现是由于渠道投放人员设置了针对特定人群的广告投放，但是这些用户却因为产品本身无法带来满足和愉悦而放弃。
上述就是一个由浅及深的人群透视分析场景，如果有这样一款数据分析工具，无需专业的数据分析师就能完成大部分的数据分析工作是不是很酷。
人群透视当前还有更多的场景。进行不同活动的效果分析对比、按照人群分析产品的走势、增长环节找到最优的决策点。
熟悉大数据相关或者数仓模型相关的同学肯定对事实表和维度表不陌生，事实表是指特定主题域下的业务行为，维度表中记录的是对某一个实体的描述信息。注册的行为表就是一张事实表，而用户画像表或者商品表我们可以称为维度表。人群透视就是按照用户属性维度表选取合适的取值来看在事实业务表上的表现情况。查看杭州地区女性的消费类型分布情况，其中“杭州地区女性”就是维度表的属性特征，消费类型则是消费记录事实表的记录。
首先明确我们要分析的业务指标。以渠道作为例子，我们想分析各个渠道的新用户增长、注册和登陆转化率情况。首先建立一张事实表，明确存储的粒度、业务字段集合。
按照渠道我们需要分析出每一个渠道的每天广告位点击情况、新增激活设备数、新增用户注册数、新增登陆用户数、设备激活转化率、注册激活转化率、登陆活跃用户转化率、激活成本、注册成本、活跃成本、总成本。
指标通常是数值类型，同时其计算规则应该满足可累性，比如sum、max、min、cnt，函数应该符合这样的关系:
f(A)=f(a,A-a) ，其中A是集合，a是A中的一个元素，即真对一个集合的计算可以进行迭代计算
比如mean、variance等就不是可累加的汇总函数
人群透视分析首先需要要按照属性圈选出人群集合，这是一个倒排索引的查询类别，市面上常用的倒排索引服务就是Eleastic Search。首先我们可以借助其倒排查询的能力快速勾选出用户ID列表。
指标的查询是一个正排索引查询的过程，根据用户ID查询出相应记录。常用的多维查询工具有Kylin、Druid、Presto、ES等，下面分别比较下各个框架的优缺点。
由于大部分的业务的转化需要一定时间的积累，大部分数据满足T+1的查询即可。同时T+1的数据可以利用数仓的数据直接进行汇总计算。如果一个业务分析指标的模型固定可以直接借助Kylin完成数据的分析存储。查询的指标如果是交互式、灵活多变的，则可以采用ES、Presto这样的存储查询方式。如上面的渠道分析模型，则直接可以采用Kylin进行存储。
目标：满足非大数据分析师日常的分析工作，帮助更快的发现问题、提出问题的方向和优先级、执行解决问题。另外提供一套标准的框架来便于用户导入合适的分析模型。
按照构建的生命周期我们可以分为五层，分别是人群指标定义、数据采集加工、数据存储、数据查询、数据图表化展示。
按照功能模块划分，我们可以得到如下架构图
场景的需求，明确要观察分析的业务场景和数据来源。渠道的注册转化分析需要收集广告的埋点点击、App的打开埋点、用户注册事件、点击成本统计等。最终借助于数据仓库加工成一张渠道转化事实表。同样的方式构建出渠道的维表信息。
人群 ：符合某一个属性取值的用户集合。如借贷用户群、理财用户群体等。
人群组 ：人群的组合，我们通常先真对不同的人群做对比，比如比较杭州和北京的借贷用户群，人群组的管理可以选取哪些维度作为区分条件组，地理位置、性别等等。人群组用户构建多维分析分析，划分组的属性列就是维度。对于一些连续数值列的属性可以按照区间值进行分类处理。
指标类型通常是数值的聚合函数，聚合函数最好要能满足可加性。
最常用的就是count，count函数无需构建在任何指标上，这种经常用于统计某一类人群的数量。
sum ：统计某一列的数值的集合
max/min ：统计数值最大/小的
distinct count ：去重的数目统计
可以先根据表选取明确的指标列（只能是数值列，count的话数值取值默认为1），再勾选对应的聚合函数。这里可以选取不同表的不同数值列。
某一类维度的选取占整个人群的占比，比如杭州地区的高收入人群的购买量。
对上提供一层通用的库、表结构管理，提供一套统一的SQL给应用层面，对外根据具体的物理表存储介质翻译为具体的物理查询计划。查询接口的请求和响应分装为统一的结果，不对外体现具体的存储细节。
dashboard的管理，可以为指定的人群创建一个指定的分析模板，同时可以进行图标的新增、修改、删除等操作。
图表类型 ：支持单维图表和二维图表。单维图表通常就是数量等，常见的有饼图、柱状图、仪表盘等
高级功能：选取一个图表，可以自己勾选要展示的维度（维度可以来源为维度表也可以来源于事实表，如时间可以来源于事实表）和指标，构建一个二维甚至是多维图形。
⑥ Es7.x使用RestHighLevelClient的3种分页实现
分页一般有三种方式：
Es封装RestHighLevelClient和BulkProcessor的工具类
上面意味着es需要在各个分片上匹配排序并得到5010条数据，协调节点拿到这些数据再进行排序，然后结果集中取最后10条数据返回。
上述语句性能低的原因：我们只需要10条数据，而es每个分片都需要执行from+size条数据然后处理后返回。
es为了性能，会限制我们分页的深度，es目前支持最大的max_result_window = 10000，也就是from+size的大小不能超过10000。
在es中我们分页要请求大数据集或者一次请求要获取大的数据集，scroll [skrəʊl] 都是一种非常好的解决方案。
scroll也是滚动搜索。会在第一次搜索的时候，保存一个当时的快照。之后只会基于该旧的视图快照提供数据搜索。在这个期间发生变动，是不会让用户看到的。
官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。
可以在实时的情况下处理深度分页，在Es5.x版本后提供的功能，search_after缺点是不能够随机跳转分页，只能是一页一页的向后翻，并且需要至少指定一个唯一不重复字段来排序。
注意：search_after必须指定一个唯一不重复的字段来排序，此处我们指定了两个字段进行排序，
该例子：id是唯一不重复字段，publishTime可能会重复。
注意，结果返回的sort字段，存储的是最后一组的排序字段的值，而search_after在下次搜索时，需要携带该数据。
最终完成了滚动分页操作。
Elasticsearch 深入理解search After 处理深度分页问题
elasticsearch深度分页问题
Es封装RestHighLevelClient和BulkProcessor的工具类
⑦ 企业如何进行大数据分析
1、数据存储和管理
MySQL数据库：部门和Internet公司通常使用MySQL存储数据，优点是它是免费的，并且性能，稳定性和体系结构也都比较好。
SQLServer：SQLServer2005或更高版本集成了商业智能功能，可为中小型企业提供数据管理，存储，数据报告和数据分析。
DB2和Oracle数据库是大型数据库，适用于拥有大量数据资源的企业。
2、数据清理类
EsDataClean是一种在线数据清理工具，不管是规则定义还是流程管理都无需编写sql或代码，通过图形化界面进行简单配置即可，使得非技术用户也能对定义过程和定义结果一目了然。
3、数据分析挖掘
豌豆DM更适合初学者。它易于操作且功能强大。它提供了完整的可视化建模过程，从训练数据集选择，分析索引字段设置，挖掘算法，参数配置，模型训练，模型评估，比较到模型发布都可以通过零编程和可视化配置操作，可以轻松简便地完成。
4.数据可视化类
亿信ABI是具有可视化功能的代表性工具。当然，它不仅是可视化工具，而且还是集数据分析、数据挖掘和报表可视化的一站式企业级大数据分析工具。
关于企业如何进行大数据分析，青藤小编就和您分享到这里了。如果你对大数据工程有浓厚的兴趣，希望这篇文章能够对你有所帮助。如果您还想了解更多数据分析师、大数据工程师的技巧及素材等内容，可以点击本站的其他文章进行学习。
⑧ 大数据查询解决方案——ES
2016-11-16
周祝群
第一次上培训课听得一脸懵逼！
ES，全称 Elastic Search ，是一个基于 Lucene 的开源搜索引擎。
核心概念：
Cluster 集群
Node 节点（主节点、数据节点、其他）
Index
Type
Document
Shards&Replicas
Create
Delete
Update(创建新文档，老文档标记删除)
Retrieve
ES查询为什么快？
参考资料：
全文搜索之 Elasticsearch
一分钟教你知道乐观锁和悲观锁的区别
⑨ 大数据分析工具面临哪些挑战
大数据发展的挑战：
目前大数据的发展依然存在诸多挑战，包括七大方面的挑战：业务部门没有清晰的大数据需求导致数据资产逐渐流失;企业内部数据孤岛严重，导致数据价值不能充分挖掘;数据可用性低，数据质量差，导致数据无法利用;数据相关管理技术和架构落后，导致不具备大数据处理能力;数据安全能力和防范意识差，导致数据泄露;大数据人才缺乏导致大数据工作难以开展;大数据越开放越有价值，但缺乏大数据相关的政策法规，导致数据开放和隐私之间难以平衡，也难以更好的开放。
挑战一：业务部门没有清晰的大数据需求
很多企业业务部门不了解大数据，也不了解大数据的应用场景和价值，因此难以提出大数据的准确需求。由于业务部门需求不清晰，大数据部门又是非盈利部门，企业决策层担心投入比较多的成本，导致了很多企业在搭建大数据部门时犹豫不决，或者很多企业都处于观望尝试的态度，从根本上影响了企业在大数据方向的发展，也阻碍了企业积累和挖掘自身的数据资产，甚至由于数据没有应用场景，删除很多有价值历史数据，导致企业数据资产流失。因此，这方面需要大数据从业者和专家一起，推动和分享大数据应用场景，让更多的业务人员了解大数据的价值。
挑战二：企业内部数据孤岛严重
企业启动大数据最重要的挑战是数据的碎片化。在很多企业中尤其是大型的企业，数据常常散落在不同部门，而且这些数据存在不同的数据仓库中，不同部门的数据技术也有可能不一样，这导致企业内部自己的数据都没法打通。如果不打通这些数据，大数据的价值则非常难挖掘。大数据需要不同数据的关联和整合才能更好的发挥理解客户和理解业务的优势。如何将不同部门的数据打通，并且实现技术和工具共享，才能更好的发挥企业大数据的价值。
挑战三：数据可用性低，数据质量差
很多中型以及大型企业，每时每刻也都在产生大量的数据，但很多企业在大数据的预处理阶段很不重视，导致数据处理很不规范。大数据预处理阶段需要抽取数据把数据转化为方便处理的数据类型，对数据进行清洗和去噪，以提取有效的数据等操作。甚至很多企业在数据的上报就出现很多不规范不合理的情况。以上种种原因，导致企业的数据的可用性差，数据质量差，数据不准确。而大数据的意义不仅仅是要收集规模庞大的数据信息，还有对收集到的数据进行很好的预处理处理，才有可能让数据分析和数据挖掘人员从可用性高的大数据中提取有价值的信息。Sybase的数据表明，高质量的数据的数据应用可以显著提升企业的商业表现，数据可用性提高10%，企业的业绩至少提升在10%以上。
挑战四：数据相关管理技术和架构
技术架构的挑战包含以下几方面：(1)传统的数据库部署不能处理TB级别的数据，快速增长的数据量超越了传统数据库的管理能力。如何构建分布式的数据仓库，并可以方便扩展大量的服务器成为很多传统企业的挑战;(2)很多企业采用传统的数据库技术，在设计的开始就没有考虑数据类别的多样性，尤其是对结构化数据、半结构化和非结构化数据的兼容;(3)传统企业的数据库，对数据处理时间要求不高，这些数据的统计结果往往滞后一天或两天才能统计出来。但大数据需要实时处理数据，进行分钟级甚至是秒级计算。传统的数据库架构师缺乏实时数据处理的能力;(4)海量的数据需要很好的网络架构，需要强大的数据中心来支撑，数据中心的运维工作也将成为挑战。如何在保证数据稳定、支持高并发的同时，减少服务器的低负载情况，成为海量数据中心运维的一个重点工作。
挑战五：数据安全
网络化生活使得犯罪分子更容易获得关于人的信息，也有了更多不易被追踪和防范的犯罪手段，可能会出现更高明的骗局。如何保证用户的信息安全成为大数据时代非常重要的课题。在线数据越来越多，黑客犯罪的动机比以往都来的强烈，一些知名网站密码泄露、系统漏洞导致用户资料被盗等个人敏感信息泄露事件已经警醒我们，要加强大数据网络安全的建设。另外，大数据的不断增加，对数据存储的物理安全性要求会越来越高，从而对数据的多副本与容灾机制也提出更高的要求。目前很多传统企业的数据安全令人担忧。
挑战六：大数据人才缺乏
大数据建设的每个环节都需要依靠专业人员完成，因此，必须培养和造就一支掌握大数据技术、懂管理、有大数据应用经验的大数据建设专业队伍。目前大数据相关人才的欠缺将阻碍大数据市场发展。据Gartner预测，到2015年，全球将新增440万个与大数据相关的工作岗位，且会有25%的组织设立首席数据官职位。大数据的相关职位需要的是复合型人才，能够对数学、统计学、数据分析、机器学习和自然语言处理等多方面知识综合掌控。未来，大数据将会出现约100万的人才缺口，在各个行业大数据中高端人才都会成为最炙手可热的人才，涵盖了大数据的数据开发工程师、大数据分析师、数据架构师、大数据后台开发工程师、算法工程师等多个方向。因此需要高校和企业共同努力去培养和挖掘。目前最大的问题是很多高校缺乏大数据，所以拥有大数据的企业应该与学校联合培养人才。
挑战七：数据开放与隐私的权衡
在大数据应用日益重要的今天，数据资源的开放共享已经成为在数据大战中保持优势的关键。商业数据和个人数据的共享应用，不仅能促进相关产业的发展，也能给我们的生活带来巨大的便利。由于政府、企业和行业信息化系统建设往往缺少统一规划，系统之间缺乏统一的标准，形成了众多“信息孤岛”，而且受行政垄断和商业利益所限，数据开放程度较低，这给数据利用造成极大障碍。另外一个制约我国数据资源开放和共享的一个重要因素是政策法规不完善，大数据挖掘缺乏相应的立法。无法既保证共享又防止滥用。因此，建立一个良性发展的数据共享生态系统，是我国大数据发展需要迈过去的一道砍。同时，开放与隐私如何平衡，也是大数据开放过程中面临的最大难题。如何在推动数据全面开放、应用和共享的同时有效地保护公民、企业隐私，逐步加强隐私立法，将是大数据时代的一个重大挑战。