Particionamento personalizado de saída de blobs do Azure Stream Analytics

O Azure Stream Analytics dá suporte ao particionamento de saída de blob personalizado com campos ou atributos personalizados e padrões de caminho personalizados DateTime .

Campo ou atributos personalizados

Os atributos de campo ou entrada personalizados melhoram o processamento de dados downstream e os fluxos de trabalho de relatórios, permitindo mais controle sobre a saída.

Opções de chave de partição

A chave de partição, ou nome da coluna, usada para particionar os dados de entrada pode conter qualquer carácter aceite para nomes de blobs. Não podes usar campos aninhados como chave de partição a menos que os uses juntamente com aliases. No entanto, você pode usar determinados caracteres para criar uma hierarquia de arquivos. Por exemplo, para criar uma coluna que combina dados de duas outras colunas para criar uma chave de partição exclusiva, você pode usar a seguinte consulta:

SELECT name, id, CONCAT(name, "/", id) AS nameid

A chave de partição deve ser NVARCHAR(MAX), BIGINT, FLOAT, ou BIT (nível de compatibilidade 1.2 ou superior). Os DateTimetipos , Array, e Records não são suportados, mas podem ser usados como chaves de partição se forem convertidos em cadeias de caracteres. Para obter mais informações, consulte Tipos de dados do Azure Stream Analytics.

Particionar a saída de blob com base num campo personalizado

Suponha que um trabalho recebe dados de entrada de sessões de usuário ao vivo conectadas a um serviço de videogame externo onde os dados ingeridos contêm uma coluna client_id para identificar as sessões. Para particionar os dados por client_id, defina o campo Padrão de caminho de blob para incluir um token {client_id} de partição nas propriedades de saída de blob ao criar um trabalho. À medida que os dados com vários client_id valores fluem através do trabalho do Stream Analytics, os dados de saída são salvos em pastas separadas com base em um único client_id valor por pasta.

Captura de tela que mostra o padrão de caminho com a ID do cliente.

Da mesma forma, se a entrada do trabalho fossem dados de milhões de sensores, onde cada sensor tivesse um sensor_id, o padrão de caminho {sensor_id} seria usado para particionar os dados de cada sensor em pastas diferentes.

Quando você usa a API REST, a seção de saída de um arquivo JSON usado para essa solicitação pode se parecer com a seguinte imagem:

Captura de ecrã que mostra a configuração de saída REST API JSON para armazenamento de blobs.

Depois que o trabalho começar a ser executado, o clients contêiner poderá se parecer com a seguinte imagem:

Captura de tela que mostra o contêiner de clientes.

Cada pasta pode conter vários blobs onde cada blob contém um ou mais registros. No exemplo anterior, há um único blob em uma pasta rotulada "06000000" com o seguinte conteúdo:

Captura de ecrã que mostra o conteúdo do blob com os registos do ID do cliente.

Observe que cada registro no blob tem uma client_id coluna correspondente ao nome da pasta porque a coluna usada para particionar a saída no caminho de saída era client_id.

Limitações de chaves de partição personalizadas

  1. Apenas uma chave de partição personalizada é permitida na propriedade de saída do blob do padrão do caminho. Todos os seguintes padrões de caminho são válidos:

    • cluster1/{date}/{aFieldInMyData}
    • cluster1/{time}/{aFieldInMyData}
    • cluster1/{aFieldInMyData}
    • cluster1/{date}/{time}/{aFieldInMyData}
  2. Se quiser usar mais do que um campo de entrada, pode criar uma chave composta numa consulta para partição de caminho personalizada na saída blob usando CONCAT. Um exemplo é select concat (col1, col2) as compositeColumn into blobOutput from input. Depois podes especificar compositeColumn como o caminho personalizado no Armazenamento de Blobs do Azure.

  3. As chaves de partição não diferenciam maiúsculas de minúsculas, portanto, chaves de partição como John e john são equivalentes. Além disso, não podes usar expressões como chaves de partição. Por exemplo, {columnA + columnB} não funciona.

  4. Quando um fluxo de entrada consiste em registos com uma cardinalidade de chave de partição inferior a 8.000, o Stream Analytics adiciona os registos a blobs existentes e só cria novos blobs quando necessário. Se a cardinalidade for superior a 8.000, não há garantia de que o Stream Analytics escreva em blobs existentes. O Stream Analytics não cria novos blobs para um número arbitrário de registos com a mesma chave de partição.

  5. Se a saída do blob estiver configurada como imutável, o Stream Analytics criará um novo blob cada vez que os dados forem enviados.

