近两年随着Elastic Stack的愈发火热，其近乎成为构建实时日志应用的工业标准。在小型数据应用场景，最新的6.5版本已经可以做到开箱即用，无需过多考虑架构上的设计工作。 然而一旦应用规模扩大到数百TB甚至PB的数据量级，整个系统的架构和后期维护工作则显得非常重要。借着2018 Elastic Advent写文的机会，结合过去几年架构和运维公司日志集群的实践经验，对于大规模日志型数据的管理策略，在此做一个总结性的思考。 文中抛出的观点，有些已经在我们的集群中有所应用并取得比较好的效果，有些则还待实践的检验。抛砖引玉，不尽成熟的地方，还请社区各位专家指正。

对于日志系统，最终用户通常有以下几个基本要求:

1. 数据从产生到可检索的实时性要求高，可接受的延迟通常要求控制在数秒，至多不超过数十秒
2. 新鲜数据(当天至过去几天)的查询和统计频率高，返回速度要快(毫秒级，至多几秒)
3. 历史数据保留得越久越好。

针对这些需求，加上对成本控制的必要性，大家通常想到的第一个架构设计就是冷热数据分离。

冷热数据分离

冷热分离的概念比较好理解，热结点做数据的写入，保存近期热数据，冷数据定期迁移到冷数据结点，就这么简单。不过实际操作起来可能还是碰到一些具体需要考虑的细节问题。

1. 冷热结点集群配置的JVM heap配置要差异化。热结点无需存放太多数据，对于heap的要求通常不是太高，在够用的情况下尽量配置小一点。可以配置在26GB左右甚至更小，而不是大多数人知道的经验值31GB。原因在于这个size的heap，可以启用zero based Compressed Oops，JVM运行效率是最高的， 参考: heap-size。而冷结点存在的目的是尽量放更多的数据，性能不是首要的，因此heap可以配置在31GB。
2. 数据迁移过程有一定资源消耗，为避免对数据写入产生显著影响，通常定时在业务低峰期，日志产出量比较低的时候进行，比如半夜。
3. 索引是否应该启用压缩，如何启用？最初我们对于热结点上的索引是不启用压缩的，为了节省CPU消耗。只在冷结点配置里，增加了索引压缩选项。这样索引迁移到冷结点后，执行force merge操作的时候，ES会自动将结点上配置的索引压缩属性套用到merge过后新生成的segment，这样就实现了热结点不压缩，冷结点merge过后压缩的功能。极大节省了冷结点的磁盘空间。后来随着硬件的升级，我们发现服务器的cpu基本都是过剩的，磁盘IO通常先到瓶颈。 因此尝试在热结点上一开始创建索引的时候，就启用压缩选项。实际对比测试并没有发现显著的索引吞吐量下降，并且因为索引压缩后磁盘文件size的大幅减少，每天夜间的数据迁移工作可以节省大量的时间。至此我们的日志集群索引默认就是压缩的。
4. 冷结点上留做系统缓存的内存一般不多，加上数据量非常巨大。索引默认的mmapfs读取方式，很容易因为系统缓存不够，导致数据在内存和磁盘之间频繁换入换出。严重的情况下，整个结点甚至会因为io持续在100%无法响应。 实践中我们发现对冷结点使用niofs效果会更好。

实现了冷热结点分离以后，集群的资源利用率提升了不少，可管理性也要好很多了. 但是随着接入日志的类型越来越多（我们生产上有差不多400种类型的日志)，各种日志的速率差异又很大，让ES自己管理shard的分布很容易产生写入热点问题。 针对这个问题，可以采用对集群结点进行分组管理的策略来解决。

热结点分组管理

所谓分组管理，就是通过在结点的配置文件中增加自定义的标签属性，将服务器区分到不同的组别中。然后通过设置索引的index.routing.allocation.include属性，控制改索引分布在哪个组别。同时配合设置index.routing.allocation.total_shards_per_node，可以做到某个索引的shard在某个group的结点之间绝对均匀分布。

