Cómo elegir un formato de Archivo para Gestión de Datos en Hadoop

Es fácil ser abrumado cuando llega el momento de elegir un formato de Archivos; el escenario es que acaba de construir y configurar su nuevo Hadoop Cluster. Pero ahora debe averiguar cómo cargar sus datos. 

Ahora debe averiguar cómo cargar sus datos. ¿Debería guardar sus datos como texto, o debería intentar utilizar Avro o Parquet? Honestamente, la respuesta correcta a menudo depende de sus datos. Sin embargo, voy a brindar un marco para abordar esta elección, y proporcionar algunos ejemplos de casos de uso.

Existen diferentes formatos de datos disponibles para su uso en el sistema de archivos distribuidos Hadoop (HDFS), y su elección puede impactar mucho su proyecto en términos de requisitos de espacio y rendimiento. 

Los resultados que aquí se presentan se basan en las experiencias de varios equipos, así como en pruebas que comparan los archivos guardados en formatos diversos como texto, Apache Avro, Apache Parquet y Optimized Row Columnar (ORC).

¿Cómo empezar?

Hay varias consideraciones que deben tenerse en cuenta al intentar determinar qué formato de datos debe utilizar en su proyecto; aquí, discutimos los más importantes que encontrarás: especificaciones del sistema, características de los datos y escenarios de casos de uso.

Especificaciones del Sistema

Empiece por ver las tecnologías que ha elegido utilizar y sus características; esto incluye las herramientas utilizadas para los procesos ETL (Extract, Transform and Load) así como las herramientas utilizadas para consultar y analizar los datos. Esta información le ayudará a determinar el formato que puede o no utilizar por compatibilidad, por ejemplo.

Un ítem importante es que no todas las herramientas admiten todos los formatos de datos y la escritura de analizadores de datos y convertidores adicionales agregará complejidad no deseada al proyecto. Por ejemplo, al momento de escribir este post Impala soporta estructuras complejas en parquet por lo tanto, si usted está planeando en la ejecución de la mayoría de sus consultas en Impala, entonces puede aprovechar esta configuración sobre Parquet.

También debe considerar la realidad de su sistema. ¿Está limitado el almacenamiento o la memoria? Algunos formatos de datos pueden comprimir más que otros. Por ejemplo, los conjuntos de datos almacenados como Parquet y ORC con compresión rápida pueden reducir su tamaño a un cuarto del tamaño de su contraparte de formato de texto sin comprimir, y Avro con compresión DEFFLATED o SNNAPY puede lograr resultados similares. Sin embargo, escribir en cualquiera de estos formatos requerirá más memoria, y quizás tenga que ajustar la configuración del sistema. Asimismo debemos considerar las configuraciones entre los formatos de Archivos y los códecs de compresión que queremos utilizar de modo que lleguemos a obtener un equilibrio entre consumo de almacenamiento, flexibilidad del formato, y performance de consultas.

Es deseable ejecutar algunas pruebas en su sistema antes de comprometerse plenamente a usar un formato. 

Características y tamaño de los datos

La siguiente consideración es alrededor de los datos que desea procesar y almacenar en su sistema. Veamos algunos de los aspectos que pueden afectar el rendimiento en un formato de datos.

¿Cómo se estructuran sus datos aun sin procesar (antes de Hadoop)?

Tal vez usted sus datos etsan en un formato de texto regular o archivos csv y está pensando en almacenarlos como tal. Mientras que los archivos de texto son legibles por los seres humanos, fácil de resolver y fácil de procesar, afectan directamente el rendimiento del sistema, ya que tienen que ser analizados cada vez. Los archivos de texto también tienen un formato implícito (cada columna es un valor determinado) y si no está documentando esto con cuidado, puede causar problemas en la línea.

Otra consideración es que si sus datos están en un formato xml y json, entonces podría encontrar algunos problemas con la capacidad de división de archivos en HDFS. Splitability determina la capacidad de procesar partes de un archivo de forma independiente que a su vez permite el procesamiento paralelo en Hadoop, por lo tanto, si sus datos no son dividibles perdemos capacidades de paralelismo que permite consultas rápidas. Los formatos de datos más avanzados (Avro, Parquet, ORC) ofrecen división independientemente del códec de compresión.

¿Qué aspecto tiene su pipeline(tubería) y qué pasos hay?

