Modelagem de dados

O Amazon Timestream LiveAnalytics for foi projetado para coletar, armazenar e analisar dados de séries temporais de aplicativos e dispositivos que emitem uma sequência de dados com um timestamp. Para um desempenho ideal, os dados enviados ao Timestream LiveAnalytics devem ter características temporais e o tempo deve ser um componente essencial dos dados.

O Timestream for LiveAnalytics fornece a flexibilidade de modelar seus dados de maneiras diferentes para atender aos requisitos do seu aplicativo. Nesta seção, abordamos vários desses padrões e fornecemos diretrizes para você otimizar seus custos e desempenho. Familiarize-se com os principais LiveAnalytics conceitos do Timestream, como dimensões e medidas. Nesta seção, você aprenderá mais sobre:

Ao decidir se deseja criar uma única tabela ou várias tabelas para armazenar dados, considere o seguinte:

Tabela única versus várias tabelas

Ao modelar seus dados no aplicativo, outro aspecto importante é como modelar os dados em tabelas e bancos de dados. Bancos de dados e tabelas no Timestream for LiveAnalytics são abstrações para controle de acesso, especificando KMS chaves, períodos de retenção etc. O Timestream para particionar LiveAnalytics automaticamente seus dados e foi projetado para escalar os recursos de acordo com a ingestão, o armazenamento e a carga de consultas e os requisitos de seus aplicativos.

Uma tabela no Timestream for LiveAnalytics pode ser dimensionada para petabytes de dados armazenados, dezenas de gigabytes/seg de gravações de dados e as consultas podem processar centenas de por hora. TBs As consultas no Timestream for LiveAnalytics podem abranger várias tabelas e bancos de dados, fornecendo uniões e uniões para fornecer acesso contínuo aos seus dados em várias tabelas e bancos de dados. Portanto, a escala dos dados ou os volumes de solicitações geralmente não são a principal preocupação ao decidir como organizar seus dados no Timestream for. LiveAnalytics Abaixo estão algumas considerações importantes ao decidir quais dados colocar na mesma tabela versus em tabelas diferentes ou tabelas em bancos de dados diferentes.

Registros de várias medidas versus registros de medida única

O Timestream for LiveAnalytics permite que você grave dados com várias medidas por registro (várias medidas) ou uma única medida por registro (medida única).

Registros de várias medidas

Em muitos casos de uso, um dispositivo ou aplicativo que você está rastreando pode emitir várias métricas ou eventos ao mesmo tempo. Nesses casos, você pode armazenar todas as métricas emitidas no mesmo timestamp no mesmo registro de várias medidas. Ou seja, todas as medidas armazenadas no mesmo registro de várias medidas aparecem como colunas diferentes na mesma linha de dados.

Considere, por exemplo, que seu aplicativo está emitindo métricas como cpu, memória, disk_iops de um dispositivo medido no mesmo instante. Veja a seguir um exemplo dessa tabela em que várias métricas emitidas no mesmo instante são armazenadas na mesma linha. Você verá que dois hosts estão emitindo as métricas uma vez a cada segundo.

Registros de medida única

