Criação de partições de saída de blobs personalizadas do Azure Stream Analytics

O Azure Stream Analytics suporta a criação de partições de saída de blobs personalizadas com campos ou atributos personalizados e padrões de caminho DateTime personalizados.

Campo ou atributos personalizados

Os atributos de entrada ou campo personalizados melhoram os fluxos de trabalho de relatórios e processamento de dados a jusante, permitindo um maior controlo sobre a saída.

Opções da chave de partição

A chave de partição, ou nome da coluna, utilizada para particionar dados de entrada pode conter qualquer caráter que seja aceite para nomes de blobs. Não é possível utilizar campos aninhados como uma chave de partição, a menos que seja utilizado em conjunto com aliases, mas pode utilizar determinados carateres para criar uma hierarquia de ficheiros. Por exemplo, pode utilizar a seguinte consulta para criar uma coluna que combina dados de duas outras colunas para criar uma chave de partição exclusiva.

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

A chave de partição tem de ser NVARCHAR(MAX), BIGINT, FLOAT ou BIT (nível de compatibilidade 1.2 ou superior). Os tipos DateTime, Array e Records não são suportados, mas podem ser utilizados como chaves de partição se forem convertidos em Cadeias. Para obter mais informações, veja Tipos de Dados do Azure Stream Analytics.

Exemplo

Suponha que uma tarefa recebe dados de entrada de sessões de utilizador em direto ligadas a um serviço de videojogos 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 do Caminho do Blob para incluir um token de partição {client_id} nas propriedades de saída do blob ao criar uma tarefa. À medida que os dados com vários valores client_id fluem através da tarefa do Stream Analytics, os dados de saída são guardados em pastas separadas com base num único valor client_id por pasta.

Da mesma forma, se a entrada da tarefa fosse dados de sensores de milhões de sensores em que cada sensor tinha uma sensor_id, o Padrão de Caminho seria {sensor_id} para particionar cada dados do sensor para pastas diferentes.

Quando utiliza a API REST, a secção de saída de um ficheiro JSON utilizado para esse pedido poderá ter o seguinte aspeto:

Assim que a tarefa começar a ser executada, o clients contentor poderá ter o seguinte aspeto:

Cada pasta pode conter vários blobs em que cada blob contém um ou mais registos. No exemplo acima, existe um único blob numa pasta com o nome "06000000" com o seguinte conteúdo:

Repare que cada registo no blob tem uma coluna client_id que corresponde ao nome da pasta, uma vez que a coluna utilizada para particionar a saída no caminho de saída foi client_id.

Limitações

1. Só é permitida uma chave de partição personalizada na propriedade de saída do blob 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 utilizar mais do que um campo de entrada, podem criar uma chave composta na consulta para a partição de caminho personalizado na saída do blob através do CONCAT. Por exemplo: selecione concat (col1, col2) como compositeColumn em blobOutput a partir da entrada. Em seguida, podem especificar compositeColumn como o caminho personalizado no armazenamento de blobs.

3. As chaves de partição não são sensíveis a maiúsculas e minúsculas, pelo que as chaves John de partição são equivalentes.john Além disso, as expressões não podem ser utilizadas 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 8000, os registos são anexados a blobs existentes e só criam novos blobs quando necessário. Se a cardinalidade for superior a 8000, não há garantia de que os blobs existentes serão escritos e não serão criados 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 cria um novo blob sempre que os dados são enviados.

Padrões de caminho DateTime personalizados

Os padrões de caminho DateTime personalizados permitem-lhe especificar um formato de saída que se alinha com as convenções de Transmissão em Fluxo do Hive, dando ao Azure Stream Analytics a capacidade de enviar dados para o Azure HDInsight e o Azure Databricks para processamento a jusante. Os padrões de caminho DateTime personalizados são facilmente implementados com a datetime palavra-chave no campo Prefixo caminho da saída do blob, juntamente com o especificador de formato. Por exemplo, {datetime:yyyy}.

Tokens suportados

Os tokens do especificador de formato seguintes podem ser utilizados individualmente ou em combinação para obter formatos DateTime personalizados:

Especificador de formato	Descrição	Resultados na hora de exemplo 2018-01-02T10:06:08
{datetime:yyyy}	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 com 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 utilizar padrões DateTime personalizados, pode adicionar o token {date} e/ou {time} ao Prefixo do Caminho para gerar uma lista pendente com formatos DateTime incorporados.

Extensibilidade e restrições

Pode utilizar o número de tokens que {datetime:<specifier>}quiser no padrão de caminho até atingir o limite de carateres do Prefixo de Caminho. Os especificadores de formato não podem ser combinados num único token para além das combinações já listadas pelas listas pendentes 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}

Pode utilizar o mesmo especificador de formato várias vezes no Prefixo caminho. O token tem de ser repetido sempre.

Convenções de Transmissão em Fluxo do Hive

Os padrões de caminho personalizados para o armazenamento de blobs podem ser utilizados com a convenção de Transmissão em Fluxo do Hive, que espera que as pastas sejam etiquetadas com column= no nome da pasta.

Por 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 manualmente partições aos dados de porta entre o Azure Stream Analytics e o Hive. Em vez disso, muitas pastas podem ser adicionadas automaticamente com:

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

Exemplo

Crie uma conta de armazenamento, um grupo de recursos, uma tarefa do Stream Analytics e uma origem de entrada de acordo com o guia de início rápido do Azure Stream Analytics portal do Azure. Utilize os mesmos dados de exemplo utilizados no guia de início rápido, também disponíveis no GitHub.

Crie um sink de saída de blobs com a seguinte configuração:

O padrão de caminho completo é o seguinte:

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

Quando inicia a tarefa, é criada uma estrutura de pastas com base no padrão de caminho no contentor de blobs. Pode desagregar até ao nível do dia.

Passos seguintes

• Compreender as saídas do Azure Stream Analytics