FAQ sur Amazon Redshift

Amazon Redshift Serverless est une option sans serveur d'Amazon Redshift qui rend plus efficace l'exécution et la mise à l'échelle des analytiques en secondes, sans devoir installer et gérer une infrastructure d'entrepôt des données. Avec Redshift Serverless, n'importe quel utilisateur, notamment analyste de données, développeur, professionnel de l'informatique et scientifique des données, peut obtenir des informations à partir des données, simplement en chargeant les données dans l'entrepôt des données et en les interrogeant.

En seulement quelques étapes dans la console de gestion AWS, vous pouvez choisir « Configure Amazon Redshift Serverless » (Configurer Amazon Redshift Serverless) et commencer à interroger les données. Vous pouvez tirer parti des jeux de données d'échantillons préchargés, tels que les données météo, les données de recensement et les jeux de données de référence, ainsi que des exemples de requêtes pour démarrer l'analytique sans délai. Vous pouvez également créer des bases de données, des schémas, des tables et charger des données à partir d'Amazon S3, accéder aux données via les partages de données Amazon Redshift ou effectuer une restauration à parti d'un instantané de cluster alloué Redshift existant. Vous pouvez par ailleurs interroger directement les données dans des formats ouverts (comme Parquet ou ORC) dans le lac de données Amazon S3, ou interroger des données dans des bases de données opérationnelles, notamment Amazon Aurora, Amazon RDS PostgreSQL et MySQL. Consultez le Guide de démarrage.

Si vous n'avez pas d'expérience dans la gestion d'entrepôt des données, vous n'avez pas à vous soucier de l'installation, de la configuration, de la gestion des clusters ou du réglage de l'entrepôt. Vous pouvez vous concentrer sur l'obtention d'informations importantes à partir de vos données ou sur la façon d'atteindre vos résultats métiers principaux via les données. Vous ne payez que pour ce que vous utilisez, ce qui permet de gérer les coûts. Vous bénéficiez toujours de toutes les meilleures performances d'Amazon Redshift, des fonctions SQL riches, de l'intégration transparente avec les lacs de données et des entrepôts des données opérationnels, ainsi que des analytiques prévisibles et des fonctionnalités de partage des données. Si vous souhaitez un contrôle plus précis de votre entrepôt des données, vous pouvez allouer des clusters Redshift.

Vous pouvez continuer d'utiliser toutes les multiples fonctionnalités d'analytique d'Amazon Redshift, comme les jointures complexes, les requêtes directes de données dans le lac de données et les bases de données opérationnelles Amazon S3, les vues matérialisées, les procédures stockées, la prise en charge de données semi-structurées et le ML, ainsi que des performances élevées à grande échelle. Tous les services connexes avec lesquels Amazon Redshift s'intègre (comme Amazon Kinesis, AWS Lambda, Amazon QuickSight, Amazon SageMaker, Amazon EMR, AWS Lake Formation et AWS Glue) continuent de fonctionner avec Amazon Redshift Serverless.

Vous pouvez continuer à exécuter tous les cas d'utilisation d'analytique. Avec un simple flux de mise en route, une scalabilité automatique et la possibilité de payer en fonction de l'utilisation, l'expérience Amazon Redshift Serverless, plus efficace et plus rentable, permet d'exécuter et de tester les environnements ayant besoin de démarrer rapidement, les analytiques métiers ad-hoc, les charges de travail avec des besoins en calcul qui varient et sont imprévisibles, et des charges de travail intermittentes et sporadiques.

Vous pouvez charger les données dans Amazon Redshift à partir de diverses sources de données, notamment Amazon S3, Amazon RDS, Amazon DynamoDB, Amazon EMR, AWS Glue, AWS Data Pipeline et/ou tout hôte compatible SSH, sur Amazon EC2 ou sur site. Amazon Redshift tente de charger vos données en parallèle dans chaque nœud de calcul afin d'optimiser le taux d'absorption des données dans votre cluster d'entrepôts de données. Les clients peuvent se connecter à Amazon Redshift à partir d'ODBC ou de JDBC, puis lancer des commandes SQL « Insert » afin d'insérer les données. Notez, toutefois, que cette méthode est plus lente que d'utiliser les services S3 ou DynamoDB. En effet, ces services chargent les données en parallèle sur chaque nœud de calcul, tandis que les instructions SQL Insert effectuent le chargement à partir d'un seul et même nœud « leader ». Pour en savoir plus sur le chargement de données dans Amazon Redshift, consultez notre Guide de mise en route.

