这篇文章详细介绍了时序数据的概述，并解释了时序数据库引擎的存储和计算能力。

这本书是周肇峰写的。

時序数据是指一系列按照时间顺序排列的数据。

時系列資料是一組根據時間索引的資料。簡單來說，這類型的資料描述了在時間範圍內的每個時間點上測量的受試者測量值。

模型化时序数据包含三个重要的部分。当应用这个模型时，您会发现在日常工作和生活中经常接触到这种类型的数据。

• あなたが株主であれば、株式の株価は時系列データの一種です。これは、各時点での株価を記録しています。

 

あなたがO&M担当者であれば、監視データは時系列データの一種です。例えば、ＣＰＵの監視データは、各時点でのＣＰＵの実際の使用状況を記録します。

世界由数据构成，世界上的一切都在不断产生数据。这种对数据的利用和榨取，悄然改变着当今人们的生活方式。例如，可穿戴设备的个人健康管理功能的核心是持续收集个人的健康数据。这些数据包括心率和体温等。收集这些数据后，设备将使用模型计算和评估您的健康状况。

如果你能夠自由地擴展你的視野和想像力，你會意識到在日常生活中所有的數據都可以被濫用和利用。能夠生成數據的對象包括手機、汽車、空調、冰箱等等。眼下為人熱議的物聯網（IoT）技術的核心理念是收集來自各種對象的數據，並建立一個能夠剝取這些數據價值的網絡。在這個網絡中收集到的數據是典型的時間序列數據。

时序数据是用于描述目标物体状态变化信息的一种数据类型，它通过过去的时间维度进行描述。时序数据分析是一种试图理解和掌握变化规律的过程。随着物联网、大数据和人工智能技术的发展，时序数据经历了爆炸式的增长。为了更好地支持此类数据的存储和分析，出现了各种数据库产品并流通到市场上。这些数据库产品的发明旨在解决传统关系型数据库在时序数据存储和分析方面的缺点和问题。这些产品统称为时序数据库（TSDB）。

根据DB-Engines数据库管理系统的受欢迎程度排名，可见TSDB在过去两年中保持了高增长率。

我希望在未来几天里撰写一些文章并进行分析。

1、包括了模型、特征、基本查询和处理操作的时序数据的基本概念。
2、对一些流行的开源TSDB实现的分析。

时序数据的特点

我們將從數據寫入、查詢和存儲這三個維度來解釋時序數據的特性分析。通過分析這些特性，我們可以了解時序數據庫的基本要求。

数据的编写特点

• スムーズな連続性、高同時性、高スループットのデータ書き込みが可能です。時系列データの書き込みは、アプリケーションデータとは異なり、比較的安定しています。アプリケーションデータは、通常、アプリケーションのページビューに比例して、ピークとバレーがあります。時系列データは、通常、一定の時間頻度で生成され、他の要因に制約されません。データ生成速度は比較的安定しています。時系列データは、個々のオブジェクトごとに独立して生成されます。個別オブジェクトの数が多いと、特にIoTシナリオでは、データの書き込み同時実行性やスループットが相対的に高くなってしまいます。書き込みの同時性とスループットは、単純に個別オブジェクトの数とデータ生成の頻度で計算することができます。例えば、10秒ごとにデータを生成するオブジェクトが1000個あれば、1秒ごとの書き込み同時実行性とスループットは100になります。

 

• 読み取りよりも書き込みの方が多いです。時系列データに対する操作の95～99％は書き込みです。これはデータの特性によって決まります。モニタリングデータを例にとると、多くのモニタリング項目があるかもしれませんが、そのうちのいくつかの項目にしか関心を持っていません。通常は、いくつかの重要なメトリクスのデータだけを読み込んだり、特定のケースだけを読み込んだりします。

 

最新のデータはリアルタイムで生成され、更新されることはありません。時系列データはリアルタイムで書き込まれ、その都度書き込まれるデータが最新のデータとなります。これは、このようなデータは時間をかけて生成され、リアルタイムで新しいデータが書き込まれるため、データ生成特性によって決定されます。データは書き込まれても更新されません。時間次元では、時間が経過するにつれて、書き込まれたデータはすべて新しいものとなります。既存のデータは、手動での修正を除いて更新されません。

