Archivo de la etiqueta: deusto

Paradigma batch para sistemas Big Data (I)

(venimos de un artículo introductorio a los tres paradigmas)

Cuando hablamos del verdadero momento en el que podemos considerar nace esta «era del Big Data», comentamos que se puede considerar el desarrollo de MapReduce y Hadoop como las primeras «tecnologías Big Data». Estas tecnologías se centraban en un enfoque de Batch Processing. Es decir, el objetivo era acumular todos los datos que se pudieran, procesarlos y producir resultados que se «empaquetaban» por lotes.

Con este enfoque, Hadoop ha sido la herramienta más empleada. Es una herramienta realmente buena para almacenar enormes cantidades de datos y luego poder escalarlos horizontalmente mientras vamos añadiendo nodos en nuestro clúster de máquinas.

Big Data Batch Processing (Fuente: http://www.datasciencecentral.com/profiles/blogs/batch-vs-real-time-data-processing)
Big Data Batch Processing (Fuente: http://www.datasciencecentral.com/profiles/blogs/batch-vs-real-time-data-processing)

Como se puede apreciar en la imagen, el «problema» que aparece en este enfoque es que el retraso en tiempo que introduce disponer de un ETL que carga los datos para su procesamiento, no será tan ágil como hacerlo de manera continua con un enfoque de tiempo real. El procesamiento en trabajos batch de Hadoop MapReduce es el que domina en este enfoque. Y lo hace, apoyándose en todo momento de un ETL, de los que ya hablamos en este blog.

Hasta la fecha la gran mayoría de las organizaciones han empleado este paradigma «Batch». No era necesaria mayor sofisticación. Sin embargo, como ya comentamos anteriormente, existen exigencias mayores. Los datos, en muchas ocasiones, deben ser procesados en tiempo real, permitiendo así a la organización tomar decisiones inmediatamente. Esas organizaciones en las que la diferencia entre segundos y minutos sí es crítica.

Hadoop, en los últimos tiempos, es consciente de «esta economía de tiempo real» en la que nos hemos instalado. Por ello, ha mejorado bastante su capacidad de gestión. Sin embargo, todavía es considerado por muchos una solución demasiado rígida para algunas funciones. Por ello, hoy en día, «solo» es considerado el ideal en casos como:

  • No necesita un cálculo con una periodicidad alta (una vez al día, una vez al de X horas, etc.)
  • Cálculos que se deban ejecutar solo a final de mes (facturas de una gran organización, asientos contables, arqueos de caja, etc.)
  • Generación de informes con una periodicidad baja.
  • etc.

Como el tema no es tan sencillo como en un artículo de este tipo podamos describir, en los últimos años han nacido una serie de herramientas y tecnologías alrededor de Hadoop para ayudar en esa tarea de analizar grandes cantidades de datos. Para analizar las mismas -a pesar de que cada una de ellas da para un artículo por sí sola-, lo descomponemos en las cuatro etapas de la cadena de valor de un proyecto de Big Data:

1) Ingesta de datos

Destacan tecnologías como:

  • Flume: recolectar, agregar y mover grandes cantidades de datos desde diferentes fuentes a un data store centralizado.
  • Comandos HDFS: utilizar los comandos propios de HDFS para trabajar con los datos gestionados en el ecosistema de Hadoop.
  • Sqoop: permitir la transferencia de información entre Hadoop y los grandes almacenes de datos estructurados (MySQL, PostgreSQL, Oracle, SQL Server, DB2, etc.)

2) Procesamiento de datos 

Destacan tecnologías como:

  • MapReduce: del que ya hablamos, así que no me extiendo.
  • Hive: framework creado originalmente por Facebook para trabajar con el sistemas de ficheros distribuidos de Hadoop (HDFS). El objetivo no era otro que facilitar el trabajo, dado que a través de sus querys SQL (HiveQL) podemos lanzar consultas que luego se traducen a trabajos MapReduce. Dado que trabajar con este último resultaba laborioso, surgió como una forma de facilitar dicha labor.
  • Pig: herramienta que facilta el análisis de grandes volúmenes de datos a través de un lenguaje de alto nivel. Su estructura permite la paralelización, que hace aún más eficiente el procesamiento de volúmenes de datos, así como la infraestructura necesaria para ello.
  • Cascading: crear y ejecutar flujos de trabajo de procesamiento de datos en clústeres Hadoop usando cualquier lenguaje basado en JVM (la máquina virtual de Java). De nuevo, el objetivo es quitar la complejidad de trabajar con MapReduce y sus trabajos. Es muy empleado en entornos complejos como la bioinformática, algoritmos de Machine Learning, análisis predictivo, Web Mining y herramientas ETL.
  • Spark: facilita enormemente el desarrollo de programas de uso masivo de datos. Creado en la Universidad de Berkeley, ha sido considerado el primer software de código abierto que hace la programación distribuida accesible y más fácil para «más públicos» que los muy especializados. De nuevo, aporta facilidad frente a MapReduce.

3) Almacenamiento de datos

Destacan tecnologías como:

  • HDFS: sistema de archivos de un cluster Hadoop que funciona de manera más eficiente con un número reducido de archivos de datos de gran volumen, que con una cantidad superior de archivos de datos más pequeños.
  • HBase: permite manejar todos los datos y tenerlos distribuidos a través de lo que denominan regiones, una partición tipo Nodo de Hadoop que se guarda en un servidor. La región aleatoria en la que se guardan los datos de una tabla es decidida, dándole un tamaño fijo a partir del cual la tabla debe distribuirse a través de las regiones. Aporta, así, eficiencia en el trabajo de almacenamiento de datos.

4) Servicio de datos

En esta última etapa, en realidad, no es que destaque una tecnología o herramienta, sino que destacaría el «para qué» se ha hecho todo lo anterior. Es decir, qué podemos ofrecer/servir una vez que los datos han sido procesados y puestos a disposición del proyecto de Big Data.

Seguiremos esta serie hablando del enfoque de «tiempo real», y haciendo una comparación con los resultados que ofrece este paradigma «batch».

Procesando «Big Data»: paradigmas batch, tiempo real y Lambda

Lo que podemos llamar como la cadena de valor de un proyecto Big Data consiste básicamente en recopilar/integrar/ingestar, procesar, almacenar y servir grandes volúmenes de datos. Eso es, en esencia, lo que hacemos en un proyecto de BIg Data. Para ejecutar esas funciones, como hemos comentado en este blog en varias ocasiones, tenemos una serie de tecnologías, que suelen ser citadas en ocasiones en relación a la función que ejercen. Es lo que aprendemos en nuestro módulo M2.2 del Programa de Big Data y Business Intelligence de nuestra universidad.