Redshift auto-copy permet d'automatiser les relevés de copie en suivant les dossiers Amazon S3 et en ingérant les nouveaux fichiers sans intervention du client. Sans copie automatique, une instruction de copie lance immédiatement le processus d'ingestion de fichiers pour les fichiers existants. Auto-copy étend la commande de copie existante et permet 1/ d'automatiser le processus d'ingestion de fichiers en surveillant les chemins d'accès Amazon S3 spécifiés pour les nouveaux fichiers, 2/ de réutiliser les configurations de copie, réduisant ainsi la nécessité de créer et d'exécuter de nouvelles instructions de copie pour les tâches d'ingestion répétitives et 3/ de garder la trace des fichiers chargés pour éviter la duplication des données.

Pour commencer, les clients doivent disposer d'un dossier Amazon S3, auquel leur cluster Redshift/terminal sans serveur peut accéder à l'aide des rôles IAM associés, et créer une table Redshift à utiliser comme cible. Une fois qu'un chemin Amazon S3 et la table Redshift sont prêts, les clients peuvent créer un travail de copie en utilisant la commande de copie. Une fois la tâche de copie créée, Redshift commence à suivre le chemin Amazon S3 spécifié en arrière-plan et lance les instructions de copie définies par l'utilisateur pour copier automatiquement les nouveaux fichiers dans la table cible.

Les principaux cas d'utilisation sont les suivants : 1/ Les clients utilisant Amazon EMR et AWS Glue pour exécuter des tâches Apache Spark qui accèdent aux données et les chargent dans Amazon Redshift dans le cadre des pipelines d'ingestion et de transformation des données (batch et streaming) 2/ Les clients utilisant Amazon SageMaker pour effectuer de machine learning à l'aide d'Apache Spark et doivent accéder aux données stockées dans Amazon Redshift pour l'ingénierie et la transformation des fonctionnalités. 3/Clients d'Amazon Athena utilisant Apache Spark pour effectuer une analyse interactive des données dans Amazon Redshift.

Baikal offre les avantages suivants :

• Facilité d'utilisation pour démarrer et exécuter des applications Apache Spark sur des données dans Amazon Redshift, sans avoir à vous soucier des étapes manuelles nécessaires à la configuration et à la maintenance des versions non certifiées de Spark
• Possibilité d'utiliser Apache Spark à partir de différents services AWS tels qu'Amazon EMR, AWS Glue, Amazon Athena et Amazon SageMaker avec Amazon Redshift pour une configuration minimale
• Performances améliorées lors de l'exécution des applications Apache Spark sur Amazon Redshift

Amazon Aurora Zero-ETL to Amazon Redshift permet aux clients d'Amazon Aurora et d'Amazon Redshift d'exécuter des analyses et une machine learning en temps quasi réel sur des pétaoctets de données transactionnelles en offrant une solution entièrement gérée pour rendre les données transactionnelles d'Amazon Aurora disponibles dans Amazon Redshift quelques secondes après leur écriture. Avec Amazon Aurora Zero-ETL to Amazon Redshift, les clients choisissent simplement les tables Amazon Aurora contenant les données qu'ils souhaitent analyser avec Amazon Redshift, et la fonctionnalité réplique de manière transparente le schéma et les données dans Amazon Redshift. Les clients n'ont plus besoin de construire et de gérer des pipelines de données complexes, ce qui leur permet de se concentrer sur l'amélioration de leurs applications. Avec Amazon Aurora Zero-ETL to Amazon Redshift, les clients peuvent répliquer les données de plusieurs clusters de bases de données Amazon Aurora dans la même instance Amazon Redshift pour obtenir des informations complètes sur plusieurs applications, tout en consolidant leurs principaux actifs analytiques, ce qui leur permet de réaliser des économies et de gagner en efficacité opérationnelle. Avec Amazon Aurora Zero-ETL to Amazon Redshift, les clients peuvent également accéder aux principales fonctionnalités d'analyse et de machine learning d'Amazon Redshift, telles que les vues matérialisées, le partage de données et l'accès fédéré à plusieurs magasins de données et lacs de données. Cela permet aux clients de combiner l'analyse en temps quasi réel et l'analyse de base afin d'obtenir efficacement des informations sensibles au temps qui éclairent les décisions commerciales. En outre, les clients utilisent Amazon Aurora pour les transactions et Amazon Redshift pour les analyses, de sorte qu'il n'y a pas de ressources informatiques partagées, ce qui donne une solution performante et stable sur le plan opérationnel.

L'intégration zéro ETL d'Amazon Aurora à Amazon Redshift permet une intégration parfaite entre les deux services pour l'analyse transactionnelle.

Les données en continu sont différentes des tableaux traditionnels des bases de données, car lorsque vous interrogez un flux, vous saisissez l'évolution d'une relation variable dans le temps. Les tableaux, quant à eux, capturent un instantané ponctuel de cette relation qui varie dans le temps. Les clients d'Amazon Redshift sont habitués à opérer sur des tables régulières et à effectuer un traitement en aval (c'est-à-dire des transformations) des données en utilisant un modèle batch traditionnel, par exemple « ELT ». Nous fournissons une méthode pour utiliser les vues matérialisées (MV) de Redshift afin que les clients puissent facilement matérialiser une vue ponctuelle du flux, tel qu'il a été accumulé jusqu'au moment où il est interrogé, aussi rapidement que possible pour prendre en charge les flux de PEL.

