FAQ sur Amazon Data Firehose

Q : qu'est-ce que l'ETL de streaming ?

L'ETL de streaming est le traitement et le déplacement de données en temps réel d'un endroit à un autre. ETL est l'abréviation des fonctions d'extraction, de transformation et de chargement (Extract, Transform, Load) de la base de données. L'extraction fait référence à la collecte de données à partir d'une source. La transformation fait référence à tous les processus effectués sur ces données. La charge fait référence à l'envoi des données traitées vers une destination telle qu'un entrepôt, un lac de données ou un outil analytique.

Q : qu'est-ce qu'Amazon Data Firehose ?

Data Firehose est une solution ETL de streaming. C'est le moyen le plus simple de charger les données de streaming vers les magasins de données et les outils d'analytique. La solution collecte, transforme et charge les données en streaming dans Amazon S3, Amazon Redshift, Amazon OpenSearch Service, Snowflake, les tables Apache Iceberg et Splunk, ce qui permet d'effectuer une analytique en quasi-temps réel avec les tableaux de bord et outils de business intelligence existants que vous utilisez habituellement. Amazon Kinesis Firehose est un service entièrement géré qui s'adapte automatiquement au débit de données et ne nécessite pas d'administration continue. Il peut également regrouper, compresser et chiffrer les données avant de les charger, ce qui réduit l'espace de stockage de la destination utilisé tout en renforçant la sécurité.

Q : Qu'est-ce qu'une source dans Firehose ?

Une source est l'endroit où vos données de streaming sont continuellement générées et collectées. Par exemple, une source peut être un serveur de connexion s'exécutant sur des instances Amazon EC2, une application s'exécutant sur appareils mobiles ou un capteur sur un appareil IoT. Vous pouvez connecter vos sources à Firehose à l'aide : 1) de l'API Amazon Data Firehose qui utilise le kit AWS SDK pour Java, .NET, Noeud.js, Python ou Ruby. 2) du flux de données Kinesis, où Firehose lit facilement les données à partir d'un flux de données Kinesis existant et les charge dans les destinations Firehose. 3) Amazon MSK, où Firehose lit facilement les données à partir d'un cluster Amazon MSK existant et les charge dans des compartiments Amazon S3. 4) Service pris en charge en natif par AWS, comme AWS Cloudwatch, AWS EventBridge, AWS IOT ou AWS Pinpoint. pour obtenir la liste complète, consultez le guide du développeur Amazon Data Firehose. 5) Kinesis Agents, qui est une application logicielle Java autonome qui surveille en permanence un ensemble de fichiers et envoie les nouvelles données à votre flux. 6) Fluentbit, qui est un processeur de journaux et un transitaire open source. 7) AWS Lambda, qui est un service de calcul sans serveur qui vous permet d'exécuter du code sans provisionner ni gérer de serveurs. Vous pouvez utiliser l'écriture de votre fonction Lambda pour envoyer le trafic de S3 ou DynamoDB vers Firehose en fonction d'un événement déclencheur.

Q : Qu'est-ce qu'une destination dans Firehose ?

Une destination représente le magasin de données où vos données seront transmises. Firehose prend actuellement en charge Amazon S3, Amazon Redshift, Amazon OpenSearch Service, Snowflake, les tables Apache Iceberg, Splunk, Datadog, NewRelic, Dynatrace, Sumo Logic, LogicMonitor, MongoDB ainsi que les points de terminaison HTTP en tant que destinations.

Q : Que gère Firehose en mon nom ?

Data Firehose gère l'ensemble de l'infrastructure sous-jacente, du stockage, des réseaux et de la configuration nécessaires pour collecter et charger vos données dans Amazon S3, Amazon Redshift, Amazon OpenSearch Service, Snowflake, tables Apache Iceberg ou Splunk. Vous n'avez à vous soucier ni de l'allocation, ni du déploiement, ni de la maintenance continue du matériel et des logiciels, ni de l'écriture d'une autre application pour gérer ce processus. Data Firehose se met également à l'échelle de manière élastique sans qu'aucune intervention ou qu'aucuns frais de développement associés ne soient requis. De plus, Data Firehose réplique de manière synchrone les données sur trois installations dans une Région AWS, offrant une haute disponibilité et durabilité pour les données lors de leur transport vers les destinations.

Q : Comment utiliser Firehose ?

