Meilleures pratiques relatives à l’utilisation de Data Lake Storage

Cet article présente les bonnes pratiques qui vous permettent d’optimiser les performances, de réduire les coûts et de sécuriser votre compte de stockage Azure compatible avec Data Lake Storage.

Rechercher de la documentation

Azure Data Lake Storage n’est ni un type de compte ni un service dédié. Il s’agit d’un ensemble de fonctionnalités qui prennent en charge des charges de travail analytiques à débit élevé. La documentation Data Lake Storage présente les bonnes pratiques et des conseils pour l’utilisation de ces fonctionnalités. Pour tous les autres aspects de la gestion du compte, tels que la configuration de la sécurité réseau, la conception pour assurer une haute disponibilité et la reprise d’activité après sinistre, consultez la documentation sur le Stockage Blob.

Évaluer la prise en charge des fonctionnalités et problèmes connus

Utilisez le modèle suivant lorsque vous configurez votre compte de manière à utiliser les fonctionnalités de stockage d’objets Blob.

1. Consultez l’article Prise en charge des fonctionnalités de stockage Blob dans les comptes de stockage Azure pour déterminer si une fonctionnalité est entièrement prise en charge dans votre compte. Certaines fonctionnalités ne sont pas encore prises en charge ou bénéficient d’une prise en charge partielle dans les comptes compatibles avec Data Lake Storage. La prise en charge des fonctionnalités est en constante évolution. Veillez donc à consulter régulièrement cet article pour découvrir les mises à jour.

2. Consultez l’article Problèmes connus avec Azure Data Lake Storage pour déterminer s’il existe des limitations ou des conseils spécifiques relatifs à la fonctionnalité que vous envisagez d’utiliser.

3. Recherchez des articles sur les fonctionnalités pour obtenir des conseils spécifiques aux comptes compatibles avec Data Lake Storage.

Comprendre les termes utilisés dans la documentation

En passant d’un ensemble de contenu à l’autre, vous remarquez quelques légères différences terminologiques. Par exemple, le contenu présenté dans la documentation du stockage Blob utilise le terme blob au lieu de fichier. Techniquement, les fichiers que vous importez dans votre compte de stockage deviennent des blobs dans votre compte. Par conséquent, le terme est correct. Toutefois, le terme blob peut prêter à confusion si vous êtes habitué au terme fichier. Vous voyez également le terme conteneur utilisé pour faire référence à un système de fichiers. Considérez ces termes comme des synonymes.

Passer à Premium

Si vos charges de travail nécessitent une latence faible et constante ou un nombre élevé d’opérations d’entrée/sortie par seconde (IOPS), envisagez d’utiliser un compte de stockage Premium pour objets blob de blocs. Ce type de compte rend les données disponibles via du matériel hautes performances. Les données sont stockées sur des disques SSD optimisés pour une latence faible. Les disques SSD offrent un débit plus élevé que les disques durs traditionnels. Les coûts de stockage des performances Premium sont plus élevés, mais les coûts des transactions sont inférieurs. Par conséquent, si vos charges de travail exécutent un grand nombre de transactions, un compte Blob de blocs Premium peut être économique.

Si votre compte de stockage doit être utilisé pour l’analytique, nous vous recommandons vivement d’utiliser Azure Data Lake Storage avec un compte de stockage d’objets blob de blocs Premium. Cette combinaison, qui consiste à utiliser des comptes de stockage Blob de blocs Premium avec un compte pour lequel Data Lake Storage est activé, est appelée le niveau premium pour Azure Data Lake Storage.

Optimiser pour l’ingestion de données

Lorsque vous ingérez des données depuis un système source, le matériel source, le matériel réseau source ou la connectivité réseau vers votre compte de stockage peuvent créer des goulots d’étranglement.

Matériel source