Voici de cas d'utilisation clé :

• Un cluster ETL central partageant des données avec de nombreux clusters d'analytique/de BI pour fournir un isolement de la charge de travail de lecture et une possibilité de facturation facultative.
• Un fournisseur de données partageant des données avec des consommateurs externes.
• Le partage de jeux de données courants tels que les clients et les produits, avec différents groupes métiers et la collaboration pour de vastes analytiques et la science des données.
• Décentralisation d'un entrepôt des données pour simplifier la gestion.
• Le partage des données entre les environnements de développement, de test et de production.
• L'accès aux données Redshift à partir d'autres services d'analytique AWS.

Avec les requêtes inter-bases de données, vous pouvez rechercher des données et y accéder sans problème dans toutes les bases de données Redshift auxquelles vous avez accès, peu importe la base de données à laquelle vous êtes connecté. Cela concerne tant les bases de données locales sur le cluster que les jeux de données partagés disponibles sur des clusters distants. Les requêtes inter-bases de données vous offrent la flexibilité nécessaire pour organiser vos données dans différentes bases afin de permettre les configurations multi-locataire.

AWS Data Exchange permet aux clients AWS d'échanger plus efficacement et d'utiliser des données tierces dans AWS en toute sécurité. Les analystes de données, les responsables de produits, les responsables de portefeuilles, les scientifiques des données, les analystes quantitatifs, les techniciens d'essais cliniques et les développeurs de pratiquement tous les secteurs aimeraient accéder à plus de données pour stimuler les analytiques, entraîner les modèles ML et prendre des décisions orientées données. Mais il n'existe pas d'emplacement unique où trouver les données provenant de plusieurs fournisseurs et aucune cohérence de livraison des données, et les utilisateurs doivent gérer un mélange de supports physiques expédiés, d'informations d'identification FTP et d'appels d'API personnalisés. De même, de nombreuses organisations voudraient que leurs données soient disponibles à des fins de recherche ou commerciales, mais il est trop difficile et coûteux de créer et de maintenir la livraison des données, les droits et la technologie de facturation, réduisant davantage l'approvisionnement de données précieuses.

Amazon Redshift Serverless alloue automatiquement la capacité de l'entrepôt de données et fait évoluer intelligemment les ressources sous-jacentes. Amazon Redshift Serverless ajuste la capacité en quelques secondes pour offrir des performances élevées et constantes et des opérations simplifiées, même pour les charges de travail les plus exigeantes et les plus volatiles. Avec la fonction de mise à l'échelle de la simultanéité, vous pouvez prendre en charge un nombre quasi illimité d'utilisateurs et de requêtes simultanés, avec des performances de requêtes constamment rapides. Lorsque la mise à l'échelle de la simultanéité est activée, Amazon Redshift ajoute automatiquement une capacité de cluster supplémentaire lorsque le nombre de requêtes en file attente de votre cluster augmente.

Pour une mise à l'échelle manuelle, si vous souhaitez augmenter les performances de requête ou remédier à une surutilisation du CPU, de la mémoire ou des E/S, vous pouvez augmenter le nombre de nœuds figurant dans votre cluster d'entrepôts des données à l'aide du redimensionnement Elastic via la console de gestion AWS ou l'API ModifyCluster. Les modifications que vous apportez à votre cluster d'entrepôts des données sont immédiatement appliquées. Les métriques relatives à l'utilisation des capacités de calcul et de stockage, ainsi qu'au trafic en lecture/écriture de votre cluster d'entrepôts des données Redshift, sont disponibles gratuitement via la console de gestion AWS ou les API Amazon CloudWatch. Vous pouvez également ajouter des métriques définies par l'utilisateur, via la fonctionnalité de métriques personnalisées d'Amazon CloudWatch.

Avec Amazon Redshift Spectrum, vous pouvez exécuter plusieurs clusters Redshift accédant aux mêmes données dans Amazon S3. Il est ainsi possible de faire appel à différents clusters selon les cas d'utilisation. Par exemple, vous pouvez utiliser un cluster pour la génération de rapports standard, et un autre pour les requêtes de science des données. Votre équipe marketing peut avoir ses propres clusters, bien distincts de ceux de l'équipe des opérations. Redshift Spectrum répartit automatiquement l'exécution de la requête entre plusieurs programmes d'exécution Redshift Spectrum au sein d'un groupe de ressources partagées, chargés de lire et traiter les données provenant d'Amazon S3, puis redirige les résultats vers votre cluster Redshift pour les éventuelles tâches de traitement restantes.