Suite à votre inscription à Amazon Web Services, vous pouvez commencer à utiliser Firehose en suivant les étapes indiquées ci-après :

• Créez un flux Firehose via la console Firehose ou par le biais de l'opération CreateDeliveryStream. Vous pouvez éventuellement configurer une fonction AWS Lambda dans votre flux Firehose pour préparer et transformer les données brutes avant de charger les données.
• Configurez vos producteurs de données de manière à ce qu'ils envoient continuellement des données vers votre flux Firehose à l'aide d'Amazon Kinesis Agent ou de l'API Firehose.
• Firehose charge automatiquement et continuellement vos données dans les destinations que vous spécifiez.

Q : Qu'est-ce qu'un flux Firehose dans Firehose ?

Un flux Firehose est l'entité sous-jacente de Firehose. Vous utilisez Firehose en créant un flux Firehose, puis en envoyant des données vers celui-ci. Vous pouvez créer un flux Firehose via la console Firehose ou par le biais de l'opération CreateDeliveryStream. Pour en savoir plus, consultez la page Création d'un flux Firehose.

Q : Qu'est-ce qu'un enregistrement dans Firehose ?

Un enregistrement correspond aux données utiles que le producteur de données envoie vers un flux Firehose. La taille maximale d'un enregistrement (avant le codage Base64) est de 1024 Ko si votre source de données est Direct PUT ou les flux de données Kinesis. La taille maximale d'un enregistrement (avant le codage Base64) est de 10 Mo si votre source de données est Amazon MSK.

Q : Quelles sont les limites de Firehose ?

Pour obtenir des informations sur les limites, consultez la section relative aux limites d'Amazon Data Firehose dans le guide du développeur.

Q : quels langages de programmation ou plateformes puis-je utiliser pour accéder à l'API Firehose ?

L'API Firehose est disponible dans les kits SDK Amazon Web Services. Pour obtenir la liste des plateformes et langages de programmation pour les kits SDK Amazon Web Services, consultez la page Outils pour Amazon Web Services.

Q : qu'est-ce qu'Amazon Kinesis Agent ?

Kinesis Agent est une application Java pré-intégrée qui permet de collecter et d'envoyer facilement des données vers votre flux Firehose. Vous pouvez installer cet agent dans des environnements serveur basés sur Linux tels que des serveurs web, des serveurs de journaux et des serveurs de base de données. L'agent surveille certains fichiers et envoie en continu des données sur votre flux Firehose. Amazon Kinesis Agent prend actuellement en charge Amazon Linux, Red Hat Enterprise Linux et Microsoft Windows. Pour en savoir plus, consultez la section relative à l'écriture à l'aide d'agents.

Q : où puis-je obtenir Amazon Kinesis Agent ?

Vous pouvez télécharger et installer Kinesis Agent à l'aide de la commande et du lien indiqués ci-après :

• Sur Amazon Linux : sudo yum install –y aws-kinesis-agent
• Sur Red Hat Enterprise Linux : sudo yum install –y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm
• Depuis GitHub : awlabs/amazon-kinesis-agent
• Sur Windows : https://docs.aws.amazon.com/kinesis-agent-windows/latest/userguide/getting-started.html#getting-started-installation

Q : quelle différence existe-t-il entre les opérations PutRecord et PutRecordBatch ?

Vous pouvez ajouter des données à un flux Firehose par le biais de Kinesis Agent ou des opérations PutRecord et PutRecordBatch de Firehose. L'opération PutRecord autorise un seul enregistrement de données au sein d'un appel d'API. L'opération PutRecordBatch, quant à elle, en autorise plusieurs. Pour en savoir plus, consultez les pages relatives à PutRecord et PutRecordBatch.

Q : Comment ajouter des données à mon flux Firehose à partir de mon Amazon MSK ?

Lorsque vous créez ou mettez à jour votre flux Firehose via la console AWS ou les API Firehose, vous pouvez configurer un cluster / sujet Amazon MSK comme source de votre flux Firehose. Une fois configuré, Firehose lira automatiquement les données de votre sujet MSK et les chargera dans le ou les compartiments S3 spécifiés.

Q : Quels sont les principaux avantages de l'intégration entre Amazon MSK et Firehose ?