Os registros de medida única são adequados quando seus dispositivos emitem métricas diferentes em períodos de tempo diferentes ou quando você está usando uma lógica de processamento personalizada que emite metrics/events at different time periods (for instance, when a device's reading/state alterações). Como cada medida tem um registro de data e hora exclusivo, as medidas podem ser armazenadas em seus próprios registros no Timestream for. LiveAnalytics Por exemplo, considere um sensor de IoT, que monitora a temperatura e a umidade do solo, que emite um registro somente quando detecta uma alteração em relação à entrada relatada anteriormente. O exemplo a seguir fornece um exemplo desses dados sendo emitidos usando registros de medida única.

Comparando registros de medida única e de várias medidas

O Timestream for LiveAnalytics fornece a flexibilidade de modelar seus dados como registros de medida única ou de várias medidas, dependendo dos requisitos e características do seu aplicativo. Uma única tabela pode armazenar registros de medida única e de várias medidas, se os requisitos de sua aplicação assim o desejarem. Em geral, quando seu aplicativo está emitindo várias medidas/eventos ao mesmo tempo instantâneo, a modelagem dos dados como registros de várias medidas geralmente é recomendada para acesso eficiente aos dados e armazenamento de dados econômico.

Por exemplo, se você considerar um caso de DevOps uso rastreando métricas e eventos de centenas de milhares de servidores, cada servidor emite periodicamente 20 métricas e 5 eventos, onde os eventos e métricas são emitidos ao mesmo tempo e instantaneamente. Esses dados podem ser modelados usando registros de medida única ou usando registros de várias medidas (consulte o gerador de dados de código aberto para ver o esquema resultante). Para esse caso de uso, modelar os dados usando registros de várias medidas em comparação com registros de medida única resulta em:

Os fatores anteriores variarão dependendo de quantas métricas você está monitorando, quantas dimensões seus dados têm, etc. Embora o exemplo anterior forneça alguns dados concretos para um exemplo, vemos muitos cenários de aplicativos e casos de uso em que, se seu aplicativo emitir várias medidas no mesmo instante, armazenar dados como registros de várias medidas é mais eficaz. Além disso, os registros de várias medidas oferecem a flexibilidade dos tipos de dados e do armazenamento de vários outros valores como contexto (por exemplo, armazenamento de solicitações IDs e registros de data e hora adicionais, que serão discutidos posteriormente).

Observe que um registro de várias medidas também pode modelar medidas esparsas, como o exemplo anterior para registros de medida única: você pode usar o measure_name para armazenar o nome da medida e usar um nome genérico de atributo de várias medidas, como value_double para armazenar DOUBLE medidas, value_bigint para armazenar medidas, value_timestamp para armazenar valores adicionais, etc. BIGINT TIMESTAMP

Dimensões e medidas

Uma tabela no Timestream LiveAnalytics permite que você armazene dimensões (identificando atributos do dispositivo/dados que você está armazenando) e medidas (as métricas/valores que você está rastreando). Consulte Timestream para obter conceitos e obter mais detalhes. LiveAnalytics Ao modelar seu aplicativo no Timestream for LiveAnalytics, a forma como você mapeia seus dados em dimensões e medidas afeta sua ingestão e latência de consulta. A seguir estão as diretrizes sobre como modelar seus dados como dimensões e medidas que você pode aplicar ao seu caso de uso.

Escolhendo dimensões

Os dados que identificam a fonte que está enviando os dados da série temporal são adequados naturalmente às dimensões, que são atributos que não mudam com o tempo. Por exemplo, se você tiver um servidor emitindo métricas, os atributos que identificam o servidor, como nome do host, região, rack e zona de disponibilidade, são candidatos às dimensões. Da mesma forma, para um dispositivo de IoT com vários sensores relatando dados de séries temporais, a identificação do dispositivo, a identificação do sensor etc. são candidatas às dimensões.

Se você estiver gravando dados como registros de várias medidas, as dimensões e os atributos de várias medidas aparecerão como colunas na tabela quando você fizer DESCRIBE ou executar uma SELECT declaração na tabela. Portanto, ao escrever suas consultas, você pode usar livremente as dimensões e medidas na mesma consulta. No entanto, ao criar seu registro de gravação para ingerir dados, lembre-se do seguinte ao escolher quais atributos são especificados como dimensões e quais são valores de medida:

Observe que uma tabela no Timestream para LiveAnalytics não limita o número de combinações exclusivas de nomes e valores de dimensões. Por exemplo, você pode ter bilhões dessas combinações de valores exclusivos armazenadas em uma tabela. No entanto, como você verá nos exemplos a seguir, uma escolha cuidadosa de dimensões e medidas pode otimizar significativamente a latência da solicitação, especialmente para consultas.

Único IDs em dimensões

Se o cenário do seu aplicativo exigir que você armazene um identificador exclusivo para cada ponto de dados (por exemplo, um ID de solicitação, um ID de transação ou um ID de correlação), modelar o atributo ID como um valor de medida resultará em uma latência de consulta significativamente melhor. Ao modelar seus dados com registros de várias medidas, o ID aparece na mesma linha no contexto de suas outras dimensões e dados de séries temporais, para que suas consultas possam continuar a usá-los de forma eficaz. Por exemplo, considerando um caso de DevOps uso em que cada ponto de dados emitido por um servidor tem um atributo de ID de solicitação exclusivo, modelar o ID da solicitação como um valor de medida resulta em uma latência de consulta até 4 vezes menor em diferentes tipos de consulta, em vez de modelar o ID de solicitação exclusivo como uma dimensão.

Você pode usar a analogia similar para atributos que não são totalmente exclusivos para cada ponto de dados, mas têm centenas de milhares ou milhões de valores exclusivos. Você pode modelar esses atributos como dimensões ou valores de medida. Você gostaria de modelá-la como uma dimensão se os valores forem necessários para a desduplicação no caminho de gravação, conforme discutido anteriormente, ou se você costuma usá-la como um predicado (por exemplo, na WHERE cláusula com um predicado de igualdade em um valor desse atributo, como device_id = ‘abcde’ onde seu aplicativo está rastreando milhões de dispositivos) em suas consultas.

Riqueza de tipos de dados com registros de várias medidas

Os registros de várias medidas oferecem a flexibilidade de modelar seus dados com eficiência. Os dados que você armazena em um registro de várias medidas aparecem como colunas na tabela semelhantes às dimensões, oferecendo a mesma facilidade de consulta de dimensões e valores de medida. Você viu alguns desses padrões nos exemplos discutidos anteriormente. Abaixo, você encontrará padrões adicionais para usar com eficiência registros de várias medidas para atender aos casos de uso do seu aplicativo.

Os registros de várias medidas oferecem suporte a atributos dos tipos de dados DOUBLE BIGINTVARCHAR,,BOOLEAN, e. TIMESTAMP Portanto, eles se encaixam naturalmente em diferentes tipos de atributos:

Em particular, se você tiver dados numéricos ou carimbos de data/hora nos quais tenha predicados na consulta, modelar esses atributos como atributos de várias medidas, em vez de dimensões, resultará em menor latência da consulta. Isso ocorre porque, ao modelar esses dados usando os tipos de dados avançados suportados em registros de várias medidas, você pode expressar os predicados usando tipos de dados nativos em vez de converter valores VARCHAR para outro tipo de dados se você modelou esses dados como dimensões.

Usando o nome da medida com registros de várias medidas

As tabelas no Timestream LiveAnalytics oferecem suporte a um atributo especial (ou coluna) chamado nome da medida. Você especifica um valor para esse atributo para cada registro para o qual você grava no Timestream. LiveAnalytics Para registros de medida única, é natural usar o nome de sua métrica (como CPU, memória para métricas de servidor ou temperatura, pressão para métricas de sensores). Ao usar registros de várias medidas, como os atributos em um registro de várias medidas são nomeados (e esses nomes se tornam nomes de colunas na tabela), cpu, memória ou temperatura, a pressão pode se tornar nomes de atributos de várias medidas. Portanto, uma questão natural é como usar efetivamente o nome da medida.

O Timestream for LiveAnalytics usa os valores no atributo nome da medida para particionar e indexar os dados. Portanto, se uma tabela tiver vários nomes de medidas diferentes e se as consultas usarem esses valores como predicados de consulta, o Timestream for LiveAnalytics poderá usar seu particionamento e indexação personalizados para eliminar dados que não sejam relevantes para as consultas. Por exemplo, se sua tabela tiver nomes de medidas de CPU e memória e sua consulta tiver um predicadoWHERE measure_name = 'cpu', o Timestream for LiveAnalytics poderá efetivamente remover dados de nomes de medidas não relevantes para a consulta, por exemplo, linhas com memória de nome de medida neste exemplo. Essa redução se aplica mesmo ao usar nomes de medidas com registros de várias medidas. Você pode usar o atributo de nome da medida de forma eficaz como um atributo de particionamento para uma tabela. O nome da medida, juntamente com os nomes e valores das dimensões, e o tempo são usados para particionar os dados em um Timestream for LiveAnalytics table. Esteja ciente dos limites do número de nomes de medidas exclusivos permitidos em uma tabela Timestream for LiveAnalytics . Observe também que o nome de uma medida também está associado a um tipo de dados de valor de medida, por exemplo, um único nome de medida só pode ser associado a um tipo de valor de medida. Esse tipo pode ser um dos DOUBLE BIGINTBOOLEAN,VARCHAR,, MULTI e. Registros de várias medidas armazenados com um nome de medida terão o tipo de dados comoMULTI. Como um único registro de várias medidas pode armazenar várias métricas com diferentes tipos de dados (DOUBLE,, BIGINTVARCHAR, eTIMESTAMP)BOOLEAN, você pode associar dados de diferentes tipos em um registro de várias medidas.

As seções a seguir descrevem alguns exemplos diferentes de como o atributo nome da medida pode ser usado com eficiência para agrupar diferentes tipos de dados na mesma tabela.

Sensores de IoT que relatam qualidade e valor

Suponha que você tenha um aplicativo monitorando dados de sensores de IoT. Cada sensor rastreia medidas diferentes, como temperatura e pressão. Além dos valores reais, os sensores também relatam a qualidade das medições, que é uma medida da precisão da leitura e uma unidade para a medição. Como qualidade, unidade e valor são emitidos juntos, eles podem ser modelados como registros de várias medidas, conforme mostrado nos dados de exemplo abaixo, em que device_id é uma dimensão, qualidade, valor e unidade são atributos de várias medidas:

Essa abordagem permite combinar os benefícios dos registros de várias medidas com o particionamento e a remoção de dados usando os valores do nome da medida. Se as consultas fizerem referência a uma única medida, por exemplo, temperatura, você poderá incluir um predicado de nome de medida na consulta. Veja a seguir um exemplo dessa consulta, que também projeta a unidade para medições cuja qualidade esteja acima de 90.

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

Usar o predicado measure_name na consulta permite que o Timestream elimine efetivamente partições e dados que não são relevantes LiveAnalytics para a consulta, melhorando assim a latência da consulta.

Também é possível armazenar todas as métricas no mesmo registro de várias medidas se todas as métricas forem emitidas no mesmo timestamp e/ou várias métricas forem consultadas juntas na mesma consulta. Por exemplo, você pode construir um registro de várias medidas com os atributos temperatura_qualidade, valor_temperatura, unidade_temperatura, qualidade_pressão, valor_pressão, unidade_pressão etc. Muitos dos pontos discutidos anteriormente sobre a modelagem de dados usando registros de medida única versus registros de várias medidas se aplicam à sua decisão de como modelar os dados. Considere seus padrões de acesso à consulta e como seus dados são gerados para escolher um modelo que otimize seu custo, ingestão e latência de consultas e a facilidade de escrever suas consultas.

Diferentes tipos de métricas na mesma tabela

Outro caso de uso em que você pode combinar registros de várias medidas com valores de nomes de medidas é modelar diferentes tipos de dados que são emitidos de forma independente pelo mesmo dispositivo. Considere o caso de uso de DevOps monitoramento que os servidores estão emitindo dois tipos de dados: métricas emitidas regularmente e eventos irregulares. Um exemplo dessa abordagem é o esquema discutido no gerador de dados que modela um caso de DevOps uso. Nesse caso, você pode armazenar os diferentes tipos de dados emitidos pelo mesmo servidor na mesma tabela usando nomes de medidas diferentes. Por exemplo, todas as métricas emitidas no mesmo instante são armazenadas com métricas de nome de medida. Todos os eventos emitidos em um instante de tempo diferente das métricas são armazenados com eventos de nome de medida. O esquema de medidas para a tabela (por exemplo, saída da SHOW MEASURES consulta) é:

Nesse caso, você pode ver que os eventos e as métricas também têm conjuntos diferentes de dimensões, em que os eventos têm dimensões diferentes jdk_version e process_name, enquanto as métricas têm dimensões instance_type e os_version.

O uso de nomes de medidas diferentes permite que você escreva consultas com predicados, de modo WHERE measure_name = 'metrics' a obter somente as métricas. Além disso, ter todos os dados emitidos da mesma instância na mesma tabela significa que você também pode escrever uma consulta mais simples com o predicado instance_name para obter todos os dados dessa instância. Por exemplo, um predicado do formulário WHERE instance_name = ‘instance-1234’ sem um predicado measure_name retornará todos os dados de uma instância específica do servidor.

Recomendações para particionar registros de várias medidas

Vimos que há um número crescente de cargas de trabalho no ecossistema de séries temporais que precisam ingerir e armazenar grandes quantidades de dados e, ao mesmo tempo, precisam de respostas de consulta de baixa latência ao acessar dados por meio de um conjunto de valores de dimensão de alta cardinalidade.

Devido a essas características, as recomendações desta seção serão úteis para cargas de trabalho de clientes que tenham o seguinte.

Nesses casos, um único nome para todas as medidas de várias medidas não ajudará, pois nosso mecanismo usa um nome de várias medidas para particionar os dados e ter um único valor limita a vantagem de partição que você obtém. O particionamento desses registros é baseado principalmente em duas dimensões. Digamos que o tempo esteja no eixo x e em um hash dos nomes das dimensões e measure_name no eixo y. Nesses measure_name casos, funciona quase como uma chave de particionamento.

Nossa recomendação é a seguinte.

Lembre-se de que, se você quiser obter os benefícios desse esquema de partição, o hash precisa ser calculado no lado do cliente e passado para o Timestream LiveAnalytics como um valor estático para o mecanismo de consulta. O exemplo anterior fornece uma forma de validar se o hash gerado pode ser resolvido pelo mecanismo quando necessário.

Para gerar o associado measure_name seguindo nossa recomendação, há dois caminhos que dependem do seu padrão de ingestão.

Em ambos os casos, recomendamos que você teste seu algoritmo de geração de hash nas duas extremidades (ingestão e consulta) para garantir que você esteja obtendo os mesmos resultados.

Aqui estão alguns exemplos de código para gerar o valor em hash com base emhost_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>