データモデリング

Amazon Timestream for LiveAnalytics は、タイムスタンプ付きの一連のデータを出力するアプリケーションやデバイスから、時系列データを収集、保存、分析するように設計されています。最適なパフォーマンスを実現するには、Timestream for LiveAnalytics に送信されるデータに時間特性が必要であり、時間はデータの本質的要素でなければなりません。

Timestream for LiveAnalytics では、アプリケーションの要件に合わせてさまざまな方法で柔軟にデータをモデリングできます。このセクションでは、こうしたパターンのいくつかを取り上げ、コストとパフォーマンスを最適化するための指針について説明します。ディメンションやメジャーなど、主要な Amazon Timestream for LiveAnalytics の概念を理解します。このセクションでは、データを保存するために単一のテーブルを作成するか複数のテーブルを作成するかを決める際の、以下の問題について詳しく解説します。

単一テーブルとマルチテーブル

アプリケーションでデータをモデリングする際の重要な要素には、データをテーブルとデータベースにモデリングする方法もあります。Timestream for LiveAnalytics のデータベースとテーブルはアクセス制御の抽象化であり、KMS キーや保持期間などを指定します。Timestream for LiveAnalytics は、データを自動的にパーティショニングし、アプリケーションの取り込み、保存、クエリ負荷、要件に合わせてリソースをスケールするように設計されています。

Timestream for LiveAnalytics のテーブルは、保存済みのペタバイト規模のデータ、および 1 秒あたり数十ギガバイトのデータ書き込みにスケールできます。クエリは 1 時間あたり数百テラバイトを処理できます。Timestream for LiveAnalytics のクエリは複数のテーブルとデータベースにまたがることができ、結合とユニオンを提供して複数のテーブルとデータベースのデータにシームレスにアクセスすることを可能にします。したがって通常は、Timestream for LiveAnalytics でデータを整理する方法を決める際に、データまたはリクエストボリュームのスケールを最優先する必要はありません。以下は、異なるテーブル、または異なるデータベースにあるテーブルを使用する場合と比較して、同じテーブルにどのデータを一緒に入れるかを決める際に考慮すべき重要な点です。

マルチメジャーレコードと単一メジャーレコード

Timestream for LiveAnalytics では、レコードごとに複数のメジャーを書き込む (マルチメジャー) か 1 つのメジャーを書き込む (単一メジャー) ことができます。

マルチメジャーレコード

多くの場合、追跡しているデバイスまたはアプリケーションは、複数のメトリクスまたはイベントを同じタイムスタンプで出力します。このような場合、同じタイムスタンプで出力されたすべてのメトリクスは、同じマルチメジャーレコードに保存できます。つまり、同じマルチメジャーレコードに保存されているすべてのメジャーは、同じデータ行内の異なる列として表示されます。

アプリケーションが、同時に測定されたデバイスから cpu、memory、disk_iops などのメトリクスを出力しているケースを考えてみましょう。以下は、同時に出力された複数のメトリクスが同じ行に保存されているテーブルの例です。2 つのホストが、1 秒に 1 回、メトリクスを出力していることがわかります。

単一メジャーレコード

単一メジャーレコードは、デバイスが異なる期間に異なるメトリクスを出力する場合や、異なる期間にメトリクス/イベントを出力するカスタムの処理ロジックを使用している場合 (デバイスの測定値/状態が変化した場合など) に適しています。各メジャーはそれぞれ異なるタイムスタンプを持っているため、Timestream for LiveAnalytics にある各自のレコードに保存することができます。例えば、土壌の温度と湿度を追跡している IoT センサーの例を考えてみます。この IoT センサーは、以前に報告されたエントリからの変更を検出した場合にのみ、レコードを出力します。以下は、単一メジャーレコードを使用して出力されるデータの例を示したものです。

単一メジャーレコードとマルチメジャーレコードの比較

