Archivo de la categoría: Analisis

Oracle’s Machine Learning and Advanced Analytics 12.2 and Oracle Data Miner 4.2 New Features | Oracle Data Mining (ODM) Blog

Presentación de las nuevas funcionalidades incorporadas en Oracle 12.2 para trabajar con Machine Learning y análisis de datos a través de Oracle’s Machine Learning and Advanced Analytics 12.2 and Oracle Data Miner 4.2 New Features | Oracle Data Mining (ODM) Blog

Anuncios

El análisis de datos y la interpretación de resultados

Oracle DBInsights Forum

El pasado miércoles 20 de abril se celebró en Madrid el Oracle DBInsights Forum. La mañana se dedicó casi de manera íntegra al análisis de datos o Data Science. Pau Agulló, director de Kernel Analytics, presentó tres casos prácticos en los que se habían empleado diferentes técnicas de análisis:

  • Mejora de la relevancia para personalizar las ofertas de una empresa de ventas flash.
  • Predicción de la demanda y gestión de stock en la gran distribución.
  • Expansión óptima de red: cómo mejorar la planificación de las inversiones en la red canalizada de una empresa de gas.

Los tres casos resultaron de gran interés y mostraban cómo el análisis de datos podía aprovechar la información disponible para mejorar aspectos muy distintos del negocio o las inversiones de estas empresas. Pero a mi me llamó especialmente la atención la primera de ellas dedicada a la mejora de la relevancia. Pau Agulló nos explicó los pasos que siguieron en el desarrollo de este proyecto desde el punto de vista del análisis de datos y cómo lograron aumentar las ventas a través de la personalización de la oferta.

Vamos a sintetizar los puntos más importantes de su presentación aprovechando la metodología que proponen Roger D. Peng y Elizabeth Matsui en su libro The Art of Data Science y las cinco etapas del análisis de datos:

Art of Data Science

En el libro The Art of Data Science se describe la metodología que subyace a todo proyecto en Data Science, siempre en opinión de sus autores, y que definen como una iteración de cinco etapas:

  1. Definición de las preguntas a resolver.
  2. Exploración de datos.
  3. Modelado de datos.
  4. Interpretación de los resultados.
  5. Comunicación de los resultados.

Cada una de estas cinco etapas se centra en un aspecto determinado del análisis. Pero al mismo tiempo, es importante revisar continuamente los resultados obtenidos en etapas anteriores para verificar si se mantiene la línea prevista o se ha producido alguna desviación que debamos revisar. Este aspecto del análisis es el más importante: la revisión continua de los resultados con respecto a las expectativas. En todo proyecto de análisis de datos, a medida que se va profundizando, se descubren nuevos enfoques que, no con poca frecuencia, nos empujan a replantearnos alguna de las etapas anteriores o incluso el propio marco de trabajo. Los autores del libro llaman a esta revisión continua Epicycles of Analysis y lo dividen en tres bloques:

  • Definición de expectativas.
  • Recopilación de datos.
  • Cotejo de las expectativas con los datos recopilados.

Estos epiciclos se deben repetir en cada una de las cinco grandes etapas del análisis.

La presentación que hizo Pau Agulló en el Oracle DBInsights Forum siguió perfectamente este modelo de trabajo:

1. Definición de las preguntas a resolver

La pregunta que definía el proyecto sobre mejora de la relevancia era la siguiente:

¿Cómo mejorar las recomendaciones que la empresa de ventas flash enviaba todos los días a sus usuarios por correo electrónico?

2. Exploración de datos

Esta etapa se centra en evaluar la información disponible y refinar la pregunta inicial para evitar resultados ambiguos, sesgos o detectar la necesidad de recopilar nuevos datos.

En el caso presentado, lo habitual es centrarse en los datos obtenidos a través de las siguientes fuentes:

  1. Ventas: es la fuente más importante en cuanto a calidad del dato pero la menos frecuente por su cantidad.
  2. Carritos abandonados.
  3. Clicks en boletines de noticias.
  4. Navegación por la web: la fuente menos relevante por su calidad pero más abundante en cantidad.

3. Modelado de datos

En el modelado de datos se busca una serie de procesos y algoritmos que se puedan estandarizar y que nos permitan tratar los datos disponibles para mejorar la comprensión de los mismos. En otras palabras, establecer un protocolo para tratar los datos disponibles y extraer de ellos la mayor información relevante posible: convertir los datos en conocimiento.