Vous pouvez réduire la complexité et les frais généraux d'exploitation de votre application en transformant et en chargeant les sources de données en continu provenant de vos sujets Amazon MSK dans Amazon S3 sans aucun code requis. Par exemple, avec Amazon MSK et Firehose, vous n'avez accès à aucun code, à des fonctionnalités intégrées de conversion et de transformation des données, telles que la conversion au format Parquet/ORC, la mise en mémoire tampon des données et la validation des données côté service. Vous bénéficiez également de la reprise automatique de la livraison, de la conservation des données, de l'autoscaling et de la redondance, afin que les données soient livrées de manière fiable.

Q: Quels types de points de terminaison Amazon MSK sont pris en charge par Firehose ?

Pour utiliser cette fonctionnalité, les clusters MSK doivent avoir des points d'extrémité publics ou des liens privés activés.

Q: Peut-on connecter Firehose au cluster Amazon MSK dans un compte AWS différent ?

Oui, Firehose peut se connecter aux clusters Amazon MSK disponibles sur différents comptes AWS. Firehose peut également effectuer des livraisons vers des compartiments S3 appartenant à différents comptes.

Q : À quelle heure est le point de contrôle nécessaire pour commencer à consommer des données issues de la rubrique Amazon MSK ?

Le point de contrôle pour commencer à consommer les données de la rubrique Amazon MSK est l'heure de création du flux Firehose. Firehose ne lit pas à partir de valeurs de décalage personnalisées.

Q : Comment ajouter des données à mon flux Firehose à partir de mon flux de données Kinesis ?

Lorsque vous créez ou mettez à jour votre flux Firehose via la console AWS ou des API Firehose, vous pouvez configurer un flux Firehose comme source de votre flux Firehose. Une fois ce flux configuré, Firehose lira automatiquement les données de votre flux Firehose et chargera les données vers des destinations spécifiques.

Q : À quelle fréquence Firehose lit-il les données provenant de mon flux Kinesis ?

Firehose appelle Kinesis Data Streams GetRecords() une fois par seconde pour chaque partition Kinesis.

Q : à partir d'où Firehose lit-il les données lorsque mon flux de données Kinesis est configuré comme source de mon flux Firehose ?

Firehose démarre la lecture des données à partir du DERNIER emplacement de votre flux de données Kinesis lorsqu'il est configuré comme source d'un flux Firehose. Pour en savoir plus sur l'emplacement du flux de données Kinesis, consultez GetShardIterator dans la référence d'API Kinesis Data Streams Service.

Q : Puis-je configurer mon flux de données Kinesis pour qu'il soit la source de plusieurs flux Firehose ?

Oui, vous pouvez. Cela dit, il est à noter que l'appel GetRecords() de Firehose est comptabilisé par rapport à la limite générale d'accélération de votre fragment Kinesis. Vous devez donc planifier votre flux Firehose avec vos autres applications Kinesis pour vous assurer de votre accélération. Pour en savoir plus, consultez la section Limites de Kinesis Data Streams dans le guide du développeur Kinesis Data Streams.

Q : puis-je quand même ajouter des données au flux Firehose via Kinesis Agent ou via les opérations PutRecord et PutRecordBatch de Firehose lorsque mon flux de données Kinesis est configuré comme source ?

Non, ce n'est pas possible. Lorsqu'un flux de données Kinesis est configuré comme source pour un flux Firehose, les opérations PutRecord et PutRecordBatch de Firehose sont désactivées. Il serait préférable que vous ajoutiez des données à votre flux de données Kinesis via les opérations PutRecord et PutRecords de Kinesis Data Streams.

Q : comment ajouter des données à mon flux de diffusion à partir d'AWS IoT ?

Vous pouvez ajouter des données à votre flux Firehose à partir d'AWS IoT en créant une action AWS IoT qui envoie des événements à votre flux Firehose. Pour en savoir plus. Consultez Écrire dans Amazon Data Firehose avec AWS IoT dans le guide du développeur Firehose.

Q : Comment diffuser mes journaux de flux de VPC vers Firehose ?

Lorsque vous créez ou mettez à jour votre flux Firehose via la console AWS ou des API Firehose, vous pouvez configurer Direct PUT comme source de votre flux Firehose. Une fois le flux créé, vous pouvez configurer le flux Firehose créé comme votre flux Firehose dans la section Journaux payants de la console des journaux de flux de VPC.

Q : comment ajouter des données à mon flux Firehose à partir de CloudWatch Logs ?

