Ingestão de streaming

A ingestão de streaming fornece ingestão de dados de transmissão de baixa latência e alta velocidade do Amazon Kinesis Data Streams e Amazon Managed Streaming for Apache Kafka em uma visão materializada provisionada pelo Amazon Redshift ou Amazon Redshift sem servidor. Ela reduz o tempo necessário para acessar os dados, bem como o custo de armazenamento. Você pode configurar a ingestão de streaming para o seu cluster do Amazon Redshift ou para o Amazon Redshift Serverless e criar uma visão materializada, usando instruções SQL, conforme descrito em Criar visualizações materializadas no Amazon Redshift. Depois disso, usando a atualização da visão materializada, você pode ingerir centenas de megabytes de dados por segundo. Isso resulta em acesso rápido a dados externos que são atualizados rapidamente.

Fluxo de dados

Um cluster provisionado pelo Amazon Redshift ou um grupo de trabalho do Amazon Redshift sem servidor é o consumidor do fluxo. Uma visão materializada é a área de pouso para dados lidos do fluxo, que são processados à medida que chegam. Por exemplo, os valores JSON podem ser consumidos e mapeados para as colunas de dados da visão materializada usando SQL familiar. Quando a visão materializada é atualizada, o Redshift consome dados dos fragmentos de dados alocados do Kinesis ou das partições do Kafka até que a visualização atinja paridade com SEQUENCE_NUMBER para o fluxo do Kafka ou o último Offset para o tópico do Kafka. A visão materializada subsequente atualiza os dados de leitura do último SEQUENCE_NUMBER da atualização anterior até atingir a paridade com os dados do fluxo ou tópico.

Casos de uso de ingestão de transmissão

Casos de uso para a ingestão de streaming do Amazon Redshift envolvem trabalhar com dados que são gerados continuamente (transmitidos) e que precisam ser processados em um curto período (latência) desde sua geração. Isso é chamado de análise quase em tempo real. As fontes de dados podem variar, incluindo dispositivos da IoT, dados de telemetria de sistemas ou dados de fluxo de cliques de um site ou uma aplicação movimentada.

Considerações sobre a ingestão de streaming

A seguir estão considerações importantes e práticas recomendadas para performance e faturamento ao configurar um ambiente de ingestão de streaming.

• Uso e ativação da atualização automática: as consultas de atualização automática para visões materializadas são tratadas como qualquer outra workload do usuário. A atualização automática carrega os dados do fluxo assim que eles chegam.

  A atualização automática pode ser ativada explicitamente para uma visão materializada criada para ingestão de streaming. Para fazer isso, especifique AUTO REFRESH na definição da visão materializada. A atualização manual é o padrão. Para especificar a atualização automática de uma visão materializada existente para ingestão de streaming, você pode executar ALTER MATERIALIZED VIEW para ativá-la. Para obter mais informações, consulte CREATE MATERIALIZED VIEW ou ALTER MATERIALIZED VIEW.

• Ingestão de streaming e Amazon Redshift Serverless: as mesmas instruções de instalação e configuração que se aplicam à ingestão de streaming do Amazon Redshift em um cluster provisionado também se aplicam à ingestão de streaming no Amazon Redshift Serverless. É importante dimensionar o Amazon Redshift Serverless com o nível necessário de RPUs para oferecer suporte à ingestão de streaming com atualização automática e outras workloads. Para obter mais informações, consulte Faturamento do Amazon Redshift Serverless.

• Nós do Amazon Redshift em uma zona de disponibilidade diferente do cluster do Amazon MSK: quando você configura a ingestão de streaming, o Amazon Redshift tenta se conectar a um cluster do Amazon MSK na mesma zona de disponibilidade, caso o reconhecimento de rack esteja habilitado para o Amazon MSK. Se todos os seus nós estiverem em zonas de disponibilidade diferentes do cluster do Amazon Redshift, você poderá incorrer custos de transferência de dados entre zonas de disponibilidade. Para evitar isso, mantenha pelo menos um nó de cluster de agente do Amazon MSK na mesma AZ do cluster ou grupo de trabalho provisionado do Redshift.

• Local de início da atualização: depois de criar uma visão materializada, sua atualização inicial começa a partir de TRIM_HORIZON de um fluxo do Kinesis, ou do offset 0 de um tópico do Amazon MSK.

• Formatos de dados: os formatos de dados compatíveis são limitados àqueles que podem ser convertidos de VARBYTE. Para ter mais informações, consulte Tipo VARBYTE e Operadores VARBYTE.

• Anexar registros a uma tabela: é possível executar ALTER TABLE APPEND para acrescentar linhas a uma tabela de destino usando uma visão materializada de origem existente. Isso funciona somente se a visão materializada estiver configurada para ingestão de streaming. Para obter mais informações, consulte ALTER TABLE APPEND.

