Procedimientos recomendados para usar Azure Data Lake Storage

En este artículo se proporcionan directrices de procedimientos recomendados que le ayudarán a optimizar el rendimiento, reducir los costes y proteger su cuenta de Azure Storage habilitada para Data Lake Storage.

Localización de documentación

Azure Data Lake Storage no es un servicio dedicado ni un tipo de cuenta. Se trata de un conjunto de funcionalidades que admiten cargas de trabajo analíticas de alto rendimiento. La documentación de Data Lake Storage proporciona procedimientos recomendados e instrucciones para usar estas funcionalidades. Para ver todos los demás aspectos de la administración de cuentas, como la configuración de la seguridad de red, el diseño de alta disponibilidad y la recuperación ante desastres, consulte el contenido de la documentación de Blob Storage.

Evaluar la compatibilidad de las funciones y los problemas conocidos

Use el siguiente patrón a medida que configure la cuenta para usar las características de Blob Storage.

1. Revise el artículo Compatibilidad con la característica Blob Storage en cuentas de Azure Storage para determinar si una característica es totalmente compatible con su cuenta. Algunas características aún no se admiten o tienen compatibilidad parcial en las cuentas habilitadas para Data Lake Storage. La compatibilidad con características siempre se expande, así que asegúrese de revisar periódicamente este artículo para ver si hay actualizaciones.

2. Revise el artículo Problemas conocidos con Azure Data Lake Storage para ver si hay alguna limitación o guía especial sobre la característica que pretende usar.

3. Examine los artículos de características para obtener instrucciones específicas para las cuentas habilitadas para Data Lake Storage.

Información sobre los términos usados en la documentación

A medida que se mueve entre conjuntos de contenido, observa algunas pequeñas diferencias de terminología. Por ejemplo, el contenido incluido en la documentación de Blob Storage usa el término blob en lugar de archivo. Técnicamente, los archivos que ingiere en la cuenta de almacenamiento se convierten en blobs en su cuenta. Por lo tanto, el término es correcto. Sin embargo, el término blob puede causar confusión si está acostumbrado al término archivo. También verá el término contenedor usado para hacer referencia a un sistema de archivos. Puede considerar estos términos como sinónimos.

Considere la opción prémium

Si las cargas de trabajo requieren una latencia baja coherente o requieren un gran número de operaciones de salida de entrada por segundo (IOPS), considere la posibilidad de usar una cuenta de almacenamiento de blobs en bloques Premium. Este tipo de cuenta hace que los datos estén disponibles a través del hardware de alto rendimiento. Los datos se almacenan en unidades de estado sólido (SSD) que están optimizadas para baja latencia. Las SSD ofrecen mayor rendimiento en comparación con las unidades de disco duro tradicionales. Los costos de almacenamiento del rendimiento prémium son mayores, pero los costos de transacción son menores. Por lo tanto, si sus cargas de trabajo procesan una gran cantidad de transacciones, una cuenta premium de blobs en bloques puede resultar económica.

Si la cuenta de almacenamiento se va a usar para el análisis, se recomienda usar Azure Data Lake Storage junto con una cuenta de almacenamiento de blobs en bloques Premium. Esta combinación de uso de cuentas de almacenamiento de blobs en bloques prémium junto con una cuenta habilitada para Data Lake Storage se conoce como el nivel prémium para Azure Data Lake Storage.

Optimizar para la ingesta de datos

Al incorporar datos de un sistema de origen, el hardware del sistema de origen, el hardware de red de origen o la conectividad de red con su cuenta de almacenamiento pueden crear cuellos de botella.

Hardware de origen

Tanto si usa máquinas locales como máquinas virtuales (VM) en Azure, seleccione cuidadosamente el hardware adecuado. En el caso del hardware de disco, considere la posibilidad de usar unidades de estado sólido (SSD) y elegir hardware de disco que tenga ejes más rápidos. Para el hardware de red, use los controladores de interfaz de red (NIC) más rápidos posibles. En Azure, use máquinas virtuales Azure D14, que tienen el hardware de disco y de red con la potencia adecuada.

Conectividad de red con la cuenta almacenamiento

La conectividad de red entre tus datos de origen y tu cuenta de almacenamiento a veces puede crear un cuello de botella. Cuando los datos de origen sean locales, considere la posibilidad de usar un vínculo dedicado con Azure ExpressRoute. Si los datos de origen están en Azure, el rendimiento será el óptimo cuando los datos se encuentren en la misma región de Azure que la cuenta habilitada para Data Lake Storage.

Configuración de herramientas de ingesta de datos para lograr una paralelización máxima

