Considerações ao usar integrações ETL zero com o Amazon Redshift

O data warehouse de destino do Amazon Redshift deve atender aos seguintes pré-requisitos:

Se você excluir uma origem de integração autorizada para um data warehouse do Amazon Redshift, todas as integrações associadas entrarão no estado FAILED. Todos os dados replicados anteriormente permanecem em seu banco de dados do Amazon Redshift e podem ser consultados.

O banco de dados de destino é somente leitura. Não é possível criar tabelas, visualizações ou visões materializadas no banco de dados de destino. No entanto, é possível usar visões materializadas em outras tabelas no data warehouse de destino.

As visões materializadas são compatíveis quando usadas em consultas entre bancos de dados. Para obter informações sobre como criar visões materializadas com dados replicados por meio de integrações ETL zero, consulte Consultar dados replicados com visões materializadas.

Por padrão, só é possível consultar tabelas no data warehouse de destino que estejam no estado Synced. Para consultar tabelas em outro estado, defina o parâmetro QUERY_ALL_STATES do banco de dados como TRUE. Consulte informações sobre a configuração de QUERY_ALL_STATES em CREATE DATABASE e em ALTER DATABASE no Guia do desenvolvedor de banco de dados do Amazon Redshift. Consulte mais informações sobre o estado do banco de dados em SVV_INTEGRATION_TABLE_STATE no Guia do desenvolvedor de banco de dados do Amazon Redshift.

Como só aceita caracteres UTF-8, talvez o Amazon Redshift não respeite o agrupamento definido na origem. As regras de classificação e comparação podem ser diferentes, o que pode, em última análise, alterar os resultados da consulta.

As integrações ETL zero estão limitadas a 50 por destino de data warehouse do Amazon Redshift.

As tabelas na fonte de integração devem ter uma chave primária. Caso contrário, as tabelas não poderão ser replicadas no data warehouse de destino no Amazon Redshift.

Para obter informações sobre como adicionar uma chave primária ao Amazon Aurora PostgreSQL, consulte Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift no AWS Database Blog. Para ter informações sobre como adicionar uma chave primária ao Amazon Aurora MySQL ou ao RDS para MySQL, consulte Handle tables without primary keys while creating Amazon Aurora MySQL or Amazon RDS for MySQL zero-ETL integrations with Amazon Redshift no Blog do banco de dados da AWS.

É possível usar a filtragem de dados para integrações ETL zero do Aurora para definir o escopo da replicação do banco de dados de origem do cluster de banco de dados de origem do Aurora para o data warehouse de destino do Amazon Redshift. Em vez de replicar todos os dados para o destino, é possível definir um ou mais filtros que incluam ou excluam seletivamente determinadas tabelas da replicação. Consulte mais informações em Filtragem de dados para integrações ETL zero do Aurora com o Amazon Redshift no Guia do usuário do Amazon Aurora.

Para integrações ETL zero do Aurora PostgreSQL com o Amazon Redshift, o Amazon Redshift é compatível com um máximo de 100 bancos de dados do Aurora PostgreSQL. Cada banco de dados é replicado da origem ao destino de forma independente.

A integração ETL zero não permite transformações enquanto replica os dados dos datastores transacionais para o Amazon Redshift. Os dados são replicados no estado em que se encontram com base no banco de dados de origem. No entanto, é possível aplicar transformações nos dados replicados no Amazon Redshift.

A integração ETL zero é executada no Amazon Redshift usando conexões paralelas. Ela é executada usando as credenciais do usuário que criou o banco de dados a partir da integração. Quando a consulta é executada, a escalabilidade simultânea não é ativada para essas conexões durante a sincronização (gravações). As leituras de escalabilidade simultânea (de clientes do Amazon Redshift) funcionam para objetos sincronizados.

Você pode definir o REFRESH_INTERVAL para uma integração ETL zero visando controlar a frequência da replicação de dados no Amazon Redshift. Consulte mais informações em CREATE DATABASE e ALTER DATABASE no Guia do desenvolvedor de banco de dados do Amazon Redshift.

Quando você exclui uma tabela na origem, a tabela no destino não é excluída, mas é alterada para o estado DroppedSource. É possível excluir ou renomear a tabela do banco de dados do Amazon Redshift.

Quando você trunca uma tabela em uma origem, são executadas exclusões na tabela de destino. Por exemplo, se todos os registros forem truncados na origem, os registros correspondentes na coluna de destino _record_is_active serão alterados para false.

Quando você executa o comando SQL TRUNCATE table na tabela de destino, as linhas de histórico ativas são marcadas como inativas com um carimbo de data/hora correspondente.

Quando uma linha em uma tabela é definida como inativa, ela pode ser excluída após um breve intervalo (cerca de 10 minutos). Para excluir linhas inativas, conecte-se ao banco de dados de ETL zero com o editor de consultas v2 ou outro cliente SQL.

Você só pode excluir linhas inativas de uma tabela com o modo histórico ativado. Por exemplo, um comando SQL semelhante ao mostrado a seguir exclui somente as linhas inativas.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'

Isso é equivalente a um comando SQL como a seguir.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False

Ao desativar o modo histórico de uma tabela, todos os dados históricos são salvos na tabela nomeada com <schema>.<table-name>_historical_<timestamp> enquanto a tabela original nomeada <schema>.<table-name> é atualizada.

