数据建模

适用于 LiveAnalytics 的 Amazon Timestream 旨在收集、存储和分析来自应用程序和设备的时间序列数据，这些应用程序和设备会输出一系列带有时间戳的数据。为实现最佳性能，发送到适用于 LiveAnalytics 的 Timestream 的数据必须具有时间特征，且时间必须是数据的典型组成部分。

适用于 LiveAnalytics 的 Amazon Timestream 为您提供灵活的数据建模方式，可根据应用程序需求采用不同建模方式。本节将介绍其中几种模式，并为您提供优化成本和性能的指南。熟悉维度和度量等关键 概念 Amazon Timestream LiveAnalytics 。在本节中，您将了解以下内容，决定是创建单个表还是多个表以存储数据：

单表与多表

在应用程序中对数据进行建模时，另一重要方面是如何将数据建模为表和数据库。适用于 LiveAnalytics 的 Timestream 中的数据库和表是访问控制的抽象概念，用于指定 KMS 密钥、保留期等。适用于 LiveAnalytics 的 Timestream 会自动对您的数据进行分区，旨在扩展资源以匹配应用程序的摄取、存储、查询负载及要求。

适用于 LiveAnalytics 的 Timestream 中的表可扩展至存储数 PB 的数据以及每秒数十千兆字节的数据写入。查询每小时可处理数百 TB 数据。适用于 LiveAnalytics 的 Timestream 中的查询可以跨越多个表和数据库，通过联接和并集操作实现无缝访问多个表和数据库中的数据。因此，在决定如何在适用于 LiveAnalytics 的 Timestream 中组织数据时，数据规模或请求量通常并非首要考虑因素。在决定将哪些数据放入相同的表中，还是分散在不同表或不同数据库的表中时，需要考虑以下重要事项。

多度量记录与单度量记录

适用于 LiveAnalytics 的 Timestream 支持写入每条记录多个度量（多度量）或每条记录单个度量（单度量）的数据。

多度量记录

在许多使用案例中，您正在跟踪的设备或应用程序可能在同一时间戳发出多个指标或事件。在这种情况下，可将同一时间戳输出的所有指标存储在同一多度量记录中。也就是说，存储在同一多度量记录中的所有度量，在数据的同一行中显示为不同的列。

例如，假设应用程序正从同时测量的设备输出 cpu、内存和 disk_iops 等指标。以下是此类表的示例，其中同时输出的多个指标存储在同一行中。您会发现两个主机每秒输出一次指标。

单度量记录

当设备在不同时间段输出不同指标，或者您使用在不同时间段（例如，当设备的读数/状态发生变化时）输出指标/事件的自定义处理逻辑时，单度量记录便适用。由于每个度量都具有唯一的时间戳，因此这些度量可以存储在适用于 LiveAnalytics 的 Timestream 独立记录中。例如，以 IoT 传感器为例，其可跟踪土壤温度和湿度，仅在检测到与之前报告条目存在变化时才会输出记录。以下示例展示使用单度量记录输出此类数据的具体情况。

比较单度量记录和多度量记录

适用于 LiveAnalytics 的 Timestream 为您提供灵活的数据建模方式，可根据应用程序的需求和特征，将数据建模为单度量记录或多度量记录。如果应用程序需要，单个表可同时存储单度量记录和多度量记录。通常情况下，当应用程序同时发出多个度量/事件时，建议将数据建模为多度量记录，以实现高性能的数据访问和经济高效的数据存储。

例如，如果某个 DevOps 使用案例需跟踪来自数十万台服务器的指标和事件，则每台服务器会定期输出 20 个指标和 5 个事件，且这些事件和指标会同时输出。可以使用单度量记录或多度量记录对该数据进行建模（有关生成的架构，请参阅开源数据生成器）。对于此使用案例，使用多度量记录与单度量记录对数据进行建模的结果如下：

上述因素将因跟踪的指标数量、数据维度数量等而有所不同。虽然上述示例为单一情况提供具体数据，但在众多应用场景和使用案例中，我们发现当应用程序在同一时刻输出多个度量时，以多度量记录的形式存储数据更为高效。此外，多度量记录可灵活处理数据类型，并支持存储多个其他值作为上下文信息（例如，存储请求 ID 和其他时间戳，相关内容将在后文详述）。

