Cuándo los datos son «big»: ticks, libros, opciones y universos.

«Big» es una relación, no un tamaño

Un fichero de 10 GB es pequeño para un servidor con 1 TB de memoria y enorme para un portátil de 16 GB. Y una tabla de 2 GB puede no caber en ese portátil si hay que unirla con otra, ordenarla y agruparla. La definición útil para un quant es operativa: los datos son grandes cuando el cálculo que necesitas no cabe con holgura en la memoria de la máquina que tienes. De ahí salen las tres preguntas de esta lección: cuántos registros hay, cuántos bytes ocupa cada uno en la representación que uses y cuánta memoria extra pide cada operación.

Wes McKinney, creador de pandas, lo resumió en 2017 en una regla práctica: con pandas conviene tener de 5 a 10 veces el tamaño de los datos en RAM; para un conjunto de 10 GB, de 64 a 128 GB. La regla es de antes de pandas 3 y de Arrow como formato por defecto, pero el mecanismo que la explica sigue ahí y se mide más abajo: los datos ocupan más en memoria que en el fichero, y cada operación crea copias intermedias.

La lección 1.3.1 midió una sesión de la acción ficticia NOVA en cada granularidad, de la barra diaria a los mensajes del libro L3: de 1 fila a más de medio millón. Aquí se pasa de una acción a un mercado.

flowchart TB
  B[Barras] --> T[Operaciones]
  T --> Q[Cotizaciones L1]
  Q --> L2[Libro L2]
  L2 --> L3[Libro L3]

• Barras (diarias o de minutos): un registro por instrumento y periodo, con apertura, máximo, mínimo, cierre y volumen.
• Operaciones (trades): un registro por ejecución.
• Cotizaciones L1 (quotes): el mejor precio de compra y de venta, un registro por cada cambio.
• Libro L2: la profundidad agregada por nivel de precio, en fotos o en actualizaciones por nivel.
• Libro L3 (market by order): cada orden y cada cambio de cada orden; con él se reconstruye el libro completo.

Cada paso a la derecha multiplica el número de registros. Las opciones lo multiplican otra vez: cada subyacente tiene cientos o miles de series (vencimientos por strikes por tipo) y cada una cotiza en varios mercados.

Un mensaje de 36 bytes

El protocolo TotalView-ITCH 5.0 de Nasdaq difunde el libro L3 de su mercado como una secuencia de mensajes binarios. La especificación fija cada campo: enteros sin signo en orden de bytes de red (big endian), textos ASCII rellenos con espacios, la hora en nanosegundos desde medianoche en 6 bytes y los precios como enteros con 4 decimales implícitos. El mensaje de una orden nueva (Add Order, tipo A) ocupa 36 bytes:

La primera celda genera una sesión sintética de 2 millones de operaciones en 500 valores ficticios (T000 a T499, con la actividad concentrada en los primeros, como en un mercado real) y la escribe en ese formato binario. NumPy lee el binario sin copiarlo con un tipo estructurado que reproduce la tabla; como NumPy no tiene enteros de 6 bytes, la hora se lee como un entero de 2 bytes y otro de 4. Los datos son sintéticos: no son datos de mercado.

import gc
import os
import tracemalloc

import numpy as np
import pandas as pd
import pyarrow as pa
import pyarrow.parquet as pq

rng = np.random.default_rng(661)
N = 2_000_000
VALORES = np.array([f"T{i:03d}" for i in range(500)])
peso = 1 / np.arange(1, 501) ** 1.1
i_valor = rng.choice(500, N, p=peso / peso.sum())
ns = np.sort(rng.integers(34_200, 57_600, N) * 10**9      # 9:30-16:00
             + rng.integers(0, 10**9, N))
precio = np.round(rng.gamma(2.0, 40.0, 500)[i_valor]
                  * np.exp(rng.normal(0, 0.002, N)), 2)
acciones = rng.geometric(0.02, N).astype(np.int32)
lado = rng.choice(np.array(["B", "S"]), N)

ADD_ORDER = np.dtype([
    ("tipo", "S1"), ("locate", ">u2"), ("tracking", ">u2"),
    ("ts_alto", ">u2"), ("ts_bajo", ">u4"), ("referencia", ">u8"),
    ("lado", "S1"), ("acciones", ">u4"), ("valor", "S8"),
    ("precio", ">u4")])
