共计 9822 个字符，预计需要花费 25 分钟才能阅读完成。
摘要：为大家带来当下时序数据模型的支流 TSDB 剖析及云厂商在时序数据模型方面的最新动静。
本文分享自华为云社区《【万字干货】OpenMetric 与时序数据库存储模型剖析（下）》，作者：麻利的小智。
在上篇《【万字干货】OpenMetric 与时序数据库存储模型剖析（上）》文章中，咱们理解了时序数据模型的相干常识内容，接下来为大家剖析当下支流 TSDB 及云厂商在书序数据模型方面的最新动静。
支流 TSDB 剖析
InfluxDB
InfluxDB[9]是一个一站式的时序工具箱，包含了时序平台所需的所有：多租户时序数据库、UI 和仪表板工具、后盾解决和监控数据采集器。如下图 9 所示。
图 9
InfluxDB 反对动静 shcema，也就是在写入数据之前，不须要做 schema 定义。因而，用户能够随便增加 measurement、tag 和 field，能够是任意数量的列。
InfluxDB 底层的存储引擎经验了从 LevelDB 到 BlotDB，再到自研 TSM 的历程。从 v1.3 起，采纳的是基于自研的 WAL + TSMFile + TSIFile 计划，即所谓的 TSM（Time-Structured Merge Tree）引擎。其思维相似 LSM，针对时序数据的个性做了一些非凡优化。TSM 的设计指标一是解决 LevelDB 的文件句柄过多问题，二是解决 BoltDB 的写入性能问题。
Cache: TSM 的 Cache 与 LSM 的 MemoryTable 相似，其外部的数据为 WAL 中未长久化到 TSM File 的数据。若过程故障 failover，则缓存中的数据会依据 WAL 中的数据进行重建。
WAL (Write Ahead Log) : 时序数据写入内存之后依照 SeriesKey 进行组织。数据会先写入 WAL，再写入 memory-index 和 cache，最初刷盘，以保障数据完整性和可用性。根本流程包含：依据 Measurement 和 TagKV 拼接出乎 series key；查看该 series key 是否存在；如果存在，就间接将时序数据写入 WAL、时序数据写缓存；如果不存在，就会在 Index WAL 中写入一组 entry；根据 series key 所蕴含的因素在内存中构建倒排索引、接着把时序数据写入 WAL 和缓存。
TSM Files: TSM File 与 LSM 的 SSTable 相似。在文件系统层面，每一个 TSMFile 对应了一个 Shard，单个最大 2GB。一个 TSM File 中，有寄存时序数据（i.e Timestamp + Field value）的数据区，有寄存 Serieskey 和 Field Name 信息的索引区。基于 Serieskey + Fieldkey 构建的形似 B +tree 的文件内索引，通过它就能疾速定位到时序数据所在的数据块。在 TSMFile 中，索引块是依照 Serieskey + Fieldkey 排序 后组织在一起的。
TSI Files：用户如果没有按预期依据 Series key 来指定查问条件，比方指定了更加简单的查问条件，技术手段上通常是采纳倒排索引来确保它的查问性能的。因为用户的工夫线规模会变得很大，会造成倒排索引耗费过多的内存。对此 InfluxDB 引入了 TSIfiles。TSIFile 的整体存储机制与 TSMFile 类似，也是以 Shard 为单位生成一个 TSIFile。
在 InfluxDB 中有一个对标传统 RDB 的 Database 概念。逻辑上每个 Database 上面能够有多个 measurement。在单机版中每个 Database 理论对应了一个文件系统的目录。
InfluxDB 作为时序数据库，必然包含时序数据存储和一个用于度量、标记和字段元数据的倒排索引，以提供更疾速的多维查问。InfluxDB 在 TSMFile 上依照上面的步骤扫描数据，以取得高性能查问成果：
• 依据用户指定的工夫线（Serieskey）和 FieldKey 在索引区找到 Serieskey+FieldKey 所在的 索引数据块。
• 依据用户指定的工夫戳范畴在索引数据块中查找数据对应在哪个或哪几个索引条目
• 把检索出的索引条目所对应的时序数据块加载到内存中进一步扫描取得后果
和 Prometheus 一样，InfluxDB 数据模型有键值对作为标签，称为标签。InfluxDB 反对分辨率高达纳秒的工夫戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 反对 float64 数据类型，但对字符串和毫秒分辨率工夫戳的反对无限。InfluxDB 应用日志构造合并树的变体来存储带有预写日志，按工夫分片。这比 Prometheus 的每个工夫序列的仅附加文件办法更适宜事件记录。
Prometheus
下图是 Prometheus 官网架构图[10]，包含了一部分生态组件，它们大多是可选项。其中最外围的是 Prometheus 服务器，它负责抓取和存储工夫序列数据，并对这些数据利用规定，从而聚合出新的工夫序列或生成警报，并记录存储它们。
图 10
TSDB 是 Prometheus 的要害内核引擎。最新的 V3 引擎 [7] 相当于面向 TSDB 场景优化后的 LSM（Log Structured Merge Tree，结构化合并树）。LSM 树核心思想的外围就是放弃局部读能力，换取写入的最大化能力；其假如前提就是内存足够大。通常 LSM-tree 实用于索引插入比检索更频繁的利用零碎。V3 存储引擎也采纳了 Gorilla 论文思维。它包含了上面几个 TSDB 组件：块头（Head Block）、预写日志 WAL 及检查点、磁盘上 Chunk 头的内存映射、长久化 block 及其索引和查问模块。下图 11 是 Prometheus 的磁盘目录构造。
图 11
在 V3 引擎中一个 chunk 内会蕴含很多的工夫线（Time series）。Chunk 目录下的样本数据分组为一个或者多个段（segment），每个缺省不超过 512MB。index 是这个 block 下的 chunk 目录中的工夫线依照指标名称和标签进行索引，从而反对依据某个 label 疾速定位到工夫线以及数据所在的 chunk。meta.json 是一个简略的对于 block 数据和状态的一个形容文件。Chunks_head 负责对 chunk 索引，uint64 索引值由文件内偏移量（下 4 个字节）和段序列号（上 4 个字节）组成。
Prometheus 将数据按工夫维度切分为多个 block。只有最近的一个 block 容许接管新数据。最新的 block 要写入数据，会先写到一个内存构造中，为了保证数据不失落，会先写一份预写日志文件 WAL，按段（大小 128MB）存储在目录中。它们是未压缩的原始数据，因而文件大小显著大于惯例块文件。Prometheus 将保留三个或者多个 WAL 文件，以便保留至多两个小时的原始数据。
V3 引擎将 2 个小时作为块（block）的默认块持续时间；也就是块按 2h 跨度来宰割（这是个经验值）。V3 也是采纳了 LSM 一样的 compaction 策略来做查问优化，把小的 block 合并为大的 block。对于最新的还在写数据的 block，V3 引擎则会把所有的索引全副 hold 在内存，保护一个内存构造，等到该 block 敞开再长久化到文件。针对内存热数据查问，效率十分高。
Prometheus 官网再三强调了它的本地存储并不是为了长久的长期存储；内部解决方案提供缩短的保留工夫和数据持久性。社区有多种集成形式尝试解决这个问题。比方 Cassandra、DynamoDB 等。
通过指标实现利用的可察看性（observability）是 IT 监控运维零碎的第一步。指标提供汇总视图，再联合日志提供的无关每个申请或事件的明细信息。这样更容易帮忙问题的发现与诊断。
Prometheus 服务器彼此独立运行，仅依赖其本地存储来实现其外围性能：抓取、规定解决和警报。也就是说，它不是面向分布式集群的；或者说以后它的分布式集群能力是不够弱小的。社区的 Cortex、Thanos 等开源我的项目就是针对 Prometheus 的有余而涌现进去的胜利解决方案。
Druid
Druid[11]是有名的实时 OLAP 剖析引擎。Druid 的架构设计比拟简洁（如下图 12）。集群中节点分 3 类：Master 节点、Query 节点和 Data 节点。
图 12
Druid 数据存储在 datasource 中，相似于传统 RDBMS 中的表（table）。每个 datasource 都按工夫（其余属性也能够）分区（partition）。每个工夫范畴称为一个“块（Chunk）”（例如，一天，如果您的数据源按天分区）。在一个 Chunk 内，数据被分成一个或多个“段（Segment）”。每个段都是一个文件，通常蕴含多达几百万行数据。如下图 13 所示。
图 13
Segment 的目标在于生成紧凑且反对疾速查问的数据文件。这些数据在实时节点 MiddleManager 上产生，而且可变的且未提交的。在这个阶段，次要包含了列式存储、bitmap 索引、各种算法进行压缩等。这些 Segment（热数据）会被定期提交和公布；而后被写入到 DeepStorage（能够是本地磁盘、AWS 的 S3，华为云的 OBS 等）中。Druid 与 HBase 相似也采纳了 LSM 构造，数据先写入内存再 flush 到数据文件。Druid 编码是部分编码，是文件级别的。这样能够无效减小大数据汇合对内存的微小压力。这些 Segment 数据一方面被 MiddleManager 节点删除，一方面被历史节点（Historical）加载。与此同时，这些 Segment 的条目也被写入元数据（Metadata）存储。Segment 的自描述元数据包含了段的架构、其大小及其在深度存储中的地位等内容。这些元数据被协调器（Coordinator）用来进行查问路由的。
Druid 将其索引存储在按工夫分区的 Segment 文件中。Segment 文件大小举荐在 300MB-700MB 范畴内。Segment 文件的内部结构，它实质上是列存的：每一列的数据被安排在独自的数据结构中。通过独自存储每一列，Druid 能够通过仅扫描查问理论须要的那些列来缩小查问提早。共有三种根本列类型：工夫戳列、维度列和指标列，如下图 14 所示：
图 14
维度（Dimension）列须要反对过滤和分组操作，所以每个维度都须要以下三种数据结构：
1) 将值（始终被视为字符串）映射到整数 ID 的字典，
2) 列值的列表，应用 1 中的字典编码。【服务于 group by 和 TopN 查问】
3) 对于列中的每个不同值，一个批示哪些行蕴含该值的位图（实质就是倒排索引，inverted index）。【服务于疾速过滤，不便 AND 和 OR 运算】
Druid 中每列存储包含两局部：Jackson 序列化的 ColumnDescriptor 和该列的其余二进制文件。Druid 强烈推荐默认应用 LZ4 压缩字符串、long、float 和 double 列的值块，应用 Roaring 压缩字符串列和数字空值的位图。尤其在高基数列场景中匹配大量值的过滤器上 Roaring 压缩算法要快得多（比照 CONCISE 压缩算法）。
值得一提的是 Druid 反对 Kafka Indexing Service 插件（extension），实现实时摄入（ingestion）工作，那么此时能够立刻查问该 segment，只管该 segment 并没有公布（publish）。这更能满足对数据的产生到可查问可聚合剖析的实时性要求。
Druid 另外一个重要个性就是在数据写入的时候，能够开启 rollup 性能，将选定的所有 dimensions 依照你指定的最小工夫距离粒度（比方 1 分钟，或者 5 分钟等）进行聚合。这样能够极大的缩小须要存储的数据大小，毛病是原始的每条数据就被抛弃了，不能进行明细查问了。
Druid 为了让查问更高效，有如下设计思考。
• Broker 修剪每个查问拜访哪些 Segment：它是 Druid 限度每个查问必须扫描的数据量的重要形式。首先查问先进入 Broker，Broker 将辨认哪些段具备可能与该查问无关的数据。而后，Broker 将辨认哪些 Historian 和 MiddleManager 正在为这些段提供服务，并向这些过程中的每一个发送重写的子查问。Historical/MiddleManager 过程将接管查问、解决它们并返回后果。Broker 接管后果并将它们合并在一起以取得最终答案，并将其返回给原始调用者。
• Segment 内利用索引过滤：每个 Segment 内的索引构造容许 Druid 在查看任何数据行之前确定哪些（如果有）行与过滤器集匹配。
• Segment 内只读取特定关联的行和列：一旦 Druid 晓得哪些行与特定查问匹配，它只会拜访该查问所需的特定列。在这些列中，Druid 能够从一行跳到另一行，防止读取与查问过滤器不匹配的数据。
工夫戳也是 Druid 数据模型的必备项。只管 Druid 不是时序数据库，但它也是存储时序数据的自然选择。Druid 数据模型能够反对在同一个 datasource 中，能够同时寄存时序数据和非时序数据。因而，Druid 不认为数据点是“工夫序列”的一部分，而是将每个点独自解决以进行摄入和聚合。比方正统的 TSDB 反对的时序数据插值计算，在 Druid 中就不复存在的必要了。这会给一些业务场景的解决带来很大的便利性。
IoTDB
Apache IoTDB[12] 始于清华大学软件学院，2020 年 9 月为 Apache 孵化器我的项目。IoTDB 是一个用于治理大量工夫序列数据的数据库，它采纳了列式存储、数据编码、预计算和索引技术，具备类 SQL 的接口，可反对每秒每节点写入数百万数据点，能够秒级取得超过数万亿个数据点的查问后果。次要面向工业界的 IoT 场景。
IoTDB 套件由若干个组件形成，独特造成数据收集、数据摄入、数据存储、数据查问、数据可视化、数据分析等一系列性能。如下图 15 所示：
图 15
IoTDB 特指其中的工夫序列数据库引擎；其设计以设施、传感器为外围，为了方便管理和应用时序数据，减少了存储组（storage group 的概念）。
存储组(Storage Group): IoTDB 提出的概念，相似于关系数据库中的 Database 的概念。一个存储组中的所有实体的数据会存储在同一个文件夹下，不同存储组的实体数据会存储在磁盘的不同文件夹下，从而实现物理隔离。对 IoTDB 外部实现而言，存储组是一个并发管制和磁盘隔离的单位，多个存储组能够并行读写。对用户而言，不便了对设施数据的分组治理和方便使用。
设施 (Device)：对应事实世界中的具体物理设施，比方飞机发动机等。在 IoTDB 中, device 是时序数据一次写入的单位，一次写入申请局限在一个设施中。
传感器(Sensor): 对应事实世界中的具体物理设施本身携带的传感器，例如：风力发电机设施上的风速、转向角、发电量等信息采集的传感器。在 IoTDB 中，Sensor 也称为测点（Measurement）。
测点 / 物理量（Measurement，也称工况、字段 field）：一元或多元物理量，是在理论场景中传感器采集的某时刻的测量数值，在 IoTDB 外部采纳 <time, value> 的模式进行列式存储。IoTDB 存储的所有数据及门路，都是以测点为单位进行组织。测量还能够蕴含多个重量（SubMeasurement），比方 GPS 是一个多元物理量，蕴含 3 个重量：经度、维度、海拔。多元测点通常被同时采集，共享工夫列。
IoTDB 的存储由不同的存储组形成。每个存储组是一个并发管制和资源隔离单位。每个存储组外面包含了多个 Time Partition。其中，每个存储组对应一个 WAL 预写日志文件和 TsFile 时序数据存储文件。每个 Time Partition 中的时序数据先写入 Memtable，同时记入 WAL，定时异步刷盘到 TsFile。这就是所谓的 tLSM 时序解决算法。
摄入性能方面：IoTDB 具备最小的写入提早。批处理大小越大，IoTDB 的写入吞吐量就越高。这表明 IoTDB 最适宜批处理数据写入计划。在高并发计划中，IoTDB 也能够放弃吞吐量的稳定增长（受网卡、网络带宽束缚）。
聚合查问性能方面：在原始数据查问中，随着查问范畴的扩充，IoTDB 的劣势开始浮现。因为数据块的粒度更大，列式存储的劣势体现进去，所以基于列的压缩和列迭代器都将减速查问。在聚合查问中，IoTDB 应用文件层的统计信息并缓存统计信息。多个查问只须要执行内存计算，聚合性能劣势显著。
数据存储比照
基于后面的剖析，咱们尝试用上面的表格比照来阐明这些时序数据处理系统的特点。
表 3
对于时序数据的解决，要害能力次要包含数据模型定义、存储引擎、与存储严密合作的查问引擎和反对分区扩大的架构设计。支流的 TSDB 根本都是基于 LSM 或者联合时序数据场景专门优化的 LSM tree 来实现（包含 InfluxDB 号称的 TSM，IoTDB 的 tLSM，实质上都还是 LSM 机制）。其中只有 IoTDB 独创采纳了 tree schema 来对时序数据建模。为了谋求极致性能和极致老本，大家都在针对海量数据和应用场景，继续改良和优化数据的存储结构设计、各种高效索引机制、和查问效率。从单点技术或者关键技术上来讲，有趋同性和同质化的大趋势。
云厂商最新动静
除了开源社区新陈代谢外，国内外泛滥云服务厂商也陆续公布了相干的时序数据库产品或者服务。
华为云
华为云的 GaussDB for Influx[13]云服务，基于 InfluxDB 进行深度优化革新，在架构、性能和数据压缩等方面进行了技术创新，获得了很好的成果。实现了存储与计算拆散架构，其中采纳了华为云自研的高性能分布式存储系统，显著晋升了时序数据库的可靠性；同时不便计算节点分钟级扩容和存储空间的秒级扩容，同时大幅升高存储老本。反对亿级工夫线（开源的能力在千万工夫线级别），写入性能根本保持稳定；可能反对更高的高散列聚合查问性能；在压缩算法上，相比原生的 InfluxDB，重点针对 Float、String、Timestamp 这三种数据类型进行了优化和改良。。
华为云 MRS 云服务蕴含了 IoTDB[14]，其中 IoTDB 定位为面向工业设施、工业现场的时序数据库库。IoTDB 优化后性能更好，千万级数据点秒级写入，TB 级数据毫秒级查问；优化后的数据压缩比可达百倍，进一步节俭存储空间和老本；通过采纳对等分布式架构，双层多 Raft 协定，边云节点同步双活，做到 7 *24 小时高可用。在工业化场景，真正做到一份时序数据兼容全场景、一套时序引擎买通云边端和一套框架集成云边端。
阿里云
据公开材料[15]，阿里云时序时空数据库 TSDB 的倒退演变经验了三个阶段。在 v1.0 阶段基于 OpenTSDB，底层实现了双引擎——HBase 和 HiStore。在 v2.0 阶段中，把 OpenTSDB 引擎换成了自研的 TSDB 引擎，补救了 OpenTSDB 不反对的倒排索引、面向时序场景的非凡编码、分布式流计算聚合函数等个性。随后实现了云和边缘计算一体化，TSQL 兼容 Prometheus 生态。其中 TSDB for Spatial Temporal 反对时空数据，它基于自研的 S3 时空索引和高性能电子围栏。最新 TSDB 同样基于 Gorilla, 将单个数据点的均匀应用存储空间降为 1~2 个字节，能够升高 90% 存储应用空间，同时放慢数据写入的速度。对于百万数据点的读取，响应工夫小于 5 秒，且最高能够撑持每秒千万数据点的写入。相较于开源的 OpenTSDB 和 InfluxDB，读写效率晋升了数倍，同时兼容 OpenTSDB 数据拜访协定。
腾讯云
腾讯云也推出了 TencentDB for CTSDB[16]云服务，它是一款分布式、可扩大、反对近实时数据搜寻与剖析的时序数据库，兼容 Elasticsearch 罕用的 API 接口和生态。它撑持了腾讯外部 20 多个外围业务。性能方面能够做到每秒千万级数据点写入，亿级数据秒级剖析。CTSDB 也是采纳 LSM 机制，先写内存再周期性刷写到存储；而后通过倒排索引减速任意维度数据查问，能实现数据秒级可查。也反对像 histogram、percentile、cardinality 这样的通用聚合计算函数；也通过配置 Rollup 工作定时聚合历史数据保留至新的数据表，实现降精度（Downsampling）个性。在集群中节点数量超过 30 个时，须要新购集群或者将通用集群架构优化降级为混合节点集群架构，以保障多节点超大集群的性能稳固。从这些个性推断，CTSDB 内核应该是借鉴了 ElasticSearch 内核深度优化教训的根底上构建的时序数据库能力。
国内其余厂商
除了云服务厂商提供的开箱即用的云服务外，还有一些创新型产品涌现进去，比拟有名的包含 TDengine[17]、字节跳动的 TerarkDB[18]、DolphinDB[19]等等。他们也在疾速演进倒退中，值得大家继续跟踪关注，尤其是国内孵化进去的一些 TSDB 产品。
总结与瞻望
InfluxDB、IoTDB 和 OpenTSDB 等除了社区版本外，也有云厂商提供原生 InfluxDB（阿里云 TSDB for InfluxDB）、IoTDB（华为云 MRS IoTDB）或 OpenTSDB（华为云 MRS OpenTSDB）云化服务，方便使用。更支流的做法是各云厂商依据本身的技术积淀和研发实力，借鉴、优化甚至从新研发了时序数据库内核，能提供更强的集群能力，更高性能写入，更快的查问和聚合剖析能力。国外厂商 AWS 有 Timestream[20]，一种 Serverless 时序数据库服务，国内华为云的 GaussDB for Influx，汇聚顶级数据库专家团队打造的新一代时空剖析数据库；腾讯云的 TencentDB for CTSDB，兼容 ES 生态；阿里云的 HiTSDB 等等。这些开箱即用的、可扩大的、高可用的时序数据库，为云原生利用的开发与部署带来了福音，无需治理底层基础设施，只需专一于业务构建。
Promeheus 倒退过程中，其须要长期保留的历史数据（long-term）存储是其短板之一。业界有一些折中的集成计划。比方采纳 Cassandra 作为 Prometheus 的长久化存储；还有采纳 InfluxDB 作为 Prometheus 的长久化存储，一方面充分利用 Prometheus 监控相干能力和社区生态（包含反对分布式集群的 Cortex）；另一方面利用好 InfluxDB 时序数据库长处，尤其是超 PB 级的分布式数据库能力，以补救 Prometheus 在海量历史数据存储上的短板。
Apache Druid 在 OLAP 即时剖析畛域有着很强的竞争力，也为泛滥大厂所采纳。业界最大的集群领有 4000 多个节点。不论是时序指标，还是业务数据，利用日志等，都能够利用 Druid 的 Kafka Indexing Service 和其弱小的数据预处理能力，转换为时序数据进入 Druid。目前 Druid SQL 个性倒退也很快，包含跨表 join，subquery 和泛滥函数、算子的继续丰盛。
不论是正统的时序数据库，还是适宜时序数据的 OLAP 剖析零碎；不论是开源社区的热门我的项目，还是云厂商提供更弱小的云原生时序数据库，都为各种时序数据（包含指标、业务数据）的存储、检索和剖析提供多样化的抉择。用户联合本人的业务场景，肯定能找到绝对适宜的工具或服务，满足业务诉求。
参考资料
[9] https://www.influxdata.com/pr…
[10] https://prometheus.io/docs/in…
[11] https://druid.apache.org/docs…
[12] https://iotdb.apache.org/Syst…
[13] https://bbs.huaweicloud.com/b…
[14] https://bbs.huaweicloud.com/b…
[15] https://developer.aliyun.com/…
[16] https://cloud.tencent.com/dev…
[17] https://www.taosdata.com/cn/
[18] https://github.com/bytedance/…
[19] https://www.dolphindb.cn/
[20] https://aws.amazon.com/cn/tim…
点击关注，第一工夫理解华为云陈腐技术~