Timestream for LiveAnalytics を使用すると、アプリケーションの要件と特性に応じて、データを単一メジャーレコードまたはマルチメジャーレコードとして臨機応変にモデリングできます。単一のテーブルに、アプリケーションの要件に応じて、単一メジャーレコードとマルチメジャーレコードの両方を保存できます。一般的に、アプリケーションが複数のメジャー/イベントを同時に出力する場合は、パフォーマンスの高いデータアクセスと費用対効果の高いデータストレージのため、データをマルチメジャーレコードとしてモデリングすることが推奨されます。

例えば、数十万台のサーバーのメトリクスとイベントを追跡する DevOps のユースケースを考えてみましょう。各サーバーは定期的に 20 のメトリクスと 5 つのイベントを出力し、これらのイベントとメトリクスは同時に出力されます。このデータは、単一メジャーレコードまたはマルチメジャーレコードを使用してモデリングできます (結果のスキーマについてはオープンソースのデータジェネレーターを参照してください)。このユースケースでは、マルチメジャーレコードと単一メジャーレコードを使用してデータをモデリングした場合、以下のような結果になります。

上記の要因は、追跡するメトリクスの数やデータに含まれるディメンションの数などによって変わってきます。前述の例では 1 つの例に対して複数の具体的なデータを示していますが、多くのアプリケーションシナリオおよびユースケースにおいて、アプリケーションが同時に複数のメジャーを出力する場合、マルチメジャーレコードとしてデータを保存する方が効果的であることが示されています。さらに、マルチメジャーレコードにはデータ型を選択したり他の複数の値をコンテキストとして保存したりできる柔軟性があります (リクエスト ID の保存や追加のタイムスタンプなど。詳細は後述)。

マルチメジャーレコードでは、前述の単一メジャーレコードの例で示したような少量のメジャーをモデリングすることもできます。measure_name を使用してメジャーの名前を保存したり、汎用のマルチメジャー属性名 (DOUBLE メジャー保存用の value_double、BIGINT メジャー保存用の value_bigint、追加の TIMESTAMP 値の保存用の value_timestamp など) を使用したりできます。

ディメンションとメジャー

Timestream for LiveAnalytics のテーブルでは、ディメンション (保存しているデバイス/データの属性を識別する) とメジャー (追跡しているメトリクス/値) を保存できます。詳細については、「Amazon Timestream for LiveAnalytics の概念」を参照してください。Timestream for LiveAnalytics でアプリケーションをモデリングする場合、データをディメンションとメジャーにマッピングする方法は、取り込みとクエリのレイテンシーに影響します。以下は、データをディメンションおよびメジャーとしてモデリングする方法に関するガイドラインです。お使いのユースケースに応用できます。

ディメンションの選択

時系列データを送信しているソースを識別するデータは、時間が経過しても変化しない属性であるディメンションにぴったりです。例えば、メトリクスを出力するサーバーを使用している場合、サーバーを識別する属性 (ホスト名、リージョン、ラック、アベイラビリティーゾーンなど) がディメンションの候補になります。同様に、時系列データを報告する複数のセンサーを持つ IoT デバイスの場合、デバイス ID やセンサー ID などの属性がディメンションの候補になります。

データをマルチメジャーレコードとして書き込む場合、ディメンションとマルチメジャー属性は、テーブルで DESCRIBE を実行するか、SELECT ステートメントを実行すると、テーブルに列として表示されます。したがって、クエリを記述するときは、ディメンションとメジャーを同じクエリで自由に使用できます。ただし、データを取り込むための書き込みレコードを作成するときは、どの属性をディメンションとして指定し、どの属性をメジャー値として指定するかを選択する際に、次の点に注意する必要があります。

Timestream for LiveAnalytics のテーブルでは、ディメンションの名前と値からなる一意の組み合わせの数に制限がないことに注意してください。例えば、上記のような一意の値の組み合わせを単一のテーブルに数十億件保存することが可能です。ただし、次の例に示すように、ディメンションとメジャーを慎重に選択すれば、特にクエリの場合は、リクエストのレイテンシーを大幅に最適化することができます。

