建立資料模型

Amazon Timestream for LiveAnalytics 旨在收集、存放和分析來自應用程式和裝置的時間序列資料，以時間戳記發出一系列資料。為了獲得最佳效能，傳送至 Timestream for LiveAnalytics 的資料必須具有時間特性，且時間必須是資料的基本元件。

Timestream for LiveAnalytics 可讓您靈活地以不同的方式建立資料模型，以符合應用程式的需求。在本節中，我們涵蓋多種模式，並提供指導方針，讓您最佳化成本和效能。熟悉重要的 Timestream for LiveAnalytics 概念，例如維度和指標。在本節中，您將進一步了解：

決定是否建立單一資料表或多個資料表來存放資料時，請考慮下列事項：

單一資料表與多個資料表

當您在應用程式中建立資料模型時，另一個重要的層面是如何將資料模型化為資料表和資料庫。Timestream for LiveAnalytics 中的資料庫和資料表是存取控制的抽象，指定 KMS 金鑰、保留期間等。LiveAnalytics 的 Timestream 會自動分割您的資料，旨在擴展資源以符合應用程式的擷取、儲存和查詢負載和需求。

Timestream for LiveAnalytics 中的資料表可以擴展到儲存的 PB 資料、數十 GB/秒的資料寫入，而查詢可以每小時處理數百 TBs。Timestream for LiveAnalytics 中的查詢可以跨越多個資料表和資料庫，提供聯結和聯集，以跨多個資料表和資料庫無縫存取您的資料。因此，決定如何在 Timestream for LiveAnalytics 中組織資料時，資料或請求磁碟區規模通常不是主要考量。以下是決定要在相同資料表中與不同資料表或不同資料庫中的資料表中共同放置哪些資料時的一些重要考量。

多重測量記錄與單一測量記錄

LiveAnalytics 的 Timestream 可讓您寫入資料，每個記錄有多個度量 （多度量） 或每個記錄有單一度量 （單一度量）。

多度量記錄

在許多使用案例中，您正在追蹤的裝置或應用程式可能會同時發出多個指標或事件。在這種情況下，您可以將所有在相同時間戳記發出的指標存放在相同的多測量記錄中。也就是說，存放在相同多量值記錄中的所有量值都會在相同資料列中顯示為不同的資料欄。

例如，假設您的應用程式正在從同時即時測量的裝置發出指標，例如 cpu、記憶體、disk_iops。以下是此類資料表的範例，其中同時發出多個指標會立即存放在相同的資料列中。您將看到兩個主機每秒發出一次指標。

單一測量記錄

當您的裝置在不同時段發出不同的指標時，或者您使用自訂處理邏輯在不同時段發出指標/事件時 （例如，當裝置的讀取/狀態變更時），單一測量記錄是適當的。由於每個量值都有唯一的時間戳記，因此這些量值可以存放在 Timestream for LiveAnalytics 中自己的記錄中。例如，請考慮追蹤土壤溫度和濕度的 IoT 感應器，只有在偵測到先前回報項目的變更時才會發出記錄。下列範例提供使用單一量值記錄發出此類資料的範例。

比較單一量值和多量值記錄

Timestream for LiveAnalytics 可讓您靈活地根據應用程式的需求和特性，將資料建模為單一量值或多量值記錄。如果您的應用程式需求需要，單一資料表可以同時存放單一量值和多量值記錄。一般而言，當您的應用程式同時發出多個量值/事件時，通常建議將資料建模為多量值記錄，以用於效能資料存取和符合成本效益的資料儲存。

例如，如果您考慮 DevOps 使用案例追蹤指標和來自數十萬伺服器的事件，則每個伺服器都會定期發出 20 個指標和 5 個事件，其中事件和指標會同時發出。該資料可以使用單一量值記錄或使用多量值記錄建立模型 （請參閱開放原始碼資料產生器以取得產生的結構描述）。在此使用案例中，使用多量值記錄與單一量值記錄建立資料模型會導致：

