Utiliser Azure Data Lake Storage Gen2 avec des clusters Azure HDInsight

Azure Data Lake Storage Gen2 est un service de stockage cloud dédié à l’analytique Big Data et intégré au Stockage Blob Azure. Data Lake Storage Gen2 réunit les capacités du Stockage Blob Azure et d’Azure Data Lake Storage Gen1. Le service qui en résulte offre les fonctionnalités d’Azure Data Lake Storage Gen1, notamment la sémantique du système de fichiers, la sécurité au niveau des répertoires et des fichiers et l’adaptabilité. En ce qui concerne les fonctionnalités à faible coût du stockage Blob Azure, elles comprennent le stockage hiérarchisé, la haute disponibilité et la récupération d’urgence.

Pour une comparaison complète des options de création de cluster à l'aide de Data Lake Storage Gen2, consultez Comparer les options de stockage à utiliser avec les clusters Azure HDInsight.

Avertissement

La facturation des clusters HDInsight est calculée au prorata des minutes écoulées, que vous les utilisiez ou non. Veillez à supprimer votre cluster une fois que vous avez terminé de l’utiliser. Consultez Guide pratique pour supprimer un cluster HDInsight.

Disponibilité de Data Lake Storage Gen2

Data Lake Storage Gen2 est disponible comme option de stockage pour presque tous les types de clusters Azure HDInsight en tant que compte par défaut et compte de stockage supplémentaire. HBase, en revanche, ne peut avoir qu’un seul compte avec Data Lake Storage Gen2.

Notes

Après avoir sélectionné Data Lake Storage Gen2 comme type de stockage principal, il n’est pas possible de sélectionner Data Lake Storage Gen1 comme stockage supplémentaire.

Création de clusters HDInsight avec Data Lake Storage Gen2

Suivez les liens ci-dessous pour obtenir des instructions détaillées sur la création de clusters HDInsight avec accès à Data Lake Storage Gen2.

Contrôle d’accès à Data Lake Storage Gen2 dans HDInsight

Quels sont les types d’autorisation pris en charge par Data Lake Storage Gen2 ?

Data Lake Storage Gen2 utilise un modèle de contrôle d’accès qui prend en charge le contrôle d’accès en fonction du rôle Azure (RBAC Azure) et les listes de contrôle d’accès (ACL) POSIX. Data Lake Storage Gen1 prend en charge les listes de contrôle d’accès uniquement pour contrôler l’accès aux données.

Azure RBAC utilise des attributions de rôles pour appliquer efficacement des ensembles d’autorisations aux utilisateurs, groupes et principaux de service des ressources Azure. En règle générale, ces ressources Azure sont limitées aux ressources de niveau supérieur (par exemple, les comptes de stockage Blob Azure). Pour le Stockage Blob Azure, de même que Data Lake Storage Gen2, ce mécanisme a été étendu à la ressource du système de fichiers.

Pour plus d’informations sur les autorisations de fichiers avec Azure RBAC, consultez Contrôle d’accès en fonction du rôle Azure (Azure RBAC).

Pour plus d’informations sur les autorisations de fichiers avec des listes ACL, consultez Listes de contrôle d’accès sur les fichiers et répertoires.

Comment contrôler l’accès à mes données dans Data Lake Storage Gen2 ?

La capacité de votre cluster HDInsight à accéder aux fichiers dans Data Lake Storage Gen2 est contrôlée par le biais d’identités managées. Une identité managée est une identité inscrite dans Microsoft Entra dont les informations d’identification sont gérées par Azure. Grâce aux identités managées, il n’est pas nécessaire d’inscrire des principaux de service dans Microsoft Entra ID. ni de gérer des informations d’identification, par exemple des certificats.

Les services Azure utilisent deux types d’identités managées : celles affectées par le système et celles affectées par l’utilisateur. HDInsight utilise des identités managées affectées par l’utilisateur pour accéder à Data Lake Storage Gen2. Une user-assigned managed identity est créée en tant que ressource Azure autonome. Via un processus de création, Azure crée une identité dans le tenant Microsoft Entra approuvé par l’abonnement en cours d’utilisation. Une fois l’identité créée, elle peut être affectée à une ou plusieurs instances de service Azure.