ディメンション内の一意の ID

アプリケーションのシナリオで、すべてのデータポイントに一意の識別子を保存する必要がある場合 (リクエスト ID、トランザクション ID、相関 ID など)、ID 属性をメジャー値としてモデリングすると、クエリのレイテンシーを大幅に改善できます。マルチメジャーレコードを使用してデータをモデリングする場合、ID は他のディメンションおよび時系列データとの関係に応じて同じ行に表示されるため、クエリでそれらを引き続き効果的に使用することができます。例えば、サーバーが出力するすべてのデータポイントに一意のリクエスト ID 属性がある DevOps のユースケースでは、リクエスト ID をメジャー値としてモデリングすると、一意のリクエスト ID をディメンションとしてモデリングする場合に比べて、異なるクエリタイプ間でのクエリのレイテンシーは、最大で 4 分の 1 まで減少します。

すべてのデータポイントで完全に一意ではないものの数十万から数百万の一意の値を持つ属性についても、同様の例で説明できます。これらの属性は共に、ディメンションまたはメジャー値としてモデリングできます。前述したように、書き込みパスでの重複排除に値が必要である場合、またはクエリで値を頻繁に述語として使用する場合 (アプリケーションを使って数百万台のデバイスを追跡している device_id = 'abcde' など、その属性の値に関する等価述語を含む WHERE 句などで) は、ディメンションとしてモデリングする必要があります。

マルチメジャーレコードを持つデータ型のリッチさ

マルチメジャーレコードは柔軟性が高く、データを効果的にモデリングすることができます。マルチメジャーレコードに保存されデータは、ディメンションと同様にテーブルに列として表示されるため、ディメンション値とメジャー値のクエリを同様の容易さで行うことができます。これらのパターンの一部は、前述の例で既に紹介しました。以下は、アプリケーションのユースケースに合わせてマルチメジャーレコードを効果的に使用するための他のパターンです。

マルチメジャーレコードは、データ型 DOUBLE、BIGINT、VARCHAR、BOOLEAN、TIMESTAMP の属性をサポートしています。したがって、さまざまな型の属性に自然に適合します。

特に、クエリで述語を使用している数値データまたはタイムスタンプがある場合、それらの属性をディメンションではなくマルチメジャー属性としてモデリングすると、クエリのレイテンシーが低下します。これは、マルチメジャーレコードでサポートされているリッチなデータ型を使用してデータをモデリングするときに、データをディメンションとしてモデリングして VARCHAR から別のデータ型に値をキャストするのではなく、ネイティブなデータ型を使って述語を表現できるためです。

マルチメジャーレコードを用いたメジャー名の使用

Timestream for LiveAnalytics のテーブルは、メジャー名と呼ばれる特別な属性 (または列) をサポートしています。この属性の値は、Timestream for LiveAnalytics にレコードを書き込むたびに指定します。単一メジャーレコードの場合、メトリクスの名前 (サーバーメトリクスでは CPU や memory、センサーメトリクスでは temperature や pressure など) を使用するのが自然です。マルチメジャーレコードを使用する場合、マルチメジャーレコードの属性には名前が付けられ、それらの名前がテーブルの列名になります。したがって、cpu、memory、temperature、pressure などが、マルチメジャー属性の名前になります。自然な質問を用いると、メジャー名を効果的に使用できます。

