Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Apache IoTDB 的前世今生与部分技术细节 2020-01
Similar to Apache IoTDB 的前世今生与部分技术细节 2020-01 (20)
More from jixuan1989
More from jixuan1989 (6)
Apache IoTDB 的前世今生与部分技术细节 2020-01
- 1. S P E A K E R 演 讲 IoTDB的前世今生 与技术细节揭秘 2019-01-04
- 9. Network MQ Database queryinsertion save data locally Network analysis How to Manage Time Series Data
- 10. 大规模时序数据的特点 占用空间极大 数据总吞吐量大 产生速度快且不间断 时序数据存储的需求 【全时全量】 保证数据全时全量存储 【高效写入】 保证数据库可以承受高吞吐写入 【紧凑存储】 对数据进行有效压缩减少磁盘空间占用 超过20,000个风机 一个风机约有120~510传感器 采集频率从0.00167 Hz 到 50Hz 不等 需求与挑战：提升工业时序数据利用率，从有效存储开始
- 11. 需求与挑战：支撑复杂工业场景，克服领域技术难点 § 场景1：由于网络延迟、设备故障等原因数 据无法完全保序到达 § 场景2：由于设备故障、损坏等原因，在进 行分析等操作前需要对错误数据进行修正 § 场景3：清理过时数据或无效、无用数据 时序数据数据乱序操作的需求 数据库需要支持时间序列数据的乱序写入 数据库需要支持时间序列数据的批量更新 数据库需要支持时间序列数据的清理删除 排口有大量取值异常 的采样点，例如PH 值超过10,000 该排口连续164天缺 失上报PH值
- 12. • 单表列数上限 • MySQL InnoDB 为1017列 • 单表行数不易过多 • 小于1000万行 • 水平、垂直分表；分库 关 系 数 据 库 键 值 数 据 库 • 可管理海量条时间序列 • 查询受限 • 按时间维度的查询 • 按值维度的查询 • 多序列的时间对齐查询 基于关系数据库 基于PG开发的插件 •时序数据自动分区 •查询计划做优化 •定制并行查询 随着导入时间的增加 导入速率不断下降 基于键值数据库 基于Hbase/Cassandra •时序分区键 •定时任务构建索引 压缩不友好，查询不友好 原生时序数据库 基于LSM机制的时序库 •专属文件结构 •专属查询优化 一些工业场景下 性能下降 时 序 数 据 库 时序数据管理 （超高性能、超多序列）
- 14. 时序数据分析（需求二） 中等风没满转 超大风满转 大风满转 超低风0转 低风低转速（稳定） 低风低转速（下降） 时间序列HMM分割算法 时间序列分割 准确计算各站点人流量 准确计算各状态下的统计值
- 15. 时序数据分析（需求三） 时序数据降采样 内存 数据量 [1, 2, 0, 5.1, 3, …., 9, 1] 高维向量 算法效率
- 17. 时序数据分析（性能） 批量使用历史数据，漫长的ETL Database insertion analysis • 查询友好 • 写入友好 • 分析友好 ETL KairosDB：导出每辆车每天3000种的数据：1小时 气象大数据系统：大量时间花费在数据获取上
- 18. 需求与挑战：面向工业应用场景，提升数据处理能力 模式匹配 聚合查询数据 十亿点数数十毫秒查询 查询延迟低、时效高 TB 级数据百毫秒查询 指定查询过滤条件 按时间、设备、传感器类型等过滤 序列对齐查询 多序列按时间维度对齐 序列填充查询 空值填充 时序分割 数字水印 Say No to ETL 高通量写入 高效压缩
- 19. 从Cassandra到IoTDB
- 20. 故事从2012年说起… 三一重工，20万设备在线，采集了三年数据，Oracle吃不消 d1:s1: 1560900000 d1:s1: 1561000000 d1:s2: 1560900000 D2:s2: 1561000000 01:1 02:1 10:1 01:1 02:1 10:1 01:1 02:1 10:1 01:1 02:1 10:1 5台Cassandra，撑起一片天。 性能一般般。。。
- 21. 2015年，基于Cassandra研发分布式时序数据库 d1:s1: 1560900000 d1:s1: 1561000000 d1:s2: 1560900000 D2:s2: 1561000000 01:1 02:1 10:1 01:1 02:1 10:1 01:1 02:1 10:1 01:1 02:1 10:1 客户机 查询/写入引擎 Cassandra 受制于人
- 23. 面向工业互联网的高性能轻量级时序数据库 清 华数为 工 业 互 联 网 时序数据库 Apache IoTDB – 工业领域千万条量级时间序列管 – 单节点万亿数据点管理 – 单节点数十TB级时间序列数据管理 – 支持Hadoop、Spark、Matlab、 Grafana等多种生态 中国高校唯一Apache基金会项目
- 24. Apache IoTDB的功能特点 扩展的时间序列操作 多种服务形式 终端 本地控制器 数据中心 灵活部署 开箱即用 支持数据实时写入/写出 支持便捷友好的分析 收集 存储 处理学习 应用 覆盖数据全生命周期 与现有生态系统集成高效的数据持久化 • 高速写入 • 每秒3000万点（单机） • 高压缩比 • 1.37bits/点 [1] • 有损和无损压缩 • 支持百万时间序列 丰富/低延迟的数据查询 • 快速过滤数据 • TB级数据百毫秒 查询 • 聚合查询数据 • 十亿点数十毫秒 查询 • 时序分段 • 时序表达 • 子序列匹配 • 时频转换 • 可视化 • MatLab • Spark • MapReduce • Grafana • Kafka
- 26. Visualization (Manual data explore) Analysis with Matlab (small data set) Integration with other systems Big data analysis 26
- 27. 技术架构 国际领先技术 - 高效聚合索引 （CKIM 2016） - 时序模式检测 （WAIM 2018） - 子序列匹配 （ICDE 2019） - … 20
- 28. IoTDB的单机千万点 写入性能
- 31. 数据写入 d1,s1, t1, v d1,s1, t3, v d1,s1, t2, v d1,s1, t4, v d1,s1, t_, v 内存数据 d1 d2 s1 s1 s2 t1, v t3, v t2, v t4, v t1, v t2, v t1, v t2, v Disk cleaned memory 存在大量乱序数据 乱序时长从0-300分钟不等 30分钟以内乱序数据较多 •WritableMemChunk容忍一定的乱序，且不排序 •过于陈旧的数据，则放入溢出数据对应的内存表中 *一些系统在内存中采用Btree结构 •刷入磁盘时或者服务于查询时，将数据拷贝并排序 •CopyOnRead d2,s1, t1, v d2,s1, t2, v d2,s2, t1, v d2,s2, t2, v 原始数据
- 32. 刷写磁盘 d1 d2 d3 d4 存储组1 StorageGroup Processor 数据文件 数据文件 数据文件 DataFile Processor + workingDFP : DFP 正在接受数据写入的DFP + closingDFPs : List<DFP> 已经不再接受数据写入的DFP 正在排队等待刷写磁盘和关闭文件 + dataFiles: List<DataFile> 所有的文件集合 • 读写操作的并发安全 • closing队列的清理 • dataFiles的同步维护 + workingMTable : MemTable 正在接受数据写入的内存表 + flushingMTabless : List<> 已经不再接受数据写入的内存表 正在排队等待刷写磁盘 可能会关闭掉文件 读写操作的并发安全
- 33. 刷写磁盘 MC M M MC M M M M M F1 F2 F3 ThreadPool 并行与串行协同工作 多 线 程 并 行 单文 件所 有M 任务 串行 保序 执行 WritableMemChunk 增大任务调度并行度 1 排序 2 编码 3 IO 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3
- 34. 数据文件：现有文件格式的问题 Apache Parquet Time1 Value1 p领域语义 Ø 时间列总是被读取 （otherwise the time dimension is missing） Ø 数据总是按时间排序 Ø 统计信息的意义很重大 (max/min time/value, for accelerating query) p空值问题 Ø Parquet 需要存储空值来保证按行返回结果 Ø Parquet has to add R and D fields for supporting nesting, which is meaningless for time series data. Time2 Value2 时间序列数据通用文件格式
- 35. 数据文件 TsFile Chunk Group …… Chunk FileMetaData Page Metadata Times Values Page 1 Chunk 1 Chunk m Chunk Metadata Page n Chunk Group Chunk Group Metadata Page … • 元信息成为微索引 • 时间列被重复存储
- 36. 数据文件 TsFile ChunkGroup Footer Chunk Header Chunk data Chunk data Chunk data marker Chunk Header marker Chunk Header marker TsDeviceMetadata( d1) marker TsFileMetaData(d1,d2) String: 12 bytes Magic TsDeviceMetadata( d2) ChunkGroup Footer Chunk Header Chunk data Chunk data Chunk data marker Chunk Header marker Chunk Header marker marker marker TsFileMetada ta Size String: 12 bytes Magic d1 d2
- 37. 数据文件 TsFile ChunkGroup Footer Chunk Header Chunk data Chunk data Chunk data marker Chunk Header marker Chunk Header marker TsDeviceMetadata( d1) marker TsFileMetaData(d1,d2) String: 12 bytes Magic TsDeviceMetadata( d2) ChunkGroup Footer Chunk Header Chunk data Chunk data Chunk data marker Chunk Header marker Chunk Header marker marker marker TsFileMetada ta Size String: 12 bytes Magic d1 d2 自解释 自修复 向量化读取
- 38. 编码 128, 136, 144, 152, 160, … 8, 8, 8, 8 à 1st difference is constant. 0, 0, 0 à 2nd difference is 1-bit storage needed! 128, 135, 143, 154, 163, … 7, 8, 11, 9 à 1st difference is not constant 1, 3, -2 à 2nd difference is 2-bit storage needed! Unified support of fixed frequency times series or irregular frequency time series TS2Diff encoding – Optimized for timestamps Bitmap encoding – for enum-type values RLE encoding - for consecutively repeated values BitPacking encoding - for squeezing out wasteful bits when storing switch values Gorilla encoding
- 39. 高压缩与高吞吐 Raw data: - 12 Bytes per point - 112 GB totally
- 40. 高效查询
- 41. IoTDB典型应用：某地铁运维监控 … 144 列车 13台 KairosDB 13台 Cassandra 3200 测点/500 ms/列车 一台 IoTDB实例 300 列车 3200 测点/200 ms/列车 升级 更 少 硬 件 ， 更 高 性 能 144 列车 300 列车 500 毫秒采样 200 毫秒采样 13 台服务器 1 台服务器 仅1台IoTDB实现 日增4140亿 数据点管理
- 42. THANK YOU!