前文《面对海量事件数据，我来告诉你怎么办！》中我们介绍了百度线上业务运维场景下海量事件数据存储与计算平台 EventDB 的系统架构、集群规划及未来发展方向，本文将介绍我们在 EventDB 高可用方向面临的问题、建设经验及后续计划，希望与业界同行一起交流学习。
问题
作为百度智能运维大数据核心存储平台，其可用性高低直接决定了上游业务系统可用性高低，我们建设可用性之初主要面临如下几个问题：
可用性建设
为了提升平台可用性，针对上述问题我们做了如下几方面工作：
1 完善监控体系
我们建立了多层次监控指标，从机器、容器(Container)、JVM、ElasticSearch 内部指标再到业务监控指标，这些监控指标对及时了解系统运行状况、分析定位问题至关重要。
其中 ElasticSearch 内部指标是通过 API 实时提供，为了图形化展示这些指标并记录历史数据我们使用 Marvel 插件，Marvel 插件通过定期调用 ElasticSearch 监控 API 提供更细粒度监控指标，能让我们看到基于每个索引（Index）的监控数据，这个功能在我们定位 IO 突增问题时发挥了重要作用。
2 统一调用接口
ElasticSearch 自身提供了非常丰富的 API，从数据操作到参数配置再到集群管理。如果把所有 ES API 都开放给终端用户会给平台带来非常大风险，一是我们无法预料用户行为，二是每个用户对 ElasticSearch 掌握程度不同，很容易造成误用。为了加强流量管理能力我们做了两方面工作：
3 优化存储模型
ElasticSearch 数据存储模型由索引(Index)、类型(Type)、文档(Document)组成，分别对应关系型数据库中库(Database)、表(Table)、行(Row)。设计合理的存储模型不光能满足业务需求，还能极大提升系统扩展性和读写性能。
分库设计
数据规模小的情况下我们为了简便可以将数据都存放在一个库中，当数据规模越来越大，这种存储方式会带来两方面问题：
所以平台设计之初就需要我们合理规划索引，一般的做法是按业务和时间两个维度来进行分库，不同的业务使用不同的索引，然后依据数据规模按天/月/年来创建索引。
合理设置分片
单个索引该设置几个分片？每个分片大小多少合适？这两个问题是我们在规划设计索引时必须要考虑的问题。
合理的做法是先评估索引数据规模，按照单个分片不小于 1G 的原则来设置分片数，这样能避免产生大量小分片；另一个原则是要让分片在集群中尽量均匀分布，实践经验就是分片数最好是数据节点数的 1.5~3 倍，这样能避免单个分片过大。
过期数据处理
数据价值会随着时间越来越低，任何一个存储系统都不可能永久无限制地保存所有历史数据，因为无论从成本投入、维护难度上都是得不偿失。所以针对不同业务场景我们需要制定清晰的历史数据清理策略，对于过期低价值数据进行定期清理，这对保持集群稳定，提高资源利用率至关重要。
4 优化配置参数
下面这些参数都是我们认为比较重要的参数，在这里只说明其对系统的影响不作具体值建议，大家可以根据各自业务场景自行进行调整。
JVM 参数
Elasticsearch 参数
ElasticSearch 作为高可用集群，单个节点挂掉并不会影响整个集群功能。当故障节点恢复时，为了避免恢复工作对集群造成太多影响（主要是避免过多的 I/O 消耗），可以设置如下两个参数：
成果及计划
经过不懈努力，事件数据存储平台已扩展到百量级的数据节点，日处理事件大小数百 GB，可用性达 99.999%。用户涵盖业务报警、异常分析、根因定位、关联分析、日志追踪，已经成为百度智能运维大数据核心存储平台。
为应对数据规模、流量持续增长的压力，持续保持系统高可用性，我们计划做如下两方面的建设：
作者介绍：
运小军，百度云资深研发工程师，负责百度智能运维方向大规模日志处理、海量事件数据存储相关设计研发工作，在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。
原文链接：
