Big Data

December 1, 2014

He tardado algún tiempo –quizás demasiado– en abordar el tema Big Data. Y es que no todos participamos en proyectos donde la cantidad de información sea tan grande como para tomar conciencia de esta realidad que se nos echa encima. Como he podido descubrir, no se trata solo de dotarse de los recursos necesarios para almacenar y procesar volúmenes enormes de información, sino que el mismo principio filosófico de causalidad se tambalea.

Datos masivos

Big Data implica un desplazamiento en la forma de estudiar los fenómenos: desde un enfoque basado en el muestreo estadístico, donde la precisión en la medición de cada elemento de la muestra es crucial para poder extrapolar los resultados fiablemente, y donde el muestreo debe cumplir ciertos requisitos para ser válido –p.ej. aleatoriedad, hacia uno basado en medir todos los elementos del dominio objeto de estudio, sin requerir tanta precisión en las medidas individuales.

Es decir, con Big Data, la muestra tiende a abarcar la población completa. Un ejemplo ilustrativo que leí de Mayer-Schonberger (2014)1 es el del servicio de traducción de Google: sus sistemas succionaron toda traducción que pudieron encontrar en Internet: páginas web corporativas, documentos oficiales, informes gubernamentales, libros del proyecto de escaneo de Google, etc, para calcular la probabilidad con que una palabra sigue a otra en cada idioma. En su fase inicial en 2006, el proyecto de traducción reunió 95 mil millones de frases en inglés –de dudosa calidad pues podían incluir erratas, errores ortográficos, etc. La razón por la que el sistema de traducción funciona bien no es por la brillantez de sus algoritmos, sino por haber alimentado al sistema con más datos, y no solo de alta calidad.

A pesar de la inherente tendencia de la humanidad a reunir cada vez más datos, este cambio solo se ha producido en los últimos diez años, y no antes, porque no se disponía del poder de computación suficiente ni de almacenes de datos de tan alta capacidad. En el momento en que escribo, 6000 nuevos tweets se “tuitean” cada segundo, unos 500 millones al día. Con los modelos apropiados, se puede extraer muchas conclusiones a partir de toda esta información. Como el famoso caso en que Google demostró anticiparse a los organismos sanitarios en la predicción de epidemias de gripe a partir de las búsquedas de sus usuarios.

Los ejemplos anteriores con comprensibles y de sentido común. Lo escalofriante es que se está obteniendo resultados absolutamente anti-intuitivos, que no dejan lugar a la búsqueda de causas y efectos, que no responden a por qués, sino que solo muestran los qués. La aplicación de multiples modelos matemáticos (p.ej. Google aplicó 500 millones en el caso de la gripe) al conjunto de datos puede encontrar correlaciones –lineales o no lineales– impensables.

P.ej. en un hospital infantil de EE.UU. se recabó información sobre las constantes vitales de los niños prematuros (a 25 medidas/segundo) y, habida suficiente información, las técnicas de Big Data concluyeron que la estabilización total en fases tempranas precedía a las peores complicaciones, como una calma antes de la tempestad. Todos los médicos pensaban que cualquier empeoramiento se vería reflejado en un deterioro anticipado de las constantes vitales, pero no era así.

Tecnología de almacenamiento

Como experto y estudioso de las bases de datos relacionales, concebidas por el Dr. Edgar F. Codd en 1970, no he podido quedar impasible ante el advenimiento de un modelo antagónico: el de las bases de datos no-relacionales, también denominadas noSQL, que han habilitado todo el potencial del Big Data.

¿Cuál es el problema ahora con las bases de datos relacionales? ¿por qué sustituirlas? ¿quién garantizará la consistencia e integridad de los datos? Estas son las preguntas que me hago y que intentaré responder.

Sistemas Relacionales

Las bases de datos relacionales ofrecen la mejor combinación de simplicidad, robustez, flexibilidad, rendimiento, escalabilidad y compatibilidad en el manejo de datos genéricos.