Vous pouvez ajouter des données à votre flux Firehose à partir de CloudWatch Logs en créant un filtre d'abonnement CloudWatch Logs qui envoie des événements à votre flux Firehose. Pour en savoir plus, consultez Utilisation des filtres d'abonnement de CloudWatch Logs dans le guide de l'utilisateur Amazon CloudWatch.

Q : comment ajouter des données à mon flux Firehose à partir de CloudWatch Events ?

Vous pouvez ajouter des données à votre flux Firehose à partir de CloudWatch Events en créant une règle CloudWatch Events avec votre flux Firehose comme cible. Pour en savoir plus, consultez Écrire dans Amazon Data Firehose avec CloudWatch Events dans le guide du développeur Firehose.

Q : comment ajouter des données à mon flux Amazon Data Firehose à partir de AWS Eventbridge ?

Vous ajoutez des données à votre flux Firehose à partir de la console AWS EventBridge. Pour plus d'informations, consultez la documentation AWS EventBridge.

Q : quel type de chiffrement puis-je utiliser ?

Firehose vous permet de chiffrer vos données une fois qu'elles ont été transférées vers votre compartiment Amazon S3. Lors de la création de votre flux Firehose, vous pouvez choisir de chiffrer vos données à l'aide d'une clé AWS Key Management Service (KMS) que vous possédez. Pour en savoir plus sur KMS, consultez la page AWS Key Management Service.

Q : quel rôle IAM dois-je spécifier lors de la création d'un flux Firehose ?

Firehose endosse le rôle IAM que vous spécifiez pour accéder aux ressources telles que votre compartiment Amazon S3 et votre domaine Amazon OpenSearch. Pour plus d'informations, consultez la section Contrôle d'accès avec Firehose dans le guide du développeur Firehose.

Firehose se connecte-t-il à des bases de données situées dans un VPC ?

Oui, Firehose utilise AWS PrivateLink pour se connecter aux bases de données situées dans un VPC.

Puis-je choisir de diffuser les mises à jour de Change Data Capture (CDC) à partir de tables et de colonnes spécifiques de ma base de données ?

Oui, lorsque vous configurez un flux de diffusion Firehose, vous pouvez sélectionner des tables et des colonnes spécifiques dans votre base de données source. Firehose fournit des mises à jour de CDC uniquement pour les tables et les colonnes sélectionnées.

Puis-je transférer des enregistrements provenant de différentes tables sources vers différentes tables Iceberg de mon lac de données Amazon S3 ?

Oui, lorsque vous configurez Firehose pour diffuser un flux CDC dans des tables Apache Iceberg sur Amazon S3, vous pouvez configurer le flux pour transmettre des enregistrements provenant de différentes tables sources vers différentes tables Apache Iceberg.

Q : comment préparer et transformer des données brutes dans Firehose ?

Firehose prend en charge la conversion de format de données intégrées à partir de données brutes ou Json vers des formats comme Apache Parquet et Apache ORC requis par vos dépôts de données de destination, sans avoir à créer vos propres pipelines de traitement de données. Firehose vous permet également de partitionner dynamiquement vos données de streaming avant leur livraison à S3 à l'aide de clés statiques ou définies dynamiquement telles que « customer_id » ou « transaction_id ». Firehose regroupe les données par ces clés et les livre dans des préfixes S3 à clé unique, ce qui vous permet d'effectuer plus facilement des analytique dans S3 de haute performance et à moindre coût, à l'aide d'Athena, EMR et Redshift Spectrum.

En plus de l'option de conversion de format intégrée dans Amazon Data Firehose, vous pouvez également utiliser une fonction AWS Lambda pour préparer et transformer les données brutes entrantes dans votre flux Firehose avant de les charger vers les destinations. Vous pouvez configurer une fonction AWS Lambda pour la transformation de données lorsque vous créez un nouveau flux Firehose ou lorsque vous en modifiez un existant. Amazon a créé plusieurs plans Lambda parmi lesquels vous pouvez choisir pour un démarrage rapide. pour obtenir la liste complète, consultez le guide du développeur Amazon Data Firehose.

Q : quel format de compression puis-je utiliser ?

Amazon Data Firehose vous permet de compresser vos données avant de les transférer vers Amazon S3. Le service prend actuellement en charge les formats de compression GZIP, ZIP et SNAPPY. Seul le format GZIP est pris en charge si les données sont ensuite chargées vers Amazon Redshift.

