?

Hummer TimeSeries DB （蜂鸟时序数据库）技术介绍

1. 背景介绍

不知不觉中，我们已经跨入“大数据”时代，而大数据的主要来源是来自于各种“传感器”所产生的时序数据记录。这些时序数据不但数量越积越多、而且频率也越来越快，但传统数据库对于这种数目庞大、更新频繁的时序数据，无论存储或检索都难以应对（“存不下”、“查不出”）。因此工业界当前迫切需要一种面向时序数据特征而专门设计的新型时序数据库 —— 蜂鸟时序数据库正是在此背景下，为存储和检索时序数据而研发的分布式数据库。

注 : 取名蜂鸟源自于蜂鸟令人惊叹的挥翅速度。蜂鸟每秒翅膀能挥动15-80次不等。想象一下，蜂鸟本身就犹如一个“传感器”，而翅膀挥动就好比不断产生时序数据。

2. 时序数据带来的新挑战

2.1. 数据量急剧膨胀

机器(传感器)产生的时序数据量与人手工录入的传统档案类数据量相比，完全不是一个数量级—— 前者百万、千万记录量已触顶，而后者动暨数十亿、数百亿的记录规模。面对如此大量的时序数据，传统数据库既“存不下”，也“查不出”(原因见 2.2/2.3/2.4)。因此当前业界普遍采用的妥协方案是：或者只存近期数据(无奈的丢弃老数据)，或者只存储一些抽样记录(如: 降频down-sampling到只记录整点数据)。显然这些方案都无法避免丢弃宝贵数据。在数据为王的时代，谁拥有的数据更多，谁就拥有更强的竞争力，被迫放弃数据实为可惜！

2.2. 数据需高速实时导入，且可实时数据获取（ingestin real time）

大量的传感器数据从四面八方、实时涌来(每分钟成千上万，甚至每秒钟成千上万条记录)，若想从中找到瞬息万变的“机会”，就需要数据能高速入库，同时还能允许及时查询刚入库的新鲜数据。但传统数据库在大量随机数据实时写入时，性能欠佳 (入库速度明显不够)，更糟的是在入库同时当有并发读操作时，读写性能都将变的更差。因此当前业界普遍采用的妥协办法是: 延迟入库(如，到晚上无查询业务时再入库新数据)，或批量入库(如，每天积攒一批数据再批量入库) —— 这些方法实际上都是为了避免或减少读写混合发生。显然上述方案肯定会牺牲数据处理的实时性，因此也必然降低了数据的内在“价值”。

?

2.3. 按时间断面（区间）高速检索数据

时序数据最普遍的查询需求是：“在时间断面上，(精确、条件、模糊)检索数据”。其检索特征更偏向于数据扫描(Scan) —— 而不是传统数据库最擅长的数据定位(seek)。对于数据量有限的档案数据，传统数据库只需在时间列上和键(key)上建立索引，就得能应这类检索。但不幸的是当时序数据上量后，索引无法继续驻留在内存；更糟的是不断的更新操作(如无序插入)又带来了索引分片(indexfragment)的麻烦。这两点都使得传统数据库在按时段查询时无法顺序扫描目标数据区（磁头需要跳跃寻址），因此传统数据库的查询性能会随时序数据增加和持续更新变的越来越差，而且是指数性下降。

除了时序数规模增长和持续更新对传统数据库索引机制造成冲击外，数据乱序入库对传统索引机制更是灾难 —— 乱序入库是指 ： 记录入库顺序并非严格按时间有序(试想多地传感器数据从远程输送来，然后再集中入库。经这个“漫长”过程后，几乎可以肯定数据入库顺序已然不等于数据的发生时间顺序了)。传统数据库在时序数据无序写入的情形下，会造成数据在物理存储上也无序分布。所以即便在时间列上建有索引，按时间断面查询还是无法顺序扫描磁盘，而需要不断seek才能定位数据 —— 我们知道在磁盘上只有顺序读写性能才是最佳，随机读写性能要相差百倍以上。

