Formatos de armazenamento de dados em filas de mensagens - Data Transmission Service: Central de Documentação do Alibaba Cloud

Formatos de armazenamento de dados

O DTS oferece suporte aos três formatos de armazenamento a seguir para dados gravados em uma fila de mensagens:

DTS Avro: formato de serialização que converte estruturas de dados ou objetos em um formato fácil de armazenar ou transmitir.
Shareplex Json: quando o software de replicação de dados SharePlex lê dados de um banco de dados source e os grava em uma fila de mensagens, os dados são armazenados no formato Shareplex Json.
Canal Json: o Canal analisa logs incrementais de um banco de dados e transmite os dados incrementais para uma fila de mensagens. Os dados são armazenados no formato Canal Json.

DTS Avro

Analise os dados com base na definição de schema do DTS Avro. Para obter mais informações, consulte Definição de schema do DTS Avro e Exemplo de desserialização do DTS Avro.

Nota

No formato DTS Avro, as instruções DDL são do tipo String.

Shareplex Json

Descrição dos parâmetros

Parâmetro	Descrição
`time`	Horário em que a transação foi confirmada no banco de dados. O formato é yyyy-MM-ddTHH:mm:ssZ (UTC).
`userid`	ID do usuário que confirmou a transação.
`op`	Tipo de operação de dados. Os valores válidos incluem INSERT, UPDATE, DELETE, TRUNCATE, DROP COLUMN, UPDATE BEFORE e UPDATE AFTER.
`scn`	System Change Number (SCN). Identifica a versão de uma transação confirmada em um momento específico no banco de dados. Cada transação confirmada recebe um SCN exclusivo.
`rowid`	Valor de endereço relativamente único usado para localizar um registro no banco de dados.
`trans`	ID da transação.
`seq`	Número ordinal da operação dentro da transação. O valor começa em 1.
`size`	Número total de operações na transação.
`table`	Nome da tabela.
`idx`	Índice da operação dentro da transação. O formato é `seq/size`. Por exemplo, `1/11` indica que esta é a primeira operação em uma transação com 11 operações.
`posttime`	Horário em que a transação foi confirmada no banco de dados de destino.

Exemplos

Inserir dados

{
    "meta": {
        "time": "2017-06-16T14:24:34", 
        "userid": 84,                                    
        "op": "ins",                                   
          "scn": "14589063118712",                  
          "rowid": "AAATGpAAIAAItcIAAA",      
        "trans": "7.0.411499",                 
        "seq": 1,                                          
        "size": 11,                                         
        "table": "CL_BIZ1.MIO_LOG",       
          "idx": "1/11",                                       
        "posttime": "2017-06-16T14:33:52"
    },
    "data": {
        "MIO_LOG_ID": "32539737"
     }
}

Atualizar dados

{
    "meta": {
        "time": "2017-06-16T15:38:13",
        "userid": 84,
        "op": "upd",                             
        "table": "CL_BIZ1.MIO_LOG"
        ….
    },
    "data": {                                          
        "CNTR_NO": "1171201606"
    },
    "key": {                                            
        "MIO_LOG_ID": "32537893",
        "PLNMIO_REC_ID": "31557806",
        "POL_CODE": null,
        "CNTR_TYPE": null,
        "CNTR_NO": "1171201606syui26"
    }
}

Excluir dados

{
    "meta": {
        "time": "2017-06-16T15:51:35",
        "userid": 84,
        "op": "del",                      
     },
    "data": {                                    
        "MIO_LOG_ID": "32539739",
        "PLNMIO_REC_ID": "31557806",
        "POL_CODE": null,
        "CNTR_TYPE": null,
        "CG_NO": null
     }
}

Canal Json

Nota

Se você ativar a opção Split message delivery after partition key update, o Kafka entregará uma mensagem DELETE e uma mensagem INSERT quando uma chave de partição for modificada. O Kafka seleciona a partição para cada mensagem com base no respectivo valor da chave de partição.

Exemplo: a chave de partição id tem o valor 1. A mensagem é entregue à partition-1. A lista a seguir descreve as diferenças antes e depois de ativar a opção Split message delivery after partition key update.

Ativado: ao executar o comando UPDATE SET id = 2 WHERE id = 1 no banco de dados source, uma mensagem DELETE com id=1 é entregue à partition-1, e uma mensagem INSERT com id=2 é entregue à partition-2.
Desativado: apenas uma mensagem UPDATE é entregue à partition-1. A operação UPDATE seleciona a partição para entrega com base no valor anterior à alteração.

