AWSIntegração sem ETL para fontes de banco de dados autogerenciadas - AWSDatabase Migration Service

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

AWSIntegração sem ETL para fontes de banco de dados autogerenciadas

AWSA integração Zero-ETL é uma solução totalmente gerenciada que disponibiliza dados transacionais e operacionais nas tabelas Amazon Redshift, Amazon S3 e Amazon S3 de várias fontes de banco de dados operacionais e transacionais. Usando o Zero-ETL, você pode replicar dados de seus bancos de dados de origem autogerenciados, como MySQL, PostgreSQL, SQL Server e Oracle, para o Amazon Redshift por meio de endpoints de origem existentes (). AWS Database Migration Service AWS DMS A sincronização automática evita o processo tradicional de extração, transformação e carregamento (ETL). Ele também permite análises em tempo real e cargas de trabalho de IA. Para obter mais informações, consulte Integrações com zero ETL no Guia de gerenciamento do Amazon Redshift.

A integração Zero-ETL oferece os seguintes benefícios:

  • Replicação de dados em tempo real — sincronização contínua de dados dos bancos de dados Oracle com o Amazon Redshift com latência mínima.

  • Eliminação de pipelines ETL complexos — Não há necessidade de criar e manter soluções personalizadas de integração de dados.

  • Redução da sobrecarga operacional — configuração e gerenciamento automatizados por meio AWS APIs de.

  • Arquitetura simplificada de integração de dados — integração perfeita entre bancos de dados autogerenciados e serviços de AWS análise.

  • Segurança aprimorada — criptografia integrada e controles de acesso do IAM.

Como a integração Zero-ETL funciona para fontes de banco de dados autogerenciadas

Você pode usar AWS DMS endpoints existentes criados anteriormente para bancos de dados autogerenciados ou criar novos.

  • Use o AWS Glue console ou a CLI para criar a integração sem ETL com o Amazon Redshift como destino no catálogo. AWS Glue Você pode especificar o esquema e o filtro de tabela ao criar integrações sem ETL.

  • Recursos adicionais somente para leitura relacionados às integrações são criados automaticamente no serviço. AWS DMS Esses recursos, incluindo o mecanismo Zero-ETL, são usados para iniciar processos de carga total e de alteração contínua de dados, para sincronizar dados com o banco de dados de destino do Amazon Redshift.

  • Você controla a criptografia dos seus dados ao criar a origem de integração, ao criar a integração ETL zero e ao criar o data warehouse do Amazon Redshift.

  • A integração monitora a integridade do pipeline de dados e se recupera de problemas quando possível.

  • É possível criar integrações de fontes do mesmo tipo em um único data warehouse do Amazon Redshift para derivar insights holísticos em várias aplicações.

Depois que os dados forem replicados, você poderá usar os recursos de análise do Amazon Redshift. Por exemplo, machine learning (ML) integrado, visões materializadas, compartilhamento de dados e acesso direto a vários armazenamentos de dados e data lakes. Para engenheiros de dados, as integrações sem ETL fornecem acesso a dados urgentes que, de outra forma, podem ser atrasados por erros intermitentes em pipelines de dados complexos. É possível executar consultas analíticas e modelos de ML em dados transacionais para obter insights oportunos de eventos urgentes e decisões comerciais.

Você pode criar assinaturas de notificação de eventos do Amazon Redshift para ser notificado automaticamente quando ocorrerem problemas em qualquer integração com ETL zero. Para ver a lista de notificações de eventos relacionadas à integração, consulte Notificações de eventos de integração com zero ETL com a Amazon. EventBridge A maneira mais simples de criar uma assinatura é com o console Amazon Simple Notification Service. Para obter informações sobre como criar um tópico do Amazon SNS e assiná-lo, consulte Getting started with Amazon SNS no Guia do desenvolvedor do Amazon Simple Notification Service.

Configurando permissões e criptografia do IAM para integração com ETL zero

Para criar e gerenciar integrações sem ETL, você precisa configurar as permissões apropriadas do IAM, AWS Key Management Service (AWS KMS) chaves de criptografia e políticas de recursos. Esta seção fornece orientação sobre como configurar os componentes de segurança necessários.