2.4. 数据分析重要性越发突出

时序数据存储的目的有两类：第一是“事故反演、场景回放”；第二是“分析统计和预测”。而分析类需求从简单到复杂可再分为三小类:

朴素的统计分析（如多维分析等）?

基于移动平均值或者差值的预测分析

基于机器学习等的预测和挖掘分析

统计分析离不开SQL和各种聚合函数和窗口函数；而对于预测、挖掘则往往需要借助于Hadoop体系的M/R、BSP等计算框架。传统数据库对于统计需求，在数据量不大时还算比较擅长，但若要与Hadoop等NOSQL系统配合，则多有不便 —— 或者接口支持不好、或不能最大发挥硬件能力。

2.5. 可控的实施成本

时序数据相关业务才刚刚起步，而且多属于运营支撑性业务。相对于一线盈利业务而言其业务价值和技术本身都存在一定风险；另外业务的数据规模也不一定能一步到位，数据往往是由少到多逐步积累，一开始或相当时间内数据量都很有限。鉴于上述实时，我们建议在项目实施开始阶段应尽量控制成本，降低实施风险。

成本控制从技术角度讲最好的选择是:

使用普通PC机器，也可用私有云提供的标准虚拟机。

先部署有限规模的机器集群(如先满足未来半年数据存储需求)。当业务价值得已证实、数据规模逐步上量后，再对集群进行扩容也不迟（避免初期实施就一步到位，而闲置大量资源）。

上述需求换而言之就是要求：

1. 系统在软件层面要做好、做足容错工作（因为普通pc机缺少小型机所具备的硬件容错设备）。传统数据库往往把容错都交给硬件做，不但成本高，而且实际上也不如软件层面更可靠和可控。

2. 系统必须有良好的横向扩展能力，即补充同类机器机即可实现自动扩容。而传统数据库初期就要购置昂贵的小机，而且扩容时多是采用纵向扩展方式，即需要用户再购买更高配置的小机代替原先的小型机。

?

综上所述（2.1-2.5），传统数据库由于设计初衷是应对“档案”数据，而非时序数据，所以面对当前大规模时序数据时，传统数据库就显得捉襟见肘，难以应对了。正是如此，原先并不被业界所重视的“时序数据库”得以快速走向前台，并日渐受到重视和推崇。

3. 时序数据库适用场景

毫无疑问，存储和检索时序数据肯定是时序数据库的最佳使用场景，但到底有那些场景会产生时序数据呢？我们身边是否有时序数据呢？

我们首先要认识到最可能产生时序数据的不是人，而是机器，更确切的讲是“传感器”。不过这里所谓的“传感器”更具抽象意义 —— 凡是具备数据采集和上报功能的设备都属于“传感器”。比如刷卡POS机、ATM款机、交通摄像头、手机、PM2.5探头等等都属于传感器。可见我们身边充斥着各种“传感器”，生活中的万千变化都被“传感器”时刻记录着。我们不妨大胆预言——不久的将来，随着数据越来越丰富和准确，基于数据权威的社会发展模式必然会让社会变得更高效、更公平、更廉洁。

我们不妨归纳一下依赖时序数据的典型行业和其用到的“传感器”数据：

能源行业：智能电表用电量数据。

通讯行业：短信、话单、邮件。

交通行业：监控摄像头（卡口设备）过车记录；监控油轮航运轨迹、耗油等。

?金融行业：银行POS机刷卡数据、ATM机取款数据。

?环保行业：气象监控数据（温度、风速、降雨等）、环境监控数据（pm2.5等）。

互联网行业：用户访问日志、广告点击日志。

移动互联：近场通讯数据、App应用统计数据。

广电行业：机顶盒操作数据。

物流行业：配送记录数据。

地理信息系统：GPS数据存储和分析。

云计算：服务器性能计数数据。

制造业：监控机器运行指标，优化制造流程。

医疗行业：纪录和监控药品使用情况、纪录和监控病人病理指标。