数据查询与分析的特点 de hé de

• データは期間ごとに読み込まれます。一般的には、特定の時点のデータではなく、ある期間のデータが必要になります。そのため、時系列データは基本的に時間範囲で読み込まれます。

 

• 最近のデータほど読まれる可能性が高く、最近のデータであればあるほど、データの読み込み可能性は高くなります。モニタリングデータを例にとると、1ヶ月前や1年前に何が起こったかよりも、ここ数時間やここ数日に何が起こったかにしか興味がないのが普通です。

 

• 多精度クエリ:時系列データの精度は、データ点の密度によって区別されます。例えば、隣接する2つのデータ点間の時間間隔が10秒の場合、時系列データの精度は10秒となります。また、時間間隔が３０秒であれば、精度は３０秒になります。時間間隔が短いほど精度は高くなります。精度が高ければ高いほど、復元された歴史的状態をより詳細かつ正確に把握することができます。しかし、精度が高いということは、保存するデータポイントが増えるということでもあります。これは、写真の解像度と非常によく似ています。解像度が高ければ高いほど画像が鮮明になり、ファイルサイズも大きくなります。時系列データの問い合わせは、必ずしも高い精度が必要なわけではありません。クエリの精度は、実際のニーズとコストによって共同で決定されます。繰り返しになりますが、モニタリングデータを例に考えてみましょう。通常、モニタリングデータは折れ線グラフの形で表示され、データの変化を自分の目で観察することができます。この場合、単位長で表示するデータポイントが密集しすぎると、観察するのに不便になってしまうのが実際のニーズです。もう一つのトレードオフは、1ヶ月などのより長い時間範囲でクエリを行う場合、精度を10秒に設定した場合、クエリは259,200データポイントを返さなければならないということです。精度を60秒に設定した場合、クエリは43,200個のデータポイントを返すだけで済みます。これがクエリの効率性を定義しています。コスト面では、精度が高ければ高いほど、保存するデータ量が多くなり、コストが高くなります。一般的に、過去のデータについては、高精度は必要ありません。データの問い合わせや処理の面では、一般的にデータの精度は時間範囲の長さで決まります。ヒストリカルデータの保存という点では、通常はダウンサンプリングされたデータを利用することになります。

 

• 多次元分析:時系列データは、異なる属性を持つ異なる個々のオブジェクトから生成されます。そのような属性は、同じ次元のものであっても、そうでないものであっても良いです。ここでも、モニタリングデータを例にしてみましょう。クラスタ内の各マシンのネットワーク・トラフィックを監視するとき、特定のマシンのネットワーク・トラフィックを問い合わせることができます。これは、1 つのディメンジョンのデータ・クエリとみなすことができます。クラスタ全体のネットワーク・トラフィックを照会すると、別の次元のデータ照会になります。

 

データマイニング:ビッグデータや人工知能技術の発展により、データストレージ、コンピューティングリソース、クラウドコンピューティングが高度に発達しているため、付加価値の高いデータマイニングの敷居はそれほど高くなくなっています。時系列データには高い価値が含まれており、活用する価値があります。

数据存储的特点

• 大量のデータ:モニタリングデータを例に考えてみましょう。収集した監視データの時間間隔を1秒とすると、1つの監視項目で毎日86,400点のデータが生成されます。この数字は、10,000個の監視項目がある場合、単純に足し算すると864,000,000個になります。IoTシナリオでは、この数字はさらに大きくなります。データサイズはTBやPBで計測されることがあります。

 

• コールドデータとホットデータの分離: 時系列データは、非常に典型的なホットとコールドの特性を持っています。データが古くなればなるほど、クエリや分析の対象になりにくくなります。

 

• タイムリー性:時系列データは時間に敏感です。TSDBには通常、保存期間があります。この保持ウィンドウを超えたデータは非アクティブとみなされ、安全に削除することができます。それは、古いデータは通常あまり価値がないので、価値の低いデータを削除することでストレージコストを節約しなければならないからです。

 

多精度データの保存: 前述したように、時系列データの保存コストと問い合わせ効率を考慮すると、多精度の問い合わせが必要です。実際には、多精度データ保存も必要になります。

