亚马逊AWS官方博客
为云端海量日志分析优化的分级存储 – Amazon Elasticsearch Service 中的 UltraWarm
我们正处于大数据和机器学习的时代。非结构化数据在数据中的占比越来越高，而在这些非结构化数据中，占据主导位置的是机器生成的日志数据。随着使用微服务，容器和机器学习构建越来越多的应用程序，机器生成的日志数据量已经呈现出指数增长的态势，因此对于日志的管理、分析、挖掘也提出了更高的挑战。为了快速解决运营和安全问题，对这些数据进行实时分析已变得至关重要。几年前，我们发布了Amazon Elasticsearch Service。它是一个完全托管的日志分析服务，使部署、管理和扩展Elasticsearch和Kibana变得更加容易。
 |
 |
但在实践中，随着日志数据的爆炸性增长，对于数月乃至数年的日志进行大规模存储和分析，其成本变得十分高昂。这可能会导致客户删除有价值的数据，而错过了长期数据可能产生的重要洞察和见解。
为解决此类难题，我们在Elasticsearch Service中设计了新的架构。在新架构设计过程中，我们受到三个关键客户需求的驱动。首先，我们希望构建的不是简单的功能增加，而是显著的成本降低。具体来说，我们希望与现有的存储成本相比，以$ / GB的计价能够降低10倍。其次，我们希望以某种方式，帮助我们的客户保留更长时间的日志，并能够对PB级的数据进行大规模的日志分析。第三，我们希望能够继续在Kibana中提供交互式和集成式的体验。
基于此，我们进行了简化创新，构建了为云平台优化的UltraWarm暖存储。我们在Elasticsearch的高层架构上进行了两次解耦。首先，我们将热存储和暖存储解耦。这样客户就可以使用热存储为最近建立索引的数据或经常修改的数据建立索引和查询，而把大量的静止和不经常访问的数据转移到暖存储以获得成本降低。同时允许这些数据在Kibana仪表板中和现在一样使用API来无缝查询热索引和暖索引。其次，我们将暖计算与暖存储解耦，以便我们将S3用作存储暖数据的持久存储，以显著降低成本。同时我们使用基于 AWS Nitro System构建的UltraWarm暖节点充当无状态计算和缓存层，为缓存、预取和查询暖数据提供交互式体验。
在新的架构里，我们使用S3存储UltraWarm暖数据，是考虑到S3提供的规模经济性和低成本存储，这使我们能够显著降低成本。同时，我们也得到S3免费提供的11个9的持久性，使得我们不需要保留副本，也就是说，使用UltraWarm无需为文件系统和故障转移开销进行超额的存储配置。UltraWarm 支持存储最多 3 PB 数据，并且能够充分使用这些存储容量。更重要的是，您只需为在UltraWarm中使用的存储容量付费。 在开始UltraWarm暖存储之前，我们不会对存储收费。
我们的另一个重要要求，就是对S3中具有成本效益的存储进行查询，并提供交互式的体验。为此，我们必须在UltraWarm节点上也进行同步的创新。经过Nitro优化的UltraWarm节点提供了连接到S3更高的网络带宽。这意味着，对于大吞吐量查询能够以比本地存储更高的速度从S3提取数据。但是，S3的平均延迟高于本地存储。为了解决这个问题，我们在查询的执行和存储都进行了深度创新，以提供交互体验。首先，我们在UltraWarm节点的内存和存储中缓存重要数据和元数据，以避免访问S3。其次，当我们必须从S3获取数据时，我们使用缓存的元数据来避免从S3下载不必要的数据。在查询执行层，我们尽可能多的预取数据，并以较小的粒度从S3有效的获取数据，以避免读取放大。在存储层，我们使查询可以透明地针对本地或远程S3数据运行，以便客户可以使用Kibana仪表板而无需进行任何更改。
UltraWarm支持所有Elasticsearch的API，工具和功能，包括具有细粒度访问控制的企业级安全性，静态和动态加密，集成警报，SQL查询等等。这使开发人员，DevOps工程师，和InfoSec专家使用Amazon Elasticsearch Service来分析近期（几周）和长期（几个月或几年）的运营数据，而无需花费几天的时间将档案（Amazon S3或Amazon Glacier）中的数据恢复到处于活动状态的可搜索状态Elasticsearch集群。在成本方面，与Amazon Elasticsearch Service热节点相比，UltraWarm的每GB价格可节省近90％。和基于EC2 D2实例自建暖存储层相比，UltraWarm也更便宜。
启用UltraWarm也很简单。AWS控制台是创建使用暖存储域的最简单方法。创建域时，选择“ 启用UltraWarm数据节点”和所需的暖节点数即可。当然也可以使用AWS CLI或 REST API。
这里需要注意的是，在Elasticsearch 服务中使用UltraWarm最少需要配置2个暖节点。这样在出现节点故障时，其他 UltraWarm 节点将会按需自动访问数据。目前我们提供两种暖节点的实例类型。
| 实例类型 | vCPU | 内存(GiB) | 最大存储空间 |
| ultrawarm1.medium.elasticsearch | 2 | 15.25 | 1.5 TiB |
| ultrawarm1.large.elasticsearch | 16 | 122 | 20 TiB |
在启用UltraWarm之后，您可以将索引从热存储迁移到暖存储：
暖存储中的索引是只读的。您可以查询索引，但不能向其中添加数据。如果需要再次写入索引，可以将其再迁移回热存储：
UltraWarm 添加了两个附加选项（类似于 _all）以帮助管理热索引和暖索引。可以提出如下请求获得所有暖索引或热索引的列表。
使用 UltraWarm需要支付两部分费用。一是UltraWarm存储的使用量。一个 ultrawarm1.large.elasticsearch 实例可以在 S3 上处理多达 20 TiB 的存储空间，但如果您仅存储 1 TiB 的数据，则只需为 1 TiB 的数据付费。二是每个 UltraWarm 节点的小时按需费率。
看到这里，您是否已经开始对海量的日志分析跃跃欲试了，赶快使用UltraWarm行动起来吧！
参考资料
https://docs.thinkwithwp.com/elasticsearch-service/latest/developerguide/ultrawarm.html