Fundamentos de Big Data

📐 Fundamento

Las 5 V's:

1. Volumen — TB, PB, EB de datos.
2. Velocidad — datos llegando en tiempo real.
3. Variedad — estructurados, semi-estructurados, no estructurados.
4. Veracidad — calidad y confiabilidad.
5. Valor — capacidad de extraer insights.

OLTP vs OLAP — la distinción fundamental:

No mezclar: correr un reporte analítico (que escanea millones de filas) sobre la BD de producción puede ralentizar las operaciones. Por eso se separan.

Escalado vertical vs horizontal:

• Vertical (scale up): servidor más grande. Limitado físicamente, costoso.
• Horizontal (scale out): muchos servidores. Casi infinito, complejo.

Vertical:                      Horizontal:
┌──────────┐                   ┌──┐ ┌──┐ ┌──┐ ┌──┐
│   GIGA   │      vs           ├──┤ ├──┤ ├──┤ ├──┤
│  SERVER  │                   │__│ │__│ │__│ │__│
└──────────┘                   commodity hardware
costoso, límite físico        más complejo, escala infinita

Big Data es escalado horizontal — distribuir datos y cómputo entre muchos nodos.

📐 Fundamento

┌─────────────────────────────────────────────────────┐
│                  Sources (orígenes)                 │
│  Apps, APIs, IoT, BD operativas, archivos, logs    │
└──────────────────────┬──────────────────────────────┘
                       │ (ingesta)
                       ▼
┌─────────────────────────────────────────────────────┐
│      Streaming  (Kafka, Kinesis, Pub/Sub)           │
│      Batch      (Airflow, Fivetran, Airbyte)        │
└──────────────────────┬──────────────────────────────┘
                       │
            ┌──────────┴──────────┐
            ▼                     ▼
   ┌──────────────┐       ┌──────────────┐
   │  Data Lake   │       │ Data Warehouse│
   │  (S3, GCS)   │  ←──  │ (BigQuery,    │
   │  Raw, JSON,  │       │  Snowflake)   │
   │  Parquet     │       │  Estructurado │
   └──────────────┘       └──────────────┘
            │                     │
            ▼                     ▼
   ┌──────────────────────────────────┐
   │   Procesamiento (Spark, dbt)     │
   └──────────────────────────────────┘
                       │
                       ▼
   ┌──────────────────────────────────┐
   │   Consumo                        │
   │   - BI: Tableau, Looker, Metabase│
   │   - ML: notebooks, training      │
   │   - Apps: APIs analíticas        │
   └──────────────────────────────────┘

Roles típicos en un equipo de datos:

• Data Engineer: construye los pipelines (ingesta, transformación, almacenamiento).
• Analytics Engineer: modela datos para análisis (dbt).
• Data Analyst: crea dashboards y reportes (SQL, BI tools).
• Data Scientist: ML, predicciones, modelos.
• MLOps Engineer: despliegue y monitoreo de modelos en producción.

Modern data stack típico:

📐 Fundamento

Data Lake: almacén de datos en bruto, sin estructura forzada.

• Storage barato (S3, GCS).
• Cualquier formato (CSV, JSON, Parquet, imágenes, videos).
• Schema-on-read: la estructura se aplica al consumir.
• Ideal para datos exploratorios, ML, archivos.

Data Warehouse: datos estructurados, modelados para análisis.

• Schema-on-write: estructura forzada al ingestar.
• Optimizado para queries analíticas (columnar storage).
• Modelado dimensional (star schema).
• Ej: BigQuery, Snowflake, Redshift.

Data Mart: subset de un data warehouse para un dominio específico.

• Marketing tiene su mart, Finanzas otro.
• Más rápido de consultar, menos datos.

Lakehouse (concepto moderno): combina lo mejor de los dos.

• Usa data lake como storage barato.
• Agrega capa de metadata (Delta Lake, Iceberg, Hudi) para queries SQL eficientes.
• Plataformas: Databricks, Apache Iceberg.

Modelo tradicional:
  [Lake (raw)] → ETL → [Warehouse (modelado)] → [Marts]

Lakehouse moderno:
  [Lake con metadata (Delta/Iceberg)] ← funciona para todo

📐 Fundamento

CSV/JSON: legibles, pero ineficientes para análisis (texto, sin compresión).

Formatos columnares (estándares en Big Data):

¿Por qué columnar es mejor para análisis?

Query: SELECT AVG(precio) FROM ventas WHERE fecha = '2026-05-01'

CSV (row-based):
  fila1: id, fecha, producto, precio, vendedor, ...    ← lee todo
  fila2: id, fecha, producto, precio, vendedor, ...
  ...
  
Parquet (column-based):
  columna fecha:    [valores...]   ← lee solo esto para filtrar
  columna precio:   [valores...]   ← y esto para promediar
  (ignora las otras columnas)

Resultado: 10x menos datos leídos del disco.

Compresión:

import pandas as pd

# CSV típico: 1 GB
df = pd.read_csv('ventas.csv')

# Parquet con compresión Snappy: ~150 MB (6x más pequeño)
df.to_parquet('ventas.parquet', compression='snappy')

# Leer solo las columnas necesarias
df_filtrado = pd.read_parquet('ventas.parquet', columns=['fecha', 'precio'])

Particionamiento:

Organizar archivos en directorios por valor permite saltar particiones enteras al leer.

s3://la-esquina/ventas/
├── año=2026/
│   ├── mes=01/
│   │   ├── parte-0001.parquet
│   │   └── parte-0002.parquet
│   ├── mes=02/
│   └── ...
└── año=2025/
    └── ...

Query: SELECT * FROM ventas WHERE año = 2026 AND mes = 01
→ Solo lee s3://la-esquina/ventas/año=2026/mes=01/