Cela dépend. Lorsque vous utilisez la fonctionnalité d'adaptation de la simultanéité, le cluster est entièrement disponible en lecture et en écriture lors de l'adaptation de la simultanéité. Avec le redimensionnement Elastic, le cluster est indisponible quatre à huit minutes pendant la période de redimensionnement. Grâce à l'élasticité du stockage Redshift RA3 dans le stockage géré, le cluster est entièrement disponible et les données sont automatiquement transférées entre les nœuds de calcul et de stockage géré.

Le redimensionnement Elastic ajoute ou supprime des nœuds d'un seul cluster Redshift en quelques minutes pour gérer son débit de requêtes. Par exemple, une charge de travail ETL durant certaines heures d'un rapport de fin de journée ou de mois peut requérir des ressources Amazon Redshift supplémentaires pour être finalisée à temps. La mise à l'échelle de la simultanéité ajoute des ressources de cluster supplémentaires pour accroître la simultanéité globale des requêtes.

Non. La mise à l'échelle de la simultanéité est un groupe de ressources Amazon Redshift extrêmement évolutif. Les clients ne peuvent pas y accéder directement.

Amazon Redshift prend en charge une sécurité de pointe avec une gestion des identités et une fédération pour l'authentification unique (SSO), l'authentification multifactorielle, le contrôle précis des accès et Amazon Virtual Private Cloud (Amazon VPC). Avec Amazon Redshift, vos données sont chiffrées en transit et au repos. Toutes les fonctionnalités de sécurité d'Amazon Redshift sont proposées prêts à l’emploi sans coût supplémentaire pour satisfaire les exigences les plus strictes en matière de sécurité, de confidentialité et de conformité. Vous bénéficiez de la prise en charge par AWS d’un plus grand nombre de normes de sécurité et de certifications de conformité que tout autre fournisseur, y compris ISO 27001, SOC, HIPAA/HITECH, et FedRAMP.

Oui, Amazon Redshift fournit la prise en charge le contrôle d'accès basé sur les rôles. Le contrôle des accès au niveau des colonnes vous permet d'affecter un ou plusieurs rôles à un utilisateur et d'octroyer des permissions et d'objet par rôle. Vous pouvez utiliser les rôles système prêts à l'emploi, notamment utilisateur root, administrateur de bases de données, opérateur et administrateurs de sécurité, ou créer vos propres rôles.

Les fonctions définies par l'utilisateur AWS Lambda vous permettent d'utiliser une fonction AWS Lambda comme une fonction définie par l'utilisateur dans Amazon Redshift et de l'appeler avec les requêtes SQL Redshift. Avec cette fonctionnalité, vous pouvez écrire des extensions personnalisées pour votre requête SQL afin de renforcer l'intégration avec d'autres services ou des produits tiers. Vous pouvez écrire des fonctions définies par l'utilisateur Lambda pour permettre la création de jeton externe, le masquage des données, l'identification ou la désidentification des données, en intégrant des fournisseurs comme Protegrity, et protéger ou déprotéger les données sensibles en fonction des groupes et des autorisations de l'utilisateur au moment de la requête.

Grâce à la prise en charge du masquage dynamique des données, les clients peuvent facilement protéger leurs données sensibles et contrôler un accès granulaire en gérant des politiques de masquage des données. Supposons que vos applications comptent plusieurs utilisateurs et des objets contenant des données sensibles qui ne peuvent être exposées à tous les utilisateurs. Vous avez des exigences pour fournir un niveau de sécurité granulaire différent que vous voulez donner à différents groupes d'utilisateurs. Redshift Dynamic Data Masking est configurable pour permettre aux clients de définir des valeurs de données masquées cohérentes, préservant le format et irréversibles. Une fois que la fonction est GA, vous commencez à l'utiliser immédiatement. Les administrateurs de la sécurité peuvent créer et appliquer des politiques en quelques commandes seulement.

Oui. Les clients qui souhaitent utiliser leurs fournisseurs d'identité d'entreprise tels que Microsoft Azure Active Directory, Active Directory Federation Services, Okta, Ping Federate ou tout autre fournisseur d'identité conforme à SAML, peuvent configurer Amazon Redshift afin de proposer l'authentification unique. Vous pouvez vous connecter au cluster Amazon Redshift avec des identités Microsoft Azure Active Directory (AD). Cela vous permet de vous connecter à Redshift sans dupliquer ces identités Azure Active Directory dans Redshift.

Oui. Vous pouvez utiliser l'authentification multi-facteurs (MFA) pour plus de sécurité au moment de vous identifier pour entrer dans votre cluster Amazon Redshift.