时序数据库（TSDB）的基本要求

根据对上述时间序列数据的特征进行从数据写入、查询和保存的角度分析的结果，总结出了时序数据库（TSDB）所需的基本要求，如下所示。

• 同時性が高く、スループットの高い書き込みに対応できること:前述したように、時系列データは読み込みよりも書き込みの方が多く、操作の95～99％が書き込みです。そのため、TSDBの書き込み能力に注目する必要があります。ほとんどの場合、TSDBは高連続性と高スループットのデータ書き込みをサポートしなければなりません。

 

• インタラクティブな集約クエリ:インタラクティブなクエリのレイテンシは、クエリされたデータが膨大なサイズ（TB単位で測定）であっても、非常に低くなければなりません。

 

• 大量のデータを保存できること:データサイズはシナリオの特性によって決まります。ほとんどの場合、時系列データはTB、さらにはPBで計測されます。

 

• 高可用性:オンラインサービスは通常、高い可用性が要求されます。

 

分散アーキテクチャ:データの書き込みとストレージの要件を考慮すると、基礎となる層は分散アーキテクチャでなければなりません。

根据对时间序列数据特性和TSDB基本要求的分析，发现使用基于LSM树的存储引擎（如HBase、Cassandra、阿里云表格存储等）的NoSQL数据库与使用基于B+树的关系型数据库管理系统（RDBMS）相比具有重大优势。不在此描述LSM树的基本理论。LSM树被设计用于优化写入性能。基于LSM树的TSDB的写入性能比基于B+树的TSDB高出十倍以上。然而，读取性能要远远低于基于B+树的TSDB。因此，基于LSM树的TSDB特别适用于写入操作较多的场景。目前，一些知名的开源TSDB中，OpenTSDB使用HBase作为基础存储引擎，BlueFlood和KairosDB使用Cassandra，InfluxDB使用类似LSM的自家研发的TSM存储引擎，而Prometheus则直接使用基于LevelDB的存储引擎。可以看出，主流的TSDB都使用了基于LSM树的分布式架构作为基础存储。区别在于，有些产品直接使用现有成熟的数据库，而另一些产品则使用了自家研发的数据库或基于LevelDB的数据库。

LSM-tree基于分布式架构，可以轻松满足时序数据的写入需求，但在数据查询方面略显不足。这些数据库可以满足少量数据的多维度集合查询需求。然而，在不具备索引的大量数据的多维度集合查询中，其性能稍显逊色。因此，在开源世界中，还存在着其他专注于解决这类查询和分析问题的产品。例如，Druid主要专注于解决时序数据的OLAP需求，使得能够在没有预聚合的情况下快速查询和分析大量数据。同时，也支持在任意维度上进行钻取。此外，我们的社区还提供了基于ElasticSearch的解决方案，面向分析场景。

总之，多样化的TSDB各自都有其优点和缺点。并没有适用于所有情景的最佳解决方案。只能选择最适合服务需求的方案。

时间序列数据模型

时间序列数据的数据模型主要由以下部分构成。

• 被験者（Subject）:測定される主題。被測定体は、複数の次元を持つ属性を持つことができます。サーバの状態監視を例にとると、測定対象はサーバであり、その属性にはクラスタ名、ホスト名などが含まれます。

 

• 測定値:被測定体は、特定のメトリックに対応する1つまたは複数の測定値を持つことができます。サーバーステータス監視の場合、測定されたメトリックにはCPU使用率とIOPSが含まれる場合があります。ＣＰＵ使用率の値はパーセンテージであり、ＩＯＰＳの値は測定期間中のＩ／Ｏの数です。

 

• タイムスタンプ:測定レポートには、時刻を示すタイムスタンプ属性が必ず添付されています。

 

現在主流のTSDBでは、データソースによるモデリングとメトリクスによるモデリングの2つのモデリング方法を使用しています。この2つの方法の違いを2つの例を使って説明します。

基于数据源的建模

以上是使用数据源进行建模的示例。在某个时间点上，同一数据源的所有指标的测量值都存储在同一行中。这个模型在Druid和InfluxDB中使用。

基于指标的建模

这个示例是基于指标建模的，每一行数据表示某个时间点上数据源中某个指标的测量值。这种模式在OpenTSDB和KairosDB中被使用。

