Elastic 寻找优秀的您

ElasticON16-Group-Photo-small.jpg

想不想去最棒的开源软件公司工作?
想不想不用朝9晚5浪费大量时间在路上,在家就能办公?
想不想让您的代码运行在成千上万台服务器上面,拯救世界?
想不想工作与生活的完美结合,做自己感兴趣的事情?
... ...
那考虑来Elastic吧,与全球顶尖工程师一起合作,福利待遇从优,一年至少2次出国机会。
基本要求:
  • 英语流利沟通
  • 掌握现代开发技术
  • 贡献过Elastic相关开源项目者优先

下面是热招职位,位置不限,Anywhere!


除了上面这些,还有很多其他市场商务类,
查看 Elastic 全部在招职位信息,点击这里

关于 Elastic
Elastic 致力于构建大规模实时数据处理软件,场景主要涵盖搜索、日志、安全与数据分析等领域。公司成立于 2012 年,旗下拥有产品:开源的 Elastic Stack(Elasticsearch、Kibana、Beats 和 Logstash)、 X-Pack (商业特性)和 Elastic Cloud (一个 SaaS 服务)。迄今为止,这些产品的累积下载次数已超过 1 亿。
成千上万的企业包括思科、易趣、高盛、美国宇航局、微软、梅约诊所、纽约时报、维基百科以及微讯通信等都在使用 Elastic 来助力其关键业务应用。 
Elastic 由 Benchmark Capital、Index Ventures 及 NEA 投资,投资额超过 1 亿美金。Elastic 拥有超过 500 位员工,分布于世界上 30 多个国家和地区。了解更多请访问: elastic.co 。
 
继续阅读 »
ElasticON16-Group-Photo-small.jpg

想不想去最棒的开源软件公司工作?
想不想不用朝9晚5浪费大量时间在路上,在家就能办公?
想不想让您的代码运行在成千上万台服务器上面,拯救世界?
想不想工作与生活的完美结合,做自己感兴趣的事情?
... ...
那考虑来Elastic吧,与全球顶尖工程师一起合作,福利待遇从优,一年至少2次出国机会。
基本要求:
  • 英语流利沟通
  • 掌握现代开发技术
  • 贡献过Elastic相关开源项目者优先

下面是热招职位,位置不限,Anywhere!


除了上面这些,还有很多其他市场商务类,
查看 Elastic 全部在招职位信息,点击这里

关于 Elastic
Elastic 致力于构建大规模实时数据处理软件,场景主要涵盖搜索、日志、安全与数据分析等领域。公司成立于 2012 年,旗下拥有产品:开源的 Elastic Stack(Elasticsearch、Kibana、Beats 和 Logstash)、 X-Pack (商业特性)和 Elastic Cloud (一个 SaaS 服务)。迄今为止,这些产品的累积下载次数已超过 1 亿。
成千上万的企业包括思科、易趣、高盛、美国宇航局、微软、梅约诊所、纽约时报、维基百科以及微讯通信等都在使用 Elastic 来助力其关键业务应用。 
Elastic 由 Benchmark Capital、Index Ventures 及 NEA 投资,投资额超过 1 亿美金。Elastic 拥有超过 500 位员工,分布于世界上 30 多个国家和地区。了解更多请访问: elastic.co 。
  收起阅读 »

【急聘】搜索推荐系统研发工程师 12-20K

岗位职责:

1,负责个性化推荐系统的算法和架构研发, 实现在相关产品中的精准推荐;

2,负责产品、内容的推荐与其他场景的基础数据挖掘;

3,根据海量用户行为的分析和挖掘,构建用户画像、标签系统等。

 
任职要求:

1、两年以上相关工作经验;

2、有推荐系统或搜索排序研发经验, 熟悉常用的推荐算法,有实际算法调优经验;

3、熟悉Hadoop、HBase、Spark、Kafka等计算平台和工具;

4、掌握自然语言处理、协同推荐算法方面的基本知识;

5、良好的沟通和学习能力,团队合作精神,能独立承担工作。

 
加分项:

1,有大规模海量数据机器学习、数据挖掘、计算广告、搜索引擎相关经验;

2,有互联网电商行业数据经验。


易所试集团(Www.liketry.com),新三板上市公司,市值10亿左右,组建北京研发中心,13薪起,正常基数五险一金并提供商业保险(补充医疗+意外等),10天年假起,弹性工作制,薪资可根据能力商议。工作地点:北京望京SOHO,简历请发送至邮箱:hang.song@liketry.com。
继续阅读 »
岗位职责:

1,负责个性化推荐系统的算法和架构研发, 实现在相关产品中的精准推荐;

2,负责产品、内容的推荐与其他场景的基础数据挖掘;

3,根据海量用户行为的分析和挖掘,构建用户画像、标签系统等。

 
任职要求:

1、两年以上相关工作经验;

2、有推荐系统或搜索排序研发经验, 熟悉常用的推荐算法,有实际算法调优经验;

3、熟悉Hadoop、HBase、Spark、Kafka等计算平台和工具;

4、掌握自然语言处理、协同推荐算法方面的基本知识;

5、良好的沟通和学习能力,团队合作精神,能独立承担工作。

 
加分项:

1,有大规模海量数据机器学习、数据挖掘、计算广告、搜索引擎相关经验;

2,有互联网电商行业数据经验。


易所试集团(Www.liketry.com),新三板上市公司,市值10亿左右,组建北京研发中心,13薪起,正常基数五险一金并提供商业保险(补充医疗+意外等),10天年假起,弹性工作制,薪资可根据能力商议。工作地点:北京望京SOHO,简历请发送至邮箱:hang.song@liketry.com。 收起阅读 »

【携程招聘】高级搜索研发工程师

岗位职责:
负责参与搜索业务的系统架构及研发,对现有搜索业务系统进行改进和优化
1.负责搜索服务端的开发工作; 
2. 负责分词,索引和查询的算法优化;
3.研究数据的存储、传输,优化系统架构,不断提升系统时效性、灵活性及性能;
4. 对代码和设计质量有严格要求,重视Code Review,知道良好编程习惯的标准;
5. 参与搜索系统分布式架构设计,研究分布式信息检索的服务架构,分析和修改相关性算法、策略,构建高性能,灵活易调研的分布式检索系统。

任职要求:
1. 计算机或相关专业本科及以上学历,2年以上搜索引擎相关的研发经验;
2. 有自然语言处理、相关性算法、rerank等经验者或数据挖掘实践经验者优先;
3. 深刻理解企业应用设计模式,有大型分布式,高并发,高负载,高可用性系统设计开发经验;
4. 有扎实的Java基础(熟悉io、多线程、集合等基础框架,熟悉分布式、缓存、消息、搜索等机制) ;
5. 熟悉Elasticsearch 对分布式搜索有一定实战经验;
6. 对互联网产品敏感,学习能力强
7. 熟悉数理统计和机器学习的基础理论,并有一定的实战经验者优先(可选);
8. 熟悉常见机器学习排序方法,如:GBDT、LTR或随机森林,熟悉特征处理方法者优先(可选);
 