Que vous utilisiez des machines locales ou des machines virtuelles dans Azure, sélectionnez soigneusement le matériel approprié. Pour le matériel disque, envisagez d’utiliser des disques SSD et de choisir le matériel disque qui a des broches plus rapides. Pour le matériel réseau, utilisez les contrôleurs d’interface réseau les plus rapides possibles. Dans Azure, utilisez Azure machines virtuelles D14, qui disposent du disque et du matériel réseau appropriés.

Vérification de la connectivité réseau au compte de stockage

La connectivité réseau entre vos données sources et votre compte de stockage peut parfois créer un goulot d’étranglement. Lorsque vos données sources sont locales, envisagez d’utiliser un lien dédié avec Azure ExpressRoute. Si vos données sources sont dans Azure, les performances seront meilleures si les données sont dans la même région Azure que le compte Data Lake Storage.

Configurer les outils d’ingestion des données pour une parallélisation maximale

Pour obtenir les meilleures performances, utilisez tout le débit disponible en effectuant autant de lectures et d’écritures en parallèle que possible.

Le tableau suivant résume les paramètres principaux pour plusieurs outils d’ingestion populaires.

Pour obtenir une liste plus complète des outils d’ingestion, consultez Sélectionner des outils de migration.

Votre compte peut être mis à l’échelle afin de fournir le débit nécessaire pour tous les scénarios d’analyse. Par défaut, un compte Data Lake Storage fournit suffisamment de débit dans sa configuration par défaut pour répondre aux besoins d’une vaste catégorie de cas d’usage. Si vous atteignez la limite par défaut, contactez Support Azure afin de configurer votre compte pour qu’il puisse offrir un débit plus élevé.

Structurer des jeux de données

Envisagez de préplanifier la structure de vos données. Le format de fichier, la taille de fichier et la structure de répertoires peuvent tous avoir un impact sur les performances et les coûts.

Formats de fichiers

Vous pouvez ingérer des données dans différents formats. Les données peuvent apparaître dans des formats lisibles par l’homme tels que JSON, CSV ou XML, ou sous forme de formats binaires compressés tels que .tar.gz. Les données peuvent être de différentes tailles. Les données peuvent être composées de fichiers volumineux (quelques téraoctets), tels que les données provenant d’une exportation d’une table SQL à partir de vos systèmes locaux. Les données peuvent également se présenter sous la forme d’un grand nombre de fichiers minuscules (quelques kilo-octets), tels que les données d’événements en temps réel provenant d’une solution Internet des objets (IoT). Vous pouvez optimiser l’efficacité et les coûts en choisissant un format de fichier et une taille de fichier appropriés.

Hadoop prend en charge un ensemble de formats de fichier qui sont optimisés pour le stockage et le traitement des données structurées. Certains formats courants sont Avro, Parquet et le format ORC (Optimized Row Columnar). Tous ces formats sont des formats de fichiers binaires lisibles par un ordinateur. Ils sont compressés pour vous aider à gérer la taille des fichiers. Ils ont un schéma incorporé dans chaque fichier, ce qui leur permet de se décrire de manière autonome. La différence entre les formats réside dans la façon dont les données sont stockées. Avro stocke les données dans un format en lignes, alors que les formats Parquet et ORC stockent des données dans format en colonnes.

Utilisez le format de fichier Avro lorsque vos modèles d’E/S sont plus lourds en écriture, ou les modèles de requête favorisent la récupération de plusieurs lignes d’enregistrements dans leur intégralité. Par exemple, le format Avro fonctionne correctement avec un bus de messages tel que Event Hubs ou Kafka qui écrit plusieurs événements ou messages en succession.

Utilisez des formats de fichier Parquet et ORC lorsque les modèles d’E/S sont plus lourds en lecture ou lorsque les modèles de requête se concentrent sur un sous-ensemble de colonnes dans les enregistrements. Les transactions de lecture peuvent être optimisées pour récupérer des colonnes spécifiques au lieu de lire la totalité de l’enregistrement.

