- Introducción
- Video
- Contexto
- Alcance
- Deploy
- Dashboard
- Modelo-Recomendación
- Fuentes de datos
- Acerca de nosotros
- Stack tecnológico
Como parte de una consultora de datos, hemos sido contratados para llevar a cabo un análisis del mercado estadounidense. Nuestro cliente forma parte de un conglomerado de empresas relacionadas con restaurantes relacionadas al rubro fast food, y buscan obtener un análisis detallado de las opiniones de los usuarios en Yelp y cruzarlas con las de Google Maps en relación a dicho rubro. Utilizando análisis de sentimientos, nuestro objetivo es prever si el rubro fast food experimentará un mayor crecimiento o declive.
Además nuestro cliente desea determinar estratégicamente la ubicación de nuevos locales de restaurantes, implementando un sistema de recomendación de restaurantes fast food para usuarios en ambas plataformas. Con nuestro producto los clientes podran identificar oportunidades de creación o compra de negocios.
La retroalimentación de los usuarios, cada vez más abundante gracias a plataformas de reseñas, es un recurso valioso para los negocios de comida rápida. Yelp y Google Maps son dos plataformas destacadas que ofrecen reseñas específicamente para este tipo de establecimientos. Los usuarios comparten sus experiencias, proporcionando a las empresas de comida rápida una visión detallada de cómo son percibidas por sus clientes. Esta información resulta esencial para evaluar el rendimiento, utilidad y áreas de mejora de los servicios ofrecidos por cada local de comida rápida. La capacidad de los usuarios para tomar decisiones basadas en estas reseñas subraya la importancia crítica de mantener una imagen positiva en estas plataformas para el éxito comercial en la industria de la comida rápida.
El presente documento establece el alcance del proyecto de análisis de opiniones de usuarios
Elegimos realizar la visualizacion e interaccion con los dos productos terminados que ofrecemos, hacerlo a traves de una web. Esta web permite interactuar con los dos grandes resultados de nuestro trabajo:
- EL Dashboard
- El modelo entrenado de ML
Pero para que la la interfaz web pueda mostrar los datos, se tuvieron que realizar varias elecciones y trabajos previos que a continuacion se detallan de manera general, asi como algunas de las justificaciones de esas selecciones y los trabajos previos necesarios.
La WEB:
Streamlit como front-end framework general:
Su simplicidad de uso permitio que nos centremos en los aspectos fundamentales del trabajo enconmendado: obtener informacion en base a los datos. Su simple API no requiere conocimientos avanzados de configuracion de rutas, escribir y correr el back-end, manejar consultas HTTP, conectar el front-end, escrbir HTML, CSS, JS, etc. Si bien no tiene un alto nivel de configuracion sin incorporacion de otras herramientas, cumple su cometido sin problemas.
Docker como plataforma para contenedorizar la interfaz web:
Docker es una plataforma para generar unidades auto contenidas que tiene todo lo que la app necesita para correr y ejecutar su funcionalidad. A Estas unidades se las denomina contenedores y tienen las siguientes caracteristicas:
- Incluyen todas las dependencias: el codigo de la aplicacion, el runtime de ejecucion y las librerias se empaquetan juntas.
- Cada contenedor corre independientemente del resto, compartiendo el Kernel del sistema operativo pero no recursos.
- Son portables y pueden ser facilmente movidos entre diferentes entornos sin romper la aplicacion.
- Son mas eficientes que las maquinas virtuales al compartir el kernel.
La interfaz web esta integremente empacada en un contenedor de Docker (un estandar internacional).
Algunas de las librerias que se estan incluidas en el contenedor de la app:
- Python (3.9 Slim)
- Streamlit
- Pandas
- Numpy
- Slack
- Folium
- Google Cloud Bigquery y Google CLoud Storage
Google Cloud Run como servicio para realizar el deploy de la web:
Si bien Stremlit dispone de un servicio apto para realizar el deploy de manera simple y rapida (Streamlit Comunity Cloud), nos volcamos por realizarlo mediante Google Cloud Run porque:
- Docker es una de las tecnologias soportadas por Cloud Run, la cual recomienda en su documentacion (si bien admite deploys no-contenedorizados como Node JS o Go).
- Serverless: Cloud Run se encarga de la adminstracion e infraestrutura ante aumentos o disminuciones de trafico.
- Cambiando streamlit como front-end framework (por ejemplo por React JS), el deploy en la nube previo creado el contenedor, es identico.
El proceso para disponibilizar un endpoint publico de la web fue:
- Localmente crear el contenedor con todas las dependencias
- Subirlo a Google Artifact Registry: un repositorio de contenedores (y mas) en la nube.
- Crear el servicio en Google Cloud Run: como resultado de la creacion, se disponibiliza un endpoint publico para su consumo.
El Dashboard y el modelo de ML:
Para ambos, si bien responden a origenes de datos y objetivos diferentes, comparten el mismo camino en la nube:
- Los datos crudos provenentes de la informacion suministrada y alguna adicional que se sumo, se suben a Google Cloud Storage.
- Una funcion creada en Google Cloud Functions se gatilla cada vez que un Storage es actualizado tanto la primera vez, como toda vez que se agreguen datos nuevos.
- Esta funcion envia trabajos (Jobs) a Google Cloud DataProc para realizar tanto el ETL automatizado como para obtener el modelo de ML entrenado. Siempre se tienen en cuenta los datos nuevos, obteniendo nuevas versiones actualizadas de los datos.
- Algunas notificaciones son enviadas por Slack a medida que los procesos se cumplen satisfactoriamente.
- Los archivos con los trabajos terminados se guardan nuevamente en Google Cloud Storage para ser consumidos tanto por PowerBI (Dashborad) como por el front-end.
Este flujo de trabajo garantiza una correcta actualizacion y permanente disponibilidad de datos actualizados para la toma de decisiones.
Nota con respecto a la visualizacion de los mapas en el modelo de ML:
Para mantener el trafico de datos liviano entre los ordenadores que realizan las consultas y la nube en cuanto a la visualizacion de los puntos de interes en los mapas, se realizan internamente dos requests HTTP.
-
request 1: se envian los parametos seleccionados al modelo de ML entrenado que reside en la nube. Esta primera request devuelve solo entre 5 y 15 indices, correpondientes a la identificacion de los comercios relevantes de acuerdo al modelo elegido.
-
request 2: los indices son enviados nuevamente a la nube, de manera que la la busqueda y devolucion de los datos relevantes para ser representados son solo los que se dibujan. Esto hace que el trafico si bien se realiza dos veces, el volumen de datos es despreciable.
El proyecto se desarrollará en un período de 6 semanas, con tres sprint que son los siguientes:
-
Sprint 1: Puesta en macha del proyecto. 2 Semanas
- Inicialización del proyecto realizando mineria de datos y documentación del datawarehouse.
- Establecimiento del stack tecnologica que utilzaremos durante el proyecto.
- Implementamos la metodología SCRUM realizando daylis, para optimizar la producción.
- Realización de tareas puntuales como EDA, KPI's y diagrama de Gantt.
- Equipo de trabajo, Roles y responsabilidades.
-
Sprint 2: Data Engineering. 2 Semanas
- Realización de extracción transformación y carga de la data.
- Creación de un flujo automatizado anual, en el que nuestro cliente podra estar actualizado de forma automatica.
- Durante la creación del flujo automatico se nos notificará via el slack de la empresa las valizaciones de la tarea de manera automatica.
- Documentación: Diagrama entidad relación, Diccionario de datos, Workflow y tecnologías.
- MVP/ Proof of Concept de producto de ML ó MVP/ Proof of Concept de Dashboard.
-
Sprint 3: Data Analitics y Machine learning. 2 Semanas.
- Diseño de Dashboard realizado en power BI, vizualizado en la página web de la empresa.
- Creación de un modelo de recomendación para nuestro cliente y puesta en producción en la página web.
- Documentación: selección del modelo, feature engineering, informe de análisis.
- Video del proyecto realizado, para ser votado y, en caso de ganar, ser presentado en la graduación final.
El proyecto seguirá una metodología de trabajo en equipo que incluye las siguientes etapas:
Objetivo: Aumentar las respuestas de negocios en un 45% respecto al año anterior.
Objetivo: Aumentar un 10% las reviews positivas comparadas con el año anterior.
(Una review positiva es cuando recibe 4 o 5 estrellas)
Objetivo: Aumentar un 5% los reviews de sentimientos positivos respecto
al total de reviews comparados con el año anterior.
El proyecto se limita al análisis de datos disponibles en Yelp y Google Maps para el mercado estadounidense. La disponibilidad y calidad de los datos pueden afectar los resultados del análisis. El alcance del proyecto no incluye la implementación de sistemas en producción, sino la entrega de modelos y recomendaciones listos para su implementación.
Realizamos una página web interactiva a través de la herramienta streamlit mediante el cual presentamos nuestros productos desarrollados como son un dashboard y un modelo de recomendación.
Desarrollamos un dashboard interactivo que brinda información gráfica y detallada de nuestros análisis que permite visualizar de manera clara y concisa los insights obtenidos durante el proceso de análisis de mercado.
Nuestro modelo predictivo de machine learning con base en la proximidad geográfica, la evaluación de usuarios y la oferta de servicios, devuelve recomendaciones valiosas acerca de los negocios de comida rápida en Estados unidos.
| Marcelo Ortiz | Belén Viglioglia Becker | Alejandro Ramírez | Mariano Popov | Martín Riveros |
 |
 |
 |
 |
 |
| Data Analyst | Data Analyst | Data Engineer | Data Engineer | Data Science |
 |
|
|
|
|
 |
|
|
|
|