薪酬范围:  
10k - 20k /月 + 年终奖 
 
有意者邮件联系: ckjiang@ctrip.com 
继续阅读 »
岗位职责:
负责参与搜索业务的系统架构及研发,对现有搜索业务系统进行改进和优化
1.负责搜索服务端的开发工作; 
2. 负责分词,索引和查询的算法优化;
3.研究数据的存储、传输,优化系统架构,不断提升系统时效性、灵活性及性能;
4. 对代码和设计质量有严格要求,重视Code Review,知道良好编程习惯的标准;
5. 参与搜索系统分布式架构设计,研究分布式信息检索的服务架构,分析和修改相关性算法、策略,构建高性能,灵活易调研的分布式检索系统。

任职要求:
1. 计算机或相关专业本科及以上学历,2年以上搜索引擎相关的研发经验;
2. 有自然语言处理、相关性算法、rerank等经验者或数据挖掘实践经验者优先;
3. 深刻理解企业应用设计模式,有大型分布式,高并发,高负载,高可用性系统设计开发经验;
4. 有扎实的Java基础(熟悉io、多线程、集合等基础框架,熟悉分布式、缓存、消息、搜索等机制) ;
5. 熟悉Elasticsearch 对分布式搜索有一定实战经验;
6. 对互联网产品敏感,学习能力强
7. 熟悉数理统计和机器学习的基础理论,并有一定的实战经验者优先(可选);
8. 熟悉常见机器学习排序方法,如:GBDT、LTR或随机森林,熟悉特征处理方法者优先(可选);
 
薪酬范围:  
10k - 20k /月 + 年终奖 
 
有意者邮件联系: ckjiang@ctrip.com  收起阅读 »

es中的jdbc,如何使用多次的lastexecutionstart.

在jdbc中,如果需要多少使用到时间的值。如果使用lastexecutionstart,分了两次查询,time不一致。对于初始化和热更新都不一致。例如:
sql : [
{ "statement" : "select * from table1 where mytimestamp > ?", "parameter" : [ "$metrics.lastexecutionstart" ] },
{ "statement" : "select * from table2 where mytimestamp > ?", "parameter" : [ "$metrics.lastexecutionstart" ] }
    ],
继续阅读 »
在jdbc中,如果需要多少使用到时间的值。如果使用lastexecutionstart,分了两次查询,time不一致。对于初始化和热更新都不一致。例如:
sql : [
{ "statement" : "select * from table1 where mytimestamp > ?", "parameter" : [ "$metrics.lastexecutionstart" ] },
{ "statement" : "select * from table2 where mytimestamp > ?", "parameter" : [ "$metrics.lastexecutionstart" ] }
    ], 收起阅读 »

[热招]饿了么搜索推荐研发部招聘信息

饿了么搜索推荐研发部现热招搜索相关人才
投递方式:wei.chen04@ele.me
QQ:2908368828
岗位福利:定期技术分享,良好的技术氛围,超级nice的leader,五险一金+补充商业保险等多种福利政策
薪资:行业内有竞争力的薪资
坐标:上海市普陀区金沙江路,13号线真北路下,地铁出来即是,大热天不怕晒
 

一、搜索架构工程师
岗位职责:

1、负责在线搜索服务的稳定性,性能,时效性和扩展性;
2、负责构建一套能快速满足多种业务检索需求的通用搜索平台;
3、负责分布式搜索服务架构设计、开发与优化、稳定性监控和维护;
4、关注行业搜索技术,引进和改善搜索架构;

职位要求:
1、本科以上学历 ,3年以上搜索相关工作经验
2、精通Lucene、Elastic Search开发和实战,能够修改Lucene、Elastic Search源代码
3、精通高可用、高并发分布式系统设计,有熟悉分布式搜索系统的架构和运维经验者有些
4、熟练掌握多线程,线程池技术,对网络通信、异步通信、高并发访问、负载均衡等技术有深入了解
5、具有高度的抽象设计能力,思路清晰,善于思考,能独立驱动、分析和解决问题
6、责任心强,良好的沟通交流、团队合作精神、以结果为导向

二、高级搜索工程师(Elasticsearch)

    岗位职责:
 1、参与平台化的各类搜索相关的功能;
 2、参与系统的设计和核心代码的编写;
 3、明确搜索业务需求,按时完成指定模块的设计与开发,并确保质量;
 4、对自己的代码要求严格,并对已有模块进行优化升级;
 5、搜索算法研究及实现,搜索相关扩展应用研发;
 6、善于思考,能解决复杂的ES性能调优问题。

任职要求:
 1、211本科以上学历,计算机或者相关专业;
 2、至少一年Elasticsearch开发经验,一年Java开发经验;
 3、掌握搜索引擎基本原理、相关检索、排序算法和数据结构,良好的数据结构基础;
 4、熟悉Java开发语言,熟悉Spring MVC、iBatis、netty等主流框架,熟练使用eclipse等开发工具;
 5、熟悉MySQL数据库应用;
 6、熟悉lucene,ELK生态,大数据平台优先;
 7、对技术富有激情,对新技术有了解,思路清晰;
 8、工作态度积极、踏实、认真,有责任感,有团队合作意识;
 
 
欢迎大家推荐或者自荐~





 
继续阅读 »
饿了么搜索推荐研发部现热招搜索相关人才
投递方式:wei.chen04@ele.me
QQ:2908368828
岗位福利:定期技术分享,良好的技术氛围,超级nice的leader,五险一金+补充商业保险等多种福利政策
薪资:行业内有竞争力的薪资
坐标:上海市普陀区金沙江路,13号线真北路下,地铁出来即是,大热天不怕晒
 

一、搜索架构工程师
岗位职责:

1、负责在线搜索服务的稳定性,性能,时效性和扩展性;
2、负责构建一套能快速满足多种业务检索需求的通用搜索平台;
3、负责分布式搜索服务架构设计、开发与优化、稳定性监控和维护;
4、关注行业搜索技术,引进和改善搜索架构;

职位要求:
1、本科以上学历 ,3年以上搜索相关工作经验
2、精通Lucene、Elastic Search开发和实战,能够修改Lucene、Elastic Search源代码
3、精通高可用、高并发分布式系统设计,有熟悉分布式搜索系统的架构和运维经验者有些
4、熟练掌握多线程,线程池技术,对网络通信、异步通信、高并发访问、负载均衡等技术有深入了解
5、具有高度的抽象设计能力,思路清晰,善于思考,能独立驱动、分析和解决问题
6、责任心强,良好的沟通交流、团队合作精神、以结果为导向

