网站代理登录域名,wordpress 密码加密方式,学校招标网站建设,网络推广网站建设有限公司简介#xff1a; 开源最大的特征就是开放性#xff0c;云生态则让开源技术更具开放性与创造性#xff0c;Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际#xff0c;我们邀请业界资深人士相聚云端#xff0c;共话云上Elasticsearch生态与技术…简介 开源最大的特征就是开放性云生态则让开源技术更具开放性与创造性Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际我们邀请业界资深人士相聚云端共话云上Elasticsearch生态与技术的未来。
开源最大的特征就是开放性云生态则让开源技术更具开放性与创造性Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际我们邀请业界资深人士相聚云端共话云上Elasticsearch生态与技术的未来。本篇内容是阿里巴巴集团技术专家魏子珺带来的阿里云Elasticsearch云原生内核分享人阿里巴巴集团技术专家魏子珺
视频地址https://developer.aliyun.com/live/246150
关于阿里云Elasticsearch云原生内核本文将通过三个部分展开介绍
阿里云Elasticsearch内核概览云原生Elasticsearch定义阿里云原生Elasticsearch实践
一、阿里云Elasticsearch内核概览
一阿里云ES的优势
下面这个对比图可以很好地说明阿里云ES相比开源ES 的优势。 先看内圈开源ES针对通用硬件设施而阿里云ES内核则是针对阿里云基础设施深度定制的内核可以最大地发挥阿里云基础设施的性能以及成本方面的优势。然后看最外圈开源ES内核为了适应ES丰富的使用场景包括搜索可观察性等无法做到功能和性能兼顾而阿里云ES内核依托于阿里云ES的服务可以做很多场景化的优化和功能增强在搜索和观察性等方面会比自建的ES更有优势。内核在中圈向下运行在阿里云基础设施向上依托于阿里云ES服务。可以看到阿里云ES内核相比开源ES自建集群不论在成本、性能、稳定性和功能上都会更具优势。
二 基于用户需求的内核建设
用户对阿里云ES内核的需求主要是以下三个方面
1、简单 存储容量能够不断扩充计算有足够的弹性用户不需要操心资源的问题。
2、好用 开箱即用不用进行一系列复杂的部署和配置直接根据场景提供最优的配置即可还要有丰富的检索功能可以使用。
3、性价比 阿里云ES做到价格足够低性能足够好足够稳定。
结合上述的需求我们从下面四个方面展开内核建设。 1、成本节约 第一我们提供计算存储分离的增强版ES成本上节省了副本的开销保证足够的弹性可按需使用。第二支持冷热分离成本更低地存储介质。第三Indexing Service这是我们全新发布的产品对写多读少的场景有很大的成本节约。第四索引数据压缩我们新增的压缩算法可以比默认的压缩方式提升45%的压缩率。
2、性能优化 第一我们研发的ElasticBuild相比在线的写入能有三倍的性能提升。第二我们还研发了物理复制功能从最早支持计算存储分离到现在的支持通用版的ES物理复制通过segment同步而不是request同步的方式减少了副本的写入开销所以有一个副本的情况下写入性能能有45%左右的性能提升副本越多提升越明显。第三bulk聚合插件在协调节点聚合下载的数据降低分布式的长尾效应在写入吞吐高、分辨数多的场景写入吞吐能有20%以上的性能提升。第四时序查询优化针对range查询可以直接跳过不在range范围内的segment结合时序策略可以获得更好的查询性能提升。
3、稳定性提升 第一我们研发了集群限流插件能够实现索引节点集群级别的读写限流在关键时刻对指定的索引降级将流量控制在合适的范围内。第二慢查询隔离池的特性它避免了异常查询消耗资源过高导致集群异常的问题。第三协调节点流控插件它集成了淘宝搜索核心的流控能力针对分布式环境中偶发节点异常导致的查询抖动能够做到秒级切流最大程度降低业务抖动概率保证业务平稳地运行。第四monitor插件它采集了集群多维度的指标可以提供全方位的监控。
4、功能增强 第一向量检索插件是基于阿里巴巴达摩院Proxima向量检索库实现能够帮助用户快速地实现图像搜索、视频指纹采样、人脸识别、语音识别等等场景的需求。第二阿里NLP的分词插件它是基于阿里巴巴达摩院提供的阿里NLP的分词技术支持阿里内部包括淘宝搜索、优酷、口碑等业务提供了近1G的海量词库。 第三OSS的Snapshot插件它支持使用阿里云OSS的对象存储来保存ES的Snapshot。 第四场景化的推荐模板可以针对不同的业务场景提供成本、性能的优化。
以上的这些特性都能在我们阿里云ES官方文档中看到欢迎大家使用。
二、云原生ES的定义
一云原生Elasticsearch如何定义
首先看一下什么是云原生。阿里巴巴云原生公众号前段时间推出了一篇文章《什么是真正的云原生》总结了云原生的定义第一弹性、API自动化部署和运维第二服务化云原生产品第三因云而生的软硬一体化架构。 上图是云原生架构的白皮书封面这是由阿里云二十位云原生技术专家共同编写已经正式对外发布欢迎大家阅读。
那么什么是云原生ES
ES的云服务开箱即用能用API自动化部署和运维计算存储分离弹性可伸缩能充分利用云基础设施网络、存储和算力等
以上三点就能对应最开始提到的三个圈 服务内核和基础设施这样才是云原生ES。
二云原生 Elasticsearch如何设计 第一它必须是计算存储分离的架构这样才能提供更加弹性的计算能力和无限的存储空间。第二可以支持冷热分离冷热的节点都要是计算存储分离的架构。冷节点使用高性价比的对象存储相比热节点可以有90%的成本节约。第三Serverless的用户真正关心的是索引的使用而不是ES集群的维护。Serverless让用户的关注点从集群的维度可以下沉到索引维度。
三云原生Elasticsearch内核挑战
实现这样的云原生内核挑战是非常大的主要的挑战分为下面三个方面
1、热节点的分布式文件系统 第一分布式文件系统自身的稳定性保证ES对Latency非常敏感它提供性能和稳定性与本地盘相当的分布式文件系统这个挑战本身就非常大。第二ES在实现一写多读时如何防止出现多写的情况。ES数据是在内存读写需要的内存状态数据、数据是如何保持一致性的这些都是很大的挑战。
2、冷节点的对象存储 对象存储提供的是HTTP接口所以需要去适配。另外对象存储的单次IO Latency非常高所以只有在冷节点相对Latency不敏感的场景才有机会使用。如何解决Latency最高的问题也是很有挑战。最后是对象存储无法使用到操作系统的pagecache和预读能力所以要用对象存储这些能力必须在ES侧实现。
3、Serverless 最难解决的就是多租户的共享和隔离的平衡问题如果不同索引直接产生相互的影响在云上是不可接受的。如果不共享就意味着资源无法充分利用。如何平衡共享和隔离的问题这是Serverless最大的挑战。 第二是体验基于索引的使用如何提供和云原生ES一样的体验也是需要考虑的问题。 第三是资源监控如何评估索引的使用资源也是一个挑战。
三、阿里云原生Elasticsearch实践
1、计算存储分离 计算存储分离核心的诉求是弹性它不只是像云原生ES那样支持动态的添加节点、自动Shard搬迁而是彻底的弹性。对于ES来说它的核心诉求是两点Shard秒级搬迁和Replication秒级增加。这样才能解决热点的问题和高低峰快速的动态扩容的问题。如果扩缩容还要迁移Shard的数据弹性是不够的。彻底的弹性一定是Shard搬迁Replication扩充数据是不动的只是调整DataNode对Shard的映射。要实现这样的弹性就必须做到计算存储分离。
阿里云对ES存储分离内核的实现如下
数据存储在分布式文件系统上由分布式文件系统保证数据的可靠性同一个Shard的多个副本数据只保存一份一写多读的场景这样就不再依赖于ES自身的replication可以减少写入的开销。索引扩Shard无需复制数据秒级增加只读ShardShard搬迁无需迁移数据秒级切换DataNode
核心技术之一内存物理复制实现replica的近实时访问
Segment同步的实现细节 图中描述的是ES物理复制的状态机核心是为了解决segment同步乱序的问题。通用的物理复制功能也是一样的实现主要区别在于计算存储分离只需要复制实时生成的segment对于后续产生的segment强制提交commit确保segment落盘来防止大的segment进行复制。而通用的物理复制外界的segment也是需要复制的这种segment往往会比较大。所以这里有一个关键的优化为了防止大segment复制导致的主从可见性差距过大主shard在从shard复制完成后才会打开最新的segment。
下图介绍了物理复制保证数据一致性的方式。 核心是保证checkpoint的一致性通过将主shard的checkpoint同步到从shard来实现。结合这张图可以看下流程当数据写进来的时候主shard会更新checkpoint在第二步刷新segment时第三步将segment复制到从shard时会带上checkpoint第四步从shard会用这个checkpoint更新自己的local checkpoint来保证主从shard使用了相同的checkpoint这样就实现了数据一致性的保证。
核心技术之二两阶段IO fence 核心要解决的问题是防止多写。通过分布式文件系统的管控侧将异常节点加入黑名单直接从根本上防止了异常节点的显露。 上图展示了整体的流程在主Shard节点异常的时候MasterNode 首先发现主Shard的异常然后将主Shard所在的节点加入黑名单。第三步这个节点切断了IO的权限彻底失去了写的能力。第四步master通知从Shard晋升成主Shard。第五步从Shard晋升成主Shard后就开始正常地读写数据。
我们的计算存储分离的架构通过阿里云增强版进行售卖。计算存储分离除了弹性的特点外由于一写多读的特点在性能、成本上都有显著的提升。我们测试了线上阿里云增强版ES和原生ES在同样规格配置的性能对比情况从表格的最右一列红色的标识可以看到不论在translog同步还是异步的场景一个副本的情况下性能都有超过百分之百的提升副本越多性能提升越明显。 总结一下计算存储分离的特点首先它是秒级弹性扩缩容第二由于不写副本所以写入性能能有100%的提升第三由于多个副本存储一份数据所以存储成本呈倍数降低。
计算存储分离——热节点 想要使用我们计算存储分离的ES集群可以选择图中所示的日志增强版欢迎大家使用。 计算存储分离——冷节点 热节点通过分布式文件系统实现了计算存储的分离冷节点也需要实现计算存储分离才能实现弹性。冷节点这部分我们还在研发阶段所以这次分享给大家的是一些思考的内容。 冷节点的成本是第一要素所以对象存储成了首选。对象存储相比分布式文件系统和块存储等特点非常鲜明。劣势大都在挑战中提及到这些劣势相比其他存储无论从易用性和性能上都无法跟分布式文件系统和块存储相比所以这些热节点很难直接使用对象存储。但是冷节点不同冷节点核心考虑的是成本因此它也有一些优势。它的成本比SSD云盘便宜近90%可以真正的按需使用不用预先准备存储空间。另外可以提供12个9的可靠性所以也可以不用存储副本这又是一半以上的成本节约。基于这些优势对象存储成了最好的选择。
如何最大减少它的劣势带来的影响这要从ES的特点说起。ES在可观察性、安全的方向上冷热数据明显日志长期存在SSD上成本过高所以可以考虑冷热架构。第二ES在search的时候很消耗CPU因此可以利用计算时异步地扒取对象存储的数据减少IO等待的时间。第三点是冷数据基本上无写入所以对写入性能要求也不高。以上的三点就是ES冷数据使用对象存储的原因。
Indexing Service Indexing service是我们即将重量级发布的新产品这是我们在serverless尝试的一个产品是针对写入方面的性能优化。相比查询的多样性写入会相对简洁明了。Indexing service从功能方面提供了写入托管服务满足高并发持续数据写入降低了业务集群的CPU开销它适用在日志、监控、APM等时序场景它解决的最大痛点是写多读少而且很多时序场景下写远多与读业务需要消耗大量的节点资源来满足写入。Indexing service 可以极大的降低这部分场景的成本开销。
Indexing service 有以下三个方面的特点 1、完全兼容原生的 API 2、按量付费按写入吞吐和QPS实际需求付费 3、写入能力可秒级快速弹性扩缩
下图展示了Indexing service是如何实现的 1、第一请求转发请求发到用户ES集群用户使用云原生API操作ESES内核会将开启托管的索引写入请求转发到Indexing Service。这里可以展开再缩小对于不再写入的索引用户就可以取消协助托管释放存储成本。Indexing service结合Data stream和over功能可以有非常好的用户体验因为新生成了索引后老索引就不再写入。我们在内核上做了优化在生成新索引的时候就会自动取消托管。
2、第二步在写入 Indexing service 后内部会经过分布式的 QoS 模块进行写入的流量控制来阻止资源的过度消耗。
3、第三步跨集群的物理复制 Indexing Service 构建的索引是通过物理复制到用户集群的。
4、最后是 Indexing Service 内部会持续地运行原数据同步的 task 实时地同步用户集群托管的索引 metadata。
Indexing Service将于2021年2月全新上线实现ES在时序日志场景的降本增效。 Index server 可以解决时序日志数据高并发写入瓶颈优化集群写入计算资源成本降低运维的复杂度。Indexing Service 无论从写入性能成本节约还是弹性伸缩的能力方面都能带来不一样的体验大家可以敬请期待。 原文链接
本文为阿里云原创内容未经允许不得转载。
