Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Atualizado em 2024-08-19 GMT+08:00

Acesso a dados de GDS-Kafka

O GDS-Kafka consome e armazena em cache dados do Kafka. Se o tempo ou o tamanho do cache de dados atingir um limite pré-configurado, o GDS-Kafka copiará os dados para uma tabela temporária do GaussDB(DWS) e, em seguida, inserirá ou atualizará os dados na tabela temporária.

  1. O formato dos dados gerados pelo produtor de mensagens do Kafka é especificado pelo parâmetro kafka.source.event.type. Para obter detalhes, consulte Formatos de mensagem suportados pelo GDS-Kafka.
  2. No GDS-Kafka, você pode inserir dados diretamente para tabelas sem chaves primárias ou atualizar dados mesclando. A inserção direta pode alcançar um melhor desempenho, porque não envolve operações de atualização. Determine seu modo de atualização com base no tipo de tabela de destino em GaussDB(DWS). O modo de importação de dados é determinado pelo parâmetro app.insert.directly e se existe uma chave primária. Para obter detalhes, consulte Modos de importação de dados do GDS-Kafka.
  • O GDS-kafka só permite nomes de tabela e coluna de destino em minúsculas.
  • O GDS-Kafka apaga os dados históricos com base no pos no campo estendido. Se os dados importados envolverem a operação de exclusão, o campo estendido deve ser usado.

Formatos de mensagem suportados pelo GDS-Kafka

Tabela 1 Formatos de mensagem suportados pelo GDS-Kafka

kafka.source.event.type

Formato

Descrição

cdc.drs.avro

Formato interno do DRS da Huawei Cloud. O DRS gera dados no formato avro usado pelo Kafka. O GDS-Kafka pode interconectar diretamente com o DRS para analisar e importar os dados.

Nenhuma

drs.cdc

Para usar o formato avro para drs.cdc, especifique a dependência Maven de GDS-Kafka-common e GDS-Kafka-source nos programas upstream do Kafka e, em seguida, crie e preencha o objeto Record. Um objeto Record representa um registro de tabela. Ele será serializado em uma matriz de byte[], produzido e enviado para o Kafka e usado pelo downstream de GDS-Kafka.

No exemplo a seguir, a tabela de destino é a tabela person no esquema public. A tabela person consiste nos campos id, name e age. O op_type é U, que indica uma operação de atualização. Este exemplo altera o campo name de a para b no registro com o ID 0, e altera o valor do campo age de 18 para 20.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Record record = new Record();
// Set the schema and table name of the target table.
record.setTableName("public.person");
// Set the field list.
List<Field> fields = new ArrayList<>();
fields.add(new Field("id", 0));
fields.add(new Field("name", 1));
fields.add(new Field("age", 2));
record.setFields(fields);
// Set the field value list before the table record is updated.
List<Object> before = new ArrayList<>();
before.add(new Integer(0, "0"));
before.add(new Character("utf-8", ByteBuffer.wrap("a".getBytes(StandardCharsets.UTF_8))));
before.add(new Integer(0, "18"));
record.setBeforeImages(before);
// Set the field value list after the table record is updated.
List<Object> after = new ArrayList<>();
after.add(new Integer(0, "0"));
after.add(new Character("utf-8", ByteBuffer.wrap("b".getBytes(StandardCharsets.UTF_8))));
after.add(new Integer(0, "20"));
record.setAfterImages(after);
// Set the operation type.
record.setOperation("U");
// Set the operation time.
record.setUpdateTimestamp(325943905);
// Serialize the record object into a byte[] array.
byte[] msg = Record.getEncoder().encode(record).array();

Formato avro padrão:

  • O campo tableName é usado para descrever os nomes de tabela e esquema de destino aos quais o registro atual pertence. [Obrigatório]
  • O campo operation é usado para descrever o tipo de operação do registro atual. I indica inserção, U indica atualização e D indica exclusão. [Obrigatório]
  • updateTimestamp indica a hora em que uma operação é executada na extremidade de origem. [Opcional]
  • A lista beforeImages descreve as informações antes que o registro atual seja atualizado ou excluído. Os campos no before body correspondem aos da tabela de destino. [Obrigatório para U/D]
  • A lista afterImages descreve as informações atualizadas ou inseridas recentemente do registro atual. [Obrigatório para U/D]
  • A lista fields descreve a lista de campos do registro da tabela atual. Os valores de values dos campos devem estar na mesma sequência que aqueles em beforeImage e afterImage. [Obrigatório]

cdc.json

No exemplo a seguir, a tabela de destino é a tabela person no esquema public. A tabela person consiste nos campos id, name e age. O op_type é U, que indica uma operação de atualização. Este exemplo altera o campo name de a para b no registro com o ID 1, e altera o valor do campo age de 18 para 20.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
{
"table": "public.person",
"op_type": "U",
"op_ts": "1668426344",
"current_ts": "1668426344",
"before": {
"id":"1",
"name":"a",
"age": 18
},
"after": {
"id":"1",
"name":"b",
"age": 20
}
}

Formato JSON padrão:

  • O campo table descreve a tabela de destino e os nomes de esquema aos quais o registro atual pertence. [Obrigatório]
  • O campo op_type é usado para descrever o tipo de operação do registro atual. I indica inserção, U indica atualização e D indica exclusão. [Obrigatório]
  • op_ts indica a hora em que uma operação é executada na extremidade de origem. [Opcional]
  • current_ts indica a hora em que uma mensagem é importada para o Kafka. [Opcional]
  • O objeto before descreve as informações antes que o registro atual seja atualizado ou excluído. Os campos no before body correspondem aos da tabela de destino. [Obrigatório para U/D]
  • A lista de objetos after descreve a atualização ou as informações recém-inseridas do registro atual. [Obrigatório para U/D]