Amazon Redshift détecte automatiquement le nœud en échec dans votre cluster d'entrepôts de données et le remplace. Sur les clusters de calcul dense (DC) et de stockage dense (DS2), les données sont stockées sur les nœuds de calcul pour garantir la durabilité élevée des données. Lorsqu'un nœud est remplacé, les données sont actualisées à partir de la copie en miroir sur l'autre nœud. Les clusters RA3 et Redshift sans serveur ne sont pas impactés de la même manière car les données sont stockées dans Amazon S3 et le lecteur local est simplement utilisé comme cache des données. Le cluster d'entrepôts de données reste indisponible pour les interrogations et les mises à jour jusqu'à ce qu'un nœud de remplacement soit mis en service et ajouté à la base de données. Amazon Redshift rend votre nœud de remplacement immédiatement disponible et charge vos données les plus fréquemment consultées à partir d'Amazon S3 afin que vous puissiez reprendre l'interrogation des données aussi rapidement que possible. Les clusters ne comportant qu'un nœud ne prennent pas en charge la réplication des données. En cas de défaillance d'un disque, vous devrez restaurer le cluster à partir d'un instantané stocké dans S3. Nous vous recommandons donc d'utiliser au moins deux nœuds en mode production.

Si votre entrepôt de données Amazon Redshift est un déploiement à une seule AZ et que la zone de disponibilité du cluster devient indisponible, Amazon Redshift va automatiquement transférer votre cluster vers une autre zone de disponibilité AWS (AZ) sans entraîner des pertes de données ou des changements de l'application. Pour activer cette procédure, vous devez activer la capacité de transfert dans les paramètres de configuration de votre cluster.

Contrairement aux déploiements mono-AZ, les clients peuvent désormais améliorer la disponibilité de Redshift en exécutant leur entrepôt de données dans un déploiement multi-AZ. Un déploiement multi-AZ vous permet d'exécuter votre entrepôt de données dans plusieurs zones de disponibilité (AZ) AWS simultanément pour continuer à fonctionner dans scénarios de panne imprévus. Aucun changement d'application n'est nécessaire pour maintenir la continuité des activités puisque le déploiement de Multi-AZ est géré comme un entrepôt de données unique avec un seul point de terminaison. Les déploiements multi-AZ réduisent le temps de récupération en garantissant la capacité de récupération automatique et sont destinés aux clients disposant d'applications d'analyse critiques pour l'entreprise qui nécessitent les plus hauts niveaux de disponibilité et de résilience aux pannes AZ. Cela permet également aux clients de mettre en œuvre une solution plus conforme aux recommandations du pilier de la fiabilité de l'AWS Well-Architected Framework. Pour en savoir plus sur Amazon Redshift Multi-AZ, cliquez ici.

RPO est l'acronyme de Recovery Point Objective (objectif de point de récupération). Il s'agit d'un terme décrivant la garantie de rétablissement des données en cas de défaillance. Le RPO est le délai maximal acceptable depuis le dernier point de récupération des données. Cela détermine ce qui est considéré comme une perte acceptable de données entre le dernier point de récupération et l'interruption du service. Redshift Multi-AZ prend en charge RPO = 0, ce qui signifie que les données sont garanties comme étant actuelles et à jour en cas de panne. Nos tests préalables au lancement ont révélé que le RTO avec les déploiements multi-AZ Amazon Redshift est inférieur à 60 secondes, voire moins, dans le cas peu probable d'une défaillance de la zone de disponibilité.

La relocalisation de Redshift est activée par défaut sur tous les nouveaux clusters RA3 et points d'extrémité sans serveur, ce qui permet de redémarrer un entrepôt de données dans un autre AZ en cas de panne à grande échelle, sans perte de données ni coût supplémentaire. Bien que l'utilisation de Relocate soit gratuite, ses limites sont qu'il s'agit d'une approche de type best-effort soumise à la disponibilité des ressources dans la zone AZ en cours de récupération et que l'objectif de temps de récupération (RTO) peut être affecté par d'autres problèmes liés au démarrage d'un nouveau cluster. Cela peut entraîner des temps de récupération compris entre 10 et 60 minutes. Redshift Multi-AZ prend en charge les exigences de haute disponibilité en fournissant un RTO mesuré en dizaines de secondes et offre un fonctionnement continu garanti puisqu'il ne sera pas soumis à des limitations de capacité ou à d'autres problèmes potentiels lors de la création d'un nouveau cluster.

Oui, Amazon Redshift utilise les instructions SQL standard du secteur et est accessible depuis les pilotes JDBC et ODBC standard. Vous pouvez télécharger les pilotes JDBC et ODBC personnalisés d'Amazon Redshift à partir de l'onglet Connect Client de notre console Redshift. Nous disposons d'intégrations validées auprès de fournisseurs de BI et d'ETL populaires, dont la plupart proposent des essais gratuits pour vous aider à débuter dans le chargement et l'analyse de vos données. Vous pouvez également vous rendre sur AWS Marketplace afin de déployer et configurer en quelques minutes des solutions conçues pour fonctionner avec Amazon Redshift.

