Time stamps e a coluna ROWTIME - Guia do desenvolvedor do Amazon Kinesis Data Analytics SQL para aplicativos
Compreensão de vários horários da análise de streaming

Para novos projetos, recomendamos que você use o novo Managed Service para Apache Flink Studio em vez do Kinesis Data Analytics for Applications. SQL O Managed Service for Apache Flink Studio combina facilidade de uso com recursos analíticos avançados, permitindo que você crie aplicativos sofisticados de processamento de stream em minutos.

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á.

Time stamps e a coluna ROWTIME

Os streams no aplicativo incluem uma coluna especial chamada ROWTIME. Ela armazena um timestamp quando o Amazon Kinesis Data Analytics insere uma linha no primeiro stream do aplicativo. ROWTIME reflete o timestamp no qual o Amazon Kinesis Data Analytics inseriu um registro no primeiro stream no aplicativo após ler a partir da fonte de streaming. Esse valor ROWTIME então é mantido em todo o aplicativo.

nota

Quando você bombeia registros de um stream no aplicativo para outro, não precisa copiar explicitamente a coluna ROWTIME, o Amazon Kinesis Data Analytics copia esta coluna para você.

O Amazon Kinesis Data Analytics garante que os valores ROWTIME sejam monotonicamente aumentados. É possível usar esse time stamp nas consultas em janelas baseadas em tempo. Para ter mais informações, consulte Consultas em janelas.

Você pode acessar a coluna ROWTIME na instrução SELECT como qualquer outra coluna no fluxo no aplicativo. Por exemplo: .

SELECT STREAM ROWTIME, 
              some_col_1, 
              some_col_2
FROM  SOURCE_SQL_STREAM_001

Compreensão de vários horários da análise de streaming

Além do ROWTIME, há outros tipos de horários em aplicativos de streaming em tempo real. Eles são:

  • Horário do evento: o time stamp em que o evento ocorreu. Isso também é às vezes chamado de horário do cliente. Muitas vezes, é desejável usar esse horário em análises, porque é o momento em que um evento ocorreu. No entanto, muitas fontes de eventos, como celulares e clientes da Web, não têm relógios confiáveis, o que pode levar a horários imprecisos. Além disso, problemas de conectividade podem levar a registros que aparecem em um stream não na mesma ordem em que os eventos ocorreram.

     

  • Horário de ingestão: o time stamp de quando o registro foi adicionada à origem de streaming. O Amazon Kinesis Data Streams inclui um campo chamado APPROXIMATE_ARRIVAL_TIME em cada registro que fornece esse time stamp. Isso também é às vezes chamado de horário do servidor. Esse horário de inclusão normalmente está muito próximo do horário do evento. Se houver qualquer tipo de atraso na inclusão do registro no stream, pode haver imprecisões, que são normalmente raras. Além disso, o horário de inclusão raramente está fora de ordem, mas pode ocorrer devido à natureza distribuída dos dados de streaming. Portanto, o horário de inclusão é na maioria das vezes preciso e reflete a ordem do horário do evento.

     

  • Horário do processamento: o time stamp quando o Amazon Kinesis Data Analytics insere uma linha no primeiro stream no aplicativo. O Amazon Kinesis Data Analytics fornece esse time stamp na coluna ROWTIME existente em cada stream no aplicativo. O tempo de processamento está sempre aumentando monotonicamente. Mas ele não será preciso se o aplicativo ficar atrasado. (Se um aplicativo ficar atrasado, o tempo de processamento não refletirá com precisão o horário do evento.) Esse ROWTIME é preciso em relação ao relógio, mas pode não representar o horário em que o evento realmente ocorreu.

Usar cada um desses horários nas consultas em janelas baseadas em horário tem vantagens e desvantagens. Recomendamos que você escolha um ou mais desses horários e uma estratégia para lidar com as desvantagens relevantes de acordo com o caso de uso.

nota

Se você estiver usando janelas baseadas em linha, o horário não será um problema e você poderá ignorar esta seção.