msg = np.zeros(N, ADD_ORDER)
msg["tipo"], msg["locate"] = b"A", i_valor + 1
msg["ts_alto"], msg["ts_bajo"] = ns >> 32, ns & 0xFFFFFFFF
msg["referencia"] = np.arange(1, N + 1)
msg["lado"] = lado.astype("S1")
msg["acciones"] = acciones
msg["valor"] = np.char.ljust(VALORES[i_valor], 8).astype("S8")
msg["precio"] = np.round(precio * 10_000).astype(np.uint32)
binario = msg.tobytes()

leido = np.frombuffer(binario, ADD_ORDER)      # sin copiar
m = leido[0]
hora = (int(m["ts_alto"]) << 32) | int(m["ts_bajo"])
print(f"{ADD_ORDER.itemsize} bytes por mensaje; "
      f"{len(binario) / 2**20:.1f} MiB en total")
print(m["valor"].decode().strip(), m["lado"].decode(),
      int(m["acciones"]), int(m["precio"]) / 10_000,
      pd.Timedelta(hora, "ns"))

36 bytes por mensaje; 68.7 MiB en total
T001 S 55 36.52 0 days 09:30:00.018014726

Dos millones de mensajes ocupan 68,7 MiB, exactamente 36 bytes cada uno, y leerlos no cuesta nada: np.frombuffer interpreta los bytes en su sitio, sin copiarlos ni convertirlos. El primero es una venta de 55 acciones de T001 a 36,52 a las 9:30:00,018. Es el formato más compacto de esta lección y el menos cómodo: los enteros están en orden de red, el símbolo lleva espacios, la hora va partida y el precio es un entero. Para analizar hay que convertirlo, y la conversión tiene un precio en memoria.

La misma operación en pandas, Arrow y Parquet

Del binario a una tabla de análisis: hora como fecha, valor, precio, acciones, mercado de ejecución y lado. Se miden cinco representaciones de los mismos datos. En pandas, memory_usage(deep=True), que con objetos de Python cuenta el tamaño de cada objeto como si no se compartiera con ninguna otra celda: es un límite superior. En Arrow, nbytes. En Parquet, el tamaño del fichero comprimido con zstd, que se borra después.

mercado = rng.choice(np.array(list("NQPZKVJX")), N)
base = pd.Timestamp("2026-10-22")
columnas = {"ts": base + pd.to_timedelta(ns, "ns"),
            "valor": VALORES[i_valor], "precio": precio,
            "acciones": acciones, "mercado": mercado,
            "lado": lado}
TEXTOS = ["valor", "mercado", "lado"]

con_str = pd.DataFrame(columnas)            # pandas 3: tipo str
con_objetos = con_str.astype({c: object for c in TEXTOS})
compacto = con_str.astype({c: "category" for c in TEXTOS})
tabla = pa.Table.from_pandas(compacto, preserve_index=False)
pq.write_table(tabla, "operaciones.parquet", compression="zstd")

bytes_fila = {
    "binario ITCH (Add Order)": ADD_ORDER.itemsize,
    "pandas, objetos de Python":
        con_objetos.memory_usage(deep=True).sum() / N,
    "pandas, tipo str (Arrow)":
        con_str.memory_usage(deep=True).sum() / N,
    "pandas, categorías": compacto.memory_usage(deep=True).sum() / N,
    "Arrow, diccionarios": tabla.nbytes / N,
    "Parquet zstd (disco)": os.path.getsize("operaciones.parquet") / N,
}
os.remove("operaciones.parquet")
for nombre, b in bytes_fila.items():
    print(f"{nombre:<27} {b:6.1f} B/fila   "
          f"{b * N / 2**20:6.1f} MiB")
print(compacto.dtypes.astype(str).to_dict())

binario ITCH (Add Order)      36.0 B/fila     68.7 MiB
pandas, objetos de Python    173.0 B/fila    330.0 MiB
pandas, tipo str (Arrow)      50.0 B/fila     95.4 MiB
pandas, categorías            24.0 B/fila     45.8 MiB
Arrow, diccionarios           24.0 B/fila     45.8 MiB
Parquet zstd (disco)          10.0 B/fila     19.1 MiB
{'ts': 'datetime64[ns]', 'valor': 'category', 'precio': 'float64', 'acciones': 'int32', 'mercado': 'category', 'lado': 'category'}

La misma sesión ocupa de 10 a 173 bytes por operación según cómo se guarde:

