专栏首页数据和云从400+节点ElasticSearch集群的运维中,我们总结了这些经验

从400+节点ElasticSearch集群的运维中,我们总结了这些经验

墨墨导读:国外一家舆情监控公司Meltwater每天处理的数据非常庞大——在高峰期需要索引大约300多万社论文章,和近1亿条社交帖子数据。其中社论数据长期保存以供检索(可回溯到2009年),社交帖子数据保存近15个月的。当前的主分片数据使用了大约200 TB的磁盘空间,副本数据大约600 TB。

本文是Meltwater的工程师结合工作中实践,分享了Elasticsearch调优秘笈,以及要绕过的一些陷阱。

Meltwater每天要处理数百万量级的帖子数据,因此需要一种能处理该量级数据的存储和检索技术。

从0.11.X 版本开始我们就已经是Elasticsearch的忠实用户了。在经历了一些波折之后,最终我们认为做出了正确的技术选型。

Elasticsearch用于支持我们的主要媒体监控应用,客户通过该应用可以检索和分析媒体数据,比如新闻文章、(公开的)Facebook帖子、Instagram帖子、博客和微博。我们通过使用一个混合API来收集这些内容,并爬取和稍作加工,使得它们可被Elasticsearch检索到。

本文将分享我们所学到的经验、如何调优Elasticsearch,以及要绕过的一些陷阱。

数据量


每天都有数量相当庞大的新闻和微博产生;在高峰期需要索引大约300多万社论文章,和近1亿条社交帖子数据。其中社论数据长期保存以供检索(可回溯到2009年),社交帖子数据保存近15个月的。当前的主分片数据使用了大约200 TB的磁盘空间,副本数据大约600 TB。

我们的业务每分钟有3千次请求。所有的请求通过一个叫做“search-service”的服务,该服务会依次完成所有与Elasticsearch集群的交互。大部分检索规则比较复杂,包括在面板和新闻流中。比如,一个客户可能对Tesla和Elon Musk感兴趣,但希望排除所有关于SpaceX或PayPal的信息。用户可以使用一种与Lucene查询语法类似的灵活语法,如下:

Tesla AND "Elon Musk" NOT (SpaceX OR PayPal)

我们最长的此类查询有60多页。重点是:除了每分钟3千次请求以外,没有一个查询是像在Google里查询“Barack Obama”这么简单的;这简直就是可怕的野兽,但ES节点必须努力找出一个匹配的文档集。

版本


