En AWS, ¿qué es mejor para el análisis y modelado de datos: instancias optimizadas para memoria o computación?

Su memoria optimizada … Err … Su cálculo optimizado … Bueno … – La respuesta correcta necesita tomar ‘su algoritmo’ en la ecuación , y necesita saber:

  1. El tamaño de entrada que su algoritmo necesita procesar.
  2. (cuánto cómputo intensivo) realiza su algoritmo para generar resultados.
  3. ¿Y cuáles son sus requisitos de rendimiento? ¿Es necesario devolver el resultado en milisegundos porque está respondiendo algunas ‘consultas en tiempo real’? ¿O es su requisito lo suficientemente liberal como para terminar en una semana porque estaba haciendo algún tipo de procesamiento por lotes de terabytes de datos, en lugar de consultas en tiempo real de unos pocos GB de datos?

Inspirándose en algunos libros sobre Computación en CPU paralela y Computación en GPU y algunas experiencias personales de la vida real: aquí hay conclusiones (pueden variar ya que sus algoritmos son diferentes a los míos):

  • Calcular instancias optimizadas para el procesamiento por lotes de terabytes de datos
    Hubo esta situación en la que tuve que procesar el volcado de wikipedia sin procesar. Terabytes de datos cuando no están comprimidos. Devuelve algunos GB de datos de salida. Un lote particular de proceso que se ejecutaba en un solo núcleo demoraba 12 horas. Procesar el basurero completo llevaría meses. Contraté algunas instancias de Compute optimized. Funcionó lotes en subprocesos múltiples. Terminado dentro de una semana
  • Instancias optimizadas de memoria para devolver consultas en tiempo real
    Unos 40 GB de datos gráficos preparados a partir de un pequeño subconjunto de Wikipedia. Se necesitarían consultas en tiempo real. Solía ​​llevar a mi programa unos ’20 minutos ‘para calentar antes de que pudiera responder cualquier consulta. Cualquier consulta utilizada para devolverse en milisegundos devolviendo varios MB de datos de los 40 GB que cargué en mi instancia de AWS de memoria optimizada de 60 GB
  • Mezcla de ambos para devolver consultas en tiempo real
    Hubo una situación en la que los datos de mi gráfico se ejecutaban en TB. La única opción que tenía era almacenar eso en una variedad de SSD: si hubiera podido comprar la infraestructura, hubiera preferido mantenerla en la memoria para una transversal más rápida. Se descubrió una ruta alternativa donde creé un ÍNDICE DE DATOS GRÁFICOS (o debería ver cargado un pequeño subgrafo) y lo guardé en la memoria. Realicé consultas contra este índice de gráfico en memoria (que tenía unos pocos GB de tamaño), y una vez que se identificó la sección ‘apropiada’ del gráfico a partir del índice de gráfico, cargaría solo esa parte de los datos de gráfico más grandes de SSD. Originalmente intenté esto en una máquina de memoria intensiva. Que podría contener varios GB de índice gráfico en memoria. Pero esto ni siquiera fue tan rápido (los resultados llegaron en segundos mientras mi requerimiento estaba en milisegundos). Probablemente requirió procesamiento de múltiples núcleos. Si bien consideré los más de 16 núcleos que tenía disponibles en mi instancia de AWS, y también consideré hacer Computación Paralela, conectar en red algunas máquinas con Optimización de Memoria para agrupar datos en un clúster, pero en estos días estoy experimentando con ejecutarlo en unos 1000 de núcleos disponibles en una sola tarjeta GPU . Su rendimiento puede ser similar a la programación en paralelo de la CPU, pero PUEDE obtener mejores resultados con la computación GPU (el reloj araría un campo con 2 bueyes fuertes o 1024 pollos …). Le diría cómo mis resultados en 2-3 semanas (envíeme un mensaje si es necesario)

En resumen, para encontrar la respuesta a SU pregunta. Debe ejecutar su algoritmo al menos una vez en una sola máquina central. Y entonces :

  1. Descubra cómo funciona en SSD.
  2. Vuelva a escribir el código para uso en memoria si no está satisfecho con la velocidad de la memoria
  3. Considere hacerlo multiproceso, para eso es posible que necesite codificar su algoritmo de tal manera que funcione en paralelo al dividir el trabajo en paquetes pequeños, en lugar de hacerlo en un orden en serie (algunos algoritmos no pueden cambiarse de serie a paralelo) a menos que lees algunos libros ilustrativos como ‘CUDA by Example’ o ‘Professional CUDA’)
  4. Considere la computación paralela sobre la CPU
  5. Considere la computación sobre una sola GPU
  6. Considere la computación paralela sobre GPU en red

No desea ir directamente al paso 3 (sin mencionar el paso 4, 5, 6), sin ejecutar puntos de referencia de su algoritmo. Es costoso en términos de horas de desarrollo. Si sus puntos de referencia exigen más rendimiento, no dude en intentar el paso 3, 4, 5, 6, que son básicamente escalas variables de máquinas AWS ‘computacionales intensivas’