搭建大规模高性能的时间序列大数据平台 搭建基于时序数据的大型监测系统

1、搭建基于时序数据大型监测系统Facebook Engineering Manager第1页运维里监测基于时序数据监控和警报检测隔离查障修复实时监测系统第2页三个挑战和应对监测系统基本架构智能监测第3页经典监测系统规模 1 per second三万台虚拟机几百万台服务器每秒搜集三百万个数据点每秒搜集20亿个数据点每秒搜集15亿个数据点存放一个亿时序数列存放超两百亿时序数列实时监控五千个告警实时监控一百万个告警六个工程师十二个工程师第4页id （时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），用于监测目标时序数列(time-series)id能够有不一样定义(Pinter

2、est) 数列名字+ 多个(key, value)对E.g., cpu.usagehost=foo(Facebook) entity + keyE.g., entity=host1, key=cpu.usage每一个独特key/value （或entity/key) 组合对应了一个时序数列时序数列定义第5页经典基于时序系列监测系统架构消息总线 (message-bus)数据实时整合和采样告警系统数据可视化和查询虚拟机服务器代理(agent)虚拟机服务器代理(agent)虚拟机服务器代理(agent)时序数据库（TSDB）第6页经典监测系统三个挑战和应对智能监测第7页三个挑战海量测量数据需要高吞

3、吐量和大容量存放方案系统可靠性要高读数据要快必须能含糊搜索可伸缩性和可靠性使用者对监测系统滥用成本第8页Pinterest分片分级存放TSDB(最近2小时)TSDB(无限期)WWW服务器和API服务器产生数据Java服务产生数据互为备份TSDB(最近2小时)TSDB(无限期)互为备份数据可视化和查询Router (依据各TSDB集群反馈指标选择最正确集群)当前负载查询成功率查询延迟第9页Facebook分层存放数据写入内存 TSDB（最近26小时）Flash TSDB（最近14天）Thrift + Hbase（无限期）Hbase周期性任务加大旧数据时间间隔压缩掉不惯用维度第10页内存时序数据库

4、(in-memory TSDB)Gorilla 是Facebook开源内存TSDB利用时序数据冗余做到12倍压缩率数据查询响应时间从几秒降低到0.1秒文章发表于 VLDB 。 Github上开源代号为Beringei多个企业 （如Twitter, Pinterest）基于Gorilla思想，独立开发了自己内存TSDB第11页数据预聚合(pre-aggregation)（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），服务器1（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），服务器2（时间1， 测量值1）， （时间2， 测量值2）， （时间3，

5、 测量值3），服务器3集群预聚合集群（时间1， 最大测量值1）， （时间2，最大测量值2）， （时间3，最大测量值3），集群（时间1， 最小测量值1）， （时间2，最小测量值2）， （时间3，最小测量值3），集群（时间1， 平均测量值1）， （时间2，平均测量值2）， （时间3，平均测量值3），预聚合把高维度时序数据压缩成低维度，同时保留统计意义。降低存放压力并加紧查询速度第12页数据预聚合 - Facebook 版本按集群或服务预聚合按数据中心预聚合第13页数据预聚合 Pinterest 版本实时计算存放存放用户界面和API数据起源聚合时序数据库原始时序数据库Kafka学习预聚合规则评定预聚

6、合规则效率第14页预聚合规则我学习到以下规则：没有些人查询集群A里单机CPU利用率，所以能够只保留集群A总体CPU利用率关于集群A总体CPU利用率，必须计算最大和平均值有些人查询了集群B里单机CPU利用率，所以不能对集群B做聚合用户查询数据日志7月1号15:30, 查询集群 A 最大单机CPU利用率7月1号17:00, 查询集群 A 平均单机CPU利用率7月1号18:00, 列出集群 B 全部单机CPU利用率7月1号18:10, 查询集群 B 最小单机CPU利用率Kafka原始时序数据写入预聚合规则学习器实时数据聚合时序数据库规则第15页三个时序数列被聚合成三个，压缩比为1预聚合规则效率（时间