请注意，多度量记录也可对稀疏度量进行建模，例如上述的单度量记录示例：可以使用 measure_name 存储度量的名称，也可以使用通用的多度量属性名称，例如使用 value_double 存储 DOUBLE 度量、使用 value_bigint 存储 BIGINT 度量、使用 value_timestamp 存储其他 TIMESTAMP 值等。

维度和度量

适用于 LiveAnalytics 的 Timestream 中的表可用于存储维度（标识正在存储的设备/数据的属性）和度量（正在跟踪的指标/值）；有关更多详细信息，请参阅 概念 Amazon Timestream LiveAnalytics 。当在适用于 LiveAnalytics 的 Timestream 上对应用程序进行建模时，如何将数据映射到维度和度量会影响数据摄取和查询延迟。以下是有关如何将数据建模为维度和度量的指南，可应用于您的使用案例。

选择维度

用于标识发送时间序列数据源的数据，天然适合用作维度，即不会随时间推移而变化的属性。例如，如果您的服务器输出指标，则用于标识服务器的属性（例如主机名、区域、机架和可用区）可作为维度候选项。同样，对于具有多个报告时间序列数据的传感器的 IoT 设备，设备 ID 和传感器 ID 等属性可作为维度的候选项。

如果以多度量记录形式写入数据，当对该表执行 DESCRIBE 或运行 SELECT 语句时，维度和多度量属性将以列的形式呈现于表中。因此，在写入查询时，可在同一查询中自由使用维度和度量。然而，在构建写入记录以摄取数据时，选择哪些属性作为维度属性，哪些属性作为度量值属性时，请注意以下事项：

请注意，适用于 LiveAnalytics 的 Timestream 中的表不会限制维度名称和维度值的唯一组合数量。例如，可将数十亿个这样的唯一值组合存储在表中。然而，正如以下示例所示，谨慎选择维度和度量可以显著优化请求延迟，尤其对于查询而言。

维度中的唯一 ID

如果应用场景要求提供存储每个数据点的唯一标识符（例如，请求 ID、交易 ID 或关联 ID），则将 ID 属性建模为度量值将显著降低查询延迟。使用多度量记录对数据进行建模时，ID 会出现在与其他维度和时间序列数据相同的行中，因此查询可以继续有效地使用这些数据。例如，在某个 DevOps 使用案例中，当服务器输出的每个数据点都具有唯一的请求 ID 属性时，如果将请求 ID 建模为度量值，相较于将其建模为维度，不同查询类型的查询延迟可降低高达 4 倍。

对于并非每个数据点都完全唯一但具有数十万或数百万个唯一值的属性，可使用类似的类比。可将这些属性建模为维度值或度量值。如前所述，如果需在写入路径中对这些值进行去重处理，或在查询中频繁将其用作谓词（例如，在 WHERE 子句中对 device_id = 'abcde' 等属性的值设置等值谓词，其中应用程序需要追踪数百万台设备），则应将其建模为维度。

数据类型丰富，具备多度量记录

多度量记录提供灵活选项，以对数据进行有效建模。存储在多度量记录中的数据在表中以列的形式呈现，类似于维度，因此查询维度和度量值同样便捷。上述讨论过的示例中已出现其中一些模式。以下是其他模式，可有效使用多度量记录以满足应用程序的使用案例需求。

多度量记录支持以下数据类型的属性：DOUBLE、BIGINT、VARCHAR、BOOLEAN 和 TIMESTAMP。因此，多度量记录自然适合不同类型的属性：

特别是，如果查询中包含带谓词的数值数据或时间戳，将这些属性建模为多度量属性而非维度将降低查询延迟。这是因为当使用多度量记录支持的丰富数据类型对此类数据进行建模时，如果将此类数据建模为维度，可以直接使用原生数据类型表示谓词，无需将值从 VARCHAR 转换为其他数据类型。

将度量名称与多度量记录结合使用

适用于 LiveAnalytics 的 Timestream 中的表支持名为度量名称的特殊属性（或列）。可为写入适用于 LiveAnalytics 的 Timestream 的每条记录指定此属性的值。对于单度量记录，自然应使用指标的名称（例如，使用 CPU 或内存表示服务器指标，或使用温度或压力表示传感器指标）。当使用多度量记录时，会对多度量记录中的属性进行命名，这些名称将成为表中的列名。因此，CPU、内存、温度和压力均可成为多度量属性名称。自然而然的问题是：如何有效使用度量名称。

