本文同步发布在腾讯云+社区Elasticsearch专栏中：https://cloud.tencent.com/developer/column/4008
在“当Elasticsearch遇见Kafka--Logstash kafka input插件”一文中，我对Logstash的Kafka input插件进行了简单的介绍，并通过实际操作的方式，为大家呈现了使用该方式实现Kafka与Elastisearch整合的基本过程。可以看出使用Logstash input插件的方式，具有配置简单，数据处理方便等优点。然而使用Logstash Kafka插件并不是Kafka与Elsticsearch整合的唯一方案，另一种比较常见的方案是使用Kafka的开源组件Kafka Connect。

1 Kafka Connect简介

Kafka Connect是Kafka的开源组件Confluent提供的功能，用于实现Kafka与外部系统的连接。Kafka Connect同时支持分布式模式和单机模式，另外提供了一套完整的REST接口，用于查看和管理Kafka Connectors，还具有offset自动管理，可扩展等优点。

Kafka connect分为企业版和开源版，企业版在开源版的基础之上提供了监控，负载均衡，副本等功能，实际生产环境中建议使用企业版。(本测试使用开源版)

Kafka connect workers有两种工作模式，单机模式和分布式模式。在开发和适合使用单机模式的场景下，可以使用standalone模式, 在实际生产环境下由于单个worker的数据压力会比较大，distributed模式对负载均和和扩展性方面会有很大帮助。（本测试使用standalone模式）

关于Kafka Connect的详细情况可以参考[Kafka Connect]

2 使用Kafka Connect连接Kafka和Elasticsearch

2.1 测试环境准备

本文与使用Logstash Kafka input插件环境一样[传送门]，组件列表如下

kafka topic也复用原来了的kafka_es_test

2.2 Kafka Connect 安装

[Kafka Connec下载地址]

本文下载的为开源版本confluent-oss-5.0.1-2.11.tar.gz，下载后解压

2.3 Worker配置

1) 配置参考

如前文所说,worker分为Standalone和Distributed两种模式，针对两种模式的配置，参考如下

[通用配置]

[Standalone Woker配置]

[Distributed Worker配置]

此处需要注意的是Kafka Connect默认使用AvroConverter，使用该AvroConverter时需要注意必须启动Schema Registry服务

2) 实际操作

本测试使用standalone模式，因此修改/root/confluent-5.0.1/etc/schema-registry/connect-avro-standalone.properties

bootstrap.servers=192.168.13.10:9092

2.4 Elasticsearch Connector配置

1) 配置参考

[Connectors通用配置]

[Elasticsearch Configuration Options]

2) 实际操作

修改/root/confluent-5.0.1/etc/kafka-connect-elasticsearch/quickstart-elasticsearch.properties

name=elasticsearch-sink
connector.class=io.confluent.connect.elasticsearch.ElasticsearchSinkConnector
tasks.max=1
topics=kafka_es_test
key.ignore=true
connection.url=http://192.168.0.8:9200
type.name=kafka-connect

注意: 其中topics不仅对应Kafka的topic名称，同时也是Elasticsearch的索引名，当然也可以通过topic.index.map来设置从topic名到Elasticsearch索引名的映射

2.5 启动connector

1 注意事项

1) 由于配置文件中jar包位置均采用的相对路径，因此建议在confluent根目录下执行命令和启动程序，以避免不必要的问题

2) 如果前面没有修改converter，仍采用AvroConverter, 注意需要在启动connertor前启动Schema Registry服务

2 启动Schema Registry服务

正如前文所说，由于在配置worker时指定使用了AvroConverter，因此需要启动Schema Registry服务。而该服务需要指定一个zookeeper地址或Kafka地址，以存储schema数据。由于CKafka不支持用户通过接口形式创建topic，因此需要在本机起一个kafka以创建名为_schema的topic。

1) 启动Zookeeper

./bin/zookeeper-server-start -daemon etc/kafka/zookeeper.properties

2) 启动kafka