Timestream for LiveAnalytics は、メジャー名属性の値を使用してデータをパーティショニングし、インデックス化します。したがって、テーブルに異なる複数のメジャー名があり、クエリがそれらの値をクエリ述語として使用している場合、Timestream for LiveAnalytics はカスタムパーティショニングとインデックス作成を使用することでクエリとは無関係のデータを削除できます。例えば、テーブルに cpu と memory のメジャー名があり、クエリに述語 WHERE measure_name = 'cpu' がある場合、Timestream for LiveAnalytics はクエリとは無関係のメジャー名のデータを効果的に削除できます。例えばこちらの例ではメジャー名のメモリを含む行です。この削除は、マルチメジャーレコードでメジャー名を使用する場合にも適用されます。メジャー名属性は、テーブルのパーティショニング属性として効果的に使用できます。メジャー名は、ディメンションの名前と値、ならびに時間と併せて、Timestream for LiveAnalytics テーブル内のデータのパーティショニングに使用されます。Timestream for LiveAnalytics テーブルで許可されている一意のメジャー名の数には制限がありますのでご注意ください。また、メジャー名がメジャー値のデータ型に関連付けられていることにも注意が必要です。例えば、あるメジャー名は 1 つの型のメジャー値にのみ関連付けることができます。この型は、DOUBLE、BIGINT、BOOLEAN、VARCHAR、MULTI のいずれかになります。メジャー名で保存されたマルチメジャーレコードのデータ型は MULTI になります。異なるデータ型 (DOUBLE、BIGINT、VARCHAR、BOOLEAN、TIMESTAMP) を持つ複数のメトリクスを単一のマルチメジャーレコードに保存できるため、異なる型のデータをマルチメジャーレコードに関連付けることが可能です。

以下のセクションでは、メジャー名の属性を効果的に使用して、同じテーブル内のさまざまな型のデータをグループ化する方法について、いくつかの異なる例を用いて説明します。

品質と価値を報告する IoT センサー

IoT センサーのデータをモニタリングするアプリケーションを使用している場合を想定してみましょう。各センサーは温度や圧力などのさまざまな測定値を追跡します。センサーは、実際の測定値の他、測定の品質、つまり測定値や測定の単位がどの程度正確であるかの評価も報告しています。品質、単位、値は一緒に出力されるため、以下のデータ例に示すように、マルチメジャーレコードとしてモデリングできます。そこでは device_id はディメンション、quality、value、unit はマルチメジャー属性です。

この方法を使うことで、マルチメジャーレコードの利点と、メジャー名の値を使用したデータのパーティショニングおよび削除とを組み合わせることができます。クエリが温度などの単一のメジャーを参照している場合、クエリに述語 measure_name を含めることができます。以下は、このようなクエリの一例です。このクエリでは、品質が 90 を超える測定値の単位も反映されます。

SELECT device_id, time, value AS temperature, unit
FROM db.table
WHERE time > ago(1h)
    AND measure_name = 'temperature'
    AND quality > 90

クエリで述語 measure_name を使用すると、Timestream for LiveAnalytics はクエリとは無関係のパーティションとデータを効果的に取り除けるため、クエリのレイテンシーが改善します。

また、すべてのメトリクスが同じタイムスタンプで出力されている場合、もしくは複数のメトリクスが同じクエリで一緒にクエリされている場合は、すべてのメトリクスを同じマルチメジャーレコードに保存することもできます。例えば、temperature_quality、temperature_value、temperature_unit、pressure_quality、pressure_value、pressure_unit などの属性を持つマルチメジャーレコードを作成することが可能です。単一メジャーレコードとマルチメジャーレコードをそれぞれ使用したデータのモデリングについては既に解説済みですが、そのポイントの多くは、データをモデリングする方法の決定に適用されます。コスト、取り込みおよびクエリのレイテンシー、クエリの記述のしやすさを最適化できるモデルを選ぶときは、クエリのアクセスパターンとデータの生成方法を考慮します。

同一テーブルにあるさまざまな型のメトリクス

マルチメジャーレコードとメジャー名の値とを組み合わせることができるもう 1 つのユースケースが、同じデバイスから個別に出力されるさまざまな型のデータをモデリングする方法です。定期的に出力されるメトリクスと不規則なイベントという 2 種類のデータをサーバーが出力している、DevOps モニタリングのユースケースを考えてみましょう。このアプローチの一例が、「Sample Ingestion and Query Workload Generator for Amazon Timestream」で解説されているスキーマです。このケースでは、同じサーバーから出力される異なるタイプのデータを、異なるメジャー名を使用して、同じテーブルに保存します。例えば、同時に出力されるすべてのメトリクスは、メジャー名メトリクスと共に保存されます。このメトリクスから別の時点で出力されるすべてのイベントは、メジャー名イベントと共に保存されます。テーブルのメジャースキーマ (SHOW MEASURES クエリの出力など) は次のとおりです。

