Sorties d’Azure Stream Analytics
Un travail Azure Stream Analytics se compose d’une entrée, d’une requête et d’une sortie. Plusieurs types de sorties vous permettent d’envoyer des données transformées. Cet article répertorie les sorties de Stream Analytics prises en charge. Lorsque vous concevez votre requête Stream Analytics, faites référence au nom de la sortie à l’aide de la clause INTO. Vous pouvez utiliser une seule sortie par travail ou, si nécessaire, plusieurs sorties par travail de diffusion en continu en ajoutant plusieurs clauses INTO à la requête.
Pour créer, modifier et tester des sorties de travail Stream Analytics, vous pouvez utiliser le portail Azure, Azure PowerShell, l’API .NET, l’API REST, Visual Studio et Visual Studio Code.
Remarque
Nous vous recommandons vivement d’utiliser les outils Stream Analytics pour Visual Studio Code pour une expérience de développement locale optimale. Il existe des lacunes au niveau des fonctionnalités dans les outils Stream Analytics pour Visual Studio 2019 (version 2.6.3000.0). Aucune amélioration ne sera apportée à l’avenir.
Certains types de sorties prennent en charge le partitionnement, comme indiqué dans le tableau suivant.
Toutes les sorties prennent en charge le traitement par lots, mais seules certaines prennent en charge la définition explicite de la taille du lot de sortie. Pour plus d'informations, consultez la section Tailles de lot de sortie.
Type de sortie | Partitionnement | Sécurité |
---|---|---|
Explorateur de données Azure | Oui | Identité managée |
Azure Functions | Oui | Clé d’accès |
Azure Synapse Analytics | Oui | Authentification utilisateur SQL, identité managée |
Stockage Blob et Azure Data Lake Gen 2 | Oui | Clé d’accès, identité managée |
Azure Cosmos DB | Oui | Clé d’accès, identité managée |
Azure Data Lake Storage Gen 2 | Oui | Utilisateur Microsoft Entra Identité managée |
Azure Event Hubs | Oui, vous devez définir la colonne clé de partition dans la configuration de sortie. | Clé d’accès, identité managée |
Kafka (Version préliminaire) | Oui, vous devez définir la colonne clé de partition dans la configuration de sortie. | Clé d’accès, identité managée |
Base de données Azure pour PostgreSQL | Oui | Authentification par nom d’utilisateur et mot de passe |
Power BI | Non | Utilisateur Microsoft Entra, Identité managée |
Files d’attente Azure Service Bus | Oui | Clé d’accès, identité managée |
Rubriques Azure Service Bus | Oui | Clé d’accès, identité managée |
Azure SQL Database | Oui, facultatif. | Authentification utilisateur SQL, identité managée |
Stockage Table Azure | Oui | Clé de compte |
Important
Azure Stream Analytics utilise l’API Insert ou Replace par conception. Cette opération remplace une entité existante ou insère une nouvelle entité si elle n’existe pas dans la table.
Partitionnement
Stream Analytics prend en charge les partitions pour toutes les sorties, à l’exception de Power BI. Pour plus d’informations sur les clés de partition et le nombre de générateurs de sortie, consultez l’article correspondant au type de sortie spécifique qui vous intéresse. Les articles pour les types de sortie sont liés dans la section précédente.
De plus, pour un réglage avancé des partitions, vous pouvez contrôler le nombre d’enregistreurs de sortie à l’aide d’une clause INTO <partition count>
(voir INTO) dans votre requête, ce qui peut ête utile pour atteindre la topologie de travail souhaitée. Si votre adaptateur de sortie n'est pas partitionné, l'absence de données dans une partition d'entrée entraîne un retard pouvant aller jusqu'au délai d'arrivée tardive. Dans ce cas, la sortie est fusionnée dans un seul enregistreur, ce qui peut créer des goulots d’étranglement dans votre pipeline. Pour en savoir plus sur la stratégie d’arrivée tardive, consultez l’article Considérations relatives à l’ordre des événements Azure Stream Analytics.
Taille de lot de sortie
Toutes les sorties prennent en charge le traitement par lots, mais seuls certains paramètres de prise en charge de la taille du lot sont explicitement pris en charge. Azure Stream Analytics utilise des lots de taille variable pour traiter les événements et générer les sorties. En général, le moteur Stream Analytics n’écrit pas les messages un par un ; il utilise des lots pour plus d’efficacité. Lorsque le taux des événements entrants et sortants est élevé, Stream Analytics utilise des lots plus volumineux. Lorsque le taux de sortie est faible, il utilise des lots plus petits pour maintenir une faible latence.
Comportement de fractionnement de fichiers Avro et Parquet
Une requête Stream Analytics peut générer plusieurs schémas pour une sortie donnée. La liste des colonnes projetées et leur type peuvent changer sur une base ligne par ligne. Par conception, les formats Avro et Parquet ne prennent pas en charge les schémas de variables dans un seul fichier.
Les comportements suivants peuvent se produire lors de la direction d'un flux avec des schémas de variables vers une sortie à l'aide de ces formats :
- Si la modification du schéma peut être détectée, le fichier de sortie actuel est fermé et un nouveau fichier est initialisé sur le nouveau schéma. Le fractionnement de fichiers ralentit grandement la sortie lorsque des modifications de schéma se produisent fréquemment. Ce comportement peut avoir un impact grave sur les performances globales du travail
- Si la modification du schéma ne peut pas être détectée, la ligne est probablement rejetée et le travail est bloqué, car la ligne ne peut pas être sortie. Les colonnes imbriquées ou les tableaux de types multiples sont des situations qui ne sont pas découvertes et qui sont rejetées.
Nous vous recommandons vivement de prendre en compte les sorties au format Avro afin qu'elles soient fortement typées, ou de schéma lors de l'écriture, et les requêtes qui les ciblent doivent être écrites comme telles (conversions explicites et projections pour un schéma uniforme).
Si plusieurs schémas doivent être générés, envisagez de créer plusieurs sorties et de fractionner des enregistrements dans chaque destination à l’aide d’une clause WHERE
.
Propriétés de la fenêtre de traitement par lot de la sortie Parquet
Lorsque vous utilisez le déploiement de modèle Azure Resource Manager ou l'API REST, les deux propriétés de la fenêtre de traitement par lot sont les suivantes :
timeWindow
Le délai d’attente maximum par lot. La valeur doit être une chaîne de
Timespan
. Par exemple,00:02:00
pour deux minutes. À l'issue de cette période, le lot est écrit dans la sortie même si l'exigence de lignes minimum n'est pas remplie. La valeur par défaut est de 1 minute et la valeur maximum autorisée est de 2 heures. Si la sortie de votre blob a une fréquence de modèle de chemin d’accès, le délai d’attente ne peut pas être supérieur à l’intervalle de temps de la partition.sizeWindow
Le nombre minimum de lignes par lot. Pour Parquet, chaque lot crée un fichier. La valeur par défaut actuelle est de 2 000 lignes et la valeur maximum autorisée est de 10 000 lignes.
Ces propriétés de fenêtre de traitement par lot sont uniquement prises en charge par la version d'API 2017-04-01-preview ou la version supérieure. Voici un exemple de la charge utile JSON pour un appel d'API REST :
"type": "stream",
"serialization": {
"type": "Parquet",
"properties": {}
},
"timeWindow": "00:02:00",
"sizeWindow": "2000",
"datasource": {
"type": "Microsoft.Storage/Blob",
"properties": {
"storageAccounts" : [
{
"accountName": "{accountName}",
"accountKey": "{accountKey}",
}
],