比如一个分组有10台机器，对一个5 primary ，1 replica的索引，让该索引分布在该分组的同时，设置total_shards_per_node为1，让每个节点上只能有一个分片，这样就避免了写入热点问题。 该方案的缺陷也显而易见，一旦有结点挂掉，不会自动recovery，某个shard将一直处于unassigned状态，集群状态变成yellow。 但我认为，热数据的恢复开销是非常高的，与其立即在其他结点开始复制，之后再重新rebalance，不如就让集群暂时处于yellow状态。 通过监控报警的手段，及时通知运维人员解决结点故障。 待故障解决之后，直接从恢复后的结点开始数据复制，开销要低得多。

在我们的生产环境主要有两种类型的结点分组，分别是10台机器一个分组，和2台机器一个分组。10台机器的分组用于应对速率非常高，shard划分比较多的索引，2台机器的分组用于速率很低，一个shard（加一个复制片）就可以应对的索引。

这种分组策略在我们的生产环境中经过验证，非常好的解决了写入热点问题。那么冷数据怎么管理？ 冷数据不做写入，不存在写入热点问题，查询频率也比较低，业务需求方面对查询响应要求也不那么严苛，所以查询热点问题也不是那么突出。因此为了简化管理，冷结点我们是不做shard分布的精细控制，所有数据迁移到冷数据结点之后，由ES默认的shard分布则略去控制数据的分布。

不过如果想进一步提高冷数据结点服务器资源的利用率，还是可以有进一步挖掘的的空间。我们知道ES默认的shard分布策略，只是保证一个索引的shard尽量分布在不同的结点，同时保证每个节点上shard数量差不多。但是如果采用默认按天创建索引的策略，由于索引速率差异很大，不同索引之间shard的大小差异可能是1-2个数量级的。如果每个shard的size差异不大就好了，那么默认的分布策略，基本上可以保证冷结点之间数据量分布的大致均匀。 能实现类似功能的是ES的rollover特性。

索引的Rollover

Rollover api可以让索引根据预先定义的时间跨度，或者索引大小来自动切分出新索引，从而将索引的大小控制在计划的范围内。合理的应用rollver api可以保证集群shard大小差别不会太大。 只是集群索引类别比较多的时候，rollover全部手动管理负担比较大，需要借助额外的管理工具和监控工具。我们出于管理简便的考虑，暂时没有应用到这个特性。

索引的Rollup

我们发现生产有些用户写入的“日志”，实际上是多维的metrcis数据，使用的时候不是为了查询日志的详情，仅仅是为了做各种维度组合的过滤和聚合。对于这种类型的数据，保留历史数据过多一来浪费存储空间，二来每次聚合都要在裸数据上跑，非常浪费资源。 ES从6.3开始，在x-pack里推出了rollup api，通过定期对裸数据做预先聚合，大大缩减了保存在磁盘上的数据量。对于不需要查询裸日志的应用场景，合理应用该特性，可以将历史数据的磁盘消耗降低几个数量级，同时rollup search也可以大大提升聚合速度。不过rollup也有其局限性，即他的实现是通过定期任务，对间隔期数据跑聚合完成的，有一定的计算开销。 如果数据写入速率非常高，集群压力很大，rollup可能无法跟上写入速率，而不具有实用性。 所以实际环境中，还是需要根据应用场景和资源使用情况，进行灵活的取舍。

多集群的便利性

数据量大到一定程度以后，单集群由于master node单点的限制，会遇到各种集群状态数据更新时得性能问题。 由此现在一些大规模的应用已经开始利用到多集群互联和cross cluster search的特性。 这种结构除了解决单集群数据容量限制问题以外，我们还发现在做容量均衡方面还有比较好的便利性。应用日志写入量通常随着业务变化也会剧烈变化，好不容易规划好的容量，不久就被业务的增长给打破，数倍或者数10倍的流量增长很可能就让一组结点过载出现写入延迟。 如果只有一个集群，在结点之间重新平衡shard比较费力，涉及到数据的迁移，可能非常缓慢，还会影响写入。 但如果有多集群互联，切换就可以做到非常的快速和简单。 原理上只需要在新集群中加入对应的索引配置模版，然后更新写入程序的配置，写入目标指向新集群，重启写入程序即可。并且，可以进一步将整个流程工具化，在GUI上完成一键切换。