El objetivo principal en los sistemas de mejora de la relevancia es reducir el tiempo necesario para que un cliente encuentre el producto que le interesa. Para lograrlo se pueden utilizar diferentes vías complementarias entre sí:

  • Cálculo de afinidad: comparación entre elecciones de distintos clientes.
  • Diversificación de oferta: productos vinculados que pertenezcan a otras categorías.
  • Objetivos del negocio: mejorar el volumen de ventas o el margen en cada operación.

En el caso expuesto, una vez establecido el modelo de datos, se hizo un reparto de los envíos de correos electrónicos entre las recomendaciones habituales y las nuevas recomendaciones personalizadas mediante los criterios del modelo desarrollado. Esto permitió completar el epiciclo de análisis en el modelado de datos mediante el cotejo de las expectativas con los datos recopilados en cada uno de los escenarios.

4. Interpretación de los resultados

Los autores del libro The Art of Data Science introducen el capítulo sobre la interpretación de resultados advirtiendo de que esta tarea, en realidad, se pone en práctica en todas y cada una de las etapas del análisis de datos. Es inevitable que las personas involucradas en un proyecto de análisis interpreten los distintos resultados parciales que se obtiene a medida que se avanza en el trabajo. Al mismo tiempo, reivindican la importancia de dedicar un espacio exclusivo para la interpretación, una vez tratados los datos, creados los modelos y cotejados los resultados para sacar las conclusiones finales.

En el proyecto de mejora de la relevancia se comparó el resultado de ventas que provenían de los boletines de ofertas generales y las ventas provenientes de los nuevos boletines elaborados con el modelo de datos. Se buscaba determinar en qué medida las diferencias observadas respondían a la personalización de la oferta o a factores ajenos al modelo (por ejemplo, sesgos en la muestra de usuarios escogida para la prueba).

5. Comunicación de los resultados

El resultado final fue muy satisfactorio para el modelo de datos que se había desarrollado: lograron mejoras en las ventas a través de una selección personalizada de las ofertas a destacar. Estos resultados fueron presentados en distintos ámbitos, como es natural. Entre otros, en el propio Oracle DBInsights Forum.

El recomendador de películas y la interpretación de resultados

En una charla posterior se comentó la siguiente anécdota:

“Ayer por la noche estaba en el salón buscando una película para ver y escogí una de las recomendadas. Al cabo de veinte minutos de película ya no aguantaba más. Era terrible. Así que la paré, me fui a la cocina a beber algo y, a la vuelta, me puse otra película.

Ahora caigo en que el algoritmo de recomendación habrá etiquetado la primera película como visionada y como un acierto del sistema de recomendación. Lo normal -nos explicó- es que a los diez minutos de reproducción una película se considere como visionada. Y lo que en realidad ocurrió es que me pareció una película espantosa y por eso la dejé de ver.”

Esta pequeña historia nos sirvió para comentar lo difícil que resulta en algunos casos interpretar unos hechos a través de las trazas que registramos en los sistemas informáticos. Y se plantearon muchas hipótesis que podrían haber explicado esta misma cadena de sucesos. Vamos a exponer alguna de ellas:

En primer lugar, los datos sobre los que trabajamos fueron:

  • Un usuario de una plataforma de vídeos a la carta selecciona una película recomendada y empieza a verla.
  • A los 20 minutos se interrumpe la reproducción.
  • 5 minutos más tarde empieza la reproducción de otra película.

Estos datos, por supuesto, encajaban perfectamente en lo que realmente sucedió: el usuario dejó de ver la película para ver otra diferente. Esto podría indicar claramente que la primera elección no le gustó. Especialmente porque no interrumpió la visualización sin más, como si hubiera tenido que atender algo urgente que le impidiera seguir con la película. Si no que al cabo de 5 minutos inició una película distinta. Parece muy claro, ¿verdad?

Pero en seguida surgió una explicación alternativa: ¿y si no fue la misma persona la que inició la reproducción de la segunda película? Atendiendo solo a los datos recogidos, también cabe la posibilidad de que la primera persona se puso una película pero tuvo que interrumpirla por algo más urgente que le impidió seguir viéndola. A los 5 minutos, una persona distinta aprovechó que la televisión estaba libre para poner una nueva película.

En la conversación fueron apareciendo, poco a poco, otros relatos que incluían los mismos puntos involucrados en situaciones muy diferentes y, por lo tanto, interpretaciones también muy variadas.