Pero para obtener todas estas ventajas, las bases de datos relacionales son muy complejas internamente2. Esta complejidad viene dada principalmente por el planificador de consulta también llamado optimizador, que debe evaluar en tiempo de ejecución la mejor forma de atender una consulta, para lo que debe considerar que:

  • las tablas se pueden juntar en diferente orden;
  • los predicados se pueden evaluar en diferente orden;
  • las subconsultas pueden o no transformarse en junta de tablas;
  • hay varios métodos para juntar tablas: bucles anidados (nested loops), hash, mezcla (merge), etc.
  • hay varios métodos para agregar los resultados: hashing, ordenación, etc.
  • hay varios algoritmos de escaneo: indexado, secuencial, etc.

El optimizador debe escoger el mejor plan en función del costo estimado, asumiendo que las operaciones de entrada/salida de disco dominan en el costo total. A su vez, para ello debe primero predecir el tamaño de los resultados intermedios usando métodos estadísticos3.

Pero para un número creciente de aplicaciones una de las características que debe ofrecer una base de datos ha eclipsado al resto en importancia: la escalabilidad. Estas aplicaciones se ejecutan en entornos de carga masiva y sus requerimientos de escalabilidad pueden crecer mucho y muy rápido. Y aquí es donde los sistemas relacionales tocan techo, pues no se han conseguido escalar a múltiples nodos de almacenamiento y/o procesamiento eficazmente.

noSQL (not only SQL)

Las bases de datos noSQL, denominadas genéricamente almacenes de clave/valor, han optimizado alguna de las características que se espera de una base de datos, relajando una o varias de las otras restricciones. P.ej:

  • sus modelos de datos no definen relaciones entre entidades de diferentes dominios y, por tanto, el sistema no debe hacer cumplir la integridad relacional;
  • los elementos de un dominio pueden tener diferentes esquemas, es decir, pueden tener conjuntos de atributos dinámicos;
  • no garantizan la consistencia absoluta de los datos en operaciones de lectura y escritura4;
  • permiten el almacenamiento en memoria principal, en lugar de en disco, mejorando el rendimiento;

Todo ello hace que los sistemas noSQL sean simples y puedan escalarse mucho más fácilmente, p.ej. en múltiples nodos de almacenamiento y procesamiento. Existe una bases de datos noSQL para cada tipo de información; las hay orientadas a: objetos, documentos, colecciones, columnas, grafos, conjuntos, filas, etc5.

Los modelos de datos relacionales difieren de los del código de aplicación, en especial en aplicaciones orientadas a objetos, donde era necesario código adicional para hacer la correspondencia entre ambos modelos. Con las bases de datos de clave/valor, el modelo de datos se corresponde de forma natural con el de la aplicación, lo cual tiene ventajas –simplicidad– y desventajas –la responsabilidad de asegurar la integridad de los datos recae en el código de la aplicación y, entonces, la base de datos deja de ser independiente de la aplicación.

Conclusión

Con la constante disminución en el precio de los recursos de almacenamiento, las empresas e instituciones tienen más excusas para mantener datos antiguos –incluso digitalizarlos, si no lo han hecho ya– que para borrarlos. Eventualmente, estos datos pueden demostrar ser de gran valor para su aplicación en los procesos de la organización.

Hasta mediados de la decada del 2000, las bases de datos relacionales eran casi la opción única y directa; con el buen compromiso que ofrece, seguirá siendo la mejor opción en muchos casos pero, por suerte, cada vez contamos con más bases de datos específicas para otras aplicaciones con requisitos excepcionales. P.ej. si quieres vasta escalabilidad bajo demanda, necesitas una base de datos noSQL.


  1. Mayer-Schonberger, Viktor et al (2014) Big Data: A Revolution That Will Transform How We Live, Work, and Think. Mariner Books. 

  2. http://readwrite.com/2009/02/12/is-the-relational-database-doomed 

  3. http://www.neilconway.org/talks/optimizer/optimizer.pdf 

  4. P.ej. en el modelo de consistencia eventual, después de cambiar un atributo de un elemento, esos cambios no se reflejan en operaciones de lectura posteriores de inmediato. 

  5. http://nosql-databases.org/ 

Archivos