Todas las entradas de: Álex Rayón

La problematización de los modelos Media en su reconversión industrial: el dato en el núcleo de la reformulación de su valor

(artículo escrito por Jon Goikoetxea Goiri, sociólogo y alumno de la primera promoción del Programa de Big Data y Business Intelligence, consultor en Marketing estratégico, analítico e Investigación de Mercados y exdirector de marketing de DEIA y GRUPO NOTICIAS -área de Estrategia y Medios Digitales- (2009-2016).

*********************************

La paradoja fundamental de la situación actual de los medios de comunicación -al menos desde el punto de vista de sus modelos de negocio– reside en que al desarrollo de la demanda no le acompaña simultáneamente una evolución positiva de sus modelos de negocio. Nunca anteriormente se consumió comunicación e información en semejante medida. Y, sin embargo, cada vez resulta más complicado hallar un solo medio de comunicación con sus cifras de negocio siquiera en equilibrio. Y ello a nivel mundial.

En los últimos decenios, y de manera significativamente más acelerada en los últimos años, la  transformación de los modelos de negocio de los medios de comunicación ha abarcado desde la reestructuración de la propuesta de valor de producto/servicio hasta el significado del consumo para el usuario, lector, espectador, oyente. El cambio en las pautas, la distribución, las  configuraciones de la demanda y, last but not least, en la esencia misma del ‘qué’ comunicativo: los antaño medios de información han devenido genéricos medios de comunicación. Los periódicos en amplísimas ediciones digitales. Las televisiones, en una multiplicidad de canales targetizados, formatos multiplataforma de emisión y con la incorporación del consumo diferido. Las radios, en la amplificación de sus programaciones a través de podcast y reemisiones a la carta.

La digitalización de la creación y distribución de contenidos audiovisuales ha convertido a la mera captación de la atención en el campo de batalla, en la sustancia, la naturaleza, en la materia prima del modelo Media actual. Ello ha afectado de manera definitiva a los soportes comunicativos tradicionales, y significadamente a la prensa al tratarse del único medio de pago, frente a radio, televisión y, actualmente, los medios digitales de orientación generalista.

Pero la digitalización también ha incluido a la generación de datos -al dato mismo- en la fórmula misma para aproximarse a la reformulación de su valor, para aprehender qué está ocurriendo con el sentido y las pautas de consumo de Medios. Para adaptar, expresado simplificadamente, la estructura de la oferta de medios a las nuevas configuraciones de la demanda, de la audiencia, del público. Al fin y al cabo, la digitalización es dato. En sí misma.

Comprender y dotar de sentido a lo que está ocurriendo es el pilar mismo de la reconversión industrial en la que se hallan los medios de comunicación. Ubicar el dato en el núcleo, la condición de posibilidad misma para la reformulación de su valor, o para ahondar en sus condiciones de monetización, si se prefiere el apremio.

Ese tránsito traumático de lo analógico a lo digital, ese salto abismal que puede metaforizarse en la conversión del módulo de prensa tradicional en herramientas de gestión de campañas de publicidad programática personalizada ha supuesto también la transformación de los paradigmas de análisis impactando directamente sobre las segmentaciones del marketing como base para la toma de decisiones. La complejidad del consumo de medios actual requiere de paradigmas analíticos a esa altura.

La tradicional estructura modular de la Prensa impresa camina dando pasos hacia ecosistemas de compra programática publicitaria, en entornos digitales (Fuente: IAB)
La tradicional estructura modular de la Prensa impresa camina dando pasos hacia ecosistemas de compra programática publicitaria, en entornos digitales (Fuente: IAB)

Y todo ello, por último, en un hábitat en el que el volumen, la variedad, la diversidad, y la velocidad de generación de datos de consumo e interacción de los usuarios crece extraordinariamente, muy probablemente por encima de la capacidad de empresas y organizaciones -de los medios de comunicación en su configuración actual- para organizarlos, dotarlos de un framework analítico sólido, productivo y continuo y digerirlos con orientación de generación de valor de negocio.

Una única cuestión es segura, entre todo: el dato estará en el centro del futuro de los medios de comunicación. Conformará el eje del cambio de paradigma que acompañará todo ello, desde la rutinaria perspectiva contenido-céntrica a una usuario-céntrica y dotada de esquemas de análisis que trasciendan los marcos actuales de comprensión del consumo de medios y contemplen algoritmos y modelizaciones de carácter más avanzado y complejo. A la altura analítica de lo que ocurre. El Big Data llama a las puertas del futuro de los medios de comunicación.

Tecnologías de ingesta de datos en proyectos «Big Data» en tiempo real

Cuando hablamos de las etapas que componían un proyecto de Big Data, y sus diferentes paradigmas para afrontarlo, una cuestión que cité fue la siguiente:

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”.

Hadoop, que marcó un hito para procesar datos en batch, dejaba paso a Spark, como plataforma de referencia para el análisis de grandes cantidades de datos en tiempo real. Y para que Spark traiga las ventajas que solemos citar (100 vez más rápido en memoria y hasta 10 veces más en disco que Hadoop y su paradigma MapReduce), necesitamos sistemas ágiles de «alimentación de datos». Es decir, de ingesta de datos.

Es el proceso por el cual los datos que se obtienen en tiempo real van siendo capturados temporalmente para un posterior procesamiento. Ese momento «posterior» es prácticamente instantáneo a efectos de escala temporal. Esto se está produciendo mucho, por ejemplo, en el mundo de los sensores y el  IoT (Internet of Things). No podemos lanzar alarmas en tiempo real si no contamos con una arquitectura como esta. Muchos sectores son ya los que están migrando a estas arquitecturas de ingesta de datos en un mundo en tiempo real.

Y es que el «tiempo real», el streaming, comienza ya desde la etapa de ingestión de datos. Tenemos que conectarnos a fuentes de datos en tiempo real, como decíamos, para permitir su procesamiento instantéano. En la era del Business Intelligence, e incluso en la era del «Big Data batch», los ETL eran los que permitían hacer estas cosas. Hemos hablado ya de su importancia. Sin embargo, son herramientas que en tiempo real, no ofrecen el rendimiento esperado, por lo que necesitamos alternativas.

ETL vs Spark (fuente: http://image.slidesharecdn.com/k2ionstoica-151028153637-lva1-app6892/95/spark-summit-eu-2015-revolutionizing-big-data-in-the-enterprise-with-spark-10-638.jpg?cb=1469144488)
ETL vs Spark (fuente: http://image.slidesharecdn.com/k2ionstoica-151028153637-lva1-app6892/95/spark-summit-eu-2015-revolutionizing-big-data-in-the-enterprise-with-spark-10-638.jpg?cb=1469144488)

Estas son el tipo de cosas que permiten hacer Spark y Storm, cuyo paradigma en tiempo real ya comentamos en su día. Aparecen, junto a ellos, 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.
  • 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). Es un sistema distribuido de colas, el más conocido actualmente, pero existen otros como RabbitMQ, y soluciones en la cloud como AWS Kinesis.
  • Sistemas de procesamiento de logs, donde podemos encontrar tecnologías como LogStash, Chukwa y Fluentd.

Con estas principales tecnologías en el menú, LogStash y Flume, se han convertido en las dos principales soluciones Open Source para lo que podríamos bautizar como «ETL en tiempo real». Es decir, para la necesidad de recoger datos en tiempo real. La ingesta de datos como etapa de un proyecto de Big Data.

Y, de este modo, nacen «packs tecnológicos» alternativos al ETL como es EFK, acrónimo de Elastic Search + Flume + Kibana. Se trata de una plataforma para procesar datos en tiempo real, tanto estructurados como no estructurados. Todo ello, con tecnologías Open Source, lo que podría venir a animar a  muchas empresas que lean esta noticia, y entiendan el valor que tiene esto para sus seguras necesidades (cada vez más) en tiempo real.

  • Elastic Search: motor de búsqueda, orientado a documentos, basado en Apache Lucene.
  • Flume: ejcución de procesos de extracción, transformación y carga de datos de manera eficiente.
  • Kibana: dashboards en tiempo real, procesando y aprovechando los datos en tiempo real indexados vía Elastich Search.

Con todo esto, quedarían esquemas tecnológicamente muy enriquecidos y útiles para necesidades de negocio como el que se presenta a continuación:

Proyectos Big Data en tiempo real (Fuente: http://www.slideshare.net/Stratio/meetup-es-efk)
Proyectos Big Data en tiempo real (Fuente: http://www.slideshare.net/Stratio/meetup-es-efk)

Como podéis apreciar, en estos ecosistemas, los ETL ya no cumplen la función que han venido desempeñando históricamente. Su rendimiento en tiempo real es realmente bajo. Por lo que tenemos que dar un paso más allá. E introducir nuevas tecnologías de ingestión de datos. Kakfa, Flume, Elastic Search, etc., son esas tecnologías. Si tu empresa está empezando a tener problemas con el datamart tradicional, o si la base de datos ya no da mucho más de sí, quizás en este ecosistema tecnológico tengamos la solución.

Nosotros, en nuestro Programa de Big Data, todo esto lo vemos durante 25 horas, montando una arquitectura en tiempo real que dé respuesta a las necesidades de empresas que cada vez necesitan más esto. Las tecnologías de ingesta de datos al servicio de las necesidades de negocios en tiempo real.

Del «Big Data» al «Data Capital»: aprovechando el valor de los datos con un data lake

Hay dos grandes formas de entender esta era del Big Data: como una evolución del Business Intelligence -herramientas que extraen inteligencia de la información de una compañía y sobre ésta elaboran algunas predicciones-, o como una disrupción. La primera consideración, suele descartarla.

El Business Intelligence, se significó en una época en la que eran los datawarehouse la norma. Es decir, grandes almacenes de datos, estructurados, con una administración rígida. No solo ya desde la óptica del almacenamiento del dato es diferente su consideración, sino también desde la mirada de procesamiento de datos. El BI tenía un marcado carácter descriptivo. En esta nueva era del Big Data, creo que la predicción es la norma y lo que todo el mundo quiere hacer. Adelantarse al futuro, pero de una manera más informada y evidenciada. Es decir, asentándose en la mayor cantidad de información posible.

Y esto, claro, como hemos comentado muchas veces, es más posible que nunca antes en la historia, por la gran cantidad de datos existentes. Pero, son datos, que muchas veces, no podemos estructurar (la lógica seguida por los datawarehouse). Son datos, además, que muchas veces, no se pueden «juntar» con otros; es mejor mantenerlos por separado, y luego ya tratar de juntarlos en tiempo de procesamiento para la extracción de valor.

Fuente: http://2.bp.blogspot.com/-dfr85pnA6R0/VtRjMG1rrUI/AAAAAAAAAHA/xsv2qhPtLIo/s302/Francisco%2BJavier%2BCervigon%2BRuckauer.jpg
Fuente: http://2.bp.blogspot.com/-dfr85pnA6R0/VtRjMG1rrUI/AAAAAAAAAHA/xsv2qhPtLIo/s302/Francisco%2BJavier%2BCervigon%2BRuckauer.jpg

Esta lógica, va un paso más allá dentro del paradigma del Big Data. Supone considerar el dato como otro activo más. Es más, supone considerar el dato como el activo más crítico de la organización. Y así, disponer de un «data capital», como otro activo más de la organización, que permita ser luego capitalizado y activado para su puesta en valor en la organización. Es decir, el almacenamiento en bruto de datos, puede ser interesante, sin mayor orden, estructura ni criterio de clasificación.

El problema es que en este momento, la mayor parte de las empresas (tanto grandes, medianas como pequeñas), está aún en la fase inicial: recopilan la información y la almacenan. Pero todavía no saben muy bien qué se puede hacer con ella. Por ello mismo, ya hay algunos que empiezan a considerar que en este estadío, en el que todavía las organizaciones no saben muy bien qué hacer, pero sí que disponen de datos, es fundametal articular una estrategia de almacenamiento de datos con sentido.

Y aquí, emerge con fuerza el concepto de «data lake». Como se puede ver en la siguiente representación gráfica, se trata de un repositorio de datos estructurados y no estructurados, sin ningún preprocesamiento, guardando los datos en bruto, y sin esquema. A los que venimos originariamente de la administración de bases de datos y sus esquemas rígidos, un concepto, un paradigma, sustantivamente diferente. Al carecer de esquema, añadir nuevos datos, será relativamente fácil.

Fuente: Microsoft
Fuente: Microsoft

Se trata, en definitiva, de proveer a las empresas de un mecanismo de almacenamiento de datos sin mayor compromiso. Ya veremos en qué momento se nos ocurre qué hacer. El problema que veníamos arrastrando, es que los sistemas de esquemas de datos, en muchas ocasiones, condicionaban luego lo que poder hacer con los datos. Porque ya representaban «algo».

Con esta explicación, se puede entender por qué esta era del Big Data, es para mí un paso más allá del Business Intelligence. En la era del BI, todos los datos que recogíamos (estructurados y no estructurados), los ordenábamos y clasificábamos según el esquema. En un data lake, también recogemos todos los datos, pero no los alteramos, limpiamos o manipulamos. Su valor queda bruto, y ya veremos en su día qué hacer con ello.

Sin alterar la «materia prima» y dejarla en bruto, dejamos abierto el campo de explotación. Y estas opciones, tan prometedoras para muchas empresas, es lo que está haciendo que cada vez más empresas me pregunten por los data lakes. Es algo que para la capitalización del dato dentro de las organizaciones, se alinea muy bien. Ya veremos algún día qué preguntas hacerles a los datos. Todavía no lo sabemos, pero no nos importa. Sabemos que esos datos tendrán valor.

Por todo esto, ya hay muchos profesionales del Big Data que dicen de cambiar el paradigma ETL (Extract, Transform, Load, del que ya hablé aquí) por ELT (Extract, Load, Transform). Es decir, ya transformaremos después, no antes, lo que suele restringir mucha las opciones de lo que podremos hacer. Los data lakes, precisamente adoptan ese rol de almacén de datos «neutro», en el que no condicionamos luego lo que se podrá hacer. Y por eso, las herramientas ELT (que no son nuevas, por otro lado), también pudieran vivir un renacimiento.

Para cerrar, una imagen muy representativa de la idea trasladada hoy.

Data Lake vs Data Warehouse (Fuente: http://www.martinsights.com/wp-content/uploads/sites/8/2014/09/Data-lake-vs-Data-warehouse.jpg)
Data Lake vs Data Warehouse (Fuente: http://www.martinsights.com/wp-content/uploads/sites/8/2014/09/Data-lake-vs-Data-warehouse.jpg)

 

Cómo el Big Data puede ayudar a percibir de manera más segura tu ciudad

En este blog, hemos hablado de ciudades ya en otras ocasiones (aquí, aquí y aquí). Es uno de los campos en los que el «mundo del dato», más está aportando. Básicamente, porque las vivas y dinámicas de una ciudad del Siglo XXI, son núcleos generadores de datos, que también se pueden beneficiar mucho del uso de los mismos.

Son varios ya los investigadores que están tratando de introducir las bondades del análisis de datos masivo en la mejora del bienestar de una ciudad. Desde el MIT Media Lab que hace «crowdsourcing» de los datos para determinar cómo de seguras son unas calles, pasando por el uso de los datos para el diseño, el trazado urbano, etc.

Uno de los investigadores que más se está moviendo en este campo es César Hidalgo. Considera que la visión e inteligencia artificial, son campos técnicos que tienen mucho que aportar a un nuevo campo dentro del conjunto de las ciudades: el impacto social del diseño de una ciudad. En el sentido, de entender cómo las decisiones que se toman a nivel urbano y de diseño, puede impactar en la sensación de seguridad (o no) de los ciudadanos. A esto lo llamo el «impacto social».

¿Y qué pintan todo esto la visión e inteligencia artificial? Durante muchos años, no hemos tenido tecnología a nuestra disposición para entender cómo la estética y el diseño de las ciudades impactaba en las decisiones de los ciudadanos a la hora de transitar por las ciudades. Es justo esto lo que Hidalgo, junto con Marco de Nadai y Bruno Lepri narran en un artículo que presentaron en la próxima ACM Multimedia Conference 2016 celebrada en Octubre en Amsterdam.

Proponen, para testar dicha hipótesis, usar dos teorías ampliamente conocidas en el mundo del diseño de la ciudad:

Para poder testar estas teorías, se apoyaron en una red neuronal. Lo primero, como ya sabemos, es entrenarla. Para ello, utilizaron los datos de Place Pulse, una web desarrollada por Hidalgo en 2013, que pedía a los usuarios que opinasen sobre diferentes imágenes de ciudades, para saber así si les parecían «seguras» o no.

Imágenes y seguridad (Fuente: http://pulse.media.mit.edu/)
Imágenes y seguridad (Fuente: http://pulse.media.mit.edu/)

Con la red neuronal entrenada (una «deep convolutional neural network«), comenzaron a analizar miles de imágenes de Google StreetView para tratar de encontrar las características de la ciudad que hacían a sus ciudadanos sentirse más seguros. Para relacionar esos datos con el comportamiento de los ciudadanos, cruzaron los datos con los de los dispositivos móviles. Así, quedaba fijada la relación entre las decisiones humanas dentro de la ciudady las características de las mismas. Todo esto, lo han testado en las dos ciudades Italianas más importantes (Roma y Milan).

Las conclusiones obtenidas son bastante claras:

  • Las calles que la red consideraba como «más seguras» son precisamente por donde más gente discurre.
  • Personas con más de 50 años, así como mujeres caminando solas, buscan zonas más seguras.
  • Personas con menos de 30 años, frecuentan sitios menos seguros.

Esta red neuronal, en consecuencia, puede ser considerada como una primera aproximación a la posibilidad de detectar qué partes de una ciudad son percibidas como menos seguras. Y así, ayudar a los legisladores a establecer puntos de mejora en sus ciudades. Es más, Hidalgo y el resto de autores, probaron diferentes opciones para ver cómo las interpretaba la red neuronal. y vieron como elementos como coches aparcados, paredes en blanco, grandes aceras vacías y la oscuridas, eran percibidas como sitios con poca seguridad. Y es que el diseño de ciudades, tiene implicaciones sociales que ya veis, no siempre había sido fácil de detectar.

En todo esto, como podéis ver, el cruce de datos aparece como protagonista nuclear de la película. Y es que la » V» de variedad, como he comentado en reiteradas ocasiones, veremos tiene cada vez más protagonismo. Quedan todavía muchas aplicaciones que pongan en valor el «Big Data» por hacer. Pero todas ellas comparten interés por cruzar datos de diferentes fuentes. Una ciudad, entre ellas.

Evento 17/11/2016: «Las oportunidades de la Inteligencia de Cliente aplicadas al Retail» (Deusto – Bilbao)

 

CABECERA-INGENIERIA-PLANTILLAS
Las oportunidades de la Inteligencia de Cliente aplicadas al Retail
La Facultad de Ingeniería de la Universidad de Deusto en colaboración con Eroski organiza una jornada dirigida a profesionales en torno al Retail y el Big Data.

El procesamiento del enorme volumen de datos y su trasformación en conocimiento es la base de grandes oportunidades en el sector de la Distribución y del Gran Consumo. Estamos asistiendo a grandes avances, tanto en la optimización de procesos como en la personalización de la relación con los clientes, aportándoles soluciones de mayor valor para ellos.

Regístrate

 

Programa:
9: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 Programas Big Data.
  • Ana Cuevas, Directora Proyectos Estratégicos de Marketing,  Grupo Eroski.
10:30 Mesa Redonda y Debate

  • Alex Rayón, Vicedecano-Universidad de Deusto (moderador)
  • Ana Cuevas, Directora Proyectos Estratégicos de Marketing,  Grupo Eroski
  • Iñaki Pariente, Socio Director Dayntic Legal
  • Maider Hormaza, Directora comercial y marketing de Kaiku Corporacionalimentaria
  • David Ruiz,  CEO Smartup
  • Félix Diez, Director Innovación Versia
11:30 Finalización de la Jornada y Café Networking

 

calendar 2
17 Noviembre 
mapa2
 
Sala Garate
Universidad de Deusto

Bilbao
reloj 2
10:00-11:30
Para más información:

bigdata.deusto.es
formacion.ingenieria@deusto.es
944 139 208
Abierta la matricula
BDBI 2017 en Bilbao
© 2016 University of Deusto – All right reserved

 

CABECERA-INGENIERIA-PLANTILLAS
Bezeroen adimenaren aukerak txikizkako merkataritzara aplikatuta
Deustuko Unibertsitateko Ingeniaritza Fakultateak profesionalentzako jardunaldi bat antolatu du, Eroskiren laguntzaz, txikizkako merkataritzaz eta Big Dataz.

Datu kopuru eskerga prozesatzea eta hori guztia ezagutza bihurtzea da aukera askoren oinarria banaketa eta kontsumo handiaren sektorean. Aurrerakuntza handien lekuko gara, bai prozesuen optimizazioan, bai bezeroekiko harremanaren pertsonalizazioan, eta horrek balio handiagoko soluzioak ematen dizkiete bezeroei.

Erregistratu

  

Egitaraua:
 9:45  Izen ematea eta erregistratzea (Doakoa/Free)
10:00  Jardunaldiaren aurkezpena eta aukeren aurrerapena

  • Alex Rayón, Ingeniaritza Fakultateko Kanpo Harremanetako eta Etengabeko Prestakuntzako dekanordea eta Big Data eta Business Intelligence Programaren zuzendaria.
  • Ana Cuevas, Marketineko Proiektu Estrategikoen zuzendaria, Eroski Taldea. 
10:30  Mahai-ingurua eta eztabaida

  • Alex Rayón, Dekanordea-Deustuko Unibertsitatea (moderatzailea)
  • Ana Cuevas, Marketineko Proiektu Estrategikoen zuzendaria, Eroski Taldea 
  • Iñaki Pariente, Dayntic Legal-enbazkide-zuzendaria
  • Maider Hormaza, Kaiku Elkargintza Korporazioko merkataritza eta marketineko zuzendaria
  • David Ruiz, Smartup-en CEO-a
  • Félix Diez, Versia-ren Berrikuntzako zuzendaria
11:30  Jardunaldiaren amaiera eta Networkinga, kafe bat hartuz

 

calendar 2
Azaroak 17 
mapa2
 
Garate Aretoa
Deustoko Unibertsitatea
Bilbo
reloj 2
10:00-11:30
Informazio gehiago:

bigdata.deusto.es
formacion.ingenieria@deusto.es
944 139 208
© 2016 University of Deusto – All right reserved

Expectativas y realidades con el Big Data

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»

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

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?

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)

(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.