海量事件数据存储与计算——高可用建设

前文《面对海量事件数据，我来告诉你怎么办！》中我们介绍了百度线上业务运维场景下海量事件数据存储与计算平台 EventDB 的系统架构、集群规划及未来发展方向，本文将介绍我们在 EventDB 高可用方向面临的问题、建设经验及后续计划，希望与业界同行一起交流学习。

问题

作为百度智能运维大数据核心存储平台，其可用性高低直接决定了上游业务系统可用性高低，我们建设可用性之初主要面临如下几个问题：

• 关键监控指标缺失：导致无法准确掌握系统状况，排查问题困难；

• 流量缺乏管控：一是终端用户直接使用 ES API 很容易造成接口误用；二是无法防御恶意请求和非预期流量洪峰；

• 数据规模持续增长：导致原有存储模型无法满足系统性能和扩展性需要；

• 参数配置不合理：默认配置参数没有按业务场景进行优化调整。

可用性建设

为了提升平台可用性，针对上述问题我们做了如下几方面工作：

1 完善监控体系

我们建立了多层次监控指标，从机器、容器(Container)、JVM、ElasticSearch 内部指标再到业务监控指标，这些监控指标对及时了解系统运行状况、分析定位问题至关重要。

• 机器、容器：CPU/MEMORY/DISK/NET/FD/PROCESS

• JVM：Eden/Survivor/Old/Full GC/Young GC/Thread

• ElasticSearch：Queue/Cache/Search Context/Marvel

• 业务监控：PV/PVLOST/Response Time/主备数据一致性

其中 ElasticSearch 内部指标是通过 API 实时提供，为了图形化展示这些指标并记录历史数据我们使用 Marvel 插件，Marvel 插件通过定期调用 ElasticSearch 监控 API 提供更细粒度监控指标，能让我们看到基于每个索引（Index）的监控数据，这个功能在我们定位 IO 突增问题时发挥了重要作用。

2 统一调用接口

ElasticSearch 自身提供了非常丰富的 API，从数据操作到参数配置再到集群管理。如果把所有 ES API 都开放给终端用户会给平台带来非常大风险，一是我们无法预料用户行为，二是每个用户对 ElasticSearch 掌握程度不同，很容易造成误用。为了加强流量管理能力我们做了两方面工作：

• 一是由平台提供统一数据操作 API，使用 BigQuery API 将所有存储、查询需求通过 SQL 来表达，用户通过 SQL 来操作数据，如果 SQL 有问题或恶意请求会被直接阻止掉；

• 二是对所有接口进行配额限流管理，超出单位时间配额的请求会被拒绝访问。

3 优化存储模型

ElasticSearch 数据存储模型由索引(Index)、类型(Type)、文档(Document)组成，分别对应关系型数据库中库(Database)、表(Table)、行(Row)。设计合理的存储模型不光能满足业务需求，还能极大提升系统扩展性和读写性能。

分库设计

数据规模小的情况下我们为了简便可以将数据都存放在一个库中，当数据规模越来越大，这种存储方式会带来两方面问题：

• 一是数据难以管理维护，例如我们想把某类业务数据清理掉，无法通过直接删除索引的方式来清理数据；

• 二是影响性能，任何读写请求都会影响索引中其他数据读写。

所以平台设计之初就需要我们合理规划索引，一般的做法是按业务和时间两个维度来进行分库，不同的业务使用不同的索引，然后依据数据规模按天/月/年来创建索引。

合理设置分片

单个索引该设置几个分片？每个分片大小多少合适？这两个问题是我们在规划设计索引时必须要考虑的问题。

• 索引分片过小一方面导致 ElasticSearch 在内存中维护大量索引分片元信息，集群管理负荷增加进而引发集群不稳定；另一方面 ElasticSearch 在查询时会扫描所有索引分片，分片过多会影响查询性能；

• 索引分片过大将导致数据过于集中，读写操作在同一分片上的概率增加进而影响操作性能。

合理的做法是先评估索引数据规模，按照单个分片不小于 1G 的原则来设置分片数，这样能避免产生大量小分片；另一个原则是要让分片在集群中尽量均匀分布，实践经验就是分片数最好是数据节点数的 1.5~3 倍，这样能避免单个分片过大。

过期数据处理

数据价值会随着时间越来越低，任何一个存储系统都不可能永久无限制地保存所有历史数据，因为无论从成本投入、维护难度上都是得不偿失。所以针对不同业务场景我们需要制定清晰的历史数据清理策略，对于过期低价值数据进行定期清理，这对保持集群稳定，提高资源利用率至关重要。

4 优化配置参数

下面这些参数都是我们认为比较重要的参数，在这里只说明其对系统的影响不作具体值建议，大家可以根据各自业务场景自行进行调整。

JVM 参数

• -Xms -Xmx：设置 Heap 大小，建议不超过 32G（JVM 使用压缩指针用 32 位地址寻址 32G 空间）；

• -XX:+ExitOnOutOfMemoryError：发生内存溢出时保证 JVM 进程及时退出，避免节点假死（JVM 进程还在但无法正常提供服务） ；

• backlog：已建立 TCP 连接处理队列长度，该队列满时会丢弃 TCP 连接并抛出 Connection Reset 异常。JVM 默认 50，建议适当增大应对流量洪峰。

Elasticsearch 参数

• index.number_of_shards：索引分片数，需要依据数据规模来设置，在索引创建时设置，后期无法更改；

• index.number_of_replicas：索引分片副本数，需要依据数据重要程度来设置，既能在索引创建时设置，也能后期通过 API 更改；

• index.refresh_interval：内存中数据写入到磁盘间隔，该参数越小数据可查询延迟越小，可靠性越高但性能低；该参数越大数据可查询延迟越大，可靠性越低但性能高；默认 1s，建议增大。

ElasticSearch 作为高可用集群，单个节点挂掉并不会影响整个集群功能。当故障节点恢复时，为了避免恢复工作对集群造成太多影响（主要是避免过多的 I/O 消耗），可以设置如下两个参数：

• cluster_concurrent_rebalance：集群中允许多少个分片同时迁移重分配；

• node_concurrent_recoveries：一个 node 上允许多少个分片同时恢复。

成果及计划

经过不懈努力，事件数据存储平台已扩展到百量级的数据节点，日处理事件大小数百 GB，可用性达 99.999%。用户涵盖业务报警、异常分析、根因定位、关联分析、日志追踪，已经成为百度智能运维大数据核心存储平台。

为应对数据规模、流量持续增长的压力，持续保持系统高可用性，我们计划做如下两方面的建设：

• 冷热数据分离：建设冷热数据分离存储架构，一方面可以有效避免冷热数据互相影响，有效提升热数据读写性能；另一方面可以针对冷热数据进行存储介质优化，例如：使用 SSD 硬盘来保存热数据，使用 SATA 硬盘保存冷数据，既能提升读写效率又能降低存储成本；

• ES 版本升级：新版本 ES 在稳定性、易用性、安全性及可维护性上都有很大提升，定期升级版本能避免很多不必要的维护工作。

作者介绍：

运小军，百度云资深研发工程师，负责百度智能运维方向大规模日志处理、海量事件数据存储相关设计研发工作，在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。

本文转载自公众号 AIOps 智能运维（ID：AI_Ops）。

原文链接：

https://mp.weixin.qq.com/s/Btb9YFpL9aqQ6xQaAj1O1Q