Amazon Redshift Spectrum prend en charge tous les outils clients Amazon Redshift. Ces outils clients peuvent continuer à se connecter au point de terminaison du cluster Amazon Redshift à l'aide de connexions ODBC ou JDBC. Aucune modification n'est nécessaire.

Vous utilisez exactement la même syntaxe de requête et avez les mêmes possibilités d'accès aux tables dans Redshift Spectrum que pour les tables du stockage local de votre cluster Redshift. Les tables externes sont référencées à l'aide du nom de schéma défini dans la commande CREATE EXTERNAL SCHEMA utilisée pour leur enregistrement.

Amazon Redshift Spectrum prend actuellement en charge de nombreux formats de données open source, notamment Avro, CSV, Grok, Amazon Ion, JSON, ORC, Parquet, RCFile, RegexSerDe, Sequence, Text et TSV. <br>Amazon Redshift Spectrum prend actuellement en charge les compressions Gzip et Snappy.

Comme pour les tables locales, vous pouvez utiliser le nom de schéma pour sélectionner précisément la table souhaitée en insérant la valeur nom_schéma.nom_table dans votre requête.

Oui. La commande CREATE EXTERNAL SCHEMA prend en charge les Hive Metastores. Toutefois, nous ne prenons pas encore en charge le langage DDL pour le Hive Metastore.

Vous pouvez interroger la table système SVV_EXTERNAL_TABLES pour obtenir cette information.

Oui, la fonction de Amazon Redshift ML permet aux utilisateurs de SQL de créer, d'entraîner et de déployer facilement des modèles de machine learning (ML) en utilisant les commandes SQL habituelles. Amazon Redshift ML vous permet de tirer parti de vos données dans Amazon Redshift avec Amazon SageMaker, un service de ML entièrement géré. Amazon Redshift prend en charge l'apprentissage non supervisé (K-Means) et l'apprentissage supervisé (algorithmes Autopilot, XGBoost, MLP). Vous pouvez également utiliser les services AWS Language AI pour traduire, rédiger et analyser les champs de texte dans les requêtes SQL avec des fonctions Lambda UDF préconstruites – voir l'article de blog.

Amazon Redshift fournit une API Data que vous pouvez utiliser pour accéder facilement aux données d'Amazon Redshift avec tous types d'applications (applications basées sur des événements, basées sur des services Web, sans serveur, traditionnelles, natives cloud et conteneurisées). L'API Data simplifie l'accès à Amazon Redshift car vous n'avez pas besoin de configurer les pilotes et de gérer les connexions aux bases de données. Vous pouvez exécuter des commandes SQL sur un cluster Amazon Redshift en appelant un point de terminaison d'API sécurisé fourni par l'API Data. L'API Data prend en charge la gestion des connexions à la base de données et la mise en mémoire tampon des données. L'API Data est asynchrone ; vous pouvez donc récupérer les résultats plus tard. Les résultats de votre requête sont hébergés durant 24 heures.

L'API Data prend en charge les informations d'identification IAM et les clés secrètes d'AWS Secrets Manager. L'API Data réunit les informations d'identification d'AWS Identity and Access Management (IAM) afin que vous puissiez utiliser des fournisseurs d'identité comme Okta ou Azure Active Directory ou les informations d'identification à la base de données enregistrées dans Secrets Manager sans fournir les informations d'identification à la base de données dans les appels d'API.

Oui, vous pouvez utiliser l'API Data depuis l'interface de ligne de commande AWS CLI via l'option de ligne de commande aws redshift-data.

Vous pouvez utiliser l'API Data à partir d'autres services comme AWS Lambda, AWS Cloud9, AWS AppSync et Amazon EventBridge.

Non, il n'y a pas d'autre facturation pour l'utilisation de l'API Data.

L'édition compatible Amazon Aurora MySQL, l'édition compatible Amazon Aurora PostgreSQL (version préliminaire), Amazon RDS for MySQL et Amazon DynamoDB (version préliminaire limitée) prennent en charge les intégrations zéro ETL avec Amazon Redshift.

Vous devez utiliser l'intégration zéro ETL d'Aurora avec Amazon Redshift lorsque vous avez besoin d'un accès en temps quasi réel aux données transactionnelles. Cette intégration vous permet de tirer parti du ML d'Amazon Redshift à l'aide de simples commandes SQL.

L'intégration zéro ETL d’Aurora avec Amazon Redshift est disponible dans l'édition compatible Aurora MySQL pour Aurora MySQL version 3.05 (compatible avec MySQL 8.0.32) et supérieure dans les Régions AWS prises en charge.

L'intégration zéro ETL d'Aurora avec Amazon Redshift est disponible dans l'édition compatible Aurora PostgreSQL pour Aurora PostgreSQL 15.4 dans la région USA Est (Ohio).