./bin/kafka-server-start -daemon etc/kafka/server.properties

3) 启动schema Registry

./bin/schema-registry-start -daemon etc/schema-registry/schema-registry.properties

4) 使用netstat -natpl 查看各服务端口是否正常启动

zookeeper 2181

kafka 9092

schema registry 8081

3 启动Connector

./bin/connect-standalone -daemon  etc/schema-registry/connect-avro-standalone.properties etc/kafka-connect-elasticsearch/quickstart-elasticsearch.properties

ps：以上启动各服务均可在logs目录下找到对应日志

2.6 启动Kafka Producer

由于我们采用的是AvroConverter，因此不能采用Kafka工具包中的producer。Kafka Connector bin目录下提供了Avro Producer

1) 启动Producer

./bin/kafka-avro-console-producer --broker-list 192.168.13.10:9092 --topic kafka_es_test --property value.schema='{"type":"record","name":"person","fields":[{"name":"nickname","type":"string"}]}'

2) 输入如下数据

{"nickname":"michel"}
{"nickname":"mushao"}

2.7 Kibana验证结果

1) 查看索引

在kibana Dev Tools的Console中输入

GET _cat/indices

结果

green open kafka_es_test 36QtDP6vQOG7ubOa161wGQ 5 1 1 0 7.9kb 3.9kb
green open .kibana       QUw45tN0SHqeHbF9-QVU6A 1 1 1 0 5.5kb 2.7kb

可以看到名为kafka_es_test的索引被成功创建

2) 查看数据

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 2,
    "max_score": 1,
    "hits": [
      {
        "_index": "kafka_es_test",
        "_type": "kafka-connect",
        "_id": "kafka_es_test+0+0",
        "_score": 1,
        "_source": {
          "nickname": "michel"
        }
      },
      {
        "_index": "kafka_es_test",
        "_type": "kafka-connect",
        "_id": "kafka_es_test+0+1",
        "_score": 1,
        "_source": {
          "nickname": "mushao"
        }
      }
    ]
  }
}

可以看到数据已经被成功写入

3 Confluent CLI

3.1 简介

查阅资料时发现很多文章都是使用Confluent CLI启动Kafka Connect，然而官方文档已经明确说明了该CLI只是适用于开发阶段，不能用于生产环境。

它可以一键启动包括zookeeper，kafka，schema registry, kafka rest, connect等在内的多个服务。但是这些服务对于Kafka Connect都不是必须的，如果不使用AvroConverter，则只需要启动Connect即可。即使使用了AvroConverter, 也只需要启动schema registry，将schema保存在远端的kafka中。Kafka Connect REST API也只是为用户提供一个管理connector的接口，也不是必选的。

另外使用CLI启动默认配置为启动Distributed的Connector，需要通过环境变量来修改配置

3.2 使用Confluent CLI

confluent CLI提供了丰富的命令，包括服务启动，服务停止，状态查询，日志查看等，详情参考如下简介视频 [Introducing the Confluent CLI | Screencast]

1) 启动

./bin/confluent start

2) 检查confluent运行状态

./bin/confluent status

当得到如下结果则说明confluent启动成功

ksql-server is [UP]
connect is [UP]
kafka-rest is [UP]
schema-registry is [UP]
kafka is [UP]
zookeeper is [UP]

3) 问题定位

如果第二步出现问题，可以使用log命令查看，如connect未启动成功则

./bin/confluent log connect

4) 加载Elasticsearch Connector

a) 查看connector

./bin/confluent list connectors

结果

Bundled Predefined Connectors (edit configuration under etc/):
elasticsearch-sink
file-source
file-sink
jdbc-source
jdbc-sink
hdfs-sink
s3-sink

b) 加载Elasticsearch connector

./bin/confluent load elasticsearch-sink

结果