我们运行的是一个基于Elasticsearch 1.7.6的定制版本。该版本与1.7.6 主干版本的唯一区别是,我们向后移植(backport)了roaring bitsets/bitmaps(http://suo.im/5bE6od) 作为缓存。该功能是从Lucene 5移植到Lucene 4的,对应移植到了ES 1.X版本。Elasticsearch 1.X中使用默认的bitset作为缓存,对于稀疏结果来说开销非常大,不过在Elasticsearch 2.X中已经做了优化。

为何不使用较新版本的Elasticsearch呢?主要原因是升级困难。在主版本间滚动升级只适用于从ES 5到6(从ES 2到5应该也支持滚动升级,但没有试过)。因此,我们只能通过重启整个集群来升级。宕机对我们来说几乎不可接受,但或许可以应对一次重启所带来的大约30-60分钟宕机时间;而真正令人担心的,是一旦发生故障并没有真正的回滚过程。

截止目前我们选择了不升级集群。当然我们希望可以升级,但目前有更为紧迫的任务。实际上该如何实施升级尚未有定论,很可能选择创建另一个新的集群,而不是升级现有的。

节点配置


我们自2017年6月开始在AWS上运行主集群,使用i3.2xlarge实例作为数据节点。之前我们在COLO(Co-located Data Center)里运行集群,但后续迁移到了AWS云,以便在新机器宕机时能赢得时间,使得我们在扩容和缩容时更加弹性。

我们在不同的可用区运行3个候选master节点,并设置discovery.zen.minimum_master_nodes为2。这是避免脑裂问题

split-brain problem

(https://qbox.io/blog/split-brain-problem-elasticsearch)非常通用的策略。

我们的数据集在存储方面,要求80%容量和3个以上的副本,这使得我们运行了430个数据节点。起初打算使用不同层级的数据,在较慢的磁盘上存储较旧的数据,但是由于我们只有相关的较低量级旧于15个月的数据(只有编辑数据,因为我们丢弃了旧的社交数据),然而这并未奏效。每个月的硬件开销远大于运行在COLO中,但是云服务支持扩容集群到2倍,而几乎不用花费多少时间。

你可能会问,为何选择自己管理维护ES集群。其实我们考虑过托管方案,但最后还是选择自己安装,理由是:AWS Elasticsearch Service

(http://suo.im/4PLuXa)暴露给用户的可控性太差了,

Elastic Cloud(https://www.elastic.co/cn/cloud)的成本比直接在EC2上运行集群要高2-3倍。

为了在某个可用区宕机时保护我们自身,节点分散于eu-west-1的所有3个可用区。我们使用AWS plugin(http://suo.im/5qFQEP)来完成该项配置。它提供了一个叫做aws_availability_zone的节点属性,我们把

cluster.routing.allocation.awareness.attributes

设置为aws_availability_zone。这保证了ES的副本尽可能地存储在不同的可用区,而查询尽可能被路由到相同可用区的节点。

这些实例运行的是Amazon Linux,临时挂载为ext4,有约64GB的内存。我们分配了26GB用于ES节点的堆内存,剩下的用于磁盘缓存。为何是26GB?因为JVM是在一个黑魔法之上构建的(https://www.elastic.co/blog/a-heap-of-trouble)。

我们同时使用Terraform

(https://www.terraform.io/)自动扩容组来提供实例,并使用Puppet(https://puppet.com/)完成一切安装配置。

索引结构


因为我们的数据和查询都是基于时间序列的,所以使用了

time-based indexing(http://suo.im/547GbE),

类似于ELK(elasticsearch、logstash、kibana) stack(https://www.elastic.co/elk-stack)。同时也让不同类型的数据保存在不同的索引库中,以便诸如社论文档和社交文档类数据最终位于不同的每日索引库中。这样可以在需要的时候只丢弃社交索引,并增加一些查询优化。每个日索引运行在两个分片中的一个。

该项设置产生了大量的分片(接近40k)。有了这么多的分片和节点,集群操作有时变得更特殊。比如,删除索引似乎成为集群master的能力瓶颈,它需要把集群状态信息推送给所有节点。我们的集群状态数据约100 MB,但通过TCP压缩可减少到3 MB

(可以通过curl localhost:9200/_cluster/state/_all 查看你自己集群的状态数据)。Master节点仍然需要在每次变更时推送1.3 GB数据(430 节点 x 3 MB 状态大小)。除了这1.3 GB数据外,还有约860 MB必须在可用区(比如 最基本的通过公共互联网)之间传输。这会比较耗时,尤其是在删除数百个索引时。我们希望新版本的Elasticsearch能优化这一点,首先从ES 2.0支持仅发送集群状态的差分数据(http://suo.im/547UyM)这一特性开始。

ElasticSearch性能


如前所述,我们的ES集群为了满足客户的检索需求,需要处理一些非常复杂的查询。

为应对查询负载,过去几年我们在性能方面做了大量的工作。我们必须尝试公平分享ES集群的性能测试,从下列引文就可以看出。

不幸的是,当集群宕机的时候,不到三分之一的查询能成功完成。我们相信测试本身导致了集群宕机。 —— 摘录自使用真实查询在新ES集群平台上的第一次性能测试

为了控制查询执行过程,我们开发了一个插件,实现了一系列自定义查询类型。通过使用这些查询类型来提供Elasticsearch官方版本不支持的功能和性能优化。比如,我们实现了phrases中的wildcard查询,支持在SpanNear查询中执行;另一个优化是支持“*”代替match-all-query;还有其他一系列特性。

Elasticsearch和Lucene的性能高度依赖于具体的查询和数据,没有银弹。即便如此,仍可给出一些从基础到进阶的参考:

  • 限制你的检索范围,仅涉及相关数据。比如,对于每日索引库,只按相关日期范围检索。对于检索范围中间的索引,避免使用范围查询/过滤器。
  • 使用wildcards时忽略前缀wildcards - 除非你能对term建立倒排索引。双端wildcards难以优化。
  • 关注资源消耗的相关迹象,数据节点的CPU占用持续飙高吗?IQ等待走高吗?看看GC统计。这些可以从profilers工具或者通过JMX代理获得。如果ParNewGC消耗了超过15%的时间,去检查下内存日志。如果有任何的SerialGC停顿,你可能真的遇到问题了。不太了解这些内容? 没关系,这个系列博文很好地介绍了JVM性能(http://suo.im/4AJgps) 。 记住,ES和G1垃圾回收器一起并非最佳(http://suo.im/4WBTA5)。
  • 如果遇到垃圾回收问题,请不要尝试调整GC设置。这一点经常发生,因为默认设置已经很合理了。相反,应该聚焦在减少内存分配上。具体怎么做?参考下文。
  • 如果遇到内存问题,但没有时间解决,可考虑查询Azul Zing。这是一个很贵的产品,但仅仅使用它们的JVM就可以提升2倍的吞吐量。不过最终我们并没有使用它,因为我们无法证明物有所值。
  • 考虑使用缓存,包括Elasticsearch外缓存和Lucene级别的缓存。在Elasticsearch 1.X中可以通过使用filter来控制缓存。之后的版本中看起来更难一些,但貌似可以实现自己用于缓存的查询类型。我们在未来升级到2.X的时候可能会做类似的工作。
  • 查看是否有热点数据(比如某个节点承担了所有的负载)。可以尝试均衡负载,使用分片分配过滤策略shard allocation filtering (http://suo.im/4IfruL),或者尝试通过集群重新路由 cluster rerouting(http://suo.im/5ja7cU) 来自行迁移分片。我们已经使用线性优化自动重新路由,但使用简单的自动化策略也大有帮助。
  • 搭建测试环境(我更喜欢笔记本)可从线上环境加载一部分代表性的数据(建议至少有一个分片)。使用线上的查询回放加压(较难)。使用本地设置来测试请求的资源消耗。
  • 综合以上各点,在Elasticsearch进程上启用一个profiler。这是本列表中最重要的一条。 我们同时通过Java Mission Control (http://suo.im/4zYEsP)和 VisualVM (http://suo.im/4AJeIM)使用飞行记录器。在性能问题上尝试投机(包括付费顾问/技术支持)的人是在浪费他们(以及你自己)的时间。排查下JVM哪部分消耗了时间和内存,然后探索下Elasticsearch/Lucene源代码,检查是哪部分代码在执行或者分配内存。
  • 一旦搞清楚是请求的哪一部分导致了响应变慢,你就可以通过尝试修改请求来优化(比如,修改term聚合的执行提示(http://suo.im/4WBUJx),或者切换查询类型)。修改查询类型或者查询顺序,可以有较大影响。如果不凑效,还可以尝试优化ES/Lucene代码。这看起来太夸张,却可以为我们降低3到4倍的CPU消耗和4到8倍的内存使用。某些修改很细微(比如 indices query (http://suo.im/4WBUR7)),但其他人可能要求我们完全重写查询执行。最终的代码严重依赖于我们的查询模式,所以可能适合也可能不适合他人使用。因此目前为止我们并没有开源这部分代码。不过这可能是下一篇博文的好素材。

图表说明:响应时间。有/没有 重写Lucene查询执行。同时也表明不再有节点每天多次发生内存不足。

顺便说明下,因为我知道会面临一个问题:从上一次性能测试我们知道通过升级到ES 2.X能小幅提升性能,但是并不能改变什么。话虽如此,但如果你已经从ES 1.X集群迁移到了ES 2.X,我们很乐意听取关于你如何完成迁移的实践经验。

如果读到了这里,说明你对Elasticsearch是真爱啊(或者至少你是真的需要它)。我们很乐意学习你的经验,以及任何可以分享的内容。欢迎在评论区分享你的反馈和问题。

作者:Anton Hägerstrand

翻译:杨振涛

扩展阅读


  1. Elasticsearch如何做到亿级数据查询毫秒级返回?
  2. 从 Elasticsearch 来看分布式系统架构设计
  3. 超详细的Elasticsearch高性能优化实践
  4. MySQL从零到一解读增量同步数据到elasticsearch canal adapter方式(binlog)实现
  5. 墙裂推荐 | 漫画解读Elasticsearch原理,看完你就懂
  6. 有多少漏洞都会重来:从ElasticSearch到MongoDB和Redis

数据和云

ID:OraNews

如有收获,请划至底部,点击“在看”,谢谢!

公司简介 | 招聘 | DTCC | 数据技术嘉年华 | 免费课程 | 入驻华为严选商城

zCloud | SQM | Bethune Pro2 | zData一体机 | MyData一体机 | ZDBM 备份一体机

Oracle技术架构 | 免费课程 | 数据库排行榜 | DBASK问题集萃 | 技术通讯

升级迁移 | 性能优化 | 智能整合 | 安全保障 | 架构设计 | SQL审核 | 分布式架构 | 高可用容灾 | 运维代维

云和恩墨大讲堂 | 一个分享交流的地方

请备注:云和恩墨大讲堂

本文分享自微信公众号 - 数据和云(OraNews)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 400+节点的Elasticsearch集群运维

    墨墨导读:本文将分享我们所学到的经验、如何调优Elasticsearch,以及要绕过的一些陷阱。

    数据和云
  • 开源正在吞噬软件业?看开源的7大理念

    软件正在吞噬世界?是的,对于购物、吃饭、健身、交停车费都需要使用软件的年代,对于平均每人每天都要花费5到6个小时使用手机软件的年代,有什么理由不相信软件正在吞噬...

    数据和云
  • 将SQL优化做到极致 - 子查询优化

    编辑手记:子查询是SQL中比较重要的一种语法,恰当地应用会很大程度上提高SQL的性能,若用的不得当,也可能会带来很多问题。因此子查询也是SQL比较难优化的部分。...

    数据和云
  • 机器学习实战--住房月租金预测(1)

    上次分享的从0开始如何用一个月杀进机器学习比赛Top25%受到很多小伙伴的支持,今天继续分享这次比赛的收获。本文会讲解数据集的分析。话不多说,我们开始吧!

    PM小王
  • SQL反模式学习笔记9 元数据分裂

    1、将一张很长的表拆分成多张较小的表,使用表中某一个特定的数据字段来给这些拆分出来的表命名。

    张传宁老师
  • ECCV 2018 | 国防科大、普林斯顿提出共面性检测网络:助力三维场景重建

    共面性检测网络为解决这一问题提供了新的思路,并能够显著提升三维场景重建的质量。目前这项研究工作已被欧洲计算机视觉大会 (ECCV 2018) 收录,并被邀请赴会...

    机器之心
  • Linq之ToDictionary<TSource, TKey, TElement>的写法

    以前一直用 var query = xxx.Select(c=>new {c.X,c.Y}); 来取表中的某二列字段,今天有个应用需要转成Dictionary<...

    菩提树下的杨过
  • Facebook开源NLP建模框架PyText

    Facebook AI Research宣布推出PyText的开源版本,PyText是一个NLP建模框架,每天为Facebook及其应用程序系列用户提供超过10...

    AiTechYun
  • python 数据分析基础 day18-使用pandas进行数据清洗以及探索

    今天是读《python数据分析基础》的第18天,读书笔记的内容是使用pandas进行数据清洗以及探索 由于原始数据在某种程度上是“脏”的,原始数据并不能完全使...

    billyang916
  • CentOS Linux 7安全基线检查

    描述 若系统使用弱口令,存在极大的被恶意猜解入侵风险,需立即修复。 加固建议 将弱密码修改复杂密码,应符合复杂性要求:

    咻一咻

扫码关注云+社区

领取腾讯云代金券