Algunos de los formatos de archivo se han optimizado para trabajar en determinadas situaciones. Por ejemplo, los archivos secuencias(sequencefile) se diseñaron para compartir fácilmente los datos entre los trabajos de reducción de MapReduce (MR), por lo que si su tuberia implica trabajos de MR, los archivos de secuencia constituyen una excelente opción. En el mismo sentido, los formatos de datos en columnas, tales como Parquet y ORC, fueron diseñados para optimizar los tiempos de consulta; si la etapa final de su pipeline necesita ser optimizada, usar un formato de archivo columnar aumentará velocidad mientras que consulta datos.

¿Cuántas columnas se están almacenando y cuántas columnas se utilizan para el análisis?

Los formatos de datos columnares como Parquet y ORC ofrecen una ventaja (en términos de velocidad de consulta) cuando se tienen muchas columnas pero solo se necesitan algunas de esas columnas para su análisis ya que Parquet y ORC aumentan la velocidad a la que se realizan las consultas. Sin embargo, esa ventaja se puede perder si todavía necesita todas las columnas durante la búsqueda, en cuyo caso podría experimentar dentro de su sistema para encontrar la alternativa más rápida. Otra ventaja de los archivos columnares es la forma en que comprimen los datos, lo que ahorra espacio y tiempo.

¿Sus datos cambian con el tiempo? Si lo hace, ¿con qué frecuencia sucede y cómo cambia?

Saber si sus datos cambian a menudo es importante porque entonces tenemos que considerar cómo un formato de datos maneja la evolución del esquema. La evolución del esquema es el término usado para denotar cuando la estructura de un archivo ha cambiado después de haber sido previamente almacenada con una estructura diferente, tales cambios en la estructura pueden incluir el cambio de tipo de datos para una columna, la adición de columnas y la eliminación de columnas. Los archivos de texto no almacenan explícitamente el esquema, por lo que cuando una nueva persona se une al proyecto, depende de ellos para determinar qué columnas y valores de columna tienen los datos. Si los datos cambian repentinamente (adición de columnas, eliminación de columnas, cambios en los tipos de datos), es necesario diseñar un proceso para reconciliar datos antiguos y nuevos datos con el formato.

Ciertos formatos de archivo manejan la evolución del esquema de forma mas transparente que otros. Por ejemplo, Parquet sólo permite la adición de nuevas columnas al final de las columnas y no controla la supresión de columnas, mientras que Avro permite la adición, eliminación y cambio de nombre de varias columnas. Si usted sabe que sus datos están obligados a cambiar a menudo (tal vez los desarrolladores o aplicaciones origen añadir nuevos ocnceptos cada cierto tiempo (unos pocos meses), Avro será una buena opción. Si sus datos no cambian con frecuencia o no cambian, la evolución del esquema no es necesaria(aquí recalco la necesidad).

Las cosas adicionales a tener en cuenta con la evolución del esquema son las compensaciones de seguir o no la pista de los esquemas más nuevos. Si el esquema para un formato de datos como Avro o Parquet necesita ser especificado (en lugar de extraído de los datos), entonces requeriremos esfuerzo adicional para almacenar y crear los archivos de esquema.

Escenarios de casos de uso

Cada uno de los formatos de datos tiene sus propias fortalezas, debilidades y compensaciones, por lo que la decisión sobre el formato de uso debe basarse en sus casos y sistemas de uso específicos.

Si su objetivo principal es poder escribir datos lo más rápido posible y no tiene ninguna preocupación por el espacio, entonces puede ser aceptable sólo almacenar sus datos en formato de texto asumiendo también la consecuencia de que los tiempos de consulta para grandes conjuntos de datos serán más largos.

Si su principal preocupación es ser capaz de manejar la evolución de los datos en su sistema, entonces usted puede confiar en Avro para guardar esquemas. Tenga en cuenta, sin embargo, que al escribir archivos en el sistema Avro requiere un esquema pre-diseñado, que podría implicar algún procesamiento adicional al principio.

Por último, si su caso de uso principal es el análisis de los datos y desea optimizar el rendimiento de las consultas, es posible que desee echar un vistazo a un formato columnar como Parquet o ORC, ya que ofrecen el mejor rendimiento en las consultas, particularmente para búsquedas parciales en las que solo está leyendo columnas específicas. Sin embargo, la ventaja de velocidad podría disminuir si está leyendo todas las columnas.

Hay un patrón en los casos de uso mencionados: si un archivo tarda más en escribir, es porque se ha optimizado para aumentar la velocidad durante lecturas, asimismo se puede diseñar el pipeline con una combinación de los mismos.

Estoy preparando el código para realizar pruebas en un cluster de forma reproducible y asi puedan obtener sus propias conclusiones

Buen Fin de Semana.