FAQ sur Amazon Data 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.

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.

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

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.

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.

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.

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

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.

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.

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.

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

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.

Oui. 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.

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.

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.

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.

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.

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.

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

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 AWS Key Management Service.

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.

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

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.

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.

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.

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.

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 fonctionnalités d’abonnement CloudWatch Logs, consultez Subscription Filters with Amazon Data Firehose dans le guide de l’utilisateur Amazon CloudWatch Logs.

Tous les enregistrements transformés provenant de Lambda doivent être renvoyées 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 le codage base64.

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.

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.

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 une analytique plus rapide pour interroger des jeux 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 fonctionnalités combinées à celle existante de conversion de format JSON vers Parquet d’Amazon Data Firehose fait d’Amazon Data Firehose une option d’ETL de streaming idéale pour S3.

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.

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.

Oui, Firehose peut sauvegarder tous les enregistrements non transformés dans votre compartiment S3 tout en transmettant des enregistrements transformés à destination. La sauvegarde des enregistrements source peut être activée lorsque vous créez ou mettez à jour votre flux Firehose.

La fréquence de transmission des données vers Amazon S3 est déterminée par la taille de mémoire tampon S3 et la valeur d'intervalle de mise en mémoire tampon configurées pour votre flux Firehose. Firehose met en mémoire tampon les données entrantes avant de les transférer vers Amazon S3. Vous pouvez configurer les valeurs de la taille de mémoire tampon S3 (de 1 à 128 Mo) ou de l’intervalle de mise en mémoire tampon (de 0 à 900 secondes). La première condition remplie déclenche la transmission de données vers Amazon S3. Si vous avez activé parquet Apache ou le partitionnement dynamique, la taille de votre mémoire tampon est en Mo et varie de 64 à 128 Mo pour la destination Amazon S3, 128 Mo étant la valeur par défaut. Notez que dans les cas où la livraison des données à la destination prend du retard par rapport à l'intégration des données dans le flux Firehose augmente automatiquement la taille de la mémoire tampon pour rattraper son retard et s'assurer que toutes les données sont transmises à la destination.

La taille du tampon s'applique avant la compression. Par conséquent, si vous choisissez de compresser vos données, la taille des objets au sein de votre compartiment Amazon S3 peut être inférieure à la taille du tampon que vous indiquez.

L'utilisateur Amazon Redshift doit disposer du privilège INSERT Redshift pour copier des données à partir de votre compartiment Amazon S3 vers votre instance Redshift.

Si votre instance Amazon Redshift se trouve au sein d'un VPC, vous devez autoriser Amazon Data Firehose à accéder à votre instance Redshift en débloquant les adresses IP Firehose depuis votre VPC. Pour obtenir des informations sur le déblocage des adresses IP sur votre VPC, consultez la section relative à l'attribution d'un accès Firehose à une destination Amazon Redshift dans le guide du développeur Amazon Data Firehose.

Pour les destinations Redshift, Amazon Data Firehose transfère d'abord les données vers votre compartiment Amazon S3, puis émet la commande COPY Redshift pour charger les données de votre compartiment S3 vers votre instance Redshift.

Actuellement, un seul flux Firehose ne peut fournir des données qu'à une seule table Snowflake. Pour fournir des données à plusieurs tables Snowflake, vous devez créer plusieurs flux Firehose.

Firehose utilise une sémantique de diffusion en une seule fois pour Snowflake. Cela signifie que chaque enregistrement est envoyé à Snowflake exactement une fois, même en cas d'erreur ou de nouvelles tentatives. Cependant, la diffusion en une seule fois ne garantit pas qu'il n'y aura pas de doublons dans les données de bout en bout, car les données peuvent être dupliquées par le producteur ou par d'autres parties du pipeline ETL.

Nous nous attendons à ce que la plupart des flux de données soient transmis dans les 5 secondes.

Amazon OpenSearch Service vous permet d'effectuer facilement des analytiques interactives de journaux , de surveiller des applications en temps réel, de rechercher du contenu sur site web, etc. OpenSearch est une suite de recherche et d'analyse distribuée, open source, dérivée d'Elasticsearch. Amazon OpenSearch Service offre les dernières versions d'OpenSearch, la prise en charge de 19 versions d'Elasticsearch (versions 1.5 à 7.10) et des fonctionnalités de visualisation à technologie OpenSearch Dashboards et Kibana (versions 1.5 à 7.10). Cliquez ici pour plus d'informations sur Amazon OpenSearch.

Firehose peut procéder à la rotation de votre index Amazon OpenSearch Service en fonction d'une certaine durée. Vous pouvez configurer cette durée lors de la création de votre flux Firehose. Pour plus d'informations, consultez Rotation d'index pour la destination Amazon OpenSearch dans le guide du développeur Amazon Data Firehose.

Lors du chargement des données dans Amazon OpenSearch Service, Firehose peut sauvegarder toutes les données ou seulement les données dont la transmission a échoué. Pour profiter de cette fonctionnalité et empêcher toute perte de données, vous devez fournir un bucket (compartiment) Amazon S3 de sauvegarde.