L'intégration zéro ETL d'Aurora avec Amazon Redshift vous évite de créer et de gérer des pipelines de données complexes. Vous pouvez consolider les données d'un ou de plusieurs clusters de bases de données Aurora vers un cluster de base de données Amazon Redshift unique et d'exécuter des analyses et un machine learning en temps quasi réel à l'aide d'Amazon Redshift sur des pétaoctets de données transactionnelles provenant d'Amazon Aurora.

L'intégration zéro ETL avec Amazon Redshift est compatible avec Amazon Redshift sans serveur et Amazon Aurora sans serveur v2. Lorsque vous utilisez Aurora sans serveur v2 et Amazon Redshift sans serveur, vous pouvez générer des analyses en temps quasi réel sur les données transactionnelles sans avoir à gérer d'infrastructure pour les pipelines de données.

Vous pouvez commencer par utiliser la console Amazon RDS pour créer l'intégration zéro ETL en spécifiant la source Aurora et la destination Amazon Redshift. Une fois l'intégration créée, la base de données Aurora sera répliquée sur Amazon Redshift et vous pourrez commencer à interroger les données une fois l'amorçage initial terminé. Pour plus d'informations, consultez le guide de démarrage relatif aux intégrations zéro ETL d'Amazon Aurora avec Amazon Redshift.

L'intégration zéro ETL d'Aurora à Amazon Redshift réplique de manière atomique les transactions afin de garantir la cohérence des données entre la base de données Aurora source et le cluster Amazon Redshift cible.
Voici quelques points clés concernant l'atomicité des transactions grâce à cette intégration :

• Seules les transactions validées dans Aurora sont répliquées sur Amazon Redshift. Les transactions non validées ou annulées ne sont pas appliquées.
• L'intégration utilise un processus de validation en deux phases pour appliquer de manière atomique chaque transaction à Amazon Redshift. Toutes les modifications apportées aux données de la transaction sont appliquées ou, en cas d'erreur, aucune n'est appliquée.
• La cohérence des transactions est maintenue entre la source et la cible. Après la réplication, les données d'une transaction donnée seront cohérentes à la fois dans Aurora et dans Amazon Redshift.
• Les modifications de schéma via DDL ou DML sont également appliquées de manière atomique pour préserver l'intégrité.
• L'application atomique des transactions garantit qu'aucune transaction partielle ou aucun état de données incohérent ne peut se produire entre les bases de données.

L'intégration zéro ETL Aurora avec Amazon Redshift assure une cohérence transactionnelle totale entre la base de données Aurora source et le cluster Amazon Redshift cible.

Voici quelques points clés sur la façon dont les modifications de schéma sont gérées :

• Les instructions DDL telles que CREATE TABLE, ALTER TABLE, DROP TABLE, etc. sont automatiquement répliquées depuis Aurora vers Amazon Redshift.
• L'intégration effectue les vérifications et les ajustements nécessaires dans les tables Amazon Redshift pour les modifications de schéma répliquées. Par exemple, l'ajout d'une colonne dans Aurora ajoutera la colonne dans Amazon Redshift.
• La réplication et la synchronisation du schéma se font automatiquement en temps réel avec un décalage minimal entre les bases de données source et cible.
• La cohérence du schéma est maintenue même si les modifications DML se produisent parallèlement aux modifications DDL.

Vous pouvez créer des vues matérialisées dans votre base de données Amazon Redshift locale pour transformer les données répliquées via une intégration zéro ETL. Connectez-vous à votre base de données locale et utilisez des requêtes entre bases de données pour accéder aux bases de données de destination. Vous pouvez utiliser des noms d'objets complets avec une notation en trois parties (nom-base-de-destination.nom-schéma.nom-table) ou créer un schéma externe faisant référence à la base de données de destination et à la paire de schémas et utiliser une notation en deux parties (nom-schéma-externe.nom-table).

Zéro ETL et le traitement continu des modifications de données sont proposés sans frais supplémentaires. Vous payez pour les ressources Amazon RDS et Amazon Redshift existantes utilisées pour créer et traiter les données de modification générées dans le cadre d'une intégration zéro ETL. Ces ressources peuvent inclure :

• E/S et stockage supplémentaires utilisés en activant les journaux binaires améliorés
• Coûts d'exportation d'instantanés pour l'exportation initiale des données afin d'alimenter vos bases de données Amazon Redshift
• Stockage Amazon Redshift supplémentaire pour le stockage des données répliquées
• Coûts de transfert de données entre plusieurs AZ pour déplacer les données de la source vers la cible

Pour plus d'informations, consultez la page de tarification Aurora.

