Particionamento de saída de blob personalizado 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, usado para particionar dados de entrada pode conter qualquer caractere aceito para nomes de blob. Não é possível usar campos aninhados como uma chave de partição, a menos que eles sejam usados junto 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.

Exemplo

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.

Da mesma forma, se a entrada do trabalho fosse dados de sensores de milhões de sensores onde cada sensor tivesse um sensor_id, o padrão de caminho seria {sensor_id} particionar cada dado do sensor para 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:

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

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:

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

1. Apenas uma chave de partição personalizada é permitida na propriedade de saída de blob do padrão de 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 os clientes quiserem usar mais de um campo de entrada, eles poderão criar uma chave composta na consulta para partição de caminho personalizado na saída de blob usando CONCAT. Um exemplo é select concat (col1, col2) as compositeColumn into blobOutput from input. Em seguida, eles podem 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, as chaves de partição gostam John e john são equivalentes. Além disso, as expressões não podem ser usadas como chaves de partição. Por exemplo, {columnA + columnB} não funciona.

4. Quando um fluxo de entrada consiste em registros com uma cardinalidade de chave de partição inferior a 8.000, os registros são anexados aos blobs existentes. Eles só criam novas bolhas quando necessário. Se a cardinalidade for superior a 8.000, não há garantia de que os blobs existentes serão gravados. Novos blobs não serão criados para um número arbitrário de registros 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 usando a datetime palavra-chave no campo Prefixodo 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	Description	Resultados no tempo de 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 personalizadosDateTime, você pode adicionar o e/ou {time} token ao campo Prefixo {date} do caminho para gerar uma lista suspensa com formatos internosDateTime.

Extensibilidade e restrições

Você pode usar quantos tokens ({datetime:<specifier>}) quiser no padrão 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

Os padrões de caminho personalizados para o Armazenamento de Blobs podem ser usados com a convenção Hive Streaming, que espera que as pastas sejam rotuladas com column= o 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

Exemplo

Crie uma conta de armazenamento, um grupo de recursos, um trabalho do Stream Analytics e uma fonte de entrada de acordo com o início rápido do portal do Azure do 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:

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. Você pode detalhar até o nível do dia.

Conteúdos relacionados

• Compreender as saídas do Azure Stream Analytics