二、高级搜索工程师(Elasticsearch)

    岗位职责:
 1、参与平台化的各类搜索相关的功能;
 2、参与系统的设计和核心代码的编写;
 3、明确搜索业务需求,按时完成指定模块的设计与开发,并确保质量;
 4、对自己的代码要求严格,并对已有模块进行优化升级;
 5、搜索算法研究及实现,搜索相关扩展应用研发;
 6、善于思考,能解决复杂的ES性能调优问题。

任职要求:
 1、211本科以上学历,计算机或者相关专业;
 2、至少一年Elasticsearch开发经验,一年Java开发经验;
 3、掌握搜索引擎基本原理、相关检索、排序算法和数据结构,良好的数据结构基础;
 4、熟悉Java开发语言,熟悉Spring MVC、iBatis、netty等主流框架,熟练使用eclipse等开发工具;
 5、熟悉MySQL数据库应用;
 6、熟悉lucene,ELK生态,大数据平台优先;
 7、对技术富有激情,对新技术有了解,思路清晰;
 8、工作态度积极、踏实、认真,有责任感,有团队合作意识;
 
 
欢迎大家推荐或者自荐~





  收起阅读 »

Kibana 新的可视化插件:Vega

Vega:
https://vega.github.io/vega/examples/
 
Vega是什么?
相比其他第三方可视化库,Vega的目的是让你更快将数据进行展现,vega通过声明的方式可以快速将你的数据进行各种格式化,而不用纠结于具体的调用细节,和SQL这种通用式交互语言类似,数据的输入是JSON。

Snip20170718_1.png

 
Vega的Kibana插件下载地址:
https://github.com/nyurik/kibana-vega-vis/releases
 
安装之后,就能在可视化类型里面选择Vega了,使用起来很简单,输入相应的描叙语言,如:
{
"$schema": "https://vega.github.io/schema/ ... ot%3B,
"description": "A simple bar chart with embedded data.",
"width": 300, "height": 200, "padding": 5,
"data": {
"values": [
{"a": "A","b": 28}, {"a": "B","b": 55}, {"a": "C","b": 43},
{"a": "D","b": 91}, {"a": "E","b": 81}, {"a": "F","b": 53},
{"a": "G","b": 19}, {"a": "H","b": 87}, {"a": "I","b": 52}
]
},
"mark": "bar",
"encoding": {
"x": {"field": "a", "type": "ordinal"},
"y": {"field": "b", "type": "quantitative"}
}
}
Vega支持各种可视化类型,更多详情请参照文档和例子:
https://vega.github.io/vega-li ... k-def
https://vega.github.io/vega/examples/
https://github.com/nyurik/kiba ... -demo
继续阅读 »
Vega:
https://vega.github.io/vega/examples/
 
Vega是什么?
相比其他第三方可视化库,Vega的目的是让你更快将数据进行展现,vega通过声明的方式可以快速将你的数据进行各种格式化,而不用纠结于具体的调用细节,和SQL这种通用式交互语言类似,数据的输入是JSON。

Snip20170718_1.png

 
Vega的Kibana插件下载地址:
https://github.com/nyurik/kibana-vega-vis/releases
 
安装之后,就能在可视化类型里面选择Vega了,使用起来很简单,输入相应的描叙语言,如:
{
"$schema": "https://vega.github.io/schema/ ... ot%3B,
"description": "A simple bar chart with embedded data.",
"width": 300, "height": 200, "padding": 5,
"data": {
"values": [
{"a": "A","b": 28}, {"a": "B","b": 55}, {"a": "C","b": 43},
{"a": "D","b": 91}, {"a": "E","b": 81}, {"a": "F","b": 53},
{"a": "G","b": 19}, {"a": "H","b": 87}, {"a": "I","b": 52}
]
},
"mark": "bar",
"encoding": {
"x": {"field": "a", "type": "ordinal"},
"y": {"field": "b", "type": "quantitative"}
}
}
Vega支持各种可视化类型,更多详情请参照文档和例子:
https://vega.github.io/vega-li ... k-def
https://vega.github.io/vega/examples/
https://github.com/nyurik/kiba ... -demo 收起阅读 »

spark1.6.3+elasticsearch5.4 netty jar冲突

spark1.6.x   elasticsearch5.x  
 
netty冲突
 
(Netty4Utils:117)-NoSuchMethodError io.netty.buffer.CompositeByteBuf.addComponents(ZLjava/lang/Iterable;)Lio/netty/buffer/CompositeByteBuf;
at org.elasticsearch.transport.netty4.Netty4Utils.toByteBuf(Netty4Utils.Java:78)
at org.elasticsearch.transport.netty4.Netty4Transport.sendMessage(Netty4Transport.java:422)
at org.elasticsearch.transport.netty4.Netty4Transport.sendMessage(Netty4Transport.java:93)
at org.elasticsearch.transport.TcpTransport.internalSendMessage(TcpTransport.java:1058)
at org.elasticsearch.transport.TcpTransport.sendRequestToChannel(TcpTransport.java:1040)
 试过其他jar排除方案都不生效,暂时可以fix的解决方案
 
```
.put("transport.type","netty3")
```
继续阅读 »
spark1.6.x   elasticsearch5.x  
 
netty冲突
 
(Netty4Utils:117)-NoSuchMethodError io.netty.buffer.CompositeByteBuf.addComponents(ZLjava/lang/Iterable;)Lio/netty/buffer/CompositeByteBuf;
at org.elasticsearch.transport.netty4.Netty4Utils.toByteBuf(Netty4Utils.Java:78)
at org.elasticsearch.transport.netty4.Netty4Transport.sendMessage(Netty4Transport.java:422)
at org.elasticsearch.transport.netty4.Netty4Transport.sendMessage(Netty4Transport.java:93)
at org.elasticsearch.transport.TcpTransport.internalSendMessage(TcpTransport.java:1058)
at org.elasticsearch.transport.TcpTransport.sendRequestToChannel(TcpTransport.java:1040)
 试过其他jar排除方案都不生效,暂时可以fix的解决方案
 
```
.put("transport.type","netty3")
``` 收起阅读 »

招兼职Cassandra培训讲师


企业培训公司面向单位员工培训,长期招Cassandra兼职老师,一般三天左右的短周期培训,周末为主,有2人左右的小辅导,也有30人左右的培训大班,待遇优,北京,上海,成都,广州,深圳等,如您想挣点外块,积累资源,充实生活,请联系我。 

要求:
相关技术专业,本科及以上学历; 
三年以上实际项目经验; 
认真,热情,耐心,乐于助人,不保守,表达能力较好。具体再议。 