Q : Comment fonctionne la compression lorsque j'utilise la fonction d'abonnement CloudWatch Logs ?

Vous pouvez utiliser la fonction d'abonnement CloudWatch Logs pour diffuser des données en streaming de CloudWatch Logs vers Firehose. Étant donné que tous les événements de journal de CloudWatch Logs sont déjà compressés au format gzip, vous devez désactiver la compression de Firehose pour éviter une double compression. Pour plus d'informations sur les fonctions d'abonnement CloudWatch Logs, consultez la section relative aux filtres d'abonnement avec Amazon Data Firehose dans le guide de l'utilisateur Amazon CloudWatch Logs.

Q : comment puis-je renvoyer les données préparées et transformées de ma fonction AWS Lambda vers Amazon Data Firehose ?

Tous les enregistrements transformés provenant de Lambda doivent être renvoyés vers Firehose avec les trois paramètres suivants ; sinon, Firehose les rejettera et les traitera comme un échec de transformation de données.

• recordId: Firehose transmet un recordId avec chaque enregistrement sur Lambda durant l'invocation. Chaque enregistrement transformé doit être renvoyé avec le même recordId. Toute incompatibilité entre le recordId original et le recordId renvoyé sera traitée comme un échec de transformation de données.
• result: L'état du résultat de transformation de chaque enregistrement. Les valeurs suivantes sont autorisées pour ce paramètre : « Ok » si l'enregistrement est transformé correctement comme prévu. « Abandonné » si votre logique de traitement abandonne intentionnellement l'enregistrement comme prévu. « ProcessingFailed » si l'enregistrement ne peut pas être transformé comme prévu. Firehose traite les enregistrements renvoyés avec les états « OK » et « Abandonné » comme des enregistrements traités avec succès, et ceux avec l'état « ProcessingFailed » comme des enregistrements échoués lorsqu'il génère les métriques SucceedProcessing.Records et SucceedProcessing.Bytes.
  
• data: la charge utile des données transformées après l'encodage en based64.

Q : qu'est-ce que le journal d'erreurs ?

Si vous activez la transformation de données avec Lambda, Firehose peut enregistrer toutes les invocations de Lambda et les erreurs de livraison de données dans les Amazon CloudWatch Logs, afin que vous puissiez afficher les journaux d'erreurs spécifiques si l'invocation de Lambda ou la transmission de données échoue. Pour plus d'informations, consultez la page dédiée à la Surveillance avec Amazon CloudWatch Logs.

Q : qu'est-ce que la sauvegarde de l'enregistrement source ?

Si vous utilisez la transformation de données avec Lambda, vous pouvez activer la sauvegarde des enregistrements source et Amazon Data Firehose transmettra les données entrantes non transformées vers un compartiment S3 séparé. Vous pouvez spécifier un préfixe supplémentaire à ajouter devant le préfixe de temps UTC « AAAA/MM/JJ/HH » généré par Firehose.

Q : quand utiliser le partitionnement dynamique Firehose ?

Le partitionnement dynamique de Firehose élimine les complexités et les retards du partitionnement manuel à la source ou après le stockage des données, et permet des analytiques plus rapides pour interroger des ensembles de données optimisés. Cela rend les ensembles de données immédiatement disponibles pour les analytiques afin d'exécuter leurs requêtes efficacement et améliore le contrôle d'accès précis aux données. Par exemple, les clients de l'automatisation du marketing peuvent partitionner les données à la volée par ID client, ce qui permet aux requêtes spécifiques au client d'interroger des ensembles de données optimisés et de fournir des résultats plus rapidement. Les clients des opérations TI ou de surveillance de la sécurité peuvent créer des regroupements basés sur l'horodatage des événements intégré dans les journaux afin de pouvoir interroger des ensembles de données optimisés et obtenir des résultats plus rapidement. Ces fonctions combinées à celle existante de conversion de format JSON vers parquet d'Amazon Data Firehose fait d'Amazon Data Firehose une option ETL de streaming idéale pour S3.

Q : comment configurer le partitionnement dynamique avec Firehose ?

