Aprendiendo Ciencia de Datos

Resumen a la lectura Explorando la infraestructura y el tunelado de datos

Si te encuentras en una situación donde el volumen, velocidad y variedad de tus datos han hecho que cambien su antiguo comportamiento nómada y manejable, el paradigma de big data está en tus manos, sin embargo, no es fácil adoptar una solución de este tipo, ya que se expande continuamente con tecnologías de datos más nuevas e innovadoras. Además, en el ecosistema de Big Data la mayoría de personas no sabemos cómo usarlo para mejorar nuestros estilos de vida, medios de subsistencia y flujo de trabajo empresarial, y es ahí, donde los ingenieros de datos y los científicos de datos pueden ayudarnos a implementar proyectos de ingeniería y ciencia de datos al mundo real. Y sí, como lo escuchas, “ingeniería y ciencia de datos”, hasta ese nivel hemos llegado, todo el glamour de la ciencia y toda la intrepidez de la ingeniería al servicio de un solo objeto de estudio: los datos “lo que nos es dado”. 

Pero no va ser tarea fácil, pues los sistemas y las arquitecturas de BD tradicionales y convencionales no se ajustan a los requisitos estructurales que demanda la ingente producción y movimiento de datos, que cada vez son más voluminosos, masivos y expansivos, es decir, rebeldes, y fácilmente se excede la capacidad de procesamiento del hardware disponible. Ahora hay que lidiar con ellos en tiempo real a un volumen, velocidad y variedad inverosímiles. Pues, el límite inferior de volumen empieza tan bajo como 1 terabyte pero no tiene límite superior. Así que, si estás arriba de él, es probable que necesites implementarlo, porque tener un repositorio tan grande de datos sin procesar tiene bajo valor, además de que continuamente se están expandiendo a través de transacciones pequeñas y crecimientos incrementales. Necesitas de ingenieros que te los compartimenten y de científicos que los analicen, pero no va ser sencillo porque su velocidad de movimiento y transferencia es altísima, entre 30 kilobytes a 30 gigabytes por segundo, requiriendo sistemas de ingeniería de datos con tiempos de respuesta menores a los 100 milisegundos, que es el tiempo que dura entre su creación y la respuesta del sistema, así que para que tu sistema de big data rinda y no sufras de indigestión de datos, necesitas manejar fácilmente 1000 mensajes por segundo, no te asustes, pues tienes ya herramientas comerciales disponibles para esa ingesta de datos, como:

Apache Sqoop: para transferencia rápida de datos entre sistemas de datos relacionales y sistema de archivos distribuidos de Hadoop. 

Apache Kafka: sistema de mensajería distribuida, como intermediario de mensajes que puedes enviar y extraer rápidamente de HDFS (Sistema distribuido de archivos Hadoop). 

Apache Flume: para manejar principalmente datos de eventos y registros, usándolo para transferir cantidades masivas de datos no estructurados hacia y desde HDFS. Puedes frotarte las manos, pero no creer que, con manejar el movimiento rápido de tus datos la tarea se vuelve más sencilla, pues ahora te queda lidiar con una variedad de datos que provienen de múltiples fuentes, formatos y tipos de estructuras. Tienes que manejar gráficos, archivos JSON, archivos XML, datos de redes sociales, datos tabulares estructurados, datos de blogs, datos de flujos de clics, datos de transacciones, formularios web, correos electrónicos, archivos Word etc., todos ellos pudiendo estar estructurados, semiestructurados y no estructurados. Pero no temas, los ingenieros, como siempre, tienen solución para todo, y se han inventado algo así como una laguna de datos, que textualmente dice: “es un sistema de almacenamiento de datos no jerárquico para almacenar grandes volúmenes de datos multiestructurados dentro de una arquitectura de almacenamiento plana”, si, como una laguna, y no solo eso, si no que puedes usar HDFS como un repositorio de almacenamiento para no enlagunarte entre tantos datos, además, si no te gusta tenerlos en tierra firma puedes usar la arquitectura de nube de la plataforma Amazon Web Services S3. 

