gran cantidad de datos en muchos archivos de texto: ¿cómo procesarlos?

Question

Tengo grandes cantidades de datos (unos pocos terabytes) y acumulando ... Están contenidos en muchos archivos de texto plano delimitados por tabuladores (cada uno de aproximadamente 30 MB). La mayor parte de la tarea implica leer los datos y agregar (sumando/promediando + transformaciones adicionales) sobre las observaciones/filas basadas en una serie de declaraciones de predicados, y luego guardar la salida como archivos de texto, HDF5 o SQLite, etc. Normalmente uso R para tales tareas, pero me temo que esto puede ser un poco grande. Algunas soluciones candidatas son a

1. escribir toda la cosa en C (o Fortran)
2. importar los archivos (tablas) en una base de datos relacional directa e a continuación, saque trozos en R o Python (algunos de las transformaciones no son susceptibles de soluciones SQL puros)
3. escribir toda la cosa en Python

Te (3) sea una mala idea? Sé que puede ajustar las rutinas C en Python, pero en este caso, dado que no hay nada computacionalmente prohibitivo (por ejemplo, rutinas de optimización que requieren muchos cálculos iterativos), creo que la E/S puede ser un cuello de botella tan importante como el cálculo. ¿Tiene alguna recomendación sobre consideraciones o sugerencias adicionales? Gracias

Editar Gracias por su respuesta. Parece haber opiniones contradictorias sobre Hadoop, pero en cualquier caso no tengo acceso a un clúster (aunque puedo usar varias máquinas sin red) ...

Answer 1

(3) no es necesariamente una mala idea - Python hace que sea más fácil procesar el archivo "CSV" (ya pesar de que la C representa la pestaña Coma, ya que un separador es igual de fácil de manejar) y, por supuesto, obtiene casi tanto ancho de banda en operaciones de E/S como en cualquier otro idioma. En cuanto a otras recomendaciones, numpy, además del cálculo rápido (que puede que no necesite de acuerdo con sus declaraciones) proporciona matrices multidimensionales muy prácticas y flexibles, que pueden ser bastante útiles para sus tareas; y el módulo de biblioteca estándar multiprocessing le permite explotar múltiples núcleos para cualquier tarea que sea fácil de paralelizar (importante ya que casi todas las máquinas en estos días tienen múltiples núcleos ;-).

Answer 2

Eche un vistazo a Disco. Es un motor MapReduce ligero distribuido, escrito en aproximadamente 2000 líneas de Erlang, pero diseñado específicamente para el desarrollo de Python. Admite no solo trabajar en sus datos, sino también almacenar una replicación de manera confiable. Acaban de lanzar la versión 0.3, que incluye una capa de indexación y base de datos.

Answer 3

En caso de que tenga un grupo de máquinas, puede paralelizar su aplicación utilizando Hadoop Mapreduce. Aunque Hadoop está escrito en Java, también puede ejecutar Python. Puede consultar el siguiente enlace para ver los indicadores al paralelizar el código: PythonWordCount

Answer 4

Sí. ¡Tienes razón! La E/S costaría la mayor parte de su tiempo de procesamiento. No sugiero que use sistemas distribuidos, como hadoop, para esta tarea.

Su tarea se puede hacer en una estación de trabajo modesta. No soy un experto en Python, creo que tiene soporte para programación asincrónica. En F #/.Net, la plataforma tiene soporte para eso. Una vez estaba haciendo un trabajo de procesamiento de imágenes, cargar imágenes de 20K en el disco y transformarlas en vectores de características solo cuesta varios minutos en paralelo.

en general, cargue y procese sus datos en paralelo y guarde el resultado en la memoria (si es pequeña), en la base de datos (si es grande).

Answer 5

Con terabytes, querrá paralelizar sus lecturas en muchos discos; así que podría ir directamente a Hadoop.

Utilice Pig o Hive para consultar los datos; ambos tienen un amplio soporte para transformaciones definidas por el usuario, por lo que debería poder implementar lo que necesita hacer usando un código personalizado.

Answer 6

Ok, entonces para ser diferente, ¿por qué no?

• Parece que sabes R por lo que puede llegar a código de trabajo rápidamente
• 30 MB por archivo no es grande en la estación de trabajo estándar con unos cuantos GB de RAM
• la variante read.csv() de read.table() puede ser muy eficiente si especifica los tipos de columnas mediante el argumento colClasses: en lugar de guestimating tipos de conversión, estos serán manejados de manera eficiente
• el cuello de botella que aquí es de e/S del disco y que es el mismo para todos los idiomas
• R tiene multicore para configurar el procesamiento paralelo en máquinas con núcleo múltiple (similar al multiprocesamiento de Python, al parecer)
• Si desea emplear la estructura "embarazosamente paralela" del problema, R tiene varios paquetes que son adecuados para datos- problemas paralelos: Ej. snow y foreach pueden implementarse en una sola máquina o en un conjunto de máquinas en red.

Answer 7

Cuando dice "acumulando", entonces la solución (2) parece más adecuada para el problema.
Después de la carga inicial en la base de datos, solo actualiza la base de datos con archivos nuevos (¿diarios, semanales? Depende de la frecuencia con que los necesite).

En los casos (1) y (3) necesita procesar archivos cada vez (lo que se dijo anteriormente como la mayor cantidad de tiempo/recursos), a menos que encuentre una forma de almacenar los resultados y actualizarlos con archivos nuevos.

Puede usar R para procesar archivos de csv a, por ejemplo, la base de datos SQLite.

Answer 8

He tenido buena suerte al usar R con Hadoop en Amazon's Elastic Map Reduce. Con EMR pagas solo por el tiempo de la computadora que usas y AMZN se encarga de girar y girar las instancias. Exactamente cómo estructurar el trabajo en EMR realmente depende de cómo está estructurado su flujo de trabajo de análisis. Por ejemplo, ¿todos los registros necesarios para un trabajo están completamente dentro de cada csv o necesita bits de cada csv para completar un análisis?

He aquí algunos recursos que pueden resultar útiles:

• Pete Skomoroch hablando R and AMZN EMR on the AMZN discussion forum
• Mi blog acerca getting started with R and AMZN EMR
• El Rhipe project tiene como objetivo integrar R y Hadoop. Rhipe no está enfocado en EMR, sin embargo, así que no lo he usado todavía. Parece que debe ser puenteable a EMR, sin embargo.

El problema que mencioné en mi publicación de blog es más uno de estar vinculado a la CPU, no a IO. Sus problemas son más IO, pero los consejos para cargar bibliotecas y archivos caché pueden ser útiles.

Si bien es tentador tratar de meterlo dentro o fuera de una base de datos relacional, recomiendo considerar cuidadosamente si realmente necesita todos los gastos generales de un RDB. Si no lo hace, puede crear un cuello de botella y un desafío de desarrollo sin una recompensa real.