Para obtener el mejor rendimiento, use todo el rendimiento disponible realizando tantas lecturas y escrituras en paralelo como sea posible.

En la tabla siguiente se resume la configuración básica de varias herramientas de ingesta populares.

Para obtener una lista más completa de las herramientas de ingesta, consulte Seleccionar herramientas de migración.

Su cuenta se puede escalar para ofrecer el rendimiento necesario para todos los escenarios de análisis. De manera predeterminada, una cuenta habilitada para Data Lake Storage proporciona el rendimiento suficiente en su configuración predeterminada para satisfacer las necesidades de una amplia variedad de casos de uso. Si alcanza el límite predeterminado, póngase en contacto con Soporte técnico de Azure para configurar su cuenta y obtener un mayor rendimiento.

Estructurar conjuntos de datos

Considere la posibilidad de planear previamente la estructura de los datos. El formato de archivo, el tamaño de archivo y la estructura de directorios pueden afectar al rendimiento y al coste.

Formatos de archivo

Puede ingerir datos en varios formatos. Los datos pueden aparecer en formatos legibles como JSON, CSV o XML, o como formatos binarios comprimidos, como .tar.gz. Los datos pueden tener varios tamaños. Los datos pueden estar compuestos por archivos de gran tamaño (unos pocos terabytes), como los datos de una exportación de una tabla SQL desde los sistemas locales. Los datos también pueden tener la forma de un gran número de archivos diminutos (unos pocos kilobytes), como los datos de eventos en tiempo real de una solución del Internet de las cosas (IoT). Puede optimizar la eficacia y los costes si elige un formato y un tamaño de archivo adecuados.

Hadoop admite un conjunto de formatos de archivo optimizados para almacenar y procesar datos estructurados. Algunos formatos comunes son Avro, Parquet y el formato columnar optimizado por filas (ORC). Todos estos formatos son formatos de archivo binario legibles por máquina. Se comprimen para ayudarle a administrar el tamaño del archivo. Tienen un esquema incrustado en cada archivo, lo que los hace autodescriptivos. La diferencia entre estos formatos radica en la forma en que se almacenan los datos. Avro almacena los datos en un formato basado en filas y los formatos Parquet y ORC almacenan los datos en formato de columnas.

Utilice el formato de archivo Avro cuando sus patrones de E/S estén más orientados a la escritura o cuando los patrones de consulta favorezcan la recuperación íntegra de varias filas de registros. Por ejemplo, el formato Avro funciona bien con un bus de mensajes como Event Hubs o Kafka que escriben varios eventos o mensajes en sucesión.

Utilice los formatos de archivo Parquet y ORC cuando los patrones de E/S sean más intensivos en lectura o cuando los patrones de consulta se centren en un subconjunto de columnas de los registros. Las transacciones de lectura pueden optimizarse para recuperar columnas específicas en lugar de leer todo el registro.

Apache Parquet es un formato de archivo de código abierto optimizado para canalizaciones de análisis de lectura intensiva. La estructura de almacenamiento en columnas de Parquet permite omitir los datos no relevantes. Las consultas son mucho más eficaces porque pueden limitar el ámbito de los datos que se van a enviar desde el almacenamiento hasta el motor de análisis. Además, dado que los tipos de datos similares (para una columna) se almacenan juntos, Parquet admite esquemas de codificación y compresión de datos eficaces que pueden reducir los costos de almacenamiento de datos. Los servicios como Azure Synapse Analytics, Azure Databricks y Azure Data Factory tienen funcionalidad nativa que aprovechan los formatos de archivo Parquet.

Tamaño de archivo

Los archivos de mayor tamaño permiten mejorar el rendimiento y reducir los costes.

Normalmente, los motores de análisis como HDInsight tienen una sobrecarga por archivo que implica tareas como enumerar, comprobar el acceso y realizar varias operaciones de metadatos. Si almacena sus datos en muchos archivos pequeños, esta elección puede afectar negativamente al rendimiento. En general, organice los datos en archivos de mayor tamaño para mejorar el rendimiento (tamaño de 256 MB a 100 GB). Algunos motores y aplicaciones podrían tener problemas para procesar eficazmente los archivos que tienen un tamaño superior a 100 GB.

Aumentar el tamaño del archivo también puede reducir los costes de las transacciones. Las operaciones de lectura y escritura se facturan en incrementos de 4 megabytes, por lo que se le cobra por la operación si el archivo contiene 4 megabytes o solo unos kilobytes. Para obtener información sobre precios, consulte Azure Data Lake Storage pricing (Precios de Azure Data Lake Storage).

