监视数据来源主要包括：业务数据处理流程各环节产生的业务日志，业务系统应用程序产生的业务运行日志，服务器、存储、网络、安全设备等基础资源的运行性能指标、状态数据、事件数据。除此之外，基于以上原始监视数据，通过处理和分析计算生成的告警信息、统计指标等。以中国气象部门国家数据中心为例，其不同来源的监视数据及数据规模如表 1所示。

目前国内外较为主流的存储模型会用到典型的NoSQL数据库，如BigTable、Dynamo、Cassandra、MongoDB、HBase等。其缺点是：现有的一些模型较难在捕捉到等待时间和一致性之间作平衡。而本文存储架构设计在可用性和一致性之间进行权衡，综合应用了Elasticsearch、Cassandra、MongoDB等数据库集群实现对各类监视数据的存储（见图 1）。重点关注了分片、存储管理、查询处理和告警数据处理。本文云存储服务模型的主要特点有：

图  1  存储框架

Figure 1.  Storage Framework

1）在存储模型的接入端，通过主备的负载均衡组件来对写入和查询服务请求进行均衡分配，以使各个存储服务节点能分摊高并发时的吞吐量；

2）为消减日志写入高峰的压力，设计了Kafka消息队列，对日志数据进行缓存；

3）配置数据因其动态变化多，需要存储附加文档，因此，采用无模式的文档型数据库技术MongoDB来存储；

4）由于告警数据变化莫测，在进行故障分析时需要与配置数据进行关联，采用MongoDB来存储。

索引存储技术用于实现监视数据中日志数据的高效存储和查询。索引存储技术起源于搜索引擎的存储技术。它通过索引来组织数据内容，将数据存储在一个或多个索引中，一个索引就像一个数据库，每个索引通过分片散布到分布式存储的多个节点。

本文存储模型采用的Elasticsearch就是一种基于索引的NoSQL数据库，它具备TB级数据的存储服务能力，通过在集群节点中进行自我分发，实现容错和水平扩展。

1）Elasticsearch存储原理

Elasticsearch中文档是一个基本的数据存储单元，一个文档类似关系数据中一行记录，同一类文档可以有不同的字段组合，可以支持更为灵活的数据存储结构。文档的元数据主要有索引（index）、类型（type）和文档ID，每个文档都属于一个索引，并通过索引来进行索引存储和查询定位。为便于管理和提升性能效率，一个索引内根据文档类型，设置不同的逻辑分区，其中具有一组共同字段的文档可定义同一个类型；同时一个索引会切分成不同分片，分布到不同的集群节点，实现分布式存储，每一个分片是一个实例，每一个分片有主分片和零个或多个副本分片，用于对分片进行冗余存储，以增加高可用性和提高性能。图 2给出了Elasticsearch中索引存储的分片及副本的组织情况。

图  2  Elasticsearch索引存储逻辑示意

Figure 2.  Index Storage Logic Schema for Elasticsearch

2）Elasticsearch索引存储流程

当向Elasticsearch集群提交文档，处理节点会根据路由规则确定需要写入的分片，并把文档发给分片所在的节点，由所在节点完成入库后返回。对于分片同步，系统提供了同步和异步两种策略。异步有更好的写入性能，而同步则更注重一致性。Elasticsearch索引一个文档的过程如图 3所示。

图  3  Elasticsearch文档索引流程

Figure 3.  Document Indexing Process for Elasticsearch

3）Elasticsearch查询流程

Elasticsearch集群完成一次查询分成几个步骤，服务节点接受请求，根据请求的索引元数据信息选择可用的数据节点，完成路由选择；数据节点从对应的分片中完成数据，并返回匹配的文档ID和评分；服务节点根据各个数据节点的返回，合并结果并排序，向数据节点提取完整的文档数据，组成完整的结果返回客户端。如图 4所示。

图  4  Elasticsearch文档查询流程

Figure 4.  Document Query Process for Elasticsearch

Elasticsearch中的大部分操作都是基于索引来完成，索引及相关的分片、副本的设计是关键存储设计，需要根据数据特点和数据量来进行设计^[4]。

在日志数据中，业务处理日志类数据与系统日志文件类数据之间相关程度不高，因此将这两类日志数据分开存储；同时日志数据具有较高的时效性，近期的日志是查询和分析的热点数据。因此，在设计索引时，将业务日志和系统日志分成两大类索引，并按日期分开建立索引。由于业务日志有一定的规范性要求和分类，每个业务日志索引内还可以进一步按照业务来分类型。