Padrões de caminho DateTime personalizados

Os padrões de caminho personalizados DateTime permitem especificar um formato de saída alinhado com as convenções de Streaming do Hive, dando ao Stream Analytics a capacidade de enviar dados para o Azure HDInsight e o Azure Databricks para processamento downstream. Os padrões de caminho personalizados DateTime são facilmente implementados utilizando a palavra-chave datetime no campo Prefixo do Caminho da saída de blob, juntamente com o especificador de formato. Um exemplo é {datetime:yyyy}.

Tokens suportados

Os seguintes tokens especificadores de formato podem ser usados sozinhos ou em combinação para obter formatos personalizados DateTime .

Especificador de formato Descrição Resultados no momento do exemplo 2018-01-02T10:06:08
{datetime:aaaa} O ano como um número de quatro dígitos 2018
{datetime:MM} Mês de 01 a 12 01
{datetime:M} Mês de 1 a 12 1
{datetime:dd} Dia de 01 a 31 02
{datetime:d} Dia de 1 a 31 2
{datetime:HH} Hora usando o formato de 24 horas, de 00 a 23 10
{datetime:mm} Minutos de 00 a 60 06
{datetime:m} Minutos de 0 a 60 6
{datetime:ss} Segundos de 00 a 60 08

Se não quiser usar padrões personalizados DateTime, pode adicionar o token {date} e/ou {time} ao campo Prefixo do Caminho para gerar uma lista suspensa com formatos internos DateTime.

Captura de ecrã que mostra os formatos DateTime antigos do Stream Analytics.

Extensibilidade e restrições do token DateTime

Você pode usar quantos tokens ({datetime:<specifier>}) quiser no modelo de caminho até atingir o limite de caracteres do prefixo do caminho. Os especificadores de formato não podem ser combinados em um único token além das combinações já listadas pelos menus suspensos de data e hora.

Para uma partição de caminho de logs/MM/dd:

Expressão válida Expressão inválida
logs/{datetime:MM}/{datetime:dd} logs/{datetime:MM/dd}

Você pode usar o mesmo especificador de formato várias vezes no prefixo do caminho. O token deve ser repetido todas as vezes.

Convenções de streaming do Hive

Pode utilizar padrões de caminho personalizados para o Armazenamento de Blobs com a convenção Hive Streaming, que espera que as pastas sejam identificadas com column= no nome da pasta.

Um exemplo é year={datetime:yyyy}/month={datetime:MM}/day={datetime:dd}/hour={datetime:HH}.

A saída personalizada elimina o incômodo de alterar tabelas e adicionar partições manualmente para portar dados entre o Stream Analytics e o Hive. Em vez disso, muitas pastas podem ser adicionadas automaticamente usando:

MSCK REPAIR TABLE while hive.exec.dynamic.partition true

Criar uma estrutura de pastas DateTime compatível com Hive

Crie uma conta de armazenamento, um grupo de recursos, um job de Stream Analytics e uma fonte de entrada de acordo com o início rápido do portal do Azure Stream Analytics. Use os mesmos dados de exemplo usados no início rápido. Dados de exemplo também estão disponíveis no GitHub.

Crie um coletor de saída de blob com a seguinte configuração:

Captura de tela que mostra o coletor de saída de blob criado pelo Stream Analytics.

O padrão de caminho completo é:

year={datetime:yyyy}/month={datetime:MM}/day={datetime:dd}

Quando você inicia o trabalho, uma estrutura de pastas com base no padrão de caminho é criada no contêiner de blob. Pode analisar detalhadamente até ao nível do dia.

Captura de tela que mostra a saída de blob do Stream Analytics com padrão de caminho personalizado.