Recomendamos uma estratégia de duas janelas que usam dois horários, o ROWTIME e um dos outros horários (de inclusão ou do evento).

  • Use o ROWTIME como a primeira janela, que controla a frequência com que a consulta emite os resultados, como mostrado no exemplo a seguir. Ele não é usado como um horário lógico.

  • Use um dos outros horários lógicos que deseja associar à sua análise. Esse horário representa quando o evento ocorreu. No exemplo a seguir, o objetivo da análise é agrupar os registros e retornar a contagem pelo marcador.

A vantagem dessa estratégia é que ela pode usar um horário que representa o momento em que o evento ocorreu. Ela pode lidar tranquilamente com atrasos de seu aplicativo ou com a chegada de eventos fora de ordem. Se o aplicativo atrasar ao colocar registros no stream no aplicativo, eles ainda estarão agrupados pelo horário lógico na segunda janela. A consulta usa o ROWTIME para garantir a ordem de processamento. Todos os registros atrasados (o time stamp de inclusão mostra um valor anterior comparado com o valor do ROWTIME) também são processados com êxito.

Considere a seguinte consulta em relação ao fluxo de demonstração usado no Exercício de conceitos básicos. A consulta usa a cláusula GROUP BY e emite uma contagem do marcador em uma janela em cascata de um minuto. 

CREATE OR REPLACE STREAM "DESTINATION_SQL_STREAM" 
    ("ingest_time"    timestamp,
    "APPROXIMATE_ARRIVAL_TIME" timestamp,
    "ticker_symbol"  VARCHAR(12), 
    "symbol_count"        integer);
            
            
CREATE OR REPLACE PUMP "STREAM_PUMP" AS
    INSERT INTO "DESTINATION_SQL_STREAM"
    SELECT STREAM STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND) AS "ingest_time",
        STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND) AS "APPROXIMATE_ARRIVAL_TIME",
        "TICKER_SYMBOL",
        COUNT(*) AS "symbol_count"
    FROM "SOURCE_SQL_STREAM_001"
    GROUP BY "TICKER_SYMBOL",
        STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND),
        STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND);

No GROUP BY, primeiro agrupe os registros baseados no ROWTIME em uma janela de um minuto e, em seguida, pelo APPROXIMATE_ARRIVAL_TIME.

Os valores de time stamp no resultado são arredondados para baixo para o intervalo de 60 segundos mais próximo. O primeiro grupo de resultados emitidos pela consulta mostra registros no primeiro minuto. O segundo grupo de resultados emitidos mostra os registros nos próximos minutos com base no ROWTIME. O último registro indica que o aplicativo atrasou a entrega do registro no stream no aplicativo (ele mostra um valor ROWTIME atrasado em comparação com o time stamp de inclusão).

ROWTIME                  INGEST_TIME     TICKER_SYMBOL  SYMBOL_COUNT

--First one minute window.
2016-07-19 17:05:00.0    2016-07-19 17:05:00.0    ABC      10
2016-07-19 17:05:00.0    2016-07-19 17:05:00.0    DEF      15
2016-07-19 17:05:00.0    2016-07-19 17:05:00.0    XYZ      6
–-Second one minute window.
2016-07-19 17:06:00.0    2016-07-19 17:06:00.0    ABC      11
2016-07-19 17:06:00.0    2016-07-19 17:06:00.0    DEF      11
2016-07-19 17:06:00.0    2016-07-19 17:05:00.0    XYZ      1  *** 

***late-arriving record, instead of appearing in the result of the 
first 1-minute windows (based on ingest_time, it is in the result 
of the second 1-minute window.

É possível combinar os resultados de uma contagem final precisa por minuto enviando os resultados para um banco de dados de downstream. Por exemplo, você pode configurar a saída do aplicativo para manter os resultados em um stream de entrega do Firehose que pode ser gravado em uma tabela do Amazon Redshift. Depois que os resultados estiverem em uma tabela do Amazon Redshift, será possível consultar esta tabela para calcular o grupo de contagem total pelo Ticker_Symbol. No caso do XYZ, o total é preciso (6+1), mesmo que um registro chegue atrasado.