根据以上的日志数据索引设计，日志数据的索引规划实现如表 2所示，其中索引名由租户、业务分类标识、日期分区共同组成。

分片路由能限定查询在指定分片上执行，是Elasticsearch应对高吞吐量的措施之一，路由设计能够把广播查询优化为确定的分片查询，能够很好地优化查询效率。

日志数据的分片路由设计可依据数据查询的主要场景。以气象资料处理为例，每种气象资料每个时次都会生成多个环节处理日志，资料类型和时次是其中关键的检索条件，因此分片路由围绕这两个字段设计。

实现上可将访问索引时的routing_key设置为资料类型和资料时次组合，这样相同资料、相同时次的数据保存在一个分片上，对routing_key进行哈希运算，并将哈希值对分片数取模，得到的结果就是制定的分片序号；在查询时也可以进行相同的运算来精确定位分片，提高查询速度。

指标类数据存储主要考虑快速读写性能。Cassandra是开源的分布式NoSQL数据库系统，与面向行的传统关系型数据库或键值存储的key-value数据库不同，Cassandra使用的是宽列存储模型，可以有最多20亿个列，每个列由一个column key标识，每个column key下对应若干value，具备100 kB级别的写入性能。本文提出的海量监视数据存储模型采用Cassandra作为监视数据中指标类数据的底层存储技术。

在指标数据存储设计上，一个指标由指标名、标签（一组多维信息）、时间戳、值等组成。随着不同时间点的数据的收集，形成一个时间相关的序列和一个指标的序列。

指标存储主要有两个表：指标索引表和指标数据表。充分利用宽列数据库的特点，一个rowkey可以保存21亿列数据，按照监控数据的毫秒精度保存，一个rowkey可以保存3周的指标数据。

1）指标索引表，rowkey为指标名，列名为该指标数据表的rowkey，值字段为空。

2）指标数据表，rowkey为指标名和一个为期3周的起始时间点，列名为指标数据对应的时间戳，值字段为指标值。

在以上模型中，指标表的rowkey是一个关键，一个指标表rowkey由指标名、起始时间片、标签组和指标数据值类型等4部分组成。

指标数据存在大量的时间戳，保存一个完整的时间戳需要4个字节，为了节约空间，在时间戳的存储上进行优化，采用了基准时间片加上偏移量的方式优化存储，每一个时间戳从4个字节下降为2个字节。

根据指标时间戳（T）计算时间片（t）和偏移量（d）值的公式如下：

其中，1 814 400 000为3周的毫秒数。读取时还原指标时间戳，即

指标值压缩：指标值都是数值类型、浮点型和整型，对于浮点数，通过数据类型精度转换成对应的整型存储，整型数据采用分段存储规则，在数值为0×0的时候，无需存储空间，值小于0× 100时，用一个字节，值小于0×10 000时，用2个字节保存。

压缩存储对比：对于0值数据完全不存储，对于整数、大量的小整数，压缩比达到50%以上，节约了一半以上的存储空间。

宽列数据写入和查询实现如下：

1）写入。根据指标rowkey设计规则，系统需要根据指标、标签、时间戳计算对应的分区主键rowkey，并且判断该rowkey是否已存在，若不存在，则在指标索引表中新增，若存在，则根据指标偏移时间式（2）计算的时间偏移量，把数据写入rowkey。

2）查询。根据查询条件（指标名、时间段）从指标索引表中查询一组指标数据的rowkey，并根据查询条件中标签组筛选有效rowkey；根据rowkey从指标数据表中连续加载对应的指标数据，并根据汇聚的要求，计算数据返回。

存储模型需要提供监视数据访问服务，并进行存储服务接口封装。为了让外部系统比较便捷地提交监视数据，并及时得到数据处理的反馈信息，系统间需要实现松耦合，采用RESTful协议提供数据交互。在安全方面，采用Accesskey机制实现访问控制。

1）接口数据格式

数据格式采用JavaScript对象简谱（javascript object notation，JSON）格式，规范采集的业务日志数据格式包括表 3中各项字段内容，指标数据格式包括表 4中各项字段内容。

2）监视数据采集接口

业务日志数据和指标数据的采集接口类似，如表 5所示，区别在于两者的表述性状态转移（representational state transfer，Rest）接口路径不同，其中，日志采集接口支持批量数据采集，当提交批量数据时，body参数赋值为多个JSON格式的日志数组即可。

监视数据中蕴含业务运行信息，不仅可以用来展示业务运行状况，有些关键指标还可以驱动业务流程环节，有必要对监视数据和基于数据生成的监视信息提供查询服务。

