网站建设的文档,网易企业邮箱注册免费,网站图片文字排版错误,一个域名建多个网站前不久#xff0c;滴滴ES团队将维护的30多个ES集群#xff0c;3500多个ES节点#xff0c;8PB的数据#xff0c;从2.3.3跨大版本无缝升级到6.6.1。在对用户查询写入基本零影响和改动的前提下#xff0c;解决了ES跨大版本协议不兼容、文件格式不兼容、mapping不兼容等难题滴滴ES团队将维护的30多个ES集群3500多个ES节点8PB的数据从2.3.3跨大版本无缝升级到6.6.1。在对用户查询写入基本零影响和改动的前提下解决了ES跨大版本协议不兼容、文件格式不兼容、mapping不兼容等难题整个过程对绝大部分用户完全透明。同时还完成了Arius的架构升级取得了单机查询性能提升40%整体集群cpu下降10%写入tps提升30%集群资源使用率提升20%、0故障、运维成本下降60%的成绩。本文将系统的介绍滴滴在从2.3.3跨大版本升级到6.6.1过程中的遇到的问题和解决方案以及在搜索平台建设过程中的体系化思考。01背景介绍1. 集群规模目前滴滴使用的ES版本是2.3.3集群个数有40多个节点规模有3500集群总容量有8PB。2. 业务规模1200多个平台应用方在使用ES30多个核心应用在使用ES写入的TPS有1500W查询的QPS有25W。02问题分析针对以上规模的ES集群从2.3.3升级到6.X版本小版本会根据最后分析的结果确定需要对潜在可能的问题进行分析和区分。1. 问题分析主要先从四大问题域进行区分分析引擎侧由于从2.3.3升级到6.X版本版本差距过大在文件格式和协议上都不兼容因此无法进行原地滚动直接升级需要双写搬迁升级这样会耗费大量的机器去参与其中用户侧6.X版本开始逐渐的不支持TCP接口因此需要用户适配和升级查询和返回值也有一定差异如果用户侧做适配会极大影响升级的进度资源侧由于无法直接原地滚动直接升级需要双写使用大量的机器但是无法提供升级所需要的机器如果升级过程中资源无法得到保障那也会极大影响升级的进度操作侧新版本的多集群如何进行运维管控升级的结果如何验证查询的效率和质量如何保障和保证的这些问题都需要考虑2. 升级思路根据上一部分问题的汇总和分类形成了一个大致的升级思路并会根据这四大步骤来解决具体的问题。架构设计平台支持多版本支持查询网关上进行多版本兼容在查询和插入使用SDK时候要做到SDK接口的透明最后要做一个平台数据采集和分析用于后续做升级的分析对比资源准备进行合理的多集群容量规划来提高资源使用率尽可能的节省机器设计索引分级存储来提升资源的利用率还针对大索引迁移开发了一个插件FastIndex也用来提升资源利用率运维绩效开发ES集群管控平台将ES集群管控平台化和图表化通过Docker的方式来提升部署和运维的效率实操在实际操作中需要实现批量双写以及查询回放的功能需要对业务进行区分实现日志和核心集群的分步推进最后就是升级过程中会遇到一些坑需要把坑都填满后续会详细介绍一下这些坑3. 升级方案上面是升级思路接下来介绍一下升级方案架构ES多版本支持的架构改造同时支持2.3.3以及6.X版本开发一套多集群管控平台用于滴滴内部ES多个集群的管控同时还开发了一套ES服务元数据体系建设资源设计ES分级存储体系开发ES-FastIndex离线数据导入的插件最后构建了一套ES集群容量规划方案来提升集群的资源使用率节约资源成本实操通过ES多集群搭建、ES流量回放对比系统、ES版本升级采坑分享来完成升级和对比的一个过程03方案介绍1. 架构① 架构重构介绍一下滴滴搜索平台(Arius)的架构业务方使用ES搜索进行读写请求时都会经过网关运维的时候会根据集群的重要程度进行划分会将四十多个集群划分为VIP、Important、Normal、Backup四类开发了一个DCDR工具用于跨集群的数据同步在ES集群运维之上开发了三大组件一个是ES Cluster Manager用于集群的搭建、重启和升级混合操作的平台第二个是集群ES的数据分析构建了一个Arius Metadata Service的元数据管理服务用于做DSL分析、成本优化和查询回放在这两个系统之上有一套Arius Admin管控系统包含索引管控、权限管控、DSL运维、多版本支持、资源管控以及容量规划等功能基于Arius Admin构建了两套面向运维和用户的管控平台前端工程。以上就是滴滴搜索平台的整体架构然后基于此来做ES的版本升级。② 升级流程上图为升级的流程首先是要升级对ES集群的管控要支持2.3.3和6.6.1两个版本对每个要升级的索引要进行主备索引的创建创建完毕后通过双写的形式对主和备都同时写入到新的索引中对于历史索引采取的是这样一个策略在双写之前主备创建之后会暂停历史数据的写入把历史数据通过migration的方式从低版本迁移到高版本中迁移完后再进行双写在迁移完成双写链路打开之后做一个DSL数据回放由于用户的读写都是通过gateway进行的所以可以拿到用户的DSL语句和返回数据来进行一个高低版本的查询、对比和分析如果最后比对结果是数据一致、性能也一致那就认为该索引在高低版本中迁移是成功的。如果迁移成功会在网关层完成用户查询的向高版本的切换如果切换完成后业务方运行没有问题就会将低版本的索引下线掉最终就完成了索引由低版本向高版本升级的过程。③ GateWay兼容性升级是一个比较漫长的过程高低版本集群会并行运行一段时间用户使用的SDK也会高低版本共存这样就需要解决高低版本兼容性的问题。查询可能会分为上图六条线标识的六种情况蓝色线表明不需要进行改造直接进行查询的2.3.3的http和tcp sdk查询2.3.3ES集群6.6.1 high sdk查询6.6.1的ES集群都是没有问题的红色线表明是需要考虑兼容性问题进行改造的例如2.3.3的sdk查询6.6.1的ES集群时候语法的差异性问题等然后ES高版本中会逐渐取消掉tcp的查询接口但是滴滴内部还是有很多用户是使用tcp方式查询的如果需要用户进行代码改造的话流程会非常漫长因此在Gateway层面做了一些兼容性处理在2.3.3http api和6.6.1 high sdk查询6.6.1集群和2.3.3集群时候做了请求DSL的兼容性处理和响应结果兼容解决了用户的痛点对于使用tcp方式查询的用户开发了一个elasticsearch-didi-java-client的sdk用户替换一下pom即可表面上还是使用tcp的方式但是在网关层面已经将其转换为了http查询的方式。这样就做到了用户透明。④ ES集群管控平台同时搭建了一套ES集群管控平台用于进行集群搭建、集群扩容、集群升级、集群监控以及集群诊断等工作为升级过程中的运维赋能提升升级推进进度。⑤ 元数据服务前面介绍的时候有讲到元数据服务该模块的作用就是提供一个ES集群和业务方的数据的分析然后获取cluster/stats、node/stats、日志、监控数据等信息进行分析最后可以得到节点磁盘使用状况、DSL查询情况(慢查、错误查询)基于此来做容量规划、分级存储、查询回放等数据驱动型工作。⑥ DSL服务此处着重介绍一下DSL服务用户所有请求都会通过网关经过网关时会收集到kafka然后用flink做一些分析如DSL模板提取(具体查询参数去掉抽象为模板)、DSL统计、DSL慢查分析、DSL异常分析等然后将分析结果回写到ES集群中然后根据这些分析的数据来做DSL审核(用户可能会查询滴滴的核心索引此处需要审核才能查询)、DSL限流(有的DSL里面会有大量的聚合查询此处会进行一定限流)、DSL分析(首先会对DSL语句进行语法树的解析解析后会生成一个无参的查询模板)等。2. 资源① 容量规划接下来将一些如何在升级过程中解决资源问题为此开发了一个容量规划的算法ES缺乏一个多节点之间索引均匀分布的功能在滴滴内部最大的集群是在两百多个节点承载容量在PB级别索引有上千个在写入索引时候可能流量分布式不均匀的很有可能有索引节点的热点存在。解决思路为将两百多个节点进行划分为五个region一个region都会有很多节点组成如r1、r2、r3组成划分之后就可以计算每个region中节点磁盘的使用情况设置一个高水位线和低水位线通过分析每个region的数据情况region超过高水位就会通过rack变更进行扩容region内部会监控不同节点的使用情况通过rack建索引mockShard进行均衡从而整体提升资源利用率通过该算法后集群磁盘的使用率从百分之四十提升到百分之六十这样就节省了大量的资源。② 分级存储基于用户查询和保存的操作进行一个数据分析开发了一个ES分级存储的体系搭建ES集群时候主要基于两种磁盘进行搭建的一种是SSD磁盘另一种是Ceph(可以理解为HDD磁盘组成的网络磁盘)SSD磁盘非常贵但是查询性能特别好会存储一些查询频繁的数据Ceph磁盘比较便宜但是查询IO性能比较低存储查询不是那么频繁的数据根据用户查询的频率将数据区分为冷数据和热数据根绝查询的DSL来分析索引的保留期限在滴滴内部基本上索引都是按天保存的(举个例子日志都是按天建索引保存的)三天之内的放到SSD上保存三天之前的数据会放到Ceph上存储这样可以大量存储的成本同等成本情况下把集群存储容量从5PB提升到了8PB。在分级存储之上还开发了一些特性专门开发了high level和low level的水位线这是基于冷存和热存系统消耗是不一样的冷存的时候high level可能会更高一点以上就是分级存储的内容。③ FastIndex另外还为离线数据导入ES开发了一个FastIIndex的组件该组件开发主要是基于滴滴内部用于分析乘客的标签系统从离线系统导入ES集群而开发的标签系统每天都会重新计算数据总量在40TB左右原始数据在hadoop上计算好之后通过kafka然后实时链路写入到ES以前把40TB数据导入到ES需要40台高配物理机基于这样一个案例开发了FastIndex组件利用hive进行一个mapreduce的过程在reduce阶段使用FastIndex组件启用ES local这样的模式将数据写到lucene data中然后再把lucene文件加载到ES集群中这样就完成了把离线数据导入ES集群的操作资源从40台下降到10台高配物理机时间也从6小时下降到1.5小时节省了大量的成本。3. 升级① 查询回放机器资源优化好了之后开始升级升级过程前面有讲过了这里主要介绍一下查询回放流程因为要保证升级后对用户的查询是没有影响的基于gateway网关层DSL的分析将用户查询的DSL全部在高低版本上进行一个回放最后得出一份查询性能报告和查询结果报告通过分析两篇报告如果是一致的就认为升级完成如果不一致就分析2.3.3和6.6.1哪些查询导致的问题然后做兼容性适配适配完成后再进行查询回放循环往复直至最后所有的报告都一致这样就认为ES集群升级成功。② 采坑接下来介绍一下升级过程中遇到的坑Mapping选择6.6.1的理由是代码里面暂时还是支持多type的还有就是布尔类型数据的兼容分词不分词的mapping修改这些内容都会提前帮助用户修改好mapping。查询兼容聚合查询term size不能为0网关兼容默认返回1000条match不支持type关键字网关兼容查询type处理逻辑not/or/and关键字不兼容网关转换must/should/must_not不支持关键字fields网关转换为store_fields性能数值字段改为BKD枚举字段会从Long类型改为keyword类型否则long类型在BKD查询时候还有问题的SDK使用高版本ES会有堆外内存消耗过大的问题需要开启jdk,nio.maxCachedBudderSize参数来保障堆外内存不会消耗过大。04升级收益1. 平台升级构建了一个完善的管控的平台大大降低了使用成本。2. 成本下降机器数量下降了400台每月成本节约了80万左右。3. 性能提升高版本的ES查询性能提升还是很明显的请求耗时下降40%集群写入提升30%。4. 特性应用使用了高版本特性带来的一些优势Sequence Number提升了集群升级速度Ingest Node索引模板和限流从网关层下放到引擎层DCDR滴滴跨集群数据同步相比CCR性能提升2倍Cluster reroute冷热节点shard搬迁更均匀Cluster allocation explain降低集群状态运维成本05总结与展望1. 总结针对搜索平台进行大版本的升级时一定要做到架构要可控服务化(网关服务、管控服务、元数据服务、FastIndex服务)、高内聚、一定优先保证稳定性平台要易用平台化、自动化、可视化成本要低廉数据驱动、技术改造、业务配合引擎要深入深入理解版本差异、深入理解ES原理、深入定位问题根因2. 规划最后对滴滴搜索平台做一个整体的规划更大的集群在滴滴现有的目前40多个集群的规模下做得更大由于master元数据管理的限制导致对集群的管控是无法做到非常大的目前滴滴希望做到单集群支持50万下载、1500节点的支撑同时需要做好多租户能力的支持更易用的平台ES云平台建设、ES专家服务更强的引擎CBO/RBO查询优化、提升写入性能更多的贡献加强和开源社区的互动、深入引擎开发作者赵情融 滴滴出行专家工程师负责滴滴搜索平台建设工作曾在阿里工作多年有丰富平台建设经验。