Pour consulter les questions les plus fréquemment posées concernant l'intégration zéro ETL d'Amazon RDS for MySQL avec Amazon Redshift, consultez les FAQAmazon RDS for MySQL. Pour en savoir plus sur la tarification de cette intégration, consultez la rubrique Tarification d'Amazon RDS for MySQL.

Les clusters Amazon Redshift RA3 et Amazon Redshift Serverless utilisent le stockage géré Redshift, qui est toujours la dernière copie des données disponible. Les clusters DS2 et DC2 reflètent en miroir les données sur le cluster pour s'assurer que la dernière copie est disponible en cas d'échec. Les sauvegardes sont automatiquement créées sur tous les types de cluster Redshift et retenues pendant 24 heures, et sur des points de reprise sans serveur fournis pour les 24 dernières heures.

Vous pouvez aussi créer vos propres sauvegardes qui peuvent être retenues indéfiniment. Ces sauvegardes peuvent être créées à tout moment, et les sauvegardes automatisées Amazon Redshift ou les points de récupération Amazon Redshift Serverless peuvent être convertis en une sauvegarde utilisateurs pour une rétention plus longue.

Amazon Redshift peut également répliquer de façon asynchrone vos instantanés ou points de reprise sur Amazon S3, dans une autre région, à des fins de reprise après sinistre.

Sur un cluster DS2 ou DC2, le stockage de sauvegarde gratuit est limité à la taille totale du stockage sur les nœuds appartenant au cluster d'entrepôts des données. Il s'applique uniquement aux clusters d'entrepôts des données actifs.

Par exemple, pour un stockage total de 8 To d'entrepôts des données, nous fournissons jusqu'à 8 To de stockage de sauvegarde sans frais supplémentaires. Si vous souhaitez prolonger la période de rétention des sauvegardes au-delà d'une journée, utilisez la console de gestion AWS ou les API Amazon Redshift. Pour en savoir plus sur les instantanés automatiques, consultez Amazon Redshift Management Guide.

Amazon Redshift sauvegarde uniquement les données qui ont été modifiées. Ainsi, la plupart des instantanés n'utilisent qu'une faible portion de votre stockage de sauvegarde gratuit. Lorsque vous avez besoin de restaurer une sauvegarde, vous avez accès à toutes les sauvegardes automatisées dans votre fenêtre de rétention des sauvegardes. Une fois que vous avez choisi la sauvegarde à partir de laquelle procéder à la restauration, nous mettons en service un nouveau cluster d'entrepôts de données et restaurons vos données sur celui-ci.

Vous pouvez utiliser la console de gestion AWS ou l'API ModifyCluster pour gérer la période pendant laquelle vos sauvegardes automatiques sont conservées via le paramètre RetentionPeriod. Si vous souhaitez désactiver complètement les sauvegardes automatiques, vous pouvez définir la période de rétention sur 0 (bien que cette option ne soit pas recommandée).

Lorsque vous supprimez un cluster d'entrepôt de données, vous avez la possibilité de spécifier si un instantané final est créé lors de la suppression. Cela permet d'effectuer une restauration ultérieure du cluster d'entrepôt de données supprimé. Tous les instantanés de votre cluster d'entrepôts des données que vous aurez créés manuellement seront retenus et facturés selon les tarifs standard Amazon S3, sauf si vous choisissez de les supprimer.

Les métriques relatives à l'utilisation des capacités de calcul et de stockage, ainsi qu'au trafic en lecture/écriture de votre cluster d'entrepôts des données Amazon Redshift, sont disponibles gratuitement via la console de gestion AWS ou les API Amazon CloudWatch. Vous pouvez également ajouter des mesures supplémentaires que vous aurez définies, via la fonctionnalité de mesures personnalisées d'Amazon CloudWatch. AWS Management Console fournit un tableau de bord de surveillance qui vous aide à surveiller la santé et les performances de tous vos clusters. Amazon Redshift fournit également des informations sur les performances des interrogations et du cluster via AWS Management Console. Ces informations vous permettent de voir quels utilisateurs et requêtes consomment le plus de ressources système afin de diagnostiquer les problèmes de performances en consultant les plans de requête et les statistiques d'exécution. Vous pouvez également consulter l'utilisation des ressources sur chacun de vos nœuds de calcul, afin de vous assurer que vos données et requêtes sont correctement équilibrées sur tous les nœuds.

Amazon Redshift effectue périodiquement des opérations de maintenance pour apporter des correctifs, des améliorations et de nouvelles fonctionnalités à votre cluster. Vous pouvez changer les fenêtres de maintenance planifiées en modifiant le cluster par programmation ou avec Redshift Console. Durant ces fenêtres de maintenance, votre cluster Amazon Redshift n'est pas disponible pour les opérations normales. Pour en savoir plus sur les fenêtres de maintenance et les programmations par région, consultez la section Fenêtres de maintenance du Guide de gestion Amazon Redshift.