感兴趣的可以联系:QQ 2355811930 ;QQ1489302364,微信15501239699,简历接收邮箱:admin@info-soft.cn 
 
 
 
继续阅读 »

企业培训公司面向单位员工培训,长期招Cassandra兼职老师,一般三天左右的短周期培训,周末为主,有2人左右的小辅导,也有30人左右的培训大班,待遇优,北京,上海,成都,广州,深圳等,如您想挣点外块,积累资源,充实生活,请联系我。 

要求:
相关技术专业,本科及以上学历; 
三年以上实际项目经验; 
认真,热情,耐心,乐于助人,不保守,表达能力较好。具体再议。 

感兴趣的可以联系:QQ 2355811930 ;QQ1489302364,微信15501239699,简历接收邮箱:admin@info-soft.cn 
 
 
  收起阅读 »

智慧芽诚聘高级搜索工程师20-30K(C轮互联网Saas)

职位描述【工作职责】:
1、负责搜索系统分布式架构设计、搭建、维护和优化;
2、负责分词,索引和查询的算法优化,提高查全率和搜索性能;
3、负责搜索服务端的开发工作,融合大数据平台实现个性化搜索,完成各种垂直搜索应用的开发;
4、负责内容的数据挖掘,分析与挖掘各种潜在关联,分析特征,建议模型,优化现有的排序结果;
5、搜索服务的线上部署和维护,监控搜索服务的运行状态;

【岗位要求】:
1. 熟悉搜索引擎原理和机制,熟练撑握搜索引擎技术,有丰富的搜索引擎相关的研发经验,对算法设计、数据结构有深刻的理解;
2. 熟悉Solr、Elasticsearch等开源搜索技术及mysql、redis等数据库,能够胜任搜索引擎应用技术的研究与开发、设计与架构能力;
3. 熟悉LINUX操作命令及Python、SHELL脚本编写;
4、对数据敏感,具备优秀的逻辑思维,对解决挑战性问题充满热情,善于独立解决问题和分析问题;
5. 在用户行为挖掘上有相关研究和专业积累;有较好的创新能力;
6. 良好的团队合作精神,较强的沟通能力;
7. 实践过自然语言处理、数据挖掘、机器学习者优先;
8. 有信息提取和大型搜索索引建立、排序算法、query优化经验者优先;
 
有意者请发简历至 yuezhitao@patsnap.com

【加入我们,你可以得到什么?】
你可以得到国际化的视野,可以和国外的同事和客户进行交流沟通
你可以跟随公司快速成长,从“前台”到“总裁”的华丽变身不再是梦想
你可以学习和应用最新最酷的技术,我们鼓励学习创新,而不是重复使用过时效率差的技术
你不需要定时打卡,不用担心迟到扣钱,因为我们是弹性工作制
你不需要担心五险一金,因为我们完全按照规定缴纳,员工还可以享受年假、病假、婚假、丧假、产假等带薪休假,另外我们还有补充商业保险

【为什么选择我们?】
1. 公司前景:整个大环境对知识产权的重视,除了现有业务增长迅猛,还在新兴业务上积极布局
2. 办公地点:坐落于上海静安区黄金地段,CBD中的CBD
3. 交通方便:地铁五线环绕(1,3,4,12,13),步行10分钟之内可到,数十多路公交车近在咫尺
4. 工作环境:开放,明亮。无限量供应的饮料和零食,可以让你迅速成为胖纸! Mac Pro, Surface Pro, 大屏显示器各种标配。

【我们是谁?】
或许现在你对专利市场还感到陌生,或许你还并不了解知识产权的重要性,但互联网时代,“IP”这个热词你一定有所听说,且耳熟能详。看看身边高精尖的技术产品,被百姓津津乐道的新能源汽车,到酷炫的无人驾驶,还有风靡持久的日本电饭煲……无不持续着、保护着、更迭着他们的IP技术。

崛起的IP界应证着这样一句话: 
21世纪一定是知识经济的时代,科技创新更是知识经济时代的灵魂——
而PatSnap智慧芽,正立旨于为科技创新指路。

PatSnap是全球领先的专利分析与管理平台,公司致力于让全球更多组织机构了解并使用专利。PatSnap通过提供强大又易用的专利工具,帮助客户从专利中获取有价值的资讯,从而促进客户的商业化过程,加速研发进度,确定重要技术发展方向,最终提高客户在行业内的核心竞争力。

PatSnap通过位于新加坡,中国苏州,英国伦敦的三家分公司,业务辐射全球上千家企业,客户中不乏 IBM ,美国国立卫生研究院,美国国防部,MIT(麻省理工学院)以及新加坡国立大学等知名企业及团体。

目前我们已经获得C轮融资,在近期的在德勤亚太区高科技高成长500强企业中获得第44位的优质排名。德勤高科技高成长500强是亚太区内享负盛名的高科技企业评选活动。本次评选基于过去三年企业的收入增长百分比而定,智慧芽在这段时期内增长了1078%!
 
有意者请发简历至 yuezhitao@patsnap.com
继续阅读 »
职位描述【工作职责】:
1、负责搜索系统分布式架构设计、搭建、维护和优化;
2、负责分词,索引和查询的算法优化,提高查全率和搜索性能;
3、负责搜索服务端的开发工作,融合大数据平台实现个性化搜索,完成各种垂直搜索应用的开发;
4、负责内容的数据挖掘,分析与挖掘各种潜在关联,分析特征,建议模型,优化现有的排序结果;
5、搜索服务的线上部署和维护,监控搜索服务的运行状态;

【岗位要求】:
1. 熟悉搜索引擎原理和机制,熟练撑握搜索引擎技术,有丰富的搜索引擎相关的研发经验,对算法设计、数据结构有深刻的理解;
2. 熟悉Solr、Elasticsearch等开源搜索技术及mysql、redis等数据库,能够胜任搜索引擎应用技术的研究与开发、设计与架构能力;
3. 熟悉LINUX操作命令及Python、SHELL脚本编写;
4、对数据敏感,具备优秀的逻辑思维,对解决挑战性问题充满热情,善于独立解决问题和分析问题;
5. 在用户行为挖掘上有相关研究和专业积累;有较好的创新能力;
6. 良好的团队合作精神,较强的沟通能力;
7. 实践过自然语言处理、数据挖掘、机器学习者优先;
8. 有信息提取和大型搜索索引建立、排序算法、query优化经验者优先;
 
有意者请发简历至 yuezhitao@patsnap.com

【加入我们,你可以得到什么?】
你可以得到国际化的视野,可以和国外的同事和客户进行交流沟通
你可以跟随公司快速成长,从“前台”到“总裁”的华丽变身不再是梦想
你可以学习和应用最新最酷的技术,我们鼓励学习创新,而不是重复使用过时效率差的技术
你不需要定时打卡,不用担心迟到扣钱,因为我们是弹性工作制
你不需要担心五险一金,因为我们完全按照规定缴纳,员工还可以享受年假、病假、婚假、丧假、产假等带薪休假,另外我们还有补充商业保险

