Información sobre la estructura y los formatos de archivo de un almacenamiento de datos moderno
Al cargar datos en el almacenamiento de datos, los tipos de archivo y los métodos para ingerir los datos varían según el origen. Por ejemplo, la carga de datos desde sistemas de archivos locales, almacenes de datos relacionales u orígenes de datos de streaming requiere enfoques diferentes, desde la ingesta en el lago de datos o en el almacén de datos intermedio, hasta el aterrizaje de datos depurados en la capa de servicio. Es importante conocer los distintos tipos de archivo y cuáles usar para el almacenamiento sin formato frente a las versiones refinadas para las consultas analíticas. Otras consideraciones de diseño incluyen estructuras jerárquicas para optimizar las consultas y las actividades de carga de datos. En esta unidad se describen los tipos de archivo y sus casos de uso óptimos, y cómo organizarlos mejor en el lago de datos.
Formatos de archivo compatibles con la ingesta de datos sin procesar en lotes
En la ingeniería de datos, se tiende a describir la velocidad de carga de datos como una de las tres latencias:
- Lote: consultas o programas que tardan decenas de minutos, horas o días en completarse. Las actividades pueden incluir la limpieza y transformación de datos, la canalización de ETL completa o la preparación para análisis de bajada.
- Consulta interactiva: la consulta de datos por lotes a velocidades interactivas "humanas", lo que, con la generación actual de tecnologías, significa que los resultados están listos en períodos de tiempo medidos en segundos o minutos.
- En tiempo real/casi en tiempo real: procesamiento de un flujo de datos de entrada (flujo) normalmente infinito, cuyo tiempo hasta que los resultados están listos es corto, medido en milisegundos o segundos en la mayoría de los casos.
En lo que respecta a la ingesta de datos sin procesar en lotes desde nuevos orígenes de datos, Synapse admite estos formatos de datos de forma nativa:
- CSV
- Parquet
- ORC
- JSON
Sin embargo, si usa Apache Spark con los cuadernos de Synapse, puede explorar y procesar más tipos de archivos para sus datos sin procesar.
Ingesta de datos de streaming en grupos de SQL dedicados de Synapse
El procesamiento de los datos que alcanza la tercera latencia (en tiempo real o casi en tiempo real) también se conoce como procesamiento de datos de streaming. Los orígenes de datos de streaming pueden incluir dispositivos y sensores de IoT, transacciones financieras, información de la secuencia de clic, fábricas y dispositivos médicos, entre otros.
Azure ofrece servicios de ingesta de flujos diseñados específicamente, como Azure IoT Hub y Azure Event Hubs, (con o sin compatibilidad con Kafka) que son sólidos, probados y eficaces. En la canalización de datos, debe recopilar mensajes de estos servicios o afines y procesarlos mediante Azure Stream Analytics, Azure Functions, Azure Databricks u otros servicios que le permitan ingerir y procesar datos de streaming.
El objetivo puede ser llevar estos datos al lago de datos, como la cuenta de Azure Data Lake Storage (ADLS) Gen2 asociada al área de trabajo de Synapse Analytics y, a continuación, usar cuadernos de Synapse Spark o consultas T-SQL con un grupo de SQL sin servidor para explorar y transformar los datos. En este caso, lo más probable es que guarde esos datos en uno de los formatos sin procesar, como CSV o JSON. Azure Stream Analytics simplifica esta tarea mediante la conexión a IoT Hub o Event Hubs como un origen de entrada y la salida de archivos a la cuenta de almacenamiento de ADLS Gen2 como salida. Puede especificar un patrón de ruta de acceso que le ayude a estructurar los datos para cargas de trabajo analíticas óptimas mediante la eliminación de datos basada en rutas de acceso. Por ejemplo, puede establecer el siguiente patrón de ruta de acceso en la salida de ADLS Gen2: tran/sensor/{datetime:yyyy}/{datetime:MM}/{datetime:dd}. Otras opciones permiten establecer la serialización, como JSON; la codificación, como UTF-8; el número mínimo de filas por archivo, como 100; etc.
Sin embargo, si desea obtener los datos de streaming en un grupo de SQL dedicado, un par de opciones que puede aplicar es procesar y almacenar primero los datos en el lago de datos, como se describió anteriormente. A continuación, cargue los datos en un grupo de SQL dedicado mediante una de las diversas técnicas de carga de datos, como canalizaciones de Synapse, grupos de Synapse Spark o instrucciones COPY. Esto le permite usar el lago de datos como un área de almacenamiento provisional o mantener el formato sin procesar en el lago de datos además de una versión más refinada de los datos en el grupo de SQL dedicado.
Otra opción es usar Azure Stream Analytics con una instancia de Azure Synapse Analytics (grupo de SQL dedicado) como un receptor de salida para la ingesta de datos de alto rendimiento con trabajos de Azure Stream Analytics.
Una vez creada la salida de Synapse Analytics, puede establecerla como destino en la consulta de Stream Analytics. En el ejemplo siguiente, tenemos una entrada de Event Hubs llamada CallStream, y una salida de Synapse Analytics llamada sqlpool-demo-asaoutput. La consulta SQL simplemente escribe todos los datos entrantes directamente en el grupo de SQL dedicado. Como alternativa, puede seleccionar solo propiedades específicas y transformar los tipos de datos del flujo entrante y usar una de las funciones de ventana para agregar datos antes de escribirlos en el grupo de SQL dedicado.
Usar Stream Analytics con Synapse Analytics de esta manera permite seleccionar la base de datos y la tabla del grupo de SQL dedicado donde la consulta de Stream Analytics escribirá los datos de streaming. Esta ingesta de flujos nativos está optimizada para escribir rápidamente los datos directamente en el grupo de SQL dedicado sin tener que llevar primero los datos a otro lugar.
Tipos de archivo recomendados
Datos sin procesar
En el caso de los datos sin procesar, se recomienda almacenar los datos en su formato nativo. Normalmente, los datos de las bases de datos relacionales deben almacenarse en formato CSV. Este es el formato admitido por la mayoría de los sistemas, por lo que proporciona la máxima flexibilidad.
Para los datos de las API web y las bases de datos NoSQL, JSON es el formato recomendado.
Versiones refinadas para datos
Cuando se trata de almacenar versiones refinadas de los datos para posibles consultas, el formato de datos recomendado es Parquet.
Hay una alineación del sector en torno al formato Parquet para compartir datos en la capa de almacenamiento (por ejemplo, en escenarios de Hadoop, de Databricks y del motor de SQL). Parquet es un formato orientado a columnas de alto rendimiento optimizado para escenarios de macrodatos.
Los formatos en columnas, como Parquet, tienen ventajas de almacenamiento y rendimiento. Los valores se agrupan por columna, por lo que la compresión es más eficaz (para reducir la superficie de almacenamiento), y un motor de consultas puede desactivar las proyecciones de columna (para reducir la E/S de lectura de la red y el disco omitiendo las columnas no deseadas), lo que también se conoce como eliminación de columnas. Los tipos de datos similares (para una columna) se almacenan juntos en archivos Parquet, lo que conduce a esquemas de codificación y compresión de datos eficaces.
Parquet almacena el esquema de archivos en los metadatos del archivo. Los archivos CSV no almacenan metadatos de archivo, por lo que hay que proporcionar el esquema a los lectores, o bien hay que inferir el esquema. Proporcionar un esquema es tedioso e inducir un esquema es propenso a errores o caro.
Organización de la estructura de archivos para consultas analíticas
Lo primero que debe tener en cuenta al ingerir datos en el lago de datos es cómo estructurar u organizar los datos dentro del lago de datos. Debe usar Azure Data Lake Storage (ADLS) Gen2 (dentro de Azure Portal, se trata de una cuenta de Azure Storage con un espacio de nombres jerárquico habilitado).
Un mecanismo clave que permite a ADLS Gen2 ofrecer rendimiento para el sistema de archivos a precios y escala de almacenamiento de objetos, aparte de un espacio de nombres jerárquico. Esto permite que la colección de objetos o archivos dentro de una cuenta esté organizada en una jerarquía de directorios y subdirectorios anidados de la misma manera en que se organiza el sistema de archivos en el equipo. Con un espacio de nombres jerárquico habilitado, una cuenta de almacenamiento es capaz de proporcionar la escalabilidad y la rentabilidad del almacenamiento de objetos, con una semántica de sistema de archivos con la que los marcos y motores de análisis están familiarizados.
En ADLS Gen2, es un procedimiento recomendado tener una cuenta de almacenamiento dedicada para producción y una cuenta de almacenamiento independiente para cargas de trabajo de desarrollo y pruebas. Esto garantizará que las cargas de trabajo de desarrollo o pruebas nunca interfieran con producción.
Un método común para estructurar carpetas dentro de un lago de datos es organizar los datos en carpetas independientes según el grado de perfeccionamiento. Por ejemplo, una carpeta bronze puede contener datos sin procesar, silver contiene los datos limpios, preparados e integrados, y gold contiene datos listos para admitir análisis, que pueden incluir mejoras finales, como agregados calculados previamente. Si se requieren más niveles de perfeccionamiento, esta estructura se puede modificar, según sea necesario, para incluir más carpetas.
Al trabajar con Data Lake Storage Gen2, se debe tener en cuenta lo siguiente:
- Cuando los datos se almacenan en Data Lake Storage Gen2, el tamaño de los archivos, su número y la estructura de carpetas afectan al rendimiento.
- Si los datos se almacenan en muchos archivos pequeños, puede afectar desfavorablemente 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.
- A veces, las canalizaciones de datos ejercen un control limitado sobre los datos sin procesar, que tienen una gran cantidad de archivos pequeños. Se recomienda disponer de un proceso de "cocinado" que genere archivos de mayor tamaño para usarlos en las aplicaciones de bajada.