本文由阿里云社群直播整理而来。
讲师：
洪阳，阿里云产品专家
和阿里云技术专家，志宸
全链路云上Elasticsearch——阿里云Elasticsearch一站式云托管服务
到今天为止我们在云上已经有Elasticsearch、Kibana、Logstash和Beats, 生态下的全部开源的组件。同时，相较于开源的ELK生态下的组件和功能来说，还提供了其他的自研插件，或者是增强型的，或者是基于内核的优化能力，来保证大家在使用ElasticStack这个生态内的功能时有更好的体验，更强的稳定性和更高的性能，更让大家觉得满意的性价比。
其中包括向量检索日志增强版的内核，阿里达摩院提供的中文分词器，跟Elastic的官方所签约战略合作所得到这个X-pack的商业插件，基于云端的容灾能力，帮助提升es集群运维效率的智能运维功能，可视化的运维窗口，以及Kibana的一些插件，比如说Query builder的插件或者打标的插件。
今天这个话题主要是聊一聊我们日志场景下的这个增强版内核的一些功能和特性。
01.日志场景的“痛心处” ——日志场景中用ELK哪些问题要人命？
日志场景是大家在使用ELK过程中，比较多的一个场景，让我们来看一下它有哪些痛点问题。
天下乌鸦一般黑 ——大家的痛点都是趋同的
这里罗列了大家常会遇到的几个问题：
第一个是高并发的写入，在日志场景中通常会有非常大的写入，而Elasticsearch在写入过程中，需要写入主分片又会同步到备份片，并且在这个过程中还会去写这个trace log之类的，开销比较大，通常它在支持这个高并发写入的时候，对于机器CPU和l/O的开销是比较高的；
第二个是存储成本比较高，日志场景中通常会涉及到海量数据库，通常我们遇到的都是TB级起步，甚至有些会到达PB级。同时在这么大数据量的前提下，除了写入主分片之外，还需要保留一份副本，那么这个时候它的存储成本压力就更加大了。
第三个是这个时序分析性能差的问题，因为es的查询是按所有的segment都会去查，做比较大范围的range时，和比较复杂的聚合时，它的查询范围太大，性能瓶颈就会突显出来。
第四个是时常会遇到可伸缩性的问题，因为日志通常随着业务的变化会有峰值、均值、谷值，它们之间的差异是非常大的。通常我们需要为了支持这个峰值流量，把机器堆的非常多，但是低峰值的时候，就会造成很严重的资源浪费，所以，解决可伸缩性的问题也是日常比较大的课题。
流量“峰值”vs流量“低谷” ——要么资源不够，要么资源浪费 我要如何优化集群配置
下面我们来看一个伸缩性案例。我们有一个用户，早高峰两小时的查询和写入是其他时间段的5倍，造成了大部分的时间资源浪费的情况，并且该用户的数据量非常大，所以在正常的情况下去做弹性扩缩容会存在数据迁移慢的问题，就没有办法去有效的实施，并且包含了副本，存储成本和高并发的写入都会存在问题。
为了解决用户场景上述提到的这些痛点问题，我们做了es内核的增强版，专门针对日常场景进行成本和稳定性的这个优化。
02.日志“大杀器”技术解读 ——增强版Es技术解读
通过计算速度分离来解决用户的这个痛点问题，分离的前提是所有结点的存储都基于NFS的共享存储。
计算存储分离架构 ——核心技术剖析
我们可以看到，数据流的写入请求，会先写到主分片，写入到共享存储，然后nrt segment会拷贝到临时目录，那么主和备去读的就不同了。主读的是commit segment a和nrt segment b，副本读的就是a和b’。计算存储分离的核心思想其实就是下图右边列的这五个点：
第一点是最重要的，索引分片一写多读。数据只会保留一份，存储成本和写入成本会更加低，写入性能就会大大的提高。
第二点是依赖云存储保证数据的可靠性。CPI的底层具备了三副本的冗余机制，对于业务是透明的，所以能够保证数据不丢，并且阿里云针对极端情况下，也会有分钟级的OSS自动备份机制，能提供数据的备份，进一步保证数据的可靠性。
第三点是状态与索引分离。
第四点是通过IO fence机制来保证数据一致性。
第五点是内存物理复制降低主备的可见延迟，主备可见延迟丛分钟级降到毫秒级。
日志场景的“棘手”问题 ——用户痛点分析
基于上述的架构大家可能会产生的一些疑问，副本在不写实时索引的情况下怎么保证数据的时效性呢？其实我们为了解决这个问题，设计了物理复制的状态机，利用lucene框架实现了主副之间的数据同步。主shard在refresh期间会生成全量meta快照。第二点是segment merge完成后，大的merge后的segment不会去做这segment同步，会直接把它fsync到共享存储来避免一个大文件的拷贝。第三个是主备延迟可效性在通过一系列的优化之后达到了毫秒级。
03.能力堪比“大宗师”——日志增强版vs纯开源版本
想必大家刚才听完上述介绍之后，对于阿里云增强日志场景下增强版的elastic search内核有了一定的了解。为了方便进一步的了解，日志场景增强版的内核和纯开源的版本去做一个对比。为了方便大家理解，我们用真实的案例基于售价和一些性能指标来给大家一个相对来说直观点的概念。
同样性能比价格 ——来源于真实的POC数据
下面说的这两个场景案例其实都是来源于真实的POC的相关数据，第一个是我们同样的性能要求，或者说同样的一个性能表现，来横向对比一下价格。这个数据是来源于真实的我们的客户数据，要求是希望Elasticsearch集群的吞吐，写入存储是500M Bps，写入量是450000 docs/s。基于这样要求，分别用纯开源的Elastic search版本和阿里云日场景增强版的Elastic search做了一个配置规划。用纯开源，其实是用25台16c 64GB的高配机器，增强版用12台就够了。同样配置50TB存储介质，配置不同的协调节点，纯开源是五台，增强版是三台，专有节点机器数比较少，所以专有节点的数量和配置也不用那么高。所以相对来说纯开源版本基于阿里云Elastic search，大概价格是15万一个月，阿里云日志场景的增强版es的原价是11万一个月，最近会有一个年末的折扣活动，折扣活动之后大概就是69000多一个月，相对于用原价作比较我们节约的费用其实是非常可观的。
同样需求比ROI ——来源于真实的POC数据
另外一个也是一个客户的真实场景，类似的需求，我们来对比一下ROI。客户这固定预算是受限的不超过5万，他希望能够做数据容灾，数据量大，我们帮他规划了这个基于开源的Elasticsearch集群配置跟阿里云日志场景下的增强版的集群配置。大家可以看到左和右的不同，性能方面经过实测，基于纯开源版本的配置，费用已经到49000，跟增强版的配置相比其费用折扣后只需要28000，性能是要优越于纯开源版本的，并发写入场景下等。性能更优越，成本更便宜。
过人之处有哪些 ——内修心法，外练强力
总结来说，阿里云基于日志场景，对于Elasticsearch做了优化之后，有哪些过人之处呢？主要就是三点：
第一点就是我们存储的成本节约百分之百，大家回顾去想一想，上文提到的，多个replica映射主shard跟主shard映射同一份物理存储介质，所以一旦有replica之后并且replica越多，节约的成本会越高，如果replica是1相当于砍了一半，replica是2成本节约了2/3，所以我们存储的成本是大大降低的，并且支持更大的内存磁盘比。因为对内存的限制，所以其实内存磁盘比是相对来说比较固化，如果你的磁盘比内存高太多，比如说64GB的内存配一个几十TB的磁盘，这个磁盘是用不掉的，在正常的这个开源的es内核里，增强版会有更多的内存磁盘比。
第二点，是写入性能会有大大提升，实际压测使用性能相对于开源提升至少100%，在计算上避免了物理写副本的多次CPU或者是IO的开销来节约了资源，来提升了写入的性能。
第三点，所有的逻辑存储与物理存储不是一一映射的，在做扩缩容的时候，不需要实际意义上去搬迁每一个数据节点里面的数据，可以做到秒级的弹性扩缩容。这个在真实场景下面是对大家很有帮助的，举一个简单的例子，业务上面有一些波峰波谷很明显的业务场景，游戏、直播、类似于餐饮等的固定周期，晚上是高峰，寒暑假是高峰，或者是饭点的时候是高峰，大量的日志写入会给集群非常大的压力，平时日志写入量不大，集群压力没有多少，空闲了很多。正常来说呢，大家可能会满足峰值的压力会预留些机器，在平时时间段其实资源是浪费的，阿里云日志增强版就非常好去解决了这个问题。到了峰值的时候快速把机身弹起来，然后峰值过了把资源释放，回到我均值情况下和集群配置的份额和水位，很大一部分钱都是可以被节约下来的，这个是从成本的角度去考虑，帮助大家节省了非常多的费用上的消耗，开源版Elasticsearch完不成的事情，阿里云日志增强版可以去做。
接下来介绍一下最佳的用武之地，最佳场景，什么时候这个日场景的增强版内核可以被用到呢，或者说大家这个时候就选它，会有比较好的ROI，就是投入产出比。
04.最佳用武之地 ——日志增强版应用场景
首先第一个就是有非常多日志的时候，基于之前的介绍日志量大，并发写入的性能会高，日志量很大，用副本的时候存储会更便宜等，这些都基于一个原则，就是我不愿意为这么大的日志量支付非常高额的存储成本，以及支撑并发写入时资源上的消耗成本，所以海量日志的时候大家可以去选择它，TB级10TB 100TB甚至更多；
第二个是增量日志的并发写入性能要求很高的时候，比如说峰值写入100000dos时，如果大家现在正在用开源的ELK去搭建自己的监控运维或者是日志系统的时候，都会有这样的痛点，一旦并发量上去，集群的负载均衡是很麻烦的，很容易被打爆，很容易集群就飘红了，这个是很危险的；
第三个是对于数据有一定容灾要求的时候，副本数，至少是一点的时候，如果没有这个副本的时候，我只是存了一份数据，那这个时候其实存储成本开销可能还是比普通的ssd还是贵点，但一旦有副本，那就是100%存储费用的降低。
什么时候应该用？ ——阿里云专家推荐
介绍完这个比较宽泛的概念之再用一个真实的案例给大家去介绍。大家都知道阿里云其有很多条业务线，举一个阿里云内部有搜索业务线的真实案例。搜索会有很多集团内的客户，集团外的客户，甚至有搜索之外的产品，或者说认为他是客户，就是业务线，他们会去使用各种各样的底层服务，那我们会对他们做一系列的监控，就是各种各样的底层服务会有各种各样的复杂的Metric，做大量的聚合，做dashboard，保证这些业务不受影响。做monitor，相伴而生的就一定会有告警了，这样的一套监控和报警的平台，内部网监控和告警的平台底层所使用的就是量身定制的日志场景下的增强版的es内核。
下图是其中一个集群的解读，Metric Beats采集大量的数据，通过Gateway向Elasticsearch集群去发送，大概写入量是40w docs/s，一些数据是热数据，一些数据是冷数据，不能把所有的数据全都放到同样的配置，出于成本的角度考虑，做冷热切分的配置，为了数据容灾将数据定时自动快照到OSS里面，这套服务在阿里云内部已经正在使用，对外提供一模一样的能力供大家去选择。大概盘算一下，用开源的Elasticsearch做同样的事情，它的费用是一倍之多，费用至少是节约了50%，不仅是存储更便宜，持续Metric场景为了聚合的效率更高阿里云的内核也做了优化。基于开源的，为了达到性能，要去做更多的data log冗余，保证内存跟CPU的性能是足够的。
最佳实践案例 ——真实客户案例
05.年末大促 ——日志增强版的新用户折扣
最后给大家介绍增强版对于我们新客户是有折扣的，从2020年的1月1日开始到3月31日结束，首月年付六折，三个月有75的折扣，今年的1月上旬推出，Metric Beats等一系列服务，在经过授权的前提下把这些Beats一键装载到您的ecs里面，采集一些esc里面的metric，与Logstash配合使用的话，Logstash2核4G首月是免费试用的，我们一直会有这个1核2G首月免费的试用活动，感兴趣的朋友们可以去体验一下阿里云Elasticsearch，到底有什么过人之处。