このケースでは、イベントとメトリクスではディメンションのセットも異なることがわかります。イベントには異なるディメンション jdk_version と process_name があり、メトリクスにはディメンション instance_type と os_version があります。

異なるメジャー名を使用すると、WHERE measure_name = 'metrics' などの述語を使用してクエリを記述し、メトリクスのみを取得することができます。また、同じテーブル内の同じインスタンスから出力されるすべてのデータがある場合、述語 instance_name を使用してより単純なクエリを記述し、そのインスタンスのデータすべてを取得することもできます。例えば、述語 measure_name を持たないフォーム WHERE instance_name = 'instance-1234' の述語は、特定のサーバーインスタンスのデータすべてを返します。

マルチメジャーレコードのパーティショニングに関する推奨事項

時系列のエコシステムでは、大量のデータを取り込み保存する必要がある、ワークロードの数が増えていると同時に、高いカーディナリティのディメンション値のセットでデータにアクセスするときに、低レイテンシーのクエリレスポンスが必要になることが明らかになっています。

このような特性のため、このセクションの推奨事項は、次のようなユーザーのワークロードに有用です。

以上のようなケースでは、エンジンはマルチメジャー名を使用してデータをパーティショニングし、単一の値を指定することでパーティションの利点が制限されるため、すべてのマルチメジャーの単一名は役に立ちません。これらのレコードのパーティショニングは、主に 2 つのディメンションに基づいています。時間を x 軸、ディメンション名のハッシュと measure_name が y 軸にあるとします。このようなケースでは、measure_name はパーティショニングキーとほぼ同等に機能します。

推奨事項は次のとおりです。

このパーティションスキーマの利点を生かしたい場合は、ハッシュをクライアント側で計算し、クエリエンジンへの静的値として Timestream for LiveAnalytics に渡す必要があります。前述の例で紹介しているのは、生成されたハッシュを必要に応じてエンジンで解決できることを検証する方法です。

推奨事項に従って関連する measure_name を生成する方法として、取り込みパターンに依存する 2 つのパスがあります。

どちらの場合も、ハッシュ生成アルゴリズムを両端 (取り込みとクエリ) でテストし、同じ結果が得られることを確認することが推奨されます。

こちらは、host_name に基づいてハッシュ化した値を生成するコードの一例です。

>>> import xxhash
>>> from bitstring import BitArray
>>> b=xxhash.xxh64('HOST-ID-1235').digest()
>>> BitArray(b).int % 8192
### 3195

package main

import (
    "bytes"
    "fmt"
    "github.com/cespare/xxhash"
)

func main() {
    buf := bytes.NewBufferString("HOST-ID-1235")
    x := xxhash.New()
    x.Write(buf.Bytes())
    // convert unsigned integer to signed integer before taking mod
    fmt.Printf("%f\n", abs(int64(x.Sum64())) % 8192)
}

func abs(x int64) int64 {
    if (x < 0) {
        return -x
    }
    return x
}

import java.nio.ByteBuffer;

import net.jpountz.xxhash.XXHash64;

public class test {
    public static void main(String[] args) {
        XXHash64 hasher = net.jpountz.xxhash.XXHashFactory.fastestInstance().hash64();

        String host = "HOST-ID-1235";
        ByteBuffer buf = ByteBuffer.wrap(host.getBytes());

        Long result = Math.abs(hasher.hash(buf, 0L));
        Long partition = result % 8192;

        System.out.println(result);
        System.out.println(partition);
    }
}

        <dependency>
            <groupId>net.jpountz.lz4</groupId>
            <artifactId>lz4</artifactId>
            <version>1.3.0</version>
        </dependency>