Categoría: Arquitectura de Datos Página 1 de 2

Ya hemos visto como en Big Data manejamos una gran cantidad de datos que se generan de manera constante a gran velocidad. Datos que además provienen de distintas fuentes, con distintas estructuras, organizadas de distintas maneras. El curado de datos es la actividad por la que organizamos todos estos datos de la misma manera, dejándolos preparados para su posterior análisis y extracción de información.

Procesos ETL

Cuando nos planteamos el tratamiento de los datos, nos vemos en la necesidad de definir algún tipo de metodología que nos ayude a estructurar el trabajo y evite que nos perdamos entre tanto dato. Estos son los procesos ETL, del inglés: E: extract, T: transform y L: load.

Los nombres de las fases de este proceso ya nos dan una ligera idea de la acción a realizar en cada una de ellas. En cualquier caso, veámoslas con un poco más de detalle.

Leer más

Hadoop es un ecosistema, es decir, un conjunto de componentes que implementan las distintas funciones necesarias para trabajar en entornos Big Data. Esta pensado para trabajar con Clusters de ordenadores de bajo coste. Y es un proyecto de la fundación Apache, por lo que cuenta con una licencia de software libre, lo que significa que cualquiera puede usarlo sin tener que pagar por ello.

Hay dos componentes fundamentales en el ecosistema Hadoop:

• El sistema de ficheros distribuidos HDFS (Hadoop Distributed File System): Basado en la Big Table de Google que fue el primer sistema de ficheros distribuidos para trabajar con Big Data. Es el sistema de ficheros para trabajar con los ordenadores del clusters, realizando todas las funciones clásicas de un sistema de ficheros: guardar datos, localizar y acceder a ellos.
• El sistema de procesamiento MapReduce: Es el sistema para procesar los datos en el Cluster, que también está tomado de Google, quien lo desarrollo para procesar la información de las distintas páginas web que recogía para las búsquedas.

La clave del éxito de Hadoop es que divide el almacenamiento de los datos y el trabajo de procesamiento entre los distintos ordenadores del cluster, realizando varias operaciones en paralelo, pudiendo así manejar muchos datos en menor tiempo.

Leer más

En posts anteriores he hablado de la aparición del Big Data y de las famosas Vs. De repente, se hizo necesario ser capaz de manejar muchísimos más datos con una afluencia muchísimo mayor. Las arquitecturas tradicionales no podían lidiar con esta nueva situación, y se desarrollaron las arquitecturas Big Data. Estas últimas enfocadas a trabajar con los datos en las nuevas condiciones.

Antes de la aparición del Big Data, con un buen servidor y un RAID de discos era suficiente para procesar y almacenar todos los datos que manejábamos. Esta arquitectura era además escalable y las necesidades de ampliación eran asumibles. Sin embargo, con la llegada del Big Data, y la gran cantidad y variedad de datos que tenemos que manejar y almacenar, las arquitecturas tradicionales basadas en un servidor resultan insuficientes. Se hace inviable procesar toda esta información en un único ordenador, y se desarrollan arquitectura Big Data basadas en Clusters de ordeanadores (un conjunto de ordenadores trabajando de manera coordinada para resolver una misma tarea).

Por tanto, en una arquitectura Big Data, vamos a trabajar con múltiples ordenadores y tendremos nuestras capacidades de computación distribuidas. Para aprovechar eficientemente estas capacidades, recurrimos a algoritmos de procesamiento paralelo que distribuyen la carga de procesamiento entre los distintos ordenadores del Cluster. Esto también nos ayudará a procesar los datos más rápidamente, que es otro de los requerimientos de una arquitectura Big Data, como por ejemplo con las queries de un buscador web.

Leer más

El término Big Data está de moda, podríamos traducirlo por “datos masivos” y viene a representar el aumento exponencial de los datos que generamos, almacenamos y manejamos. Estos datos se han convertido en un activo muy valioso para las compañías, que se encuentran con el reto de saber gestionarlos y convertirlos en información útil para el negocio, para ayudar a la toma de decisión en tiempo real. De ahí la manida expresión de los datos son el petróleo del futuro.

Durante los últimos tiempos, esta cantidad de datos ha crecido significativamente, hasta el punto de que los sistemas de gestión de datos tradicionales no dan una respuesta satisfactoria a esta nueva realidad. Y cuando hablo de sistemas tradicionales, me refiero fundamentalmente a las bases de datos relacionales.

Seguramente, habréis escuchado en alguna ocasión, que un Smartphone tiene más capacidad de almacenamiento y computación de la que dispuso la NASA para colocar al hombre en la luna y traerlo de vuelta sano y salvo. Lo cierto es actualmente, en un día, enviamos más de 250 mil millones de correos, realizamos más de 6 mil millones de búsquedas en Google, casi 7 mil millones de reproducciones de videos en YouTube o más de 700 millones de tweets diarios.

Leer más

En posts anteriores, habíamos visto como las bases de datos relacionales supusieron la solución para el problema de redundancia que surgía cuando usábamos los ficheros planos para almacenar los datos. No obstante, las bases de datos relacionales presentaban otros problemas, y no tardaron en surgir otras alternativas de bases de datos que organizaban los datos de forma diferente, y que son conocidas en su conjunto como bases de datos NO relacionales. En este tema, recorreremos estas bases de datos, describiendo brevemente los distintos tipos y explicando como estructuran los datos para su almacenamiento.

La rigidez de las bases de datos relacionales

Al abandonar los ficheros planos y empezar a usar las bases de datos relacionales, solucionamos el problema de redundancia. Ya no teníamos que repetir datos en varias filas y además reducíamos sensiblemente el número de errores en la introducción de los datos, lo que obviamente redundaba en una notable mejora de la calidad de los mismos.

Sin embargo, la manera de estructurar los datos que proponen las bases de datos relacionales es muy rígida, obliga a emplear estructuras muy estrictas en las que manejamos un número fijo de campos que además tienen que almacenar datos de un determinado tipo. Esto hizo que empezaran a plantearse opciones más flexibles.

La primera demanda de una mayor flexibilidad a la hora de guardar los datos, vino con el auge de la programación orientada a objetos. En este tipo de programación, los programadores emplean Clases, una estructura de datos que representaban objetos reales y su comportamiento. Sin embargo, cuando queríamos guardar los datos al acabar de trabajar con el programa, había que traducir la estructura de datos de los objetos, a la de la base de datos relacional en la que fuéramos a guardarlos. Esta complicación es conocida con el nombre de problema de impedancia.

Leer más