Apache Parquet est un format de fichier open source optimisé pour les pipelines d’analyse à forte intensité de lecture. La structure de stockage en colonnes de Parquet vous permet d’ignorer les données non pertinentes. Vos requêtes sont bien plus efficaces, car elles permettent d’étendre de manière étroite les données à envoyer du stockage au moteur d’analyse. En outre, étant donné que les types de données similaires (pour une colonne) sont stockés ensemble, Parquet prend en charge des schémas efficaces de compression et d’encodage des données qui peuvent réduire les coûts de stockage de données. Les services tels que Azure Synapse Analytics, Azure Databricks et Azure Data Factory disposent de fonctionnalités natives qui tirent parti des formats de fichiers Parquet.

Taille du fichier

Des fichiers plus volumineux entraînent de meilleures performances et réduisent les coûts.

En règle générale, les moteurs d’analyse tels que HDInsight ont une surcharge par fichier qui implique des tâches, telles que le listage, la vérification de l’accès et l’exécution de diverses opérations de métadonnées. Si vous stockez vos données autant de petits fichiers, ce choix peut affecter négativement les performances. En général, organisez vos données en fichiers de plus grande taille pour obtenir de meilleures performances (de 256 Mo à 100 Go). Certains moteurs et applications peuvent avoir des difficultés à traiter efficacement les fichiers supérieurs à 100 Go.

L’augmentation de la taille des fichiers peut également réduire les coûts des transactions. Les opérations de lecture et d’écriture sont facturées par incréments de 4 mégaoctets afin que vous soyez facturé pour l’opération, que le fichier contienne 4 mégaoctets ou seulement quelques kilo-octets. Pour obtenir des informations de tarification, consultez Tarification d’Azure Data Lake Storage.

Parfois, les pipelines de données ont un contrôle limité sur les données brutes qui contiennent un grand nombre de petits fichiers. En général, votre système doit disposer d’un certain type de processus pour agréger de petits fichiers en fichiers plus volumineux à utiliser par les applications en aval. Si vous traitez des données en temps réel, vous pouvez utiliser un moteur de diffusion en continu en temps réel (tel que Azure Stream Analytics ou Spark Streaming) avec un répartiteur de messages (par exemple, Event Hubs ou Apache Kafka) pour stocker vos données sous forme de fichiers plus volumineux. Au fur et à mesure que vous regroupez des fichiers de petite taille en fichiers plus volumineux, envisagez de les enregistrer dans un format optimisé en lecture comme Apache Parquet pour le traitement en aval.

Structure de répertoires

Chaque charge de travail a des exigences différentes pour la façon dont elle consomme des données. Toutefois, lors de l’utilisation d’Internet des objets (IoT), de scénarios de traitement par lots ou lors de l’optimisation des données de série chronologique, tenez compte de ces dispositions courantes.

Structure de l’IdO

Dans les charges de travail IoT, vous pouvez ingérer une grande quantité de données qui s’étend sur de nombreux produits, appareils, organisations et clients. Préplanez la disposition du répertoire pour l’organisation, la sécurité et le traitement efficace des données pour les consommateurs de flux inférieurs. Voici un modèle général de disposition à prendre en compte :

• {Region}/{SubjectMatter(s)}/{aaaa}/{mm}/{dd}/{hh}/

Par exemple, la télémétrie d’arrivée d’un moteur d’avion dans le Royaume-Uni ressemble à la structure suivante :

• UK/Planes/BA1293/Engine1/2017/08/11/12/

Dans cet exemple, en plaçant la date à la fin de la structure de répertoire, vous pouvez utiliser des listes de contrôle d’accès pour sécuriser plus facilement les régions et les sujets à des utilisateurs et des groupes spécifiques. Si vous placez la structure de date au début, il sera bien plus difficile de sécuriser ces régions et sujets. Par exemple, si vous souhaitez fournir un accès uniquement aux données provenant du Royaume-Uni ou à certains plans, vous devez appliquer une autorisation distincte pour de nombreux répertoires sous chaque répertoire horaire. Cette structure augmenterait également de façon exponentielle le nombre de répertoires au fil du temps.