Ahora que ya empiezas a ver que no estás solo y que ya existen soluciones comerciales para tu problema, que lo sobrepasan y lo hacen ver más fácil, puede que subas un escalón más, y te interese ya no solo manejar y procesar tus datos, sino conseguir más de ellos, antes eras avaro y ahora quieres más, es normal porque tienes una variedad de fuentes generadas tanto por la actividad humana como por máquinas y sensores. Si te animas y aceptas el reto, puedes obtenerlos de las redes sociales, transacciones financieras, registros de salud, secuencias de clics, archivos de registro, y, del nuevo paradigma dentro de otro paradigma, el internet de las cosas, red de conexiones digitales entre una gama cada vez mayor de dispositivos electrónicos. 

Ahora, a estas alturas, tengo que darte un buen consejo, antes de que me olvide, debes tener muy clara la diferencia entre científico e ingeniero de datos, no vaya ser que los confundas y termines más enredado. El ingeniero tiene la tarea de procesar tus datos, para ello debe ser diestro en informática, diseño de base de datos e ingeniería del software, para diseñar e implementar marcos de procesamiento en tiempo real, plataformas de procesamiento masivo en paralelo, sistemas de gestión de base de datos relacionales, es decir, hacer fontanería fina para que los cómodos científicos de datos lleguen a su asiento y reciban con el periódico del día, toda la información relevante y oportuna a la cual tienen que dar sentido, pero no creas que por estar de bata blanca y lentes cuadrangulares sentados ante un computador tienen las cosas más fáciles, puedes deben tener una experiencia cuantitativa amplia y diversa en el uso de técnicas matemáticas, estadísticas, técnicas de pronóstico, métodos predictivos, programación de computadoras, pero sobre todo, un dominio del tema que te haga despreocuparte por completo de estar pendiente de ellos. Finalmente, no trates de ahorrarte dinero queriendo pagar por dos el precio de uno, pues vas a tener de todo un poco, que al final no lleva a nada. 

Con este pequeño preámbulo, ya podemos pasar a cosas más interesantes como las técnicas que existen para procesar y manejar la Big Data. Comencemos por Hadoop, que, ante las limitaciones de los sistemas relacionales, es una plataforma de procesamiento que reduce el big data en conjuntos más pequeños pero manejables de datos, siguiendo el viejo dicho de divide y vencerás. Hadoop en sí, es ahora, un ecosistema que incluye a “Hadoop parte” para almacenamiento de datos, MapReduce para procesarlos masivamente, Spark para hacerlo en tiempo real y YARN para gestionar los recursos involucrados. 

Pues bien, este tema de dividir, clasificar e integrar, aunque suene muy aburrido y repetitivo permite hacer lotes de grandes volúmenes de datos, facilitándote el trabajo de organizarlos y procesarlos. Pero como todo buen proceso de producción en economía de escala, requiere de una máquina procesadora muy potente pero que sea de bajo costo, para hacer que esos datos valgan la pena. Esto se logra con la distribución y procesamiento en paralelo de tareas, en grupos de servidores básicos que, aunque sean de bajo rendimiento y bajo costo, no significa que no tengan oportunidad de afrontar desafíos más grandes, pues, dos cabezas piensan más que una, y todos ellos sumados sí que piensan demasiado. 

El proceso comienza por mapear los datos, delegándolos a pares clave-valor, y así, transformados, filtrarlos para asignarles su nodo de procesamiento, donde les reciben clústeres de computación (conjunto de servidores básicos) que han de reducirlos a conjuntos de datos de menor tamaño pero en un formato de clave-valor estándar, es decir, los hemos domesticado, aunque momentáneamente encarcelándolos, ya que la clave actúa como identificador de registro, para así, finalizadas las tareas de reducción, distribuidas a los diferentes nodos del clúster, la salida final se escriba en un sistema de archivos. 

