Auto Byte

专注未来出行及智能汽车科技

微信扫一扫获取更多资讯

Science AI

关注人工智能与其他前沿技术、基础学科的交叉研究与融合发展

微信扫一扫获取更多资讯

百分点大数据技术团队:Elasticsearch多数据中心大规模集群的实战经验

编者按 :Elasticsearch(简称ES)作为一种分布式、高扩展、高实时的搜索与数据分析引擎,能使数据在生产环境变得更有价值,自ES从诞生以来,其应用越来越广泛,特别是大数据领域,功能也越来越强大。但当前,ES多数据中心大规模集群依然面临着数据量大、查询周期长、集群规模大、聚合分析要求高等诸多挑战。
本文针对当前面临的问题,结合百分点大数据技术团队在某海外国家级多数据中心的ES集群建设经验,总结了ES集群规划与性能调优方法,供工程师们参考
一、ES集群建设实践
1. 集群拆分
集群规模过大会导致Master节点压力比较大,造成索引的创建删除、分片分配等操作较慢,严重影响集群稳定性。所以将集群进行拆分,业务上ES集群存储三种业务类型数据A、B、C,数据占比大约A:B:C=8:3:1,根据业务类型,拆分A数据类型6个集群,B数据类型2个集群,C数据类型2个集群,存储在两个中心机房,每个集群不超过100个节点。(推荐集群节点数不要超过服务器核心数 * 5)使用跨集群搜索(Cross-cluster search),客户端在查询数据的时候连接Query集群,通过Query集群查询10个数据集群的数据。

2. 角色分离

ES集群中有多种角色,协调(coordinator)节点,主(master)节点,数据(data)节点。
一台节点可以配置成多种角色,角色分离可以避免各种角色性能互相影响。比如一个节点既是数据节点也是协调节点,可能协调角色聚合时占用大量资源导致数据角色写入数据出现异常。
通过配置elasticsearch.yml来使一个节点只承担一种角色。
主节点:当有一半主节点下线整个集群也就不可用了,一般一个集群设置3台主节点,可以容许一台主节点下线。不要配置偶数台主节点,因为配置4台主节点也仅能容许一台主节点下线。
node.master: true node.data: false
数据节点:根据自己的数据情况配置合适的节点数量。数据节点下线会导致数据不完整,集群仍能正常工作。
node.master: false node.data: true
协调节点:任何一个节点都可以是协调节点,我们通过配置几个仅协调节点来单独行使协调功能。
node.master: false node.data: false
3. 版本选择
在当初项目选型的时候,ES刚刚发布7.X,我们选择相对稳定的6.7.2版本,在后期大规模测试过程中发现,6.X版本有些局限性,此时ES已经发布7.8版本了。通过调研最终选用7.6.2版本,原因主要有下面两点:
(1)元数据压力
在6.7.2版本,集群shard个数达到5w时,更新template或创建index会出现大于30s的情况。详细参考问题页:https://github.com/elastic/elasticsearch/pull/47817
在7.6.2版本,集群shard个数达到5w时,更新template或创建index在3s内。
我们shard个数最多的集群达到了4.4w。
(2)跨集群搜索(Cross-cluster search)
当存在三个集群:Query集群、data1集群、data2集群时,配置data1、data2集群为Query集群的远程集群,此时可以通过向Query集群发送请求来获取data1、data2集群的数据。
跨集群搜索提供了两个处理网络延迟的选项:
最小化网络传输
您向Query集群发送跨集群搜索请求,Query集群中的协调节点接收并解析请求;
协调节点向每个集群(包括Query集群)发送单个搜索请求,每个集群独立执行搜索请求,将其自己的集群级别设置应用于请求;
每个远程集群将其搜索结果发送回Query集群的协调节点;
从每个集群收集结果后,Query集群的协调节点在跨集群搜索响应中返回最终结果。
不使用最小化网络传输
您向Query集群发送跨集群搜索请求,Query集群中的协调节点接收并解析请求;
协调节点向每个远程集群发送搜索分片API请求;
每个远程集群将其响应发送回协调节点,此响应包含有关将在其上执行跨集群搜索请求的索引和分片的信息;
协调节点向每个分片发送搜索请求,包括其自己集群中的分片,每个分片独立执行搜索请求;
每个分片将其搜索结果发送回协调节点;
从每个集群收集结果后,协调节点在跨集群搜索响应中返回最终结果。
更详细的说明参考:https://www.elastic.co/guide/en/elasticsearch/reference/7.6/modules-cross-cluster-search.html#ccs-min-roundtrips
最小化网络传输会减少与远程集群之间的网络往返次数,这减少了网络延迟对搜索速度的影响,同时各个远程集群的协调节点会预先将自己集群的数据聚合一次。即便如此,Query集群协调节点压力还会比较大,因为要聚合所有集群返回的数据。
我们根据最小化网络传输流程图,分析如下聚合时协调节点的压力:
coordinator node2和coordinator node3接收各自数据节点的1w条数据(shard数 * shard_size)并全量返回给coordinator node1,最终在coordinator node1上会有2w条数据,取前10条(size)返回给客户端。当我们查询的集群、索引或者索引的shard更多时,coordinator node1的压力会越来越大。测试过程中总会出现OOM的情况。
基于此考虑,我们修改部分源码,增加了coordinator_size参数,在第3步数据集群将搜索结果发回coordinator node1时只返回TOP N(前coordinator_size)。对于一个集群,通过shard_size来平衡精度与性能;对于整个跨集群方案,通过coordinator_size来平衡精度与性能。
不使用最小化网络传输由于数据不会经过coordinatornode2和coordinator node3,所以不支持这样的修改。
在6.7.2版本,跨集群搜索只支持不使用最小化网络传输的方式。
在7.6.2版本,默认使用最小化网络传输的方式进行跨集群搜索,可以在请求中添加ccs_minimize_roundtrips:false参数来选择不使用最小化网络传输。

