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

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. 数据分析重要性越发突出

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

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


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

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

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

2.5. 可控的实施成本

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

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

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

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

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

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

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

 

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

3. 时序数据库适用场景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    另外，公安刑侦、情报分析、物联网、智慧城市等也都是时序数据的消费行业。不夸张的讲：凡是具有公共服务特征的行业就离不开时序数据—— 或产生时序数据、或消费时序数据、或兼而有之（时序数据库的具体实践请见“最佳实践”一章）。

4. 系统运行环境要求

    蜂鸟不需要高端存储设备和高性能小型机，而是使用配置SATA磁盘的普通PC服务器（组成计算存储一体化集群）。这种通用机型的配置要求其实正是大数据、云计算运行环境发展的主流趋势和必然结果。因为通用机型除了价格低廉和保护企业现有投资的原因外，更重要的原因是：可以使用私有云和公有云所提供的虚拟机部署系统。由此可见，蜂鸟系统可部署在提供虚拟机的“私有云”中，甚至还可被部署在EC2这种“公有云”上。

    当然对于预算宽裕，或想要求最佳性能表现的客户，完全可以给出较高的环境配置 —— 更高的配置必然能带来更高的性能。

    下面简要给出一个大众化的配置要求（可满足大多数要求），供大家参考：

n  CPU — 4-12 core(主频>2G)  # 如果计算任务颇多,可尝试提升CPU主频档次, 另外核/core数最好比机器磁盘数多才好(如8盘,则12核最佳)

n  内存 — 16G-512G # 32G属于标配，内存越大缓存越多，处理数据也自然更快，所以有实力的可将内存容量扩充到32G、64G、128G、256G、甚至更高。

n  磁盘 — 2 - 12个STAT/SAS磁盘 # 一般大容量的SATA磁盘速度就足够了，但数量应尽可能多，因为越多的磁盘数量不仅仅是容量增加，更重要是写入和查询性能的提升(近线性提升)，所以多盘是高性能性能的保证之一。

n  网络 — 千兆网络环境 # 千兆网络已能应对大多数场景了，如在万兆网环境下，则写入和查询性能（尤其是大表Join操作）都将显著提升。

n  OS — Centos6.5(64bit) # 我们推荐比较稳定的Centos系统，不过实际上Linux各种操作系统都予以支持

如果要求更高的处理性能和存储能力，则简单补充机器即可达到目的(性能的具体计算公式见章节10.2)

注：如果需要高可用性，则最少配置三台机器，以保证数据安全；

5. 体系架构

   蜂鸟系统最重要的架构特点是分层结构 —— 每层各司其职，相互解耦，独立演化。最重要的两层分别是NOSQL数据层和SQL查询层。 而在NOSQL层于SQL层上分别选择了Shared Nothing和MPP两种分布式经典架构。

层次说明(见图1):


n  NOSQL数据层 : NOSQL层处于基础层，内部自下而上又分为 “数据存储层” 、“数据同步层”、 “对象检索层”。分别负责数据持久化、多副本数据传播、对象读写控制功能。该层采用NOSQL经典的Shared Nothing架构，具备高扩展性、高并发性、高可用性等优良特性。

n  SQL查询层 : SQL层依赖于 NOSQL层，内部自下而上又分为“并行SQL执行层” 和“JDBC/ODBC接口层”。该层采用SQL查询领域最成功的MPP架构，具备大吞吐、高并发等优良特性。

n  离线计算层 : 该层和SQL层一样都是依赖于NOSQL层，但同时也依赖于HADOOP 体系中得M/R组件。简单讲，离线计算原理是利用M/R框架就近(到数据所在机 执行计算任务)操作NOSQL数据层所管理的数据。 从编程接口一节可看到，蜂鸟支持M/R 程序，也支持PIG、HIVE等工具，都些无不得益于离线计算层。显然该层继承了HADOOP离线计算框架具有的大吞吐、高容错等优良特性。

 

 图 1

6. 时序数据存储格式

    近年来，经过在大数据项目中不断探索与实践，使得我们更“懂”时序数据。蜂鸟大胆抛弃了传统数据库的掣肘，针对时序数据设计了专有数据格式和执行计划，以求最佳性能。在展开时序数据存储格式前，重申时序数据处理的主要特征 : 时间断面(区间)上进行精确、模糊、条件检索 —— 例如 : 查找国庆期间查询给定嫌疑人通讯踪迹(精确查询) ; 查春节期间具有“陕A”车牌号字样的进京车辆/总数(模糊前缀查询) ; 查询大年初一北京望京地区用电量最高的电表(地域条件查询)；除时间区间上基本检索外，很多场景更需要在时间段面(区间)上进行各种统计分析计算 —— 例如 : 如，总量统计、同比、环比计算等。

    我们针对上述时序数据处理的两大场景 : “区间内个体回放”和“区间内统计分析”(前者是在时间区间上进行给定key的检索；后者是在时间区间上进行分析计算)，分别设计了KT和TK两种针对性存储格式。如果应用场景同时有统计分析和个体回放两类需求，则可使用蜂鸟专有的PKT格式兼顾这两类需求 —— PKT格式属于TK格式和KT格式之间的一种“折中”选择。若场景确定时，优先考虑使用KT或TK场格式 —— 比如，侦查员追查嫌疑车辆轨迹，或疑犯的通话记录等场景，属标准的个体回放需求，应优先考虑KT格式；路况车流等指标计算则属于区间内统计分析运算需求，应优先考虑TK格式；但当你既想查看给定车轨迹，又想统计路况信息时，则最好选择PKT格式了。

 

我们以示例数据做样本，分别按照三种不同存储格式组织时序数据，通过对比展示几种格式之间的区别。

示例数据:

时间从