• Con objetos de Python (el object de pandas 2), cada texto es un objeto con su cabecera (más de 40 bytes por una cadena de cuatro letras) y la columna guarda un puntero de 8 bytes a cada uno: 173 bytes por operación, casi cinco veces el mensaje binario. La cifra es un límite superior, porque memory_usage(deep=True) cuenta cada objeto aunque varias celdas compartan el mismo, pero da el orden de magnitud.
• Con el tipo str de pandas 3, que guarda los textos en un array de Arrow (los caracteres seguidos más un desplazamiento de 8 bytes por celda), baja a 50.
• Con categorías, cada texto repetido se guarda una vez y cada fila lleva un código pequeño: 2 bytes para 500 valores, 1 para 8 mercados o 2 lados. Quedan 24 bytes por fila, menos que el binario, porque solo se guardan los campos que se analizan: 8 de la hora, 8 del precio, 4 de las acciones y 4 de los tres códigos.
• Arrow con diccionarios (la traducción de las categorías) ocupa lo mismo, 24 bytes.
• Parquet con zstd baja a 10 bytes en disco: comprime bien porque las horas están ordenadas y los códigos se repiten. Pero es un formato de disco, no de memoria: para trabajar con los datos hay que descomprimirlos.

Pasar de objetos a categorías divide la memoria por siete sin perder información. Es la primera palanca, y casi siempre la más barata.

Lo que pide cada operación

Que una tabla quepa en memoria no significa que se pueda trabajar con ella. Cada operación de pandas crea resultados intermedios: un índice de ordenación, las claves de los grupos, la tabla unida antes de devolverla. El módulo tracemalloc de la biblioteca estándar registra las reservas de memoria de Python y de NumPy (no las de Arrow, que tiene su propio gestor; por eso se mide con la tabla de categorías, que está toda en NumPy) y da el pico de memoria desde que se activa. La celda mide cuatro operaciones habituales sobre el primer millón de operaciones, con el pico expresado en veces el tamaño de la tabla:

muestra = compacto.iloc[:1_000_000].copy()
tam = muestra.memory_usage(deep=True).sum()
sectores = pd.DataFrame({"valor": VALORES,
                         "sector": np.arange(500) % 11})
OPERACIONES = {
    "ordenar por valor y hora":
        lambda d: d.sort_values(["valor", "ts"]),
    "VWAP por valor":
        lambda d: ((d["precio"] * d["acciones"])
                   .groupby(d["valor"], observed=True).sum()
                   / d.groupby("valor", observed=True)
                   ["acciones"].sum()),
    "barras de 1 minuto por valor":
        lambda d: d.groupby(["valor", d["ts"].dt.floor("min")],
                            observed=True)["precio"]
                   .agg(["first", "max", "min", "last"]),
    "unir con el sector":
        lambda d: d.merge(sectores.astype({"valor": "category"}),
                          on="valor"),
}

def pico(funcion, datos):
    gc.collect()
    tracemalloc.start()
    resultado = funcion(datos)
    maximo = tracemalloc.get_traced_memory()[1]
    tracemalloc.stop()
    del resultado
    return maximo

picos = {k: pico(f, muestra) / tam for k, f in OPERACIONES.items()}
print(f"tabla: {tam / 2**20:.1f} MiB")
for nombre, veces in picos.items():
    print(f"{nombre:<30} pico {veces:4.1f} veces la tabla")

tabla: 22.9 MiB
ordenar por valor y hora       pico  2.8 veces la tabla
VWAP por valor                 pico  1.3 veces la tabla
barras de 1 minuto por valor   pico  3.2 veces la tabla
unir con el sector             pico  5.9 veces la tabla

La tabla de un millón de operaciones ocupa 22,9 MiB, y ninguna operación se conforma con eso. Ordenar por valor y hora pide 2,8 veces el tamaño de la tabla, además de la tabla: el índice de ordenación y la copia ordenada. La VWAP por valor, que reduce un millón de filas a 500, pide 1,3. Las barras de un minuto, con una clave de grupo nueva (la hora truncada), 3,2. Y la unión con una tabla de 500 sectores, la más inocente en apariencia, 5,9 veces: pandas construye los índices de las dos tablas y la tabla resultado completa antes de devolverla.

Son las cifras de esta tabla y de esta versión de pandas, no constantes universales, pero dan la idea que hay detrás de la regla de McKinney: un análisis encadena varias de estas operaciones y conserva varios resultados intermedios, así que el pico de un cuaderno de trabajo típico es de varias veces el tamaño de los datos.

Cuánto ocupa cada mercado

Con los bytes por fila y los picos medidos, falta el número de registros. Las cifras de esta sección salen de publicaciones de los propios sistemas (consultadas el 23 de octubre de 2026) o son supuestos declarados:

Dos advertencias. Las cifras de CTA son las del día pico de cada trimestre, no la media, y solo cubren las cintas A y B (las acciones cotizadas en NYSE y en otros mercados que no son Nasdaq; las de Nasdaq van por otro SIP, el de UTP). Y la de OPRA es la capacidad para la que se dimensiona el sistema, no el tráfico de un día normal. Las dos sirven para dimensionar una infraestructura, que es para lo que se publican.

Los bytes por fila de las cotizaciones y de las barras se miden igual que los de las operaciones, con tablas de una fila con sus columnas en los tipos compactos:

def bytes_por_fila(**tipos):
    vacia = pd.DataFrame({c: pd.Series([0], dtype=t)
                          for c, t in tipos.items()})
    return vacia.memory_usage(index=False).sum()

B_OPERACION = bytes_fila["pandas, categorías"]
B_COTIZACION = bytes_por_fila(
    ts="datetime64[ns]", valor="int16", compra="float64",
    venta="float64", tam_compra="int32", tam_venta="int32",
    mercado="int8")
B_BARRA = bytes_por_fila(
    ts="datetime64[ns]", valor="int32", apertura="float64",
    maximo="float64", minimo="float64", cierre="float64",
    volumen="int64")
print(f"bytes por fila: operación {B_OPERACION:.0f}, cotización "
      f"{B_COTIZACION}, barra {B_BARRA}")

CONJUNTOS = {                      # (registros, bytes por registro)
    "operaciones CTA, día pico": (113.9e6, B_OPERACION),
    "operaciones CTA, 252 días pico": (113.9e6 * 252, B_OPERACION),
    "cotizaciones CTA, día pico": (2_761e6, B_COTIZACION),
    "OPRA, un día a capacidad": (311e9, B_COTIZACION),
    "barras 1 min, 5.000 acciones, 1 año":
        (5_000 * 390 * 252, B_BARRA),
    "barras diarias, 50.000 valores, 20 años":
        (50_000 * 252 * 20, B_BARRA),
}
pico_union = 1 + round(picos["unir con el sector"], 1)   # 1 + 5,9
tamanos = pd.DataFrame(
    [(k, n / 1e6, n * b / 1e9, n * b * pico_union / 1e9)
     for k, (n, b) in CONJUNTOS.items()],
    columns=["conjunto", "millones", "GB", "GB al unir"]
).set_index("conjunto")
tamanos.round(1)

bytes por fila: operación 24, cotización 35, barra 52
                                         millones       GB  GB al unir
conjunto
operaciones CTA, día pico                   113.9      2.7        18.9
operaciones CTA, 252 días pico            28702.8    689.0      4753.8
cotizaciones CTA, día pico                 2761.0     96.6       666.8
OPRA, un día a capacidad                 311000.0  10885.0     75106.5
barras 1 min, 5.000 acciones, 1 año         491.4     25.6       176.3
barras diarias, 50.000 valores, 20 años     252.0     13.1        90.4

Con 24 bytes por operación, 35 por cotización y 52 por barra:

• El día pico de operaciones de las cintas A y B (113,9 millones) ocupa 2,7 GB en memoria: cabe en un portátil, pero unirlo con otra tabla ya pide 19 GB, más de lo que tiene uno de 16 GB. Un año de días como ese, 689 GB, no cabe en ninguno.
• El día pico de cotizaciones (2.761 millones) ocupa 96,6 GB: ya no cabe en un portátil, pero sí en una estación de trabajo o un servidor con 128 o 256 GB, y con la unión pide 670 GB.
• El libro L3 de un solo mercado, Nasdaq, ocupa de 7,9 a 12,6 GB por sesión en sus ficheros de muestra, ya comprimidos con gzip; descomprimidos y convertidos en tabla, varias veces más. Con 36 bytes por mensaje, 12,6 GB comprimidos son cientos de millones de mensajes en un día.
• OPRA a su capacidad proyectada, 311.000 millones de mensajes en un día, serían casi 11 TB en memoria. No hay una máquina con esa memoria; ni siquiera el disco de un portátil lo guarda.
• Las barras de un universo grande son moderadas: 25,6 GB las de un minuto de 5.000 acciones durante un año y 13,1 GB las diarias de 50.000 valores durante 20 años. Un problema de una máquina, no de un clúster.

La figura de la cabecera lo resume en escala logarítmica, frente a la memoria de un portátil de 16 GB y de un servidor grande de 1 TB.

