8 滴滴基于 ElasticSearch 的一站式搜索中台实践.docxVIP

滴滴基于 ElasticSearch 的一站式搜索大陆与台湾实践 滴滴自 2021 年 4 月开头组建团队，处理 ElasticSearch 在使用过程中遇到的功能问题。搜索平台的建设是随着业务体量的进展逐渐演进的，如今已经进展到有超过 3500+ ElasticSearch 实例， 5PB 的数据存储，峰值写入 TPS 超过了 2000W/S 的超大规模，每天近 10 亿次检索查询。 ElasticSearch 在滴滴有着格外丰富的应用场景： 为线上核心搜索业务供应引擎支持； 作为?RDS?从库，海量数据检索需求； 处理公司海量日志检索问题； 为平安场景供应数据分析力量。 不同场景业务方对写入的准时性、查询的 RT、全体稳定性的要求都是不一样的，我们对平台供应的服务笼统为索引模板服务，用户可以自助开通相应的服务。 我们内部经过压测、线上调优以及引擎的一些优化，已经将最佳实践，沉淀到标准的 Docker 镜像中，共性化的需求都在索引模板的服务级别进行设置与管控，部分优化如下： 平台稳定性面临的风险与挑战 超大的集群规模和丰富的场景给滴滴 ElasticSearch 平台带来了极大的风险与挑战。主有以下几个方面： 线上业务场景 稳定性要求至少 99.99%，对查询的 90 分位功能抖动敏感； 架构层面需要支持多活的需求，对数据的全都性与准时性都有要求，必需保证数据的最终全都性，数据更新秒级可见； 不同线上业务，插件需求、索引分片规章都是多样化的； 众多独立集群如何快速平滑地进行滚动升级，保障的线上业务无影响。 准线上业务场景 离线快速导入时效性要求分钟级，实时导入 10 亿条数据需要 5 个小时，导入时在线资源消耗严峻，线上服务基本不行用，导入成本消耗过大； 查询的多样性，14W+ 查询模板，单索引最高有 100+ 应用同时查询，在多租户场景下，如何保证查询的稳定性。 平安与日志场景 千万级别数据每秒的实时写入，PB 级日志数据的存储，对大规模 ElasticSearch 的集群提出诉求，但 ElasticSearch 有本人的元信息瓶颈，详见团队同学的共享：/article/SbfS6uOcF_gW6FEpQlLK ； 查询场景不固定，单个索引几百亿级别的数据体量，需要保障不合理查询对集群与索引的稳定性风险可控； PB 级存储，查询频率低，但查询的时效性要求 S 级别前往，全部基于 SSD 盘，成本太高，需要在查询体验没有太大变化的情况下，降低全体的存储成本。 那么，如何处理这些问题呢？欢迎到 QCon 全球软件开发大会（广州站）现场与我面对面沟通。 如何打造“存储成本低”的搜索大陆与台湾 目前，在日志与平安分析场景下，存储成本压力很大，属于典型的“写多查少”的场景，我们对存储成本的耗散点进行了深化的分析，全体情况如下： 针对资源耗散点，我们在架构层面进行了优化，全体成本降低了 30%，累积节省了 2PB 的存储，分别从以下几个方面进行了优化 存储索引分别：日志与索引进行分开存储 不合理的索引字段 Mapping 自动优化 冷热数据进行了分级存储 ES On DockerCeph 改造 将来进展规划 基于 ElasticSearch 的搜索大陆与台湾给用户带来的收益 服务了超过 1200+ 平台业务方，其中 20+ 线上 P0 级应用，200+ 准实时应用； 索引服务接入效率从原来的两周降低到 5 分钟； 服务稳定性有保障：线上场景 99.99%，日志场景 99.95%； 高频运维操作一键自助完成，90% 的问题，5 分钟完成定位； 全体存储成本是业内云厂商的 1/3。 不足点 目前滴滴 90% 的集群还是在 ElasticSearch 2.3.3 版本，内部修复的 BUG 与优化，无法跟社区进行同步； 目前通过 ES-GateWay 的方式支持了多集群方案很好的满足了业务进展的需求，但是集群变多之后的，版本维护与升级、全体资源利用率提升、容量规划都变得格外困难。 进展规划 解架构之“熵” 突破引擎元数据瓶颈，提升运维效率，降低成本 -ES - Federation; GateWay 力量插件式下沉引擎，削减两头环节，与社区融合，优化功能。 提引擎迭代效率 100 个节点集群滚动重启时长从 2 天提升至 1 小时； 架构层面处理跨大版本升级之“痛” 2.2.3 - 6.6.1 http restful。 聚焦价值问题 多租户查询、CBO、RBO 的查询优化器建设； 数据体系化 - 数据智能化； 基于 Ceph、Docker 改造 ElasticSeach，支持 Cloud Native 的存储计算分别。