Práticas recomendadas

Configurar CloudWatch alarmes da Amazon — Você pode usar as CloudWatch métricas que o Kinesis Data Analytics fornece para monitorar o seguinte:

Recomendamos que você configure pelo menos dois CloudWatch alarmes nas seguintes métricas para seus aplicativos em produção:

Para evitar a exceção ReadProvisionedThroughputException, restrinja o número de aplicativos de produção que leem o mesmo streaming de dados do Kinesis a dois aplicativos.

O Amazon Kinesis Data Analytics lê uma origem de streaming aproximadamente uma vez a cada segundo por aplicativo. No entanto, um aplicativo atrasado pode ler dados a uma taxa mais rápida para sair do atraso. Para permitir que o throughput adequado dos aplicativos seja alcançado, limite o número de aplicativos que leem a mesma fonte de dados.

Limite o número de aplicações de produção que leem o mesmo fluxo de entrega do Firehose a uma aplicação.

Um fluxo de entrega do Firehose pode gravar em vários destinos, como Amazon S3 e Amazon Redshift. Pode ser também uma origem de streaming para o aplicativo Kinesis Data Analytics. Portanto, é recomendável não configurar mais de uma aplicação do Kinesis Data Analytics por fluxo de entrega do Firehose. Isso ajuda a garantir que o fluxo de entrega também possa realizar a entrega para outros destinos.

Use vários fluxos e o Kinesis Data Analytics para aplicativos SQL se o aplicativo tiver necessidades de dimensionamento além de 100 MB/segundo.

Use o Managed Service for Apache Flink Applications se quiser usar um único stream e aplicativo.

O maior throughput que recomendamos para um único fluxo no aplicativo é entre 2 e 20 MB/segundo, dependendo da complexidade da consulta do aplicativo.

O throughput máximo de streaming que um único aplicativo Kinesis Data Analytics para SQL pode processar é de aproximadamente 100 MB/seg. Isso pressupõe que você aumentou o número de streams no aplicativo para o valor máximo de 64 e aumentou seu limite de KPU para além de 8. Para obter mais informações, consulte Limites.

Teste adequadamente o esquema inferido. O processo de descoberta usa somente uma amostra dos registros na origem de streaming para inferir um esquema. Se a origem de streaming tiver vários tipos de registro, pode ser que a API de descoberta não tenha feito amostragem de um ou mais tipos de registro. Essa situação pode resultar em um esquema que não reflete precisamente os dados na origem de streaming.

Quando o aplicativo for iniciado, esses tipos de registro perdidos poderão resultar em erros de análise. O Amazon Kinesis Data Analytics envia esses registros ao stream de erros de aplicativo. Para reduzir esses erros de análise, é recomendável testar o esquema inferido de modo interativo no console e monitorar o fluxo do aplicativo em busca de registros perdidos.

A API do Kinesis Data Analytics não permite a especificação da restrição NOT NULL em colunas na configuração de entrada. Se desejar restrições NOT NULL em colunas no fluxo do aplicativo, crie esses fluxos de aplicativo usando o código do aplicativo. Em seguida, você pode copiar dados de um fluxo de aplicativo para outro que e a restrição será aplicada.

Qualquer tentativa de inserir linhas com valores NULL quando um valor é necessário resultará em um erro. O Kinesis Data Analytics envia esses erros ao fluxo de erros de aplicativo.

Reduz os tipos de dados inferidos pelo processo de descoberta. O processo de descoberta recomenda colunas e tipos de dados com base em uma amostragem aleatória de registros na origem de streaming. É recomendável que você os analise cuidadosamente e considere a redução desses tipos de dados para cobrir todos os casos possíveis de registros na entrada. Isso garante menos erros de análise em todo o aplicativo enquanto ela está sendo executada. Por exemplo, se um esquema inferido tiver SMALLINT como tipo de coluna, talvez seja recomendável alterá-lo para INTEGER.

Use funções SQL no código do aplicativo para tratar quaisquer dados ou colunas não estruturados. Talvez você tenha ter dados ou colunas não estruturados na entrada, como dados de log. Para obter exemplos, consulte Exemplo: Transformação de valores DateTime . Uma forma de tratar esse tipo de dados é definir o esquema com apenas uma coluna do tipo VARCHAR(N), em que N é o maior linha possível esperada no fluxo. No código do aplicativo, você pode ler os registros de entrada e usar as funções String e Date Time para analisar e esquematizar os dados brutos.

Trate totalmente os dados da origem de streaming que contêm aninhamento com mais de dois níveis de profundidade. Quando os dados de origem forem JSON, você poderá ter aninhamento. A API de descoberta infere um esquema que nivela um nível de aninhamento. No caso de dois níveis de aninhamento, a API de descoberta tenta nivelá-los. Para mais de dois níveis de aninhamento, o suporte a nivelamento é limitado. Para tratar completamente o aninhamento, é necessário modificar manualmente o esquema inferido para atender às suas necessidades. Use uma das seguintes estratégias para fazer isso:

Use o primeiro destino para inserir os resultados das consultas SQL.

Use o segundo destino para inserir todo o fluxo de erros e enviá-lo a um bucket do S3 por meio de um fluxo de entrega do Firehose.

Na instrução SQL, não especifique uma janela de tempo mais extensa do que uma hora, pelos seguintes motivos:

Durante o desenvolvimento, use um tamanho de janela pequeno nas instruções SQL para que possa ver os resultados com maior rapidez. Quando você implantar o aplicativo no ambiente de produção, poderá definir o tamanho da janela conforme apropriado.

Em vez de uma única instrução SQL complexa, é recomendável dividi-la em várias instruções, em cada etapa, e salvar os resultados em fluxos de aplicativo intermediários. Isso pode ajudar a agilizar a depuração.

Ao usar janelas em cascata, é recomendável usar duas janelas, uma para tempo de processamento e outra para tempo lógico (horário da conclusão ou horário do evento). Para obter mais informações, consulte Time stamps e a coluna ROWTIME.

Use o Kinesis Data Generator (KDG). O KDG usa um modelo de dados para enviar dados aleatórios para um fluxo do Kinesis. O KDG é simples de usar, mas não é apropriado para testar relações complexas entre itens de dados, como para aplicativos que detectam pontos de acesso a dados ou anomalias.

Use um aplicativo Python personalizado para enviar dados mais complexos para um fluxo de dados do Kinesis. Um aplicativo Python pode gerar relações complexas entre itens de dados, como pontos de acesso ou anomalias. Para obter um exemplo de aplicativo Python que envia dados clusterizados em um hotspot de dados, consulte Exemplo: detectar hotspots em um streaming (função HOTSPOTS).

Os dados do fluxo estão sendo compelidos para o tipo de dado correto. Por exemplo, verifique se os dados de data e hora não estão sendo ingeridos no aplicativo como uma string.

Os dados estão sendo analisados e impelidos para o tipo de dado que você deseja. Se ocorrerem erros de análise ou coerção, você pode visualizá-los no console ou atribuir um destino no fluxo de erros e visualizar os erros no armazenamento do destino.

Os campos de dados são para dados de caractere têm comprimento suficiente e o aplicativo não está truncando os dados de caractere. Você pode verificar os registros de dados no armazenar de destino para confirmar se os dados do aplicativo não está sendo truncados.