En una escala lineal, la barra de OPRA mediría unas 4.000 veces la del día de operaciones. El salto entre lo que trabaja un quant con barras o con las operaciones de un día y lo que exige el libro de opciones completo es de tres a cuatro órdenes de magnitud. Por eso «big» significa cosas distintas en cada mesa: para un equipo que investiga con barras diarias, un universo global cabe en un portátil; para uno que modeliza la microestructura de las opciones, ningún ordenador es suficiente y los datos se filtran (subyacentes, vencimientos, franjas) antes de llegar a la memoria.

Un año de OPRA a su capacidad, en una sola reserva de memoria, deja de ser un problema de pandas: el sistema operativo no puede darla. NumPy calcula el tamaño y lo pide; Linux, con su política de memoria por defecto, se niega antes de tocar un byte:

un_ano = int(311e9 * 252 * B_COTIZACION)
np.empty(un_ano, dtype=np.uint8)

numpy._core._exceptions._ArrayMemoryError: Unable to allocate 2.44 PiB for an array with shape (2743020000000000,) and data type uint8

Qué hacer cuando no cabe

Lo primero no es una herramienta nueva, sino reducir. Casi ningún análisis necesita todas las columnas, todas las filas y la máxima precisión a la vez:

Si con eso no basta, el orden de las lecciones siguientes es el orden en que conviene escalar:

flowchart TB
  A[¿Cabe con holgura?] -->|sí| P[pandas o Polars]
  A -->|no| R[Reducir]
  R --> B[¿Cabe ahora?]
  B -->|sí| P
  B -->|no| S[Streaming local]
  S --> C[¿Cabe en un disco?]
  C -->|sí| S2[Polars o DuckDB]
  C -->|no| D[Distribuir]

• En una máquina, fuera de memoria (lección 6.6.2): Parquet particionado, Arrow, Polars en modo lazy y streaming y DuckDB con un límite de memoria procesan por bloques conjuntos mucho mayores que la RAM. Un día pico de cotizaciones de CTA (unos 97 GB en memoria) es un problema de una máquina con buen disco, no de un clúster.
• Distribuir (lección 6.6.3): Dask, Spark o Ray, cuando el cálculo no cabe ni en el disco de una máquina o hay que repartirlo para que acabe a tiempo.
• Almacenar para consultar (lección 6.6.4): bases de series temporales y ArcticDB, cuando los datos llegan cada día y se consultan por rangos de fechas y valores.
• Nube y lakehouse (lección 6.6.5): cuando el volumen o el equipo lo justifican.

Ejercicios

1. Calcula cuánto ocupa un día de fotos del libro L2 con 10 niveles por lado (precio en float64 y tamaño en int32 por nivel, más hora y valor), cada 100 milisegundos, para los 500 valores de la lección durante las 6,5 horas de sesión. ¿Cabe en 16 GB con el pico de la unión?

niveles, lados = 10, 2
b_foto = 8 + 2 + niveles * lados * (8 + 4)     # ts, valor, niveles
fotos = 500 * 6.5 * 3600 * 10                   # cada 100 ms
gb = fotos * b_foto / 1e9
print(f"{fotos:,.0f} fotos de {b_foto} bytes: {gb:.1f} GB; "
      f"con el pico de la unión, {gb * pico_union:.1f} GB")

117,000,000 fotos de 250 bytes: 29.2 GB; con el pico de la unión, 201.8 GB

2. Mide el pico de ordenar la tabla con objetos de Python (el primer millón de filas) y compáralo con el de la tabla de categorías. ¿Cuánta memoria pide en total, tabla incluida?

muestra_obj = con_objetos.iloc[:1_000_000].copy()
tam_obj = muestra_obj.memory_usage(deep=True).sum()
p_obj = pico(OPERACIONES["ordenar por valor y hora"], muestra_obj)
p_cat = picos["ordenar por valor y hora"] * tam
for nombre, t_, p_ in [("objetos", tam_obj, p_obj),
                       ("categorías", tam, p_cat)]:
    print(f"{nombre:<11} tabla {t_ / 2**20:6.1f} MiB, pico "
          f"{p_ / 2**20:5.1f} MiB, total "
          f"{(t_ + p_) / 2**20:6.1f} MiB")

objetos     tabla  165.0 MiB, pico  63.5 MiB, total  228.5 MiB
categorías  tabla   22.9 MiB, pico  63.5 MiB, total   86.4 MiB

3. En Parquet, una operación ocupa unos 10 bytes. ¿Significa eso que un día pico de operaciones de CTA en Parquet (unos 1,1 GB) se puede analizar con 2 GB de RAM?