此前，滴滴日志主要存储于 ES 中。然而，ES 的分词、倒排和正排等功能导致其写入吞吐量存在明显瓶颈。此外，ES 需要存储原始文本、倒排索引和正排索引，这增加了存储成本，并对内存有较高要求。随着滴滴数据量的不断增长，ES 的性能已无法满足当前需求。
在追求降低成本和提高效率的背景下，我们开始寻求新的存储解决方案。经过研究，我们决定采用 CK 作为滴滴内部日志的存储支持。据了解，京东、携程、B站等多家公司在业界的实践中也在尝试用 CK 构建日志存储系统。
面临的挑战主要来自下面三个方面：
技术Leader核心工作是让团队拿更好的成绩，日常工作主要是制定方案、推进业务、掌控下属、协助领导等四项内容，本次分享主要分享最基础也是最重要的管理职责：
好几年前的文章了，之前排查问题，随手写的，但是发现其他团队人遇到类似问题没有思路，所以还是发出来，给大家一起解决问题的思路。
ES集群磁盘报警，发现/home/coresave/ core文件导致根目录磁盘被打满，删除core文件恢复，已知这个集群新上线了jdk 17 zgc，排查下jvm为啥core。而jvm core一般有以下几个原因：资源超了（内存、线程数，vma数等），jvm bug（比如指令集）
先去elasticsearch根目录查看core日志，即hs_err_pid_xxx.log，内容如下：
看core原因是因为资源不足（不一定是内存）导致的问题，jdk 17 zgc core后，fatal error 原因与g1 有明显不同，突然不知道怎么去排查了，研究下，思路如下。资源不足原因我们可以在hs_err.log里查看具体的原因，步骤如下：
前文分别介绍了滴滴自研的ES强一致性多活是如何实现的、以及如何提升ES的性能潜力。由于滴滴ES日志场景每天写入量在5PB-10PB量级，写入压力和业务成本压力大，为了提升ES的写入性能，我们让ES支持ZSTD压缩算法，本篇文章详细展开滴滴在落地ZSTD压缩算法上的思考和实践。
ES通过索引（Index）对外提供数据检索能力，索引是用于组织和存储数据的逻辑单元。每个索引由若干个分片（shard）组成，每个分片就是一个Lucene索引，可以在不同的节点上进行分布式存储和并行处理，提高性能和可伸缩性。每个分片由一组段文件（segment）组成，段是分片中更小的存储和搜索单元，是一组物理文件，包含了检索需要的倒排索引（词项和文档ID的映射关系）和文档存储（字段值和其他元数据），如下图：
Lucene作为ES的底层索引引擎，提供了灵活的数据检索能力，同时也导致CPU、存储占用较为严重。为实现降本增效，23年上半年，ES团队开启了Lucene压缩编码优化专项，通过改进存储层压缩算法，从而降低单位Document所占用的资源。本文概述了ES的底层索引文件，并介绍了Lucene存储压缩编码的优化。
ES的压缩编码优化专项涉及到Lucene底层的文件存储，Lucene索引由一组Segment构成，每个Segment包含了一系列文件，重点文件类型如下图：
前文介绍了滴滴自研的ES强一致性多活是如何实现的，其中也提到为了提升查询性能和解决查询毛刺问题，滴滴ES原地升级JDK17和ZGC，在这个过程中我们遇到了哪些问题，怎样解决的，以及最终上线效果如何，这篇文章就带大家深入了解。
滴滴ES在2020年的时候由2.X升级到7.6.0，该版本是在官方7.6.0的基础上改造而来，支持的是JDK11，采用的垃圾回收器是G1。ES的业务主要分为两类，一类是日志场景，该场景写多读少，高峰期CPU使用率在85%左右，写入性能是它的主要瓶颈；另一类是非日志场景，例如POI检索、订单、支付，这些场景对查询耗时及查询稳定性都有着较高的要求。
随着ES业务数据量的增长，GC导致的查询稳定性压力剧增，已经逐渐无法满足业务需求。以下是ES面临的主要问题：
1、Yong GC平均暂停时间长，一些集群的平均暂停时间达到百毫秒级别。
GC暂停时间长在订单集群这种112G大内存的进程中表现尤为明显。下图为订单集群的GC暂停时间，可以发现一次Yang GC的平均暂停时间就达到了200ms，有些甚至超过了1s。ES的核心业务POI、订单等对查询耗时的P99以及Max都有一定的需求，GC暂停导致的查询延时以及毛刺问题无法满足业务需求。