Le cycle de vie d’une identité attribuée par l’utilisateur est géré séparément du cycle de vie des instances de service Azure auxquelles elle est affectée. Pour en savoir plus sur les identités managées, consultez la section Que sont les identités managées pour les ressources Azure ?.

Comment définir les autorisations permettant aux utilisateurs de Microsoft Entra d’interroger des données dans Data Lake Storage Gen2 en utilisant Hive ou d’autres services ?

Pour définir des autorisations pour que les utilisateurs puissent interroger des données, utilisez les groupes de sécurité Microsoft Entra comme principal affecté dans des listes de contrôle d’accès (ACL). N’attribuez pas directement des autorisations d’accès aux fichiers à des utilisateurs ou principaux de service individuels. Grâce aux groupes de sécurité Microsoft Entra qui contrôlent le flux d’autorisations, vous pouvez ajouter et supprimer des utilisateurs ou des principaux de service sans réappliquer des ACL à une structure de répertoires entière. Il vous suffit d’ajouter ou de supprimer les utilisateurs du groupe de sécurité Microsoft Entra approprié. Les listes de contrôle d’accès ne sont pas héritées. Par conséquent, pour les réappliquer, vous devez les mettre à jour dans chaque fichier et sous-répertoire.

Accès aux fichiers à partir du cluster

Il existe plusieurs méthodes pour accéder aux fichiers dans Data Lake Storage Gen2 à partir d’un cluster HDInsight.

  • Utilisation du nom complet. Avec cette approche, vous fournissez le chemin d’accès complet au fichier auquel vous souhaitez accéder.

    abfs://<containername>@<accountname>.dfs.core.windows.net/<file.path>/
    
  • Utilisation du format de chemin d’accès raccourci. Avec cette approche, vous remplacez le chemin d’accès à la racine du cluster par :

    abfs:///<file.path>/
    
  • Utilisation du chemin d’accès relatif. Avec cette approche, vous fournissez uniquement le chemin d’accès relatif au fichier auquel vous souhaitez accéder.

    /<file.path>/
    

Exemples d’accès aux données

Les exemples sont basés sur une connexion ssh au nœud principal du cluster. Les exemples utilisent les trois schémas d’URI. Remplacez CONTAINERNAME et STORAGEACCOUNT par les valeurs correspondantes

Quelques commandes hdfs

  1. Créez un fichier sur le stockage local.

    touch testFile.txt
    
  2. Créez des répertoires sur le stockage en cluster.

    hdfs dfs -mkdir abfs://CONTAINERNAME@STORAGEACCOUNT.dfs.core.windows.net/sampledata1/
    hdfs dfs -mkdir abfs:///sampledata2/
    hdfs dfs -mkdir /sampledata3/
    
  3. Copiez les données du stockage local vers le stockage en cluster.

    hdfs dfs -copyFromLocal testFile.txt  abfs://CONTAINERNAME@STORAGEACCOUNT.dfs.core.windows.net/sampledata1/
    hdfs dfs -copyFromLocal testFile.txt  abfs:///sampledata2/
    hdfs dfs -copyFromLocal testFile.txt  /sampledata3/
    
  4. Affichez le contenu du répertoire sur le stockage en cluster.

    hdfs dfs -ls abfs://CONTAINERNAME@STORAGEACCOUNT.dfs.core.windows.net/sampledata1/
    hdfs dfs -ls abfs:///sampledata2/
    hdfs dfs -ls /sampledata3/
    

Création d’une table Hive

Trois emplacements de fichiers sont indiqués à titre d’illustration. Pour l’exécution réelle, n’utilisez qu’une seule des entrées LOCATION.

DROP TABLE myTable;
CREATE EXTERNAL TABLE myTable (
    t1 string,
    t2 string,
    t3 string,
    t4 string,
    t5 string,
    t6 string,
    t7 string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
STORED AS TEXTFILE
LOCATION 'abfs://CONTAINERNAME@STORAGEACCOUNT.dfs.core.windows.net/example/data/';
LOCATION 'abfs:///example/data/';
LOCATION '/example/data/';

Étapes suivantes