Pré-requisitos

Antes de criar uma integração sem ETL, verifique se você tem o seguinte:

  • Um usuário ou função do IAM com as permissões apropriadas para criar e gerenciar integrações

  • Endpoints AWS DMS de origem existentes para seus bancos de dados autogerenciados

  • Um cluster provisionado pelo Amazon Redshift ou namespace sem servidor como destino

  • Configuração de rede, incluindo sub-redes VPC e grupos de segurança

Criar uma chave do KMS

Primeiro, crie uma AWS KMS chave gerenciada pelo cliente para criptografar dados em sua integração com ETL zero. O exemplo a seguir cria uma chave de criptografia simétrica:

aws kms create-key \ --description "On-prem Zero-ETL Integration Encryption Key" \ --key-usage ENCRYPT_DECRYPT \ --key-spec SYMMETRIC_DEFAULT \ --region region

Anote o KeyId e Arn da resposta, pois você precisará deles ao configurar a política de chaves e criar a integração.

Resultado do exemplo:

{ "KeyMetadata": { "AWSAccountId": "account-id", "KeyId": "4e2c14f8-7abe-4aec-851a-379f6ed973a8", "Arn": "arn:aws:kms:region:account-id:key/4e2c14f8-7abe-4aec-851a-379f6ed973a8", "CreationDate": 1763155061.148, "Enabled": true, "Description": "Zero-ETL Integration Encryption Key", "KeyUsage": "ENCRYPT_DECRYPT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT", "KeySpec": "SYMMETRIC_DEFAULT", "EncryptionAlgorithms": [ "SYMMETRIC_DEFAULT" ], "MultiRegion": false } }

Configurando a política de chaves do KMS

Depois de criar a chave KMS, configure a política de chaves para permitir que o Amazon Redshift AWS Glue e os serviços usem a chave para operações de criptografia e descriptografia. A política de chaves deve conceder as permissões necessárias aos diretores do serviço e incluir o contexto de criptografia que será usado durante a criação da integração.

O exemplo a seguir mostra uma política fundamental para integrações com zero ETL:

{ "Version": "2012-10-17", "Id": "key-default-1", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::account-id:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allows the Redshift and glue service principal to add a grant to a KMS key", "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com", "glue.amazonaws.com" ] }, "Action": "kms:CreateGrant", "Resource": "*", "Condition": { "StringEquals": { "kms:EncryptionContext:context-key": "context-value" }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt", "GenerateDataKey", "CreateGrant", "GenerateDataKeyWithoutPlaintext", "ReEncryptTo" ] } } } ] }

A kms:EncryptionContext condição deve corresponder ao contexto de criptografia adicional que você especifica ao criar a integração. Você pode atualizar a política de chaves usando o AWS KMS console ou o seguinte comando da CLI:

aws kms put-key-policy \ --key-id key-id \ --policy-name default \ --policy file://kms-key-policy.json

Criação de um usuário do IAM e configuração da CLI AWS

Crie um usuário do IAM que será usado para gerenciar integrações sem ETL e configurar a CLI AWS com as credenciais apropriadas.

  1. Crie um usuário do IAM:

    aws iam create-user --user-name cli-user
  2. Crie chaves de acesso para o usuário:

    aws iam create-access-key --user-name cli-user

    Salve o AccessKeyId e SecretAccessKey da saída, pois você precisará deles para configurar a AWS CLI.

Criar e anexar uma política do IAM

Crie uma política do IAM que conceda permissões para operações de integração com ETL zero. A política deve incluir permissões para AWS GlueAWS DMS,, Amazon RedshiftAWS KMS, e.

