引言

在大数据的生态系统里，时间序列数据(Time Series Data，简称TSD)是很常见也是所占比例最大的一类数据，几乎出现在科学和工程的各个领域，一些常见的时间序列数据有：描述服务器运行状况的Metrics数据、各种IoT系统的终端数据、脑电图、汇率、股价、气象和天文数据等等，时序数据在数据特征和处理方式上有很大的共性，因此也催生了一些面向面向时序数据的特定工具，比如时序数据库和时序数据可视化工具等等，在云平台上也开始出现面向时序数据的SaaS/PaaS服务，例如微软最近刚刚发布的Azure Time Series Insight。本文会介绍一个时间序列数据处理平台案例，探讨这类大数据平台在架构、选型和设计上的一些实践经验以供参考。

业务场景

本文介绍的案例是一个面向大型企业IT系统运维的监控平台，数据来源于多种监控终端产生的时序数据，涉及的数据源涵盖了SCOM、AppDynamics、Website Pulse、Piwik以及AWS Cloud Watch等多种主流的第三方监控工具，基于组织内部的IT规范，所有应用系统都安装了上述一种或多种监控工具，这为建立一个统一的多维度的监控平台提供了保证，该平台基于多种监控数据，对同一应用/服务系统进行综合的健康评估，在发生故障时会根据不同的数据源进行交叉验证，从而帮助运维人员快速和准确地定位故障原因。

架构设计

完整的大数据系统往往包涵数据采集，消息对列，实时流处理，离线批处理，数据存储和数据展示等多个组件，为了满足业务上对实时监控和历史数据汇总分析的需求，系统遵循了Lambda架构，将实时流处理与离线批处理进行了分离。此外，鉴于平台处理的所有数据均为时序数据，在架构上针对这个特点着重进行了调整和优化，其中重要的一环是引入“时间序列数据库”作为核心的数据存储与查询引擎。

系统完整的数据流如下：首先，数据被数据采集组件从外部系统采集并来放入消息队列，接着，流处理组件从队列中取出数据进行流式计算，消息队列从中的起到的作用是平衡“生产者”——数据采集组件和“消费者”——流处理组件在消息处理上的速率差，提升系统的稳定性和可靠性。数据在流处理组件中会经历清洗、过滤、转换、业务处理等诸多环节，之后按TSD引擎规定的标准TSD格式推送到TSD引擎，由TSD引擎最终写入后端数据库。

实时流处理部分要求数据从采集到最后的展示控制在秒级延迟，严格来说，这是一套近实时系统，但其实时性已经足够满足业务上的需求，为了保证处理速率，实时链条上的数据大多数时间是驻留在内存中的，好在实时部分只关注近两周的数据，所以总的内存消耗处在可控的范围之内。

在批处理数据线上，利用数据库的同步机制将实时部分落地的数据持续同步到批处理的数据库上，这个库存储着数据全集，所有批处理相关的查询都在这个库上执行，与实时部分的组件完全隔离。批处理会保存过去三年的数据，分析尺度多为日，周，月甚至年。不同于一般离线分析系统选型Hive一类的数据仓库，我们希望在离线分析时继续充分利用时序数据库带来的种种好处，比如经过特殊优化的时序数据查询，开箱即用的查询接口等等，所以在离线部分我们依然配备TSD引擎，批处理组件在实现业务需求时可以深度利用TSD引擎对时序数据进行聚合运算，在聚合之后的结果上再进行更加复杂的分析并写回数据库，同时也可以在普通查询无法实现需求时越过TSD引擎直接对底层数据文件进行MR计算。

最后，数据展示组件会从TSD引擎中提取数据，以各种形式的图表展示给用户。在实际的开发中我们发现TSD引擎对数据格式有诸多的限制，有的TSD需要进行某些转换和适配才能展示，因此我们在TSD引擎和数据展示组件中间引入了一个轻量的驱动程序来透明地解决这些问题。