{
    "name": "elasticsearch-sink",
    "config": {
        "connector.class": "io.confluent.connect.elasticsearch.ElasticsearchSinkConnector",
        "tasks.max": "1",
        "topics": "kafka_es_test",
        "key.ignore": "true",
        "connection.url": "http://192.168.0.8:9200",
        "type.name": "kafka-connect",
        "name": "elasticsearch-sink"
    },
    "tasks": [],
    "type": null
}

5) 使用producer生产数据，并使用kibana验证是否写入成功

4 Kafka Connect Rest API

Kafka Connect提供了一套完成的管理Connector的接口，详情参考[Kafka Connect REST Interface]。该接口可以实现对Connector的创建，销毁，修改，查询等操作

1) GET connectors 获取运行中的connector列表

2) POST connectors 使用指定的名称和配置创建connector

3) GET connectors/(string:name) 获取connector的详细信息

4) GET connectors/(string:name)/config 获取connector的配置

5) PUT connectors/(string:name)/config 设置connector的配置

6) GET connectors/(string:name)/status 获取connector状态

7) POST connectors/(stirng:name)/restart 重启connector

8) PUT connectors/(string:name)/pause 暂停connector

9) PUT connectors/(string:name)/resume 恢复connector

10) DELETE connectors/(string:name)/ 删除connector

11) GET connectors/(string:name)/tasks 获取connectors任务列表

12) GET /connectors/(string: name)/tasks/(int: taskid)/status 获取任务状态

13) POST /connectors/(string: name)/tasks/(int: taskid)/restart 重启任务

14) GET /connector-plugins/ 获取已安装插件列表

15) PUT /connector-plugins/(string: name)/config/validate 验证配置

5 总结

Kafka Connect是Kafka一个功能强大的组件，为kafka提供了与外部系统连接的一套完整方案，包括数据传输，连接管理，监控，多副本等。相对于Logstash Kafka插件，功能更为全面，但配置也相对为复杂些。有文章提到其性能也优于Logstash Kafka Input插件，如果对写入性能比较敏感的场景，可以在实际压测的基础上进行选择。另外由于直接将数据从Kafka写入Elasticsearch, 如果需要对文档进行处理时，选择Logstash可能更为方便。

1. 如何迁移到kibana空间 http://t.cn/E2yMhZi

2. 利用kibana空间优化管理权限。 http://t.cn/E2yJq1b

3. Elasitcsearch索引优化。 http://t.cn/E2y6afZ

• 编辑：bsll

• 归档：https://elasticsearch.cn/article/6139

• 订阅：https://tinyletter.com/elastic-daily

1. ES 设置
2. 配置 TLS/SSL
3. 配置ES（x-pack认证）
4. 启动ES
5. 配置密码
6. 配置kibana

xpack.monitoring.enabled: true
xpack.graph.enabled: true
xpack.ml.enabled: true
xpack.security.enabled: true
xpack.watcher.enabled: true
xpack.security.authc.accept_default_password: false
xpack.security.transport.ssl.enabled: true
xpack.monitoring.collection.cluster.stats.timeout: 30m
xpack.monitoring.collection.index.stats.timeout: 30m
xpack.monitoring.collection.index.recovery.active_only: true
xpack.monitoring.collection.index.recovery.timeout: 30m
xpack.monitoring.history.duration: 3650d

2018 Elastic中国开发者大会前一天，我参加了Elastic认证工程师考试，隔天在大会的闪电演讲部分做了一个快速的分享。 昨天考试结果下来了，比较遗憾，没能通过。 不过这次参考心得颇多，值得专门写一篇文总结一下，帮助准备考认证的同学少走一点弯路。

考试内容

官方有一个考试要求达到的目标提纲Objectives， 其中涵盖的知识点还是比较广的，建议每个点都要根据文档操作演练一下。 我考前几天大致扫了一下提纲，感觉基本上都熟悉，没有仔细一一演练。 到了考试的时候，才发现有几个知识点只是浮于表面的了解，细节并不熟悉，临时去读文档时间又不够。

考试环境