industrial.iot.json

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
{
"header": {
"thing_id":"a0001",
"instance_id":"1",
"thing_model_name":"computer",
"timestamp":"1668426344"
},
"body": {
"status":"Normal",
"temperature":"10",
"working_time":"10000"
},
}

Formato de dados da IoT:

  • thing_model_name no header indica o nome da tabela. [Obrigatório]
  • Os valores de thing_id, instance_id e timestamp no header e o conteúdo no corpo compreendem os campos do registro atual.
  • Os dados de IoT são dados de séries temporais e não envolvem atualização ou exclusão. Apenas operações de inserção estão envolvidas.

industrial.iot.recursion.json

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
{
"header": {
"thing_id":"a0001",
"instance_id":"1",
"thing_model_name":"computer",
"timestamp":"1668426344"
},
"body": {
"status":"Normal",
"temperature":"10",
"property":{
  "key1":"1",
  "key2":2
},
"working_time":"10000"
},
}

Formato de dados da IoT:

  • thing_model_name no header indica o nome da tabela. [Obrigatório]
  • Os valores de thing_id, instance_id e timestamp no header e o conteúdo no corpo compreendem os campos do registro atual.
  • Os dados de IoT são dados de séries temporais e não envolvem atualização ou exclusão. Apenas operações de inserção estão envolvidas.
  • Nesse formato de dados, a chave e o valor do body são adicionados aos campos property e value no novo formato para gerar várias partes de novos dados. Desta forma, as linhas são convertidas em colunas.

industrial.iot.event.json.independent.table

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
{
"event_id":"1",
"event_name":"test",
"start_time":"1970-1-1T00:00:00.000Z",
"end_time":"1970-1-1T00:00:00.000Z",
"fields":{
    "field1":"value1",
    "field2":2
    }
}

Formato de dados de fluxo de eventos IoT:

  • event_name indica um nome de tabela. [Obrigatório]
  • event_id, start_time, end_time e fields compreendem o conteúdo do campo de um registro. [Obrigatório]
  • Os dados de fluxo de eventos da IoT são dados de séries temporais e não envolvem atualização ou exclusão. Apenas operações de inserção estão envolvidas.

industrial.iot.json.multi.events

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
{
"event_id":"1",
"event_name":"test",
"start_time":"1970-1-1T00:00:00.000Z",
"end_time":"1970-1-1T00:00:00.000Z",
"fields":{
    "field1":"value1",
    "field2":2,
    "field3":{
       "key1":"1",
       "key2":2
       }
    }
}

Formato de dados de fluxo de eventos IoT:

  • event_name indica um nome de tabela. [Obrigatório]
  • event_id, start_time, end_time e fields compreendem o conteúdo do campo de um registro. [Obrigatório]
  • Os dados de fluxo de eventos da IoT são dados de séries temporais e não envolvem atualização ou exclusão. Apenas operações de inserção estão envolvidas.
  • Nesse formato de dados, a chave e o valor de fields são adicionados aos campos field_name e field_value no novo formato para gerar vários novos dados. Desta forma, as linhas são convertidas em colunas.

Modos de importação do GDS-Kafka

Para importar dados do GDS-Kafka para o banco de dados, copie os dados para uma tabela temporária e, em seguida, mescle ou insira os dados. A tabela a seguir descreve seu uso e cenários.

Tabela 2 Modos de importação do GDS-Kafka

Operação

app.insert.directly

Tabela de chave primária

Modo de importação

insert

true (somente para tabelas sem chaves primárias)

Não

Use INSERT SELECT para gravar dados da tabela temporária na tabela de destino.

false

Sim

Mescle dados da tabela temporária para a tabela de destino com base na chave primária.

Não

Use INSERT SELECT para gravar dados da tabela temporária na tabela de destino.

delete

true (somente para tabelas sem chaves primárias)

Não

Use INSERT SELECT para gravar dados da tabela temporária na tabela de destino.

false

NOTA:

Você pode marcar a exclusão configurando o parâmetro app.del.flag. A bandeira de um registro excluído será definida como 1.

Sim

  • Se o campo delflag estiver definido, a mesclagem será realizada com base na chave primária. Se uma chave primária correspondida for encontrada, e o valor de pos na tabela de destino for menor que o da tabela temporária, o campo delflag será definido como 1. Caso contrário, um novo registro será inserido.
  • Se o campo delflag não estiver definido, uma chave primária correspondente será encontrada e o valor de pos na tabela de destino for menor que o da tabela temporária, o registro será excluído da tabela de destino.

Não

  • Se o campo delflag estiver definido, todos os campos na tabela temporária serão usados para corresponder e mesclar com a tabela de destino. Se um registro correspondente for encontrado e o valor de pos na tabela de destino for menor do que o da tabela temporária, o campo delflag será definido como 1. Caso contrário, um novo registro será inserido.
  • Se o campo delflag não estiver definido, todos os campos na tabela temporária serão usados para corresponder à tabela de destino. Se um registro correspondente for encontrado e o valor de pos na tabela de destino for menor do que o da tabela temporária, o registro correspondente será excluído da tabela de destino.

update

true (somente para tabelas sem chaves primárias)

Não

Use INSERT SELECT para gravar dados da tabela temporária na tabela de destino.

false

NOTA:

A operação de atualização é dividida. A mensagem em before ou beforeImage é processada como uma operação de exclusão, e a mensagem em after ou afterImage é processada como uma operação de inserção. Em seguida, a mensagem é salva no banco de dados com base nas operações de inserção e exclusão.

Sim

Equivalente à operação insert+delete em uma tabela com uma chave primária.

Não

Equivalente à operação insert+delete em uma tabela sem uma chave primária.