Dado el interés que está despertando en los últimos años la parte «procesamiento» (debido fundamentalmente a cómo se origina esto del Big Data) es interesante hablar de las diferentes alternativas tecnológicas que existen para procesar «Big Data». Ya saben, datos que se disponen en grandes volúmenes, que se generan a gran velocidad y con una amplitud de formatos importante.

Esta etapa de la cadena de valor es la responsable de recoger los datos brutos y convertirlos/transformarlos a datos enriquecidos que pueden dar respuesta a la pregunta que nos estamos haciendo. Y para enfrentar esta etapa, en los últimos años, se han desarrollado dos paradigmas fundamentales:

  • Paradigma «Batch Processing«: son procesos que se asientan fundamentalmente en el paradigma MapReduce, que ya explicamos en un artículo anterior, y que decíamos, permitió comenzar esta apasionante carrera alrededor del Big Data. Siguen el modelo «batch» que tan importante resultó en el mundo de la informática original: se ejecutan de manera periódica y trabajan con grandísimos volúmenes de datos.
    Existen varias alternativas para proveer de estos servicios: la más importante es Hadoop MapReduce, que funciona dentro del framework de aplicaciones de Hadoop. Se apoya en el planificador YARN. Dado el bajo nivel con el que trabajan estas tecnologías, estos últimos años han nacido soluciones de más alto nivel para ejecutar estas tareas, tales como Apache Pig.
    Estamos hablando de tecnologías que funcionan realmente bien con grandes cantidades de datos. Sin embargo, los procesos de Map y Reduce pueden ser algo lentos cuando estamos hablando de cantidades realmente «BIG», dado que escriben en disco entre las diferentes fases. Por ello, como siempre, se produce una evolución natural, y aparecen tecnologías que resuelven este problema, entre las que destaca Apache Spark.
    Haremos un artículo separado, dada su importancia, para hablar exclusivamente y en detalle de este paradigma «Batch Processing«.
  • Paradigma «Streaming Processing«: a diferencia del enfoque «batch» anterior, el «streaming», como su propio concepto describe, funciona en tiempo real. Si antes decíamos que un proyecto «Big Data» consta de cuatro etapas –(1) Ingestión; (2) Procesamiento; (3) Almacenamiento y (4) Servicio-, con este enfoque, nada más ser «ingestados», son transferidos a su procesamiento. Esto, además, se hace de manera continua. En lugar de tener que procesar «grandes cantidades», son, en todo momento, procesadas «pequeñas cantidades».
    Como con el enfoque batch, hay una serie de tecnologías que permiten hacer esto. Se pueden clasificar en dos familias: 1) Full-streaming: Apache Storm, Apache Samza y Apache Flink; y 2) Microbatch: Spark Streaming y Storm Trident.
    Son tecnologías que procesan datos en cuestión de mili o nanosegundos. Se diferencian entre ellas por las garantías que aportan ante fallos en la red o en los sistemas de información. La siguiente tabla resume muy bien estas diferencias. Por lo tanto, más que por «gustos», la diferencia puede radicar en cuanto a su «sistema de garantías»:

    Fuente: http://madrid.bigdataweek.com/2015/11/18/tecnologias-en-el-mundo-del-big-data/
    Fuente: http://madrid.bigdataweek.com/2015/11/18/tecnologias-en-el-mundo-del-big-data/

    Haremos un artículo separado, dada su importancia, para hablar exclusivamente y en detalle de este paradigma «Streaming Processing«.

A estos dos, podemos añadir la arquitectura Lambda, la más reciente en llegar a este mundo de necesidades en evolución de las diferentes alternativas de procesar datos. Provee parte de solución Batch y parte de solución en Tiempo Real. Como su propio creador Nathan Marz explica aquí:

The lambda architecture solves the problem of computing arbitrary functions on arbitrary data in real time by decomposing the problem into three layers: the batch layer, the serving layer, and the speed layer.

Estamos hablando de diferentes paradigmas; esto es, de diferentes maneras de afrontar el problema. Y dada la importancia de cada uno de ellos, he considerado interesante hacer un artículo monográfico de cada una de ellas. Paradigmas que nos van a ayudar a procesar las grandes cantidades de datos de un proyecto de Big Data. Y conocer y empezar a dominar así las tecnologías que disponemos para cada paradigma.

Cuándo empieza esta era del Big Data: MapReduce

Comentábamos en un artículo anterior, que fue allá por 2012 cuando se empieza a popularizar el término Big Data en el acervo popular. Pero eso no quiere decir, que sea entonces cuando podamos decir que comienza esta era del Big Data. De hecho, los orígenes son bastante anteriores.

Dos ingenieros de Google, Jeffrey Dean y Sanjay Ghemawat, allá por 2004, publican un artículo titulado «MapReduce: Simplified Data Processing on Large Clusters«.

Dean Ghemawat

Hablan de un nuevo modelo de programación que permite simplificar el procesamiento de grandes volúmenes de datos. Lo bautizan como MapReduce. Básicamente es la evolución natural y necesaria que tenían dentro de Google para procesar los grandes volúmenes de datos que ya por aquel entonces manejaban (documentos, referencias web, páginas, etc.). Lo necesitaban, porque a partir de toda esa información, sacaban una serie de métricas que luego les ayudó a popularizar industrias como el SEO y SEM. Vamos, de lo que hoy en día vive Google (Alphabet) y lo que le ha permitido ser la empresa de mayor valor bursátil del mundo.

La idea que subyace a este nuevo modelo de programación es el siguiente: ante la necesidad de procesar grandes volúmenes de datos, se puede montra un esquema en paralelo de computación que permita así distribuir el trabajo (el procesamiento de datos) entre diferentes máquinas (nodos dentro de una red) para que se pueda reducir el tiempo total de procesamiento. Es decir, una versión moderna del «divide y vencerás«, que hace que ese trabajo menor en paralelo, reduzca sustantivamente lo que de otra manera sería un único, pero GRAN trabajo.