Vous pouvez configurer la capacité de partitionnement des données Firehose via la Console de gestion AWS, les CLI ou les kits SDK. Lorsque vous créez ou mettez à jour un flux Firehose, sélectionnez Amazon S3 comme destination de diffusion pour le flux Firehose et activez le partitionnement dynamique. Vous pouvez spécifier des clés ou créer une expression qui sera évaluée au moment de l'exécution pour définir les clés utilisées pour le partitionnement. Par exemple, vous pouvez sélectionner un champ de données dans le flux entrant tel que l'ID client et définir une expression de préfixe S3 telle que customer_id=!{partitionKey:customer_id}/, qui sera évaluée au moment de l'exécution en fonction des enregistrements intégrés pour définir à quel préfixe S3 livrer les enregistrements.

Q : quels types de transformations et de traitement de données puis-je effectuer avec le partitionnement dynamique et les clés de partitionnement ?

Firehose prend en charge la conversion parquet/orc dès que vous écrivez vos données sur Amazon S3. Firehose s'intègre également à la fonction Lambda, ce qui vous permet d'écrire votre propre code de transformation. Firehose prend également en charge l'extraction des champs de données clés à partir des enregistrements au format JSON. Firehose prend également en charge le langage d'analyse JQ pour permettre les transformations sur ces clés de partition. Pour en savoir plus, consultez le Guide du développeur Firehose.

Q : Pourquoi suis-je soumis à des limitations lorsque j'envoie des données à mon flux Amazon Data Firehose ?

Par défaut, chaque flux Firehose peut traiter jusqu'à 2 000 transactions/seconde, 5 000 enregistrements/seconde et 5 Mo/seconde. Vous pouvez facilement augmenter cette limite en envoyant un formulaire d'augmentation des limites de service.

Q : Pourquoi y a-t-il des enregistrements dupliqués dans mon compartiment Amazon S3, ma table Amazon Redshift, mon index Amazon OpenSearch ou mes clusters Splunk ?

Amazon Data Firehose utilise au moins une fois la sémantique pour transmettre les données. Dans de rares conditions, notamment en cas de dépassement du délai de demande lors d'une tentative de livraison de données, la nouvelle tentative de livraison par Firehose peut produire des doublons si la requête précédente finit par aboutir.

Q : Que se passe-t-il si la diffusion des données vers mon compartiment Amazon S3 échoue ?

Si votre source de données est Direct PUT et que la diffusion de données vers votre compartiment Amazon S3 échoue, Amazon Data Firehose tente à nouveau de diffuser les données toutes les 5 secondes pendant une période maximale de 24 heures. Si le problème persiste au-delà de la période de rétention maximale de 24 heures, Amazon Data Firehose élimine les données en question.

Si votre source de données est Kinesis Data Streams et que la diffusion de données vers votre compartiment Amazon S3 échoue, Amazon Data Firehose tente à nouveau de diffuser les données toutes les 5 secondes pendant une période maximale équivalente à la durée configurée dans Kinesis Data Streams.

Q : Que se passe-t-il si la diffusion des données vers mon instance Amazon Redshift échoue ?

Si la transmission des données vers votre instance Redshift échoue, Amazon Data Firehose tente à nouveau de diffuser les données toutes les 5 minutes pendant une période maximale de 120 minutes. Une fois le délai de 120 minutes écoulé, Amazon Data Firehose ignore le lot actuel d'objets S3 prêts pour COPY et passe au lot suivant. Les informations concernant les objets ignorés sont transmises à votre compartiment S3 en tant que fichier manifeste dans le dossier des erreurs, que vous pouvez utiliser pour effectuer un renvoi manuel. Pour obtenir des informations sur la COPIE manuelle des données avec des fichiers manifestes, consultez Utilisation d'un manifeste pour spécifier des fichiers de données.

Q : Que se passe-t-il si la transmission de données vers mon domaine Amazon OpenSearch échoue ?

Pour la destination Amazon OpenSearch Service, vous pouvez définir une période de nouvelle tentative d'envoi comprise entre 0 et 7200 secondes lors de la création du flux Firehose. Si la livraison des données à votre domaine Amazon OpenSearch échoue, Amazon Data Firehose tente à nouveau de livrer les données pendant la durée spécifiée. Une fois la période de nouvelle tentative d'envoi écoulée, Amazon Data Firehose ignore le lot de données actuel et passe au lot suivant. Les informations concernant les documents ignorés sont transmises à votre compartiment S3 dans le dossier opensearch_failed, que vous pouvez utiliser pour un remplissage manuel.

Q : Que se passe-t-il si la transformation de données échoue ?

Il existe deux types de scénarios d'échec lorsque Firehose tente d'évoquer votre fonction Lambda pour la transformation de données :

