{"id":13468,"date":"2020-05-25T13:31:10","date_gmt":"2020-05-25T11:31:10","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=13468"},"modified":"2023-12-14T23:02:42","modified_gmt":"2023-12-14T22:02:42","slug":"mas-alla-de-pandas-y-apache-spark-para-la-manipulacion-de-datos-apache-arrow-y-gpu","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/mas-alla-de-pandas-y-apache-spark-para-la-manipulacion-de-datos-apache-arrow-y-gpu\/","title":{"rendered":"M\u00e1s all\u00e1 de Pandas y Apache Spark para la manipulaci\u00f3n de datos: Apache Arrow y GPU"},"content":{"rendered":"

Cuando nos enfrentamos a problemas de escalabilidad usualmente se piensa en cl\u00fasteres que permiten alcanzar distribuciones horizontales de carga y garant\u00edas de disponibilidad. Por ello, si venimos de usar Pandas<\/strong> y pasamos a Apache Spark<\/strong>, creemos que todos nuestros problemas han sido resueltos. Sin embargo, si definimos a la escalabilidad como la habilidad de un sistema para soportar carga creciente (Kleppmann, 2017, p\u00e1gs. 10, 11), podemos ver que existen diversas maneras alcanzar esta propiedad sin recurrir a entornos necesariamente distribuidos.<\/p>\n

Por esta raz\u00f3n, conviene pensar en las caracter\u00edsticas espec\u00edficas del problema al que nos enfrentamos, los cuellos de botella<\/strong> que lo afligen, y su estructura de programa.<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 1: USANDO C\u00d3MPUTOS ACELERADOS POR EL GPU EN TODO EL FLUJO DE TRABAJO CON FORMATOS DE DATOS INTERPOPERADOS POR ARROW (FUENTE: HTTPS:\/\/GITHUB.COM\/RAPIDSAI\/CUDF)<\/p><\/div>\n

 <\/p>\n

Tomemos como ejemplo a Pandas. Wes McKinney, el autor de Pandas y coautor de Apache Arrow,<\/strong> afirm\u00f3 en un art\u00edculo publicado el 21 de septiembre de 2017 que los principales problemas de Pandas<\/strong> para la \u00e9poca eran el rendimiento pobre durante la ingesta y exportaci\u00f3n de datos<\/strong> provenientes de bases de datos y archivos, el soporte lento y limitado de algoritmos multin\u00facleo o paralelos, <\/strong>la falta de conjuntos de datos basados en mapas de memoria, entre otros.<\/p>\n

Este art\u00edculo, adem\u00e1s, resulta interesante en t\u00e9rminos hist\u00f3ricos pues describe brevemente cu\u00e1n dif\u00edcil resultaba analizar datos con Python antes de que \u00e9l empezara a trabajar con Pandas.<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 2: Wes McKinney, el creador de Pandas y de Arrow (fuente: https:\/\/wesmckinney.com\/)<\/p><\/div>\n

 <\/p>\n

A\u00f1os despu\u00e9s de haber creado a Pandas, luego de haber interactuado con proyectos como Apache Kudu, Apache Spark, Apache Impala<\/strong> y otros, todos com\u00fanmente usados por ingenieros de datos, McKinney reconoci\u00f3 que estas herramientas eran afligidas por problemas similares y que se necesitaba un lugar com\u00fan para empezar a resolverlos.<\/p>\n

Por ello, en 2015 \u00e9l decidi\u00f3 empezar a dise\u00f1ar y especificar lo que luego se convertir\u00eda en Apache Arrow<\/strong><\/a>: un est\u00e1ndar que permite unificar herramientas com\u00fanmente asociadas con dataframes<\/strong> y resolver sus problemas sin duplicar esfuerzos. (McKinney, 2020)<\/p>\n

\u00bfQu\u00e9 es Apache Arrow<\/strong>?<\/h2>\n

Ahora bien, \u00bfqu\u00e9 es Apache Arrow<\/strong>? \u00c9sta es una plataforma pensada para aplicaciones anal\u00edticas de Big Data que necesitan procesar y mover datos entre s\u00ed r\u00e1pidamente. Para lograr esto, el est\u00e1ndar de Arrow define un formato de datos orientado a columnas<\/strong> que se caracteriza por la adyacencia de datos secuenciales<\/strong>, el acceso aleatorio en tiempo constante<\/strong>, el patr\u00f3n de programa Single Instruction Multiple Data<\/em><\/strong> y la relocalizaci\u00f3n de datos con punteros sin uso de copias<\/strong>. Todo esto al final se traduce en tiempos m\u00e1s r\u00e1pidos de ingesta, manipulaci\u00f3n, transformaci\u00f3n y exportaci\u00f3n de datos. (Apache Arrow Documentation, 2020)<\/p>\n

Sin embargo, tal vez la mayor ventaja de Apache Arrow no sea su capacidad de mejorar el rendimiento de herramientas ya existentes, sino su capacidad pr\u00e1ctica de unificar el ecosistema de ciencias de datos<\/strong>. Esto se debe a la gran popularidad de diversas implementaciones del modelo de datos basado en tablas o dataframes. \u00c9sta es una estructura de datos muy com\u00fan y se pueden encontrar implementaciones en m\u00faltiples languajes como Python, Scala y R, as\u00ed como en m\u00faltiples herramientas como Apache Spark, Pandas<\/strong> y Dask<\/strong>.<\/p>\n

En general, si bien los dataframes representan el mismo tipo de datos, sus implementaciones pueden variar sobremanera. Es por esto que la conversi\u00f3n de datos entre un formato y el otro requiere la creaci\u00f3n de una herramienta espec\u00edfica y las m\u00e1s de las veces esto implica un proceso de copia y conversi\u00f3n<\/strong> (Ilustraci\u00f3n 3) que en total se caracteriza por una complejidad lineal sobre los datos.<\/p>\n

Sin embargo, si todos estas implementaciones siguieran el mismo formato a bajo nivel, ser\u00eda posible simplemente mover apuntadores<\/strong> para poder pasar entre un formato y otro (Ilustraci\u00f3n 4). En efecto, esto es lo que hace precisamente Apache Arrow. (Sitio Web de Apache Arrow, 2020)<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 3: antes de Arrow, un m\u00e9todo que copia y convierte ha de hacerse por cada par de formatos basados en columnas (fuente: https:\/\/arrow.apache.org\/)<\/p><\/div>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 4: con Arrow, cada formato basado en columnas s\u00f3lo ha de seguir el est\u00e1ndar de Arrow (fuente: https:\/\/arrow.apache.org\/)<\/p><\/div>\n

 <\/p>\n

Si bien Apache Arrow ayuda sobremanera a mitigar el problema del bajo rendimiento durante la ingesta y exportaci\u00f3n de datos, as\u00ed como a mejorar la interoperabilidad<\/strong> entre distintos proyectos, a\u00fan se puede mejorar mucho desde el punto de vista de la concurrencia y paralelizaci\u00f3n de operaciones. Por esta raz\u00f3n, nace el proyecto cuDF<\/strong>, de RAPIDS (Ilustraci\u00f3n 5).<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 5: relaci\u00f3n entre los componentes del ecosistema de RAPIDS (fuente: https:\/\/github.com\/BlazingDB\/blazingsql)<\/p><\/div>\n

 <\/p>\n

Qu\u00e9 es\u00a0RAPIDS<\/h2>\n

En efecto, RAPIDS<\/a> es una organizaci\u00f3n que ofrece un conjunto de herramientas de c\u00f3digo abierto que permiten ejecutar proyectos de ciencias de datos y anal\u00edtica usando GPU<\/strong> de principio a fin teniendo como base a CUDA<\/strong> y tambi\u00e9n da soporte a despliegues distribuidos con m\u00faltiples GPU. (RAPIDS, 2020)<\/p>\n

Por su parte, cuDF<\/strong> es la principal implementaci\u00f3n de un dataframe basado en Apache Arrow<\/strong> y adaptado completamente para ejecutar operaciones de carga, uni\u00f3n, agregaci\u00f3n, filtrado y manipulaci\u00f3n de datos usando siempre GPU. Como es un dataframe, la principal ventaja que ofrece cuDF es un API bien conocido por los usuarios<\/strong> de herramientas como Apache Spark y Pandas mientras ofrece operaciones aceleradas por GPU<\/strong>. Es decir, es la combinaci\u00f3n perfecta entre Pandas y CUDA<\/strong>, sin las limitaciones del primero y sin los detalles de bajo nivel del segundo. (RAPIDS, cuDF GitHub Repository, 2020)<\/p>\n

Si bien Apache Arrow les permite a los dataframes basados en memoria principal el poder interoperar, tambi\u00e9n les permite lo mismo a los dataframes basados en memoria del GPU. Sin embargo, aqu\u00ed surge un cuello de botella<\/strong>: el ancho de banda del bus de memoria del GPU<\/strong> (Barlas, 2015, p\u00e1gs. 391, 392). Esto implica que la transmisi\u00f3n de datos entre memoria principal y el GPU ha de limitarse necesariamente a la entrada de datos y el retorno de los resultados, todo mientras se dejan los datos la mayor parte del tiempo en el GPU conforme son manipulados.<\/p>\n

Aunque la principal intenci\u00f3n del proyecto cuDF<\/strong> es la introducci\u00f3n de un dataframe con API bien conocido y parecido al encontrado en Pandas, el uso del GPU tras bambalinas exige un nuevo tipo de disciplina. Sin embargo, para poder entender esto, es menester comprender a CUDA<\/strong>.<\/p>\n

Qu\u00e9 es\u00a0CUDA<\/h2>\n

CUDA<\/strong>, o Compute Unified Device Architecture<\/em>, es una arquitectura introducida por Nvidia en 2006 y es la piedra fundacional<\/strong> de muchos API y bibliotecas de nivel m\u00e1s alto que explotan el poder de c\u00f3mputo de los GPU. El modelo de programaci\u00f3n seguido por CUDA sigue el patr\u00f3n GSLP (globally sequential, locally parallel). Para poder implementar este patr\u00f3n, CUDA despliega todos los hilos que puede como un grupo y aplica una misma funci\u00f3n a todos ellos mientras var\u00eda los argumentos de \u00e9sta dependiendo del hilo. Esta funci\u00f3n es mejor conocida como el kernel<\/strong>. (Barlas, 2015, p\u00e1gs. 393, 394)<\/p>\n

Si usaramos CUDA<\/strong> directamente, el kernel<\/strong> se ver\u00eda como en la Ilustraci\u00f3n 6:<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 6: Ejemplo de kernel en CUDA (Barlas, 2015, p\u00e1g. 411)<\/p><\/div>\n

 <\/p>\n

Es decir, el kernel<\/strong> es una funci\u00f3n complicada, pues se aplica a todos los hilos y es responsabilidad de esta determinar, de ser necesario, en cu\u00e1l hilo est\u00e1 y con qu\u00e9 subconjunto de los datos est\u00e1 operando. En este ejemplo, el identificador del hilo es usado para obtener los datos apropiados de la memoria del GPU<\/strong>.<\/p>\n

Por suerte, para nosotros todos estos detalles permanecen ocultos<\/strong> si usamos cuDF<\/strong>:<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 7: ejemplo del API de cuDF (fuente: https:\/\/github.com\/rapidsai\/cudf)<\/p><\/div>\n

 <\/p>\n

En la Ilustraci\u00f3n 7 se puede ver c\u00f3mo unas pocas l\u00edneas de c\u00f3digo<\/strong> con cuDF<\/strong> son equivalentes<\/strong> a la ingesta de datos, transmisi\u00f3n de datos entre memoria principal y GPU, el uso de varios kernels y el retorno de resultados a memoria principal en CUDA<\/strong>.<\/p>\n

Sin embargo, no todo es color de rosas. Existen casos en los que resulta imprescindible bajar de nivel en cuDF<\/strong> y usar el concepto de kernel<\/strong>. Esto ocurre especialmente cuando el usuario ha de implementar funciones personalizadas, mejor conocidas como UDF<\/strong> o user defined functions<\/strong>. Un ejemplo de ello se puede apreciar en la Ilustraci\u00f3n 8:<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 8: ejemplo de kernel en cuDF con UDF (fuente: https:\/\/docs.rapids.ai\/api\/cudf\/stable\/guide-to-udfs.html#DataFrame-UDFs)<\/p><\/div>\n

 <\/p>\n

Hemos visto que con cuDF<\/strong> se pueden aprovechar las ventajas<\/strong> de los GPU<\/strong>, pero resulta importante determinar cu\u00e1ndo es apropiado usar estas herramientas<\/strong>. Mientras los n\u00facleos de un CPU son poderosos y son adecuados para procesar tareas complicadas e intensivas en c\u00f3mputo, los n\u00facleos de un GPU son perfectos para procesar numerosas tareas simples<\/strong>. Esto se refleja en el bajo n\u00famero de n\u00facleos que tiene un CPU en contraste con el gran n\u00famero de los que dispone un GPU. (OMNISCI, 2020)<\/p>\n

Ahora bien, hemos visto todas las ventajas de Apache Arrow y los dataframes acelerados por GPU, pero tambi\u00e9n surge la inquietud de cu\u00e1nto del proceso ETL se puede mejorar gracias a estas herramientas. La respuesta es: todo. Un ejemplo de ello es el surgimiento de motores de SQL acelerados por GPU<\/strong>, como BlazingSQL<\/strong>. \u00c9sta herramienta fue construida sobre el cuDF<\/strong> y es interoperable<\/strong> con diversos formatos de dataframe gracias a su uso de Apache Arrow<\/strong>. (BlazingSQL Documentation, 2020)<\/p>\n

Un ejemplo de cu\u00e1n f\u00e1cil resulta usar BlazingSQL<\/strong> con cuDF<\/strong> lo podemos ver en la Ilustraci\u00f3n 9, donde se crea un contexto de trabajo. Esto resulta similar a c\u00f3mo se trabaja con Apache Spark.<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 9: creaci\u00f3n de un contexto con BlazingSQL (BlazingSQL, 2020)<\/p><\/div>\n

 <\/p>\n

Luego de eso, se puede usar cuDF<\/strong> para cargar datos y crear una tabla en BlazingSQL<\/strong> (Ilustraci\u00f3n 10). Otra vez, esto resulta similar a Apache Spark<\/strong> cuando se desea crear una tabla con Hive<\/strong>.<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 10: creaci\u00f3n de una tabla en BlazingSQL (BlazingSQL, 2020)<\/p><\/div>\n

 <\/p>\n

Finalmente, se pueden ejecutar consultas con SQL:<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 11: consulta de SQL con BlazingSQL (BlazingSQL, 2020)<\/p><\/div>\n

 <\/p>\n

BlazingSQL no est\u00e1 solo, pues existen otras bases de datos cuyo prop\u00f3sito es acelerar operaciones b\u00e1sicas usando GPU. Un ejemplo de ello es OmniSciDB<\/strong>, un motor de SQL que ofrece operaciones de anal\u00edtica aceleradas por GPU. Su arquitectura est\u00e1 basada en la conjunci\u00f3n de tres capas que se concentran en el uso de recursos del GPU, CPU y SSD (Ilustraci\u00f3n 12).<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 12: capas de memoria y c\u00f3mputo de OMNISCI (fuente: https:\/\/www.omnisci.com\/platform\/omniscidb)<\/p><\/div>\n

 <\/p>\n

Una caracter\u00edstica importante de este motor es su modelo h\u00edbrido de c\u00f3mputo, pues en todo momento trata de ejecutar al mismo tiempo operaciones distintas tanto en CPU como en GPU. Adicionalmente, tambi\u00e9n se permite la escalabilidad horizonal de alta disponibilidad, pues ofrece un modelo de memoria de tipo shared-nothing entre distintos GPU: cada vez que m\u00e1s de un nodo es usado, cada uno s\u00f3lo tiene acceso a un subconjunto de los datos. Los datos al final del c\u00f3mputo son recogidos por el CPU. Finalmente, promote tener a futuro una excelente interoperabilidad con herramientas como TensorFlow<\/strong> y PyTorch<\/strong> debido al soporte de Apache Arrow<\/strong>. (OMNISCI, 2020)<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 13: ejemplo de reporte acelerado por GPU de OMNISCI (fuente: https:\/\/www.omnisci.com\/demos\/ships)<\/p><\/div>\n

 <\/p>\n

Un ejemplo de cu\u00e1n poderosa puede ser la aceleraci\u00f3n por GPU<\/strong> en los problemas de anal\u00edtica<\/strong> es el benchmark<\/em> hecho por el consultor Mark Litwintschik en el a\u00f1o 2017 en el que determina el tiempo que le toma a BrytlytDB <\/strong>ejecutar consultas comunes, siendo esta una base de datos similar a OmniSciDB<\/strong>, pero privada. Para su experimento descarg\u00f3 50 GB de datos sobre carreras de taxi y los carg\u00f3 sobre esta base de datos. Como resultado obtuvo tiempos de ejecuci\u00f3n<\/strong> que no tomaban m\u00e1s de un segundo<\/strong> para diversas tareas de agrupaci\u00f3n. (Litwintschik, 2020)<\/p>\n

En respuesta al reporte de Litwintschik, Richard Heyns de Brytlyt, decidi\u00f3 comparar esta base de datos con Apache Spark<\/strong>. A pesar del costo superior de usar GPU<\/strong>, el tiempo de c\u00f3mputo fue tan corto que result\u00f3 ser mucho m\u00e1s barato<\/strong> que mantener un cl\u00faster de Apache Spark<\/strong>:<\/p>\n

 <\/p>\n

\"\"

Ilustraci\u00f3n 14: comparaci\u00f3n entre Apache Spark y BrytlytDB (fuente: https:\/\/www.brytlyt.com\/blog\/apache-spark-and-brytlyt\/)<\/p><\/div>\n

 <\/p>\n

En definitiva, m\u00e1s all\u00e1 de Pandas<\/strong> existen herramientas que permiten afrontar los cuellos de botella que t\u00edpicamente encontramos durante las tareas de an\u00e1lisis y procesamiento de datos. Desde problemas de serializaci\u00f3n y cambio de formato, hasta el uso de algoritmos paralelos, todo se ha venido resolviendo con el surgir de nuevos proyectos y cambios de paradigma. Si bien esto exige un dominio mucho m\u00e1s amplio de las herramientas que ofrece el \u00e1rea del c\u00f3mputo de alto desempe\u00f1o<\/strong>, todo esto se hace necesario a medida que se va redefiniendo qu\u00e9 significa ser un ingeniero de datos.<\/p>\n

Si desean m\u00e1s informaci\u00f3n sobre estas herramientas recomiendo ver estos v\u00eddeos:<\/p>\n