4. 拆分索引

业务上存储的是日志数据,只有增加,没有变更,按时间累积,天然对索引的拆分友好支持,并且如果按天拆分索引有以下好处:
方便数据删除,超过保存周期的数据直接使用定时脚本在夜间删除索引即可;
提升搜索聚合的效率,业务上对数据的搜索必须要携带时间范围的参数,根据该时间参数转化为具体的索引这样搜索的shard就会比较少;
方便后期修改shard个数和mapping,虽然shard个数和mapping一般不修改,但也会遇到特殊情况,如果需要修改,我们只需要修改template,之后新索引都会应用最新的shard设置和mapping设置,等业务滚动数据存储周期天数后所有数据就都会应用最新规则。

5. 副本数量

越多的副本数量会增加搜索的并发数,但是同时也会影响写入索引的效率,占用磁盘空间。可以根据数据安全性来设置副本的数量,一般一个副本是足够的,同时可以考虑在索引创建时拥有更多的副本,当数据超过一定时间而变得不那么重要后,通过API减少副本个数。
二、ES集群配置经验
1. 内存和CPU
(1)内存分配
Lucene能很好利用文件系统的缓存,它是通过系统内核管理的。如果没有足够的文件系统缓存空间,性能会受到影响。此外,专用于堆的内存越多意味着其他所有使用doc values 的字段内存越少。参考以下原则:
当机器内存小于64G时,遵循通用的原则,50% 给 ES,50% 留给 lucene。
当机器内存大于64G时,遵循以下原则:
如果主要的使用场景是全文检索,那么建议给ES Heap分配4~32G的内存即可;其它内存留给操作系统,供lucene使用(segments cache),以提供更快的查询性能;
如果主要的使用场景是聚合或排序,并且大多数是numerics,dates,geo_points以及非分词的字符串,建议分配给ES Heap 4~32G的内存即可,其余部分留给操作系统来缓存doc values;
如果使用场景是基于分词字符串的聚合或排序,意味着需要fielddata,这时需要更多的heap size,建议机器上运行多ES实例,每个实例保持不超过50%的ES heap设置。
内存配置不要超过32G,如果堆大小小于32GB,JVM可以利用指针压缩,这可以大大降低内存的使用:每个指针4字节而不是8字节。这里32G可能因为某些因素的影响有些误差,最好配置到31G。
内存最小值(Xms)与最大值(Xmx)的大小配置相等,防止程序在运行时改变堆内存大小,这是一个很耗系统资源的过程。
配置jvm.options
-Xms31g -Xmx31g
(2)GC设置
保持GC的现有设置,默认设置为:Concurrent-Mark and Sweep(CMS),别换成 G1 GC,因为目前G1还有很多BUG。
(3)禁止swap
禁止swap,一旦允许内存与磁盘的交换,会引起致命的性能问题,可以通过在 elasticsearch.yml 中配置以下参数以保持JVM锁定内存,保证ES的性能。
bootstrap.memory_lock: true
(4)核心数
processors配置参数的值决定了节点allocated_processors的参数值,而ES很多线程池的大小都是基于allocated_processors的值来计算的。
修改elasticsearch.yml
elasticsearch.yml
node.processors: 56
在以下情况可以考虑调整该参数:
在一台服务器部署多个ES实例,此时调整参数为处理器实际核心数一半;
错误地检测处理器的数量,此时调整参数进行修正;
实际处理器核心数大于32,ES默认处理器核心数最大限制为32个,如果物理机的处理器核心数超过了32个,为了更充分利用CPU,可以调整参数为实际处理器核心数。如果可以选择CPU,更多的核心数比更快的CPU更有意义。