适用于 LiveAnalytics 的 Timestream 使用度量名称属性中的值对数据进行分区和索引。因此，如果表有多个不同的度量名称，且查询使用这些值作为查询谓词，则适用于 LiveAnalytics 的 Timestream 可使用其自定义分区和索引，清理与查询无关的数据。例如，如果表包含 cpu 和 memory 度量名称，且查询包含谓词 WHERE measure_name = 'cpu'，则适用于 LiveAnalytics 的 Timestream 可有效清理与查询无关的度量名称的数据，例如本示例中具有度量名称内存的行。即使在多度量记录中使用度量名称，此修剪操作仍适用。可有效使用度量名称属性作为表的分区属性。度量名称以及维度名称和值及时间可用于对适用于 LiveAnalytics 的 Timestream 表中的数据进行分区。请注意，在适用于 LiveAnalytics 的 Timestream 表中，允许的唯一度量名称数量存在限制。另请注意，度量名称也会与度量值数据类型相关联。例如，单个度量名称仅可与一种类型的度量值相关联。该类型可以是 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 谓词可让适用于 LiveAnalytics 的 Timestream 有效修剪与查询无关的分区和数据，从而降低查询延迟。

如果所有指标都在相同的时间戳输出，且/或在同一查询中同时查询多个指标，则所有指标也可以存储在同一多度量记录中。例如，您可以使用 temperature_quality、temperature_value、temperature_unit、pressure_quality、pressure_value 和 pressure_unit 等属性构造多度量记录。就决定如何对数据进行建模，先前讨论的关于使用单度量记录与多度量记录对数据进行建模的诸多要点同样适用。根据查询访问模式以及数据生成方式，选择能够优化成本、数据摄取和查询延迟以及便于写入查询的模型。

同一个表中不同类型的指标

另一个可将多度量记录与度量名称值结合使用的使用案例，是对来自同一设备但独立输出的不同类型数据进行建模。以 DevOps 监控使用案例为例，服务器会输出两种类型的数据：定期输出的指标和不规则的事件。此方法的一个示例是在数据生成器建模 DevOps 使用案例中讨论的架构。在此情况下，您可以使用不同的度量名称，将同一服务器输出的不同类型数据存储在同一个表中。例如，所有同时输出的指标都使用度量名称指标进行存储。所有在与指标不同时间点输出的事件都使用度量名称事件进行存储。表的度量架构（例如，SHOW MEASURES 查询的输出）为：

在此情况下，您可以发现事件和指标也有不同的维度集，其中事件具有维度 jdk_version 和 process_name，而指标具有维度 instance_type 和 os_version。

使用不同的度量名称，可让您写入带有谓词（例如 WHERE measure_name = 'metrics'）的查询，以便仅获取指标。此外，将同一实例输出的所有数据存储在同一个表中，意味着您可以写入带有 instance_name 谓词的更简单查询语句，以获取该实例的所有数据。例如，形式为 WHERE instance_name = 'instance-1234' 且不带 measure_name 谓词的谓词将返回特定服务器实例的所有数据。

对多度量记录进行分区的建议

我们注意到，在时间序列生态系统中，越来越多的工作负载需要同时满足两大需求：既要处理海量数据的采集与存储，又要在通过高基数维度值集访问数据时实现低延迟的查询响应。

由于这些特性，本节中的建议尤其适用于具有以下特征的客户工作负载：

在这些情况下，所有多度量值的单一名称并无助益，因为我们的引擎使用多度量名称对数据进行分区，而使用单个值会限制您获得的分区优势。这些记录的分区主要基于两大维度。假设时间在 x 轴上，维度名称的哈希值和 measure_name 在 y 轴上。在这些情况下，measure_name 的作用近似于分区键。

我们的建议如下：

请注意，如果想从此分区架构中受益，则需在客户端计算哈希值，并将其作为查询引擎的静态值传递给适用于 LiveAnalytics 的 Timestream。上述示例提供一种验证引擎是否可在需要时解析所生成哈希值的方法。

根据我们的建议生成关联的 measure_name 时，有两种路径可选，具体取决于您的摄取模式。

在这两种情况下，我们建议您在两端（摄取和查询）测试哈希生成算法，以确保获得相同结果。

以下是一些基于 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>