作者：朱杰 Elastic中国区首席解决方案架构师
一、Elasticsearch功能改进
①增强集群扩展性系统优化项目
该项目创建时间较久，可以在GitHub里通过number77466进行查看。
项目包含了大量任务，涉及88个task，目前优化进度为69个。我们从Elasticsearch的各个不同部分，比如general、search以及网络方面做大量测试与发掘，查看哪些点阻碍了Elasticsearch的扩展性。此处的扩展性主要指在大集群里，具有大量分片的情况下，集群消耗了大量资源，对搜索以及生命周期管理等都会产生很多负面影响。
因此，该工程会从所有方面进行测试、发掘，整理在系统扩展性方面的各种瓶颈。
我们在GitHub issue里罗列了所有点，并且会后面版本陆续做修复，使Elasticsearch的集群承载能力变得更好，能够处理更多分片。
业务复杂度增加之后，分片也会越来越多。经过集群扩展性优化的一系列修改后，测试显示整个集群扩展性得到了较大提高，降低了内存使用，搜索更快，生命周期、进度等不会因为大量分片而降低。
②仅保存Doc Value的字段
Doc Value指列式存储，搜索时必须构建索引。而在8.1版本里允许某字段仅保存列式存储，不会构建索引，只会将value存在列式结构里。适用场景有比如全观测场景，有大量指标数据往往只用于指标聚合值、平均值等，不会用字段进行查询与过滤。也有一些业务场景可以选择性地将有些字段的value保存下来，而不会对其进行过滤。
该能力带来的好处在于可以节省大量存储空间，尤其在全观测场景，数据量非常可观，测试显示可以节省大于20%的存储空间；其次，能够提高索引构建吞吐率，全观测大数据量写进时，可提高20%地索引速率。但与此同时，它牺牲了一定的查询性能，可能会下降5到10倍。
总体来说，该能力是通过牺牲一定的查询来换取成本的下降以及索引构建速率的上升，用户可以根据具体情况选择是否使用。
③从Doc Values合成_source
8.4版本推出的功能同样围绕着列式存储Doc Value进行，进一步优化了成本，主要着眼于字段source。
存储写进JSON的原始文档存储在source里，因此我们考虑：如果不存source，是否可以节省大量存储空间？那么，原始source能从哪些地方来？其中一个很好地途径便是列式存储，从Doc Value重新将其构建回source，从而实现节省存储的目标。
其优势在于极大减少了索引大小，提高了写入性能，但也带来了一定的限制：
l 轻微降低get_source性能，因为需要从列式存储恢复source。
l 原始JSON里的字段顺序难以保持稳定性，与写入时JSON里的字段顺序不一。
④新的集群平衡策略
此前，在大集群、分片比较多的情况下，经常会出现分布不均匀的问题，有些节点的磁盘写得非常快，会过早触发水位线，导致磁盘不均匀。索引在大数据上写入时，因为不均匀的分布会引发写入热点。其根本原因在于原先的Elasticsearch采用了较为简单的平衡策略，只考虑分片数量，并且在做平衡时算法较简单，造成很多不必要的分片移动，不会根据最终的集群分布做合理规划。
而新的平衡策略会根据最终集群分布的一致性做预先计算，再进行必要的分片挪动，能够使整个集群分片变得更均匀。现阶段提供了两个方向的策略：
l 基于磁盘分片大小维度进行考虑，最终使每个节点的分片总大小比较均匀。然后基于此计算整个集群状态，做必要的分片挪动。
l 基于索引负载进行衡量，负载依据为根据节点上的写线程数量进行评估。有些节点负载比较高，会做全局评估，再做合理分布，使得写入均匀落在不同节点上。
二、Elasticsearch全新功能
①查询旧版本ES创建的索引
8.3版本实现了查询旧版本ES创建的索引的能力。
此前，做Elasticsearch升级时，必须重新做数据索引才能被新版本读写，极大妨碍了版本升级。另外，在全观测与安全场景下，可能会需要查询比较远期的旧数据，而旧数据往往在旧版本上生成。
有了该功能，能够减少升级负担，最快使用引入大量优化特性的新版本，同时能够查询老版本的数据。
原理为：将老版本的snapshot恢复到新集群里，作为存档index做只读查询。或存储在Elasticsearch的可搜索快照对象存储里，可以直接查询老版本快照里的数据。
注意，该能力对于支持的数据类型有一定限制，无法支持所有Elasticsearch数据类型；其次，索引只能被读取，不能被写入；另外，性能方面稍慢，牺牲了速度。
②TSDB时序数据优化
8.6版本正式推出了Time Series Database，是针对时序指标数据的全新功能，底层基于现有框架实现。
时序数据有很强的约束性，因此也可以实现很多优化手段。比如，将数据尽量集中在一个索引或某台机器的某个shard里，并且按照时间序列进行预先选择，使得磁盘上的存储经济性以及搜索速度都得到了质的提高。
实现原理为：
第一，根据数据维度、各种数据标签、timestamp等联合因素生成TSID，目标是要将相同dimension、相同timeseries的数据都集中在一个shard的某个segment里，因此生成逻辑需要进行改造。
第二，数据经过排序与聚合后能够产生很高的压缩率，比如某些指标具有很多相同的tag（维度信息），而这些维度信息几乎都是重复的。如果所有数据的document都紧靠在一起，可以得到极高的压缩率，并且在后续做聚合运算时，性能也会大幅提高，可以直接精准路由到某个segment做聚聚合。
第三，时间戳不会交错，一个datastream里会生成很多个index，index里的起始时间与结束时间不会在两个索引里交错，可以很容易地定位到某个索引直接进行计算与搜索，忽略掉不可能存在答案的索引，可以极大提高性能。
此外，时间序列里会存在一些边缘场景，比如迟到数据，先发的数据比后发的数据晚到。在该种情况下，依然可以接收迟到数据，但会将其存在新索引里，以保证不同index时间不会交错的目标。经测试，最高可降低约44%的索引大小。
②TSDB降采样
TSDB降采样是时间序列数据库的标配功能。很多采样精度非常高，但是没必要保存原始精度，可以降低采样频率拟合原始目标。采样越低，数据精度越低，但是存储下降也非常可观。
可以在生命周期管理里启用该任务，降采样结果会写到新索引里，与原始精度索引进行联合查询，用户无需感知，会根据查询时间段选择合适精度的索引回答，全面支持Kibana的各种分析组件。
③全新的向量搜索
7.3版本曾提供暴力搜索的方式做向量匹配，但只适用于小数据量场景。如果使用在大索引上，延迟会非常大。
而8.0版本提供了HNSW索引，在较大数据规模上也能够获取较好的数据性能。8.5版本开始，KNN集成到了标准的search API下面，用户可以在标准search里结合原始query对某些字段进行knn query做综合打分，能够获取到数据集。
④机器学习支持外部模型
支持了有监督的机器学习。支持了有监督之后会涉及到模型问题，在模型方面，Elasticsearch并不会让用户去构建很多模型，现在有丰富的模型社区和模型市场，用户可以下载很多高质量的外部生成模型。
用户可以在外部下载模型，通过Eland工具导入到Elasticsearch里，由Elasticsearch提供原生的机器学习能力实现分词、NLP等相关任务。
兼容性方面，并不是所有Pytorch模型都能够直接导入，具体能导入哪些需要参看兼容模型文档。简单来说，从8.0开始主要支持NLP任务，比如模型填空、命名实体识别、文本分类（二分类或多分类）、生成词向量等，后续也会支持问答、翻译类型模型。
上述能力使得Elasticsearch能够支撑用户的更多应用场景，用户无需自己写代码编写一套机器学习框架，能够更快地完成项目。
三、Elasticsearch研发前瞻
Elasticsearch Query Language和Serverless Architecture是未来研发的两个重要功能，是全新的架构。其中，serverless架构与现有的存算一体传统架构有着天壤之别，Elasticsearch Query Language（ESQL）是一种全新查询语言。
传统Elasticsearch存算一体的架构存在显而易见的弊端。同时，云原生兴起，给众多大数据组件提出了新的要求。
原先架构的弊端包括：
l 写入损耗：有主分片，也会有副本，写入时在主分片上做了一份索引，同时也需要在所有副本上消耗CPU资源构建副本。副本数目越多，浪费的CPU资源越大。
l 多份数据拷贝。在云原生架构下，底层存储本身是高可用与多副本，没有必要再依靠Elasticsearch提供多副本能力，完成高可用要求。
l 现有结构里，写入与搜索共享CPU，会争抢CPU，有大量写入时必然会影响搜索速度。
l 现有架构冷热分层，因为存算一体的限制，热数据和冷数据分别属于不同数据节点，会带来大量数据移动，从热节点搬运到冷节点，再搬运到冻结节点。
l 会影响集群规划，使规划变得麻烦。因为存在大量数据搬运，所以会对每部分进行大小规划设计，需求变更之后规划也需要变更。
而Serverless架构的目标是存与算彻底解耦，也意味着写入与搜索做了分离。会有独立节点做写入索引构建，构建好segment之后，将其写入到对象存储里，分发到search节点。
通过在对象存储中做解耦，将写入与搜索做了分离，索引只需要构建一次即可分发到多个search里，避免浪费大量cpu资源；其次，可以很容易地独立扩展存储层和计算层，可以灵活扩展写入层，也可以独立扩展search侧计算资源，每一部分都可以独立伸与缩，甚至可以将计算资源缩到0，需要时再拉齐某些search节点，集群变得前所未有的灵活。
同时，因为对象存储的引入，存储变得非常弹性，高可用也得到很高保障，不再有大量数据搬运，不需要在不同生命周期里，在热节点、冷节点等之间搬运，消除大量不必要的搬运动作，包括分片均衡等数据搬运。
搜索性能方面，沿用了原来的可搜索快照技术，会有本地缓存来存储对象存储里的数据，可以选择全量缓存，也可以选择根据命中的冷热点进行缓存，也简化了管理。
现有情况下，我们大多基于云环境构建，而改为云原生架构之后，版本概念会变得模糊，新功能可更快到达用户端。
ESQL是管道连接的分布处理逻辑，与原先的Elasticsearch是完全不一样的语言，会涉及到数据的搜索获取，可以做独立的数据转换，可以对数据进行中间步骤的计算与数据转换等，可以交给下一个比如聚合运算任务，还可以对数据进行排序等分阶段的步骤，灵活性远超现有的查询语言。
ESQL的最大意义是可以引入很多数据转换工作，可以保持极大的灵活性，查询时在语言里直接做大量数据转换，使应用实现逻辑变得更简单。比如Join、Lookups、子查询等，经过前面步骤后，可以在结果集里再进行搜索、聚合等。
ESQL是一种全新的分布式计算引擎，有自己语言的分析器、优化器，还有分布式执行引擎。面向大数据量设计，并且是分布式，支持弹性伸缩。未来，我们还会纳入比如外部数据源，打开更大的想象空间，使解决方案层面获得更大提升，在应用层面也可以获得更多提升。
四、Elastic解决方案更新
在全观测解决方案里，经过一两年的沉淀与积累，我们实现了丰富全面的功能，包括日志、指标、APM的完整功能（包括客户端、分析端）、RUM以及用户体验观测。RUM指真实用户追踪，追踪用户与网站如何交互等数据，用户体验观测可以对页面加载情况、各个资源加载情况进行分析。
安全解决方案也已经十分全面，不仅包括传统的SIEM检测，还有主动防御。安装Elastic Agent软件至终端，即可主动防御恶意软件、勒索软件等。同时，具备强大的信息采集能力，涵盖内核级数据采集、安全方面数据采集、主机数据采集以及osquery数据采集等，安全数据采集变得更简单、更丰富。
有了数据之后，传统的SIEM部分也标配了规则检测引擎，预置大量原厂检测规则，具备完备的告警能力，可对接其他系统。
在安全响应方面，可以通过email、Webhook等工具对接外部平台，也可以通过原生外部case连接器对接ServiceNow等安全响应工具。另外，可以通过Elastic Agent实现主机隔离或主动检查状态等。