【为什么选择我们?】
1. 公司前景:整个大环境对知识产权的重视,除了现有业务增长迅猛,还在新兴业务上积极布局
2. 办公地点:坐落于上海静安区黄金地段,CBD中的CBD
3. 交通方便:地铁五线环绕(1,3,4,12,13),步行10分钟之内可到,数十多路公交车近在咫尺
4. 工作环境:开放,明亮。无限量供应的饮料和零食,可以让你迅速成为胖纸! Mac Pro, Surface Pro, 大屏显示器各种标配。

【我们是谁?】
或许现在你对专利市场还感到陌生,或许你还并不了解知识产权的重要性,但互联网时代,“IP”这个热词你一定有所听说,且耳熟能详。看看身边高精尖的技术产品,被百姓津津乐道的新能源汽车,到酷炫的无人驾驶,还有风靡持久的日本电饭煲……无不持续着、保护着、更迭着他们的IP技术。

崛起的IP界应证着这样一句话: 
21世纪一定是知识经济的时代,科技创新更是知识经济时代的灵魂——
而PatSnap智慧芽,正立旨于为科技创新指路。

PatSnap是全球领先的专利分析与管理平台,公司致力于让全球更多组织机构了解并使用专利。PatSnap通过提供强大又易用的专利工具,帮助客户从专利中获取有价值的资讯,从而促进客户的商业化过程,加速研发进度,确定重要技术发展方向,最终提高客户在行业内的核心竞争力。

PatSnap通过位于新加坡,中国苏州,英国伦敦的三家分公司,业务辐射全球上千家企业,客户中不乏 IBM ,美国国立卫生研究院,美国国防部,MIT(麻省理工学院)以及新加坡国立大学等知名企业及团体。

目前我们已经获得C轮融资,在近期的在德勤亚太区高科技高成长500强企业中获得第44位的优质排名。德勤高科技高成长500强是亚太区内享负盛名的高科技企业评选活动。本次评选基于过去三年企业的收入增长百分比而定,智慧芽在这段时期内增长了1078%!
 
有意者请发简历至 yuezhitao@patsnap.com 收起阅读 »

关于Elasticsearch性能优化的几点问题

本次分享主要包含两个方面的实战经验:索引性能和查询性能。
一. 索引性能(Index Performance)
首先要考虑的是,索引性能是否有必要做优化?
索引速度提高与否?主要是看瓶颈在什么地方,若是 Read DB(产生DOC)的速度比较慢,那瓶颈不在 ElasticSearch 时,优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢,查下来是新版 IK 分词的问题,修改分词插件后得到解决。
如果需要优化,应该如何优化?
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度,每天进行优化还是很有必要的。在初次索引的时候,把 replica 设置为 0,也能提高索引速度。
bulk 是不是一定需要呢?
若是 Elasticsearch 普通索引已经导致高企的 LA,IO 压力已经见顶,这时候 bulk 也无法提供帮助,SSD 应该是很好的选择。
在 create doc 速度能跟上的时候,bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++,不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度:index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能(Query Perofrmance)
王道是什么?routing,routing,还是 routing。
我们为了提高查询速度,减少慢查询,结合自己的业务实践,使用多个集群,每个集群使用不同的 routing。比如,用户是一个routing维度。
在实践中,这个routing 非常重要。
我们碰到一种情况,想把此维度的查询(即用户查询)引到非用户routing 的集群,结果集群完全顶不住!
在大型的本地分类网站中,城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询,把各个不同查询分别引入合适的集群。这样做以后,每个集群只需要很少的机器,而且保持很小的 CPU Usage 和 LA。从而查询速度够快,慢查询几乎消灭。
分合?
分别(索引和routing)查询和合并(索引和routing)查询,即此分合的意思。
索引越来越大,单个 shard 也很巨大,查询速度也越来越慢。这时候,是选择分索引还是更多的shards?
在实践过程中,更多的 shards 会带来额外的索引压力,即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引,或者主要的大城市一个索引。然后将他们进行合并查询。如:http://cluster1:9200/shanghai,beijing/_search?routing=fang,自动将查询中城市属性且值为上海或北京的查询,且是房类目的,引入集群 cluster1,并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引,我们使用城市做 routing,如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search,全部城市查询。
再如: http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息,那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards?
除了有 IO 压力,而且不能进行全部城市或全部类目查询,因为完全顶不住。
Elastic 官方文档建议:一个 Node 最好不要多于三个 shards。
若是 "more shards”,除了增加更多的机器,是没办法做到这一点的。
分索引,虽然一个 Node 总的shards 还是挺多的,但是一个索引可以保持3个以内的shards。
我们使用分索引时,全量查询是可以顶住的,虽然压力有点儿高。
索引越来越大,资源使用也越来越多。若是要进行更细的集群分配,大索引使用的资源成倍增加。
有什么办法能减小索引?显然,创建 doc 时,把不需要的 field 去掉是一个办法;但是,这需要对业务非常熟悉。
有啥立竿见影的办法?
根据我们信息的特点,内容(field:description)占了索引的一大半,那我们就不把 description 索引进 ES,doc 小了一倍,集群也小了一倍,所用的资源(Memory, HD or SSD, Host, snapshot存储,还有时间)大大节省,查询速度自然也更快。
那要查 description 怎么办?
上面的实例中,我们可以把查询引入不同集群,自然我们也可以把 description 查询引入一个非实时(也可以实时)集群,这主要是我们业务特点决定的,因为description查询所占比例非常小,使得我们可以这样做。
被哪些查询搞过?第一位是 Range 查询,这货的性能真不敢恭维。在最热的查询中,若是有这货,肯定是非常痛苦的,网页变慢,查询速度变慢,集群 LA 高企,严重的时候会导致集群 shard 自动下线。所以,建议在最热的查询中避免使用 Range 查询。
Facet 查询,在后续版本这个被 aggregations 替代,我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed,使用 cached 有可能控制不好。主要是比较大的分片 relocation时,会导致分片自动下线,集群可能处于危险状态。在集群高压时,若是 cached ,分片也可能自动下线。自 1.4 版本后,我们就一直 fixed,至于新版是否还存在这个问题,就没再试验了。
两个原因:一是 routing王道带来的改善,使得集群一直低压运行;二是使用fixed 后,已经极少遇到自动下线shard了。
我们前面说过,user 是一个非常好的维度。这个维度很重要,routing 效果非常明显。其他维度,需要根据业务特点,进行组合。
所以我们的集群一直是低压运行,就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的,一般默认是够用了,可以尝试提高。
2)优化
每天优化是有好处的,可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长,但是在高峰期前能完成的话,会对查询性能有很大好处。
3) JVM GC的选择:选择 G1还是 CMS?
应该大多数人还是选择了 CMS,我们使用的经验是 G1 和 CMS 比较接近;但和 CMS 相比,还是有一点距离,至少在我们使用经验中是如此。
JVM 32G 现象?
128G内存的机器配置一个 JVM,然后是巨大的 heapsize (如64G)?
还是配多个 JVM instance,较小的 heapsize(如32G)?
我的建议是后者。实际使用中,后者也能帮助我们节省不少资源,并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" (https://www.elastic.co/guide/e ... _oops
跨 32G 时,有一个现象,使用更多的内存,比如 40G,效果还不如31G!
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true,比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize,加上SSD?我听说有人使用过,效果还不错,当然,我们自己还没试过。
4)插件工具
推荐 kopf,是一个挺不错的工具,更新及时,功能完备,可以让你忘掉很多 API :)。