这两种模型之间没有明显的区别。基础的层次架构采用了列式存储，并且如果每个列都有索引，那么采用数据源建模可能会更好。如果基础的层次架构类似于HBase或Cassandra，将多个度量值存储在同一行中可能会对某个度量的查询和过滤效率产生影响。因此，通常会选择为每个度量逐个建模。

时间序列数据的处理

在这里，我们主要讲解时间序列数据的处理。TSDB中，除了基本的数据写入和保存，查询和分析是最重要的功能。时间序列数据的处理主要包括过滤、聚合、分组和降采样。为了更好地支持分组查询，一些TSDB会预先对数据进行聚合。降采样是通过滚动更新进行的。为了支持更快速和实时的滚动更新，TSDB通常支持自动滚动更新。

过滤

以上是一个简单的过滤处理。简单来说，它对满足给定条件的所有数据进行查询，这些条件可能有不同的维度。在时序数据分析的场景中，过滤通常从高维度开始，然后根据更详细的维度条件执行更详细的查询和数据处理。

统计

汇总是时序数据查询和分析的最基本功能。时序数据记录着原始状态的变化信息。然而，在进行时序数据查询和分析时，通常不需要原始信息，相反需要基于原始信息的统计量。汇总包括一些基本的统计计算。最常见的计算有SUM、AVG、Max和TopN。例如，分析服务器流量时，我们会关注平均流量、总流量或高峰时的流量。

按GroupBy进行预汇总。

GroupBy是一种将低维时间序列数据转换为高维统计量的处理方式。上述是GroupBy的简单示例。GroupBy通常在查询中执行。在查询原始数据之后，通过实时计算获取结果。该处理过程可能非常耗时，取决于最初查询的数据量。主流的TSDB通过预聚合优化此过程。在实时写入数据后，进行预聚合以根据给定规则生成GroupBy后的结果。这样，您可以直接查询结果而无需重新计算。

降低采样、卷起、自动卷起

下采样是将高分辨率的时序数据转换为低分辨率的时序数据的处理过程。这个过程被称为Rollup。与GroupBy类似，但它们有所不同。GroupBy是根据相同的时间粒度，在不同的维度上聚合数据到相同的时间层级。转换后的数据的时间粒度不变，但维度增加。下采样是在不同的时间层级上聚合具有相同维度的数据。转换后的数据的时间粒度变粗，但维度不变。

这是一个简单的例子，将10秒分辨率的数据聚合到30秒分辨率的数据中，并求取统计平均值。

在中文中，下采样可以分为存储下采样和查询下采样。存储下采样旨在减少数据（尤其是历史数据）的存储成本。查询下采样主要用于范围广泛的查询，以减少返回的数据点。存储下采样和查询下采样都需要自动卷帘（autoroollup）功能。自动卷帘会自动进行数据卷帘而不是等待查询。类似于预聚合（preaggregation），这种处理可以有效地提高查询效率。此外，自动卷帘也是目前主流的时间序列数据库（TSDB）所设计或计划实现的功能。目前，Druid、InfluxDB和KairosDB支持自动卷帘。OpenTSDB不支持自动卷帘，但提供了支持导入经过外部自动卷帘处理后的结果的API。

总结

本篇文章主要分析了时序数据的特点、模型以及基本的查询和处理操作，并明确了TSDB的基本要求。下一篇文章将分析一些受欢迎的开源TSDB的实现。虽然存在许多TSDB，但您可能会注意到它们的基本功能相似。虽然每个TSDB都有其特点和实现方式，但它们都是基于时序数据的写入、存储、查询和分析等维度的权衡设计的。不存在适用于解决所有潜在问题的万能TSDB。从业务角度选择最佳TSDB非常重要。

此博客是从英语版翻译而来的。您可以在此处查看原始版本。我们部分使用了机器翻译。如有翻译错误，请您指出，不胜感激。

阿里巴巴云拥有两个数据中心在日本，并拥有超过60个可用区域，是亚太地区第一的云基础设施提供商（根据2019年的Gartner报告）。
更多有关阿里巴巴云的详细信息，请点击此处查看。
阿里巴巴云日本官方网页。