Untitled

INFORME DE EVALUACIÓN PARCIAL N° 1

ANÁLISIS DE VENTAS EN TIEMPO REAL PARA E-COMMERCE MEDIANTE MAKE.COM Y GOOGLE CLOUD PLATFORM

Sigla: AVY1101
Asignatura: Big Data
Estudiantes: Maximiliano Castillo-21.629.250.2, Sebastian Hurtado-
Fecha: 07-04-2026
Profesor: Vicente Julio Zapata Valenzuela

ÍNDICE

1. Introducción
2. Justificación de Big Data (IL 1.1)
3. Propuesta de Herramientas GCP (IL 1.2)
4. Gobierno de Datos y Ciclo de Vida (IL 1.3)
5. Arquitectura de Referencia (IL 1.4)
6. Conclusión
7. Anexos

1. INTRODUCCIÓN

• El proyecto aborda la ingesta y análisis de ventas de E-commerce (Amazon) generadas por Make.com.
• Los datos generados incluyen:
  • id_cliente
  • cliente
  • producto
  • precio
  • cantidad
  • monto
  • forma_pago
  • fecreg
• Se requiere una solución en Google Cloud Platform (GCP) para procesamiento en tiempo real.

2. JUSTIFICACIÓN DE BIG DATA (IL 1.1)

• Se justifica el uso de Big Data por el cumplimiento íntegro de las 5 V's:
  • Volumen:
  • Justificación Técnica:
    • Escalable hasta terabytes durante eventos como CyberDay.
    • BigQuery permite manejar petabytes de datos sin degradación del rendimiento.
    • Herramientas tradicionales como Excel y SQL Server colapsan ante este volumen.
  • Velocidad:
  • Los datos llegan en tiempo real mediante Webhook.
  • Utilizando Cloud Pub/Sub y Dataflow, se garantiza una latencia menor a 60 segundos.
  • El ETL Batch nocturno es considerado obsoleto.
  • Variedad:
  • Los datos son semi-estructurados en formato JSON.
  • Veracidad:
  • Mecanismos para asegurar la calidad de los datos.
  • Valor:
  • Dashboard en Looker Studio con KPIs en vivo:
    • Ventas totales
    • Producto estrella ("Amazon")
    • Detección de anomalías en pagos
• Conclusión IL 1.1:
  • Herramientas tradicionales no soportan velocidad, volumen ni variedad que se requieren.
  • Se requiere un stack de Big Data robusto en GCP.
  • Posibilidad de añadir campos (cupon, region) sin previo aviso, gestionados eficientemente por BigQuery que tiene evolución de esquema nativa sin necesidad de ALTER TABLE.
  • En Dataflow, se valida que monto = precio * cantidad.
  • Los registros inválidos se envían a Dead Letter Queue (Pub/Sub) para garantizar datos confiables.

3. PROPUESTA DE HERRAMIENTAS EN GCP (IL 1.2)

3.1. Stack Tecnológico Nativo GCP (4 On-Premise + 1 Cloud)

3.2. Herramientas NO Adecuadas

• Hadoop MapReduce:
  • Motivo de Exclusión: Latencia inaceptable (minutos/horas). Diseñado para procesamiento Batch, no para tiempo real.
• Cloud SQL (MySQL):
  • Motivo de Exclusión: Cuello de botella en escrituras masivas, no optimizado para analítica.
• Power BI (Import):
  • Motivo de Exclusión: Trabaja con datos estáticos y requiere refresco manual. Se debe usar DirectQuery sobre BigQuery.

4. GOBIERNO DE DATOS Y CICLO DE VIDA (IL 1.3)

4.1. Prácticas de Gobierno de Datos

• Validación:
  • Se valida que monto = precio * cantidad.
  • Registros erróneos se envían a Dead Letter Queue en Pub/Sub.
• Visualización:
  • Utilización de Looker Studio, que es un dashboard nativo conectado a BigQuery, permite actualización automática.

Herramientas Descartadas