• Le premier type correspond à l'échec d'invocation de la fonction pour des raisons telles que l'expiration du délai d'atteinte du réseau et l'atteinte des limites d'invocation Lambda. Dans ce genre de scénarios d'échec, Firehose refait une tentative d'invocation trois fois par défaut, puis ignore ce groupe d'enregistrement en particulier. Les enregistrements ignorés sont traités comme des enregistrements dont le traitement a échoué. Vous pouvez configurer le nombre de nouvelles tentatives d'invocations entre 0 et 300 à l'aide des API CreateDeliveryStream et UpdateDeliveryStream. Pour ce type d'échec, vous pouvez aussi utiliser la fonction de journalisation d'erreurs de Firehose afin d'émettre des erreurs d'invocation dans les journaux CloudWatch. Pour plus d'informations, consultez la page dédiée à la Surveillance avec Amazon CloudWatch Logs.
• Le deuxième type de scénario d'erreur se produit lorsque le résultat de transformation d'un enregistrement est défini sur « ProcessingFailed » lorsqu'il est renvoyé de votre fonction Lambda. Firehose traite ces enregistrements comme des enregistrements dont le traitement a échoué. Pour ce type d'échec, vous pouvez utiliser la fonction de journalisation Lambda pour émettre des journaux d'erreurs dans les journaux CloudWatch. Pour plus d'informations, consultez la page Accès à Amazon CloudWatch Logs pour AWS Lambda.

Pour ces deux types de scénarios d'erreurs, les enregistrements dont l'enregistrement a échoué sont transmis vers votre compartiment S3 dans le dossier processing_failed.

Q : Pourquoi la taille des objets S3 transmis est-elle plus importante que la taille de tampon que j'ai indiquée dans la configuration des flux Firehose ?

La taille des objets S3 transmis doit refléter la taille de tampon indiquée la plupart du temps si la condition de la taille de tampon est remplie avant la condition de l'intervalle de mise en mémoire tampon. Notez que lorsque la diffusion de données à destination retarde l'écriture de données vers le flux Firehose, Firehose augmente la taille du tampon de façon dynamique pour rattraper le retard et garantir la diffusion de l'ensemble des données à destination. Dans ce cas, la taille des objets S3 transmis peut être plus importante que la taille de tampon indiquée.

Q : Qu'est-ce que le dossier erreurs dans mon compartiment Amazon S3 ?

Le dossier erreurs stocke les fichiers manifestes contenant des informations sur les objets S3 ayant échoué au chargement dans votre instance Redshift. Vous pouvez charger de nouveau ces objets de façon manuelle par le biais de la commande COPY Redshift. Pour obtenir des informations sur la COPIE manuelle des données avec des fichiers manifestes, consultez Utilisation d'un manifeste pour spécifier des fichiers de données.

Q : Qu'est-ce que le dossier opensearch_failed dans mon compartiment Amazon S3 ?

Le dossier opensearch_failed stocke les documents dont le chargement vers Amazon OpenSearch a échoué. Que se passe-t-il si la transmission de données vers mon domaine Amazon OpenSearch échoue ? Vous pouvez ré-indexer ces documents manuellement à des fins de remplissage.

Q : Qu'est-ce que le dossier processing_failed dans mon compartiment Amazon S3 ?

Le dossier processing_failed conserve les enregistrements dont la transformation a échoué dans votre fonction AWS Lambda. Vous pouvez à nouveau traiter ces enregistrements manuellement.

Q : Comment contrôler les opérations et les performances de mon flux Amazon Data Firehose ?

La console Firehose affiche les métriques opérationnelles et de performances clés, telles que le volume de données entrantes et le volume de données transmises. Amazon Data Firehose peut également être intégré à des métriques Amazon CloudWatch, ce qui vous permet d'enregistrer, de consulter et d'analyser des métriques pour vos flux Firehose. Pour en savoir plus sur les métriques Amazon Data Firehose, consultez la section relative à la Surveillance à l'aide des métriques Amazon CloudWatch dans le guide du développeur Amazon Data Firehose.

Q : Comment surveiller les échecs de transformation et de transmission de données de mon flux Amazon Data Firehose ?