7、1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），服务器1（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），服务器2（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），服务器3集群预聚合集群（时间1， 最大测量值1）， （时间2，最大测量值2）， （时间3，最大测量值3），集群（时间1， 最小测量值1）， （时间2，最小测量值2）， （时间3，最小测量值3），集群（时间1， 平均测量值1）， （时间2，平均测量值2）， （时间3，平均测量值3），只有压缩比大于1聚合规则才有意义原始维度过小时序列不需要预聚合第16页诠释数据(

8、meta-data)时序数据库消息总线实时数据导入和预处理模块时序数据+数据名map时序数新时序数列诠释数据，包含key/value 或 entity/key，以及产生时间诠释数据索引和管理用途：用户能够用诠释数据含糊查询相关时序数列案例：(1) 已知机器名是key, 查询全部机器名是foo时序数据(2) 列出全部指标名含有 error 时序数据(3) 找出过去一个小时内全部新产生时序数据第17页可伸缩性和可靠性使用者对监测系统滥用成本极少许有用数据 （5%），大量冗余无用数据少数指标产生过量垃圾数据，威胁数据库稳定少许昂贵查询可能影响系统性能监测系统被用于关键服务一环第18页反垃圾（anti

9、-spam）数据虚拟机服务器代理(agent)虚拟机服务器代理(agent)虚拟机服务器代理(agent)消息总线按指标名/集群名/服务名 等各种维度统计当前时间窗口里数据量，并和过去时间窗口对比。假如发觉有突发爆炸性增加，制订垃圾数据黑名单。实时数据分析器垃圾数据黑名单配置参数配置参数配置参数把垃圾数据黑名单加入到服务器代理配置参数里第19页垃圾数据探测不需要100%准确，能够经过采样降低数据处理量Zookeeper很可能成为瓶颈Facebook利用了基于Zookeeper开发出Zeus （链接）Pinterest让程序不直接和Zookeeper建立TCP连接（链接）已被过滤掉垃圾数据，应该

10、找到并修改对应代码。不然传送垃圾数据会浪费服务器资源反垃圾数据本身可伸缩性(scalability)第20页对昂贵查询防范昂贵查询通常要对多个维度，大量时序数据做查询和计算，造成整个TSDB集群变慢和不稳定比如，“整个US-1数据中心平均服务器CPU使用率是多少？”防范办法Facebook有另一套基于采样和内存实时数据查询系统Scuba执行查询前，利用meta-data索引预估该查询需要读入数据量。超出一定阈值时，禁止其被服务第21页监测系统被引入关键服务本身设计 危险！时序数据库真实案例1CPU利用率某关键服务auto-scaling，用该服务CPU利用率来决定资源增减时序数据库真实案例2假

11、如上游服务成功率低于80%，发出警报某关键服务收到该警报后，自动重启监测系统设计目标普通是可扩展性，但允许极少许数据丢失监测系统本身复杂性造成了其可靠性往往低于关键服务期望值应对搭建多个独立监测系统，用冗余换取高可靠性和关键服务开发者加强沟通，关键服务必须在监测系统失效时有备份方案第22页可伸缩性和可靠性使用者对监测系统滥用成本数据不可删除性对存放资源压力实时性对计算资源压力监测系统本身复杂性对运维人员资源压力第23页降低检测系统成本Gorilla集群Gorilla冗余集群1Gorilla冗余集群2HDFSWBL (Write-behind logs)WBLWBL数据适度拷贝左边架构中，WBL

12、有9份拷贝！把WBL挪到LogDevice后只需3份拷贝慎用通用型Key/Value数据库通用型Key/Value数据库在存放时序数列时较低效Purpose-built TSDB更有潜力依据数据使用规律采取不一样成本存放方案前面meta-data可用于此目标第24页监测系统基本架构三个挑战和应对智能监测第25页智能监测系统传统监测系统数据采集，存放系统可伸缩性和可靠性智能监测系统从海量数据里快速地提取有价值信息以用于故障发觉和修复第26页异常检测+警报系统Facebook异常检测采取了以色列Anodot企业算法引擎异常检测产生告警传统人工方式产生告警第27页异常检测单个时序数列异常第28页异常检测多个时序数列异常Anodot异常检测基于semi-supervised，单个多个时序数列混合机器学