Ahora bien, se te puede ocurrir la brillante idea de que, una vez que estos datos han cumplido su labor y empiezan a deambular, hay que evitar que se vuelvan vagos e improductivos, lo cual requiere que el procesamiento por lotes sea efectuado en tiempo real, permitiéndote consultar flujos de big data en plena transmisión de los datos. Y nuevamente tenemos que agradecer a los hábiles ingenieros que han logrado crear el procesamiento en tiempo real, donde Spark destaca queriendo reemplazar a MapReduce, al lograr avances importantes como consultar, explorar, analizar e incluso ejecutar algoritmos de aprendizaje automático en datos de transmisión errantes en tiempo real. Y eso no es suficiente para Spark, que ha logrado grandes avances, alargando la vida útil de los datos para hacer predicciones a partir de fuentes grandes y diversas en tiempo record, de tres segundos. 

Déjame decirte que hemos empezado por el final, ya que hasta aquí hemos hablado de la forma de procesar los datos, pero no de su almacenamiento, pero lo hemos hecho porque esta sigue la misma lógica de los clústeres de procesamiento distribuido, al generarse a partir de un sistema de archivos distribuidos de Hadoop, HDFS. Lo extraordinario de ello, es que tanto para las tareas de almacenamiento como para las de procesamiento, se requiere del mismo contingente de hardware básico, compuesto de servidores genéricos de bajo costo y bajo rendimiento que en conjunto se entusiasman y son muy productivos ofreciendo potentes capacidades informáticas. Lo único que se debe tomar en cuenta para que este almacenamiento sea garantizado es que debe cumplir con tres características claves: 

Bloques HDFS: unidades de almacenamiento que contienen un número máximo de registros.

Redundancia: esos datos divididos y almacenados en bloques, deben ser replicados, tres veces de forma predeterminada, es decir, se los clona en varios servidores diferentes por cada clúster como respaldo en caso de que uno falle. 

Tolerancia a fallos: con lo anterior se logra, que ante presencia de fallas el sistema pueda continuar con sus operaciones exitosamente. 

Finalmente quiero hablarte de soluciones alternativas al Big Data, que te permiten trabajar en tiempo real o utilizar tecnologías de base de datos alternativas para manejarlo y procesarlo. 

Lo primero se logra con plataformas de procesamiento masivo en paralelo MPP, que permiten implementar procesamiento paralelo en almacén de datos tradicional, este marco de procesamiento, a diferencia de MapReduce ejecuta tareas de computación paralela, pero con hardware costoso y personalizado, siendo más rápido y fácil de usar que los trabajos estándar de MapReduce, ya que se puede consultar MPP mediante SQL.

Lo segundo se logra con bases de datos NoSQL, aunque todavía no se logra diferenciar entre “No solo SQL” de “No son SQL”. Estas bases de datos superan los problemas que tienen las RDBMS tradicionales para manejar demandas de Big Data, ya que no pueden manejar datos estructurados y semiestructurados y no tienen las capacidades para afrontar el reto de las “3V”. En cambio, NoSQL al ser bases de datos distribuidas y no relacionales superan la arquitectura tradicional de las bases de datos relacionales ofreciendo una solución mucho más escalable y eficiente, pudiendo manejar base de datos no relacionales de tipo gráficos, documentos, clave-valor y familias por columnas. Entre las aplicaciones NoSQL conocidas están Apache Cassandra y MongoDV.

Así que, he llegado al final, dejándote como desafío empresarial que logres transformar esa estructura aislada e introvertida de tus sistemas de datos, donde los datos muchas veces se pierden y quedan enterrados en un lío de sistemas separados de almacenamiento, siendo una restricción que limita el crecimiento de tu negocio al no permitirte optimizar el retorno de la inversión en ventas y marketing, en una moderna arquitectura de plataforma de big data. 

Pues bien, ¡manos a la obra!