¿Elige escalar su DW / DB o implementar Hadoop cuando la cantidad de datos o la concurrencia se vuelve muy grande?

Aumentar proporcionalmente.

El volumen de datos por sí solo nunca debería ser el punto decisivo para implementar Hadoop. El análisis de datos tiene un costo, y el liderazgo empresarial necesita entender eso. No es realista para la mayoría de las empresas suponer que simplemente pueden almacenar y analizar todo bajo el sol. El beneficio debe superar el costo. Para ayudar a lidiar con esto, tener una estrategia de archivo y purga de datos de sonido es increíblemente importante, y la mayoría de las bases de datos tienen herramientas para ayudar con esto (desde la compresión hasta el almacenamiento en frío).

Si bien la pila de Hadoop se puede descargar y usar de forma gratuita, implementarla, desarrollarla y mantenerla es muy costosa (solo mire el salario de un desarrollador de reducción de mapas). Los proveedores del almacén de datos eliminan gran parte del dolor de cabeza de escalar, eso es lo que estás pagando.

Estoy completamente de acuerdo con Chris: agregaré otros puntos a la conversación.
Más datos no lo hacen, y no deberían ser iguales a más datos en el almacén de datos. Hay mucho ruido, inconsistencia y datos incorrectos agrupados en lo que la industria se refiere como explosión de datos. Solo porque sus datos no significan que sean buenos, y no significa que deben ir al almacén de datos.

El rendimiento es una gran razón por la que no elegiría Hadoop: el hecho de que haya más datos no significa que necesariamente obtenga más rendimiento de hadoop; los RDBMS tienen excelentes herramientas para obtener rendimiento en grandes conjuntos de datos: índices, particiones, mapeo de zonas , Sugerencias de SQL, memoria inteligente, almacenamiento en caché, etc. Se tarda un promedio de 2 minutos en ejecutar un trabajo de Map Reduce, dependiendo de la consulta, eso es un minuto y medio más de lo que tomaría en un RDBMS.

– Nota al margen, para todos los fanáticos de Hadoop que van a lanzar Presto y Cassandra, sí, son excelentes sistemas de db sobre Hadoop, pero todavía son bases de datos NoSQL que pueden dar a algunas consultas un mejor rendimiento, pero no todos, y aún debe tener en cuenta el costo de la migración, el soporte y la capacitación de los usuarios en CQL, Java o Python, lo que no necesariamente vale el costo por el aumento del rendimiento. (a partir de abril de 2014, como con cualquier tecnología, me reservo el derecho de editar esta declaración más adelante)

Además, Hadoop no ofrece E / S “más rápidas”. Ofrece más rutas de acceso al disco que no compiten entre sí. Diferente bajo las sábanas, mismo resultado. Además, mayor acceso concurrente: la mayor parte de la funcionalidad que he visto en Hadoop ha sido aplicaciones que acceden a ella en tiempo real o procesamiento por lotes. No creo que Hadoop aborde una mayor concurrencia.

Así que sugiero las siguientes formas de “aliviar la presión” del almacén de datos:

  1. La estrategia de depuración y archivo es muy importante.
  2. Hadoop para el tipo correcto de datos y los casos de uso correctos
  3. En Memory Analytics para consultas que requieren un alto rendimiento
  4. Entorno de exploración de datos (sandbox, Asterdata, Watson Data Explorer, etc.) para datos con valor comercial cuestionable o desconocido
  5. Tenga una estrategia sólida de data mart y de informes operativos: no todo tiene que ir al almacén
  6. Consulta de federación en múltiples fuentes de datos