Vous pouvez modifier la configuration de votre flux Firehose à n'importe quel moment après sa création. Vous pouvez le faire en utilisant la console Firehose ou l'opération UpdateDestination. Votre flux Firehose conserve l'état ACTIVE lors de la mise à jour de vos configurations et vous pouvez continuer d'envoyer des données à votre flux Firehose. En général, les configurations mises à jour prennent effet en seulement quelques minutes.

En cas de distribution vers une destination VPC, vous pouvez modifier l'URL du point de terminaison de destination, tant que la nouvelle destination est accessible dans les mêmes VPC, sous-réseaux et groupes de sécurité. Pour modifier les VPC, sous-réseaux et groupes de sécurité, vous devez recréer le flux Firehose.

La diffusion de Firehose peut être envoyée à un autre compte dans Amazon OpenSearch Service uniquement lorsque Firehose et Amazon OpenSearch Service sont connectés via un point de terminaison public.

Si Firehose et Amazon OpenSearch Service sont connectés via un VPC privé. Le flux Firehose et le domaine VPC d'Amazon OpenSearch Service de destination doivent être dans le même compte.

Non, votre flux Firehose et le domaine Amazon OpenSearch Service de destination doivent se trouver dans la même région.

La fréquence de transmission des données vers Amazon OpenSearch Service est déterminée par les valeurs de la taille de mémoire tampon et de l'intervalle de mise en mémoire tampon d'OpenSearch que vous avez configurées pour votre flux Firehose. Firehose met en mémoire tampon les données entrantes avant de les transférer vers Amazon OpenSearch Service. Vous pouvez configurer les valeurs de la taille de mémoire tampon (de 1 à 100 Mo) ou de l’intervalle de mise en mémoire tampon (de 0 à 900 secondes) d’OpenSearch. La première condition remplie déclenche la transmission des données vers Amazon OpenSearch Service. Notez que dans les cas où la transmission des données à la destination prend du retard sur l’ingestion des données dans le flux Firehose, Amazon Data Firehose augmente automatiquement la taille de la mémoire tampon pour rattraper son retard et s’assurer que toutes les données sont transmises à la destination.

Pour les destinations Redshift, Amazon Data Firehose génère des fichiers manifestes pour charger par lot des objets Amazon S3 vers l'instance Redshift. Le dossier manifeste stocke les fichiers manifestes générés par Firehose.

Si le mode « tous les documents » est utilisé, Amazon Data Firehose concatène plusieurs enregistrements entrants en fonction de la configuration de la mise en mémoire tampon de votre flux Firehose, puis les transfère vers votre compartiment S3 sous forme d'objet S3. Quel que soit le mode de sauvegarde configuré, les documents dont l'envoi a échoué sont transmis à votre compartiment S3 à l'aide d'un certain format JSON qui fournit des informations supplémentaires telles que le code d'erreur et l'heure de la tentative d'envoi. Pour plus d'informations, voir Sauvegarde Amazon S3 pour la destination Amazon OpenSearch dans le guide du développeur Amazon Data Firehose.

Un flux Firehose unique peut transmettre actuellement des données uniquement vers un seul compartiment Amazon S3. Si vous souhaitez que les données soient transférées vers plusieurs compartiments S3, vous pouvez créer plusieurs flux Firehose.

Un flux Firehose unique ne peut actuellement transmettre des données qu'à une seule instance et une seule table Redshift. Si vous souhaitez que les données soient transférées vers plusieurs instances ou tables Redshift, vous pouvez créer plusieurs flux Firehose.

À l'heure actuelle, un flux Firehose unique peut transmettre des données uniquement vers un domaine et un index Amazon OpenSearch Service. Si vous souhaitez que les données soient transférées vers plusieurs domaines ou index Amazon OpenSearch, vous pouvez créer plusieurs flux Firehose.

Lorsque vous autorisez Firehose à transmettre les données à une destination Amazon OpenSearch Service dans un VPC, Amazon Data Firehose crée une ou plusieurs interfaces réseau Elastic (ENI) inter-comptes dans votre VPC pour chaque sous-réseau que vous choisissez. Amazon Data Firehose utilise ces ENI pour transmettre les données dans votre VPC. Le nombre d'ENI est automatiquement mis à l'échelle pour répondre aux exigences de service.

Oui, un flux Firehose peut fournir des données à plusieurs tables Apache Iceberg.

Oui, Firehose prend en charge la connexion au Catalogue de données AWS Glue dans un autre compte ou dans une autre région AWS.

Oui, vous pouvez utiliser la transformation des données à l'aide de Lambda lors de la livraison vers des tables Apache Iceberg. 

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.

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.

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.

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.

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.

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.

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.

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.

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 pour effectuer un remplissage.

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

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.

Amazon Data Firehose s’intègre à 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.

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.

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.

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 l’offre gratuite AWS.

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, consultez la Tarification d’Amazon Data Firehose.

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).

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 la Tarification d’Amazon S3, la Tarification d’Amazon Redshift, la Tarification d’Amazon OpenSearch Service et la Tarification d’AWS Lambda.

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

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 obtenir tous les détails sur les termes et conditions de l’accord de niveau de service, ainsi que sur la marche à suivre pour soumettre une demande, veuillez consulter la page de détails de l’accord de niveau de service Amazon Data Firehose.