用自己的电脑，登陆到考试网站，有一个远程桌面连接到考试虚拟机。虚拟机上原装了5个ES集群，结点数量各异。 桌面提供有一个浏览器，可以访问kibana和官方文档站点，还有一个终端，可以ssh到集群各个结点。 考试所有操作基本都是在kibana的sense和这个终端里完成， 期间只允许访问官方文档，不允许通过Google查找解决方案。 我们是现场考试，人工监考。 常规的考试是通过摄像头远程监考的，并且需要安装一个插件，检查后台进程。 按照规定，自己的机器只能开浏览器，不允许开evernotes等其他辅助工具。 远程桌面的速度不是很快，在浏览器里翻看文档会感觉有些卡顿，所以要求对文档非常熟悉，一查即准，否则来回翻页都会消耗不少时间。最好用鼠标，翻页会容易得多，我没带鼠标，用MAC的触摸板翻页，非常痛苦。 另外用Mac的同学，要适应一下拷贝粘贴快捷键，考试机器拷贝粘贴用的是ctrl-c / ctrl-v ，用惯了Mac的快捷键会有些不适应。

考试时长

3个小时，期间可以上厕所，但是建议考前少喝水，上好厕所，时间宝贵。

考题形式

12道考题全部是上机题，每道题描述一个场景，要求解决问题或者达到某个目标。 每道题都会涉及到考试提纲里2-3个知识点，所以对各个知识点细节的了解非常重要， 只要一个知识点理解的模糊，就容易卡住。 做题顺序可以自己控制，最好先把自己熟悉，马上能搞定的先做了，耗时超过10分钟还没把握的，先放一放最后再做把。这12道题我只完成了其中的9个，有3个在现场卡了比较长时间，因为时间不够放弃， 接下来的部分会做更细节的分析。

亲历考题类型总结

1. 给一个状态是red的集群，要求不损失数据的前提下，让集群变green。
   该题我遇到3个要解决的问题:

   • 有一个结点挂了，找到挂掉的结点，ssh上去，手动起来；
   • 此时集群变成yellow，还是有shard不能分配，检查发现有一个索引的routings设置里，routing ->include里rack1写成了rakc1，故意写错的，修正好即可
   • 集群依然还有shard是unassinged状态，继续检查发现有一个索引的routings里，include的rack数量不够，导致有些 replica分配不了。 更新一下routing，让他include更多的rack就解决了。集群状态变green。

   此题考查的知识点包括，如何查看集群状态，如果查看结点列表，如何使用allocation explain api， 如何通过索引的allocation routing控制shard的分布。因为平常工作中解决集群问题比较多，所以此题完成比较轻松。

2. 有一个文档，内容类似dog & cat， 要求索引这条文档，并且使用match_phrase query，查询dog & cat或者dog and cat都能match。

   此题我现场没搞出来，当时第一反应是标准tokenizer已经将&剥离掉了，那么只要用stop words filter将and剥离掉，不就可以了吗？ 结果配置后，发现match不上。 仔细一想，match_phase需要匹配位置的，&是tokenize阶段剥离的， and是token filter阶段剥离的，这样位置就不对了。 用analyzer api分析一下，位置的确不对。然后想到应该用synonym token filter来处理，结果配置还是一直有问题。 这时候耗时已经太多，直接放弃了。回来后又演练了一下这道题，才发现用synonym token filter是没问题的，但是tokenizer应该改成whitespace，否则&被剥离了。 总结起来还是平常这块用得少，不熟练，所以考试的时候时间一紧，脑子没转过来。