• Executar TRUNCATE ou DELETE: você pode remover registros de uma visão materializada usada para ingestão de streaming utilizando alguns métodos:

  • TRUNCATE: esse comando exclui todas as linhas de uma visão materializada configurada para ingestão de streaming. Ele não verifica a tabela. Para obter mais informações, consulte TRUNCATE.

  • DELETE: esse comando exclui todas as linhas de uma visão materializada configurada para ingestão de streaming. Para obter mais informações, consulte DELETE.

Práticas recomendadas e orientações sobre ingestão de streaming

Há casos em que são apresentadas opções de configuração da ingestão de streaming. Recomendamos seguir as práticas recomendadas abaixo. Elas se baseiam em nossos próprios testes e ajudam os clientes a evitar problemas que causem perda de dados.

• Extração de valores de dados transmitidos: se você usar a função JSON_EXTRACT_PATH_TEXT na definição de visão materializada para fragmentar o JSON de streaming de entrada, isso poderá afetar significativamente a performance e a latência. Para explicar, para cada coluna extraída usando JSON_EXTRACT_PATH_TEXT, o JSON de entrada é analisado novamente. Depois disso, ocorre qualquer conversão de tipo de dados, filtragem e lógica de negócios. Isso significa, por exemplo, que se você extrair dez colunas dos dados JSON, cada registro JSON será analisado dez vezes, o que inclui conversões de tipo e de lógica adicional. Isso ocasiona maior latência de ingestão. Uma abordagem alternativa que recomendamos é usar a função JSON_PARSE para converter registros JSON no tipo de dados SUPER do Redshift. Depois que os dados transmitidos chegarem à visão materializada, use o PartiQL para extrair strings individuais da representação SUPER dos dados JSON. Para ter mais informações, confira Consultar dados semiestruturados.

  Também é importante observar que JSON_EXTRACT_PATH_TEXT tem um tamanho máximo de dados de 64 KB. Portanto, se algum registro JSON for maior que 64 KB, processá-lo com JSON_EXTRACT_PATH_TEXT vai gerar um erro.

• Associação de um fluxo do Amazon Kinesis Data Streams ou de um tópico do Amazon MSK a uma visão materializada de ingestão de streaming do Amazon Redshift: não recomendamos criar várias visões materializadas de ingestão de streaming para ingerir dados de um único fluxo do Amazon Kinesis Data Streams ou de um tópico do Amazon MSK. Isso ocorre porque cada visão materializada cria um consumidor para cada fragmento no fluxo do Kinesis Data Streams ou no tópico do Kafka. Isso pode ocasionar controle de utilização ou throughput excessivo do fluxo ou do tópico. Também pode gerar custos mais altos, já que você está ingerindo os mesmos dados várias vezes. Recomendamos criar uma visão materializada de streaming para cada fluxo ou tópico.

  Se o caso de uso exigir que você coloque os dados de um fluxo do KDS ou do tópico do MSK em várias visões materializadas, antes de fazer isso, consulte o AWS Big Data Blog, especificamente Best practices to implement near-real-time analytics using Amazon Redshift Streaming Ingestion with Amazon MSK.

Comparação entre ingestão de streaming e preparação de dados no Amazon S3

Há várias opções para realizar streaming de dados para o Amazon Redshift ou para o Amazon Redshift sem servidor. Duas opções conhecidas são a ingestão de streaming, descrita neste tópico, ou a configuração de um fluxo de entrega para o Amazon S3 com o Firehose. A seguinte lista descreve cada método:

1. A ingestão de streaming do Kinesis Data Streams ou do Amazon Managed Streaming for Apache Kafka para o Amazon Redshift ou Amazon Redshift sem servidor requer a configuração de uma visão materializada para receber os dados.

2. Para entregar dados ao Amazon Redshift usando o Kinesis Data Streams e transmiti-los por meio do Firehose, é necessário conectar o fluxo de origem ao Amazon Data Firehose e esperar que o Firehose prepare os dados no Amazon S3. Esse processo utiliza lotes de vários tamanhos em intervalos de buffer de duração variável. Após a transmissão para o Amazon S3, o Firehose inicia um comando COPY para carregar os dados.

Com a ingestão de streaming, você ignora várias etapas que são necessárias no segundo processo:

• Não é necessário enviar dados para um fluxo de entrega do Amazon Data Firehose porque, com a ingestão de streaming, os dados podem ser enviados diretamente do Kinesis Data Streams a uma visão materializada em um banco de dados do Redshift.

• Não é necessário descarregar os dados transmitidos no Amazon S3 porque os dados de ingestão de streaming vão diretamente para a visão materializada do Redshift.