2. 写入

(1)增加Refresh时间间隔

ES写入数据时先写入memory buffer中,memory buffer会周期性(index.refresh_interval默认1s)或者写满后做refresh操作,将内容写入到一个新的segment中。此时数据可以被搜索,这就是为什么ES提供的是近实时的搜索。如果系统对数据延迟要求不高的话,通过延长refresh时间间隔(比如index.refresh_interval设置为30s),可以有效地提高索引速度,同时减少segment个数降低segment合并压力。
修改索引的settings:
PUT /my_index/_settings { "index" : { "refresh_interval" : "30s" } }
在导入大量数据的时候可以暂时设置index.refresh_interval: -1和index.number_of_replicas:0来提高性能,数据导入完成后还原设置。

(2)修改index_buffer_size的设置

上一条说memory buffer写满时也会触发refresh操作,为了减少refresh操作,我们同时也要配合增加memory buffer的大小。这是一个全局静态配置,会应用于一个节点上所有的分片上。
修改elasticsearch.yml:
# 接受百分比或字节大小值。它默认为10%,这意味着10%分配给节点的总堆中的将用作所有分片共享的索引缓冲区大小。 indices.memory.index_buffer_size: 10% # 如果index_buffer_size指定为百分比,则此设置可用于指定绝对最小值。默认为48mb。 indices.memory.min_index_buffer_size: 48mb # 如果index_buffer_size指定为百分比,则此设置可用于指定绝对最大值。默认为无界。 indices.memory.max_index_buffer_size: 10240mb

(3)修改translog相关的设置

