Disclaimer: Hay muchísima gente infinitamente mejor preparada que yo para hablar de Big Data. Muchos que, como yo, venimos del mundo del marketing, sentimos la inquietud de entender este tsunami pero no resulta sencillo descrifrar sus claves. Si quieres profundizar en el tema la mayoría de la información que está disponible es demasiado técnica y difícilmente accesible para quien no tenga ese background. Soy un voraz consumidor de información y no suelo achantarme ante los retos así que me he propuesto hacer una serie de posts relacionados con este mundo desde mi entendimiento del Big Data con los que compartir lo que he ido aprendiendo en el camino en un lenguaje que, espero, haga más accesible este mundo a otros marketers como yo.[/alert] De manera intuitiva el Big Data suele traer a la mente la imagen de la ingente cantidad de datos que somos capaces de generar a día de hoy, un volumen tan descomunal que hace tiempo que ha excedido las capacidades de almacenamiento y procesado de los sistemas tradicionales. Se trata, en mi opinión, de un buen punto de partida.
De todas las definiciones que he leído me gusta esta de Bernard Marr:
[well]»The Basic idea behind the phrase Big Data is that everything we do is increasingly leaving a digital trace (or data), which we can use and analyze to become smarter. The driving forces in this brave new world are access to ever-increasing volumes of data and our ever-increasing technological capability to mine that data for commercial insights»[/well]Sin embargo no sólo se trata sólo de la cantidad de información que generamos, la mayoría de las definiciones de Big Data que vais a encontrar coinciden en destacar algunos elementos comunes. Generalmente estos elementos se centran en las famosas V’s del Big Data
Velocidad
Que hace referencia al ritmo al que somos capaces de acumular información por unidad de tiempo. Según IBM un 90% de los datos que hay en el mundo se han creado en los dos últimos años.
Volumen
Hace referencia a la escala a la que somos capaces de acumular grande volúmenes de información (datos) comparado con las maneras tradicionales de guardar nuestros datos así como a la escalabilidad de dicha capacidad de almacenamiento. Se estima que sólo un 20% de los datos son generados por personas por lo que también implica la corriente de información (stream) de nuevas fuentes de datos como, por ejemplo, el mundo de los sensores del internet de las cosas (IoT).
Variedad
Se refiere a la gran diversidad de tipos de datos a los que podemos tener acceso, desde las clásicas tablas (estructurada) a otros tipos de datos que no están organizados de una determinada manera como imágenes, vídeos o tweets (desestructurada).
Veracidad
Esta V viene a destacar el reto que supone ser capaces de discernir en este océano de información a la que tenemos acceso cuál es fiable y veraz, cuál contiene errores, carece de ciertos valores o es directamente inexacta o falsa.
Valor
Cada vez más se oye hablar de esta V, el valor de los datos. La gran oportunidad de los datos está en nuestra capacidad para obtener valor de ellos. Esta característica, como yo la entiendo, está más en las capacidades para procesar los datos y obtener insights relevantes que tengan impacto en nuestro negocio bien detectando oportunidades, ocultas en los datos, soportando la toma de decisiones o bien ayudando a optimizar procesos y reducir costes.
¿Por qué se le da tanta importancia al Big Data?
Tradicionalmente el análisis de datos ha estado sujeto a ciertas limitaciones que han condicionado la manera en que los analistas de datos han hecho su trabajo. Según mi punto de vista las limitaciones principales han sido tres: la limitación de fuentes de información disponibles, las capacidades de procesado de los sistemas disponibles y el acceso a herramientas.
Cómo dice en su definición el Sr. Marr todas las interacciones del mundo digital, sean o no humanas, generan una traza. En los últimos años el crecimiento de los sistemas que dejan traza no ha dejado de crecer con la llegada del mundo de los sensores. Por poner un ejemplo cercano a nuestra realidad nuestros smartphones están generando una traza continua de nuestra ubicación a través del GPS del teléfono o, por poner otro ejemplo, nuestra conexión wifi está continuamente buscando Hotspots a los que conectarse generando otra traza más . Ambos son ejemplos de casos en los que sin necesidad de intervención humana se genera un intercambio de información que es trazable. El análisis de la traza de nuestro smartphone Android, por ejemplo, la usa Google para decirle a un anunciante si un usuario que interactuó con su campaña después visitó su tienda física. Esta y otras muchas fuentes de información se convierten, en muchos casos, en nuevas fuentes de datos que antes no existían o no eran facilmente accesibles.
Por otro lado, por muy potente que fuera la máquina con la que trabajase un analista siempre tenía una capacidad limitada, tanto por la cantidad de datos que puede guardar en el disco duro (almacenamiento) como por su capacidad de procesado, que limita tanto la cantidad de operaciones que puede hacer sobre los datos como el volumen de datos con los que puede operar simultáneamente.
Los sistemas de computación distribuida del mundo Big Data han acabado con esas limitaciones como explicaré más adelante cuando llegue el momento de hablar de Hadoop. Esta limitación ha hecho que la metodología de análisis habitual haya sido la de trabajar con un subconjunto de datos (muestra) y tratar de hacer inferencias sobre el total de la población mediante la aplicación de técnicas estadísticas. Según parece, hace tiempo que los analistas se dieron cuenta que más es siempre mejor, por lo que renunciar a parte de los datos es una limitación a la posibilidad de descubrir patrones y, por lo tanto, de obtener valor de los datos.
Por otro lado el acceso a los grandes sistemas de bases de datos tradicionales (Oracle, Teradata, SAP…) suponían una barrera de entrada a cualquiera que no pudiera hacer inversiones que sólo estaban al alcance de grandes corporaciones. De la misma forma las principales herramientas analíticas de carácter estadístico (SPSS, SAS…) tenían sistemas de licencias digamos poco accesibles. La llegada del mundo de capacidades de infraestructura, almacenamiento y procesamiento en modelos escalables y en un pago por servicio ha puesto la infraestructura necesaria a disposición de cualquiera y en un formato que escala según lo requiere el negocio.
Por otro lado el mundo del Open Source ha ofrecido a los analistas herramientas como R que no tienen nada que envidiar a las soluciones tradicionales y que, además, tienen detrás una comunidad de desarrolladores que contribuyen a evolucionar sus capacidades continuamente. R se ha convertido en el estándar con el que trabajan muchos cientificos de datos (Data Scientist) en la actualidad.
El conjunto de estas nuevas capacidades ha abierto todo un mundo de posibilidades para trabajar con datos, con grandes cantidades de datos. Muchas compañías están definiendo una parte importante de su propuesta de valor a través del análisis de estos datos y creando ventajas competitivas sustentadas en su capacidad de sacar valor de los mismos.
La información estructurada y no estructurada
Con la entrada de esta nuevas fuentes de información a disposición de los analistas se ha incrementado de manera espectacular el acceso a grandes volúmenes de datos que carecen de estructura definida. Generalmente cuando hablamos de datos el concepto de estructura se refiere a que los datos tengan una longitud y un formato definidos. Algunos ejemplos clásicos de datos estructurados son las fechas o las cadenas de caracteres (strings) que usamos por ejemplo para recoger un nombre de un usuario o su dirección de correo electrónico.
Según algunas fuentes el volumen de datos estructurados sólo supone un 20% de los datos disponibles por lo que la mayor parte de los datos ahí fuera son desestructurados. Por diferenciación con el estructurado el dato desestructurado es todo aquel dato que carece de un formato específico.
Es habitual hablar de un formato de datos que se encuentra a mitad de camino entre los datos estructurado y los desestructurados de ahí que reciba el nombre de semi-estructurados. Este tipo de datos son aquellos que no tienen un esquema fijo y definido pero que el formato utilizado es capaz de explicarse por si mismo y utiliza un sencillo sistema de pares etiqueta/valor. Casos comunes en el mundo digital serían el XML o el JSON. Para entenderlo espero que sirva este ejemplo superbásico de XML:
[well]<ficha><nombre>Gabriel</nombre>
<apellido>López</apellido>
<dirección>Calle La Salle #15</direccion>
</ficha>[/well]
La etiqueta nombre define el contexto para el valor Gabriel, y así sucesivamente para apellido y direccion. Todos ellos pertenecen a un entidad padre que es ficha
Como he dicho antes la información puede tener dos orígenes: humano o máquina. Una definición un tanto peculiar ya que se consideran humanos a los datos que se generan cuando los humanos interactuamos con una máquina. Por oposición se consideran datos generados por máquinas a aquellos datos que se generan por máquinas sin necesidad de intervención de un humano.
Algunos ejemplos de datos generados por máquinas son los logs de los servidores, los datos que emiten los sensores de todo tipo (RFID, GPS…) o la lectura de datos de un código de barras en un TPV. Ejemplos de datos generados por humanos podrían ser el click-stream que generamos con cada click de nuestros usuarios en nuestra página web o los datos que rellenamos en un formulario.
En el mundo de las bases de datos estructuradas el modelo que se ha venido utilizando desde los años 70, cuando lo creó un ingeniero de IBM llamado Edgar Codd, ha sido el de las Bases de Datos Relacionales.
Las Bases de Datos Relacionales
Las bases de datos tradicionales han trabajado siempre con datos estructurados que se alojaban en un formato de tablas. Cada tabla tenía un serie de registros (filas) y una serie campos (columnas) que recogen los diferentes atributos de cada registro. Generalmente los datos se guardaban en diferentes tablas y se establecían relaciones entre las tablas para poder combinar la información disponible en las distintas tablas, de ahí el nombre de base de datos relacional.
Las bases de datos relacionales tienen un esquema donde se representa la estructura de los datos que están alojados en ella. El esquema recoje la definición de las tablas, los campos que contienen y las relaciones entre ambas. La relación de las tablas se establece a través de las claves (Key) presentes en cada tabla. En la imagen siguiente El ID de País, por ejemplo, no sirve para vincular la tabla de países y la de provincias. Como se puede comprobar cada campo tiene definido un tipo de dato.
En los modelos relacionales los datos puedes ser accesibles para consultarlos, modificarlos o eliminarlos, para ello contamos con el lenguaje SQL (Structured Query Language). Escucharéis pronunciar SQL como SEQUEL (pronunciado algo parecido a sicuel), esto es una herencia del origen del SQL que inicialmente pretendió llamarse SEQUEL pero que, por conflictos por el registro de la marca, acabó siendo simplemente SQL, sin embargo la comunidad del mundo de la informática y los datos ha mantenido la pronunciación del nombre original.
En mi opinión todo marketer debería aprender a hacer consultas en SQL, esto es algo que está totalmente fuera de la ambición de esta serie pero hay un montón de recursos muy útiles disponibles por ahí para poder conocer los fundamentos básicos y practicar con datos reales. Un buen sitio por el que empezar es Mode, muy recomendable si te manejas bien con el inglés.
El SQL, por lo tanto, es el lenguaje que utilizamos para hacer consultas a la base de datos (queries). A modo de ejemplo sencillo veamos la siguiente sintaxis de la siguiente consulta SQL a una base de datos:
SELECT Name, Population / 1000000 AS PopMM FROM Country WHERE Population >= 1000000 ORDER BY Population DESC;
Como se puede observar la utilización de comandos muy cercanos al lenguaje natural facilita la comprensión de la consulta de manera intuitiva, la traducción podría ser: selecciona las columas Name y Population (a esta divídela entre un millón y renómbrala como PopMM) de la tabla Country pero sólo de aquellos casos en los que la población sea superior a un millón, ¡Ah! y ordéname los resultados en orden descendente por el campo Population.
Hay mucho más en el SQL de lo que muestra este pequeño ejemplo, SQL permite realizar consultas que puede crear nuevas tablas (CREATE), borrar actuales (DROP), insertar líneas en tablas existente (INSERT) y muchas más interacciones con la base de datos.
Quizá alguno se esté preguntando porque hablar del modelo relacional en un artículo dedicado al mundo de Big Data. En mi opinión hay dos motivos por los que deberías conocer las bases de datos relacionales, en primer lugar para entender cuáles son los cambios de la filosofía del mundo Big Data. En segundo lugar porque las Bases de Datos relacionales y el SQL van a seguir con nosotros por mucho tiempo. El mundo de la gestión de datos en modelos Big Data no va a sustituir, al menos a corto y medio plazo, las bases de datos relacionales, ambos mundos van a coexistir y trabajar en muchas ocasiones de la mano.
Uno de los principales problemas de las Bases de Datos Relacionales es que no escalan muy bien. Para empezar este modelo de bases de datos no fue concebido para manejar rangos de dimensiones que se miden en terabytes o incluso en Petabytes. No sólo no son muy eficientes a este nivel de información sino que además tienen una escala de costes que lo haría prohibitivo. Además a medida que incrementa la disparidad de datos (tablas) la estructura de tablas vinculadas por claves (ID’s) puede hacer que sea muy complejo mantener una estructura (esquema) eficiente lo que puede afectar al rendimiento de las consultas (el tiempo de respuesta o latencia) y la complejidad de las consultas, lo que incrementa la posibilidad de errores.
Hasta aquí el “capítulo” de hoy, espero que haya sido de vuestro interés y utilidad. Nos vemos pronto.