En definitiva, solo se trataba de un recomendador de películas automático. Incluso nuestros mejores amigos, que conocen bien nuestros gustos, se equivocan en algunas recomendaciones.

SQL vs R

Introducción

Vamos a realizar una breve comparativa entre SQL y R. Para ello nos centraremos en los aspectos básicos del acceso a datos, mostrando ejemplos de las mismas operaciones en ambos lenguajes.

En junio de 2015 Oracle publicó el documento SQL – the natural language for analysis en el que se describen los fundamentos del lenguaje SQL y las ventajas que ofrece en el campo del acceso y análisis de datos:

http://www.oracle.com/technetwork/database/bi-datawarehousing/wp-sqlnaturallanguageanalysis-2431343.pdf

Éste documento será nuestra guía en la pequeña comparativa que sigue a continucaión.

Preparación del entorno

El juego de datos que se utiliza en los ejemplos del documento son las conocidas tablas EMP y DEPT, que tradicionalmente han acompañado a Oracle. Desde R se puede acceder a una gran variedad de fuentes de datos, entre las que se incluyen bases de datos, ficheros, recursos web, etc.

En este caso, para acceder a los datos de las tablas Oracle desde R, primero los volcaremos a un fichero con estructura CSV y los cargaremos utilizando la librería de R “DPLYR”.

Las siguientes sentencias SQL nos pueden servir para generar la estructura CVS:

select '"EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO"' from dual
union all
select EMPNO||',"'||ENAME||'","'||JOB||'",'||MGR||','||HIREDATE||','||SAL||','||COMM||','||DEPTNO
from emp;
select '"DEPTNO","DNAME","LOC"' from dual
union all
select DEPTNO||',"'||DNAME||'","'||LOC||'"'
from dept;

Después de guardar los datos de EMP y DEPT en disco con formato CSV será necesario copiar ambos ficheros en una ruta a la que se tenga acceso desde el entorno de ejecución de R (por ejemplo, un subdirectorio “./data” dentro del espacionde trabajo) y ejecutar los siguientes comandos:

library(dplyr)
emp <- tbl_dt(read.csv("./data/emp.csv",stringsAsFactors = FALSE))
dept <- tbl_dt(read.csv("./data/dept.csv",stringsAsFactors = FALSE))

Principios de SQL

El lenguaje SQL se compone de cuatro operadores básicos:

  • Projection
  • Filter
  • Join
  • Aggregate

Projection

El operador projection permite indicar las columnas que queremos recuperar de una tabla. En su forma básica, se indican las columnas existentes por su nombre o posición en la tabla.

SELECT ename, job, hiredate
FROM emp;
ENAME	JOB		HIREDATE
-----	---------	--------------------
KING	PRESIDENT	17-NOV-1981 00:00:00
BLAKE	MANAGER		01-MAY-1981 00:00:00
CLARK	MANAGER		09-JUN-1981 00:00:00
JONES	MANAGER		02-APR-1981 00:00:00
-- Next lines were deleted
emp %>%
select(ENAME, JOB, HIREDATE)
Source: local data table [14 x 3]

    ENAME       JOB             HIREDATE
    (chr)     (chr)                (chr)
1    KING PRESIDENT 17-NOV-1981 00:00:00
2   BLAKE   MANAGER 01-MAY-1981 00:00:00
3   CLARK   MANAGER 09-JUN-1981 00:00:00
4   JONES   MANAGER 02-APR-1981 00:00:00
# Next lines were deleted

La proyección, en su forma extendida, permite generar columnas dinámicas aplicando operaciones que son calculadas en tiempo de ejecución.

SELECT ename, sal, comm, comm/sal*100 as COMM_RATE
FROM emp;
ENAME	SAL	COMM	COMM_RATE
-----	----	----	---------
KING	5000	- 	-
BLAKE	2850	- 	-
CLARK	2450	- 	-
JONES	2975	- 	-
SCOTT	3000	- 	-
FORD	3000	- 	-
SMITH	800	- 	-
ALLEN	1600	300	18.75
WARD	1250	500	40
MARTIN	1250	1400	112
TURNER	1500	0	0
ADAMS	1100	- 	-
JAMES	950	- 	-
MILLER	1300	- 	- 
emp %>%
mutate(COMM_RATE = COMM/SAL*100) %>%
select(ENAME,SAL,COMM,COMM_RATE)
Source: local data table [14 x 4]

    ENAME   SAL  COMM COMM_RATE
    (chr) (int) (int)     (dbl)