Structure des tâches par lots

Une approche couramment utilisée dans le traitement par lots consiste à placer les données dans un répertoire « in ». Ensuite, une fois les données traitées, les nouvelles données sont placées dans un répertoire « out » pour que les processus en aval puissent les consommer. Cette structure de répertoire est parfois utilisée pour des travaux qui nécessitent un traitement sur des fichiers individuels et qui ne nécessitent pas forcément de traitement parallèle massif sur des jeux de données volumineux. Tout comme la structure IoT recommandée plus haut, une bonne structure de répertoire dispose de répertoires de niveau parent pour des choses telles que la région et les sujets (par exemple l’organisation, le produit ou le producteur). Tenez compte de la date et de l’heure dans la structure pour permettre une meilleure organisation, des recherches filtrées, la sécurité et l’automatisation du traitement. Le niveau granularité de la structure de date est déterminé par l’intervalle de chargement ou de traitement des données, par exemple à l’heure, quotidien, ou mensuel.

Parfois le traitement de fichiers échoue en raison de corruption des données ou de formats inattendus. Dans ces cas, une structure de répertoire peut bénéficier d’un dossier /bad dans lequel les fichiers sont déplacés pour une inspection plus approfondie. La tâche de traitement par lots peut aussi gérer le rapport ou la notification de ces fichiers bad en vue d’une intervention manuelle. Considérez la structure de modèle suivante :