Amazon Data Firehose peut être intégré à Amazon CloudWatch Logs, ce qui vous permet de consulter les journaux d'erreurs spécifiques en cas d'échec de transmission ou de transformation de données. Vous pouvez activer la consignation des erreurs lors de la création de votre flux Firehose. Pour plus d'informations, consultez la section relative à la Surveillance à l'aide d'Amazon CloudWatch Logs dans le guide du développeur Amazon Data Firehose.

Q : Comment gérer et contrôler les accès à mon flux Amazon Data Firehose ?

Amazon Data Firehose s'intègre à AWS Identity and Access Management, un service qui vous permet de contrôler l'accès des utilisateurs à vos ressources et services AWS en toute sécurité. Vous pouvez, par exemple, créer une politique permettant uniquement à un utilisateur ou à un groupe d'utilisateurs en particulier d'ajouter des données à votre flux Firehose. Pour en savoir plus sur la gestion et le contrôle des accès à votre flux, consultez la page relative au contrôle d'accès avec Amazon Data Firehose.

Q : Comment journaliser les appels d'API adressés à mon flux Amazon Data Firehose à des fins d'analyse de sécurité et de résolution des problèmes opérationnels ?

Amazon Data Firehose s'intègre à AWS CloudTrail, un service qui enregistre les appels d'API AWS sur votre compte et vous fournit les fichiers journaux. Pour en savoir plus sur la journalisation des appels d'API et consulter la liste des opérations d'API Amazon Data Firehose prises en charge, reportez-vous à la section dédiée à la journalisation des appels d'API Amazon Data Firehose à l'aide d'AWS CloudTrail.

Q : Le service Firehose est-il disponible dans le cadre de l’offre gratuite d'AWS ?

Non, Firehose n'est actuellement pas disponible dans le cadre de l'offre gratuite d'AWS. L'offre gratuite d'AWS est un programme qui permet d'essayer gratuitement un certain nombre de services AWS. Pour en savoir plus, consultez la page relative à l'offre gratuite d'AWS.

Q : Combien coûte Firehose ?

Firehose propose un système de paiement à l'utilisation très simple. Aucun investissement initial n'est nécessaire et nous n'appliquons pas de frais minimum : vous payez uniquement les ressources que vous utilisez. La tarification Amazon Data Firehose est calculée en fonction du volume de données (Go) ingérées par Firehose, chaque enregistrement étant arrondi aux 5 Ko les plus proches pour Direct PUT et Kinesis Data Streams comme sources. Pour les journaux payants comme source, la tarification dépend du volume de données (Go) ingérées par Firehose. Pour en savoir plus sur les frais liés à Amazon Data Firehose, visitez Tarification Amazon Data Firehose.

Q : Lorsque j'utilise l'opération PutRecordBatch pour envoyer des données vers Amazon Data Firehose, comment est calculé l'arrondi aux 5 Ko ?

L'arrondi aux 5 Ko est calculé au niveau de l'enregistrement plutôt qu'au niveau de l'opération d'API. Par exemple, si votre appel PutRecordBatch comprend deux enregistrements de 1 Ko chacun, le volume de données de cet appel compte comme 10 Ko. (5 Ko par enregistrement)

Q : Le coût de Firehose inclut-il les coûts Amazon S3, Amazon Redshift, Amazon OpenSearch Service et AWS Lambda ?

Non, les frais associés à l'utilisation d'Amazon S3, Amazon Redshift, Amazon OpenSearch Service et AWS Lambda, notamment les coûts de stockage et de requêtes, vous sont facturés séparément. Pour plus d'informations, consultez Tarification Amazon S3, Tarification Amazon Redshift, Tarification Amazon OpenSearch Service et Tarification AWS Lambda.

Q : Qu'est-ce que garantit l'Amazon Data Firehose SLA ?

Notre Amazon Data Firehose SLA garantit un pourcentage de disponibilité mensuel d'au moins 99,9 % pour Amazon Data Firehose.

Q : Comment savoir si je peux bénéficier d'un crédit de service SLA ?

Vous pouvez bénéficier d'un crédit SLA pour Amazon Data Firehose dans le cadre du SLA Amazon Data Firehose si plusieurs zones de disponibilité dans lesquelles vous exécutez une tâche dans la même région ont un pourcentage de disponibilité mensuel inférieur à 99,9 % pendant un cycle de facturation mensuel.

Pour consulter l'intégralité des conditions générales de l'accord de niveau de service Compute et en savoir plus sur la marche à suivre pour soumettre une demande, référez-vous à la page d'informations d'Amazon Data Firehose SLA.