• Hadoop MapReduce:
  • Latencia inaceptable.
• Cloud SQL (MySQL):
  • Cuello de botella en escrituras masivas.
• Power BI (Import):
  • Requiere refresco manual.

4.2. Ciclo de Vida del Dato (4 Fases)

1. Captura:
   • Cloud Function recibe solicitud POST desde Make.com y publica en Pub/Sub.
2. Almacenamiento (Hot):
   • Pub/Sub retiene datos por 7 días.
   • BigQuery almacena datos validados para consultas en vivo.
3. Archivado (Cold):
   • BigQuery mueve datos con antigüedad de más de 90 días a almacenamiento frío automáticamente, reduciendo costos en un 50%.
4. Eliminación:
   • Política de retención en BigQuery: se eliminan datos con más de 5 años.
   • Pub/Sub elimina datos después de 7 días.

5. ASOCIACIÓN A ARQUITECTURA DE REFERENCIA (IL 1.4)

5.1. Arquitectura Seleccionada: Lambda Light Speed Layer

• Streaming:
  • Flujo: Make.com → Cloud Functions → Pub/Sub → Dataflow (Streaming) → BigQuery (buffer)
  • Latencia <60 segundos.
• Seguridad y Privacidad:
  • Implementación de IAM + encriptación:
  • TLS 1.3 en tránsito
  • AES-256 en reposo
  • Data Masking en BigQuery para ocultar el nombre del cliente.

5.2. Mapeo de Componentes

5.3. Modo de Procesamiento: Combinación (Real-Time + Batch)

• Real-Time:
  • Visibilidad intra-día de ventas y stock del producto "Amazon".
• Batch:
  • Cálculo de KPIs históricos complejos (LTV de clientes).
• Elementos adicionales:
  • Data Catalog: Para gestión de metadatos (podría faltar).
  • Capa Batch: Puede omitirse en la fase inicial (MVP).

5.4. Análisis de Beneficios (4 Aspectos Característicos)

Aspecto - Beneficio Aplicado

1. Escalabilidad:
   • GCP ofrece un sistema serverless que escala automáticamente sin requerir la provisión de servidores.
   • Costo cero en inactividad.

6. CONCLUSIÓN

• El proyecto cumple con las 5 V's del Big Data, justificando el uso de Google Cloud Platform como solución.
• Se propone una arquitectura Lambda Light que utiliza Cloud Functions, Pub/Sub, Dataflow y BigQuery.
• Se incorpora prácticas de Gobierno de Datos enfocadas en calidad y seguridad, así como un Ciclo de Vida completo de datos (captura, almacenamiento, archivado, eliminación).
• La solución es escalable, segura y alineada con los indicadores IL 1.1 a IL 1.4.

7. ANEXOS

7.1. Estructura JSON (Make.com)

json { "id_cliente": "6", "cliente": "Carolina López", "genero": "M", "id_producto": "1", "producto": "Amazon", "precio": 151.48, "cantidad": 2, "monto": 302.96, "forma_pago": "Débito", "fecreg": "7 de abril de 2026 11:28" }

7.2. Diagrama de Arquitectura (Make.com + GCP)

• Se requiere incluir un diagrama ilustrativo que detalle el flujo de información desde Make.com hacia GCP, destacando las funciones y servicios utilizados.

7.3. Comparativa: GCP vs AWS vs Azure

• Se presenta una comparativa detallada en base a funcionalidades y costo-eficiencia.

Justificación

• GCP ofrece la mejor relación costo-rendimiento para este caso académico/profesional, eliminando la necesidad de administración de infraestructura.

7.4. Referencias y Notas Técnicas

• Run ID Make.com: b518b70b3b7f47458be514b4417669d7
• Endpoint: https://bdrealtimeescuelait.duoc.cl
• Tecnologías utilizadas: Python 3.11, Apache Beam SDK 2.50+, BigQuery Storage API.
• Cumplimiento LGPD/GDPR: Los datos personales (cliente) son enmascarados mediante Vistas Autorizadas en BigQuery.