-贾新禹
2024云栖大会上，我们的阿里云高级技术专家——贾新禹先生，向我们全面解析了Elasticsearch Serverless在智能日志分析领域的关键技术、优势及其在实际应用中的价值，以及为实现高效且成本效益高的日志数据分析。发布内容主要分为四大部分：日志分析场景的核心痛点、日志分析型 Serverless 能力介绍、关键技术解读、快速入门的方式。
一、日志分析场景的核心痛点
众所周知，ES 在企业检索、日志场景应用广泛，大量的企业使用ELK、EFK作为其日志的解决方案，阿里云在公有云上和在集团内部也有大量用户来使用 ES 作为其日志分析引擎。我们在与这些用户的长期沟通中，发现日志分析场景最为核心的痛点就是性价比。
具体表现有以下四点：
- 资源成本高：为了存储海量的数据，保证安全的水位，承载突发的峰值，需要预留住大量的资源，这也造成了成本居高不下。
- 运维成本大：在海量数据的这个场景下，索引的 Shard 、副本配置和 Rollover 策略等等非常复杂。尤其是在数百 TB 甚至 PB 级的大规模数据下，数百个节点的状态同步，数十万个 Shard 的索引搬迁，这些开源 ES 的默认配置 已不再适用，因为运维团队需要投入大量人力来解决这些问题。
- 读写性能难以保障：在严格限制成本的情况下，如何保障读写性能更是个很大的挑战。
- 稳定性难以保障：开源 ES 中，读写操作风险相互影响，而且缺少熔断能力。在负载高的时候，比如说CPU超过50%，它的处理能力会断崖式下跌，单条大型聚合查询便可能会导致集群宕机。
自从阿里云 ES 上线以来，我们就一直在着力解决这些问题。
- 2021年，阿里云推出 Indexing Service , 通过读写分离与写入池化，同样规格下提升了800%的写入能力，实现了写入的按流量计费。让用户再也不用为写入性能担忧。
- 2022年，阿里云推出了Open Store 存算分离架构，通过多级智能缓存及查询优化，实现了查询性能不下降的情况下，存储成本降低70%，并且实现了存储按量计费。
- 2023年，阿里云基于日志场景的特点，结合 Indexing Service 和 OpenStore ，在内部推出了 Serverless 的LogHouse 日志服务，进一步对用户屏蔽复杂的配置，做到了开箱即用，取得到一个非常好的效果。
- 2024的今年，我们推出了公有云上的 Serverless 日志分析型，用来帮助云上的用户降本增效。
那么我们在内部的 LogHouse 下取得什么样的成绩呢？与之前的日志全观测方案相比，我们将成本平均降低了51.44%，每月为公司节省了数百万元。其中，是在菜鸟某业务和高德某业务中更是下降了78.04%和64.86%。效果非常显著。
二、日志分析型 Serverless 能力介绍
那日志分析型 Serverles 有哪些能力可以帮助用户来实现降本增效呢？主要靠 Serverless 的四大关键能力。
- 开箱即用，兼容开源。我们所有的 API，SDK 都和开源保持一致，这样用户就无需任何代码改动，也不需要适配特殊的 SDK 就可直接使用，极大降低了用户的接入成本。
- 高性能低成本。我们通过在日志分析场景和定制优化，大幅提升了单核的处理能力，同时又显著降低了存储的成本。
- 真正的按量付费。不同于之前的按流量付费，我们在 Serverless 版本上实现了按 CPU 用量收费的。这和之前的按流量付费相比，带来了很大的成本节省。
- 智能调度免运维。在我们的 Serverless 场景下，用户不仅不需要关心集群运维，甚至连索引的Shard、副本都不需要关心，只需要关心保存天数、表结构即可，极大减少了运维配置的工作。
2.1 第一个关键能力是：开箱即用，兼容开源
在日志分析型 Serverless 上，大家依旧可以使用熟悉的这些的 API , 包括一些开源的 ES 基础原生 API 都是可以直接使用的。为了充分的兼容开源，我们甚至都没有使用 Xpack 中的数据流、ILM 等概念，而是直接在原生的索引上进行拓展，通过增加保留天数，写入优化等特殊的索引配置，让用户无需替换 SDK 或者适配特殊的 API ，即可直接应用。另外，我们还提供了简单易用的白屏操作页面，哪怕 API 不会使用，也可以轻松创建与修改。 
2.2 第二个关键能力是：高性能低成本
从下图中可以看到，最左边的浅蓝色的是 Serverless , 中间的深蓝色是 Paas 上用了 Indexing Service 的日志增强版，橙色的是最佳实践下的开源自建。
在我们的基准数据集下，我们的日志增强版比开源的最佳实践提升了两倍多，从2MB/s 提升到了4.32MB/s。而我们的 Serverless 版又比我们的日志增强版提升了2倍多，达到了9.25MB/s，整体比开源的最佳实践提升了4.5倍。
在压缩比上，Serverless 版更是从1.93提升到了5.8，提升了3倍多。需要注意的是，这是在最佳实践下的开源自建才能达到1.93这个效果。如果没有丰富的 ES 优化经验，直接使用 ES 的话，那这个就不是1.93，而是一个0.8，那成本会非常高。
在此之前，1G 基准数据开源需要530MB 空间，现在仅需要176MB。这些优化让我们能够在相同的资源下实现更高的写入性能和更低的存储成本。
2.3 第三个关键能力是：真正的按量付费
按 CU 付费和按流量付费到底有什么区别呢？大家可以看到上图同样的1G 流量下的情况，不同的表结构所消耗的计算资源差距极大，从最大的 110CU 到最低的 46CU 相差将近2.4倍。因此大部分场景下，我们按 CU 付费比按流量付费可以节省将近50%。
今年，我们除了在存储和写入上实现了按量付费，在查询上我们也实现了百分之百的实际用量付费。大家可以看到在上图中，右上方是查询的 CPU 用量，右下方的是查询的 QPS ，两个曲线基本是完全一致的，这也就说明了是百分之百按照用量在做付费的。
2.4 第四个关键能力是：智能调度免运维
这上面的三条线，最底下的一条是用户的实际的费用消耗。中间的这一条是我们的配额限制线，而最上面绿色的则是我们的资源线。为了更直观的展示，我们将资源线设置到了一个上限120，但是大家在实际使用中，这是没有上限的。然后大家可以看到，在业务水位平稳增长的一个场景下，它是基本上是不可能遇到我们的配额险。整体对用户是透明无感的。除了在资源上的自动扩充，我们还会通过一些自动化手段来调整集群和索引的配置来实现让我们的索引始终在一个最佳的状态下。
三、关键技术解读
3.1 日志分析型 Serverless 整体的架构
整体的架构如图所示，左边是我们的数据面，右边是我们的管控面。
服务层转发对应流量给计算层的读写和元数据服务，最下方的数据层为一个的共享的分布式存储。右边的管控面，包含应用管控系统，负责应用生命周期管理，索引元数据管理，配额管理和智能运维系统，负责进行弹性决策以及一些内部的的自动化运维。开源兼容就是通过这一层服务层的包装来实现的。
3.2 高性能成本的关键
3.2.1 高性能成本的关键—引擎架构
首先看下图中我们的引擎架构，我们是通过读写分离架构，通过网关层将读写请求各自路由到对应的服务节点上，随后基于 Openstore 进行存算分离，数据不落在本地，也无需进行实时的副本同步。只需定时从 oss 拉取即。这样的架构，让索引只需构建一次，本地存储也不再成为瓶颈，使得快速弹性成为了可能。
3.2.2 高性能成本的关键—倚天机型优化
其次，我们还通过将底层 ECS 从 Intel 换成了倚天的 ARM机型，这使得安全水位可以从30%提升到了50%。资源利用率可以提升了66%。那为什么可以提升安全水位呢？大家可以看到下面这三幅图，其中虚线的红色是我们倚天，黄色的实线是我们 X86 。可以看到当 CPU 超过40%时，在 X86 上性能会有急剧的退化，而在倚天上性能依旧稳定，这就是我们为什么可以提升安全水位的底气。
3.2.3 高性能成本的关键—写入优化
除了在架构上的优化，我们在 ES 内核上也做了大量的优化。为了便于大家理解，我们只选取四个主要写入优化来说。
- 左上角的是我们的 Source 复用 DocValue。这其实很好理解，就是我们不存原文，在返回时通过 DocValue 拼接出 Source 。这样可以极大的减少我们的存储空间，并且可以让我们写入的速度更快。
- 右上角这一组则是我们定制化的 LineAnalyzer 的分词器。因为 ES 原生分词器为了通用性，实际上会有非常多的冗余计算，我们针对日志场景重写了分词逻辑，就单通过这一个特性就使得单核性能提高了20%。
- 左下角是指我们用 ZSTD 压缩，替代 ES 原生的压缩，并且通过定向路由技术，保证了数据的连续性，进一步提高了压缩率。
- 而右下则是我们针对 Keyword 或数值字段，不健倒排索引，只存 Docvalue 。在查询时通过布隆过滤器进行快速剪枝，进一步提高了写入性能。通过这一系列的内核优化，最终使得我们的单核写入能力提升300%，存储大小减少70%。
3.2.4 高性能低成本的关键—查询优化
众所周知，在存算分离的场景下，如何保证查询性能是一个很大的挑战。而我们通过并发查询，以空间换时间，将多次 IO 变成一次 IO ,将多次 IO 变成一次 IO 暂存在内存中 ，后续直接从内存读取。将 OSS 查询提速200%，如下图所示。
左下角是 Kibana 的 Discovery 页面，使用过 ES 的大家可能都知道，当ES 在数据范围很大的时候，查询速度会非常慢，往往需要数分钟才能刷出次页面。针对于这个场景也做了一系列的定制优化，我们做了查询剪枝，并通过分片内的并发查询，使得百亿数据的展示优化到了10s 以内，点查速度提升了10倍以上。
而右下角则是我们基于应对查询稳定性，做的慢查询自适应降级。我们通过重写了 ES 的线程池逻辑，引入了优先级队列，根据查询的历史情况，自动将慢查询降级，来避免影响快查询。
正是这从架构，宿主机到内核层面的一系列定制优化，让我们取得了单核能力比开源强4.5倍、压缩率强3倍的高性能低成本的好结果。
3.3 真正的按量付费
下图的左侧是按量付费实现的时序图，我们在请求开始前，打上对应的应用，索引信息。然后再通过一条异步汇报链路进行统计。而对于不同的 CPU 规格，则通过主频压制和统计调整方式进行归一化，避免机型差异。
下图的右上角是我们劫持并记录其对应的线程池情况，大家可以看到我们劫持了大量的线程池，但其实并不是所有的线程池，这是因为我们不记录系统的开销，比如说 GC 、数据迁移等，都不会把费用算给用户，而是由我们阿里云的系统自行承担，这其实会比按机器的 CU 减少了20%左右的费用。通过这些机制，我们让用户真正的实现只为自己的使用付费。
3.4 智能调度免运维
运维其实主要会分成两类自动化运维，一类是对资源的调度，另一类是对配置的调优。
首先对资源的调度，是为了保证资源的利用率。具体就是基于 Shard CU 进行 Rebalance。我们在 ES 的 Rebalance 的策略中引入了 Shard CU 消耗这一项，可以保证各个节点的水位均衡，而除了在 ES 节点内部做这样的均衡外，我们在多个服务集群之间也会通过这个方式来进行均衡，来保证整体水平均衡。
第二个对配置的调优，以保证实例达到最优状态。配置包含集群配置，索引配置。因为我们默认的配置并不一定适用于所有表结构。因此我们会实时去统计每一个节点的一些基本信息，比如 CU 用量、内存用量、IO用量、网络吞吐等十多个指标，根据占用的这个线流器的情况和线程的情况，判断当前集群和索引有无达到瓶颈，若有瓶颈，则会进行对应的调整。
四、快速入门的方式
最后将快速介绍一下如何接入，只需三步。
第一步：打开控制台，创建应用
第二步：填写对应的基本信息
第三步：等待1到2分钟，便可创建完成
通过以上的介绍大家应该已经了解了日志分析型 Serverless 的四大核心能力及其背后的关键技术实现。我们相信，通过高性能低成本、真正的按量付费的免运维 serverless 产品，能够帮助大家有效降低日志场景成本。
最后，我们推出了最新的阿里云 Elasticsearch 向量增强版，其向量性能提升5倍！内存成本降低75%！可以灵活对接多种产品，提供多场景解决方案，与AI搜索开放平台无缝结合，拥有云原生管控和运维平台，同时我们也准备了成熟的数据迁移与同步方案，价格更是超乎想象，欢迎大家前来使用。
向量增强8.15版全部规格，以及通用商业版/内核增强版的2C～4C规格，新购年付5折优惠重磅上线！