上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ,慢慢要忘光了:)
索引,查询,和一些重要的配置,是今天分享的重点。

Q&A
Q1:您建议生产环境JVM采用什么样的参数设置?FULL GC频率和时间如何?
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2:生产环境服务器如何配置性价比较高?单机CPU核数、主频?内存容量?磁盘容量?
内存大一些,CPU 多核是必要的,JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题,很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3: 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算,怎么实现?应用如果需要实时进行统计而且并发量较大,如何优化?
因为我们是网站系统,所以对于 Facet 请求,引导到后端慢慢计算,前端初始的时候可能没数据,但是此后就会有了。
如果是精确要求的话,那就只能从 提高 facet 查询性能去下手,比如 routing、filter、cache、更多的内存...
Q4:存进Elasticsearch的数据,timestamp是UTC时间,Elasticsearch集群会在UTC 0点,也就是北京时间早上8点自动执行优化?如何改参数设置这个时间?
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5:我的Java程序,log4j2 Flume appender,然后机器上的Flume agent ,直接Elasticsearch 的sink avro到 es节点上,多少个agent 连在单个Elasticsearch节点比较合适 ?
ElasticSearch本身是一个分布式计算集群,所以,请求平均分配到每个 node 即可。
Q6:我代码里直接用 Java API 生成Flume appender 格式,Flume agent 里interceptor去拆分几个字段,这样是不是太累了?比较推荐的做法是不是还是各业务点自己控制字段,调用Elasticsearch API 生成索引内容?
业务点自己控制生成的文档吧?如果需要产生不同routing,并且分了索引,这些其实是业务相关的。routing和不同索引,都是根据业务情况哪些查询比较集中而进行处理的。
Q7:您见过或管理过的生产环境的Elasticsearch数据量多大?
我们使用 Elasticsearch 进行某些业务处理,数据量过亿。
Q8:SSD性能提升多少?
SSD 对索引帮助非常大,效果当当的,提高几十倍应该是没问题。不过,我们没有试过完全使用SSD顶查询,而是使用内存,内存性价比还是不错的。
Q9:我们现在有256个shard,用uid做routing,所有查询都是走routing。每个shard有30多G,每次扩容很慢,有什么建议?
可以考虑使用分合查询吗? 或者使用更多的维度? 256个 shard 确实比较难以控制。但是如果是分索引和查询,比more shards(256) 效果应该会好不少。
Q10:Elasticsearch排序等聚合类的操作需要用到fielddata,查询时很慢。新版本中doc values聚合查询操作性能提升很大,你们有没有用过?
Facet 查询需要更大的内存,更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet,建议尽快替换原来的facet API。
Q11:Elasticsearch配置bootstrap.mlockall,我们在使用中发现会导致启动很慢,因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的,启动慢的原因也许是内存没有有效释放过,比如文件 cached了。 内存充足的情况下,启动速度还是蛮快的,可以接受。 JVM 和 Lucene 都需要内存,一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12:优化是一个开销比较大的操作,每天优化的时候是否会导致查询不可用?如何优化这块?
优化是开销很大的。不会导致查询不可用。优化是值得的,大量的碎片会导致查询性能大大降低。 如果非常 care 查询,可以考虑多个集群。在优化时,查询 skip 这个集群就可以。
Q13:Elasticsearch适合做到10亿级数据查询,每天千万级的数据实时写入或更新吗?
10亿是可以做到的,如果文档轻量,10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ,进行日志处理每天千万是小case吧?
不过我们除了使用 ELK 进行日志处理,还进行业务处理,10亿级快速查询是可以做到,不过,需要做一些工作,比如索引和shards的分分合合:)
Q14:Elasticsearch相比Solr有什么优势吗?
我们当年使用 Solr 的时候,Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ,省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高,更新版本是和Lucene一起的,这是个优点。
很多年没用 Solr了,毕竟那时候数据量还不大,所以折腾的就少了,主要还是折腾 JVM。所以,就不再过多的比较了。
Q15:分词用的什么组件?Elasticsearch自带的吗?
我们使用 IK 分词,不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。:)
Q16: reindex有没有好的方法?
reindex 这个和 Lucene 有关,它的 update 就是 delete+ add。
Q17:以上面的两个例子为例 : 是存储多份同样的数据么?
是两个集群。第一个集群使用大城市分索引,不过,还有大部分小城市合并一个索引。大城市还是用类目进行routing,小城市合并的索引就使用城市进行routing 。
第二个集群,大类分得索引,比如fang、che,房屋和车辆和其他类目在一个集群上,他们使用 city+二级类目做routing。
Q18:集群部署有没有使用 Docker ? 我们使用的时候 ,同一个服务器 节点之间的互相发现没有问题 ,但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群,跨IP段的时候是有这个需要。
Q19:您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群,怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性?
我们以前使用 php在web代码中进行索引和分析 query,然后引导到不同集群。 现在我们开发了一套go rest系统——4sea,使用 redis + elastic 以综合提高性能。
索引时,更新db的同时,提交一个文档 ID 通知4sea 进行更新,然后根据配置更新到不同集群。
数据提交到查询时,就是分析 query 并引导到不同集群。
这套 4sea 系统,有机会的可以考虑开源,不算很复杂的。
Q20: 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗?
“段”合并?,我们是根据业务特点,产生几个不一样的集群,主要还是 routing 不一样。
shards 比较平均很重要的,所以选择routing 维度是难点,选择城市的话,大城市所在分片会非常大,此时可以考虑 分索引,几个大城市几个索引,然后小城市合并一个索引。
如果 shards 大小分布平均的话,就不关心如何 allocation 了。
Q21:关于集群rebalance,其实就是cluster.routing.allocation配置下的那些rebalance相关的设置,比如allow_rebalance/cluster_concurrent_rebalance/node_initial_primaries_recoveries,推荐怎么配置?
分片多的情况下,这个才是需要的吧。
分片比较少时,allow_rebalance disable,然后手动也可以接受的。
分片多,一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance (多个 Elasticsearch node)的话,我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下,再改成默认就好了。
node_initial_primaries_recoveries,在保证集群低压的情况下,不怎么care。
kopf 上面有好多这种配置,你可以多试试。
Q22:合并查询是异步请求还是同步请求?做缓存吗?
合并查询是 Elasticsearch 自带 API。
Q23:用http url connection请求的时候,会发现返回请求很耗时,一般怎么处理?
尽可能减少慢查询吧?我们很多工作就是想办法如何减少慢查询,routing和分分合合,就是这个目的。
Q24:生产环境单个节点存储多少G数据?
有大的,有小的。小的也几十G了。不过根据我们自己的业务特点,某些集群就去掉了全文索引。唯一的全文索引,使用基本的routing(比较平衡的routing,比如user。城市的话,就做不到平衡了,因为大城市数据很多),然后做了 快照,反正是增量快照,1小时甚至更短时间都可以考虑!!!去掉全文索引的其他业务集群,就小多了。
 
