搭建大规模高性能的时间序列大数据平台
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
服务器
虚拟机
配置参数
配置参数 服务器
代理 (agent )
虚拟机
配置参数 服务器
代理 (agent )
把垃圾数据黑名单加入到 服务器代理的配置参数里
反垃圾数据自身的可伸缩性(scalability)
•
垃圾数据的探测不需要100%准确，可以通过采样降低数据处理量
•
Zookeeper很可能成为瓶颈
集 群
服务器2
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
预聚合
集群
（时间1， 最小测量值1）， （时间2，最小测量值2），
（时间3，最小测量值3），…
集群
（时间1， 平均测量值1）， （时间2，平均测量值2）， （时间3，平均测量值3），…
服务器3
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
Gorilla集群
Gorilla冗余集群1
Gorilla冗余集群2
•
•
慎用通用型的Key/Value数据库
通用型的Key/Value数据库在存储时序数 列时较低效
WBL (Write-behind logs)
WBL
WBL
HDFS
•
•
Purpose-built TSDB更有潜力
根据数据的使用规律采用不同成本 的存储方案
告警疲劳的对策
•
告警的合并
合并同一时间段内相同目的地的告警 合并描述类似的告警 提供语言来描述告警间的相互触发依赖关系
•
• •
提高告警参数的设置
允许用历史数据来测试告警参数 提倡用异常检测来代替部分人工告警
三个时序数列被聚合成三个，压缩比为1
o
只有压缩比大于1的聚合规则才有意义 原始维度过小的时序列不需要预聚合
o
诠释数据(meta-data)
消息总线
时序数 新时序数列的诠释数据， 包括key/value 或 entity/key， 以及产生时间 时序数据库
实时数据导入和预 处理模块
诠释数据的索引 和管理
7月1号17:00, 查询集群 A 的平均单机CPU
利用率 7月1号18:00, 列出集群 B 的所有单机CPU 利用率 7月1号18:10, 查询集群 B 的最小单机CPU 利用率 ……
预聚合规则的效率
服务器1
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
集群
（时间1， 最大测量值1）， （时间2，最大测量值2）， （时间3，最大测量值3），…
Facebook利用了基于Zookeeper开发出的Zeus （链接） Pinterest让程序不直接和Zookeeper建立TCP连接（链接）
•
已被过滤掉的垃圾数据，应该找到并修改相应的代码。不然传送垃圾数 据会浪费服务器的资源
对昂贵查询的防范
•
昂贵查询通常要对多个维度的，大量的时序数据做查询和计算，导致整 个TSDB集群的变慢和不稳定
用途：用户可以用诠释数据模糊查询相关的时序数列
时序数据 + 数据名map
案例： (1) 已知机器名是key, 查询所有机器名是foo的时序数据 (2) 列出所有指标名含有 error 的时序数据 (3) 找出过去一个小时内所有新产生的时序数据
可伸缩性和可靠性
使用者对监测系统的滥用 极少量的有用数据 （～5%），大量的冗余 无用数据 少数指标产生过量的垃 圾数据，威胁数据库稳 定
•
某关键服务的autoscaling，用该服务的 CPU利用率来决定资 源的增减
监测系统的设计目标一般是可扩展性， 但允许极少量的数据丢失
监测系统的自身复杂性导致了其可靠性 往往低于关键服务的期望值 应对
时序 数据库
•
真实案例2
时序 数据库
如果上游服务的 成功率低于80%， 发出警报
•
搭建多个独立监测系统，用冗余换取高可靠性 和关键服务的开发者加强沟通，关键服务必须在监测系 统失效时有备份方案
异常检测
单个时序数列的异常
wenku.baidu.com常检测
多个时序数列的异常
Anodot的异常检测基于semi-supervised，单个多个时序数列混合的机器学习方法
告警(alert)疲劳
•
大量的冗余告警
Facebook的告警系统里有一百万个告警!
•
•
告警的参数很难精确校准
极易造成false positive 和 false negative
例如，“整个US-1数据中心的平均服务器CPU使用率是多少？”
•
防范措施
Facebook有另一套基于采样和内存的实时数据查询系统Scuba 执行查询前，利用meta-data的索引预估该查询需要读入的数据量。超过一定阈值时，禁止其被服务
监测系统被引入关键服务本身的设计 – 危险！
真实案例1
CPU利用率
集群
（时间1， 最大测量值1）， （时间2，最大测量值2）， （时间3，最大测量值3），…
集 群
服务器2
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
预聚合
集群
（时间1， 最小测量值1）， （时间2，最小测量值2）， （时间3，最小测量值3），…
集群
（时间1， 平均测量值1）， （时间2，平均测量值2），
数据的查询响应时间从几秒降低到～0.1秒 文章发表于 VLDB 2015。 Github上的开源代号为Beringei 多个公司 （如Twitter, Pinterest）基于Gorilla的思想，独立 开发了自己的内存TSDB
数据的预聚合(pre-aggregation)
服务器1
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
搭建基于时序数据的大型监测 系统
Facebook Engineering Manager
运维里的监测
基于时序数据的监 控和警报
查障
修复
实时监测系统
隔离
检测
•
• •
监测系统的基本架构
三个挑战和应对
智能监测
典型监测系统规模
三万台虚拟机 每秒搜集三百万个数据点 存储一个亿的时序数列 实时监控五千个告警 六个工程师 几百万台服务器 每秒搜集20亿个数据点 存储超两百亿的时序数列 实时监控一百万个告警 十二个工程师
代理 (agent )
服务器
虚拟机
代理 (agent )
服务器
虚拟机
代理 (agent )
服务器
•
典型的监测系统
•
•
三个挑战和应对
智能监测
三个挑战
可伸缩性和可靠性 使用者对监测系统的滥用 成本
海量的测量数据需要高 吞吐量和大容量的存储 方案
系统可靠性要高 读数据要快 必须能模糊搜索
Pinterest的分片分级存储
成本
少量昂贵的查询可能影 响系统的性能
监测系统被用于关键服 务的一环
反垃圾（anti-spam）数据
实时的数据分析器
按指标名/集群名/服务名 等各种维度统计当前 时间窗口里的数据量，并和过去的时间窗口对 比。如果发现有突发的爆炸性增长，制定垃圾 数据的黑名单。 垃圾数据的黑名单
消息总线
虚拟机
代理 (agent )
数据的写入
内存 TSDB （最近26小时）
Thrift + Hbase （无限期）
Hbase周期性任务
o 加大旧数据的时间间隔 o 压缩掉不常用的维度
内存时序数据库(in-memory TSDB)
•
•
• • •
Gorilla 是Facebook开源的内存TSDB
利用时序数据的冗余做到12倍的压缩率
某关键服务收到该警报 后，自动重启
可伸缩性和可靠性
使用者对监测系统的滥用
成本
数据的不可删除性对存 储资源的压力
实时性对计算资源的压 力 监测系统本身的复杂性 对运维人员资源的压力
降低检测系统的成本
•
•
数据的适度拷贝
左边的架构中，WBL有9份拷贝！把WBL 挪到LogDevice后只需3份拷贝
（时间3，平均测量值3），…
服务器3
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
o
预聚合把高维度的时序数据压缩成低维度，同时保留统计意义。 减少存储压力并加快查询速度
数据的预聚合 - Facebook 版本
按集群或服务的预聚合 按数据中心的预聚合
数据的预聚合 – Pinterest 版本
•
E.g., {entity=host1, key=cpu.usage}
每一个独特的key/value （或entity/key) 组合对应了一个时序数列
典型的基于时序系列的监测系统架构
告警系统 数据可视化和查询 数据的实时整合和采样
时序数据库 （TSDB）
消息总线 (message-bus)
虚拟机
WWW服务器和API服务器产生的数据 Java服务产生的数据
TSDB(最近2小时)
互为备份
TSDB(最近2小时)
互为备份
TSDB(无限期)
TSDB(无限期)
当前负载 查询成功率 查询延迟
Router (根据各TSDB集群反馈的指标选择最佳集群)
数据可视化和查询
Facebook的分层存储
Flash TSDB （最近14天）
原始的时序数据库 数据来源 实时计算 用户界面和API Kafka
聚合的时序数据库
学习预聚合规则
评估预聚合规则的效率
存储
预聚合规则
Kafka
原始时序数据的写入
实时数据的聚合
规则
时序 数据库
用户查询数据的日志
7月1号15:30, 查询集群 A 的最大单机CPU 利用率
预聚合规则学习器
我学习到如下规则： 没有人查询集群A里的单机CPU利用率，所以可 以只保留集群A的总体CPU利用率 关于集群A的总体CPU利用率，必须计算最大和 平均值 有人查询了集群B里的单机CPU利用率，所以不 能对集群B做聚合
用于监测目的的时序数列(time-series)
时序数列的定义
id ⇨ （时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
id可以有不同的定义
•
(Pinterest) 数列名字+ 多个(key, value)对
•
E.g., cpu.usage{host=foo}
•
(Facebook) entity + key
•
前面的meta-data可用于此目的
• • •
监测系统的基本架构 三个挑战和应对 智能监测
智能监测系统
•
传统监测系统
数据的采集，存储
系统的可伸缩性和可靠性
•
智能监测系统
从海量数据里迅速地提取有价值的信息以用于故障的发现和修复
异常检测产生告警
异常检测+警报系统
传统人工方式产生告警
Facebook的异常检测采用了以色列Anodot公司的算法引擎
虚拟机
配置参数
配置参数 服务器
代理 (agent )
虚拟机
配置参数 服务器
代理 (agent )
把垃圾数据黑名单加入到 服务器代理的配置参数里
反垃圾数据自身的可伸缩性(scalability)
•
垃圾数据的探测不需要100%准确，可以通过采样降低数据处理量
•
Zookeeper很可能成为瓶颈
集 群
服务器2
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
预聚合
集群
（时间1， 最小测量值1）， （时间2，最小测量值2），
（时间3，最小测量值3），…
集群
（时间1， 平均测量值1）， （时间2，平均测量值2）， （时间3，平均测量值3），…
服务器3
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
Gorilla集群
Gorilla冗余集群1
Gorilla冗余集群2
•
•
慎用通用型的Key/Value数据库
通用型的Key/Value数据库在存储时序数 列时较低效
WBL (Write-behind logs)
WBL
WBL
HDFS
•
•
Purpose-built TSDB更有潜力
根据数据的使用规律采用不同成本 的存储方案
告警疲劳的对策
•
告警的合并
合并同一时间段内相同目的地的告警 合并描述类似的告警 提供语言来描述告警间的相互触发依赖关系
•
• •
提高告警参数的设置
允许用历史数据来测试告警参数 提倡用异常检测来代替部分人工告警
三个时序数列被聚合成三个，压缩比为1
o
只有压缩比大于1的聚合规则才有意义 原始维度过小的时序列不需要预聚合
o
诠释数据(meta-data)
消息总线
时序数 新时序数列的诠释数据， 包括key/value 或 entity/key， 以及产生时间 时序数据库
实时数据导入和预 处理模块
诠释数据的索引 和管理
7月1号17:00, 查询集群 A 的平均单机CPU
利用率 7月1号18:00, 列出集群 B 的所有单机CPU 利用率 7月1号18:10, 查询集群 B 的最小单机CPU 利用率 ……
预聚合规则的效率
服务器1
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
集群
（时间1， 最大测量值1）， （时间2，最大测量值2）， （时间3，最大测量值3），…
Facebook利用了基于Zookeeper开发出的Zeus （链接） Pinterest让程序不直接和Zookeeper建立TCP连接（链接）
•
已被过滤掉的垃圾数据，应该找到并修改相应的代码。不然传送垃圾数 据会浪费服务器的资源
对昂贵查询的防范
•
昂贵查询通常要对多个维度的，大量的时序数据做查询和计算，导致整 个TSDB集群的变慢和不稳定
用途：用户可以用诠释数据模糊查询相关的时序数列
时序数据 + 数据名map
案例： (1) 已知机器名是key, 查询所有机器名是foo的时序数据 (2) 列出所有指标名含有 error 的时序数据 (3) 找出过去一个小时内所有新产生的时序数据
可伸缩性和可靠性
使用者对监测系统的滥用 极少量的有用数据 （～5%），大量的冗余 无用数据 少数指标产生过量的垃 圾数据，威胁数据库稳 定
•
某关键服务的autoscaling，用该服务的 CPU利用率来决定资 源的增减
监测系统的设计目标一般是可扩展性， 但允许极少量的数据丢失
监测系统的自身复杂性导致了其可靠性 往往低于关键服务的期望值 应对
时序 数据库
•
真实案例2
时序 数据库
如果上游服务的 成功率低于80%， 发出警报
•
搭建多个独立监测系统，用冗余换取高可靠性 和关键服务的开发者加强沟通，关键服务必须在监测系 统失效时有备份方案
异常检测
单个时序数列的异常
wenku.baidu.com常检测
多个时序数列的异常
Anodot的异常检测基于semi-supervised，单个多个时序数列混合的机器学习方法
告警(alert)疲劳
•
大量的冗余告警
Facebook的告警系统里有一百万个告警!
•
•
告警的参数很难精确校准
极易造成false positive 和 false negative
例如，“整个US-1数据中心的平均服务器CPU使用率是多少？”
•
防范措施
Facebook有另一套基于采样和内存的实时数据查询系统Scuba 执行查询前，利用meta-data的索引预估该查询需要读入的数据量。超过一定阈值时，禁止其被服务
监测系统被引入关键服务本身的设计 – 危险！
真实案例1
CPU利用率
集群
（时间1， 最大测量值1）， （时间2，最大测量值2）， （时间3，最大测量值3），…
集 群
服务器2
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
预聚合
集群
（时间1， 最小测量值1）， （时间2，最小测量值2）， （时间3，最小测量值3），…
集群
（时间1， 平均测量值1）， （时间2，平均测量值2），
数据的查询响应时间从几秒降低到～0.1秒 文章发表于 VLDB 2015。 Github上的开源代号为Beringei 多个公司 （如Twitter, Pinterest）基于Gorilla的思想，独立 开发了自己的内存TSDB
数据的预聚合(pre-aggregation)
服务器1
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
搭建基于时序数据的大型监测 系统
Facebook Engineering Manager
运维里的监测
基于时序数据的监 控和警报
查障
修复
实时监测系统
隔离
检测
•
• •
监测系统的基本架构
三个挑战和应对
智能监测
典型监测系统规模
三万台虚拟机 每秒搜集三百万个数据点 存储一个亿的时序数列 实时监控五千个告警 六个工程师 几百万台服务器 每秒搜集20亿个数据点 存储超两百亿的时序数列 实时监控一百万个告警 十二个工程师
代理 (agent )
服务器
虚拟机
代理 (agent )
服务器
虚拟机
代理 (agent )
服务器
•
典型的监测系统
•
•
三个挑战和应对
智能监测
三个挑战
可伸缩性和可靠性 使用者对监测系统的滥用 成本
海量的测量数据需要高 吞吐量和大容量的存储 方案
系统可靠性要高 读数据要快 必须能模糊搜索
Pinterest的分片分级存储
成本
少量昂贵的查询可能影 响系统的性能
监测系统被用于关键服 务的一环
反垃圾（anti-spam）数据
实时的数据分析器
按指标名/集群名/服务名 等各种维度统计当前 时间窗口里的数据量，并和过去的时间窗口对 比。如果发现有突发的爆炸性增长，制定垃圾 数据的黑名单。 垃圾数据的黑名单
消息总线
虚拟机
代理 (agent )
数据的写入
内存 TSDB （最近26小时）
Thrift + Hbase （无限期）
Hbase周期性任务
o 加大旧数据的时间间隔 o 压缩掉不常用的维度
内存时序数据库(in-memory TSDB)
•
•
• • •
Gorilla 是Facebook开源的内存TSDB
利用时序数据的冗余做到12倍的压缩率
某关键服务收到该警报 后，自动重启
可伸缩性和可靠性
使用者对监测系统的滥用
成本
数据的不可删除性对存 储资源的压力
实时性对计算资源的压 力 监测系统本身的复杂性 对运维人员资源的压力
降低检测系统的成本
•
•
数据的适度拷贝
左边的架构中，WBL有9份拷贝！把WBL 挪到LogDevice后只需3份拷贝
（时间3，平均测量值3），…
服务器3
（时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
o
预聚合把高维度的时序数据压缩成低维度，同时保留统计意义。 减少存储压力并加快查询速度
数据的预聚合 - Facebook 版本
按集群或服务的预聚合 按数据中心的预聚合
数据的预聚合 – Pinterest 版本
•
E.g., {entity=host1, key=cpu.usage}
每一个独特的key/value （或entity/key) 组合对应了一个时序数列
典型的基于时序系列的监测系统架构
告警系统 数据可视化和查询 数据的实时整合和采样
时序数据库 （TSDB）
消息总线 (message-bus)
虚拟机
WWW服务器和API服务器产生的数据 Java服务产生的数据
TSDB(最近2小时)
互为备份
TSDB(最近2小时)
互为备份
TSDB(无限期)
TSDB(无限期)
当前负载 查询成功率 查询延迟
Router (根据各TSDB集群反馈的指标选择最佳集群)
数据可视化和查询
Facebook的分层存储
Flash TSDB （最近14天）
原始的时序数据库 数据来源 实时计算 用户界面和API Kafka
聚合的时序数据库
学习预聚合规则
评估预聚合规则的效率
存储
预聚合规则
Kafka
原始时序数据的写入
实时数据的聚合
规则
时序 数据库
用户查询数据的日志
7月1号15:30, 查询集群 A 的最大单机CPU 利用率
预聚合规则学习器
我学习到如下规则： 没有人查询集群A里的单机CPU利用率，所以可 以只保留集群A的总体CPU利用率 关于集群A的总体CPU利用率，必须计算最大和 平均值 有人查询了集群B里的单机CPU利用率，所以不 能对集群B做聚合
用于监测目的的时序数列(time-series)
时序数列的定义
id ⇨ （时间1， 测量值1）， （时间2， 测量值2）， （时间3， 测量值3），…
id可以有不同的定义
•
(Pinterest) 数列名字+ 多个(key, value)对
•
E.g., cpu.usage{host=foo}
•
(Facebook) entity + key
•
前面的meta-data可用于此目的
• • •
监测系统的基本架构 三个挑战和应对 智能监测
智能监测系统
•
传统监测系统
数据的采集，存储
系统的可伸缩性和可靠性
•
智能监测系统
从海量数据里迅速地提取有价值的信息以用于故障的发现和修复
异常检测产生告警
异常检测+警报系统
传统人工方式产生告警
Facebook的异常检测采用了以色列Anodot公司的算法引擎