上述因素會因您追蹤的指標數量、資料擁有的維度等而異。雖然上述範例提供一些具體資料作為一個範例，但我們在許多應用程式案例和使用案例中看到，如果應用程式同時發出多個量值，則將資料儲存為多量值記錄會更有效率。此外，多度量記錄可為您提供資料類型的彈性，並將多個其他值儲存為內容 （例如，儲存請求 IDs 和其他時間戳記，稍後會討論）。

請注意，多度量記錄也可以建立稀疏度量的模型，例如用於單一度量記錄的先前範例：您可以使用 measure_name 來存放度量的名稱，並使用一般多度量屬性名稱，例如 value_double to store DOUBLE measures、value_bigint to store BIGINT measures、value_timestamp 來存放其他TIMESTAMP值等。

維度和量值

Timestream for LiveAnalytics 中的資料表可讓您存放維度 （識別您要存放之裝置/資料的屬性） 和量值 （您正在追蹤的指標/值），如需詳細資訊，請參閱 Timestream for LiveAnalytics 概念。當您在 Timestream for LiveAnalytics 上建立應用程式模型時，將資料映射到維度和指標的方式會影響您的擷取和查詢延遲。以下是如何將資料建模為可套用至使用案例的維度和指標的指導方針。

選擇維度

識別傳送時間序列資料之來源的資料是維度的自然擬合，這些維度是不會隨時間變更的屬性。例如，如果您有伺服器發出指標，則識別伺服器的屬性，例如主機名稱、區域、機架、可用區域，都是維度的候選項目。同樣地，對於具有多個感應器回報時間序列資料的 IoT 裝置，裝置 ID、感應器 ID 等適合維度。

如果您要將資料寫入為多度量記錄，當您在資料表上執行 DESCRIBE 或執行 SELECT 陳述式時，維度和多度量屬性會在資料表中顯示為資料欄。因此，在撰寫查詢時，您可以自由地在相同的查詢中使用維度和量值。不過，當您建構寫入記錄以擷取資料時，當您選擇哪些屬性指定為維度，以及哪些屬性是測量值時，請記住下列事項：

請注意，Timestream for LiveAnalytics 中的資料表不會限制維度名稱和值的唯一組合數量。例如，您可以在資料表中存放數十億個這類唯一值組合。不過，如以下範例所示，仔細選擇維度和量值可以大幅最佳化您的請求延遲，尤其是查詢。

維度中的唯一 IDs

如果您的應用程式案例需要您為每個資料點存放唯一識別符 （例如請求 ID、交易 ID 或關聯 ID)，則將 ID 屬性建模為度量值將可大幅改善查詢延遲。使用多度量記錄建立資料模型時，ID 會顯示在與您其他維度和時間序列資料相同的資料列中，讓您的查詢可以繼續使用它們。例如，考慮 DevOps 使用案例，其中伺服器發出的每個資料點都有唯一的請求 ID 屬性，將請求 ID 建模為測量值會導致不同查詢類型的查詢延遲降低高達 4 倍，而不是將唯一請求 ID 建模為維度。

您可以針對不是每個資料點完全唯一的屬性使用類似的比喻，但具有數十萬或數百萬個唯一值。您可以將這些屬性建模為維度或度量值。如果這些值是先前討論在寫入路徑上刪除重複的必要值，或者您經常在查詢中使用它做為述詞 （例如，在 WHERE子句中，具有該屬性值的等式述詞，例如您的應用程式正在追蹤數百萬個裝置device_id = ‘abcde’的位置），則您想要將其建模為維度。

具有多度量記錄的資料類型的豐富度

多度量記錄可讓您靈活地有效地建立資料模型。您在多度量記錄中存放的資料在表格中顯示為類似維度的資料欄，因此提供相同的查詢維度和度量值的便利性。您在先前討論的範例中看到其中一些模式。您可以在下方找到其他模式，以有效使用多度量記錄來滿足應用程式的使用案例。

多度量記錄支援資料類型 DOUBLE、BIGINT、BOOLEAN、 VARCHAR和 的屬性TIMESTAMP。因此，它們自然適合不同類型的屬性：