Distribución de trabajo a través del modelo MapReduce (Fuente: http://www.admin-magazine.com/HPC/Articles/MapReduce-and-Hadoop)
Distribución de trabajo a través del modelo MapReduce (Fuente: http://www.admin-magazine.com/HPC/Articles/MapReduce-and-Hadoop)

En aquel entonces, estos grandes «visionarios del Big Data» (luego volvemos a ello), se dieron cuenta que este problema que tenía Google en esos momentos, lo iban a tener otras cuantas aplicaciones. Así que decidieron desarrollar un modelo de programación que se desacoplara de las necesidades concretas de Google, y se pudiera generalizar a un conjunto de aplicaciones que pudieran luego reutilizarlo. Pensaron en un inicio a todos los problemas que pudiera tener el propio buscador. Pero se dan cuenta que quizás todavía hay un universo más amplio de problemas, por lo que se abtsrae y generaliza aún más.

De hecho, lo simplificaron tanto que dejaron la preocupación del programador en dos funciones:

  • Map: transforma un conjunto de datos de partida en pares (clave, valor) a otro conjunto de datos intermedios también en pares (clave, valor). Un formato, que hará más eficiente su procesamiento y sobre todo, más fácil su «reconstruccón» futura.
  • Reduce: recibe los valores intermedios procesados en formato de pares (clave, valor) para agruparlos y producir el resultado final.

Este paradigma lo adoptó Google allá por 2004. Y dado el rendimiento que tenía, se comenzó a emplear en otras aplicaciones (como decíamos ahora). Se comienzan luego a desarrollar versiones de código abierto en frameworks. Esto hace muy fácil su rápida adopción, y quizás deja una lección para la historia sobre cómo desarrollar rápidamente un paradigma.

Uno de los frameworks que comienza a ganar en popularidad es Apache Hadoop. Y, para muchos, aquí nace esta era del «Big Data». El creador del framework Hadoop se llama «Doug» Cutting, una persona con una visión espectacular. En cuanto leyó la publicación de Dean y Ghemawat se dio cuenta que si crease una herramienta bajo el paradigma MapReduce, ayudaría a muchos a procesar grandes cantidades de datos. Cutting acabó luego trabajando en Yahoo!, que es donde realmente empujó el proyecto Hadoop (qué vueltas da la vida…).

El ecosistema Hadoop consta de una serie de módulos como los que se pueden encontrar en la imagen debajo de estas líneas. Pero en su día, fueron dos sus principales componentes, y los que dan otro nuevo empuje a esta era del Big Data:

  • HDFS: una implementación open-source de un sistema distribuido de ficheros (que ya había descrito Google en realidad).
  • MapReduce: utilizando HDFS como soporte, la implementación del modelo de programación que hemos descrito al comienzo.
Ecosistema Apache Hadoop (Fuente: https://opensource.com/sites/default/files/resize/styles/image-full-size/public/images/life-uploads/hadoop-EcoSys_yarn-640x418.PNG)
Ecosistema Apache Hadoop (Fuente: https://opensource.com/sites/default/files/resize/styles/image-full-size/public/images/life-uploads/hadoop-EcoSys_yarn-640×418.PNG)

La historia sobre el origen y verdadero impulso a esta era del «Big Data», puede cerrarse con la salida de Yahoo! de Cutting en 2009. Se incorpora a Cloudera, empresa que comienza a dar servicio, soporte y formación de Hadoop a otras empresas. Para esa fecha, Hadoop ya era un ecosistema de módulos y aplicaciones, que merecen cada una un hilo aparte para entender las grandes aportaciones que hicieron las personas que hemos comentado en este artículo. Por cierto, mucha de esta historia la cuenta el propio Cutting en este hilo de Quora.

En definitiva, primero MapReduce, y luego el framework Hadoop, pueden ser considerados como el origen de esta era Big Data de la que tanto hablamos hoy en día. Y, las empresas de Internet (Google, Yahoo, hablaremos luego de Twitter, Facebook, Linkedin, etc.), las que propician la aparición de tecnologías de Big Data que luego son llevadas a otros sectores.

El abuso de la palabra «Big Data»

Es innegable que la palabra «Big Data» lleva ya tiempo con nosotros y está de moda. Su uso no ha parado de crecer desde mediados de 2012, que es cuando aparecen varios artículos que comienzan a popularizar el paradigma.

 

Es tanto su uso, que ha dado un salto desde los foros más tecnológicos a los más populares. Son varios periódicos generalistas que se atreven a encabezar sus noticias con titulares como éstos:

Fuente: http://economia.elpais.com/economia/2016/06/30/actualidad/1467300223_055396.html
Fuente: http://economia.elpais.com/economia/2016/06/30/actualidad/1467300223_055396.html
Fuente: http://www.elmundo.es/economia/2016/06/07/57569c8722601d712e8b45ab.html
Fuente: http://www.elmundo.es/economia/2016/06/07/57569c8722601d712e8b45ab.html
Fuente: http://www.expansion.com/juridico/actualidad-tendencias/2016/06/05/5751c298268e3ea50d8b4660.html
Fuente: http://www.expansion.com/juridico/actualidad-tendencias/2016/06/05/5751c298268e3ea50d8b4660.html

Este tipo de titulares, ha provocado que ahora todo el mundo diga que «hace Big Data» o que todos los problemas de una empresa «se arreglen haciendo Big Data«. Ojo, no con esto se debe quitar valor a lo que hacen. Lo que ocurre, es que quizás no estén poniendo en valor el paradigma del Big Data. Sino que puede que estén haciendo un proyecto de Data Mining o Minería de datos de toda la vida. Pero de eso, no se habla en las noticias. En la siguiente gráfica de Google Trends podéis ver cómo para la categoría de «Noticias», últimamente se cita mucho «Big Data», pero bastante menos «Data Mining» o «Minería de Datos».

Creo que debiéramos empezar a ser un poco más rigurosos en su uso. Es decir, debiéramos empezar a preguntarnos si es «Big Data» todo lo que decimos que lo es. Y es que sino a este paso, ocurrirá como ya pasó con términos como «calidad» o «innovación«, que de tanto uso, ahora la gente se muestra reacia al valor que aportan disponer de importantes equipos de calidad e innovación.

Y es que el uso de los métodos de análisis de datos para la mejora de la competitividad y el día a día de las organizaciones no es nada nuevo. Hace décadas que llevamos haciendo uso de estas técnicas. Quizás no en todos los sectores (lo que ahora sí podemos decir está ocurriendo). Pero en el sector financiero o asegurador, llevan décadas empleando técnicas de minería de datos para sacar valor de sus grandes volúmenes de datos. Lo han empleado siempre para la detección de fraudes, perfiles de propensión al impago o para el scoring en la concesión de créditos.

Sí que es cierto que estos métodos, ahora son más sofisticados. Pero eso realmente no se debe a la evolución de los algoritmos solo, sino a la existencia de una mayor cantidad de datos, de muy diferentes fuentes, almacenados en muy diferentes formatos y sobre todo, generados a gran velocidad. Y esto último sí que hace distinguir un proyecto de Big Data de otro que no lo es.

Lo que ocurre en un momento determinado en el tiempo es que se empieza a popularizar el término «Big Data» cuando otro tipo de empresas no financieras ni aseguradoras, especialmente las grandes tecnológicas, comienzan a aplicar esas técnicas de minería de datos. Pero se dan cuenta que muchas de las técnicas que se venían empleando no son válidas. Básicamente por:

  • El gran volumen de datos que disponen
  • La gran variedad de formatos de datos
  • La velocidad a la que generan nuevos datos

Sí, estamos hablando de las famosas 3 «V» que se concibieron inicialmente, que son las 3 (por mucho que ahora haya una burbuja de «V») que creo siguen caracterizando y definiendo mejor a este paradigma del «Big Data». Volumen, Variedad y Velocidad. Y son estas 3 «V», las que hace que nos demos cuenta que lo que veníamos haciendo hasta la fecha no es válido. Se necesitan nuevas tecnologías. Y se desarrollan varias nuevas tecnologías que hacen más fácil tan ardua labor, especialmente el modelo MapReduce y los sistemas de ficheros distribuidos. Y, el trabajo que anteriormente era imposible o muy difícil hacerlo, ahora se hace posible gracias a un conjunto de máquinas (clústers) que se distribuyen el trabajo, y que en agregado, superan a cada máquina que anteriormente existía.

Por todo ello, creo que es compartido por todos afirmar que no todas las empresas que hagan uso de técnicas de minería de datos están haciendo uso del Big Data. Como paradigma que es, existen una seria de condicionantes del problema que lo hacen singular y diferente.  Y por ello, es importante dejar claro que, por favor, no usemos el término allí donde no aplique. Y aplica, en aquellos contextos que se rigen por ese paradigma de las 3 «V» que caracterizan muy bien los retos que tienen muchas empresas por delante.

El Big Data en los Papeles de Panamá (con Mar Cabra)

Nada más hacerse público el caso de los Papeles de Panamá, escribimos un artículo en este blog para describir cómo el paradigma del Big Data (con sus método de trabajo del dato, sus tecnologías, su aproximación al dato, etc.) había jugado un papel fundamental para ser clave y posibilitar el procesamiento de la mayor filtración de la historia del periodismo (2.6 terabytes, y 11,5 millones de documentos -Wikileaks, para que se hagan a la idea, fueron 1,7 GB “solo”-).

Dado que hemos empezado ya nuestra actividad para el próximo lanzamiento en Otoño de nuestro Programa de Big Data y Business Intelligence en nuestra sede de Donostia – San Sebastián, quisimos organizar una jornada en la que pudiéramos contar con una de las principales protagonistas de dicha investigación. Mar Cabra, que ha desarrollado su carrera alrededor del periodismo de datos y la transparencia, y que ha formado parte del International Consortium of Investigative Journalists que ha estado detrás de la investigación sobre este escándalo social y moral.

Os dejo, lo primero, su presentación, que resumo a continuación:

La verdad es que Mar señaló muchos de los puntos críticos que trabajamos en nuestros Programas de Big Data y Business Intelligence:

  • Tuvieron muchos problemas con la calidad de los datos. Estaban muy «sucios», y dedicaron gran cantidad del tiempo a ponerlos limpios y eficientes para su procesamiento.
  • Nos introdujo las tecnologías que han estado detrás de la investigación y cómo han jugado un papel totalmente determinante para que fuera un éxito el proyecto. En esta entrada ya detallamos todas las tecnologías, pero por resumir las más determinantes, Mar nos habló de Talend como ETL, NEO4J para almacenamiento y Linkurious para la representación visual. Su expresividad y las facilidades para el descubrimiento de conocimiento, fueron aspectos críticos.
  • Entre los 11,5 millones de documentos de la filtración, prácticamente 5 millones eran emails, 3 millones formatos de bases de datos, 2.1 millones PDFs, 1.1 millones eran imágenes y el resto, otro tipo de documentos. Como vemos, el grado de no-estructuración de la información y los datos era tan alto, que la importancia de las tecnologías que facilitan el procesamiento de datos no estructurados, ha sido de vital importancia.
  • Nos habló mucho sobre cómo la visualización resulta crítica para que la gente luego entienda el conocimiento hallado de una manera bastante resumida y ágil. En la visualización que han realizado en colaboración con The Guardian, destacó The Power Players, que podéis consultar aquí.
  • No solo se trata de la mayor filtración de la historia del periodismo, sino también de la mayor colaboración de la historia del periodismo. La importancia que ha tenido el haber compartido datos dentro del marco de un consorcio, trabajando con una tecnología de red social abierta, ha sido crítica. Se han evitado los silos de datos, clave para que se pudieran compartir los documentos del despacho Mossack Fonseca.
  • Las tecnologías de bases de datos de grafos les han permitido una navegación por la información tan eficiente, que han sido capaces de procesar en meses lo que de otra manera les hubiera llevado años. De esto ya hablamos en una entrada anterior. Ella lo llamó «magia» destacando lo siguiente (literal):
    • Hago clicks en “puntos” y encuentro historias!
    • Descubro nuevos nombres con las búsquedas fuzzy
    • Encuentra el camino más corto (shortest path)
  • Si a alguien le interesa, y quiere adentrarse en la base de datos de grafos generada y estructurada para modelizar los Papeles de Panamá, puede acceder aquí. Un ejercicio de transparencia y colaboración al que Mar no paraba de invitarnos.

Para terminar, os dejo los vídeos de su intervención completa, así como la entrevista que la hicimos (que resume los puntos comentados anteriormente). Un caso, como ven, el de los Papeles de Panamá, en el que el Big Data ha aportado a la sociedad mucho.


Bayes y la inteligencia colectiva para predecir sucesos (fútbol, catástrofes aéreas, política, etc.)

Kenneth Arrow, premio Nobel de Economía en 1972, y experto en predicciones económicas dijo aquello de:

“El buen pronóstico no es el que te dice que lloverá, sino el que te da las probabilidades”.

Esto es algo que suelo comentar a la hora de hablar de predicciones. No tienen más que abrir muchos titulares de periódicos para darse cuenta que la ausencia de la estimación de probabilidades es palpable. Y eso a pesar que nada es seguro hasta que ocurre y que la probabilidad cero no existe. La certeza y la magia debieran quedar excluidas de nuestra  manera de ver el mundo.

Por todo ello, quiero hablar hoy de cómo poder manejarnos en este mundo de la incertidumbre, asignando probabilidades a las diferentes alternativas que puede tomar un determinado suceso. De esta manera, podremos ayudar a las empresas, organizaciones e individuos a asignar eficientemente recursos en múltiples situaciones. Y, como solemos decir en el mundo del Big Data, tomar mejores decisiones.

Predecir consta de tres partes:

  1. Modelos dinámicos
  2. Análisis de datos
  3. Juicio humano

En el mundo de las predicciones, las empresas han solido llevar la delantera. Básicamente, porque trabajan en mercados. Los economistas suelen decir que los mercados proporcionan 1) incentivos para buscar información; 2) incentivos a revelar la información; y 3) un mecanismo para agregar información dispersa. Por eso solemos tener todos un amigo empresario al que solemos preguntarle por el desenlace de  muchas cuestiones que nos pueden afectar.

Primero, hablemos de probabilidades. Supongamos que estamos con un amigo intentando predecir la cara que saldrá al tirar la moneda al aire. Intuitivamente, todos nosotros podemos pensar que la probabilidad de que salga cara es de 0,5. Y que incluso esto es un concepto «absoluto», en el sentido que todos deberíamos pensar lo mismo. Esto es lo que se denomina una interpretación frecuentista de la probabilidad, y es la que ha sido predominante a lo largo del Siglo XX, con Ronald A. Fisher a la cabeza.

Sin embargo, hay otro enfoque, algo más antiguo. Y es una en la que ese 0,5 se le da un carácter subjetivo, dado que un jugador puede esperar una mayor o menor probabilidad. Este enfoque fue mayoritario en el Siglo XIX, con Pierre-Simon Laplace al frente. Y esta subjetividad en la interpretación de la probabilidad se la debemos al Teorema de Bayes. Dado que en muchas ocasiones, para predecir, tenemos un conocimiento limitado, la probabilidad es la expresión matemática de ese conocimiento. Es decir, que yo «no puedo predecir con un 50% de probabilidades que saldrá cara«, sino que diría «basándome en el conocimiento que tengo, hay un 50% de  certeza que saldrá cara«.

El auge de los métodos Bayesianos, especialmente, por la irrupción del Big Data (que trae nuevo conocimiento), está provocando que mucha gente cambie la forma de afrontar estos problemas, dado que Bayes no solo es una fórmula, sino también una manera de afrontar predicciones y situaciones. Consiste en que a nueva información (recibida), nueva probabilidad (estimada). Según vaya obteniendo nueva información, mejoro las probabilidades iniciales que tengo. A más información, más probabilidad puedo estimar. De ahí la relación con el Big Data, claro.

Ha habido casos muy «populares» de la aplicación del teorema de Bayes en los últimos tiempos: la búsqueda del avión perdido de Malaysia Airlines y las probabilidades de su ubicación, la localización del vuelo de Air France que cayó en el Atlántico tras dos años gracias a Bayes (explicado en este paper), o cómo iba a quedar el España – Italia durante el propio partido de la Eurocopa (como dijimos, el fútbol usa mucho esta información).

Probabilidades de encontrar los restos del vuelo de Air France (Fuente: https://www.technologyreview.com/i/images/AF447.png?sw=590)
Probabilidades de encontrar los restos del vuelo de Air France (Fuente: https://www.technologyreview.com/i/images/AF447.png?sw=590)

Uno de los campos donde más interés puede tener ahora mismo Bayes es en de la aplicación de la inteligencia colectiva para predecir sucesos. Cuando la predicción de un resultado/suceso se vuelve compleja, el enfoque de la «inteligencia colectiva» sugiere agregar información dispersa y heterogénea. En ese proceso de agregación, quitamos el «ruido», dado que todo paquete de información se compone de una parte veraz (señal) y de ruido (aleatorio) -la Teoría de la Información de Shannon de 1948-.

Así, de esta agregación de predicciones subjetivas de una realidad, nace un nuevo «mercado de predicciones». Algunos autores prefieren llamarlos “mercados de información”, dado que reflejan una mejora de la información disponible gracias a la «sabiduría de las masas». Otros los llaman “mercados de futuros de ideas” o “mercados de decisiones”, reseñando así el valor que tiene.

Estos mercados se basan en la teoría de la “sabiduría de las masas”. Esta, fue descubierta en 1906 por el estadístico Francis Galton (que también bautizó conceptos como la correlación o la regresión a la media). Su tesis fue aparentemente sencilla: la predicción de un grupo de personas expresada como un todo, mejora la precisión de cualquiera de sus partes por separado. En el libro «The Wisdom of Crowds» de James Suroweicki, en 2004, esta teoría fue impulsada de nuevo, gracias a sus postulados sobre cuándo esta puede funcionar y cuándo no. James, expone que existen tres tipos de problemas que pueden ser resueltos por la inteligencia colectiva:

  1. Problemas cognitivos (siempre tienen una solución, o, en su defecto, hay unas respuestas mejores que otras);
  2. Problemas de coordinación (los miembros de un grupo se ven en la necesidad de armonizar su comportamiento con el del resto de la gente);
  3. Problemas de cooperación (personas que buscan satisfacer el propio interés se ven en la necesidad de lidiar con los demás para obtener una solución que sea buena para todos).

A nivel estadístico, lo que ocurre es que si se agregan apropiadamente la visión de muchas personas, el ruido queda compensado con el ruido, y nos quedamos con la señal. Es una teoría realmente útil y eficiente, pero que requiere de la heterogeneidad de las fuentes, la toma de decisiones independientes y un buen proceso de agregación de información. De ahí que este enfoque científico sea utilizado por las empresas con mucho rigor cuando se juegan millones de dólares con sus apuestas. En el el mercado de predicciones, estos requisitos se garantizan habilitando un mercado bursátil a la hora de incentivar a los participantes a aportar solamente la mejor información disponible, puesto que los beneficios o pérdidas irán a parar directamente a ellos.

En España, como mercado de predicciones que funciona y marca tendencias, está FuturaMarkets.com como uno de los más conocidos. El precio indica la probabilidad de que un determinado evento ocurra. Los participantes, compran o venden acciones si creen que la probabilidad real es distinta. Y esto es lo que hace fluctuar el mercado, y estas «predicciones de las masas que tienen los incentivos adecuados para acertar» (dado que ganarán dinero) es lo que hace que sean mercados con mucha capacidad informativa. No me deja de sorprender que no se use  más, por ejemplo, en telediarios o en medios de comunicación. Ahora mismo podemos ver qué se opina sucesos tan diversos como la presidencia de Brasil, la salida del Reino Unido de la UE, el paro en España o el regreso de Telepizza a España:

Mercado de predicciones en Futura Markets (Fuente: http://www.futuramarkets.com/)
Mercado de predicciones en Futura Markets (Fuente: http://www.futuramarkets.com/)

Como vemos, Bayes está de vuelta. Y la utilización de su enfoque para un «mercado de predicciones» abre un mundo muy interesante y de utilidad para los próximos años. Y en todo ello, el Big Data, con sus técnicas de agregación de datos heterogéneos, juega un papel clave.

Bayes y la inteligencia colectiva al servicio de la predicción en la era del Big Data. ¿A qué esperamos para seguir sacando provecho de ella?

El fútbol y Big Data (Parte II)

(continuación de la entrada anterior)

En el artículo anterior, veíamos varias aplicaciones del cruce entre el fútbol y Big Data. Describíamos cómo podría aportar ventajas competitivas importantes, una vez que algunas limitaciones que ahora mismo existen pudieran desaparecer. El fútbol y Big Data se convertían así en un dúo que parece veremos con frecuencia en los próximos años.

Con todos estos datos, el entrenador puede tomar muchas decisiones, claro. Un análisis de las ventajas y debilidades actuales, analizar las amenazas de un rival (es un juego donde la interacción entre dos jugadores produce diferentes contextos), mayor aprovechamiento de oportunidades, diseño de estrategias de entrenamiento y competición personalizadas para cada jugador (y así evitar lesiones, puntos de fatiga y mejoras de rendimiento). En definitiva, poner la tecnología a funcionar y los datos a trabajar para tomar decisiones más acertadas.

Pero hay todavía más campos donde el fútbol y Big Data se están encontrando. Las compañías de apuestas, que tan fuerte han entrado en España desde la cultura británica (de ahí sus nombres), usan sofisticados modelos para optimizar las utilidades a obtener. Por ejemplo, William Hill usa datos de Opta Sports (uno de los mayoristas de datos que más os aconsejo), SkyBet emplea estos modelos y datos para las comunicaciones con sus clientes, etc. Por otro lado, los operadores «Daily Fantasy Sports«, también tan populares en otras latitudes, y que en España tienen su fiel reflejo en el famoso Comunio, hacen lo propio. De hecho, los mejores jugadores de este tipo de «juegos de fantasía», son verdaderos magos del uso de Big Data para sus decisiones y estrategias. Siempre me pregunto por qué no podrían dar el salto a un equipo profesional…. ¿quizás es que ningún club los esté «monitorizando»? 🙂

Por otro lado, y para ir terminando, uno podría preguntarse por el origen de los datos. Y esta, es una pregunta muy interesante, porque también se está produciendo mucho desarrollo en este área. Un ejercicio éste del fútbol y Big Data, en el que ven, hay mucha monitorización. Uno podría pensar que con datos estructurados y cuantitativos, el proyecto de análisis de datos se vuelve fácil. Bueno, en realidad no lo es tanto, dado que exige unos requisitos computacionales muy importantes, y, en segundo lugar, porque estos datos se enriquecen con otras fuentes normalmente (como encuestas sobre cómo han dormido, cómo se sienten, etc., así como datos climatológicos y contextuales del lugar, hora y espacio del encuentro, por ejemplo). Por lo tanto, estamos hablando de Big Data como paradigma y reto.

Todos estos dispositivos que ayudan a obtener datos de la actividad de los jugadores están dentro de la categoría de «Electronic Performance Tracking System» (EPTS). De hecho, la FIFA ya está trabajando en un estándar de los datos que estos dispositivos generan, dada la implosión de datos que se está produciendo. Hay productos como Adidas’ miCoach elite team systemCatapult Sports -focalizado en sistemas Global Navigation Satellite System (GNSS), que usan equipos como el Chelsea o el Real Madrid-, la Italiana MatricsChyronHego conocida por su tecnología de monitorización de futbolistas TRACABTechedge España -que ha diseñado una plataforma Big Data denominada Sportedge (patrones de juego, inteligencia, sinergias del equipo y reciprocidad en el juego)-, etc. Como ven, la tecnología de monitorización deportiva está en un buen momento.

Monitorización jugadores selección Argentina (Fuente: fifa.com)
Monitorización jugadores selección Argentina (Fuente: fifa.com)

Por cierto, para los que les guste mucho el fútbol o el deporte en general y el Big Data -como a mí, sí, no lo oculto-, les recomiendo encarecidamente la MIT Sloan Sports Analytics Conference, un evento anual en el que salen todo tipo de estrategias de análisis de datos y su aplicación a grandes y pequeños equipos. Este año ha sido su décima edición, y como siempre, he tenido mucho interés en seguir los «Research papers» que se han presentado. Ahí podrán ver cómo el Big Data impactará no solo en el fútbol, sino en el deporte en general, en los próximos años. Por ejemplo, el paper que ganó en 2012 el premio número 1, hoy en día es la empresa y servicio Second Spectrum, líder en análisis de datos de jugadores de la NBA.

Como ven, el fútbol y Big Data, un dúo con mucho desarrollo últimamente. Un campo, donde todavía hay mucho por hacer. Esperemos, eso sí, que tanto «determinismo» de las máquinas no termino con el humanismo que rodea al fútbol y las visiones y opiniones que tenemos todos nosotros de nuestro equipo de cabecera. La magia de lo imprevisible, algo intrínseco al juego, esperemos que siga ahí.

El fútbol y Big Data (Parte I)

Una de las áreas donde el Big Data está sonando cada vez con más fuerza es el fútbol. Dada la afición que existe por el deporte rey, es fácil que sea una pregunta recurrente. Más aún, si consideramos el fútbol como un juego en el que al intervenir tantas variables, las estrategias y decisiones a tomar, y el análisis de datos para que éstas sean lo más fundadas posible, se vuelve crítico.

Son muchas variables las que pueden intervenir: el estado de forma de los jugadores, los estilos de juego, la interacción entre las propias estrategias frente a las del rival, la combinación de los jugadores con sus propios estilos entre sí, su adecuación al estilo del entrenador, etc. Éstas hacen que la combinación estadística de todas ellas produzca muchos escenarios dignos de buen análisis. Tantos datos y tantas decisiones que poder tomar, en consecuencia, que voy a dividir esta entrada en dos partes, para no generar pereza en la lectura de una única larga entrada.

Empecemos con algo de contexto en esto del fútbol y Big Data. Recuerdo varias frases cuando Pep Guardiola llegó al Bayern de Munich, pero una en especial:

The match analysis department is the most important department for me.

Efectivamente, ahí tenéis a uno de los mejores entrenadores según Transfermarkt, confiando en disponer de un departamento de Analytics bien pegado a él que le ayude a analizar los muchos datos que genera su equipo y su juego. No solo él. El Arsenal de Arsene Wenger, utiliza también modelos estadísticos para ayudar en la gestión de la detección del talento. Incluso pagó 2 millones de libras para comprar una empresa -StatDNA-que se dedicaba a ello.

Por lo tanto, parece que el Big Data en el campo del fútbol tiene un amplio abanico de aplicaciones. Y eso que todavía no es posible lo que se conoce como «On in-game analytics-driven coaching«. Es decir, en fútbol, un entrenador no puede tomar decisiones sobre la estrategia del juego y cómo jugar/variar su estrategia, hasta el descanso, o antes o después del partido. A diferencia de una empresa, todavía no es posible las decisiones «en tiempo real». Y eso a pesar que los sistemas de monitorización de partidos actuales, son capaces de compilar entre 1.500 y 1.600 eventos por partido.

Fuente: http://news.sap.com/two-global-champions-join-forces/

A sabiendas que en los partidos hay mucho dispositivo prohibido (más allá de cámaras y sensores en estadios), pero que en los entrenamientos los jugadores llevan cada vez más tecnología (un sujetador deportivo -o cualquier otro wearables deportivos- en cada entrenamiento que consta de un monitor de pulsaciones, un acelerómetro y un sistema de geolocalización), podemos obtener explotaciones de datos como:

  • Análisis de patrones y tendencias en parámetros básicos: desempeño atlético (velocidad, aceleración), la posición de los jugadores y sus movimientos, la tenencia del balón, etc. Y, de esta manera, detectar los parámetros críticos de mejora en base a referencias de juego.
  • Modelos predictivos de juego, remate y gol: la empresa Oulala Games tiene un modelo matemático que, empleando datos de la empresa Opta (hablaremos de ella más adelante), permite a un club disponer de un sistema predictivo de los factores que llevan a obtener el mejor resultado de un jugador. Juegan con un total de 70 variables para obtener 275 posibles acciones a realizar con las que ganar o perder puntos.
  • Modelo de propensión a la lesión o fatiga: si un equipo es capaz de detectar los factores que mejor predicen una lesión, podrá evitarlos a futuro con un modelo que lo detecte con carácter preventivo. A más de un equipo, que a estas alturas ha rotado poco, le podría venir muy bien.
  • Análisis individual vs. global del equipo: no olvidemos que como juego de equipo que es, lo importante es el análisis global del equipo, en la estrategia global. Es lo que se ha bautizado como el «eventing», secuencias que miden los pases buenos, las pérdidas de balón, remates, goles, faltas, tarjetas, tenencia y similares, que permiten ver la contribución de cada jugador al equipo y viceversa. Esto, con grafos, ya se ha hecho en varias ocasiones para las selecciones y enfrentamientos clave (como la final del Mundia entre España y Holanda). De esta manera, la adecuación de jugadores a equipos y viceversa -como le encanta al Cholo Simeone-, resulta más fácil.
  • Simulación de jugadas y enfrentamientos: cruzando todo este conjunto de variables y datos de los que estamos reiteradamente hablando, un equipo puede disponer de un simulador de posibles jugadas y enfrentamientos, con los que afrontar de la mejor manera posible cada partido. La personalización del juego y el equipo en función del rival.
  • Valoración de jugadores en mercado: más allá de ejercicios «amateurs» como los que he podido hacer yo en el caso de Aymeric Laporte, aquí hay modelos realmente sofisticados. Como decíamos antes, el Arsenal dispone de una herramienta propia para ello. Y hay bastantes rumores que el acierto de Monchi en el Sevilla, se debe a lo mismo.
  • Factores Críticos de Éxito: una de mis historias preferidas en cuanto al análisis de factores de triunfo de un equipo es el de la selección Alemania de fútbol durante el Mundial. La actual campeona del mundo, implantó un sistema global de Big Data que le permitió tomar decisiones sobre qué factores eran los que la hacían producir mejores resultados. Se dieron cuenta que, por ejemplo, reducir el tiempo de posesión a poco más de un segundo (de los 3,5 segundos en los que estaba).
  • Detección de talento: en 2011, la película Moneyball narró la historia de Billy Beane, director técnico de un modesto equipo de beisbol que en 2001 empezó a utilizar la estadística para detectar jugadores poco valorados en mercado, pero con grandes probabilidades de hacer grandes cosas. Desde entonces, el fútbol se ha llenado de herramientas y bases de datos estadísticas como Opta Sports -que ya trabajar con el Sevilla, Valencia o FC Barcelona, entre otros- o Transfermarkt, que ponen a disposición de los clubes datos para hacer eso mismo. Supongo que ya lo estarán empleando, pero dada su sensibilidad y la ventaja competitiva que ganan, entiendo no lo divulgarán mucho.

(continuará)

El uso del Machine Learning en las entidades financieras

(Artículo de nuestro profesor Pedro Gómez Tejerina)

Las entidades financieras han sido las pioneras tradicionalmente en utilizar el Data Mining y Machine Learning (ML). Y lo han aplicado principalmente en el núcleo de su negocio, la financiación. Cuando un cliente quiere solicitar un préstamo, el banco le solicita una determinada información (edad, estado civil, nivel de ingresos, domicilio, etc). En realidad el banco lo que ha hecho internamente ha sido analizar los datos históricos de los préstamos que tiene concedidos e intentar determinar la probabidad de que un cliente con determinadas características pueda impagar ese préstamo (a través de modelos de Machine Learning). Es lo que se denomina un scoring, y es el primer requisito que requiere una entidad financiera para conceder un préstamo a un cliente, que pase ese modelo de scoring (es decir, que no tenga una gran probabilidad de impago según ese modelo estimado).

Pero hay otras muchas otras áreas dentro de un banco donde se utiliza el ML. Ya comentamos en otro artículo cómo los departamentos de Marketing hacen un proceso similar para intentar predecir qué clientes podrían contratar en un futuro cercano un nuevo producto. Son los denominados modelos de propensión y la lógica es parecida al caso anterior. Analizar los datos históricos de contrataciones de productos para buscar clientes “similares” a los que anteriormente ya contrataron esos productos. Los clientes más parecidos a los que en el pasado contrataron un producto son a priori los que más probabilidad tienen de contratarlos en el futuro. A esos serán a los siguientes a los que les ofrecerán las ofertas comerciales.

Pero esto del ML tiene muchas más aplicaciones en una entidad financiera. Por ejemplo intentar detectar automáticamente operaciones (bien sean de tarjetas de crédito o transferencias) fraudulentas para evitar disgustos a sus clientes. O intentar predecir el uso en fin de semana de los cajeros automáticos de las oficinas para asegurarse de que no se quedan sin efectivo cuando los clientes vayan a retirarlo. O incluso a nivel organizativo re-estructurar la localización de sus oficinas físicas para atender mejor a sus clientes a través del análisis de los datos de las visitas de los mismos a las oficinas. Y todo esto por no hablar de los motores de recomendación de inversión, que analizan rentabilidades históricas de los activos financieros para ofrecer recomendaciones de inversión personalizadas a los clientes según el apetito de riesgo que estos tengan.

Todos estos ejemplos son tan sólo una muestra de las aplicaciones que el mundo del Data Mining y Machine Learning tienen en una entidad financiera, pero como os podéis imaginar, hay muchos más. La tendencia actual es enriquecer estos modelos con otro tipo de datos (redes sociales, Open Data, datos no estructurados…) para mejorar su capacidad predictiva. Aquí es donde entra en juego el Big Data.

Fuente: https://www.coursera.org/course/compfinance
Fuente: https://www.coursera.org/course/compfinance

El Big Data en los Papeles de Panamá

No creo que a estas alturas, a usted, estimado lector de cualquier parte del mundo del que lea esto, le tenga que contar nada sobre los «Papeles de Panamá». Unos documentos filtrados, en el que se dice la mayor filtración periodística de toda la historia. En el contenido de los mismos se puede encontrar a personas de todo el mundo aprovechando los paraísos fiscales para ocultar su dinero en el pago de impuestos. Nada que la ética no pueda explicar por si sola les voy a contar.

Pero de lo que se ha hablado menos es de cómo se produce. Como quizás también sepan, todo se produce a partir de la extracción de unos documentos de dos sitios web de la empresa Mossack Fonseca: la web que sirve como descripción de sus servicios -un WordPress- y un portal interno de clientes donde se podía compartir información sensible de todos ellos -un Drupal-. Uno, lo primero que podría pensar s que entonces la «culpa» es de la falta de seguridad tecnológica. Y efectivamente, al parecer, la falta de actualización del portal interno y un plugin de WordPress habrían expuesto toda esa documentación.

Pero, una vez obtenidos los documentos, hay que analizarlos para extraer inteligencia de los mismos. Vamos, un proyecto de Big Data, en definitiva, porque la cantidad documental de la que estamos hablando es realmente grande (2.6 terabytes, y 11,5 millones de documentos -Wikileaks, para que se hagan a la idea, fueron 1,7 GB «solo»-). El Big Data en los Papeles de Panamá ha jugado un papel nuclear.

La escala de los
La escala de los «Papeles de Panamá» (Fuente: http://www.alternet.org/files/screen_shot_2016-04-04_at_12.01.06_pm.png)

Lo interesante del caso para la temática de este blog es la parte que viene después de la obtención de la «puerta de entrada a los datos». Un proyecto de Big Data, literal:

  • Fuentes de datos: la heterogeneidad -una de las famosas 5 Vs- de las fuentes de datos es muy importante: cinco millones de emails, tres millones de ficheros de bases de datos, dos millones de PDFs, un millón de imágenes, más de 320.000 documentos de texto y 2.242 archivos de otro tipo no clasificados. Un reto de extracción de las fuentes de datos importante.
  • Integración de datos: para poder procesar esta heterogeneidad de las fuentes de datos, es preciso integrar todos estos datos en un mismo modelo de datos. Y claro, mientras hay documentos medianamente sencillos para ello (las bases de datos o los documentos de texto e emails por ejemplo -gracias a tecnologías de procesamiento de lenguaje natural-), tenemos también grandes retos como los PDF y las imágenes: deben primero pasarse a un formato de caracteres para luego poder disponerse para su explotación. Ya hablamos en este blog de la aportacióin de las herramientas ETL en ello.
  • Gestión de la calidad de los datos: hay que tener en cuenta que como «filtración» que es, los datos, obviamente, no están preparados para su explotación. Entre el mar de datos, muchos son totalmente irrelevantes y no hacen más que aportar una mala calidad a los datos de entrada. Esto, ya dijimos, era crítico de solucionar ex-ante.
  • Procesamiento de los datos para la extracción de inteligencia: una vez que los datos están preparados, se deben procesar, en este caso, buscando relaciones entre entidades y acciones. Para ello, estructurar anteriormente la información de una manera que permita navegar entre la información de manera ágil y eficiente, resulta clave. Y por ello, se procesó la información estructurada en grafas, que además de tener un buen rendimiento, permite extraer mucha inteligencia. Ya hablamos de ello.
  • Visualización de datos, obtención de inteligencia: la visualización analítica, eficiente e inteligente de datos es la que permite sacar conclusiones y tomar decisiones de manera ágil.  También lo comentamos. Para ello, es preciso visualizar los datos de una manera apropiada para obtener inteligencia de los mismos.
  • Y por debajo de todas estas etapas, una infraestructura tecnológica realmente potente: para poder hacerlo a una velocidad medianamente razonable se emplearon hasta 30 servidores en paralelo. Y, sobre estos servidores, mucho software de «Big Data», tal y como detalló Mar Cabra -responsable del área de Investigación y Datos del consorcio de periodistas ICIJ, que estaba a la cabeza de esta investigación. Incluye una lista de Software Libre y también propietario, que cedieron licencias por la causa, que ha sido adaptado por el propio consorcio para sus labores de Investigación.
    • Neo4j, tecnología que vemos en nuestro Programa de Big Data y Business Intelligence, fue la base datos de nueva generación (ya hablé de ella en otro artículo), donde se almacenaron las relaciones y coincidencias entre los documentos. Esta tecología, como ya expliqué, permite modelar la información a partir de conexiones entre entidades,  lo cual facilita mucho poder luego estudiar estos flujos de datos para detectar e inferir conocimiento. Aquí lo describe la propia empresa.
    • Nuix, un software de gestión documental, que permite indexar y categorizar información rápida y ágilmente. Aquí la noticia de ellos mismos hablando sobre el caso.
    • Con Apache Solr y Apache Tika, se puso a disposición de la búsqueda y recuperación la información contenida en los documentos de manera centralizada. Es la parte más relacionada con la integración de datos. Aquí explicado.
    • Linkurious,  la herramienta para trazar y visualizar los vínculos de la documentación obtenida por temas y sujetos de investigación. Aquí lo describen ellos mismos.

Obviamente, como solemos decir, la tecnología, por muy buena que sea, no descubre por sí sola. Por un lado, alguien debe hacerle las preguntas más acertadas, y en segundo lugar, alguien tiene que entender los resultados que nos devuelve. Ahí está la formidable labor realizada por los periodistas. Sin conocer el contexto bien, es difícil hacer un proyecto de Big Data de este calibre. Por ello, el futuro del periodismo con un importante soporte en datos y tecnologías que le permita acelerar su proceso de investigación se me antoja cada vez más cercano.

El «Big Data», como paradigma habilitante que es, permite cambiar las reglas de juego de diferentes sectores de actividad. En este caso, hemos visto cómo ayudó al caso de los «Papeles de Panamá». Y es que este método de trabajo que hemos visto (extracción, integración, depuración, procesamiento y visualización), con el apoyo de las mejores tecnologías para ello, ha venido para quedarse. El Big Data en los papeles de Panamá ha sido un paradigma muy habilitante.