1    KING  5000    NA        NA
2   BLAKE  2850    NA        NA
3   CLARK  2450    NA        NA
4   JONES  2975    NA        NA
5   SCOTT  3000    NA        NA
6    FORD  3000    NA        NA
7   SMITH   800    NA        NA
8   ALLEN  1600   300     18.75
9    WARD  1250   500     40.00
10 MARTIN  1250  1400    112.00
11 TURNER  1500     0      0.00
12  ADAMS  1100    NA        NA
13  JAMES   950    NA        NA
14 MILLER  1300    NA        NA

Filter

El operador filter permite indicar una serie de reglas que deben cumplir los datos almacenados para ser recuperados en la consulta. En su forma más sencilla comparan los valores de la tabla con una expresión.

SELECT ename, job, hiredate
FROM emp
WHERE job = 'CLERK';
ENAME	JOB	HIREDATE
------	-----	--------------------
SMITH	CLERK	17-DEC-1980 00:00:00
ADAMS	CLERK	12-JAN-1983 00:00:00
JAMES	CLERK	03-DEC-1981 00:00:00
MILLER	CLERK	23-JAN-1982 00:00:00
emp %>%
filter(JOB == "CLERK") %>%
select(ENAME, JOB, HIREDATE)
Source: local data table [4 x 3]

   ENAME   JOB             HIREDATE
   (chr) (chr)                (chr)
1  SMITH CLERK 17-DEC-1980 00:00:00
2  ADAMS CLERK 12-JAN-1983 00:00:00
3  JAMES CLERK 03-DEC-1981 00:00:00
4 MILLER CLERK 23-JAN-1982 00:00:00

Join

El operador join relaciona distintas tablas a través de la comparación de uno o varios de sus campos. Existen varios tipos de join dependiendo de la forma en la que va a realizar el cruzado de los datos: inner, full outer, outer left, outer right y cross.

SELECT d.deptno, d.dname, e.empno, e.ename
FROM dept d INNER JOIN emp e
 ON (e.deptno = d.deptno);
DEPTNO	DNAME		EMPNO	ENAME
------	----------	-----	------
10	ACCOUNTING	7782	CLARK
10	ACCOUNTING	7934	MILLER
10	ACCOUNTING	7839	KING
20	RESEARCH	7902	FORD
20	RESEARCH	7788	SCOTT
-- Next lines were deleted
emp %>%
inner_join(dept, by = c("DEPTNO"="DEPTNO")) %>%
select(DEPTNO,DNAME,EMPNO,ENAME)
Source: local data table [14 x 4]

   DEPTNO      DNAME EMPNO  ENAME
    (int)      (chr) (int)  (chr)
1      10 ACCOUNTING  7839   KING
2      10 ACCOUNTING  7782  CLARK
3      10 ACCOUNTING  7934 MILLER
4      20   RESEARCH  7566  JONES
5      20   RESEARCH  7788  SCOTT
# Next lines were deleted

Aggregate

El operador aggregate ejecuta operaciones sobre grupos, o sets, de datos.

SELECT SUM(sal) AS total_salary
FROM emp;
TOTAL_SALARY
------------
29025
emp %>%
summarise(total_salary = sum(SAL))
Source: local data table [1 x 1]

  total_salary
         (int)
1        29025

Este operador es especialmente importante en el análisis de datos porque permite acotar las operaciones a rangos o agrupaciones de los datos sobre los que estamos trabajando.

SELECT deptno,
       COUNT(empno) AS no_of_employees,
       SUM(sal) AS total_salary,
       AVG(sal) AS average_salary
FROM emp
GROUP BY deptno;
DEPTNO	NO_OF_EMPLOYEES	TOTAL_SALARY	AVERAGE_SALARY
------	---------------	------------	----------------------------------------
30	6		9400		1566.66666666666666666666666666666666667
20	5		10875		2175
10	3		8750		2916.66666666666666666666666666666666667
emp %>%
group_by(DEPTNO) %>%
summarise(no_of_employees = length(EMPNO),total_salary = sum(SAL), average_salary = mean(SAL))
Source: local data table [3 x 4]

  DEPTNO no_of_employees total_salary average_salary
   (int)           (int)        (int)          (dbl)
1     10               3         8750       2916.667
2     30               6         9400       1566.667
3     20               5        10875       2175.000