字节跳动海量时序数据库内核探究
如果无法正常显示,请先停止浏览器的去广告插件。
1. 字节跳动海量时序数据库
内核探究
王栋
字节跳动基础架构 研发工程师
2.
3. • 字节 TSDB 概述
• 字节 TSDB 内核探究
• 字节 TSDB 业务支撑案例
• 总结和展望
4. 字节可观测性平台 业务挑战
• 服务数
• 国内装机量
• 日均服务发布
• 日均配置变更
5. 字节可观测性平台 构建思路
构建思路:三位一体
“三位”:
• Metrics 监控数据
• Tracing 调用链路数据
• Logging 日志数据
“一体”:
• 一个平台,观测上述 3 类数据
• 一套存储,链接上述 3 类数据
6. 字节 TSDB 使用方式
重要概念
• 序列(Series):一组 时间戳 和 值
• 序列的唯一主键:Tag组合
写入:SDK(Golang/Java/C++/Python);数据
类型(Timer/Counter/Gauge/Histogram)
查询:实现了绝大部分 OpenTSDB 查询语法,可
通过 Grafana、Bosun 等接入,亦可用 OpenAPI
查询数据
7. 字节 TSDB 使用方式
查询举例:
q("avg:cpu.load{idc=1}", "1h-ago", "")
Series Key 10:00:00 10:00:10 10:00:20
idc=1, host=1.1.1.1 10.0 7.0 10.0
idc=1, host=1.1.1.2 9.0 5.0 -
idc=1, host=1.1.1.3 8.0 9.0 -
idc=2, host=2.1.1.1 3.0 1.0 4.0
Series Key 10:00:00 10:00:10 10:00:20
idc=1 9.0 7.0 10.0
8. 字节 TSDB 整体架构
9. 字节 TSDB 内部落地情况
吞吐量 国内 2 Billion 打点/秒 [30 秒本地聚合后]
查询性能 国内 40K QPS, Latency avg 0.3s, pct99 2.1s
Metric 数量 国内集群 Metric 数量超过 20M
最大支持维度 单指标最大支持 30M Dimension
资源配比 每 5 台机器,支撑 1000 台机器监控
OpenAPI 账号 1000+ OpenAPI APP 账号
用户规则 2000+ 预聚合规则
10. • 字节 TSDB 概述
• 字节 TSDB 内核探究
• 字节 TSDB 业务支撑案例
• 总结和展望
11. 高性能存储:结合 Cache 和 HDFS 构建冷热存储
12. 热存 tsdc:引擎内核 (1/3)
引擎细节:
• TagK 和 TagV 会字典化,TagSet
使用 varint 编码
• SeriesId 是自增 ID
• 查询过的 Tag 会创建索引,Tag
Cardinality 决定索引类型
• Inverted Index 的 postings 使用
RoaringBitMap
13. 热存 tsdc:引擎内核 (2/3)
• 两类 TimeSlot:Mutable,Immutable
• Immutable Slot 会序列化到磁盘,同时
LruCache 加速其查询速度
• DataPointSet 为核心数据结构,包括:
1. 优化版 Gorilla 压缩算法
2. 动态长度 RingBuffer
3. 多值列式存储
14. 热存 tsdc:引擎内核 (3/3)
• Scan:Async RPC,并根据load数据
大小区分轻重查询,轻重查询线程隔
离
• 使用 Distributed Weighted Round-
Robin(DWRR) 调度算法,保证租户
cpu粒度的公平调度
• 支持用户自定义、实时预聚合 [TSDB
物化视图]
15. 冷存 arestor: PreShuffle, Streaming and Compaction
PreShuffle
• Shuffle数据
• 生成Watermark
Streaming
• 窗口化聚合计算
• Auto-Rollup
Compaction
• 小文件Merge
• 清理历史高精度数据
16. 冷存 arestor: File Format
17. 高性能查询:执行引擎 (1/2)
字节 TSDB 查询服务使用自研轻量级执行引擎。包含2个框架:
框架一:定义 Dag,生成异步Workflow
(Dag包括:Action、Plan、Graph)
18. 高性能查询:执行引擎 (2/2)
框架二:远程执行器,“真”异步
rpc
支持 Fast Fail On Exception,基于 Cost 预测的 Fast Fail 也正在开发中。
19. 高性能查询:分布式查询 DQuery (1/4)
==>
Scatter-Gather
20. 高性能查询:分布式查询 DQuery (2/4)
执行过程的优化项:
(1) 多节点分布式执行:上述所有 Action,都可以转
化成 Remote Event 并远程执行
(2) 算子下推:比如聚合算子SUM/COUNT/MIN/MAX
等,下推到最底层节点执行
(3) 流式聚合:非叶子节点支持流式聚合
21. 高性能查询:分布式查询 DQuery (3/4)
(4) 异步 load 存储:使用异步 client 获取 tsdc 和
arestor的数据
(5) 时间片长度选择:时间片的切分,对齐 tsdc 和
arestor 存储的 TimeSlot 长度
22. 高性能查询:分布式查询 DQuery (4/4)
Dquery 支持多机房容灾:
(1) 一个依赖:机房单元化
(2) 一个假设:两条专线,不会同时中断
(3) 容灾方案:在主机房之间发生网络孤
岛、长传中断等故障时,查询 proxy 可以
动态切到第三方控制面
23. 高可用大脑:集群状态中心 Coordinator(1/3)
使用Raft作为一致性协议,保证系统的CP性(Consistency & Partition Tolerance)。
基本抽象:资源组(Resource Group)
· 需要分配 shard 的 tsdc 集群
· 需要分配 partition 的 MQ Consumer
Group
24. 高可用大脑:集群状态中心 Coordinator(2/3)
1. tsdc会向Coordinator注册,注册后保
持心跳
2. Coordinator给tsdc资源组分配节点
3. 读写两侧,获取分配好的拓扑
25. 高可用大脑:集群状态中心 Coordinator(3/3)
Coordinator 支撑 tsdc 水平扩展:
• 写入:根据消息的 EventTime,对齐
Timeline,确定消息对应的TimeState
• 查询:根据查询的时间范围,如果包含
多个 TimeState,则在制定查询计划时、
在时间片拆分这一步对齐 Timeline
26. 其他内核细节(1/3):二级一致性 Hash
数据的sharding,使用二级一致性 Hash :
•
Consumer:两次 Consistent Hash 计算,确定序
列的数据分片
•
Query:一次 Consistent Hash 计算,确定同一
Metric 下多个序列的数据分布范围
27. 其他内核细节(2/3):常态写降级
解决问题:部分指标,只写不查
解决办法:
1. 查询过的 Metric Name,写入Bloom Filter,该 BF 的 Key 定时过期
2. 写入侧根据上述 Bloom Filter ,对未查询的指标降级到5分钟
28. 其他内核细节(3/3):写入链路私有Codec
字节TSDB定义了一套高性能的私有写入Codec
1. 代码复用:写入链路每个环节,都可以复用相同代码
2. 个性化部署:支持更个性化的部署方案,比如SDK直
写tsdc
3. Decode友好:只需要解码出Metric Header,即可完
成封禁、常态写降级等功能
4. Hashcode 计算迁移:Metric Name、Tags的 hashcode 计算,前移到 SDK 进行
29. • 字节 TSDB 概述
• 字节 TSDB 内核探究
• 字节 TSDB 业务支撑案例
• 总结和展望
30. 业务支撑案例(一): 框架和链路追踪
字节内部Rpc & Http框架,通过字节链路追踪系
统,深度集成了TSDB Client:
• 涵盖golang/python/c++/java等多个语言
• 定义统一的微服务黄金指标:QPS / 延时 /
错误率 等
• 用户开箱即用
31. 业务支撑案例(二):观测诊断平台
• 监控:应用监控、容器&主机资源监
控、基础组件监控
• 报警:微服务报警、自定义报警、组
件报警、智能报警
• 事件 & 日志
• 归因 & 诊断
32. 业务支撑案例(三):微服务数仓
• [性能倍增项目] 各服务资源占用、吞吐、单
核 QPS
• 单服务天级别的请求数、成功率、SLA 等,
用来计量计费
33. • 字节TSDB 概述
• 字节TSDB 内核探究
• 字节TSDB 业务支撑案例
• 总结和展望
34. 经验总结
容量 & 成本
1.
冷热存储
2. Agent 侧30s聚合
3. 常态写降级
4. tsdc内存模型极致优化
性能
1.
存储引擎的细节:字典化、
varint 编码、索引、锁粒度
细化
2. 分布式查询、算子下推
时序模型
1.
多租户
2. 多值
35. 未来展望
• 多租户持续演进
• 自定义多值 & 支持 Schema
• 云原生
• tsdc 持久化持续演进
36. nh.wangdong@gmail.com
37.
38.