Expectativas y realidades con el Big Data

4 comentarios
Big Data y Dilbert (Fuente: http://www.bigdata-madesimple.com/wp-content/uploads/sites/8/2015/01/bigdata-knows-everything.jpg)
Big Data y Dilbert (Fuente: http://www.bigdata-madesimple.com/wp-content/uploads/sites/8/2015/01/bigdata-knows-everything.jpg)

NINO y GIGO (Nothing in, Nothing Out, Gargabe in, Garbage Out). Estos dos paradigmas son mucho más ilustrativos de lo que parecen. Aquí es donde yo suelo hablar del concepto «dato relevante«. El primero de ellos, básicamente refleja una realidad en la que por mucho que tengamos un gran modelo o herramienta, si los datos de entrada, no son buenos, no podremos hacer nada. Y lo mismo, si los datos de entrada no son de buena calidad.

Es por ello que creo en ocasiones es bueno hablar de las expectativas que el Big Data ha venido a generar, y lo que luego efectivamente se ha convertido en realidad. Se han generado estos año muchas expectativas con Google y Facebook y lo que supuestamente saben de nosotros. Saben más que el resto, sin duda. Pero, suavicemos el discurso. No saben todo.

¿Por qué? Pues porque el concepto de «dato relevante» no siempre es alcanzado. Fijense en la siguiente representación gráfica:

Datos relevantes para proyectos de Big Data (Fuente: https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAIEAAAAJGRhNWYzODhmLTdhZjItNDYxMS04MTY2LWZmMjFmNjgyYjg5ZQ.png)
Datos relevantes para proyectos de Big Data (Fuente: https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAIEAAAAJGRhNWYzODhmLTdhZjItNDYxMS04MTY2LWZmMjFmNjgyYjg5ZQ.png)

Como se puede apreciar los datos más relevantes están alejados de lo que hoy todavía las empresas disponen. Incluso en las grandes empresas tecnológicas de Internet. La horquilla tradicional de datos relevantes/datos totales se mueve entre el 10% y el 15%. Las empresas disponen de muchos datos demográficos (si se fijan, sobre los que pivotan la gran mayoría de noticias), pero apenas saben nada sobre nuestras actitudes o necesidades, por ejemplo. Se aproximan con modelos sencillos. De ahí, que muchas de las expectativas que se han venido generando con el «Big Data», luego las tratas de aterrizar, y se vuelven complicadas.

No es lo mismo los datos demográficos, que los sociológicos, de comportamiento, de actitud o de necesidades. El valor incrementa con el orden en la frase anterior. Pero normalmente construimos discursos alrededor de datos demográficos. Que tienen valor, vaya, pero  no el que tienen los de actitud o necesidades.

En este punto hay que hablar de lo que se denomina «First-Party Data» y «Third-Party Data». Las fuentes «First-Party» son aquellas que son propias de las empresas. Entre ellas, destacan:

Fuente: http://www.business2community.com/marketing/personalize-retail-experience-data-01491335
Fuente: http://www.business2community.com/marketing/personalize-retail-experience-data-01491335

Ahora mismo la explotación de estos datos está siendo limitada por la sencilla razón de no disponer de un único punto central que integra y permite la explotación de datos centralizada. Aquí es donde cobra sentido el concepto de «data lake«, por cierto.

Por otro lado, los «Third-Party Data», son aquellos datos que compramos a «mayoristas» o «proveedores» de datos. Datos relacionados con el consumo, estilo de vida, demografía, comportamiento en tiempo real, etc. Permiten completar la «foto» a una empresa. Ya hablamos en cierto modo de los problemas que entrañaba para la privacidad de un sujeto estas transacciones de datos.  En este caso, las limitaciones de las empresas parecen venir desde la óptica de la calidad de datos: frescura, precisión, etc., problemas ligados a la calidad de datos de lo que ya hemos hablado en el pasado.

Las empresas, ante la limitación que suelen tener de explotar sus «First-Party Data«, deberían comenzar a mirar hacia los «Third-Party Data» si quieren enriquecer muchos sus modelos y hacer más más precisos sus modelos. La capacidad de generar valor a partir del análisis de datos necesita de integrar nuevas fuentes de datos. Porque los datos que son más importantes no quedan recogidos en las operaciones diarias de una empresa.

Y es que el paradigma del «Big Data» es un medio, no un fin. Es un instrumento del que podemos valernos para obtener conclusiones. Pero el valor de los mismos, dependerá en gran medida de la materia prima con la que trabajemos. Y por ello, muchos de los fines están todavía por inventar. De ahí que suela decir que no hay dos proyectos de Big Data iguales; depende mucho de cómo las empresas vayan avanzando desde sus datos demográficos a los datos de actitud. De sus datos propios («First-Party Data«) a integrar también datos de terceros («Third-Party Data«).

Creo que muchas de las expectativas no alcanzadas aún hoy se deben a que seguimos viendo este campo del análisis de datos como el «Data Mining original«. Aquel en el que el objetivo era explotar grandes conjuntos de datos. Que no digo que esto no siga siendo válido; pero si queremos alcanzar las grandes expectativas generadas, debemos mirar «más allá». Y entender el valor que tienen los datos que nos pueden aportar los datos de terceros o los «Open Data«, me resulta bastante crítico. Y así, poder alcanzar mejor las expectativas para hacerlas reales.

La medicina personalizada como ejemplo del Big Data para la «economía de la personalización»

16 comentarios

Hace unos meses (el Enero pasado), hablábamos de la medicina 5P.  El cruce entre la sanidad y el Big Data, donde aparecían conceptos y ventajas como la Personalización, Predicción, Prevención, Participación y Población. En términos de la personalización, decía lo siguiente:

Personalizada: el eterno sueño de la medicina. Poder dar un tratamiento singular al diagnóstico y necesidades concretas de cada uno de los pacientes. Con el Big Data, la cantidad ingente de datos, y el contexto que describe a cada uno de los pacientes, esto es posible. Solo es cuestión de “codificar” en datos lo que hasta ahora no hemos hecho, en cuestión de aspectos clínicos como estado de ánimo, emociones, expresión del dolor, etc.

La personalización de la prestación de un servicio es algo que ha venido inexorablemente ligado a esta era del Big Data. Si lo pensamos por un momento, tiene todo el sentido del mundo. Una reciente encuesta de Infosys, decía como el 78% de los consumidores estaría dispuesto a repetir la compra con una marca si se le personalizaba la propuesta de valor. Otro informe de RightNow Customer Impact, ilustraba la idea de la personalización desde la óptica de más ventas para una marca: un 86% de los consumidores estaría dispuesto a pagar más si la personalización se refería a sus necesidades.

Por lo tanto, hay margen y posibilidad de ganancia en la era de la personalización. Sin embargo, no es un proyecto fácil, por mucho que veamos muchos textos hablando de ello. Y es que hasta la fecha, nos costaba mucho personalizar los servicios por varias cuestiones:

  • No era rentable
  • El consumidor tampoco lo demandaba
  • No teníamos información para hacerlo

Pero ahora, estos tres elementos se desvanecen. Han cambiado. Las posibilidades ahora se multiplican, gracias a que con la ingente generación de datos, el reto está más relacionado con saber sacar valor de los datos que de no tener información para ello. Sin embargo, todavía queda mucho por hacer. Solo el 20% de las acciones de marketing llevan ligadas características de personalización. Esto es solo un ejemplo de un «área», donde la personalización tiene mucho que aportar.

Y más en el campo sanitario, donde las ineficiencias, o donde la no-personalización de la aplicación de algún fármaco, puede traer importantes consecuencias. Miremos la siguiente figura: 

Ineficiencia de algunos fármacos para determinadas poblaciones de pacientes (Fuente: http://www.knowledgedriven.com/media/55013/percent_of_patient_pop_for_which_a_drug_is_ineffective_500x425.jpg)
Ineficiencia de algunos fármacos para determinadas poblaciones de pacientes (Fuente: http://www.knowledgedriven.com/media/55013/percent_of_patient_pop_for_which_a_drug_is_ineffective_500x425.jpg)

En la entrada de la Wikipedia en Español, la definición de «Medicina Personalizada«, hace referencia a varias cuestiones que me parecen bastante ilustrativas de lo que hoy queremos hablar:

  • Administración de un fármaco o conjunto de fármacos más idóneos
  • En las dosis adecuadas para cada paciente concreto
  • A la vista de su individualidad química y genética
  • Se apoya tanto en el conocimiento de la naturaleza molecular de las enfermedades como en la individualidad química que posee cada paciente

Sin embargo, la entrada de la Wikipedia en Inglés ofrece otra serie de elementos que describen de una manera más global y multidimensional el concepto de «personalización», en este caso, para la medicina:

  • Modelo médico
  • Toma de decisiones y prácticas basadas en la personalización y las características individuales de cada paciente
  • Uso sistemático de información genética del paciente

Es decir, habla más de muchos de los elementos que hemos venido citando necesarios para los proyectos de Big Data: una buena materia prima, una transformación de los modelos (de negocio u organizativos), una toma de decisiones basada en la evidencia, etc. Y son cuestiones que vemos en nuestros Programas de Big Data, no solo para la medicina, sino también en otras cuestiones (ofertas publicitarias, planes de carrera personalizados, recomendaciones de productos en tiendas online, etc.). Por eso he señalado en negrita los aspectos más relacionados con esto de la «era de la personalización«.

El estado de adopción de la Medicina Personalizada (Fuente: http://www.photonics.com/images/Web/Articles/2010/9/1/thumbnail_44349.jpg)
El estado de adopción de la Medicina Personalizada (Fuente: http://www.photonics.com/images/Web/Articles/2010/9/1/thumbnail_44349.jpg)

Y todo esto, tiene aplicación en toda la cadena de valor del sector de la salud, no solo en la prestación médica. Y tiene aplicación en otros sectores. Porque el sector sanitario en cierto modo me recuerda a cuando el sector de las telecomunicaciones o las utilities pasó de un modelo de abonado a un modelo de cliente. Una transición que se hizo realmente mal (más allá de la privatización + poca liberalización de España). Los clientes, por el trato recibido, mostraron su poca satisfacción cambiando constantemente de operador (es un sector con un CHURN muy elevado), y ve estos servicios como commodities. Y por eso, también en nuestros programas de Big Data diseñamos y desarrollamos modelos predictivos de propensión a la fuga (CHURN).

En el sector sanitario, el concepto «Consumer Driven Healthcare» hace un poco referencia a todo ello. Los ciudadanos toman un rol activo en la gestión de su salud y están dispuestos a pagar por ello. Se le da: decisión, información y control. Y, de nuevo, hablamos de poner al cliente -el paciente en este caso- en el centro del proceso.

En todo esto, y como solemos concluir muchos artículos, nunca debemos abandonar la ética. Y menos en un campo tan sensible como es el sanitario.

El «mercado de Hadoop» y MapR: el valor de las tecnologías Big Data

1 comentario

En un artículo anterior, hablábamos del nacimiento de esta era del Big Data. Y comentábamos, que el framework Hadoop había jugado en ello un papel fundamental. Desde entonces, su uso no ha dejado de crecer en el mundo empresarial.

El «mercado de Hadoop» está en pleno crecimiento. Hablamos de un mercado en el que las empresas, cogen el framework open source del que hablábamos, y desarrollan sus propias soluciones. Es una carrera entre tres principales «players»:

Con estas cifras, además de entender el dinamismo del sector ahora mismo, se deja entrever que las valoraciones de las que estamos hablando de tecnologías Big Data, no son nada pequeños. Y si utilizamos estas cifras para aproximarnos a su verdadero valor, creo que podemos pensar que valor, existe.

Vamos a hablar de MapR, solo por la reciente noticia del aumento de su capital nuevamente. Y lo haremos como excusa para entender qué empresas están detrás de todo ello, y cuál es su base de clientes. Una tecnología de procesamiento de datos masivos que se asienta sobre el paradigma MapReduce, y que ofrece a las empresas la posibilidad de procesamiento Batch y Tiempo real (ya hablaremos de ello).

Tecnologías MapR (Fuente: http://www.storagenewsletter.com/wp-content/uploads/sites/8/old/0icono13/mapr_der_540_01.jpg.pagespeed.ce.PJ1TlwAsX7.jpg)
Tecnologías MapR (Fuente: http://www.storagenewsletter.com/wp-content/uploads/sites/8/old/0icono13/mapr_der_540_01.jpg.pagespeed.ce.PJ1TlwAsX7.jpg)

Ellos se autodefinen como plataforma de datos de convergencia, en el sentido que te permite hacer «de todo» con los datos con un mismo paquete de módulos tecnológicos. Una empresa que ha duplicado en el último trimestre su cartera de clientes, que ya incluyen a empresas del tamaño de American Express, Audi, Ericsson, NTT, Philips o el banco Mizuho. Su modelo de negocio se asienta sobre las licencias y los servicios de soporte. Representan un 90% de sus ingresos totales. Y esto es lo que exponen en su propia web:

MapR proporciona, en el marco del universo Hadoop, una plataforma unificada que dispone de funcionalidades de misión crítica, que permite realizar desarrollos de producción en tiempo real. MapR cuenta con cerca de 700 clientes de los sectores de finanzas, gobierno, salud, Internet, industria, medios, retail y telecomunicaciones. Amazon, Cisco, Google, Teradata y HP también forman parte del ecosistema de partners de MapR.

¿Y cuál es su propuesta de valor? Básicamente, sobreponerse a las restricciones que tiene la distribución estándar de Hadoop, pero bajo una licencia que sigue siendo Apache. En lugar del HDFS del que hablábamos, ofrece MapRFS para una gestión de datos más eficiente, confiable y fácil de usar. Por ello, suelen decir que está más orientada a la «producción empresarial» que las dos anteriores.

Además, su módulo de integración de datos es realmente eficiente, permitiendo a las organizaciones integrar y procesar datos «legacy» así como nuevos, procedentes de diferentes plataformas. Una vez hecho esto, igualmente proveen soluciones de analítica avanzada.

El procesamiento de datos en el mundo de las empresas está en tanta transformación, que todas estas empresas proveedoras de soluciones de procesamiento de grandes volúmenes de datos, seguirán registrando cifras récord. La tendencia así parece demostrarlo. Aquellas que más están cambiando (aquellas que más competitividad están consiguiendo), son clientes de MapR, Hortonworks o Cloudera. Por ello, nada hace pensar que esta tendencia va a cambiar.

¿Qué lenguaje debemos utilizar para Data Science?

3 comentarios

En este blog, ya hemos hablado con anterioridad de diferentes herramientas para emprender proyectos de analítica. Fue en esta entrada, comparando más allá a nivel de herramienta, cuando comparábamos R, Python y SAS, que son sobre las que pivotamos en nuestros Programas de Big Data.

El mundo de la analítica está avanzando a la velocidad de la luz, por lo que es importante que escribamos artículos volviendo a esa pregunta original sobre ¿Qué lenguaje utilizar para Data Science? No es una pregunta sencilla, porque las opciones existentes no son pocas.

La pregunta se vuelve más complicada aún en contextos como el nuestro. Tenemos que enseñar y aprender desde cero la disciplina de Data Science. Y una pregunta muy recurrente de parte de nuestros alumnos de Bilbao, Donostia y Madrid, es, ¿por qué lenguaje empieza para arrancar en este mundo del Big Data?

Son muchas los lenguajes que ofrecen las capacidades para ejecutar operaciones de análisis de datos de una manera más eficiente que los lenguajes tradicionales (C++, C, Java, etc.). Entre ellos, destacan algunos sospechosos habituales, y otros que están emergiendo con fuerza: R, Python, MATLAB, Octave y Julia. Éste es el menú en el que tenemos que elegir; decisión, como suele pasar con estas cuestiones, no sencilla. Dejo fuera de esta comparación soluciones analíticas como SAS, Stata o Excel, básicamente, porque no están orientadas a nivel de «lenguaje de programación», sino a nivel de herramientas.

En esta entrada, y para poder encontrar un ganador, se han comparado los lenguajes en varias dimensiones: velocidad de ejecución, curva de aprendizaje requerida, capacidades de ejecutar acciones de analítica de datos, soporte a la visualización, entornos de desarrollo, facilidad de integración con otros lenguajes/aplicaciones y las oportunidades de trabajo existentes.

Comparación entre lenguajes

Obviamente, debemos notar que las calificaciones otorgadas en cada dimensión son la opinión de Siva Prasad, la persona que lo ha elaborado. Por lo tanto, creo que no debemos tampoco sacar conclusiones exclusivamente de ello. Creo que lo más ilustrativo del caso es fijarse en que en función de cuál sea el objetivo y la necesidad concreta, hay diferentes opciones que explorar.

Lo que sí me parece igualmente interesante, son la utilidad que puede tener en función del punto en el que cada uno se encuentre. El autor, en su entrada, destaca que:

If you are a graduate student, it’s good to start with Python

Si somos estudiantes de Grado, que estamos arrancando, sugiere emplear Python.

If you are a research scholar, good to start with R and explore Octave

Si estamos por la vía de la investigación/doctorado, sugiere el empleo de R y/o Octave.

If you are an employee, I suggest to master both Python and R

Si eres una persona ya trabajando en la industria, parece que las mejores apuestas pasan por Python y R.

If you are tech enthusiast and love exploring/learning new things, you can learn Julia

Si eres un entusiasta tecnológica y te gusta explorar/aprender nuevas cosas, métete con Julia (yo, estoy en esta etapa, haciendo modelos de optimización con Julia, que es realmente potente e interesante).

If the data needs to try several different algorithms, choose R

Si necesitamos probar diferentes algoritmos para tratar el conjunto de nuestros datos, prueba con R.

If you need to use data structures and integrate with external applications, use Python

Si tenemos que utilizar muchas estructuras de datos e integrar los mismos con aplicaciones externas, probemos con Python.

Para gustos están los colores. En definitiva, que no consideremos esto como conclusiones a escribir en un libro. Pero sí por lo menos, para orientarnos, y tener primeras aproximaciones a la ciencia de datos, Data Science, así como las opciones que abre cada uno de ellos. Disfruten de todos ellos 🙂

Arquitectura Lambda para sistemas Big Data (y III)

3 comentarios

(venimos de una serie hablando de los tres paradigmas, para haber hablado luego del paradigma batch y luego del tiempo real)

Fuente: http://image.slidesharecdn.com/bigdatarealtimearchitectures-150823093028-lva1-app6891/95/big-data-real-time-architectures-5-638.jpg?cb=1440322348
Fuente: http://image.slidesharecdn.com/bigdatarealtimearchitectures-150823093028-lva1-app6891/95/big-data-real-time-architectures-5-638.jpg?cb=1440322348

Terminamos esta serie de artículos, hablando de las arquitecturas Lambda. Y es que una de las cosas que decíamos a la hora de procesar flujos de datos en tiempo real, es que se puede no renunciar a la aproximación batch. Es decir, que podemos diseñar sistemas de Big Data que los integren a ambos, dando así una opción genérica y que para cada necesidad concreta, pueda emplear las tecnologías Batch o Tiempo Real.

Nathan Marz publicó el libro «Big Data: Principles and best practices of scalable realtime data systems» en abril de 2015 para explicar todo esto (aquí está el primer capítulo, gratis). Lo resumió en «la Arquitectura Lambda«, que representamos a continuación:

Arquitectura Lambda (Fuente: http://lambda-architecture.net/img/la-overview_small.png)
Arquitectura Lambda (Fuente: http://lambda-architecture.net/img/la-overview_small.png)

En la web http://lambda-architecture.net/ se puede comprobar como son muchos los casos de aplicación de este paradigma que se han producido en los últimos tiempos.

El problema ante el que nos solemos encontrar al tratar con grandes volúmenes de datos es que no existe una técnica predefinida para hacerlo. Ya hemos visto con los paradigmas anteriores que el enfoque a adoptar para el procesamiento puede ser diferente. En esta ocasión, el creador de este paradigma Lambda, propone descomponer el problema en tres capas: Batch, Serving y Speed.

Arquitectura Lambda (Fuente: http://www.databasetube.com/wp-content/uploads/sites/8/2012/09/lambda1.jpg)
Arquitectura Lambda (Fuente: http://www.databasetube.com/wp-content/uploads/sites/8/2012/09/lambda1.jpg)

En este paradigma todo comienza con una ecuación que podríamos formular de la siguiente manera: query = function(all data). Consiste en que en esa capa Batch inicial que veíamos, disponer de vistas indexadas de datos que han sido pre-computadas, de tal manera que cuando tenga una necesidad en tiempo real, no necesite procesar todo el largo conjunto de datos, sino simplemente acceder a la vista de datos que tuviera pre-computada. De esta manera, me adelanto a la necesidad de consultar datos, disponiendo de largos subconjuntos de los mismos ya pre-computados, de tal manera que se trataría de localizar los mismos. Es importante entrever que estas pre-consultas son aleatorias, por lo que para analizar todo el dataset tendríamos que lanzar varias consultas.

Supongamos que tenemos un proyecto de análisis de datos de una web con Google Analytics. Dejamos así «preparada» una función con todas las métricas que quisiéramos consultar (páginas vistas, visitantes únicos, búsquedas orgánicas, etc.) en una función con (URL, día). De esta manera, cuando queramos lanzar una consulta para un día determinado, solo necesitaríamos consultar la vista del rango de día donde hubiera caído el día concreto que nos interesa, y así, ágilmente, conseguir la información que nos interesa. En esta capa intervienen Hadoop o Spark.

Posteriormente, tenemos la capa de servicio. La capa anterior, creaba esas vistas con los datos pre-computados. Pero, siempre necesitaremos una capa que cargue esas vistas en algún lugar que luego permita se puedan consultar. Esto se hace en la capa de servicio. Indexa las vistas creadas en la capa batch, las actualiza cada vez que llegan nuevas versiones de la capa batch. Dado que no recibe escrituras de datos «aleatorias» (que suele ser el factor que hace realmente lenta una Base de Datos tradicional), esta capa es realmnete robusta, predecible, fácil de configurar y operar. Ya ven, un problema habitual de las bases de datos, resuelto no tanto con tecnología (que también), sino con enfoques de tratamiento de datos. En esta capa, destaca ElaphantDB, por ejemplo.

Y, por último, aparece la capa de velocidad. Cuando alguien quiere acceder a una consulta de datos, lo hace a través de una combinación de la capa de servicio y de la capa de velocidad. Esto lo podemos ver en el siguiente gráfico:

Capa de Velocidad y Servicio

La capa de velocidad es similar a la batch en el sentido que produce vistas a partir de los datos que recibe. Ahora bien, hay algunas diferencias clave. La más importante es que para conseguir altas velocidades, esta capa no mira a todos los nuevos datos de golpe. Solo actualiza aquellos nuevos datos que recibe, lo que le permite ofrecer de manera efectiva consultas de datos en tiempo real. Por eso se suele decir que esta capa actúa con actualizaciones incrementales, solo marcando como nuevo aquello que sea estrictamente necesario para ofrecer al usuario una vista en tiempo real.

Y todos esos módulos y funcionalidades es lo que nos permite disponer de una arquitectura Lambda que de manera completa representamos en la siguiente figura. Nada mejor para seguir ampliando conocimientos que leer el libro de Nathan Marz, que lo explica realmente bien y al detalle.

Arquitectura Lambda completa (Fuente: http://www.databasetube.com/wp-content/uploads/sites/8/2012/09/lambda8.jpg)
Arquitectura Lambda completa (Fuente: http://www.databasetube.com/wp-content/uploads/sites/8/2012/09/lambda8.jpg)

Con este artículo, cerramos esta serie en la que hemos hablado de los diferentes paradigmas para afrontar un proyecto de Big Data real. Como veis, muchas novedades, y mucha cabeza puesta en hacer sistemas realmente eficientes y ágiles para las organizaciones.

 

Big Data en la Industria 4.0: un marco de oportunidades

Deja un comentario

Como comentábamos en un artículo anterior, este pasado martes, celebramos en nuestro campus de Donostia – San Sebastián el evento titulado «Oportunidades en la Industria 4.0 desde el sector TEIC: el Big Data«. Tratábamos de ofrecer una nueva mirada a las enormes aplicaciones y utilidades que tiene este nuevo paradigma del Big Data. En este caso, en un contexto más industrial, de tanto peso en Euskadi.

El evento lo abrimos con la conferencia de Tomás Iriondo, director general de GAIA, en lo que a la presentación de oportunidades en la Industria 4.0 se refiere.  Una vez presentó la economía digital en general, y el nuevo paradigma de la Industria 4.0 en particular, destacó, como una de sus principales tecnologías al Big Data y sus algoritmos. Esta forma de poner en valor la analítica de datos y sus modelos de tratamiento de datos a través de la estadística y los algoritmos de inteligencia artificial (que podemos aproximar a las «Dos Culturas de datos» del artículo de Breiman), es algo que vemos en nuestro Programa de Big Data y Business Intelligence de Donostia.

A continuación mostramos la presentación empleada por Tomás, donde podéis ver el desarrollo conceptual de este marco descrito.

A continuación, moderamos una mesa redonda en la que tuvimos la fortuna de contar con personas y empresas referentes en lo que a la aplicación del Big Data en la industria se refiere, a saber:

Muchas fueron las cuestiones señaladas durante la mesa redonda, pero creo que se pueden resumir en varias ideas-clave como acta de la misma:

  • Hay numerosas oportunidades de aplicación del Big Data ahora mismo en contextos de industria. Especialmente, en lo relacionado con la optimización de procesos, análisis predictivo para adelantarnos a la necesidad del mantenimiento de equipamientos y máquinas, así como para la detección de nuevas oportunidades de eficiencia (y por lo tanto, nuevas fuentes de negocio para las empresas).
  • Los volúmenes de datos que se manejan en entornos industriales son realmente grandes. Estamos hablando de arquitecturas de datos que hasta la llegada de este paradigma del Big Data no existían. Por lo tanto, son muchas las empresas industriales que se están acercando a poder sacar provecho de estas nuevas tecnologías que les traigan nuevas fuentes de valor.
  • El perfil que están buscando ahora mismo estas empresas es el del científico de datos (del que ya hablamos anteriormente). Personas que no solo tengan conocimientos técnicos para sacar valor de los datos, sino también que entiendan de procesos en las organizaciones, de tal manera que se puedan introducir cambios en las organizaciones para la mejora de manera proactiva.
  • Quizás el mayor gap que encuentran ahora mismo las empresas es el de disponer de personas formadas en ambos campos: Industria 4.0 y Big Data. Necesitamos más personas formadas en todo ello, porque las empresas tienen proyectos, pero en muchas ocasiones, no encuentran los perfiles que buscan.
  • Los tipos de datos que se manejan en la industria vienen fundamentalmente de las medidas sensóricas, de los sistemas de información industriales (ERP, CRM, SCADAs, etc.). Esto hace que uno de los primeros problemas que se deban enfrentar sea el del modelado y la integración de datos. Una tarea que en muchas ocasiones olvidamos y que no podemos hacer.
  • Por último, hablando de tecnologías propias o ajenas. Las empresas destacaron que en este nuevo paradigma del Big Data, muchas de las tecnologías son producidas por ellas mismas. Y que por eso, si bien la curva de aprendizaje de las personas que se incorporan es mayor, la ventaja competitiva que les reporta compensa la inversión temporal a realizar.

Como ven, estos dos nuevos paradigmas del Big Data e Industria 4.0 han venido para quedarse. Se avecinan tiempos de cambios acelerados debidos a la evolución tecnológica. En nuestras manos está formarnos en ello para poder sacar el mayor provecho posible. Os esperamos en nuestro próximo encuentro debatiendo, de nuevo, con los datos encima de la mesa.

big data industria 4.0
big data industria 4.0

Evento Donostia 27/09: «Oportunidades en la Industria 4.0 desde el sector TEIC: el Big Data»

2 comentarios

La Facultad de Ingeniería de la Universidad de Deusto en colaboración con Gaia organiza una jornada dirigida a profesionales en torno a la Industria 4.0 y el  Big Data.

La evolución operativa y técnica de los sectores industriales y de servicios va a requerir de nuevas herramientas, como consecuencia de la  transformación digital de las organizaciones. Este cambio requiere, por parte de los profesionales, de una inmersión en conceptos, conocimiento y tecnología que puede reforzar la trayectoria profesional de los trabajadores y/o generar nuevas oportunidades de empleo para jóvenes y profesionales.

Objetivos generales

  • Compartir las previsiones de evolución operativa y técnica que van a experimentar los sectores industriales, y otras actividades de servicios conexas, como consecuencia del desarrollo de la transformación digital de las organizaciones.
  • Poner al alcance de los asistentes conceptos y casos aplicados de empresas en el desarrollo de actividades 4.0 en sus tres fases: preproducción, producción o postproducción.

Objetivos específicos

  • Reflexionar sobre iniciativas que refuercen las competencias de los profesionales ante este nuevo escenario.
  • Reflexionar sobre las oportunidades de desarrollar nuevos servicios gracias a la implantación de las TEIC en la industria.
  • Ofrecer herramientas y soluciones para el desarrollo profesional en la nueva sociedad digitalizada.
  • Entender las oportunidades que abre este paradigma del Big Data a la industria en el País Vasco como en el desarrollo de la estrategia industria 4.0.

 

Programa

09:45     Inscripción y Registro (Free/ Gratuita)

10:00    Presentación de la jornada y avance de las oportunidades

  • Alex Rayón, Vicedecano de Relaciones Externas y Formación Continua de la Facultad de  Ingeniería y Director Programa Big Data en Donostia – San Sebastián y Business Intelligence
  • Tomás Iriondo, Director General de Gaia. Presentación de Oportunidades en la Industria 4.0 desde el Sector TEIC

10:35    Mesa Redonda y Debate

  • Alex Rayón, Vicedecano de Relaciones Externas y Formación Continua de la Facultad de  Ingeniería y director Programa Big Data en Donostia – San Sebastián y Business Intelligence – Moderador
  • Gorka Esnal, Nem Solutions
  • Pablo García Bringas, Director DeustoTech
  • Fernando Sáenz, Savvy Data Systems
  • Mikel Lorente, Informática 68, S.A.

11:30     Finalización de la Jornada

11.30     Café Networking

Inscripción y Registro

La participación en esta jornada es gratuita, si bien dado el aforo limitado del espacio rogamosconfirmación de asistencia a través del siguiente enlace

Para cualquier consulta o duda sobre la sesión pueden contactar con nosotros en el correo:  formacion.ingenieria@deusto.es o en el teléfono: 94 413 92 08

Universidad de Deusto Donostia (Fuente: http://deustoemprende.deusto.es/lets-discover-innogune/)
Universidad de Deusto Donostia (Fuente: http://deustoemprende.deusto.es/lets-discover-innogune/)

Entrevistamos a Nagore de los Ríos, profesora de nuestro Programa de Big Data y Experto en Comunicación y Datos

2 comentarios

“La comunicación corporativa ya tiene claro que la mejor manera de llegar a sus receptores es con la caracterización y eso sólo se consigue a través del Big Data” (Nagore de los Ríos)

NagoreDeLosRios

Nagore de los Ríos participará en nuestro Programa en Big Data y Business Intelligence  y Programa Experto en Análisis, Investigación y Comunicación de Datos que impulsa la Universidad de Deusto. Fundadora de Irekia, portal de Gobierno Abierto del Gobierno Vasco, y consultora Senior del Banco Mundial en iniciativas de Comunicación y Open Data, acercará su experiencia en el ámbito del Big Data y otras cuestiones vinculadas con la comunicación y el Business Inteligence. Para Nagore de los Ríos, la complejidad del ámbito comunicativo en la actualidad, cuando se incorpora el Big Data, hace necesario el uso de metodologías, como Outreach Tool, para diseñar estrategias y planes de comunicación. Participará en el módulo M3.1 de nuestro Programa de Big Data, en colaboración con Mª Luz Guenaga y Alex Rayón, en las sesiones de Open Data y visualización de datos.

Periodista de formación, consultora en Comunicación, experta en Open Data, ¿cuál es tu aportación al Programa en Big Data y Business Intelligence?

Tanto el Open Data como la comunicación están muy ligados a los Datos. El Open Data porque en sí mismos son fuentes de datos que cualquiera puede extraer y con ello enriquecer su propio Big Data, cruzando sus datos con los Open Data, lo que supone aplicar el Business Intelligence de una forma mucho más enriquecida y además de manera gratuita. Es la materia prima más barata y accesible que alcanza gran valor cuando se cruza con otros datos bajo las preguntas adecuadas. 

Y cuando hablamos de comunicación, en primer lugar, los datos son la primera y mejor fuente de información, la más fiable, la que nos aporta el mejor conocimiento, por lo que es clave realizar buenas preguntas a los datos para que nos ofrezcan las respuestas que deseamos conocer. En segundo lugar porque para comunicar es muy importante asegurarnos de que no generamos ruido, de que el destinatario está receptivo a nuestro mensaje y es el destinatario acertado. De este modo, el Big Data se utiliza en dos momentos claves de la comunicación, el primero de ellos a la hora de hipersegmentar a los destinatarios, saber lo que desean o necesitan escuchar y en segundo lugar a la hora de vincular los mensajes y segmentarlos de la misma manera. Muchas veces queremos comunicar demasiadas cosas a todas las personas y eso no es eficaz. Si a la Comunicación le aplicamos las técnicas de Business Intelligence y utilizamos bien el Big Data podemos obtener la respuesta exacta de quien es el que necesita recibir un determinado mensaje, y qué mensaje es el más adecuado.

Y por último el Big Data está muy ligado al Marketing y a la Comunicación sobre todo a la hora de conocer los resultados, establecer los indicadores, extraer información valiosa de las redes sociales y de lo que las personas y marcas están hablando así como observar los impactos que al emitir los mensajes somos capaces de producir o no en nuestros públicos objetivos.

Cuando hablamos de comunicar, contamos con dos ámbitos, el del periodismo tradicional y la comunicación corporativa o institucional. ¿Qué beneficios obtiene cada uno de ellos?

Ambos mundos están despertando y entendiendo que los datos son la mejor fuente de información posible. En el ámbito del periodismo se están dando cuenta de que los datos no mienten y no tienen intenciones o están condicionados, los periodistas empiezan a ver una ventaja no solo en la objetividad de sus informaciones sino también en el acceso a las fuentes y en la rapidez para encontrar las respuestas y poder con ello contar las historias que los datos guardan. 

En el ámbito de la comunicación corporativa también se están dando cuenta de que para llegar a sus receptores o clientes de forma más directa la hipersegmentación es básica y sólo se consigue a través del Big Data. Gracias al Big Data además pueden localizar a nuevos receptores que son público objetivo de las marcas o empresas, más allá de los habituales medios de investigación sobre audiencias, que se centraban en los últimos años en receptores que desde las redes sociales estaban dispuestos a escuchar los mensajes de la marca o los seguidores o fans que se conseguían por otras vías del marketing. 

¿De qué modo puede ayudar el Big Data a la comunicación de empresas e instituciones?

Con la aparición de las redes sociales, las organizaciones encontraron una forma más directa de llegar a su audiencia sin pasar por intermediarios, pero se encontraron con el problema de captar tráfico y atraerlas hasta sus perfiles o webs para poder hacer llegar sus mensajes. Gracias a la publicidad en internet que facilita la segmentación pudieron acotar a ese público pero seguían esperando a que fuesen los consumidores quienes, buscando productos similares o a través de palabras claves, acabasen en sus publicaciones o anuncios. Ahora con el Big Data hemos alcanzado ya el tercer nivel, y son las marcas las que por distintas vías recopilan información de los consumidores, y utilizan el mejor canal para llegar a ellos.

Otra ventaja que encuentran ahora todas las organizaciones públicas o privadas es que pueden cocrear mejor sus servicios con los destinatarios y usuarios finales. Ya no se basan en intuiciones o en evidencias o en encuestas o preguntas de satisfacción donde los usuarios decían que es lo que ellos mismos creían que necesitaban o querían (y digo creían porque muchas veces pensamos que nos vamos a comportar de una cierta manera o vamos a tener unas necesidades concretas y luego la realidad es totalmente diferente). Los servicios y productos se pueden cocrear ahora de forma más fehaciente, prediciendo el futuro y ofreciendo soluciones a lo que verdaderamente se va a consumir o necesitar

Pero para ello hace falta actuar con cierto método, por el volumen de información que se maneja.

Si hablamos de comunicación en concreto, y queremos aplicar una estrategia y un plan de comunicación toda esa información que el Big Data y el Business Inteligence nos ha aportado lo debemos canalizar y nos sirve de base para realizar una estrategia. Contar con una estrategia definida permite señalar objetivos y llegar a alcanzarlos, no perder la perspectiva, ser eficaz en el desarrollo de la ocupación correspondiente, no malgastar tiempo ni recursos, sobre todo en un mundo tan complejo como el presente. Y una vez determinada la estrategia es necesario un plan de acciones, porque el plan permite conocer de antemano qué se pretende conseguir y cómo se piensa lograrlo.

Y para diseñar esa estrategia y el plan con el que se va a ejecutar, es necesaria una metodología. En este sentido, os recomiendo una metodología abierta y gratuita que se llama Outreachtool.com, que está empezando a dar sus primeros pasos ahora.

¿Nos puedes explicar qué es Outreach Tool, y que supone para la Comunicación corporativa e institucional en el ámbito del Big Data?

Se trata de una herramienta para generar estrategias y planes de comunicación efectivos de manera abierta, sencilla, intuitiva y ágil. Está publicada bajo la licencia Creative Commons y se conforma por una metodología y una tabla dinámica, que se pueden descargar gratuitamente. Se desarrolla en tres fases y se resuelve en un calendario de acciones para desarrollar la estrategia que se genera con la metodología.

A grandes rasgos (porque la metodología es más completa) La primera fase gira en torno a la empresa, institución, marca personal para la que se prepara la estrategia. La segunda fase analiza el conjunto de receptores a los que se dirige el plan, con una profunda hipersegmentación de destinatarios. Porque no les interesa lo mismo a unos destinatarios que a otros, ni se quiere conseguir lo mismo de todos ellos. Esto marcará también lo que se va a comunicar, que se analiza en la tercera fase, cuando se concreta el qué, el cómo, el con qué y el cuándo comunicar.

Nuestro empeño con Outreach Tool ha sido obtener un mecanismo fácil de comprender y aplicar que, no obstante, no se desvirtúe al simplificar en demasía el complejo entramado de claves que afectan a la comunicación. Buscamos que no se escape ningún detalle, que no caiga en la improvisación ninguna parte esencial de una buena estrategia de comunicación, pero que, al tiempo, no te resulte un trabajo farragoso ni tedioso.

¿Y cómo interviene el Big Data en Outreach Tool?

Para realizar cualquier estrategia es imprescindible poseer información que nos indique que caminos tomar. Se puede trabajar con intuiciones, como hasta ahora se desarrollaban los planes de comunicación. También con la recogida “manual” de información con entrevistas, estudios, análisis, encuestas… Pero si esa información es obtenida a través del Big Data tendrá un grado de acierto mayor. Y, por supuesto, con la combinación de las tres vías, el resultado será todavía mejor.

Paradigma tiempo real para sistemas Big Data (II)

1 comentario

(venimos de una serie de un artículo introductorio a los tres paradigmas, y de uno anterior hablando del paradigma batch)

Decíamos en el artículo anterior, que a la hora de procesar grandes volúmenes de datos existen dos principales enfoques: procesar una gran cantidad de datos por lotes o bien hacerlo, en pequeños fragmentos, y en «tiempo real». Parece, así, bastante intuitivo pensar cuál es la idea del paradigma en tiempo real que trataremos en este artículo.

Este enfoque de procesamiento y análisis de datos se asienta sobre la idea de implementar un modelo de flujo de datos en el que los datos fluyen constantemente a través de una serie de componentes que integran el sistema de Big Data que se esté implatando. Por ello, se le como como procesamiento «streaming» o de flujo. Así, en tiempos muy pequeños, procesamos de manera analítica parte de la totalidad de los datos. Y, con estas características, se superan muchas de las limitaciones del modelo batch.

Por estas características, es importante que no entendamos este paradigma como la solución para analizar un conjunto de grandes datos. Por ello, no presentan esa capacidad, salvo excepciones. Por otro lado, una cosa es denominarlo «tiempo real» y otra es realmente pensar que esto se va a producir en veradero tiempo tiempo. Las limitaciones aparecen por:

  • Se debe disponer de suficiente memoria  para almacenar entradas de datos en cola. Fíjense en la diferencia con el paradigma batch, donde los procesos de Map y Reduce podrían ser algo lentos, dado que escribían en disco entre las  diferentes fases.
  • La tasa de productividad del sistema debería ser igual o más rápida a la tasa de entrada de datos. Es decir, que la capacidad de procesamiento del sistema sea más ágil y eficiente que la propia ingesta de datos. Esto, de nuevo, limita bastante la capacidad de dotar de «instantaneidad al sistema».
Plataforma de analítica Big Data en tiempo real (Fuente: https://infocus.emc.com/wp-content/uploads/sites/8/2013/02/Real-time-Analytic-Platforms-Enable-New-Value-Creation-Opportunities.png)
Plataforma de analítica Big Data en tiempo real (Fuente: https://infocus.emc.com/wp-content/uploads/sites/8/2013/02/Real-time-Analytic-Platforms-Enable-New-Value-Creation-Opportunities.png)

Uno de los principales objetivos de esta nueva arquitectura es desacoplar el uso que se hacía de Hadoop MapReduce para dar cabida a otros modelos de computación en paralelo como pueden ser:

  • MPI (Message Passing Interface): estándar empleado en la programación concurrente para la sincronización de procesos ante la existencia de múltiples procesadores.
  • Spark: plataforma desarrollada en Scala para el análisis avanzado y eficiente frente a las limitaciones de Hadoop. Tiene la habilidad de mantener todo en memoria, lo que le da ratios de hasta 100 veces mayor rapidez frente a MapReduce. Tiene un framework integrado para implementar análisis avanzados. Tanto Cloudera, como Hortonworks, lo utilizan.

Y, con estos nuevos modelos, como hemos visto a lo largo de esta corta pero intensa historia del Big Data, aparecen una serie de tecnologías y herramientas que permiten implementar y dar sentido a todo este funcionamiento:

  • Flume: herramienta para la ingesta de datos en entornos de tiempo real. Tiene tres componentes principales: Source (fuente de datos), Channel (el canal por el que se tratarán los datos) y Sink (persistencia de los datos). Para entornos de exigencias en términos de velocidad de respuesta, es una muy buena alternativa a herramientas ETL tradicionales.
Flume (Fuente: http://blog.cloudera.com/wp-content/uploads/sites/8/2012/10/fig.png)
Flume (Fuente: http://blog.cloudera.com/wp-content/uploads/sites/8/2012/10/fig.png)
  • Kafka: sistema de almacenamiento distribuido y replicado. Muy rápido y ágil en lecturas y escrituras. Funciona como un servicio de mensajería y fue creado por Linkedin para responder a sus necesidades (por eso insisto tanto en que nunca estaríamos hablando de «Big Data» sin las herramientas que Internet y sus grandes plataformas ha traído). Unifica procesamiento OFF y ON, por lo que suma las ventajas de ambos sistemas (batch y real time). Funciona como si fuera un cluster.
Apache Kafka (Fuente: https://unpocodejava.files.wordpress.com/2012/12/image0019.jpg?w=780)
Apache Kafka (Fuente: https://unpocodejava.files.wordpress.com/2012/12/image0019.jpg?w=780)
  • Storm:  sistema de computación distribuido, por lo que se emplea en la etapa de análisis de datos (de la cadena de valor de un proyecto de Big Data). Se define como un sistema de procesamiento de eventos complejos (Complex Event Processing, CEP), lo que le hace ideal para responder a sistemas en los que los datos llegan de manera repentina pero continua. Por ejemplo, en herramientas tan habituales para nosotros como WhatsApp, Facebook o Twitter, así como herramientas como sensores (ante la ocurrencia de un evento) o un servicio financiero que podamos ejecutar en cualquier momento.

Vistas estas tres tecnologías, queda claro que la arquitectura resultante de un proyecto de tiempo real quedaría compuesto por Flume (ingesta de datos de diversas fuentes) –> Kafka (encolamos y almacenamos) –> Storm (analizamos).

Fuente: http://www.slideshare.net/Datadopter/the-three-generations-of-big-data-processing
Fuente: http://www.slideshare.net/Datadopter/the-three-generations-of-big-data-processing

Vistas todas estas características, podemos concluir que para proyectos donde el «tamaño» sea el *verdadero* problema, el enfoque Batch será el bueno. Cuando el «problema» sea la velocidad, el enfoque en tiempo real, es la solución a adoptar.

(continuará)

Oh my Goat!

Deja un comentario

(Artículo escrito por Miren Gutiérrez, directora del Programa Experto en Análisis, Investigación y Comunicación de Datos de la Universidad de Deusto)

El nuevo indicador de pobreza se visualiza con “mitras” y “coronas”: cuanto más elevada la mitra, más pobre el país (ver LIC o low income countries), cuanto más agudos los picos de la corona, más rico (ver HIC o high income countries).

hic lic

¿Es un nuevo indicador de Naciones Unidas? No, es un trabajo de un alumno del Programa Experto “Análisis, investigación y comunicación de datos” de Deusto.  Resulta que la presencia de cabras en un país está directamente relacionada con la pobreza.

Con esta premisa, Santiago López se  propuso “descubrir la verdad sobre la idea generalizada de que la cabra es un producto de regiones sin recursos o en desarrollo, o es una imagen transmitida por los films en los que se muestran regiones pobres con un niño pastoreando cabras. Ya que alternativamente las modernas tendencias culinarias y gastronómicas han añadido al conocido asado de cabrito, los exquisitos beneficios de la leche de cabra y de su delicioso queso de cabra”.

Resultó, además, que en la historia, conforme los países van desarrollándose, desde 1961 hasta 2013, el ganado caprino va desapareciendo (ver siguiente gráfico).

¿Cómo se ha hecho este estudio? Primero, los datos se obtienen de diversas fuentes oficiales y no oficiales, con métodos tan dispares como descarga de archivos xls y csv de fuentes de datos Open Data y con formación de datos mediante técnicas y herramientas de scraping de archivos pdf y páginas web. Y homogenizando datos de Excel con Google Refine, verificando la información, cantidades, superficies, etc., seleccionando años y realizando comparaciones de la hipótesis en series anuales para verificar su coherencia y evolución a través de los años.

Pero lo más interesante es la idea y la forma en que se ha comunicado.

Si te apetece aprender estas técnicas, pero sobre todo cómo encontrar historias en los datos y comunicarlas, apúntate al Programa Experto “Análisis, investigación y comunicación de datos” de Deusto.

Los datos de tu organización en valor

Escudo Universidad de deusto