Procesamiento de datos, historia y evolución

Procesamiento de datos, historia y evolución.¿Cómo podemos procesar los datos y cuáles son los sistemas de procesamiento de datos disponibles para nosotros hoy? ¿Por qué procesamos datos?
¿Cómo ha evolucionado el procesamiento de datos (de código abierto) y cómo han progresado las diferentes tecnologías con el tiempo a medida que los marcos de procesamiento de datos se han vuelto más sofisticados y la cantidad y la velocidad de los datos generados han aumentado por hora?

Tratemos de responder las siguientes dos preguntas: ¿Cómo podemos procesar los datos y cuáles son los sistemas de procesamiento de datos disponibles para nosotros hoy? ¿Por qué procesamos datos? Eso es bastante obvio cuando considera la gran cantidad de dispositivos conectados, sensores y visitas al sitio web. Sin mencionar todos los datos generados por humanos y máquinas. Está claro que el procesamiento de datos ha existido desde que inventamos las computadoras y tuvimos acceso a los datos.

Al principio…

La invención de las computadoras creó una clara necesidad de información y procesamiento de datos. Durante estos primeros días, los informáticos tuvieron que escribir programas personalizados para procesar datos y estos probablemente se almacenaron en una tarjeta perforada. Los siguientes pasos trajeron lenguaje ensamblador y lenguajes de programación más útiles como Fortran, seguido de C y Java. Durante el espacio prehistórico de big data, los ingenieros de software usarían estos lenguajes para escribir programas especialmente diseñados para tareas específicas de procesamiento de datos. Sin embargo, este paradigma de procesamiento de datos solo era accesible para unos pocos seleccionados que tenían antecedentes de programación que impedían una adopción más amplia por parte de los analistas de datos o la comunidad empresarial más amplia que quería procesar información y tomar decisiones específicas.

El siguiente paso natural fue la invención de la base de datos, en y alrededor de la década de 1970. Los sistemas de bases de datos relacionales tradicionales, como las bases de datos de IBM, habilitaron SQL y aumentaron la adopción de procesamiento de datos por audiencias más amplias. SQL es un lenguaje de consulta estandarizado y expresivo que se lee como el inglés. Permitió a más personas acceder al procesamiento de datos que, por lo tanto, ya no tuvieron que depender de los programadores para escribir programas especiales caso por caso y analizar datos. SQL también amplió la cantidad y el tipo de aplicaciones relevantes para el procesamiento de datos, tales como aplicaciones comerciales, análisis de tasas de abandono, tamaño promedio de la canasta, cifras de crecimiento interanual, etc.

Amanecer de Big Data

La era de Big Data comenzó con el documento MapReduce, publicado por Google, que explica un modelo simple basado en dos primitivas: Map y Reduce. Estas primitivas permitieron cálculos paralelos en una gran cantidad de máquinas paralelas. Obviamente, los cálculos paralelos eran posibles incluso antes de la era de MapReduce a través de múltiples computadoras, supercomputadoras y sistemas MPI. Sin embargo, MapReduce lo puso a disposición de un público más amplio.

Apache Hadoop vino después como una implementación de código abierto del marco (inicialmente implementado en Yahoo!) que estaba ampliamente disponible en el espacio de código abierto y accesible para un público más amplio. Hadoop fue adoptado por una variedad de compañías y muchos jugadores de Big Data tuvieron su origen en el marco de Hadoop. Hadoop creó un nuevo paradigma en el espacio de procesamiento de datos: la capacidad de almacenar datos en un sistema de archivos distribuido o almacenamiento (como HDFS para Hadoop) que luego podría ser interrogado / consultado en un momento posterior. Hadoop abrió un camino similar a las bases de datos relacionales, en donde el primer paso incluyó la programación personalizada por un «elenco» específico de individuos que pudieron escribir programas para luego implementar consultas SQL en los datos en un sistema de archivos distribuido, como Hive u otros marcos de almacenamiento.

El procesamiento por lotes se intensifica

El siguiente paso en Big Data vio la introducción de Apache Spark. Spark permitió paralelización adicional y llevó el procesamiento por lotes al siguiente nivel. Como se mencionó anteriormente, el procesamiento por lotes incluye poner datos en un sistema de almacenamiento en el que luego se programan los cálculos. El concepto principal aquí es que sus datos se encuentran en algún lugar mientras realiza periódicamente (diariamente, semanalmente, cada hora) cálculos para obtener resultados basados ​​en información pasada. Estos cálculos no se ejecutan continuamente y tienen un punto de inicio y un punto final. Como resultado, debe volver a ejecutarlos de forma continua para obtener resultados actualizados.