• Não é necessário gravar e executar comandos COPY porque os dados na visão materializada são atualizados diretamente do fluxo. O carregamento de dados do Amazon S3 para o Redshift não faz parte do processo.

Observe que a ingestão de streaming é limitada a fluxos do Amazon Kinesis Data Streams e tópicos do Amazon MSK. Para transmitir do Kinesis Data Streams para destinos diferentes do Amazon Redshift, você provavelmente vai precisar de um fluxo de entrega do Firehose. Para obter mais informações, consulte Sending Data to an Amazon Data Firehose Delivery Stream.

Considerações

Veja a seguir as considerações para a ingestão de streaming no Amazon Redshift.

Recurso ou comportamento	Descrição
Limite de tamanho de tópicos do Kafka	Não é possível usar um tópico do Kafka com um nome maior que 128 caracteres (sem incluir aspas). Para obter mais informações, consulte Nomes e identificadores.
Atualizações e JOINs incrementais em uma visão materializada	A exibição materializada deve poder ser mantida de forma incremental. Não é possível realizar recálculo completo para o Kinesis ou Amazon MSK porque eles não preservam o histórico de fluxos ou tópicos após 24 horas ou 7 dias, por padrão. Você pode definir períodos de retenção de dados mais longos no Kinesis ou no Amazon MSK. No entanto, isso pode resultar em mais manutenção e custo. Além disso, atualmente não há suporte para JOINs em visões materializadas criadas em um fluxo do Kinesis ou em um tópico do Amazon MSK. Depois de criar uma visão materializada em seu fluxo ou tópico, você pode criar outra visão materializada para unir a visão materializada de streaming a outras visões materializadas, tabelas ou visões. Para obter mais informações, consulte ATUALIZAR EXIBIÇÃO MATERIALIZADA.
Análise de registros	A ingestão de streaming do Amazon Redshift não oferece suporte à análise de registros que foram agregados pela Kinesis Producer Library (Conceitos chave da KPL - Agregação). Os registros agregados são ingeridos, mas são armazenados como dados de buffer de protocolo binário. (Consulte Buffers de protocolo para obter mais informações.) Dependendo de como você envia dados para o Kinesis, talvez seja necessário desativar esse recurso.
Descompressão	No momento, VARBYTE não é compatível com nenhum método de descompressão. Por causa disso, registros contendo dados compactados não podem ser consultados no Redshift. Descompacte seus dados antes de enviá-los para o fluxo do Kinesis ou para o tópico do Amazon MSK.
Tamanho máximo do registro	O tamanho máximo de qualquer campo de registro que o Amazon Redshift consegue ingerir do Kinesis ou do Amazon MSK é um pouco menos de 1 MB. Os pontos a seguir detalham o comportamento: Comprimento máximo de VARBYTE: para ingestão de streaming, o tipo VARBYTE é compatível com um comprimento de dados máximo de 1.024.000 bytes. O Kinesis limita a carga útil a 1 MB. Limites de mensagens: a configuração padrão do Amazon MSK limita as mensagens a 1 MB. Além disso, se uma mensagem incluir cabeçalhos, a quantidade de dados será limitada a 1.048.470 bytes. Com as configurações padrão, não há problemas com a ingestão. No entanto, você pode alterar o tamanho máximo de mensagem para o Kafka, bem como para o Amazon MSK, para um valor maior. Nesse caso, talvez seja possível que o campo de chave/valor de um registro do Kafka, ou do cabeçalho, exceda o limite de tamanho. Esses registros podem causar um erro e não serem ingeridos. nota O Amazon Redshift permite um tamanho máximo de 1.024.000 bytes para ingestão de streaming do Kinesis ou do Amazon MSK, embora o Amazon Redshift permita um tamanho máximo de 16 MB para o tipo de dados VARBYTE.
Registros de erros	Em cada caso em que um registro não pode ser ingerido no Redshift porque o tamanho dos dados excede o tamanho máximo, esse registro é ignorado. A atualização da visão materializada ainda é bem-sucedida, nesse caso, e um segmento de cada registro de erro é gravado na tabela do sistema SYS_STREAM_SCAN_ERRORS. Erros resultantes da lógica comercial, como um erro em um cálculo ou um erro resultante de uma conversão de tipo, não são ignorados. Antes de adicionar lógica à sua definição de visão materializada, teste a lógica com cuidado para evitá-las.
Amazon MSK Multi-VPC private connectivity	No momento, a conectividade privada de várias VPCs do Amazon MSK não é compatível com a ingestão de streaming do Redshift. Uma alternativa é usar o emparelhamento de VPC para conectar VPCs ou o AWS Transit Gateway para conectar VPCs e redes on-premises em um hub central. Qualquer um deles permite que o Redshift se comunique com um cluster do Amazon MSK ou com o Amazon MSK Sem Servidor em outra VPC.