Predicción de ganancias en R

En este post se quiere dar una pequeña introducción a la predicción de las ganancias en ventas utilizando modelos de regresión lineal en R.

R es un lenguaje y ambiente  de programación para el análisis estadístico, es uno de los lenguajes mas utilizados para la investigación, con R podemos utilizar la data desde cualquier fuente de datos ya sea Excel, CSV, incluso conectarse con una base de datos y utilizarla para realizar este tipo de análisis, esta es una de las grandes ventajas con R ya que podemos utilizar la data cualquier forma que venga, manipularla y obtener resultados.

Los modelos de regresión lineal se basan en la relación entre una variable dependiente y una o mas variables independientes, los modelos de regresión lineal son utilizados para la predicción de los valores de la variable dependiente, se debe llegar a utilizar las variables dependientes correctas para tener un modelo mas preciso y llegar a tener una diferencia entre los valores predichos y la variable dependiente sea mínimo.

Los datos para realizar el ejemplo se obtuvieron de un csv que Pentaho brinda para hacer pruebas, este set de datos es un ejemplo de ventas de vehículos del año 2003 a inicios del 2005. En la data tenemos las columnas ORDERNUMBER, QUANTITYORDERED, PRICEEACH, ORDERLINENUMBER, SALES, STATUS, QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINE, MSRP, PRODUCTCODE, CUSTOMERNAME, CITY,  STATE, COUNTRY, PRODUCTLINEID, STATE_ID.

Para este post se realizo un script en R y se pretende demostrar como aplicar el modelo linear y predecir las ventas en este caso de vehículos, se agrego el link para descargar el ejemplo.

Si se quiere ver mas a fondo como se realizo este ejemplo, se puede descargar el código fuente, para ejecutarlo cargamos el script R  y ejecutamos la función :

   > predictSales()

 La funcionalidad de este script es con un modelo lineal describir la relación entre la ganancia y la información con la que se cuenta de los pedidos como por ejemplo la ciudad, fecha y el producto, y al final de la ejecución mostrar un gráfico que muestra las ganancias reales y las que genera el modelo. 

Al ejecutar el script se genera un gráfico con las ventas del año 2003 a inicios del 2005.

En este ejemplo se tomaron como variables independientes QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINEID, STATE_ID y como variable dependiente la ganancia. En R se puede generar un resumen del modelo con lo que podemos obtener valores como el error residual estándar, los grados de libertad, valos que nos indican que tan funcional es nuestro modelo e ir mejorando el modelo cambiando las variables dependientes para obtener un modelo mas eficiente. 

El error residual estándar es la diferencia entre los valores reales y los valores estimados de la regresión, en este caso se obtuvo un error residual estándar de 1,4077.55, este es un valor muy elevado por lo que se debe mejorar el modelo, a continuación se muestra la gráfica generada en R, en negro se muestra la ganancia obtenida de forma mensual y en rojo los valores estimados de la regresión linear. 

En la segunda parte de este post se explicara como mejorar el modelo para estar mas cerca de los valores reales y se estará prediciendo el numero de ordenes de un vehículo para ciertos estados, con esto se podrían tomar mejores decisiones para lograr mayores ganancias.

El código de este ejemplo se encuentra en Github. 

Watch Download

Muchas Gracias.

La importancia menospreciada de la aplicación de índices en un proyecto de BI/DWH

A diferencia de nuestros anteriores posts , este post no esta enfocado al analista de negocio o el tomador de desiciones que utiliza el data warehouse y el sistema o aplicaciones analiticas de inteligencia de negocios, si no que esta mas enfocado al equipo técnico detrás de un proyecto de este tipo(project managers,arquitectos de sistemas, desarrolladores de sistemas,administradores de sistemas y de bases de datos,ingenieros de datos,etc).

Todo aquel que haya tomado un curso de bases de datos, conoce la importancia de la apliacion de índices para mejorar el desempeño de una base de datos,pero la pregunta es , cuantas personas o equipos detrás de la construcción y mantenimiento de un sistema aplican lo aprendido en la teoría para mejorar el funcionamiento de un sistema real en su día a día? . Lamentablemente la respuesta es que muy pocas personas(o casi ninguna) lo hacen a pesar de que de manera académica se ve su importancia y los beneficios obtenidos, esto por muchas posibles razones,según mi experiencia y charlas con colegas ingenieros de sistemas, algunas de estas razones son:

• La constante presión y tiempos apretados para proyectos de este tipo obligan a que el equipo “funcione” y cumpla su objetivo, sin importar si lo hace de manera óptima y eficiente.
• Aun que la importancia de los indices es recalcada en los cursos, la teoría nunca se pone en práctica ya que los cursos universitarios se enfocan en un buen diseño de la base de datos pretendiendo cumplir con los requerimientos funcionales,sin dar importancia a el rendimiento del sistema.
• Muchas personas, no conocen la importancia(o incluso que es) de la aplicación de indices nisiquiera de manera teorica ya que el curso se enfoca en crear un buen diseño y sentencias y herramientas de implementacion y manipulación de ese diseño.
• Muchas veces el adminsitrador de bases de datos piensa que es tarea del desarrollador y el desarrollador piensa que es tarea del administrador de base de datos. En realidad es una tarea conjunta en donde ambos deberían de aportar , el desarrollador comunmente tiene un mayor conocimiento y detalle de la manera y frecuencia en que las aplicaciones acceden a la información y el administrador de base de datos conoce como esta realiza internamente estos accesos.
• Simplemente al equipo no le importa o es algo para lo que no se desea invertir esfuerzo.

En el ámbito de proyectos y sistemas de inteligencia de negocios y data warehouse, este problema se presenta aún con mas frecuencia a pesar de que debería de ser mas importante ya que uno de los objetivos de un sistema de Dwh es agilizar y minimizar el tiempo de acceso a la información, en este caso el problema se presenta debido a las razones ya mencionadas(agendas apretadas,desconocimiento del tema, mala planificación,indiferencia) y otras razones tales como:

• Se utiliza un motor de base de datos optimizado para sistemas analiticos(por ejemplo motorores de bases de datos columnares) y se tiene la falsa creencia o se escucha el falso mito, de que estos motores de base de datos, no necesitan(o incluso no poseen) indices. (Ver al final del post : Ejemplo Aplicado)
• Se tiene la falsa creencia ,de que al tener la información en un diseño optimizado para analisis(como un modelo estrella) se hace innecesario contar con indices ya que no hay manera de agilizar el acceso a la información.
• Nuevamente , mala planificación y no contar con tiempo en la agenda para realizar esto.

En mi experiencia trabajando para una consultora con expertise en BI/DWH , la aplicación de indices nunca estuvo en el plan del proyecto , y se contemplaba como una alternativa, hasta que el performance del sistema se veía degradado.

Según los expertos(y creadores originales) de las técnicas y patrones del modelado dimensional para sistemas de BI/DWH , el diseño de un plan de índices es tan importante, como el diseño del modelo dimensional ,el tiempo para esta actividad debe estar contemplado en el plan del proyecto y debe ser realizado posteriormente(al menos en una versión inicial) justo después de tener el diseño del modelo dimensional realizado y un perfilamiento inicial de la data realizado(para conocer cantidad de registros,tipos de datos , valores unicos en cada tabla). Para mayor información de esto , se puede consultar la metodología o ciclo de vida Kimball y el libro “The Data Warehouse Lifecycle Toolkit”

Ejemplo 

Como se mencionó, una de las razones por las cuales erróneamente no se aplican índices en un sistema de BI/DWH ,es que muchas veces se utiliza un motor de base de datos optimizado para analíticos, por ejemplo una base de datos columnar(como amazon Redshift o Sybase IQ) y se tiene la idea equivocada de que esto hace innecesaria la aplicación de índices, o incluso que el motor de base de datos no brinda esta característica.

En mi experiencia en multiples proyectos con motores de base de datos columnares ,esta fue una tarea menospreciada y olvidada en muchas ocasiones ,pero cuando se presento la necesidad de realizara, se obtuvieron beneficios destacables,por ejemplo para el motor de base de datos columnar Sybase IQ(al igual que la mayoría en el mercado) ofrece multiples tipos de indices y cada tipo se encuentra destinado a cierta tarea, según factores como:

• Tipo de dato
• Cardinalidad de valores en una tabla
• Es una columna utilizada para un join?
• Es una dimension o un indicador?

Para el caso de amazon redshift, el concepto de indice no aplica en el sentido convencional, pero este maneja diferentes conceptos tales como sortkeys,distribution keys y encoding. Que tipo de cada uno de estos aplicar depende mucho de la estructura , cardinalidad , uso(por ejemplo si es ROLAP o OLTP,para ROLAP si es dimension o fact table)  , como ejemplos tenemos:

• Para surrogate keys conviene usar encoding o compresion tipo delta.
• Para llaves foraneas(en una fact table) a dimensiones con cardinalidad menor a 255 valores, usar bytedict(equivalente a indices bitmap en Sybase IQ).

pero los beneficios pueden ser enormes, tanto en performance como en storage(lo cual se traduce en ahorro de dinero).

Referencias utiles

•   Para aprender mas sobre índices en general(para los motores de base de datos mas comunes) consultar:
  • el libro: “SQL Performance Explained” de Markus Winand
  • El sitio: http://use-the-index-luke.com/
    
• Para aprender mas sobre la metodología Kimball , y sus recomendaciones sobre el plan y aplicación de indices, consultar:
  • “The Data Warehouse Lyfecycle Toolkit”
  • “The Data Warehouse Toolkit”
• Para aprender mas sobre los diferentes tipos de indices y su aplicación en el motor SAP Sybase IQ, consultar mi siguiente post :)   

Un poco más allá de reportes

Cuando se escucha hablar sobre el BI (Business Intelligence) dentro de las empresas, es muy común a que se refieran a este como la sección que realiza los reportes de la empresa. Un departamento en el cual se le pide un reporte de forma periódica, lo vemos en una hoja de cálculo, se le pide a lo sumo una cuantas operaciones aritméticas, estadísticas y una gráfica de barras.

Es cierto que el departamento de BI puede realizar este tipo de requerimientos pero es solo una mínima parte del potencial que se puede llegar a tener un departamento de BI. Las empresas generan data de formas muy diferentes y de distinto índole, tanto como lo es en en el aspecto comercial sino también del funcionamiento en sí de la empresa. Pero la data en sí no representa mucho, el potencial se encuentra escondido en este mar de data y por eso es fundamental poder procesarla y poder obtener información, pero muchisimo mas importante es la interpretación que se le pueda dar.

Uno de los aspectos a tomar en cuenta y que se puede pensar que es algo lógico pero muchas veces no se le da la importancia necesaria es: la data. Es el corazón de todo, ya que de nada sirve tener definido los tipos de análisis que se realizarán, las herramientas más complejas y modernas que se encuentren disponibles en el mercado para la presentación, el último motor de base de datos en nuestro datawarehouse,  sino tenemos una data que valga la pena analizar. Se debe contar con una data limpia, confiable y certificada. Tenemos que tener reglas claras para el manejo de la data, datos nulos, el manejo de apropiado de texto. Cuando se maneja tablas dimensionales como por ejemplo en un modelo estrella tener las llaves subrogadas de forma apropiada, si se maneja una tabla de comportamiento en el tiempo (Slow change dimension) tener claro cuánto cambio en el registro vamos a tener, definiendo el detalle de cambio que queremos guardar. Se debe de contar con una data en la cual podamos realizar las operaciones y análisis con toda la certeza de que los valores que representa la data son los correctos, sin necesidad de preocuparnos por algún registro cuyo valor esté fuera de lo normal, la fuente de datos sea la correcta y no alguna temporal o emergente.

Es importante contar con suficiente data para analizar, ya que se si realizara análisis de comportamiento o análisis de series de tiempo no es posible realizar un análisis confiable con un set de datos pequeño en cuestión de historia guardada. Se debe contar data que cubran diferentes series de tiempo,  años, lustros, etc. para realmente encontrar patrones de comportamiento y poder realizar comparaciones respecto de alguna posicion del tiempo.

Ya con nuestras herramientas y la materia prima lista, nos podemos preguntar ¿qué esperamos de estos análisis? Dependiendo del negocio que se está analizando existen diferentes tipos de análisis, una empresa comercial tendria interes en conocer si sus promociones han tenido impacto en los consumidores de forma esporádica e instantánea o realmente han elevado las transacciones en cada consumidor, fue correcto el segmento de clientes que eligieron para dicha promoción dado las características de estos. Si la empresa está teniendo una disminución de clientes, qué características tienen estos, es posible plantear un plan de retención que sea lo suficientemente atractivo para los clientes. Para esto se cuentan con diferentes modelos análisis como análisis de regresión, árboles de decisión, redes neuronales, SVM, Deep Learning, entre otras; las cuales pueden llegar a tener diferentes objetivos como ser un análisis predictivo o un analisis de clasificacion.

Con estas herramientas podemos descubrir nueva formas de estrategias para  alimentar la toma de decisiones dentro del negocio de una forma más analitica con un respaldo matemático bastante sólido.

Con esto podemos tener un departamento de BI involucrado en el negocio y no solamente un departamento de reportería.