Problema de Big Data
Los volúmenes de Big Data están creciendo exponencialmente. Este fenómeno ha estado ocurriendo durante años, pero su ritmo se ha acelerado drásticamente desde 2012. Consulte este blog titulado Big Data Just Beginning to Explode de CSC para obtener un punto de vista similar sobre el surgimiento de Big Data y los desafíos relacionados.
IRI ha sido consciente de esta tendencia desde la fundación de la empresa a fines de la década de 1970. Su paquete insignia CoSort está diseñado para manejar volúmenes de datos crecientes a través de eficiencias en algoritmos y diseño de software, técnicas de explotación de hardware "portátiles" y consolidación de tareas (por ejemplo, ordenar-unir-agregar-encriptar-informe). La pregunta que plantea este artículo es de enfoque, dado el “aumento de las máquinas”.
Limitación del hardware para resolverlo
Ciertamente, el rendimiento de la computadora se ha acelerado en casi todos los aspectos durante décadas. Y para muchos, lanzar hardware al problema de big data es simplemente una segunda naturaleza. Sin embargo, el problema puede ser más grande que eso. Considere la Ley de Moore, en la que la potencia de la CPU solo se duplica cada 18 meses en el mejor de los casos, y la obsolescencia inherente, los problemas de mantenimiento y los costos puros de una estrategia centrada en el hardware.
Algo nuevo a considerar también es la expectativa de que este paradigma de rendimiento para big data pueda estar llegando a su fin. Según Gery Menegaz, su premisa es que el final de la Ley de Moore está cerca. La revista Time publicó una historia similar en mayo de 2012 titulada El colapso de la ley de Moore:el físico dice que ya está sucediendo. Según el artículo de Time,
Dado eso, Kaku dice que cuando la Ley de Moore finalmente se derrumbe a fines de la próxima década, "simplemente la modificaremos un poco con computadoras similares a chips en tres dimensiones". Más allá de eso, dice que "es posible que tengamos que ir a las computadoras moleculares y tal vez a finales del siglo XXI las computadoras cuánticas".
Sin embargo, para la mayoría de los usuarios, su hardware se compra para manejar y, en cierta medida, escalar, para cumplir con los desafíos de procesamiento de big data que enfrentan o prevén. Pero cuanto menos eficiente sea el rendimiento del software que se ejecuta en él, más recursos de hardware se deben gastar para superar la ineficiencia. Un ejemplo en nuestro mundo podría ser comprar un IBM p595 para ejecutar /bin/sort cuando una máquina de un tercio de ese tamaño y costo que ejecuta CoSort produciría el mismo resultado.
Mientras tanto, los dispositivos DB y ELT como Exadata y Netezza construidos alrededor del hardware ya requieren inversiones de 6 a 7 cifras. Y si bien pueden escalar para aceptar cargas más grandes, generalmente hay un límite en cuanto a cuánto pueden escalar (ciertamente no exponencialmente), cuánto dinero se puede gastar en el intento de seguir escalando y qué tan dispuestas están las personas a confiar en un único proveedor para cada aspecto de misión crítica de sus cargas de trabajo. Y, ¿es una buena idea imponer la sobrecarga de la transformación de big data en bases de datos que fueron diseñadas para la optimización de almacenamiento y recuperación (consultas)?
Incluso si todas esas preguntas tuvieran respuestas fáciles, ¿cómo se resuelven los problemas computacionales (incluso con solo escalar linealmente el crecimiento de big data) que requieren un consumo de recursos exponencialmente mayor (como la clasificación)? De alguna manera, la respuesta no parece estar simplemente esperando la computación cuántica asequible...
El papel del software
Como saben los arquitectos de almacenamiento de datos y Hadoop, la clasificación (y las operaciones de unión, agregación y carga en ETL que dependen de la clasificación) está en el centro del desafío del procesamiento de big data y es un consumidor exponencial de recursos de cómputo. A medida que el big data se duplica, los requisitos de recursos para clasificarlo pueden triplicarse. Por lo tanto, los algoritmos, las técnicas de explotación de hardware y los esquemas de procesamiento involucrados con el software de clasificación multinúcleo y multiplataforma son las claves para gestionar este problema de manera escalable, asequible y eficiente.
Contribución de CoSort
El rendimiento de CoSort escala linealmente en volumen, más en la línea de la Ley de Amdahl. Si bien CoSort puede transformar cientos de gigabytes de big data en minutos con unas pocas docenas de núcleos, otras herramientas pueden tardar más del doble, no escalan tan bien y/o consumen más memoria y E/S en el proceso. Quizás lo más importante es que CoSort integra la clasificación directamente en las aplicaciones relacionadas y realiza todo el trabajo pesado fuera de la capa de DB y BI, donde los datos de preparación serían menos eficientes.
La arquitectura co-rutina de CoSort mueve registros entre el clasificador y programas como SortCL (utilidad de transformación, filtrado, búsqueda, generación de informes, migración y protección de datos de CoSort) de forma interactiva, a través de la memoria. Entonces, tan pronto como el siguiente registro ordenado esté disponible, puede pasar a la aplicación, cargar, etc. A la aplicación le parece que está leyendo un archivo de entrada, pero en realidad, el back-end de la fuente aún no se ha producido. Y no, no te adelantarás al clasificador.
A finales de 2015, CoSort también se convirtió en el motor de Voracity, la moderna plataforma de gestión y manipulación de big data de IRI. Voracity aprovecha los motores CoSort o Hadoop sin problemas.
Conclusión
No se puede contar con los recursos informáticos físicos por sí solos para escalar el problema del procesamiento de big data. El entorno de software de CoSort es uno en el que la transformación de big data requerida y los trabajos relacionados no se ejecutan como procesos independientes, sino en paralelo durante el mismo paso de E/S.
Por lo tanto, si necesita una clasificación rápida para algún propósito que no sea solo el tiempo de clasificación, debe pensar en lo que sucede aguas abajo de la clasificación y las mejores formas de vincular dichos procesos. Y una vez que haya determinado el mejor paradigma de tiempo de ejecución, ¿puede combinar hardware de alto rendimiento con dicho software para optimizar el rendimiento? ¿Puede organizar datos DW con CoSort en el lado del servidor de base de datos de Exadata, por ejemplo? ¿O tendría más sentido mantener su IBM p595 y agregar CoSort para triplicar el rendimiento? O si tiene la intención de usar Hadoop, considere usar el mismo 4GL simple de CoSort o las asignaciones ETL intuitivas de Voracity para impulsar los trabajos de MapReduce 2, Spark, Storm o Tez.
Deje que su presupuesto y su imaginación sean sus guías para abordar el crecimiento de los datos.