Salve a política a seguir em um arquivo (por exemplo,/tmp/zetl-policy.json):

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ZetlGlueIntegrationAccess", "Effect": "Allow", "Action": [ "glue:CreateIntegration", "glue:ModifyIntegration", "glue:DeleteIntegration", "glue:DescribeIntegrations", "glue:DescribeInboundIntegrations" ], "Resource": "*" }, { "Sid": "DMSIntegrationAccess", "Effect": "Allow", "Action": [ "dms:CreateOutboundIntegration", "dms:ModifyOutboundIntegration", "dms:CreateEndpoint", "dms:DescribeEndpoints", "dms:ModifyEndpoint", "dms:DeleteEndpoint", "dms:TestConnection" ], "Resource": "*" }, { "Sid": "ZetlRedshiftFullAccess", "Effect": "Allow", "Action": [ "redshift:*", "redshift-serverless:*", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeInternetGateways", "sns:CreateTopic", "sns:Get*", "sns:List*", "cloudwatch:Describe*", "cloudwatch:Get*", "cloudwatch:List*", "cloudwatch:PutMetricAlarm", "cloudwatch:EnableAlarmActions", "cloudwatch:DisableAlarmActions", "tag:GetResources", "tag:UntagResources", "tag:GetTagValues", "tag:GetTagKeys", "tag:TagResources" ], "Resource": "*" }, { "Sid": "ZetlRedshiftDataAPI", "Effect": "Allow", "Action": [ "redshift-data:ExecuteStatement", "redshift-data:CancelStatement", "redshift-data:ListStatements", "redshift-data:GetStatementResult", "redshift-data:DescribeStatement", "redshift-data:ListDatabases", "redshift-data:ListSchemas", "redshift-data:ListTables", "redshift-data:DescribeTable" ], "Resource": "*" }, { "Sid": "ZetlKMSAccess", "Effect": "Allow", "Action": [ "kms:CreateKey", "kms:DescribeKey", "kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey", "kms:ListKeys", "kms:CreateAlias", "kms:ListAliases", "kms:CreateGrant" ], "Resource": "*" }, { "Sid": "ZetlSecretsManagerAccess", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:CreateSecret", "secretsmanager:UpdateSecret", "secretsmanager:DeleteSecret", "secretsmanager:DescribeSecret", "secretsmanager:ListSecrets", "secretsmanager:GetResourcePolicy", "secretsmanager:PutResourcePolicy", "secretsmanager:ValidateResourcePolicy" ], "Resource": "*" } ] }

Crie a política e anexe-a ao usuário do IAM:

aws iam create-policy \ --policy-name ZetlCustomPolicy \ --policy-document file:///tmp/zetl-policy.json aws iam attach-user-policy \ --policy-arn arn:aws:iam::account-id:policy/ZetlCustomPolicy \ --user-name cli-user

Configurando o perfil AWS CLI

Configure um perfil AWS CLI com as credenciais do usuário criadas nas etapas anteriores:

aws configure set aws_access_key_id ACCESS_KEY_ID --profile cli-user aws configure set aws_secret_access_key SECRET_ACCESS_KEY --profile cli-user aws configure set region region --profile cli-user aws configure set output json --profile cli-user

Teste a configuração do perfil:

aws sts get-caller-identity --profile cli-user

A saída deve exibir o ID da conta, o ID do usuário e o ARN do usuário, confirmando que o perfil está configurado corretamente.

Criação de uma política de recursos do Redshift

Crie uma política de recursos do Amazon Redshift para autorizar o endpoint de AWS DMS origem a criar integrações de entrada com seu namespace do Amazon Redshift. Essa política é anexada ao namespace Amazon Redshift e controla quais fontes podem replicar dados nele.

O exemplo a seguir mostra como criar uma política de recursos para um namespace do Amazon Redshift:

aws redshift put-resource-policy \ --policy '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": ["redshift.amazonaws.com"] }, "Action": ["redshift:AuthorizeInboundIntegration"], "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:dms:region:account-id:endpoint:endpoint-id" } } }, { "Effect": "Allow", "Principal": { "AWS": "account-id" }, "Action": [ "redshift:CreateInboundIntegration", "redshift:ModifyInboundIntegration" ] } ] }' \ --resource-arn arn:aws:redshift:region:account-id:namespace:namespace-id \ --region region

Substitua os seguintes espaços reservados:

  • region— A AWS região onde seus recursos estão localizados

  • account-id— O ID AWS da sua conta

  • endpoint-id— O ID do seu endpoint AWS DMS de origem

  • namespace-id— O ID do seu namespace Amazon Redshift

Exemplo: Criação de uma integração de ETL zero com criptografia

Depois de configurar as permissões e as chaves de criptografia necessárias, você pode criar uma integração sem ETL usando a API. AWS Glue O exemplo a seguir demonstra a criação de uma integração de uma fonte do MySQL para um destino do Amazon Redshift com criptografia KMS:

aws glue create-integration \ --integration-name mysql-onprem-integration \ --source-arn arn:aws:dms:region:account-id:endpoint:source-endpoint-id \ --target-arn arn:aws:redshift:region:account-id:namespace:namespace-id \ --description "MySQL to Redshift integration" \ --integration-config '{"SourceProperties":{"SubnetIds":"subnet-id1,subnet-id2,subnet-id3","VpcSecurityGroupIds":"sg-id"}}' \ --data-filter "include: mysql.*" \ --kms-key-id arn:aws:kms:region:account-id:key/key-id \ --additional-encryption-context '{"context-key": "context-value"}' \ --profile cli-user \ --region region

O comando inclui os seguintes parâmetros principais:

  • --integration-name— Um nome exclusivo para sua integração

  • --source-arn— O ARN do seu endpoint de origem AWS DMS

  • --target-arn— O ARN do seu namespace Amazon Redshift

  • --integration-config— Configuração de rede, incluindo sub-rede IDs e grupos de segurança

  • --data-filter— Especifica quais esquemas e tabelas devem ser replicados

  • --kms-key-id— O ARN da AWS KMS chave para criptografia

  • --additional-encryption-context— Pares de valores-chave do contexto de criptografia que devem corresponder à política de chaves do KMS (por exemplo,) {"context-key": "context-value"}

  • --profile— O perfil AWS CLI a ser usado (o perfil de usuário CLI criado anteriormente)

Após a criação bem-sucedida, o comando retorna os detalhes da integração, incluindo o ARN da integração, o status e os parâmetros de configuração. Resultado do exemplo:

{ "SourceArn": "arn:aws:dms:region:account-id:endpoint:endpoint-id", "TargetArn": "arn:aws:redshift:region:account-id:namespace:namespace-id", "IntegrationName": "mysql-onprem-integration", "IntegrationArn": "arn:aws:glue:region:account-id:integration:integration-id", "KmsKeyId": "arn:aws:kms:region:account-id:key/key-id", "AdditionalEncryptionContext": { "context-key": "context-value" }, "Status": "CREATED", "CreateTime": 1763234086.001, "DataFilter": "include: mysql.*", "IntegrationConfig": { "SourceProperties": { "SubnetIds": "subnet-id1,subnet-id2,subnet-id3", "VpcSecurityGroupIds": "sg-id" } } }

Práticas recomendadas de segurança

Siga estas melhores práticas de segurança ao configurar integrações com ETL zero:

  • Use menos privilégios de acesso — conceda somente as permissões mínimas necessárias para criar e gerenciar integrações. Considere usar permissões em nível de recurso sempre que possível.

  • Ative a criptografia — sempre use AWS KMS chaves gerenciadas pelo cliente para criptografar os dados de integração. Especifique o contexto de criptografia para obter segurança adicional.

  • Alterne as credenciais regularmente — Se estiver usando as chaves de acesso do usuário do IAM, alterne-as regularmente. Em vez disso, considere usar funções do IAM com credenciais temporárias.

  • Monitore o acesso — Use AWS CloudTrail para monitorar chamadas de API relacionadas à criação e ao gerenciamento da integração.

  • Restringir o acesso à rede — configure os grupos de segurança da VPC para limitar o acesso à rede somente aos recursos necessários.

  • Use políticas de recursos — Implemente políticas de recursos do Amazon Redshift para controlar quais fontes podem criar integrações com seu data warehouse.

  • Recursos de tags — aplique tags a integrações e recursos relacionados para melhor organização e controle de custos.