La ciencia intensiva en datos necesita de herramientas, métodos y personal con miras analíticas para explotar convenientemente Big Data. A lo largo de las próximas semanas analizaremos las Vs que caracterizan a Big Data así como su valor e impacto para las Unidades de Información
A los largo de las ultimas semanas hemos ido revisando, mas bien comentando algunas ideas sin ser demasiado exhaustivo, las distintas dimensiones de Big Data, es decir las Vs, que se encuentran por doquier en la literatura, blogs y recortes de prensa: Volumen (parte 1), Variedad (parte 2) y Velocidad (parte 3).
A parte de estas tres archi-conocidas Vs, incluimos más Vs que a nuestro parecer son igualmente relevante para entender el alcance y complejidad de Big Data: Validez y Veracidad (parte 4), Valor (parte 5), y Visualización (parte 6).
Podríamos haber seguido con vulnerabilidad, etc. hasta agotar todas las palabras con Vs que se nos ocurriesen pero creamos que no es necesario. ¿Cogéis la idea, no? El tamaño no es tan importante como nos vende y nos pregona continuamente la industria y prensa especializada, que ha abusado excesivamente del término Big Data.
Cerramos esta serie con la presente entrada a modo de conclusión personal. A continuación anotamos algunas frases resumen en cuanto a las "verdades" (otra v!) de Big Data y algunos comentarios aplicados al caso particular de las unidades de información.
- Los datos son fundamentales, ya sean big o small, pero secundarios. La pregunta a resolver es lo realmente prioritario. Debe existir un objetivo o problema bien definido para emprender un proyecto de este tipo. Luego, la ciencia en Data Science es lo primario, y no lo datos.
- La inmensa mayoría de los proyectos a día de hoy no son Big Data. Se pueden resolver con la tecnología que ya existía antes del fenómeno Big Data. Esto no impide que se emplee tecnología como Hadoop para montar por ejemplo un cluster para computación en paralelo aunque la solución requerida fuera mucha más sencilla. Por la tanto, el uso de Hadoop (u otra tecnología relacionado con Big Data) no es condición suficiente para presumir de tener en marcha un proyecto Big Data.
- Se tiene entre manos un proyecto de Big Data cuando cumple algunas (o incluso todas) de las tres primeras Vs: volumen descomunal de datos, variedad exponencial de datos, o velocidad incesante de entrada de datos. ¿Se encuentran las unidades de información y bibliotecas en un escenario que requiera computación en paralelo para atender a millones de usuarios? Puede que existan algunos casos en centros internacionales pero en territorio español decididamente no. Un estudio reciente muestra las carencias de la bibliotecas españolas en cuanto por ejemplo presencia web o disponibilidad de catálogos en línea, no hablemos pues de proyectos de Big Data. ¿Y en el futuro? Pues depende totalmente de la naturaleza de los futuros problemas que las bibliotecas tenga que acarar en el futuro. Si se convirtiesen en gestores de los datos generados en proyectos de investigación, por ejemplo, la cosa cambiaría radicalmente porque en ese escenario o bien el volumen, variedad o velocidad de entrada de datos a escalas exponenciales sería más que probable.
- Resulta mucho más interesante definir el equipo de un proyecto Big Data que el término en sí. Como hemos recalcado en la serie de entradas, el factor humano es decisivo para el éxito de un proyecto de este tipo. La tecnología es importante, pero ella sola no te salvará de la quema si no hay equipo. Definir un equipo con competencias complementarias que cubra todas las necesidad de un proyecto de Big Data es primordial pero nadie parece importarle. ¿Que alguien me diga si alguna biblioteca o unidad de información española tiene un estadístico, matemático, informático, o experto en visualización y comunicación de los datos entre su personal o colaborando con personal de la biblioteca?
No hay comentarios:
Publicar un comentario