A veces, las canalizaciones de datos ejercen un control limitado sobre los datos sin procesar, que tienen una gran cantidad de archivos pequeños. En general, el sistema debe tener algún tipo de proceso para agregar archivos pequeños en archivos más grandes para su uso por parte de las aplicaciones de bajada. Si está procesando datos en tiempo real, puede usar un motor de streaming en tiempo real (como Azure Stream Analytics o Spark Streaming) junto con un agente de mensajes (como Event Hubs o Apache Kafka) para almacenar los datos como archivos más grandes. A medida que agrega archivos pequeños en archivos más grandes, considere la posibilidad de guardarlos en un formato optimizado para lectura, como Apache Parquet, para procesarlos en dirección descendente.

Estructura de directorios

Cada carga de trabajo tiene requisitos diferentes para cómo consume los datos. Sin embargo, al trabajar con Internet de las cosas (IoT), escenarios por lotes o al optimizar los datos de serie temporal, tenga en cuenta estos diseños comunes.

Estructura de IoT

En las cargas de trabajo de IoT, puede ingerir una gran cantidad de datos que abarque numerosos productos, dispositivos, organizaciones y clientes. Preplane el diseño del directorio para la organización, la seguridad y el procesamiento eficaz de los datos para los consumidores de flujos descendentes. Una plantilla general a tener en cuenta podría tener el siguiente diseño:

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

Por ejemplo, la telemetría de aterrizaje de un motor de un avión del Reino Unido podría ser parecida a la estructura siguiente:

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

En este ejemplo, al colocar la fecha al final de la estructura de directorios, puede usar ACL para proteger más fácilmente regiones y asuntos para usuarios y grupos específicos. Si coloca la estructura de fecha al principio, resultará mucho más difícil proteger estas regiones y estos asuntos. Por ejemplo, si quisieras proporcionar acceso solo a los datos del Reino Unido o a determinados planes, tendrías que aplicar un permiso independiente para numerosos directorios dentro de cada directorio horario. Esta estructura también aumentaría exponencialmente el número de directorios con el paso del tiempo.

Estructura de trabajos por lotes

Un enfoque que se usa habitualmente en el procesamiento por lotes es colocar los datos en un directorio "in". Posteriormente, una vez procesados los datos, coloque los nuevos datos en un directorio "out" para que los consuman los procesos de nivel inferior. Esta estructura de directorios se usa a veces con trabajos que requieren el procesamiento de archivos individuales, pero puede que no requieran un procesamiento paralelo masivo con grandes conjuntos de datos. Al igual que en la estructura de IoT que se recomienda anteriormente, una estructura adecuada cuenta con directorios de nivel primario para elementos como regiones o asuntos (por ejemplo, organización, producto o productor). Considere la posibilidad de usar la fecha y la hora en la estructura para permitir una mejor organización, búsquedas filtradas, seguridad y automatización del procesamiento. El nivel de granularidad de la estructura de fecha viene determinado por el intervalo en el que los datos se cargan o procesan como, por ejemplo, cada hora, cada día o incluso mensualmente.

En algunas ocasiones, el procesamiento de archivos es incorrecto debido a datos dañados o a formatos imprevistos. En tales casos, podría resultar útil que la estructura de directorios tuviera una carpeta /bad a la que mover los archivos para inspeccionarlos más a fondo. El proceso por lotes también puede encargarse de la generación de informes o de la notificación de estos archivos defectuosos para su intervención manual. Tenga en cuenta la siguiente estructura de plantilla:

• {Region}/{SubjectMatter(s)}/In/{aaaa}/{mm}/{dd}/{hh}/
• {Región}/{Asunto(s)}/Salida/{aaaa}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/

Por ejemplo, una empresa de marketing recibe a diario extractos de datos de actualizaciones de los clientes de Norteamérica. Podría tener el aspecto del siguiente fragmento de código antes y después del procesamiento:

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

En el caso común de los datos por lotes que se procesan directamente en bases de datos como Hive o bases de datos SQL tradicionales, no es necesario un directorio de entrada o salida porque la salida ya entra en una carpeta independiente para la tabla de Hive o la base de datos externa. Por ejemplo, las extracciones diarias procedentes de los clientes se depositan en sus respectivos directorios. A continuación, un servicio como Azure Data Factory, Apache Oozie o Apache Airflow desencadena un trabajo diario de Hive o Spark para procesar y escribir los datos en una tabla de Hive.

Estructura de datos de series temporales

En las cargas de trabajo de Hive, la eliminación de las particiones de los datos de serie temporal puede ayudar a algunas consultas a leer solo un subconjunto de los datos, lo que mejora el rendimiento.