Quando uma tabela com o modo histórico ativado é excluída da replicação usando um filtro de tabela, todas as linhas são definidas como inativas e ela é alterada para o estado DroppedSource. Consulte mais informações sobre filtros de tabela em Filtragem de dados para integrações ETL zero do Aurora com o Amazon Redshift no Guia do usuário do Amazon Aurora.

O modo histórico só pode ser alternado para true ou false para tabelas no estado Synced.

É possível usar a filtragem de dados do Aurora e do RDS para integrações ETL zero do MySQL para definir o escopo da replicação do cluster de origem do banco de dados para o data warehouse de destino do Amazon Redshift. Em vez de replicar todos os dados para o destino, é possível definir um ou mais filtros que incluam ou excluam seletivamente determinadas tabelas da replicação. Consulte mais informações em Filtragem de dados para integrações ETL zero do Aurora com o Amazon Redshift no Guia do usuário do Amazon Aurora.

As tabelas na fonte de integração devem ter uma chave primária. Caso contrário, as tabelas não poderão ser replicadas no data warehouse de destino no Amazon Redshift.

Para obter informações sobre como adicionar uma chave primária ao Amazon Aurora PostgreSQL, consulte Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift no AWS Database Blog. Para ter informações sobre como adicionar uma chave primária ao Amazon Aurora MySQL ou ao RDS para MySQL, consulte Handle tables without primary keys while creating Amazon Aurora MySQL or Amazon RDS for MySQL zero-ETL integrations with Amazon Redshift no Blog do banco de dados da AWS.

O tamanho máximo de um tipo de dados VARCHAR do Amazon Redshift é de 65.535 bytes. Quando o conteúdo da fonte não se encaixa nesse limite, a replicação não prossegue e a tabela é colocada em um estado de falha. É possível definir o parâmetro do banco de dados TRUNCATECOLUMNS como TRUE a fim de truncar o conteúdo para caber na coluna. Consulte informações sobre a configuração de TRUNCATECOLUMNS em CREATE DATABASE e em ALTER DATABASE no Guia do desenvolvedor de banco de dados do Amazon Redshift.

Para ter mais informações sobre diferenças de tipos de dados entre fontes de integração ETL zero e bancos de dados do Amazon Redshift, consulte Diferenças de tipos de dados entre os bancos de dados Aurora e Amazon Redshift no Guia do usuário do Amazon Aurora.

Não há suporte para nomes de tabelas do DynamoDB com mais de 127 caracteres.

Os dados de uma integração ETL zero do DynamoDB são mapeados para uma coluna de tipo de dados SUPER no Amazon Redshift.

Não há suporte para nomes de coluna para a chave de partição ou chave de classificação com mais de 127 caracteres.

Uma integração ETL zero do DynamoDB só pode ser mapeada para um banco de dados do Amazon Redshift.

Para chaves de classificação e partição, o máximo de precisão e escala é (38,18). Os tipos de dados numéricos no DynamoDB oferecem suporte a uma precisão máxima de até 38. O Amazon Redshift também oferece suporte a uma precisão máxima de 38, mas a precisão/escala decimal padrão no Amazon Redshift é (38,10). Isso significa que os valores da escala podem ser truncados.

Para uma integração ETL zero bem-sucedida, um atributo individual (consistindo em nome+valor) em um item do DynamoDB não pode ser maior que 64 KB.

Na ativação, a integração ETL zero exporta a tabela completa do DynamoDB para preencher o banco de dados do Amazon Redshift. O tempo necessário para que esse processo inicial seja concluído depende do tamanho da tabela do DynamoDB. A integração ETL zero então replica incrementalmente as atualizações do DynamoDB para o Amazon Redshift usando exportações incrementais do DynamoDB. Isso significa que a atualização dos dados replicados do DynamoDB no Amazon Redshift é feita automaticamente.

Atualmente, a latência mínima para a integração ETL zero do DynamoDB é de 15 minutos. Você pode aumentá-la ainda mais definindo um REFRESH_INTERVAL diferente de zero para uma integração ETL zero. Consulte mais informações em CREATE DATABASE e ALTER DATABASE no Guia do desenvolvedor de banco de dados do Amazon Redshift.

Nomes de tabelas e colunas de origens de aplicações com mais de 127 caracteres não são compatíveis.

O tamanho máximo de um tipo de dados VARCHAR do Amazon Redshift é de 65.535 bytes. Quando o conteúdo da fonte não se encaixa nesse limite, a replicação não prossegue e a tabela é colocada em um estado de falha. É possível definir o parâmetro do banco de dados TRUNCATECOLUMNS como TRUE a fim de truncar o conteúdo para caber na coluna. Consulte informações sobre a configuração de TRUNCATECOLUMNS em CREATE DATABASE e em ALTER DATABASE no Guia do desenvolvedor de banco de dados do Amazon Redshift.

Para obter mais informações sobre as diferenças de tipos de dados entre origens de aplicações de Integração ETL zero e bancos de dados do Amazon Redshift, consulte Integrações ETL zero no Guia do desenvolvedor do AWS Glue.

A latência mínima para uma Integração ETL zero com aplicações é de 1 hora. Você pode aumentá-la ainda mais definindo um REFRESH_INTERVAL diferente de zero para uma integração ETL zero. Consulte mais informações em CREATE DATABASE e ALTER DATABASE no Guia do desenvolvedor de banco de dados do Amazon Redshift.