3. 有index_a包含一些文档， 要求创建索引index_b，通过reindex api将index_a的文档索引到index_b。 要求增加一个整形字段，value是index_a的field_x的字符长度； 再增加一个数组类型的字段，value是field_y的词集合。(field_y是空格分割的一组词，比方"foo bar"，索引到index_b后，要求变成["foo", "bar"]。

   此题没什么技巧，就是考察reindex api的使用+ painless script。 但是我平常不怎么用painless，虽然原理上知道需要对一个字段求size，一个需要做split，但具体的语法不熟悉，也是来不及翻看文档，直接放弃。

4. 按照要求创建一个index template，并且通过bulk api索引一些文档，达到自动创建索引的效果。 创建的索引的settings和mappings应该符合要求。

   此题比较简单，熟悉index template语法，常用的settings， mappings设置就OK了。

5. 按要求写一个查询， 其中一个条件是某个关键词必须包含在4个字段中至少2个。

   此题也没什么技巧，考查bool query和minimum_should_match，熟悉就能写出来

6. 按照要求写一个search template

   熟悉search template的mustache模版语言即可轻松写出，但是很遗憾，平常没用过search template，虽然知道个大概，但是当时写的时候，不知道哪里语法有问题，PUT template总是不成功。猜想可能是哪个位置的字符没有转译产生非法json字符，或者哪一层嵌套有问题。 总之就是调试不成功，又浪费了很多时间。

7. 多层嵌套聚合，其中还包括bucket过滤

   没技巧，熟悉聚合，聚合嵌套，buckets过滤即可。

8. 给定一个json文档，要求创建一个索引，定义一个nested field，将json文档索引成嵌套类型，同时完成指定的嵌套查询和排序。

   比较简单，熟悉nested type和nested query即可完成。

9. 给定两个集群，都包含有某个索引。 要求配置cross cluster search，能够从其中一个集群执行跨集群搜索，写出搜索的url和query body。

   中间设置了一个陷阱，有一个集群有结点挂掉了，不能访问。 所以先要解决结点挂掉的问题，然后在要执行查询的集群配置cross cluster。 确认链接没问题以后，写出查询即可。

10. 有一个3结点集群，还有一个kibana。 es集群没有安装x-pack，但是安装包已经放在了机器上，kibana有安装x-pack，并且启用了security，所以此时还连接不到集群。 要求给3个结点配置security，给内置的几个用户分别设定指定的密码。 之后添加指定的新用户，指定的role，并给用户赋予role a, role b。

    此题熟悉x-pack security即可。 先分别ssh到3个结点，安装x-pack后启动结点。 等结点链接成功以后，用初始化内置用户密码的脚本，按要求分别设置密码。 之后就可以用elastic这个内置的管理员账号登陆kibana了。 然后通过kibana的用户和角色管理界面，分别添加对应的用户和角色。

还有2题是什么不太记得了，应该都是要求根据要求创建索引，reindex数据，然后执行某种类型的查询，或者聚合，比较简单吧。

总结下来，本次考试就是考察的知识点比较多，虽然只有12道考题，但是每道考题都是对多个知识点的综合考察，对ES的理解只停留在理论上是不够的，要求比较强的实际动手能力。 能考过的同学，一定是有过比较丰富的实际操作经验，该认证的含金量我感觉还是非常非常的高！

Elasticsearch5.5冷热数据读写分离

前言

冷数据索引：查询频率低，基本无写入，一般为当天或最近2天以前的数据索引

热数据索引：查询频率高，写入压力大，一般为当天数据索引

当前系统日志每日写入量约为6T左右，日志数据供全线业务系统查询使用。

查询问题：

高峰时段写入及查询频率都较高，集群压力较大，查询ES时，常出现查询缓慢问题。

写入问题：

索引峰值写入量约为12w/s，且无副本。加上副本将导致索引写入速度减半、磁盘使用量加倍；不使用副本，若一个节点宕掉，整个集群无法写入，后果严重。

一、冷热数据分离

ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储数据。

若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。

几个ES关键配置解读：

• 节点属性（后续索引及集群路由分布策略均依据此属性）

  node.attr.box_type
  node.attr.zone
  ...

  elasticsearch.yml中可增加自定义配置，配置前缀为node.attr，后续属性及值可自定义，如：box_type、zone，即为当前es节点增加标签，亦可在启动命令时设置：bin/elasticsearch -d -Enode.attr.box_type=hot

• 索引路由分布策略

  "index.routing.allocation.require.box_type": "hot"

  可在索引模板setting中设置，也可通过rest api动态更新。意义为索引依据哪个属性标签，对分片、副本进行路由分布。

  如我们对使用SSD作为存储介质的ES节点增加属性标签node.attr.box_type: hot，对其他SATA类ES节点增加属性标签node.attr.box_type: cool，将使当前索引的分片数据都落在SSD上。

​

后续对其索引配置更新为

  "index.routing.allocation.require.box_type": "cool"

将使索引分片从SSD磁盘上路由至SATA磁盘上，达到冷热数据分离的效果。

• 集群路由分布策略（此策略比索引级路由策略权重高）

  目的：不将鸡蛋放进一个篮子中。

  "cluster.routing.allocation.awareness.attributes": "box_type"

  如上配置，新建索引时，索引分片及副本只会分配到含有node.attr.box_type属性的节点上。（该值可以为多个，如"box_type,zone"）

  若集群中的节点box_type值只有一个，如只有hot，索引分片及副本会落在hot标签的节点上；若box_type值包括hot、cool，则同一个分片与其副本将尽可能不在相同的box_type节点上。

  此种场景使用于：同一个物理机含有多个ES节点，若这多个节点标签相同，使用此路由分布策略将尽可能保证相同物理机上不会存放同一个分片及其副本。

  "cluster.routing.allocation.awareness.force.box_type.values": "hot,cool"

  强制使分片与副本分离。若只有hot标签的节点，索引只有分片可以写入，副本无法分配；若有hot、cool两种标签节点，相同分片与其副本绝不在相同标签节点上。

二、数据读写分离

几点结论：

• 若使当天索引及副本都写在SSD磁盘上，SSD磁盘使用量需20T以上，代价可能过高。（读写效率最高，但由于SSD节点肯定较少，读写都在相同节点上，节点压力会非常大）
• 现有的方式，只使用普通的SATA磁盘存储，代价最低。（读写效率最低，即为当前运行状况）
• 使用集群路由分配策略，SSD与SATA各存放1份数据，SSD磁盘需分配10T以上。（读写效率折中，均有较大提升）

若使用折中方案，另一个问题考虑：

SSD节点即有读操作，也有写操作，节点较少，压力还是较大，怎么实现mysql的主从模式，达到读写分离的效果？

目标：使主分片分配在SSD磁盘上，副本落在SATA磁盘上，读取时优先从副本中查询数据，SSD节点只负责写入数据。

实现步骤：

1. 修改集群路由分配策略配置

   增加集群路由配置

   "allocation.awareness.attributes": "box_type",
   "allocation.awareness.force.box_type.values": "hot,cool"

2. 提前创建索引

   提前创建下一天的索引，索引配置如下（可写入模板中）：

   PUT log4x_trace_2018_08_11
   {
      "settings": {
        "index.routing.allocation.require.box_type": "hot",
        "number_of_replicas": 0
   }
   }

   此操作可使索引所有分片都分配在SSD磁盘中。

3. 修改索引路由分配策略配置

   索引创建好后，动态修改索引配置

   PUT log4x_trace_2018_08_11/_settings
   {
    "index.routing.allocation.require.box_type": null,
    "number_of_replicas": 1
   }

4. 转为冷数据

   动态修改索引配置，并取消副本数

   PUT log4x_trace_2018_08_11/_settings
   {
    "index.routing.allocation.require.box_type": "cool",
    "number_of_replicas": 0
   }

Elasticsearch在数据湖中的地位

• 解读Elasticsearch：
  • 定位： ElasticSearch作为高扩展分布式搜索引擎，主要满足于海量数据实时存储与检索、全文检索与复查查询、统计分析。在如今大数据时代已经成为较popular的存储选择。
  • 特点： 由于Elasticsearch使用java作为开发语言、使用lucene作为核心处理索引与检索，尤其是使用简单的RestApi隐藏lucene的复杂，使得上手非常容易、海量数据索引与检索极快。es集群由于分片和副本的机制实现了自动容错、高可用、易扩展。
  • 开源且流行： Elasticsearch支持插件机制，社区活跃度高、官网更新频繁：提供了分析插件、同步插件、hadoop插件、es-sql插件、可视化插件、性能监控插件等，可以让我们站在巨人的肩膀上专心研究搜索需求
  • 不支持： 不支持频繁更新、关联查询、事务

最优部署架构

角色划分

• es分为三种角色： master、client、data，三种角色根据elasticsearch.yml配置中node.master、node.data区分，分别为true false、false false、true true

• master： 该节点不和应用创建连接，主要用于元数据(metadata)的处理，比如索引的新增、删除、分片分配等，master节点不占用io和cpu，内存使用量一般

• client： 该节点和检索应用创建连接、接受检索请求，但其本身不负责存储数据，可当成负载均衡节点，client节点不占用io、cpu、内存

• data： 该节点和索引应用创建连接、接受索引请求，该节点真正存储数据，es集群的性能取决于该节点个数（每个节点最优配置情况下），data节点会占用大量的cpu、io、内存

• 各节点间关系： master节点具备主节点的选举权，主节点控制整个集群元数据。client节点接受检索请求后将请求转发到与查询条件相关的的data节点的分片上，data节点的分片执行查询语句获得查询结果后将结果反馈至client，在client对数据进行聚合、排序等操作将最终结果返回给上层请求

资源规划

• master节点： 只需部署三个节点，每个节点jvm分配2-10G，根据集群大小决定
• client节点： 增加client节点可增加检索并发,但检索的速度还是取决于查询所命中的分片个数以及分片中的数据量。如果不清楚检索并发，初始节点数可设置和data节点数一致，每个节点jvm分配2-10
• data节点： ①单个索引在一个data节点上分片数保持在3个以内；②每1GB堆内存对应集群的分片保持在20个以内；③每个分片不要超过30G。
• data节点经验：
  • 如果单索引每个节点可支撑90G数据，依此可计算出所需data节点数 。
  • 如果是多索引按照单个data节点jvm内存最大30G来计算，一个节点的分片保持在600个以内，存储保持在18T以内。
  • 主机的cpu、io固定，建议一台主机只部署一个data节点，不同角色节点独立部署，方便扩容
  • 每条数据保持在2k以下索引性能大约3000-5000条/s/data节点，增加data节点数可大幅度增加索引速率，节点数与索引效率的增长关系呈抛物线形状​

优秀的插件与工具

• ik分词器： es默认分词器只支持英文分词，ik分词器支持中文分词

• head数据查询工具： 类似于mysql的Navicat

• logstash： 数据处理管。采样各种样式、大小的数据来源，实时解析和转换数据，选择众多输出目标导出数据

• x-pack性能监控： 获取进程运行时资源与状态信息并存储至es中。可通过kibana查看es、logstash性能指标，试用版包括集群状态、延迟、索引速率、检索速率、内存、cpu、io、磁盘、文件量等还可以看到集群数据负载均衡时的情况。商用版还支持安全、告警等功能

• kibana可视化工具： es的可视化工具可制作各种图表，可在该工具上执行dsl语句灵活操作es

• es-sql： 用sql查询elasticsearch的工具，将封装复杂的dsl语句封装成sql

• beats： 轻量级的数据采集工具，可监控网络流量、日志数据、进程信息（负载、内存、磁盘等），支持docker镜像的file采集

• repository-hdfs： 该插件支持将es中离线数据转存至hdfs中长期存储

  ​

Elasticsearch优化经验

• 参数调优

  • 开启内存锁，禁止swapping

    执行linux命令(临时生效)

    ulimit -l unlimited

    修改主机配置：/etc/security/limits.conf

    * soft memlock unlimited
    * hard memlock unlimited

    修改es配置：config/elasticsearch.yml

    bootstrap.memory_lock : true

  • 调大文件描述符数量

    执行linux命令(临时生效)

    ulimit -n 65535

    修改linux配置文件：/etc/security/limits.conf

    * soft nofile 65536
    * hard nofile 65536

  • 调大最大映射数

    执行linux命令(临时生效)

    sysctl -w vm.max_map_count=262144

    修改linux配置文件：/etc/sysctl.conf

    vm.max_map_count=262144

• 索引配置

  • settings:{efresh_interval}：数据写入刷新间隔，默认1s，调整增加该值可以减少写入压力、增加写入速度，如设为60

    {
    "settings": {
      "refresh_interval": "60s"
    }
    }

  • mappings:{dynamic}： 禁止es自动创建字段，仅允许预先设定好的字段存入es，防止索引结构混乱

    {
     "mappings": {
       "mytype": {
         "dynamic": false
       }
     }
    }

  • _all：建议禁用

    {
    "_all": {
       "enable": false
      }
    }

  • keyword字段属性: ingore_above超过多少字符不写入，keyword一般用于精确查询，不能写入太长。

    {
    "name": {
        "type": "keyword",
        "ingore_above": 1000
     } 
    }

  • index属性：将 不作为查询字段的index值设为false

    {
      {
        "content": {
          "type": "text",
          "index": "false"
        }
      }
    }

• JVM内存溢出处理

    ​ 防止es节点内存溢出后处于僵死状态且无法恢复，影响整个集群，在进程出现OOM时让进程宕掉，退出ES集群并引发告警，然后重启。
  
    ​ 在config/jvm.options中增加JVM启动参数：

          -XX:+ExitOnOutOfMemoryError

  该参数在jdk 1.8.0_92版本上线

• 数据生命周期

  ​ es中的开启状态的索引都会占用堆内存来存储倒排索引，过多的索引会导致集群整体内存使用率多大，甚至引起内存溢出。所以需要根据自身业务管理历史数据的生命周期，如近3个月的数据开启用于快速查询；过去3-6月的数据索引关闭以释放内存，需要时再开启；超过6个月的可以生成快照保存至hdfs并删除索引，需要的时候从hdfs选择需要的索引恢复至集群中进行查询

  ​ 生产上常常使用logstash+索引模板的方式按照一定时间创建新的索引，例如按天创建索引，索引的命名可能是index-yyyy-mm-dd，每天生产不同的索引，清除历史数据时可直接关闭或删除

  ​ 需要注意的是：如何按照logstash默认的时间分割索引会有8个小时的误差，所以需要在logstash中将真实数据中的时间字段作为分割条件，保障按照业务时间分割索引

• 路由查询

  ​ 在将数据写入es时，指定一个字段作为路由字段，es会将该字段进行hash计算写入到对应的分片上；查询时根据查询条件中的路由值，直接查找所在的分片，大幅度提高查询速度。

  ​ 需要注意的是：路由字段必须是随机分布，否则会导致分片数据不平均引发的主机存储使用不平均，可以作为路由字段的：如业务流水、省份、系统编码等。

• 过滤器

  ​ ES中的查询操作分为2种：查询（query）和过滤（filter），查询默认会计算每个返回文档的得分，然后根据得分排序；而过滤（filter）只会筛选出符合的文档，并不计算得分，且它可以缓存文档。单从性能考虑，过滤比查询更快而且更节省io资源。过滤适合在大范围筛选数据，而查询则适合精确匹配数据。开发时应先使用过滤操作过滤数据，然后使用查询匹配数据

• 查询限制

  ​ 限制是为了保证es集群的稳定性。限制的内容包括：查询范围、单次查询数量等，过大的查询范围不仅会导致查询效率低，而且会是es集群资源耗费急剧增加，甚至引起es集群崩溃；单次查询数量限制是为了保证内存不会被查询内存大量占用，就是分页原理，es默认可以查询10000条数据

• 批量导入

  ​ 如果你在做大批量导入，考虑通过设置 index.number_of_replicas: 0关闭副本。把每个索引的 index.refresh_interval 改到 -1关闭刷新。导入完毕后再开启副本和刷新

  ​