继续阅读 »
本次分享主要包含两个方面的实战经验:索引性能和查询性能。
一. 索引性能(Index Performance)
首先要考虑的是,索引性能是否有必要做优化?
索引速度提高与否?主要是看瓶颈在什么地方,若是 Read DB(产生DOC)的速度比较慢,那瓶颈不在 ElasticSearch 时,优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢,查下来是新版 IK 分词的问题,修改分词插件后得到解决。
如果需要优化,应该如何优化?
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度,每天进行优化还是很有必要的。在初次索引的时候,把 replica 设置为 0,也能提高索引速度。
bulk 是不是一定需要呢?
若是 Elasticsearch 普通索引已经导致高企的 LA,IO 压力已经见顶,这时候 bulk 也无法提供帮助,SSD 应该是很好的选择。
在 create doc 速度能跟上的时候,bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++,不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度:index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能(Query Perofrmance)
王道是什么?routing,routing,还是 routing。
我们为了提高查询速度,减少慢查询,结合自己的业务实践,使用多个集群,每个集群使用不同的 routing。比如,用户是一个routing维度。
在实践中,这个routing 非常重要。
我们碰到一种情况,想把此维度的查询(即用户查询)引到非用户routing 的集群,结果集群完全顶不住!
在大型的本地分类网站中,城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询,把各个不同查询分别引入合适的集群。这样做以后,每个集群只需要很少的机器,而且保持很小的 CPU Usage 和 LA。从而查询速度够快,慢查询几乎消灭。
分合?
分别(索引和routing)查询和合并(索引和routing)查询,即此分合的意思。
索引越来越大,单个 shard 也很巨大,查询速度也越来越慢。这时候,是选择分索引还是更多的shards?
在实践过程中,更多的 shards 会带来额外的索引压力,即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引,或者主要的大城市一个索引。然后将他们进行合并查询。如:http://cluster1:9200/shanghai,beijing/_search?routing=fang,自动将查询中城市属性且值为上海或北京的查询,且是房类目的,引入集群 cluster1,并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引,我们使用城市做 routing,如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search,全部城市查询。
再如: http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息,那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards?
除了有 IO 压力,而且不能进行全部城市或全部类目查询,因为完全顶不住。
Elastic 官方文档建议:一个 Node 最好不要多于三个 shards。
若是 "more shards”,除了增加更多的机器,是没办法做到这一点的。
分索引,虽然一个 Node 总的shards 还是挺多的,但是一个索引可以保持3个以内的shards。
我们使用分索引时,全量查询是可以顶住的,虽然压力有点儿高。
索引越来越大,资源使用也越来越多。若是要进行更细的集群分配,大索引使用的资源成倍增加。
有什么办法能减小索引?显然,创建 doc 时,把不需要的 field 去掉是一个办法;但是,这需要对业务非常熟悉。
有啥立竿见影的办法?
根据我们信息的特点,内容(field:description)占了索引的一大半,那我们就不把 description 索引进 ES,doc 小了一倍,集群也小了一倍,所用的资源(Memory, HD or SSD, Host, snapshot存储,还有时间)大大节省,查询速度自然也更快。
那要查 description 怎么办?
上面的实例中,我们可以把查询引入不同集群,自然我们也可以把 description 查询引入一个非实时(也可以实时)集群,这主要是我们业务特点决定的,因为description查询所占比例非常小,使得我们可以这样做。
被哪些查询搞过?第一位是 Range 查询,这货的性能真不敢恭维。在最热的查询中,若是有这货,肯定是非常痛苦的,网页变慢,查询速度变慢,集群 LA 高企,严重的时候会导致集群 shard 自动下线。所以,建议在最热的查询中避免使用 Range 查询。
Facet 查询,在后续版本这个被 aggregations 替代,我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed,使用 cached 有可能控制不好。主要是比较大的分片 relocation时,会导致分片自动下线,集群可能处于危险状态。在集群高压时,若是 cached ,分片也可能自动下线。自 1.4 版本后,我们就一直 fixed,至于新版是否还存在这个问题,就没再试验了。
两个原因:一是 routing王道带来的改善,使得集群一直低压运行;二是使用fixed 后,已经极少遇到自动下线shard了。
我们前面说过,user 是一个非常好的维度。这个维度很重要,routing 效果非常明显。其他维度,需要根据业务特点,进行组合。
所以我们的集群一直是低压运行,就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的,一般默认是够用了,可以尝试提高。
2)优化
每天优化是有好处的,可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长,但是在高峰期前能完成的话,会对查询性能有很大好处。
3) JVM GC的选择:选择 G1还是 CMS?
应该大多数人还是选择了 CMS,我们使用的经验是 G1 和 CMS 比较接近;但和 CMS 相比,还是有一点距离,至少在我们使用经验中是如此。
JVM 32G 现象?
128G内存的机器配置一个 JVM,然后是巨大的 heapsize (如64G)?
还是配多个 JVM instance,较小的 heapsize(如32G)?
我的建议是后者。实际使用中,后者也能帮助我们节省不少资源,并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" (https://www.elastic.co/guide/e ... _oops
跨 32G 时,有一个现象,使用更多的内存,比如 40G,效果还不如31G!
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true,比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize,加上SSD?我听说有人使用过,效果还不错,当然,我们自己还没试过。
4)插件工具
推荐 kopf,是一个挺不错的工具,更新及时,功能完备,可以让你忘掉很多 API :)。



上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ,慢慢要忘光了:)
索引,查询,和一些重要的配置,是今天分享的重点。