refresh操作后,数据写入segment文件中,此时segment在OS Cache中,以上所有数据都保存在内存里,如果服务器异常重启则数据都不可恢复。所以数据在写入memory buffer的同时,记录当前操作到translog,每30分钟或者当translog中的数据大小达到阈值后,会触发一次flush操作将OS Cache中的segment落盘,同时清理translog。
translog默认在每次索引、删除、更新或批量请求后会提交到磁盘。我们可以通过设置使translog异步提交来提高性能:
PUT /my_index/_settings { "index" : { "translog.durability": "async", # 刷新方式。默认request 同步, async 异步 "translog.sync_interval": "10s" # 刷新频率。默认5s,不能低于100ms } }
也可以控制translog的阈值来降低flush的频率:
PUT /my_index/_settings { "index" : { "translog.flush_threshold_size": "1024mb" # translog阈值。默认512mb。如果达到则会强制flush,否则需要等待30分钟 } }
3. 分配

(1)延迟分配配置

当集群中某个节点离开集群时:
master节点会将此节点上的主分片对应的副本分片提升为主分片;
在其他节点上重建因节点下线而丢失的分片;
重建完成后很可能还会触发集群数据平衡;
如果节点又重新加入集群,集群数据自动平衡,将一些分片迁移到此节点。
节点很可能因为网络原因或硬件原因短暂离开集群,过几分钟又重新加入集群,触发上述操作会导致集群有比较大的开销,是完全没有必要的。当设置了延时分配为5分钟时,节点下线时,只会执行上述第1步操作,此时的集群处于yellow状态,在5分钟内下线的节点重新加入集群则集群直接恢复green。避免了很多分片的迁移。通过API修改延时分配时间,值为0则表示会立即分配。
cluster.routing.allocation.balance.shard:默认0.45f,定义分配在该节点的分片数的因子阈值=因子*(当前节点的分片数-集群的总分片数/节点数,即每个节点的平均分片数);
cluster.routing.allocation.balance.index:默认0.55f,定义分配在该节点某个索引的分片数的因子,阈值=因子*(当前节点的某个索引的分片数-索引的总分片数/节点数,即每个节点某个索引的平均分片数);
cluster.routing.allocation.balance.threshold:默认1.0f,超出这个阈值就会重新分配分片。
根据配置可以算出,当某一节点超过每个节点平局分片数2.2(1/0.45)个分片时会触发rebalance。
当某个节点my_index的分片数超过每个节点my_index的平均分片数1.8(1/0.55)个分片时会触发rebalance。
4. Mapping
(1)字段类型配置
不需要被分词的字段应使用not_analyzed;
不需要被搜索的字段设置index:false;
不需要聚合的字段设置doc_value:false;
仅用于精确匹配而不进行范围查询的数值字段使用keyword类型的效率更高。numeric类型从lucene6.0开始,使用了一种名为block KD tree的存储结构。这种结构比较适用于范围查找,在精确匹配方面没有倒排索引的性能好。

(2)使用自动生成的_id

避免自定义_id,建议用ES的默认ID生成策略,ES在写入对id判断是否存在时对自动生成的id有优化。同时避免使用_id字段进行排序或聚合,如果有需求建议将该_id字段的内容复制到自定义已启用doc_values 的字段中。

(3)禁用_source

_source存储了原始的document内容,如果没有获取原始文档数据的需求,可通过设置includes、excludes属性来定义放入_source的字段。
"mappings":{  "_source": {  "excludes": [   "content"  ]  } }
案例:在我们的方案中,考虑在架构上,原始数据保存在分布式文件系统。所以在ES中可以不存储content字段(其他字段仍然存储),只为content字段建立倒排索引用于全文检索,而实际内容从分布式文件系统中获取。
收益:
降低ES中存储;
提高查询性能(OS cache中能装更多的Segment);
shard的merge、恢复和迁移成本降低。
限制:
此字段不能高亮;
update、update_by_query、reindex APIs不能使用。
下面是我们根据业务数据特点测试不存储content字段对存储空间和查询的影响。
(1)测试不存储content字段对磁盘存储的影响
数据分布:
可以看出,不存储content字段可以加快搜索,对聚合影响不大。
总的来说,需要根据业务场景考虑益弊,比如是否对数据进行更新、reindex、高亮,或者说通过其他方式实现对数据的更新、reindex、高亮的成本如何。
三、ES集群设计经验

1. 批量提交

bulk批量写入的性能比你一条一条写入的性能要好很多,并不是bulk size越大越好,而是根据你的集群等环境具体要测试出来的,因为越大的bulk size会导致内存压力过大,最好不要超过几十m。

2. 多线程写入

单线程发送bulk请求是无法最大化ES集群写入的吞吐量的。如果要利用集群的所有资源,就需要使用多线程并发将数据bulk写入集群中。为了更好的利用集群的资源,这样多线程并发写入,可以减少每次底层磁盘fsync的次数和开销。
3. Merge只读索引
合并Segment对ES非常重要,过多的Segment会消耗文件句柄、内存和CPU时间,影响查询速度。Segment的合并会消耗掉大量系统资源,尽量在请求较少的时候进行,比如在夜里两点ForceMerge前一天的索引。
POST my_index/_forcemerge?only_expunge_deletes=false&max_num_segments=1&flush=true
4. Filter代替Query
如果涉及评分相关业务使用Query,其他场景推荐使用Filter查询。在做聚合查询时,filter经常发挥更大的作用。因为没有评分ES的处理速度就会提高,提升了整体响应时间,同时filter可以缓存查询结果,而Query则不能缓存。

5. 避免深分页

分页搜索:每个分片各自查询的时候先构建from+size的优先队列,然后将所有的文档 ID 和排序值返回给协调节点。协调节点创建size为number_of_shards *(from + size) 的优先队列,对数据节点的返回结果进行合并,取全局的from ~ from+size返回给客户端。
什么是深分页?
协调节点需要等待所有分片返回结果,然后再全局排序。因此会创建非常大的优先队列。比如一个索引有10个shard,查询请求from:9990,size:10(查询第1000页),那么每个shard需要返回1w条数据,协调节点就需要对10w条数据进行排序,仅仅为了获取10条数据而处理的大量的数据。且协调节点中的数据量会被分片的数量和页数所放大,因而一旦使用了深分页,协调节点会需要对大量的数据进行排序,影响查询性能。
如何避免深分页?
限制页数,限制只能获取前100页数据。翻页操作一般是人为触发的,并且人的行为一般不会翻页太多。ES自身提供了max_result_window参数来限制返回的数据量,默认为1w。每页返回100条数据,获取100页以后的数据就会报错。
使用Scroll或search_after代替分页查询,Scroll 和 search_after都可以用于深分页,不支持跳页,适合拉取大量数据,目前官方推荐使用search_after代替 scroll。

6. 硬盘

固态硬盘比机械硬盘性能好很多;
使用多盘RAID0,不要以为ES可以配置多盘写入就和RAID0是一样的,主要是因为一个shard对应的文件,只会放到其中一块磁盘上,不会跨磁盘存储,只写一个shard的时候其他盘是空闲的,不过RAID0中一块盘出现问题会导致整个RAID0的数据丢失。
7. 枚举空间大的字段聚合方案
(1)根据字段路由到固定shard
这样在聚合时每个shard的bucket少,并且精度几乎不损失,但是会造成数据倾斜。如果字段数据比较平均可以选用,但是我们业务场景不适用。
(2)调整字段的存储类型
在字段类型配置里介绍了精确匹配时keyword比数值类型效率高,我们测试了相同数据keyword和long的聚合性能。
集群创建4个索引(4天数据),每个索引120个shard,每个shard大小为30G,总数据量为:3.5T。
其数据分布为1k的占比50%、10k的占比30%、100k的占比20%。
 结束语
实时数据分析和文档搜索是ES的常用场景之一,结合客户数据特点,百分点大数据技术团队对ES进行了优化和一定的改造,并将这些能力沉淀到了我们的大数据平台上,以更好的满足客户的业务需求。通过调优,在生产环境中ES集群已经稳定运行近两年的时间了。在实际部署前,对集群稳定性和性能进行了多次大规模测试,也模拟了多种可能发生的故障场景,正是不断地测试,发现了一些局限性,对版本升级,对源码修改,也在不断测试中增加了更多的优化项来满足需求。
文中的优化实践总体上非常的通用,希望可以给大家带来一定的参考价值。
文章的最后,就以ILM作为彩蛋吧!
ILM生命周期管理:
索引生命周期的四个阶段
Hot:index正在查询和更新,性能好的机器会设置为Hot节点来进行数据的读写。
Warm:index不再更新,但是仍然需要查询,节点性能一般可以设置为Warm节点。
Cold:index不再被更新,且很少被查询,数据仍然可以搜索,但是能接受较慢的查询,节点性能较差,但有大量的磁盘空间。
Delete:数据不需要了,可以删除。
#节点属性可以通过 elasticsearch.yml 进行配置 # node.attr.xxx: xxx,hot warm cold node.attr.data: warm
这四个阶段按照Hot,Warm,Cold,Delete顺序执行,上一个阶段没有执行完成是不会执行下一个阶段的,对于不存在的阶段,会跳过该阶段进入到下一个阶段。
示例:创建索引生命周期策略来管理elasticsearch_metrics-YYYY.MM.dd日志数据。
策略如下:
在index创建后立即进入hot阶段:当index创建超过1天或者文档数超过3000w或者主分片大小超过50g后,生成新index;
旧index进入到warm阶段,segment数量merge为1,index迁移至属性data为warm的节点;
warm阶段完成后,进入delete阶段,index rollover时间超过30天后,将index 删除。
(4)后续数据读写使用指定的别名elasticsearch_metrics
Actions
各阶段支持的actions参考:Index lifecycle actions选择对应ES版本。(https://www.elastic.co/guide/en/elasticsearch/reference/7.6/ilm-actions.html)
不同版本各个阶段支持的action有变化,因此建议手动测试一下,因为7.6版本官方文档说明在hot阶段如果存在rollover则可指定forceMerge,但实际测试7.6所有版本都不支持,7.7.0之后才可以这样设置。
参考资料
[1] https://www.elastic.co/guide/en/elasticsearch/reference/7.6/index.html
[2] https://cloud.tencent.com/developer/article/1661414
[3] 《elastic stack实战手册》
百分点科技
百分点科技

百分点科技是领先的数据科学基础平台及数据智能应用提供商,以“用数据科学构建更智能的世界”为使命,为企业和政府提供端到端的场景化解决方案。我们会定期与您分享百分点科技在数据科学及数据智能领域的实践经验、心得,以及我们对前沿趋势的洞见。

工程
暂无评论
暂无评论~