2019年1月至2019年7月，滴滴ElasticSearch团队（Arius）维护国内30多个ES集群，2000多个ES节点，4PB数据。从2.3.3无缝升级到6.6.1。图片来自Pexels。在对用户查询编写基本零影响和修改的前提下，解决了ES跨版本协议不兼容、Mapping不兼容等行业难题。整个过程对大多数用户来说是完全透明的。经过7个月的努力，团队成员完成了ES版本的升级，同时也完成了滴滴ElasticSearch平台的架构升级。实现了单机查询性能提升40%，集群整体CPU降低10%，写入TPS提升30%，回归近400台物理机，成本节约80W/月，零故障结果，以及在引擎上为社区贡献了4个PR，一个同学升级为ESContributor。如此大规模的版本升级，在ES界实属罕见。从开始准备到实际实施，我们遇到了很多困难，踩了一些坑。这期间，我们也有很多思考。为此，我们准备了本期的总结分享，主要从以下几个方面进行：推石的Sisyphus滴滴ElasticSearch团队在2016年开始搭建ElasticSearch平台，并于2016年6月开始对外提供服务，当时选用的是ElasticSearch最新的2.3版本。现在三年过去了，ElasticSearch生态系统经历了快速增长。Elastic已完成上市。ElasticSearch在db-engines中的得分从88分上升到148分，排名从第11位上升到第7位。这期间，ES发布了3个大版本和几十个中版本，最近ElasticSearch发布了7.x版本。过去三年，滴滴Elasticsearch平台推出了基于ElasticSearch的四大服务，包括日志检索、MySQL实时数据库快照、分布式文档数据库、搜索引擎。四大业务发展迅速。目前，滴滴ElasticSearch平台服务于集团1200个应用。其中，订单、客服、金融、脉搏、新政策等核心实时场景也在Elasticsearch上运行。ES集群运维30+，峰值写入TPS达到1500W。查询QPS达到2W。业务的快速发展是对滴滴ElasticSearch团队工作的肯定，但同时也面临着巨大的挑战和压力。低版本是ElasticSearch平台未来发展的最大制约。要点如下。①社区不再维护旧版本：ElasticSearch2.3.3版本太旧，ES社区不再维护。社区不解决2.x上遇到的问题，提交的issue不处理，不接受提交的代码。在2.3.3的基础上，我们也解决了很多ES自身的问题，比如：Master更新元数据超时导致内存泄露，TCP协议字段溢出等。由于无法与社区互动，团队成员的价值不被社会认可。长此以往只会离ES生态越来越远，我们在ES技术圈的话语权也会越来越弱。②新版本特性难用：最近三年是ES生态大发展的三年，ES本身在功能和性能上都有很大的提升。例如，默认使用BM25评分算法以获得更好的结果；改进lucenedocvalues稀疏区以节省磁盘空间；新的Frozen索引功能可以显着减少ES内存开销。很多特性也非常适合ElasticSearch平台的场景，但是较大的版本差距一直制约着我们，无法享受到技术进步的红利。一方面，业务的快速发展需要更丰富的功能、更强的性能、更低的成本、更稳定的服务；另一方面，它离最新的行业技术越来越远，团队的价值越来越弱。一个会做业务的伪引擎团队，整个团队的现状就像推石头的西西弗斯。要么迎难而上，克服困难，一口气将整个集群升级到最新版本，推开山顶的石头，轻装前行；.滴滴ElasticSearch团队最终选择重构滴滴ElasticSearch平台，将维护的所有ES集群升级到最新版本。难点：理想很丰满，现实很骨感，决定很容易，但实际执行起来很困难：2.3.3和6.6.1协议不兼容，6.6.1不支持TCP协议，那些通过TCP查的用户怎么办，让他们一个一个改代码，什么时候改？2.3.3和6.6.1返回的部分字段不同，部分查询语法不兼容。如何为用户做？透明化，还是直接强制用户接受变更？2.3.3和6.6.1的lucene文件格式不一样，没办法直接原地升级，需要创建集群，全部双写。2.3.3和6.6.1的Mapping格式不统一，6.6.1不支持多种类型，没有办法移动已有的数据。滴滴ElasticSearch平台目前不支持同时查询多版本索引，用户查询习惯各不相同，很多带*的查询根本无法控制。用户那么多，使用上差别很大。如何与用户沟通和宣传，如何屏蔽用户影响力和期望值管理？就算要搬迁升级，哪里找那么多机器？拿起机器。几十个集群，几千个节点，部署、搭建、重启，上千台机器搬迁。慢慢做，什么时候做，快点，万一出了问题怎么办？即使是双写升级，你怎么知道中间有没有问题，数据有没有丢失，用户查询是否一致，功能和性能是否达到预期，如何验证这？数据那么多，用的人那么多，资源那么少，业务稳定性压力大，估计今年完不成。…………我们一开始决定跨版本升级后，遇到了很多问题，如果其中任何一个不解决，都会极大地阻碍升级进程。心想：我天生有用。在起步阶段，很多问题混杂在一起。有必要明确每个问题的重要性、紧迫性、影响程度和相互依存关系。通过分析和归纳，我们归纳为四大问题域：归纳完问题域，讨论了具体的实施方案和步骤，归纳为以下四个可以实际推进的环节：第一，升级架构：解决2.x/6.x在引擎端的不兼容问题，所有协议、查询语法、Mapping等不兼容的处理都在平台端处理。同时我们开发了ESjavaSDK来解决6.x不支持TCP接口的问题。使用方法与原来的esjava客户端完全一样，用户只需要修改pom.xml即可。具体包括：Arius平台多版本支持、Gateway多版本兼容、用户SDK开发、AMS数据采集等，详见后续详细说明。其次，解决运维问题：解决运维操作过程中多集群的构建、部署、重启等管控问题，提高操作的便捷性，提升升级的操作效率。详情请参见后续的详细描述。再次解决资源问题：解决搬迁升级所需的大量机器资源问题，为大量集群升级做好充分准备，同时满足机房取消和归还的要求机器。具体包括：索引存储周期优化、冷热数据分离、Mapping优化、fastIndex等，具体见后续详细说明。最后开始实推：在做好前期的所有准备工作后，开始实推升级流程。具体包括：性能压力测试、资源评估、批量双写、查询回放，以及一些意想不到的挖坑填坑过程。详情请参见后续的详细描述。实战：在梳理了整个升级过程中各个环节的依赖关系、资源消耗、瓶颈后，破铁易从架构、资源、实战三个方面设计了相应的解决方案。方案主要如下：架构①滴滴ElasticSearch平台ES多版本支持的架构改造首先，我们完成了滴滴ElasticSearch平台ES多版本支持的架构升级。重点在于：AriusGateway兼容跨版本查询差异，以及跨高低版本集群的多集群索引访问，升级过程中对用户查询结果透明。Elasticsearch-didi-interanl-clientSDK开发，屏蔽用户ESTCP/HTTP查询差异，解决ES6.x版本不支持TCP接口的问题，原2.x用户只需要修改一行pom即可切换到更高版本访问。滴滴ElasticSearch平台架构梳理与Ariusadmin多版本支持。②基于弹性云的ES多集群管控方案目前，滴滴ElasticSearch团队运维了30多个ES集群，5000+个ES节点。集群规模大，场景复杂，运维管控成本相对较高。为此，我们设计开发了ECM（ElasticSearchClusterManager）系统，用于ES集群部署、重启、扩容、配置控制等一系列操作。而我们80%的ES节点运行在弹性云上，结合弹性云灵活高效的特点，让我们在迁移升级的过程中更加高效。③ES服务元数据体系构建我们构建了一套AMS（AriusMetaDataService）服务，用于收集和分析所有ES集群、节点和索引的各种数据。包括：容量信息（集群、节点、模板、索引、租户）、TPS/QPS信息（集群、节点、模板、索引、租户）、运行信息、查询语句、查询模板信息、查询结果及命中率分析信息等在这些基础指标数据的基础上，我们构建了完善的ES运行指标体系，可以全面了解和监控集群、节点、索引、租户层面的运行信息。详细的数据为后续ES成本优化提供了依据。详见——基于数据驱动的ES分层存储系统，分层存储系统的构建让我们可以构建一个系统化的ES成本节约系统。详细数据为后续升级查询流量回放对比提供依据。详见——基于ES服务元数据的查询流量播放对比系统，使我们在升级过程中能够快速验证升级结果，提高升级效率和稳定性。同时，AMS还对数据的可靠性负责，确保生成的数据及时准确，因此依赖于AMS的数据分析服务。如：分层存储、容量规划、回放系统、费用计费、集群健康检查、索引健康评分等，你只需要专注于自己逻辑的实现即可。资源在解决架构和兼容性问题后，我们自信地将集群实时升级到新版本。但由于版本跨度太大，无法直接在原有集群上进行滚动升级，必须进行数据双写搬迁升级。这样一来，升级所需的buff资源就成为了制约整个升级进度的最主要因素。因此，我们将重点放在节约资源和提高资源利用率方面。通过内外部挖潜和技术改造，不仅支撑了版本升级所需的机器资源（高峰时段同时升级了三个集群），还返还了近400台机器，节约成本80W+/月。①基于数据驱动的ES分层存储体系，基于AMS对应索引大小、数据量、查询量、查询条件、查询时间、返回结果的统计分析，可以准确分析出每个索引所在的场景使用以及如何使用。查询方式。例如：索引的高频查询时间间隔，索引要检索的字段等。我们在数据分析的基础上，针对每个优化映射，存储周期优化，冷热数据存储优化指数。在不影响用户使用需求的前提下，累计节省数据1PB，冷数据搬迁700TB，不仅保证了升级过程中足够的buff机，还返还了近400台物理机，节约成本70W+/月。②ESFastIndex离线数据导入系统ESFastIndex的初衷是为了解决集团标签系统离线导入的效率和资源问题。群标签系统每天有30多TB的数据，需要在短时间内同步到ES，否则会影响当天。业务结果，之前的方案为了满足效率使用了大量的机器资源。采用基于Hadoop的ESfastIndex离线数据导入系统后，同样的数据导入时间从8小时缩短到2小时。机器成本从原来的40台物理机（27台ES，3台Kafka，10台Dsink）降低到30个弹性云节点（10台物理机），仅标签场景每月节省7W+。③基于资源配额控制的ES集群容量规划方案，提高ES集群的资源利用率，也是滴滴ElasticSearch团队一直面临并致力于解决的问题。滴滴ElasticSearch团队维护的ES机器总容量接近5PB。资源使用量增加10%可以节省500TB的空间，这些空间可用于返还机器或服务于新的需求。目前ES集群整体磁盘使用率在50%左右，高峰期达到60%，日志集群磁盘使用率达到69.5%（2019.05.01）。压力很大，偶尔会出现数据丢失的问题。为此，我们在原有ES机器容量规划算法中加入资源Qutoa控制，深入引擎，在引擎层面提升ES节点的容量规划和资源统一性，期望提升ES的整体磁盘使用率再聚类10%。日均达到60%，峰值达到70%，不存在磁盘告警和稳定性问题。在实际运行中的准备工作完成后，集群升级就变成了一个循序渐进的过程。期间虽然遇到了一些意想不到的情况，也踩了一些坑，但整体过程还是比较顺利的。①基于ES服务元数据的查询流量播放对比系统在之前搭建的AMS（AriusMetaService）系统上，我们对用户查询条件和查询结果进行记录和分析。在双写迁移升级过程中，我们回放了用户在高低版本集群上的查询情况，对比分析了查询返回的结果和性能参数。只有对比一致，性能没有太大差异，才能认为升级有效，我们才会有信心去做。②基于ECM的ES多集群升级过程需要双写搬迁升级。在实际升级过程中，需要进行集群搭建、搬迁、重启等密集型操作。得益于ECM的集群管控能力，弹性云具有弹性。特点，我们可以通过与运维同学的紧密配合，在短时间内完成多个集群的升级。③ES新版本特性及升级性能分析ES6.6.1提供了很多新特性，查询写入性能也有了很大的提升。我们升级的一些案例也得到了验证。我们将对这些功能和性能改进进行详细的分析，并与大家分享。④ES版本升级坑分析在升级过程中，我们也踩过一些坑，比如：高版本SDK无限使用堆外内存导致的OOM问题，我们会详细记录遇到的所有问题，与大家分享。收获：经过长风创汇近半年的开发和重构，在将国产集群升级到更高版本的过程中，我们在架构、产品、成本、性能、特性、自身能力等方面也取得了长足的进步.推动。结构更清晰。重构之后，整个滴滴ElasticSearch平台的服务体系变得更加清晰。主要汇聚成四大应用：Gateway负责查询写请求的访问。用户的限流、权限校验、版本兼容就到这里完成了。ECM负责所有集群的管理和控制。集群的搭建、升级、重启、集群级别的监控和运维分析都在这里完成。AMS负责收集和分析所有集群、节点和索引的运行时信息，保证数据质量，支持其他数据分析应用。分层存储、索引健康评分、集群健康检查、查询回放等都在这里完成。AriusAdmin负责索引、权限和资源控制等核心功能。依托Admin的核心能力和AMS的数据采集能力，还提供容量规划和智能告警两大精心设计的可插拔扩展服务。四个应用完成了功能抽象、依赖解耦、服务改造。与之前的arius-watch、arius-dsl、arius-tools、arius-monitor、arius-mark这五个小应用相比，整体开发效率和可操作性都有了很大的提升。该产品更易于使用。基于ES6.5.1版本，我们对滴滴ElasticSearch用户控制台进行了全面重构，包括用户的一些高频操作，如：映射设置/更改、数据清洗、索引扩缩容、索引转移、成本票据等向用户开放，提高用户自助操作性。未来，我们还将滴滴ElasticSearch用户控制台中的Kibana升级到最新版本，并进行定制化开发，为用户提供更丰富、更强大的功能。更便宜的成本之前滴滴ElasticSearch平台有基于索引创建规则的容量规划算法，与完全没有规划相比，旧的容量规划算法可以将整体集群资源使用率从30%提高到50%左右。但仍存在资源分布不均、无法快速发现热点、动态自适应性低、规划算法抽象不足、指标集群生效、运维便利性差等问题。下图是一个日志集群新旧容量规划的磁盘使用率对比。新容量计划启动后，集群资源将向两个方向发展：使用的资源更加集中，节点间的资源利用更加均匀。资源占用也更高。闲置资源完全释放，基于弹性云部署，可以快速从集群中移除，添加到备份资源池，或者加入到其他资源受限的集群中。经过一系列的存储优化和资源利用改造，在满足集群升级和业务增长的基础上，国产ES的资源成本从2019年2月的339w下降到2019年6月的259w，机器数量也有所减少。从1658个单位增加到1321个单位。随着国内集群升级的逐步完成和Ceph冷库的完善，更多的机器会逐渐回归。使用滴滴ElasticSearch平台的成本也会逐步降低。我们也会在定价方面考虑进一步降价。更强大的性能新版本升级后的性能主要体现在以下两点：①查询性能提升下图是升级前后客服订单列表查询语句的对比。第50个百分位数的耗时从300毫秒下降到50毫秒。第99个百分位数从600毫秒下降到300毫秒。性能提升的详细分析请见：ES新版本特性及升级性能分析。②集群写入性能提升只有升级到更高版本时，ES6.6.1集群在与ES2.3.3集群相同的资源消耗下，整个集群的写入能力提升了30%。如下图，日志集群写入TPS前后对比，集群写入能力从240w/s提升到320w/s。前景：直连云助海目前，滴滴ElasticSearch团队已完成国内所有日志集群和90%VIP集群的升级。更大的发展空间。未来，我们将更加专注于发动机建设，更加从根本上解决当前存在的问题。未来，我们将继续朝着以下方向努力：①更大的集群尝试突破日志场景下ES单集群支持的最大节点数，增加单集群可支持的节点数，目前单个集群支持的200个。节点提升至1000个节点。我们期待在大集群下减少我们集群的数量，提高运维效率。同时，更大的集群可以更方便、更灵活地提高资源利用率，解决流量激增和资源热点问题。②降低成本降低使用ES的成本，提高资源利用率一直是我们的目标。上半年在完成集群升级服务好业务的同时，我们也实现了每月80w的成本节约，ES整体成本下降了25%左右，力争下半年成本再降10%。ES6.6.1提供的一些新特性，如Frozen机制和Indexing排序，将进一步降低资源消耗。③迭代更快ES集群中多租户查询的交互一直是滴滴ElasticSearch团队面临的难题。之前更多是在平台层面通过物理资源隔离、查询审核、限流等方式。解决方案，资源利用率不高，人力运维成本过高。未来我们会构建一套ES自带的查询优化器，类似MySQL的Explain，可以在查询语句层面进行性能分析和查询优化，通过索引模板层面的查询资源隔离，在引擎层面进行性能分析和查询优化，通用查询和重查询分离，保证查询的稳定性。④更紧密的联系在新版ES的基础上，我们将与社区保持更紧密的联系，积极跟进社区提供的新功能和发展方向，将滴滴介绍给大家使用。我们也会积极参与社区建设，将我们在滴滴内部遇到和解决的问题反馈给社区，贡献更多的PR，产生更多的ESContributors。作者：赵庆荣简介：滴滴专家工程师，2018年加入滴滴，滴滴搜索团队负责人，全面负责滴滴搜索平台建设。曾在阿里巴巴工作多年，具有丰富的平台建设经验。