Q&A
Q1:您建议生产环境JVM采用什么样的参数设置?FULL GC频率和时间如何?
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2:生产环境服务器如何配置性价比较高?单机CPU核数、主频?内存容量?磁盘容量?
内存大一些,CPU 多核是必要的,JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题,很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3: 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算,怎么实现?应用如果需要实时进行统计而且并发量较大,如何优化?
因为我们是网站系统,所以对于 Facet 请求,引导到后端慢慢计算,前端初始的时候可能没数据,但是此后就会有了。
如果是精确要求的话,那就只能从 提高 facet 查询性能去下手,比如 routing、filter、cache、更多的内存...
Q4:存进Elasticsearch的数据,timestamp是UTC时间,Elasticsearch集群会在UTC 0点,也就是北京时间早上8点自动执行优化?如何改参数设置这个时间?
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5:我的Java程序,log4j2 Flume appender,然后机器上的Flume agent ,直接Elasticsearch 的sink avro到 es节点上,多少个agent 连在单个Elasticsearch节点比较合适 ?
ElasticSearch本身是一个分布式计算集群,所以,请求平均分配到每个 node 即可。
Q6:我代码里直接用 Java API 生成Flume appender 格式,Flume agent 里interceptor去拆分几个字段,这样是不是太累了?比较推荐的做法是不是还是各业务点自己控制字段,调用Elasticsearch API 生成索引内容?
业务点自己控制生成的文档吧?如果需要产生不同routing,并且分了索引,这些其实是业务相关的。routing和不同索引,都是根据业务情况哪些查询比较集中而进行处理的。
Q7:您见过或管理过的生产环境的Elasticsearch数据量多大?
我们使用 Elasticsearch 进行某些业务处理,数据量过亿。
Q8:SSD性能提升多少?
SSD 对索引帮助非常大,效果当当的,提高几十倍应该是没问题。不过,我们没有试过完全使用SSD顶查询,而是使用内存,内存性价比还是不错的。
Q9:我们现在有256个shard,用uid做routing,所有查询都是走routing。每个shard有30多G,每次扩容很慢,有什么建议?
可以考虑使用分合查询吗? 或者使用更多的维度? 256个 shard 确实比较难以控制。但是如果是分索引和查询,比more shards(256) 效果应该会好不少。
Q10:Elasticsearch排序等聚合类的操作需要用到fielddata,查询时很慢。新版本中doc values聚合查询操作性能提升很大,你们有没有用过?
Facet 查询需要更大的内存,更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet,建议尽快替换原来的facet API。
Q11:Elasticsearch配置bootstrap.mlockall,我们在使用中发现会导致启动很慢,因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的,启动慢的原因也许是内存没有有效释放过,比如文件 cached了。 内存充足的情况下,启动速度还是蛮快的,可以接受。 JVM 和 Lucene 都需要内存,一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12:优化是一个开销比较大的操作,每天优化的时候是否会导致查询不可用?如何优化这块?
优化是开销很大的。不会导致查询不可用。优化是值得的,大量的碎片会导致查询性能大大降低。 如果非常 care 查询,可以考虑多个集群。在优化时,查询 skip 这个集群就可以。
Q13:Elasticsearch适合做到10亿级数据查询,每天千万级的数据实时写入或更新吗?
10亿是可以做到的,如果文档轻量,10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ,进行日志处理每天千万是小case吧?
不过我们除了使用 ELK 进行日志处理,还进行业务处理,10亿级快速查询是可以做到,不过,需要做一些工作,比如索引和shards的分分合合:)
Q14:Elasticsearch相比Solr有什么优势吗?
我们当年使用 Solr 的时候,Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ,省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高,更新版本是和Lucene一起的,这是个优点。
很多年没用 Solr了,毕竟那时候数据量还不大,所以折腾的就少了,主要还是折腾 JVM。所以,就不再过多的比较了。
Q15:分词用的什么组件?Elasticsearch自带的吗?
我们使用 IK 分词,不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。:)
Q16: reindex有没有好的方法?
reindex 这个和 Lucene 有关,它的 update 就是 delete+ add。
Q17:以上面的两个例子为例 : 是存储多份同样的数据么?
是两个集群。第一个集群使用大城市分索引,不过,还有大部分小城市合并一个索引。大城市还是用类目进行routing,小城市合并的索引就使用城市进行routing 。
第二个集群,大类分得索引,比如fang、che,房屋和车辆和其他类目在一个集群上,他们使用 city+二级类目做routing。
Q18:集群部署有没有使用 Docker ? 我们使用的时候 ,同一个服务器 节点之间的互相发现没有问题 ,但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群,跨IP段的时候是有这个需要。
Q19:您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群,怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性?
我们以前使用 php在web代码中进行索引和分析 query,然后引导到不同集群。 现在我们开发了一套go rest系统——4sea,使用 redis + elastic 以综合提高性能。
索引时,更新db的同时,提交一个文档 ID 通知4sea 进行更新,然后根据配置更新到不同集群。
数据提交到查询时,就是分析 query 并引导到不同集群。
这套 4sea 系统,有机会的可以考虑开源,不算很复杂的。
Q20: 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗?
“段”合并?,我们是根据业务特点,产生几个不一样的集群,主要还是 routing 不一样。
shards 比较平均很重要的,所以选择routing 维度是难点,选择城市的话,大城市所在分片会非常大,此时可以考虑 分索引,几个大城市几个索引,然后小城市合并一个索引。
如果 shards 大小分布平均的话,就不关心如何 allocation 了。
Q21:关于集群rebalance,其实就是cluster.routing.allocation配置下的那些rebalance相关的设置,比如allow_rebalance/cluster_concurrent_rebalance/node_initial_primaries_recoveries,推荐怎么配置?
分片多的情况下,这个才是需要的吧。
分片比较少时,allow_rebalance disable,然后手动也可以接受的。
分片多,一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance (多个 Elasticsearch node)的话,我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下,再改成默认就好了。
node_initial_primaries_recoveries,在保证集群低压的情况下,不怎么care。
kopf 上面有好多这种配置,你可以多试试。
Q22:合并查询是异步请求还是同步请求?做缓存吗?
合并查询是 Elasticsearch 自带 API。
Q23:用http url connection请求的时候,会发现返回请求很耗时,一般怎么处理?
尽可能减少慢查询吧?我们很多工作就是想办法如何减少慢查询,routing和分分合合,就是这个目的。
Q24:生产环境单个节点存储多少G数据?
有大的,有小的。小的也几十G了。不过根据我们自己的业务特点,某些集群就去掉了全文索引。唯一的全文索引,使用基本的routing(比较平衡的routing,比如user。城市的话,就做不到平衡了,因为大城市数据很多),然后做了 快照,反正是增量快照,1小时甚至更短时间都可以考虑!!!去掉全文索引的其他业务集群,就小多了。
  收起阅读 »