Descrição das métricas

Parâmetro	Descrição
`database`	Nome do banco de dados.
`es`	Horário em que a operação foi executada no banco de dados source. Trata-se de um timestamp UNIX de 13 dígitos em milissegundos. Nota O tempo real de execução está em segundos. Três zeros são adicionados para converter a unidade para milissegundos. Use um mecanismo de busca para encontrar uma ferramenta de conversão de timestamp UNIX.
`id`	Número de série da operação. Nota Gerado a partir do timestamp e de um deslocamento interno do DTS. Ajuda a determinar a ordem dos registros.
`isDdl`	Indica se a operação é DDL. true: sim. false: não.
`mysqlType`	Tipo de dados do campo. Nota Parâmetros para tipos de dados, como precisão, não são suportados.
`old` e `data`	Dados antes ou depois da alteração. Nota Para instâncias de sincronização ou migração criadas antes de 20 de março de 2022, o valor de old corresponde aos dados após a alteração, e o valor de `data` corresponde aos dados antes da alteração. Por padrão, o valor de `old` inclui todas as colunas, não apenas as modificadas. Para alinhamento com a comunidade open source, nas instâncias criadas ou reiniciadas em ou após 20 de março de 2022, o valor de `data` corresponde aos dados após a alteração, e o valor de `old` corresponde aos dados antes da alteração.
`pkNames`	Nome da chave primária.
`sql`	Instrução SQL.
`sqlType`	Tipo de campo transformado. O valor é igual ao valor de dataTypeNumber. Para obter mais informações, consulte Mapping between field types and dataTypeNumber values.
`table`	Nome da tabela.
`ts`	Horário em que a operação começou a gravar dados no banco de dados de destino. Trata-se de um timestamp UNIX de 13 dígitos em milissegundos. Nota Use um mecanismo de busca para encontrar uma ferramenta de conversão de timestamp UNIX.
`type`	Tipo de operação, como DELETE, UPDATE ou INSERT. Nota Para tarefas de sincronização ou migração completa de dados, o valor é fixo em INIT.
`gtid`	Global Transaction Identifier (GTID). Um GTID é globalmente único. Cada transação corresponde a um GTID. Nota O DTS não oferece suporte à sincronização do campo GTID. O valor deste campo é NULL por padrão.

Exemplos

Atualizar dados

Nota

Para instâncias de sincronização ou migração criadas antes de 20 de março de 2022, quando uma instrução DELETE de uma tabela source é sincronizada ou migrada para o Kafka, o campo old contém os dados e o campo data é nulo. Para alinhamento com a comunidade open source, nas instâncias criadas ou reiniciadas em ou após 20 de março de 2022, o campo data contém os dados e o campo old é nulo.

Instâncias de sincronização ou migração criadas antes de 20 de março de 2022

{
    "old": [
        {
            "shipping_type": "aaa"
        }
    ], 
    "database": "dbname", 
    "es": 1600161894000, 
    "id": 58, 
    "isDdl": false, 
    "mysqlType": {
        "id": "bigint", 
        "shipping_type": "varchar"
    }, 
    "pkNames": [
        "id"
    ], 
    "sql": "", 
    "sqlType": {
        "id": -5, 
        "shipping_type": 12
    }, 
    "table": "tablename", 
    "ts": 1600161894771, 
    "type": "DELETE"
}

Instâncias de sincronização ou migração criadas ou reiniciadas em ou após 20 de março de 2022

{
    "data": [
        {
            "id": "500000287", 
            "shipping_type": null
        }
    ], 
    "database": "dbname", 
    "es": 1600161894000, 
    "id": 58, 
    "isDdl": false, 
    "mysqlType": {
        "id": "bigint", 
        "shipping_type": "varchar"
    }, 
    "pkNames": [
        "id"
    ], 
    "sql": "", 
    "sqlType": {
        "id": -5, 
        "shipping_type": 12
    }, 
    "table": "tablename", 
    "ts": 1600161894771, 
    "type": "DELETE"
}

Operação DDL

{
    "database":"dbname", // The name of the database for synchronization or migration.
    "es":1600161894000, // The time when the source data was written to the binary log.
    "id":58, // The offset in the DTS cache.
    "isDdl":true, // Specifies whether to synchronize or migrate DDL statements.
    "sql":"eg:createxxx", // The DDL statement from the binary log.
    "table":"tablename", // The name of the table for synchronization or migration.
    "ts":1600161894771, // The time when DTS wrote the data to the destination.
    "type":"DDL"
}