标准的监视数据查询接口的封装如表 6所示，指标数据查询接口与此类似。

根据气象业务监视数据的数据量统计，目前数据日增量约245 GB，包括215 GB日志数据、30 GB指标数据等。根据业务需求，日志和指标数据在线存储6个月，汇聚后的指标数据在线存储5年，保留2份存储副本。考虑未来业务增长，预留50%的存储容量。存储量计算如下：

膨胀系数设为1.3，原始日志存储量为：

215 GB/日×180日×3×1.3/50%/1 024= 296 TB

压缩比为50%，则原始指标存储量为：

28 GB/日×180日×3×50%/50%/1 024= 14.8 TB

汇聚后指标存储量为：

2 GB/日×365日×5年×3副本/50%/1 024 = 21.4 TB

存储环境采用Elasticsearch和Cassandra集群部署，配置见表 7。在存储环境部署后，重点对海量日志和指标数据存储模型的应用效果、存储服务性能、水平扩展、容错性等多方面进行了测试评估，均达到预期效果，满足监控业务需求。

日志数据存储采用Elasticsearch集群，共12个节点，在不同数据量写入时，数据存储耗时见图 5，同时也测试了相同配置下，Oracle集群的日降低。志数据存储耗时。

图  5  日志数据库存储性能

Figure 5.  Storage Performance of Log Database

从图 5可以看出，Elasticsearch集群即使在实时存储亿级数据量的情况下，都可以达到快速持久的数据存储效率，随着数据量的增加，每秒仍稳定提供约8万条数据的存储能力，远高于关系型数据库的存储性能，Oracle的写入速率为每秒3万条左右。

指标数据存储采用Cassandra集群，共3个节点，在不同数据量写入时，数据存储耗时如图 6所示。可以看出，Cassandra集群对比传统关系型数据库Oracle，具有更快的写入速率，达到每秒约7万条数据的存储能力，Oracle的写入速率为每秒4万条左右。

图  6  指标数据库存储性能

Figure 6.  Storage Performance of Index Database

在不同并发访问请求下，Elasticsearch集群的查询时效见图 7。可以看出，Elasticsearch集群在低于50次并发访问时，查询耗时低于1 s，300次并发时，查询耗时为4.2 s，满足日志数据查询业务需求，超过300次并发时，访问性能急剧降低。

图  7  日志数据库服务性能

Figure 7.  Service Performance of Log Database

在不同并发访问请求下，Cassandra集群的查询时效见图 8。可以看出，Cassandra集群在低于50次并发访问时，查询耗时约2 s，满足指标数据查询业务需求，超过150次并发时，访问性能急剧降低。

图  8  指标数据库服务性能

Figure 8.  Service Performance of Indicator Database

针对Elasticsearch集群和Cassandra集群在高并发访问时，数据库访问性能急剧降低的问题，本文通过集群节点的水平扩展，增加存储服务节点数量开展扩展前后的性能分析。测试结果表明，增加节点后，数据库的读写性能都有较大增速。未来可根据业务增长及服务需求，动态在线扩展集群的存储节点。

存储架构设计考虑了可扩展性，存储模型采用互联网微服务（MicroService）架构设计，可以提供方便快捷的组件扩展能力。在数据分片基础上，将原有12个节点Elasticsearch集群、3个节点Cassandra集群，各增加2个存储服务节点。水平扩展前后，数据库集群的存储服务性能变化见表 8~11。

分布式存储系统设计的一个重要指标就是系统的容错性，当数据库集群的某个节点发生故障时，仍然可以提供有效的数据读写服务，不会严重影响整体性能。

在存储模型的设计中，所有数据分片保留2份副本，为测试存储架构的容错性，将原有12个节点Elasticsearch集群、3个节点Cassandra集群，各关闭1个节点，在测试的24 h内数据库操作有效率无明显衰减。

为解决对海量监视数据高效管理的问题，本文分析了海量监视数据的组成及不同监视数据的特点，提出了监视数据云存储服务模型。综合应用Elasticsearch、Cassandra、MongoDB等数据库集群实现对监视数据的存储，并通过真实环境测试，说明所提模型比传统关系型数据库具有更好的读写性能，同时也测试了该模型的水平可扩展性和稳定性。目前，监视信息存储服务模型已应用到全国气象综合业务实时监控系统建设中，实现了有效数据支撑。

未来，本文还将对存储服务模型进行完善和优化，实现对海量历史监视数据的在线存储，建立面向不同分析挖掘服务需求的存储服务模型，构建监控运维大数据平台。