• {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Mauvais/{yyyy}/{mm}/{dd}/{hh}/

Par exemple, une firme marketing qui reçoit quotidiennement des extraits de données de mises à jour client de la part de leurs clients en Amérique du Nord. Avant et après avoir été traité, il peut ressembler à l’extrait de code suivant :

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

Dans le cas courant du traitement des données par lots directement dans des bases de données telles que Hive ou des bases de données SQL traditionnelles, il n’est pas nécessaire d’utiliser un répertoireentrant ou sortant, car la sortie passe déjà dans un dossier distinct pour la table Hive ou la base de données externe. Par exemple, les extraits quotidiens des clients sont déposés dans leurs répertoires respectifs. Ensuite, un service tel que Azure Data Factory, Apache Oozie ou Apache Airflow déclenche un travail Hive ou Spark quotidien pour traiter et écrire les données dans une table Hive.

Structure de données de séries chronologiques

Pour les charges de travail Hive, le nettoyage de partition de données de série chronologique peut aider certaines requêtes à lire uniquement un sous-ensemble de données, ce qui améliore les performances.

Ces pipelines qui ingèrent des données de série chronologique placent souvent leurs fichiers avec un nom structuré pour les fichiers et les dossiers. Voici un exemple courant pour les données structurées par date :

/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv

Notez que les informations de date / heure s’affichent à la fois en tant que dossiers et dans le nom de fichier.

Pour la date et l’heure, le modèle suivant est récurrent.

/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

Là encore, le type d’organisation des dossiers et fichiers sélectionné doit optimiser les plus gros fichiers et un nombre raisonnable de fichiers par dossier.

Configurer la sécurité

Commencez par passer en revue les recommandations de l’article Recommandations de sécurité pour Stockage Blob. Vous trouverez des conseils sur la meilleure pratique pour protéger vos données contre la suppression accidentelle ou malveillante, sécuriser les données derrière un pare-feu et utiliser Microsoft Entra ID comme base de la gestion des identités.

Consultez ensuite l’article Modèle de contrôle d’accès dans Azure Data Lake Storage pour obtenir une aide spécifique aux comptes compatibles avec Data Lake Storage. Cet article vous aide à comprendre comment utiliser des rôles Azure RBAC (contrôle d’accès en fonction du rôle) avec des listes de contrôle d’accès (ACL) pour appliquer des autorisations de sécurité aux répertoires et fichiers de votre système de fichiers hiérarchique.

Ingérer, traiter et analyser

Vous pouvez ingérer des données dans un compte Data Lake Storage activé à partir de nombreuses sources différentes et de différentes façons.

Par exemple, vous pouvez ingérer de grands jeux de données à partir de clusters HDInsight et Hadoop, ou de plus petits jeux de données ad hoc pour le prototypage d’applications. Vous pouvez ingérer des données diffusées en continu que différentes sources génèrent, telles que des applications, des appareils et des capteurs. Pour ce type de données, utilisez des outils pour capturer et traiter les données sur une base événement par événement en temps réel, puis écrivez les événements par lots dans votre compte. Vous pouvez également ingérer des journaux d’activité de serveur web qui contiennent des informations telles que l’historique des requêtes de pages. Pour les données de journal, envisagez d’écrire des scripts personnalisés ou des applications pour les charger afin que vous puissiez inclure votre composant de chargement de données dans le cadre de votre application Big Data plus volumineuse.

Une fois les données disponibles dans votre compte, vous pouvez exécuter l’analyse sur ces données, créer des visualisations et même télécharger des données sur votre ordinateur local ou dans d’autres référentiels, tels qu’une base de données Azure SQL ou SQL Server instance.

Le tableau suivant recommande des outils que vous pouvez utiliser pour ingérer, analyser, visualiser et télécharger des données. Utilisez les liens de ce tableau pour obtenir des instructions sur la configuration et l’utilisation de chaque outil.

Surveiller la télémétrie

La surveillance de l’utilisation et des performances de votre service est une partie importante de l’opérationnalisation de votre service. Parmi les exemples de données de télémétrie, citons les opérations fréquentes, les opérations avec une latence élevée ou les opérations qui provoquent une limitation côté service.

Vous pouvez accéder à toutes les données de télémétrie de votre compte de stockage par le biais de journaux d’activité stockage Azure dans Azure Monitor. Cette fonctionnalité intègre votre compte de stockage à Log Analytics et Event Hubs, tout en vous permettant d’archiver les journaux vers un autre compte de stockage. Pour afficher la liste complète des métriques et des journaux des ressources et de leur schéma associé, consultez stockage Azure référence des données de surveillance.

Le choix de l’emplacement de stockage de vos journaux dépend de la manière dont vous comptez y accéder. Par exemple, si vous souhaitez accéder à vos journaux en quasi temps réel et être en mesure de mettre en corrélation les événements dans les journaux avec d’autres métriques de Azure Monitor, stockez vos journaux dans un espace de travail Log Analytics. Ensuite, interrogez vos journaux à l’aide de KQL et rédigez des requêtes qui interrogent la table StorageBlobLogs dans votre espace de travail.

Si vous souhaitez stocker vos journaux pour une requête en temps quasi réel et une rétention à long terme, configurez vos paramètres de diagnostic pour envoyer des journaux à la fois à un espace de travail Log Analytics et à un compte de stockage.

Si vous souhaitez accéder à vos journaux via un autre moteur de requête tel que Splunk, configurez vos paramètres de diagnostic pour envoyer des journaux à un hub d’événements et ingérer des journaux d’activité du hub d’événements vers votre destination choisie.

Vous pouvez activer les journaux stockage Azure dans Azure Monitor à l’aide du portail Azure, de PowerShell, d’Azure CLI et des modèles Azure Resource Manager. Pour les déploiements à grande échelle, utilisez Azure Policy avec prise en charge complète des tâches de correction. Pour plus d’informations, consultez ciphertxt/AzureStoragePolicy.

Voir aussi

• Stratégie de direction pour unifier vos données
• Modèle de contrôle d’accès dans Azure Data Lake Storage
• Guide de l’autostoppeur vers le lac de données
• Présentation d'Azure Data Lake Storage