特別是，如果您在查詢中具有述詞的數值資料或時間戳記，則將這些屬性建模為多測量屬性，而不是維度，將導致較低的查詢延遲。這是因為當您使用多度量記錄中支援的豐富資料類型建立此類資料的模型時，您可以使用原生資料類型來表達述詞，而不必將此類資料建模為維度，而是將值從 VARCHAR 轉換為其他資料類型。

將量值名稱與多量值記錄搭配使用

Timestream for LiveAnalytics 中的資料表支援稱為量值名稱的特殊屬性 （或資料欄）。您可以為寫入 Timestream for LiveAnalytics 的每個記錄指定此屬性的值。對於單一量值記錄，使用指標的名稱 （例如 cpu、伺服器指標的記憶體或溫度、感應器指標的壓力） 是很自然的。使用多度量記錄時，由於多度量記錄中的屬性已命名 （且這些名稱會成為資料表中的資料欄名稱），Cpu、記憶體或溫度時，壓力可能會成為多度量屬性名稱。因此，自然問題是如何有效地使用量值名稱。

LiveAnalytics 的 Timestream 使用量值名稱屬性中的值來分割資料並編製索引。因此，如果資料表有多個不同的量值名稱，且如果查詢使用這些值做為查詢述詞，則 LiveAnalytics 的 Timestream 可以使用其自訂分割和索引來刪除與查詢無關的資料。例如，如果您的資料表具有 cpu 和記憶體測量名稱，且您的查詢具有述詞 WHERE measure_name = 'cpu'，則 LiveAnalytics 的 Timestream 可以有效地為與查詢無關的測量名稱剪除資料，例如，此範例中具有測量名稱記憶體的資料列。即使將量值名稱與多量值記錄搭配使用，此剪除也適用。您可以有效地使用量值名稱屬性做為資料表的分割屬性。測量名稱以及維度名稱和值，以及時間用於分割 Timestream for LiveAnalytics 資料表中的資料。請注意 Timestream for LiveAnalytics 資料表中允許的唯一量值名稱數量限制。另請注意，測量名稱也與測量值資料類型相關聯，例如，單一測量名稱只能與一種類型的測量值相關聯。該類型可以是 DOUBLE、BIGINT、VARCHAR、 BOOLEAN和 之一MULTI。以量值名稱存放的多度量記錄的資料類型為 MULTI。由於單一多度量記錄可以存放具有不同資料類型 (DOUBLE、VARCHAR、、 和 TIMESTAMP) BIGINT的多個指標BOOLEAN，因此您可以將多度量記錄中不同類型的資料建立關聯。

下列各節說明幾個不同的範例，說明如何有效地使用量值名稱屬性來將相同資料表中的不同資料類型分組。

IoT 感應器報告品質和價值

假設您有一個來自 IoT 感應器的應用程式監控資料。每個感應器都會追蹤不同的量值，例如溫度、壓力。除了實際值之外，感應器也會報告測量品質，這是測量讀數準確度的指標，以及測量單位。由於品質、單位和值會一起發出，因此它們可以建模為多度量記錄，如以下範例資料所示，其中 device_id 是維度、品質、值和單位是多度量屬性：

此方法可讓您使用量值名稱，結合多度量記錄的優點，以及分割和刪除資料。如果查詢參考單一量值，例如溫度，您可以在查詢中包含量值名稱述詞。以下是此類查詢的範例，該查詢也會針對品質高於 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、tempor_value、tempor_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 軸上，以及維度名稱和 y 軸measure_name上的 雜湊。measure_name 在這些情況下， 的運作方式幾乎與分割金鑰類似。

我們的建議如下。

請記住，如果您想要從此分割區結構描述中獲益，則需要在用戶端計算雜湊，並將雜湊傳遞給 Timestream for LiveAnalytics 做為查詢引擎的靜態值。上述範例提供一種方法來驗證產生的雜湊可以在需要時由引擎解決。

若要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>