Iceberg Apache est un format de tableau ouvert pour de très grands ensembles de données analytiques, qui capture des informations de métadonnées sur l'état des ensembles de données à mesure qu'ils évoluent et changent au fil du temps. Il ajoute des tables aux moteurs de calcul, notamment Spark, Trino, PrestoDB, Flink et Hive, à l'aide d'un format de table hautes performances qui fonctionne comme une table SQL. Iceberg est devenu très populaire pour sa prise en charge des transactions ACID dans les lacs de données et des fonctionnalités telles que l'évolution des schémas et des partitions, le voyage dans le temps et la restauration.
L'intégration d'Apache Iceberg est prise en charge par les services d'analyse AWS, notamment Amazon DME, Amazone Athénaet Colle AWS. Amazon EMR peut provisionner des clusters avec Spark, Hive, Trino et Flink qui peuvent exécuter Iceberg. À partir de la version 6.5.0 d'Amazon EMR, vous pouvez utiliser Iceberg avec votre cluster EMR sans nécessiter d'action d'amorçage. Début 2022, AWS a annoncé la disponibilité générale des transactions Athena ACID, optimisées par Apache Iceberg. Le récemment publié Moteur de requête Athena version 3 offre une meilleure intégration avec le format de table Iceberg. AWS Glue 3.0 et versions ultérieures prend en charge le framework Apache Iceberg pour les lacs de données.
Dans cet article, nous discutons de ce que les clients attendent des lacs de données modernes et de la manière dont Apache Iceberg aide à répondre aux besoins des clients. Ensuite, nous passons en revue une solution pour créer un lac de données Iceberg hautes performances et évolutif sur Service de stockage simple Amazon (Amazon S3) et traiter les données incrémentielles en exécutant des instructions SQL d'insertion, de mise à jour et de suppression. Enfin, nous vous montrons comment régler les performances du processus pour améliorer les performances de lecture et d'écriture.
Comment Apache Iceberg répond aux attentes des clients dans les lacs de données modernes
De plus en plus de clients créent des lacs de données, avec des données structurées et non structurées, pour prendre en charge de nombreux utilisateurs, applications et outils d'analyse. Il est de plus en plus nécessaire que les lacs de données prennent en charge des fonctionnalités telles que les bases de données telles que les transactions ACID, les mises à jour et les suppressions au niveau des enregistrements, le voyage dans le temps et la restauration. Apache Iceberg est conçu pour prendre en charge ces fonctionnalités sur des lacs de données rentables à l'échelle du pétaoctet sur Amazon S3.
Apache Iceberg répond aux besoins des clients en capturant des informations de métadonnées riches sur l'ensemble de données au moment de la création des fichiers de données individuels. Il existe trois couches dans l'architecture d'une table Iceberg : le catalogue Iceberg, la couche de métadonnées et la couche de données, comme illustré dans la figure suivante (la source).
Le catalogue Iceberg stocke le pointeur de métadonnées vers le fichier de métadonnées de la table actuelle. Lorsqu'une requête de sélection lit une table Iceberg, le moteur de requête accède d'abord au catalogue Iceberg, puis récupère l'emplacement du fichier de métadonnées actuel. Chaque fois qu'il y a une mise à jour de la table Iceberg, un nouvel instantané de la table est créé et le pointeur de métadonnées pointe vers le fichier de métadonnées de la table actuelle.
Voici un exemple de catalogue Iceberg avec implémentation AWS Glue. Vous pouvez voir le nom de la base de données, l'emplacement (chemin S3) de la table Iceberg et l'emplacement des métadonnées.
La couche de métadonnées comporte trois types de fichiers : le fichier de métadonnées, la liste manifeste et le fichier manifeste dans une hiérarchie. Au sommet de la hiérarchie se trouve le fichier de métadonnées, qui stocke des informations sur le schéma de la table, les informations de partition et les instantanés. L'instantané pointe vers la liste des manifestes. La liste des manifestes contient des informations sur chaque fichier manifeste qui constitue l'instantané, telles que l'emplacement du fichier manifeste, les partitions auxquelles il appartient et les limites inférieure et supérieure des colonnes de partition pour les fichiers de données qu'il suit. Le fichier manifeste suit les fichiers de données ainsi que des détails supplémentaires sur chaque fichier, tels que le format de fichier. Les trois fichiers fonctionnent dans une hiérarchie pour suivre les instantanés, le schéma, le partitionnement, les propriétés et les fichiers de données dans une table Iceberg.
La couche de données contient les fichiers de données individuels de la table Iceberg. Iceberg prend en charge une large gamme de formats de fichiers, notamment Parquet, ORC et Avro. Étant donné que la table Iceberg suit les fichiers de données individuels au lieu de pointer uniquement vers l'emplacement de la partition avec les fichiers de données, elle isole les opérations d'écriture des opérations de lecture. Vous pouvez écrire les fichiers de données à tout moment, mais ne validez la modification qu'explicitement, ce qui crée une nouvelle version des fichiers d'instantané et de métadonnées.
Vue d'ensemble de la solution
Dans cet article, nous vous présentons une solution pour créer un lac de données Apache Iceberg hautes performances sur Amazon S3 ; traiter les données incrémentielles avec des instructions SQL d'insertion, de mise à jour et de suppression ; et régler la table Iceberg pour améliorer les performances de lecture et d'écriture. Le diagramme suivant illustre l'architecture de la solution.
Pour démontrer cette solution, nous utilisons le Amazon Commentaires des clients jeu de données dans un compartiment S3 (s3://amazon-reviews-pds/parquet/
). Dans un cas d'utilisation réel, il s'agirait de données brutes stockées dans votre compartiment S3. Nous pouvons vérifier la taille des données avec le code suivant dans le Interface de ligne de commande AWS (AWS CLI) :
Le nombre total d'objets est de 430 et la taille totale est de 47.4 Gio.
Pour configurer et tester cette solution, nous effectuons les étapes de haut niveau suivantes :
- Configurez un compartiment S3 dans la zone organisée pour stocker les données converties au format de table Iceberg.
- Lancez un cluster EMR avec les configurations appropriées pour Apache Iceberg.
- Créez un bloc-notes dans EMR Studio.
- Configurez la session Spark pour Apache Iceberg.
- Convertissez les données au format de table Iceberg et déplacez les données vers la zone organisée.
- Exécutez des requêtes d'insertion, de mise à jour et de suppression dans Athena pour traiter les données incrémentielles.
- Effectuez le réglage des performances.
Pré-requis
Pour suivre cette procédure pas à pas, vous devez disposer d'un Compte AWS peut comprendre un atténuateur. Gestion des identités et des accès AWS (IAM) qui dispose d'un accès suffisant pour provisionner les ressources requises.
Configurez le compartiment S3 pour les données Iceberg dans la zone organisée de votre lac de données
Choisissez la région dans laquelle vous souhaitez créer le compartiment S3 et fournissez un nom unique :
Lancer un cluster EMR pour exécuter des tâches Iceberg à l'aide de Spark
Vous pouvez créer un cluster EMR à partir du Console de gestion AWS, l'interface de ligne de commande Amazon EMR ou Kit de développement AWS Cloud (AWSCDK). Pour cet article, nous vous expliquons comment créer un cluster EMR à partir de la console.
- Sur la console Amazon EMR, choisissez Créer un cluster.
- Selectionnez Options avancées.
- Pour Configuration logicielle, choisissez la dernière version d'Amazon EMR. Depuis janvier 2023, la dernière version est la 6.9.0. Iceberg nécessite la version 6.5.0 et supérieure.
- Sélectionnez JupyterEnterpriseGateway ainsi que Spark comme logiciel à installer.
- Pour Modifier les paramètres du logiciel, sélectionnez Entrez la configuration et entrez
[{"classification":"iceberg-defaults","properties":{"iceberg.enabled":true}}]
. - Laissez les autres paramètres par défaut et choisissez Suivant.
- Pour Matériel, utilisez le paramètre par défaut.
- Selectionnez Suivant.
- Pour Nom du cluster, entrez un nom. Nous utilisons
iceberg-blog-cluster
. - Laissez les paramètres restants inchangés et choisissez Suivant.
- Selectionnez Créer un cluster.
Créer un bloc-notes dans EMR Studio
Nous vous expliquons maintenant comment créer un bloc-notes dans EMR Studio à partir de la console.
- Sur la console IAM, créer un rôle de service EMR Studio.
- Sur la console Amazon EMR, choisissez Studio DME.
- Selectionnez Commencez.
La Commencez la page apparaît dans un nouvel onglet.
- Selectionnez Créer un atelier dans le nouvel onglet.
- Entrez un nom. Nous utilisons iceberg-studio.
- Choisissez le même VPC et le même sous-réseau que ceux du cluster EMR, ainsi que le groupe de sécurité par défaut.
- Selectionnez Gestion des identités et des accès AWS (IAM) pour l'authentification, puis choisissez le rôle de service EMR Studio que vous venez de créer.
- Choisissez un chemin S3 pour Sauvegarde des espaces de travail.
- Selectionnez Créer un atelier.
- Une fois le Studio créé, choisissez l'URL d'accès au Studio.
- Sur le tableau de bord EMR Studio, choisissez Créer un espace de travail.
- Entrez un nom pour votre espace de travail. Nous utilisons
iceberg-workspace
. - Développer vous Configuration avancée et choisissez Attacher Workspace à un cluster EMR.
- Choisissez le cluster EMR que vous avez créé précédemment.
- Selectionnez Créer un espace de travail.
- Choisissez le nom de l'espace de travail pour ouvrir un nouvel onglet.
Dans le volet de navigation, un bloc-notes porte le même nom que l'espace de travail. Dans notre cas, il s'agit d'iceberg-workspace.
- Ouvrez le cahier.
- Lorsque vous êtes invité à choisir un noyau, choisissez Spark.
Configurer une session Spark pour Apache Iceberg
Utilisez le code suivant, en fournissant votre propre nom de compartiment S3 :
Cela définit les configurations de session Spark suivantes :
- spark.sql.catalog.demo – Enregistre un catalogue Spark nommé demo, qui utilise le plug-in de catalogue Iceberg Spark.
- spark.sql.catalog.demo.catalog-impl – Le catalogue de démonstration Spark utilise AWS Glue comme catalogue physique pour stocker la base de données Iceberg et les informations de table.
- spark.sql.catalog.demo.warehouse – Le catalogue de démonstration Spark stocke toutes les métadonnées et tous les fichiers de données Iceberg sous le chemin racine défini par cette propriété :
s3://iceberg-curated-blog-data
. - spark.sql.extensions - Ajoute la prise en charge des extensions Iceberg Spark SQL, ce qui vous permet d'exécuter des procédures Iceberg Spark et certaines commandes SQL Iceberg uniquement (vous l'utiliserez dans une étape ultérieure).
- spark.sql.catalog.demo.io-impl – Iceberg permet aux utilisateurs d'écrire des données sur Amazon S3 via S3FileIO. Le catalogue de données AWS Glue utilise par défaut ce FileIO, et d'autres catalogues peuvent charger ce FileIO à l'aide de la propriété de catalogue io-impl.
Convertir les données au format de table Iceberg
Vous pouvez utiliser Spark sur Amazon EMR ou Athena pour charger la table Iceberg. Dans la session Spark du bloc-notes EMR Studio Workspace, exécutez les commandes suivantes pour charger les données :
Après avoir exécuté le code, vous devriez trouver deux préfixes créés dans le chemin S3 de votre entrepôt de données (s3://iceberg-curated-blog-data/reviews.db/all_reviews
) : données et métadonnées.
Traiter des données incrémentielles à l'aide d'instructions SQL d'insertion, de mise à jour et de suppression dans Athena
Athena est un moteur de requête sans serveur que vous pouvez utiliser pour effectuer des tâches de lecture, d'écriture, de mise à jour et d'optimisation sur des tables Iceberg. Pour démontrer comment le format de lac de données Apache Iceberg prend en charge l'ingestion de données incrémentielle, nous exécutons des instructions SQL d'insertion, de mise à jour et de suppression sur le lac de données.
Accédez à la console Athena et choisissez Éditeur de requête. Si c'est la première fois que vous utilisez l'éditeur de requête Athena, vous devez configurer l'emplacement du résultat de la requête être le compartiment S3 que vous avez créé précédemment. Vous devriez pouvoir voir que la table reviews.all_reviews est disponible pour l'interrogation. Exécutez la requête suivante pour vérifier que vous avez correctement chargé la table Iceberg :
Traitez les données incrémentielles en exécutant des instructions SQL d'insertion, de mise à jour et de suppression :
L'optimisation des performances
Dans cette section, nous passons en revue différentes manières d'améliorer les performances de lecture et d'écriture d'Apache Iceberg.
Configurer les propriétés de la table Apache Iceberg
Apache Iceberg est un format de table, et il prend en charge les propriétés de table pour configurer le comportement de la table comme la lecture, l'écriture et le catalogue. Vous pouvez améliorer les performances de lecture et d'écriture sur les tables Iceberg en ajustant les propriétés de la table.
Par exemple, si vous remarquez que vous écrivez trop de petits fichiers pour une table Iceberg, vous pouvez configurer la taille du fichier d'écriture pour écrire moins de fichiers mais de plus grande taille, afin d'améliorer les performances des requêtes.
Biens immobiliers | Réglage par défaut | Description |
write.target-file-size-bytes | 536870912 (512 MB) | Contrôle la taille des fichiers générés pour cibler environ ce nombre d'octets |
Utilisez le code suivant pour modifier le format du tableau :
Partitionnement et tri
Pour accélérer l'exécution d'une requête, moins il y a de données lues, mieux c'est. Iceberg tire parti des riches métadonnées qu'il capture au moment de l'écriture et facilite des techniques telles que la planification de l'analyse, le partitionnement, l'élagage et les statistiques au niveau des colonnes telles que les valeurs min/max pour ignorer les fichiers de données qui n'ont pas d'enregistrements correspondants. Nous vous expliquons comment la planification et le partitionnement de l'analyse des requêtes fonctionnent dans Iceberg et comment nous les utilisons pour améliorer les performances des requêtes.
Planification de l'analyse des requêtes
Pour une requête donnée, la première étape d'un moteur de requête est la planification de l'analyse, qui est le processus permettant de rechercher les fichiers dans une table nécessaires à une requête. La planification dans une table Iceberg est très efficace, car les métadonnées riches d'Iceberg peuvent être utilisées pour élaguer les fichiers de métadonnées qui ne sont pas nécessaires, en plus de filtrer les fichiers de données qui ne contiennent pas de données correspondantes. Lors de nos tests, nous avons observé qu'Athena a scanné 50 % ou moins de données pour une requête donnée sur une table Iceberg par rapport aux données d'origine avant la conversion au format Iceberg.
Il existe deux types de filtrage :
- Filtrage des métadonnées – Iceberg utilise deux niveaux de métadonnées pour suivre les fichiers dans un instantané : la liste des manifestes et les fichiers manifestes. Il utilise d'abord la liste des manifestes, qui agit comme un index des fichiers manifestes. Lors de la planification, Iceberg filtre les manifestes à l'aide de la plage de valeurs de partition dans la liste des manifestes sans lire tous les fichiers manifestes. Ensuite, il utilise les fichiers manifestes sélectionnés pour obtenir les fichiers de données.
- Filtrage des données – Après avoir sélectionné la liste des fichiers manifestes, Iceberg utilise les données de partition et les statistiques au niveau des colonnes pour chaque fichier de données stocké dans les fichiers manifestes pour filtrer les fichiers de données. Lors de la planification, les prédicats de requête sont convertis en prédicats sur les données de partition et appliqués en premier pour filtrer les fichiers de données. Ensuite, les statistiques de colonne telles que le nombre de valeurs au niveau de la colonne, le nombre de valeurs nulles, les limites inférieures et les limites supérieures sont utilisées pour filtrer les fichiers de données qui ne peuvent pas correspondre au prédicat de la requête. En utilisant des limites supérieures et inférieures pour filtrer les fichiers de données au moment de la planification, Iceberg améliore considérablement les performances des requêtes.
Partitionnement et tri
Le partitionnement est un moyen de regrouper par écrit des enregistrements avec les mêmes valeurs de colonne de clé. L'avantage du partitionnement est des requêtes plus rapides qui n'accèdent qu'à une partie des données, comme expliqué précédemment dans la planification de l'analyse des requêtes : filtrage des données. Iceberg simplifie le partitionnement en prenant en charge le partitionnement caché, de la même manière qu'Iceberg produit des valeurs de partition en prenant une valeur de colonne et en la transformant éventuellement.
Dans notre cas d'utilisation, nous exécutons d'abord la requête suivante sur la table Iceberg non partitionnée. Ensuite, nous partitionnons la table Iceberg par la catégorie des avis, qui sera utilisée dans la condition WHERE de la requête pour filtrer les enregistrements. Avec le partitionnement, la requête pourrait analyser beaucoup moins de données. Voir le code suivant :
Exécutez l'instruction select suivante sur la table all_reviews non partitionnée par rapport à la table partitionnée pour voir la différence de performances :
Le tableau suivant montre l'amélioration des performances du partitionnement des données, avec environ 50 % d'amélioration des performances et 70 % de données analysées en moins.
Nom du jeu de données | Ensemble de données non partitionné | Ensemble de données partitionné |
Durée d'exécution (secondes) | 8.20 | 4.25 |
Données numérisées (Mo) | 131.55 | 33.79 |
Notez que le temps d'exécution est le temps d'exécution moyen avec plusieurs exécutions dans notre test.
Nous avons constaté une bonne amélioration des performances après le partitionnement. Cependant, cela peut être encore amélioré en utilisant les statistiques au niveau des colonnes des fichiers manifestes Iceberg. Afin d'utiliser efficacement les statistiques au niveau des colonnes, vous souhaitez trier davantage vos enregistrements en fonction des modèles de requête. Le tri de l'ensemble de données à l'aide des colonnes souvent utilisées dans les requêtes réorganisera les données de manière à ce que chaque fichier de données se retrouve avec une plage de valeurs unique pour les colonnes spécifiques. Si ces colonnes sont utilisées dans la condition de requête, cela permet aux moteurs de requête d'ignorer davantage les fichiers de données, permettant ainsi des requêtes encore plus rapides.
Copie sur écriture ou lecture sur fusion
Lors de la mise en œuvre de la mise à jour et de la suppression sur les tables Iceberg dans le lac de données, il existe deux approches définies par les propriétés de la table Iceberg :
- Copie sur écriture – Avec cette approche, lorsqu'il y a des changements dans la table Iceberg, que ce soit des mises à jour ou des suppressions, les fichiers de données associés aux enregistrements impactés seront dupliqués et mis à jour. Les enregistrements seront soit mis à jour, soit supprimés des fichiers de données dupliqués. Un nouvel instantané de la table Iceberg sera créé et pointera vers la nouvelle version des fichiers de données. Cela rend les écritures globales plus lentes. Il peut y avoir des situations où des écritures simultanées sont nécessaires avec des conflits, donc une nouvelle tentative doit se produire, ce qui augmente encore plus le temps d'écriture. D'autre part, lors de la lecture des données, aucun processus supplémentaire n'est nécessaire. La requête récupérera les données de la dernière version des fichiers de données.
- Fusion à la lecture – Avec cette approche, lorsqu'il y a des mises à jour ou des suppressions sur la table Iceberg, les fichiers de données existants ne seront pas réécrits ; à la place, de nouveaux fichiers de suppression seront créés pour suivre les modifications. Pour les suppressions, un nouveau fichier de suppression sera créé avec les enregistrements supprimés. Lors de la lecture de la table Iceberg, le fichier de suppression sera appliqué aux données récupérées pour filtrer les enregistrements de suppression. Pour les mises à jour, un nouveau fichier de suppression sera créé pour marquer les enregistrements mis à jour comme supprimés. Ensuite, un nouveau fichier sera créé pour ces enregistrements, mais avec des valeurs mises à jour. Lors de la lecture de la table Iceberg, les fichiers supprimés et nouveaux seront appliqués aux données récupérées pour refléter les dernières modifications et produire les résultats corrects. Ainsi, pour toute requête ultérieure, une étape supplémentaire pour fusionner les fichiers de données avec la suppression et les nouveaux fichiers se produira, ce qui augmentera généralement le temps de requête. D'autre part, les écritures peuvent être plus rapides car il n'est pas nécessaire de réécrire les fichiers de données existants.
Pour tester l'impact des deux approches, vous pouvez exécuter le code suivant pour définir les propriétés de la table Iceberg :
Exécutez les instructions SQL de mise à jour, de suppression et de sélection dans Athena pour afficher la différence d'exécution entre la copie sur écriture et la fusion sur lecture :
Le tableau suivant récapitule les durées d'exécution des requêtes.
Question | Copie sur écriture | Fusion à la lecture | ||||
MISE À JOUR | EFFACER | SELECT | MISE À JOUR | EFFACER | SELECT | |
Durée d'exécution (secondes) | 66.251 | 116.174 | 97.75 | 10.788 | 54.941 | 113.44 |
Données numérisées (Mo) | 494.06 | 3.07 | 137.16 | 494.06 | 3.07 | 137.16 |
Notez que le temps d'exécution est le temps d'exécution moyen avec plusieurs exécutions dans notre test.
Comme le montrent les résultats de nos tests, il y a toujours des compromis entre les deux approches. L'approche à utiliser dépend de vos cas d'utilisation. En résumé, les considérations se résument à la latence entre la lecture et l'écriture. Vous pouvez vous référer au tableau suivant et faire le bon choix.
. | Copie sur écriture | Fusion à la lecture |
Avantages | Lectures plus rapides | Écritures plus rapides |
Inconvénients | Écritures coûteuses | Latence plus élevée sur les lectures |
Quand l’utiliser | Bon pour les lectures fréquentes, les mises à jour et les suppressions peu fréquentes ou les mises à jour par lots volumineux | Bon pour les tables avec des mises à jour et des suppressions fréquentes |
Compactage des données
Si la taille de votre fichier de données est petite, vous pourriez vous retrouver avec des milliers ou des millions de fichiers dans une table Iceberg. Cela augmente considérablement l'opération d'E/S et ralentit les requêtes. De plus, Iceberg suit chaque fichier de données dans un ensemble de données. Plus de fichiers de données entraînent plus de métadonnées. Cela augmente à son tour la surcharge et les opérations d'E/S lors de la lecture des fichiers de métadonnées. Afin d'améliorer les performances des requêtes, il est recommandé de compacter les petits fichiers de données en fichiers de données plus volumineux.
Lors de la mise à jour et de la suppression d'enregistrements dans la table Iceberg, si l'approche de lecture sur fusion est utilisée, vous pouvez vous retrouver avec de nombreuses petites suppressions ou de nouveaux fichiers de données. L'exécution du compactage combinera tous ces fichiers et créera une version plus récente du fichier de données. Cela élimine le besoin de les réconcilier lors des lectures. Il est recommandé d'avoir des tâches de compactage régulières pour avoir un impact le moins possible sur les lectures tout en maintenant une vitesse d'écriture plus rapide.
Exécutez la commande de compactage des données suivante, puis exécutez la requête de sélection à partir d'Athena :
Le tableau suivant compare le temps d'exécution avant et après le compactage des données. Vous pouvez constater une amélioration des performances d'environ 40 %.
Question | Avant le compactage des données | Après le compactage des données |
Durée d'exécution (secondes) | 97.75 | en 32.676 secondes |
Données numérisées (Mo) | 137.16 M | 189.19 M |
Notez que les requêtes de sélection s'exécutaient sur le all_reviews
table après les opérations de mise à jour et de suppression, avant et après le compactage des données. Le temps d'exécution est le temps d'exécution moyen avec plusieurs exécutions dans notre test.
Nettoyer
Après avoir suivi la procédure pas à pas de la solution pour effectuer les cas d'utilisation, procédez comme suit pour nettoyer vos ressources et éviter des coûts supplémentaires :
- Supprimez les tables et la base de données AWS Glue d'Athena ou exécutez le code suivant dans votre bloc-notes :
- Sur la console EMR Studio, choisissez Espaces de travail dans le volet de navigation.
- Sélectionnez l'espace de travail que vous avez créé et choisissez Supprimer.
- Sur la console EMR, accédez au Studios .
- Sélectionnez le Studio que vous avez créé et choisissez Supprimer.
- Sur la console EMR, choisissez Clusters dans le volet de navigation.
- Sélectionnez le cluster et choisissez Mettre fin.
- Supprimez le compartiment S3 et toutes les autres ressources que vous avez créées dans le cadre des prérequis pour cette publication.
Conclusion
Dans cet article, nous avons présenté le framework Apache Iceberg et comment il aide à résoudre certains des défis auxquels nous sommes confrontés dans un lac de données moderne. Ensuite, nous vous avons présenté une solution pour traiter les données incrémentielles dans un lac de données à l'aide d'Apache Iceberg. Enfin, nous avons approfondi le réglage des performances afin d'améliorer les performances de lecture et d'écriture pour nos cas d'utilisation.
Nous espérons que cet article vous fournira des informations utiles pour décider si vous souhaitez adopter Apache Iceberg dans votre solution de lac de données.
À propos des auteurs
Flore Wu est architecte résident principal chez AWS Data Lab. Elle aide les entreprises clientes à créer des stratégies d'analyse de données et à créer des solutions pour accélérer les résultats de leur entreprise. Dans ses temps libres, elle aime jouer au tennis, danser la salsa et voyager.
Daniel Li est un architecte de solutions principal chez Amazon Web Services. Il se concentre sur l'aide aux clients pour développer, adopter et mettre en œuvre des services et une stratégie cloud. Lorsqu'il ne travaille pas, il aime passer du temps à l'extérieur avec sa famille.
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
- La source: https://aws.amazon.com/blogs/big-data/use-apache-iceberg-in-a-data-lake-to-support-incremental-data-processing/
- 10
- 100
- 11
- 2022
- 2023
- 7
- 9
- a
- Capable
- À propos
- au dessus de
- accélérer
- accès
- Gestion des accès
- Action
- actes
- ajout
- Supplémentaire
- propos
- adresses
- Ajoute
- adopter
- Avantage
- Après
- à opposer à
- Tous
- permet
- toujours
- Amazon
- Amazon DME
- Amazon Web Services
- Analytique
- analytique
- ainsi que
- annoncé
- Apache
- applications
- appliqué
- une approche
- approches
- approprié
- architecture
- associé
- Authentification
- disponibilité
- disponibles
- moyen
- éviter
- AWS
- Colle AWS
- basé
- car
- devenez
- before
- profiter
- Améliorée
- jusqu'à XNUMX fois
- plus gros
- Bootstrap
- construire
- Développement
- entreprises
- captures
- Capturer
- maisons
- cas
- catalogue
- catalogues
- Catégories
- globaux
- Change
- Modifications
- vérifier
- le choix
- Selectionnez
- classification
- le cloud
- services de cloud computing
- Grappe
- code
- Colonne
- Colonnes
- combiner
- comment
- commettre
- par rapport
- complet
- calcul
- concurrent
- condition
- les configurations
- considérations
- Console
- Conversion
- converti
- rentable
- Costs
- pourriez
- engendrent
- créée
- crée des
- organisée
- Courant
- des clients
- Clients
- Danse
- tableau de bord
- données
- Analyse de Donnée
- Lac de données
- informatique
- entrepôt de données
- Base de données
- ensembles de données
- profond
- plongée profonde
- Réglage par défaut
- défini
- Démo
- démontrer
- dépend
- un
- détails
- développer
- Développement
- différence
- différent
- discuter
- Ne pas
- down
- Dramatiquement
- Goutte
- pendant
- chacun
- Plus tôt
- "Early Bird"
- éditeur
- de manière efficace
- efficace
- non plus
- élimine
- activé
- permettant
- se termine
- Moteur
- Moteurs
- Entrer
- Entreprise
- clients entreprise
- Ether (ETH)
- Pourtant, la
- évolution
- évolue
- évolution
- exemple
- existant
- existe
- expliqué
- extensions
- supplémentaire
- facilite
- famille
- RAPIDE
- plus rapide
- Fonctionnalités:
- Figure
- Déposez votre dernière attestation
- Fichiers
- une fonction filtre
- filtration
- filtres
- finalement
- Trouvez
- Prénom
- première fois
- se concentre
- suivre
- Abonnement
- le format
- Framework
- fréquent
- de
- plus
- En outre
- Général
- généré
- obtenez
- donné
- Goes
- Bien
- considérablement
- Réservation de groupe
- main
- arriver
- aider
- aider
- aide
- caché
- hiérarchie
- de haut niveau
- haute performance
- haute performance
- Ruche
- d'espérance
- Comment
- How To
- Cependant
- HTML
- HTTPS
- IAM
- Active
- gestion des identités et des accès
- Impact
- impact
- Mettre en oeuvre
- la mise en oeuvre
- la mise en œuvre
- améliorer
- amélioré
- amélioration
- améliore
- in
- Y compris
- Améliore
- increased
- Augmente
- indice
- individuel
- d'information
- installer
- plutôt ;
- l'intégration
- introduit
- Isole
- IT
- Janvier
- Emplois
- clés / KEY :
- laboratoire
- lac
- gros
- plus importantes
- Latence
- Nouveautés
- dernière version
- couche
- poules pondeuses
- conduire
- niveaux
- LIMIT
- Gamme
- Liste
- peu
- charge
- emplacement
- faire
- FAIT DU
- gestion
- de nombreuses
- marque
- marché
- Match
- assorti
- aller
- Métadonnées
- pourrait
- des millions
- Villas Modernes
- PLUS
- Bougez
- plusieurs
- prénom
- Nommé
- NAVIGUER
- Navigation
- Besoin
- nécessaire
- Besoins
- Nouveauté
- cahier
- objet
- ouvert
- opération
- Opérations
- à mettre en œuvre pour gérer une entreprise rentable. Ce guide est basé sur trois décennies d'expérience
- Optimiser
- de commander
- original
- Autre
- l'extérieur
- global
- propre
- pain
- partie
- chemin
- motifs
- effectuer
- performant
- Physique
- et la planification de votre patrimoine
- Platon
- Intelligence des données Platon
- PlatonDonnées
- jouer
- plug-in
- des notes bonus
- Populaire
- possible
- Post
- alimenté
- conditions préalables
- procédures
- processus
- traitement
- produire
- propriétés
- propriété
- fournir
- fournit
- aportando
- disposition
- gamme
- raw
- les données brutes
- Lire
- en cours
- réal
- récemment
- recommandé
- Articles
- refléter
- région
- registres
- Standard
- libérer
- libéré
- restant
- conditions
- a besoin
- Ressources
- résultat
- Résultats
- Avis
- Rich
- Rôle
- racine
- Courir
- pour le running
- même
- balayage
- secondes
- Section
- sécurité
- choisi
- la sélection
- Sans serveur
- service
- Services
- Session
- set
- Sets
- mise
- Paramétres
- devrait
- montrer
- Spectacles
- étapes
- situations
- Taille
- ralentit
- petit
- Instantané
- So
- Logiciels
- sur mesure
- Solutions
- quelques
- Spark
- groupe de neurones
- vitesse
- Dépenses
- SQL
- Commencez
- Région
- Déclaration
- déclarations
- stats
- étapes
- Étapes
- Encore
- storage
- Boutique
- stockée
- STORES
- les stratégies
- de Marketing
- structuré
- données structurées et non structurées
- studio
- sous-réseau
- ultérieur
- Avec succès
- tel
- suffisant
- RÉSUMÉ
- Support
- Appareils
- Appuyer
- Les soutiens
- table
- prend
- prise
- Target
- tâches
- techniques
- tennis
- tester
- Essais
- tests
- La
- les informations
- L'État
- leur
- ainsi
- milliers
- trois
- Avec
- fiable
- voyage dans le temps
- à
- ensemble
- trop
- les outils
- top
- Total
- suivre
- Transactions
- transformer
- Voyage
- Voyages
- TOUR
- types
- sous
- unique
- Mises à jour
- a actualisé
- Actualités
- la mise à jour
- URL
- utilisé
- cas d'utilisation
- utilisateurs
- d'habitude
- VAL
- Plus-value
- Valeurs
- vérifier
- version
- marcha
- walkthrough
- Entrepots
- montres
- façons
- web
- services Web
- Quoi
- que
- qui
- tout en
- large
- Large gamme
- sera
- sans
- Activités:
- de travail
- vos contrats
- pourra
- écrire
- écriture
- Votre
- zéphyrnet