Esas canalizaciones que ingieren datos de serie temporal suelen colocar sus archivos con una nomenclatura estructurada para archivos y carpetas. A continuación se muestra un ejemplo común para los datos estructurados por fecha:

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

Observe que la información de fecha y hora aparece tanto en las carpetas como en el nombre de archivo.

Para la fecha y la hora, el siguiente es un patrón común

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

De nuevo, su elección de organización de los archivos y carpetas debería ser la que consiga un tamaño de archivo mayor y un número razonable de archivos en cada carpeta.

Configuración de la seguridad

Empiece por revisar las recomendaciones del artículo Recomendaciones de seguridad para Blob Storage. Encontrará instrucciones de procedimientos recomendados sobre cómo proteger los datos frente a la eliminación accidental o malintencionada, proteger los datos detrás de un firewall y usar Microsoft Entra ID como base de la administración de identidades.

A continuación, revise el artículo Modelo de control de acceso de Azure Data Lake Storage para obtener instrucciones específicas de las cuentas habilitadas para Data Lake Storage. Este artículo le ayuda a comprender cómo usar los roles de control de acceso basado en roles de Azure (Azure RBAC) junto con listas de control de acceso (ACL) para hacer cumplir los permisos de seguridad en directorios y archivos de su sistema de archivos jerárquico.

Ingesta, proceso y análisis

Puede ingerir datos en una cuenta habilitada Data Lake Storage de muchos orígenes diferentes y de muchas maneras diferentes.

Por ejemplo, puede ingerir grandes conjuntos de datos de clústeres de HDInsight y Hadoop o de conjuntos más pequeños de datos ad hoc para la creación de prototipos de aplicaciones. Puede incorporar datos en streaming generados por varias fuentes, como aplicaciones, dispositivos y sensores. Para este tipo de datos, use herramientas para capturar y procesar los datos en tiempo real y, a continuación, escribir los eventos en lotes en su cuenta. También puede ingerir registros de servidor web que contengan información como el historial de solicitudes de página. En el caso de los datos de registro, considere la posibilidad de escribir scripts personalizados o aplicaciones para cargarlos para que tenga la flexibilidad de incluir el componente de carga de datos como parte de la aplicación de macrodatos más grande.

Una vez que los datos están disponibles en la cuenta, puede ejecutar análisis sobre esos datos, crear visualizaciones e incluso descargar datos a su máquina local o a otros repositorios, como una base de datos de Azure SQL o una instancia de SQL Server.

En la tabla siguiente se recomiendan herramientas que puede usar para ingerir, analizar, visualizar y descargar datos. Use los vínculos de esta tabla para buscar instrucciones sobre cómo configurar y usar cada herramienta.

Supervisión de la telemetría

La supervisión del uso y el rendimiento del servicio es una parte importante de la operacionalización del servicio. Entre los ejemplos de telemetría se incluyen operaciones frecuentes, operaciones con alta latencia u operaciones que provocan limitación por parte del servicio.

Puede acceder a todos los datos de telemetría de la cuenta de almacenamiento a través de los registros de Azure Storage en Azure Monitor. Esta característica integra la cuenta de almacenamiento con Log Analytics y Event Hubs, al tiempo que permite archivar los registros en otra cuenta de almacenamiento. Para ver la lista completa de métricas y registros de recursos y su esquema asociado, consulte Azure Storage referencia de datos de supervisión.

El lugar en el que decida almacenar los registros dependerá de cómo piense acceder a ellos. Por ejemplo, si desea acceder a los registros casi en tiempo real y poder correlacionar eventos en registros con otras métricas de Azure Monitor, almacene los registros en un área de trabajo de Log Analytics. Después, consulta los registros mediante KQL y crea consultas que enumeran la tabla StorageBlobLogs en el área de trabajo.

Si desea almacenar los registros tanto para consultas casi en tiempo real como para la retención a largo plazo, configure la configuración de diagnóstico para enviar registros tanto a un área de trabajo de Log Analytics como a una cuenta de almacenamiento.

Si desea acceder a los registros a través de otro motor de consultas, como Splunk, configure las opciones de diagnóstico para enviar registros a un centro de eventos e ingerir registros desde el centro de eventos al destino elegido.

Puede habilitar los registros de Azure Storage en Azure Monitor a través del portal de Azure, PowerShell, las plantillas de CLI de Azure y Azure Resource Manager. Para las implementaciones a escala, use Azure Policy con compatibilidad completa con tareas de corrección. Para más información, consulte ciphertxt/AzureStoragePolicy.

Consulte también

• Estrategia ejecutiva para unificar los datos
• Modelo de control de acceso de Azure Data Lake Storage
• Guía del autoestopista para el Data Lake
• Información general de Azure Data Lake Store