阿里巴巴双十一千万级实时监控系统技术揭秘-InfoQ



 写点什么

本次分享主要介绍以下四方面：

时序业务全景
TSDB 介绍
核心技术
总结展望

时序业务全景

从底层的机器监控到直面用户的应用，都离不开时序性的业务场景，而时序性的数据一般都由专业的时序数据库来存储分析，下面主要介绍 TSDB 覆盖的业务场景以及面临的挑战。

1.1 时序数据库覆盖场景

基础设施层：机柜、物理机、操作系统监控日志

基础运维：sunfire(集团统一监控、采集、报警系统)、阿里云监控、GOC(阿里全球应急调度指挥系统)

资源调度：集团内部调度系统、Kubernetes

集群管理：DBPaas(阿里所有数据库实例的监控和调度)

应用层：APM 场景下的各种应用

1.2 时序数据库面临的挑战

由于面临各个层级的不用场景，所以时序数据库也面临不同挑战：

应用层挑战：由于直面客户所以需要提供高频率、低延迟的查询
olap 数据库本身特性：海量数据的聚合
时序数据库特有的：发散时间线
双十一大促：突然流量十倍以上增长

TSDB 介绍

2.1 TSDB 的发展及性能

TSDB 于 2016 年开始服役,到目前为止参与了三次双十一大促，相比于 2017 年读写吞吐翻倍增长,写入 TPS4000w，查询 2wQPS 覆盖集团 130+业务线及存储百亿的时间线。

2.2 TSDB 架构介绍

如上图，从左到右为数据的采集到展现的过程：

边缘计算：轻量可靠的计算方案，主要负责数据的采集，与云端的 TSDB 打通，在 OLAP 场景或者资源不稳定的场景下实现数据的稳定采集、清洗等。

时序引擎：

时序索引：时间线的查询；

储存引擎：时序数据、海量数据存储的解决方案；

流式数据聚合：在时序数据库的海量数据里做高效的的聚合分析；

稳定性管理：在云上稳定安全的运行；

计算引擎、sql 引擎、智能引擎：主要与时序引擎交互实现数据计算、sql 解析、模型算法等功能，可以扩展时序引擎的能力，降低使用的门槛；

协议支持：主要面向用户，为用户提供一些可视化的查询和分析支持。

核心技术

3.1 海量时序数据存储

3.1.1 数据压缩

说起存储就离不开压缩,数据的压缩方法和压缩算法的选择很大程度上支持了海量数据的储存。

如上图代表时间窗口为一小时的数据，0-3600 代表过去一个小时内的数据，采用 key-value 存储格式,以秒值作为 key，每秒的数据作为 value 存储。

这里参考 facebook grada 思想引入了时序压缩算法，通过列合并的方式把所有的时间戳和对应的 value 聚合长两个的大数据块，然后对这个两个大块进行时序压缩算法，然后再用通用的块压缩算法进行压缩。

另外不同的数据类型采用不同的数据压缩格式，如：

时间戳：delta- delta

浮点型：XOR 编码

整型：variable length encoding

字符串：LZ4，实现了存储层乱序数据压缩，保证压缩数据的准确性,整理的压缩率在 15:1。

3.1.2 数据压缩效果

为什么要采用时序压缩+块压缩，我们可以看一下这个图。

首先时序压缩针对不同类型的数据采用了不同的压缩格式，所以整体的效果优于块压缩算法，而在时序压缩算法对数据压缩后在采用通用的块压缩，不会影响到块压缩的压缩效率，用时序压缩+块压缩相比单独的块压缩能有 40%的压缩率提升，这为海量数据的存储提供了有力的帮助。

3.2 高频、低延迟查询

淘宝魔兔是阿里一款应用无线端数据分析和监控的产品，支持集团内部 500+的应用，在双十一大促是查询峰值可达 4000QPS，相较于平常查询量有 10 倍的提升，,99%读写 rt 都要求在 20ms 以内，那么 TSDB 是如何实现用户端高频、低延迟的查询呢?

3.2.1 分布式缓存存储适配

参考 Facebook Gorilla 论文，基于 java 做了一套分布式的内存缓存存储，基于 zookeeper 实现分片及容量的调整，可以实现动态的扩容和缩容，在整个双 11 过程中支持 1000wTPS 的写入和 4000 的 QPS 的查询。

3.2.2 TsMem 设计

如图所示，TsMem 基于 Disruptor 做一个 RingBuffer，把用户读写的请求都暂存在 RingBuffer 中，采用多个生产者和一个消费者模式，一个消费者的请求会打到多个 worker 线程中，每一个 worker 线程又是一个分片，所以其实就是基于 RingBuffer 做了一个内存的分片，这样一来就是一个线程对应一个分片，这样就不会产生共享资源,也就无需考虑锁的实现。

把写和读都分配到一个链路上，一个 worker 同时处理读和写，提高读写性能

同时还利用了 RingBuffer 的 batching 特性，将用户的读写请求都暂存在一个 butching 中，然后当达到一定阈值或时间 worker 将直接提交一个 batching，这样虽然会是请求有一定的延迟，但是大大提高了 worker 的吞吐量。

那么如何保证高效的内存管理和极低毛刺的延迟呢？

对于数据块基于引用计数的 chunk 池化管理，把所有的时序数据块在内存中做了池化，这样就能减少读取数据时临时对象的创建，而且还能避免大块时产生的抖动和延迟。