De Big Data a Fast Data: la llegada del procesamiento continuo

El siguiente paso en la evolución de Big Data vio la introducción del procesamiento de flujo con Apache Storm como el primer marco ampliamente utilizado (hubo otros sistemas y marcos de investigación al mismo tiempo, pero Storm fue el que vio una mayor adopción). Este marco permitió escribir programas que podrían ejecutarse continuamente (24/7). Contrariamente al enfoque de procesamiento por lotes donde los programas y las aplicaciones tienen un principio y un final, los programas de procesamiento de flujo se ejecutan continuamente en los datos y producen resultados en tiempo real, mientras se generan los datos. El procesamiento de flujo se avanzó aún más con la introducción de Apache Kafka (originado en LinkedIn) como un mecanismo de almacenamiento para un flujo de mensajes. Kafka actuó como un búfer entre las fuentes de datos y el sistema de procesamiento (como Apache Storm).

Lambda Architecture creó un pequeño desvío en la historia de Big Data. Esta arquitectura se originó porque los adoptantes iniciales del procesamiento de flujo no creían que los sistemas de procesamiento de flujo como Apache Storm fueran lo suficientemente confiables; por lo tanto, mantuvieron ambos sistemas (procesamiento por lotes y flujo) ejecutándose simultáneamente. La arquitectura Lambda era una combinación de ambos sistemas: se utilizó un sistema de procesamiento de flujo como Apache Storm para obtener información en tiempo real, pero luego la arquitectura utilizaba periódicamente un sistema de procesamiento por lotes que mantenía la verdad de lo que había sucedido.

Apache Flink: el procesamiento de flujo se vuelve accesible

Alrededor de 2015, Apache Flink comenzó a convertirse en un marco de procesamiento de flujo prominente adoptado por desarrolladores y líderes de datos / análisis. Desde el principio, Flink exhibió garantías muy fuertes; la semántica exactamente una vez y un motor de procesamiento tolerante a fallas que hizo que los usuarios creyeran que la arquitectura Lambda ya no era necesaria y que el procesamiento de flujo podría ser confiable para el procesamiento de eventos complejos y aplicaciones críticas de misión continua. Todos los gastos generales que vinieron con la construcción y el mantenimiento de dos sistemas (procesamiento por lotes / flujo) se volvieron redundantes debido al marco de procesamiento de datos confiable y accesible de Flink.

El procesamiento de flujo introdujo un nuevo paradigma y cambio de mentalidad de una posición de solicitud-respuesta, donde los datos se almacenan antes de la posible interrogación de casos de fraude a uno en el que hace preguntas primero y luego obtiene la información en tiempo real a medida que se generan los datos. Por ejemplo, con el procesamiento continuo puede desarrollar un programa de detección de fraude que se ejecuta 24/7. Obtiene eventos en tiempo real y le brinda información cuando hay fraude con tarjetas de crédito, evitando que ocurra en primer lugar. Este es potencialmente uno de los cambios más importantes en el procesamiento de datos porque permite obtener información en tiempo real de lo que está sucediendo en el mundo.

La evolución del procesamiento de datos de código abierto ha experimentado un patrón común; Se introduce un nuevo marco en el mercado (es decir, una base de datos relacional, procesamiento por lotes, procesamiento continuo) que está inicialmente disponible para un público específico (programadores) que puede escribir programas personalizados para procesar datos. Luego viene la introducción de SQL en el marco que lo hace ampliamente accesible para audiencias que no necesitan escribir programas para el procesamiento sofisticado de datos. El procesamiento de flujo sigue un patrón similar; SQL para el procesamiento de transmisión experimenta una amplia adopción en aplicaciones de transmisión que valida el patrón que experimentamos en el pasado. Se espera que el mercado de procesamiento de flujo crezca exponencialmente en los próximos años a una tasa compuesta anual de 21.6 porcentavo. Con este crecimiento y la cantidad de aplicaciones de procesamiento de flujo y casos de uso que explotan cada día, los desarrollos en este espacio son numerosos y el futuro del procesamiento de flujo en un entorno en constante cambio y evolución.

Leer también: Big data analytics qué es, definición, concepto, significado; porqué es importante; Big data vs Business Intelligence

This post is also available in: Español