Tiempo, hashes e identificadores

Un instante como número

Un timestamp (marca de tiempo) es la hora en que pasó algo, guardada junto con ese algo: cuándo se subió una foto, cuándo se calculó una predicción, cuándo llegó una etiqueta. Para que una computadora compare y reste horas, lo más cómodo es guardarlas como un solo número.

El número que casi todas usan es el tiempo Unix (Unix time o epoch time): los segundos que han pasado desde el 1 de enero de 1970 a las 00:00:00, en UTC (en un momento ves qué es UTC). Ese instante de partida se llama el epoch de Unix. Nada que ver con la época de entrenamiento: es la misma palabra en inglés para otra cosa.

Así, el instante en que Ana subió su foto es el número 1,793,973,785. Restar dos tiempos Unix da los segundos entre ellos, sin pensar en meses, años bisiestos ni horarios. Un día tiene 86,400 segundos, así que 1,793,973,785 ÷ 86,400 ≈ 20,764 días desde 1970: casi 57 años.

El mismo instante se escribe a veces en milisegundos (1,793,973,785,000: lo que da Date.now() en JavaScript, el lenguaje de las páginas web, y lo que usan muchos sistemas de eventos, como la hora de cada mensaje de Kafka, el registro de eventos de la lección de colas) o en microsegundos, con tres ceros más. En Python, time.time() da segundos con decimales, un float.

¿En qué tipo de dato se guarda? Si es un entero de 32 bits con signo (un int32), el tope es 2³¹ − 1 = 2,147,483,647, y llega antes de lo que parece.

from datetime import datetime, timezone

t = 1_793_973_785                      # un tiempo Unix: segundos desde 1970, en UTC
print(datetime.fromtimestamp(0, tz=timezone.utc))
print(datetime.fromtimestamp(t, tz=timezone.utc))
print("en milisegundos:", t * 1000, "· en microsegundos:", t * 1_000_000)

tope = 2**31 - 1                       # el int32 más grande
print("el int32 se llena el", datetime.fromtimestamp(tope, tz=timezone.utc))
print("y da la vuelta al", datetime.fromtimestamp(-2**31, tz=timezone.utc))

1970-01-01 00:00:00+00:00
2026-11-06 14:03:05+00:00
en milisegundos: 1793973785000 · en microsegundos: 1793973785000000
el int32 se llena el 2038-01-19 03:14:07+00:00
y da la vuelta al 1901-12-13 20:45:52+00:00

UTC: la hora de referencia

El tiempo Unix cuenta desde una hora fija del planeta, no desde la de un país. Esa referencia es UTC (Coordinated Universal Time, tiempo universal coordinado): la hora que sale de los relojes atómicos y que heredó el papel de «la hora de Greenwich» (GMT). Cada zona horaria se describe por su diferencia con UTC, el offset:

• La Ciudad de México está en UTC−6 todo el año: a las 14:03 UTC son las 8:03 de Ana.
• Cancún, en UTC−5. Madrid, en UTC+1 en invierno y UTC+2 en verano.
• Tijuana, en UTC−8 en invierno y UTC−7 en verano.

Ese «en verano» es el horario de verano (daylight saving time): adelantar el reloj una hora en primavera y regresarla en otoño. México lo quitó con la Ley de los Husos Horarios de 2022 (el último cambio general fue el 30 de octubre de ese año), pero los municipios de la franja fronteriza del norte, entre ellos todo Baja California, lo conservan para ir al parejo de Estados Unidos. Por eso Tijuana cambia y la Ciudad de México no. Las reglas de cada zona, con todos sus cambios históricos, viven en una base de datos pública, la tz database, que traen el sistema operativo y Python (zoneinfo). Sus zonas tienen nombres como America/Mexico_City.

Esto lleva a la regla de oro: guarda en UTC y muestra en la hora local. Las horas de los logs, de las bases de datos y de los datasets van en UTC; la conversión a la hora de cada persona se hace una sola vez, en la pantalla. Una hora sin zona se llama naive (ingenua): 2026-11-06 08:03:05 no dice si es de CDMX, de Tijuana o de Madrid. La Ronda (M09) lo resume así: un timestamp sin zona es la hora local «de quién sabe dónde».

La hora que no existe y la que se repite

Donde sí hay horario de verano pasan dos cosas raras, una vez al año cada una:

• El 8 de marzo de 2026, en Tijuana, el reloj pasa de 1:59:59 a 3:00:00. Las 2:30 no existen: ese día dura 23 horas.
• El 1 de noviembre, pasa de 1:59:59 a 1:00:00. La 1:30 ocurre dos veces, una en UTC−7 y otra en UTC−8. Ese día dura 25.

Un job programado «a las 2:30, hora local» se puede saltar en marzo, y uno «a la 1:30» puede correr dos veces en noviembre; qué pasa exactamente depende del programa que los lanza. Un conteo «por hora local» tiene una hora que junta dos. En UTC nada de esto pasa.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

ahora = datetime(2026, 11, 6, 14, 3, 5, tzinfo=timezone.utc)   # un instante, en UTC
for zona in ("America/Mexico_City", "America/Tijuana", "America/Cancun", "Europe/Madrid"):
    print(f"{zona:<20}", ahora.astimezone(ZoneInfo(zona)).isoformat())

ingenua = datetime(2026, 11, 6, 8, 3, 5)          # sin zona: ¿de dónde?
print("sin zona:", ingenua.isoformat(), "· tzinfo =", ingenua.tzinfo)

tj = ZoneInfo("America/Tijuana")
no_existe = datetime(2026, 3, 8, 2, 30, tzinfo=tj)  # ese día el reloj salta de 2:00 a 3:00
print("ida y vuelta de las 2:30:", no_existe.astimezone(timezone.utc).astimezone(tj).time())
primera = datetime(2026, 11, 1, 1, 30, tzinfo=tj)            # ese día, la 1:30 pasa dos veces
segunda = datetime(2026, 11, 1, 1, 30, fold=1, tzinfo=tj)
print("la 1:30 de dos maneras:", primera.astimezone(timezone.utc).time(), "y",
      segunda.astimezone(timezone.utc).time(), "en UTC")

America/Mexico_City  2026-11-06T08:03:05-06:00
America/Tijuana      2026-11-06T06:03:05-08:00
America/Cancun       2026-11-06T09:03:05-05:00
Europe/Madrid        2026-11-06T15:03:05+01:00
sin zona: 2026-11-06T08:03:05 · tzinfo = None
ida y vuelta de las 2:30: 03:30:00
la 1:30 de dos maneras: 08:30:00 y 09:30:00 en UTC

ISO 8601: escribir la hora sin dudas

¿Qué día es 03/04/2026? En México, el 3 de abril; en Estados Unidos, el 4 de marzo. Para no adivinar existe ISO 8601, el estándar internacional para escribir fechas y horas como texto:

2026-11-06T14:03:05Z

De lo grande a lo chico: año, mes, día, una T que separa la fecha de la hora, horas, minutos, segundos y la zona. La Z significa UTC (los aviadores la leen Zulu). En vez de la Z puede ir el offset: 2026-11-06T08:03:05-06:00 es el mismo instante, escrito con la hora de CDMX. Los decimales de segundo van después de un punto: 14:03:05.412Z (ISO 8601 también acepta coma).

Ese orden de lo grande a lo chico tiene un premio: si todas las horas están en UTC y con el mismo formato, ordenarlas como texto las ordena en el tiempo. «2026-10-31T23:59:59Z» va antes que «2026-11-06T09:30:00Z» letra por letra. Por eso los nombres de archivos, de carpetas y de snapshots llevan la fecha así, como el ds-2026-09-01 de C01. Con el formato día/mes/año no funciona: «01/01/2027» empieza con 01 y «06/11/2026» con 06, así que el 1 de enero de 2027 quedaría antes que el 6 de noviembre de 2026.

El reloj de pared y el monotónico

Cada computadora tiene, en realidad, dos relojes que le sirven a un programa.

El reloj de pared (wall clock) es la hora del calendario, la que sale en la esquina de la pantalla. En Python es time.time(). Sirve para poner timestamps. Pero puede brincar: si el sistema descubre que iba adelantado, lo corrige y la hora retrocede; si alguien la cambia a mano, salta; si una máquina virtual se pausa y despierta, avanza de golpe.

El reloj monotónico (monotonic clock, también «monótono») solo avanza. Cuenta desde un punto arbitrario, por ejemplo desde que se prendió la máquina, así que su valor no dice qué hora es. Lo que sí dice bien es cuánto pasó entre dos lecturas. En Python es time.monotonic().

La regla: los timestamps, con el de pared; las duraciones, con el monotónico. Si mides una latencia restando dos time.time() y en medio el sistema atrasa el reloj 300 ms, una request de 40 ms sale de 40 − 300 = −260 ms. Los timeouts y los deadlines de la lección de fallas de red se miden igual, con el monotónico: un timeout de 150 ms no puede durar 0 ni 2 segundos porque alguien movió la hora.

import time

for nombre in ("time", "monotonic"):
    info = time.get_clock_info(nombre)
    print(f"time.{nombre}(): ¿lo pueden mover? {info.adjustable} · ¿solo avanza? {info.monotonic}")

inicio = time.monotonic()          # un punto de partida, no una hora
time.sleep(0.3)                    # lo que quieres medir
duracion = time.monotonic() - inicio
print(f"tardó ≈ {duracion:.1f} s")

time.time(): ¿lo pueden mover? True · ¿solo avanza? False
time.monotonic(): ¿lo pueden mover? False · ¿solo avanza? True
tardó ≈ 0.3 s

Dos máquinas nunca marcan lo mismo

El reloj de una computadora es un cristal de cuarzo que vibra, y ningún cristal vibra exacto: se adelanta o se atrasa unas partes por millón. Con un error de 20 partes por millón, el reloj se corre 20 ÷ 1,000,000 × 86,400 s ≈ 1.7 segundos al día. Sin corregirlo, en un mes van casi 52 segundos.

Para corregirlo, cada máquina le pregunta la hora a un servidor de referencia con NTP (Network Time Protocol) y ajusta la suya poco a poco. Aun así, la red tarda en llevar la respuesta y ese tiempo varía, así que dos máquinas sincronizadas quedan con una diferencia: del orden de decenas de milisegundos si el servidor de hora está al otro lado de internet, y menos de un milisegundo, en buenas condiciones, si está en la misma red local. Esa diferencia es el desfase de relojes (clock skew).

Unos milisegundos parecen nada, pero bastan para mentir:

De ahí salen tres consecuencias:

• No ordenes eventos de dos máquinas por su hora. Si los milisegundos importan, el orden lo da quién llamó a quién. Para seguir una request por varios saltos se usa su identificador, que ves en la sección de UUID.
• No midas una latencia restando horas de dos máquinas. Cada máquina mide su parte con su monotónico. Por eso, entre máquinas, un deadline viaja como «te quedan 190 ms» y no como «termina a las 14:03:05.290».
• Vigila el desfase. En la Ronda, C02, que vigila con cámaras unos centros de distribución, corre NTP en cada caja de cómputo de sus sitios y compara su hora con la del servidor en cada latido (heartbeat); si se separan más de 2 segundos, lo registra. Un reloj corrido por días rompe hasta las conexiones cifradas (TLS, en la lección de cifrado), porque revisan que el certificado del otro lado no esté vencido.

Varias horas para la misma foto

La foto de Ana tiene varias horas, y no son la misma:

1. Cuándo se tomó. El teléfono la anota en los metadatos EXIF del JPEG, en hora local. La zona va en otro campo (OffsetTimeOriginal, que existe desde la versión 2.31 de EXIF, de 2016), y muchas cámaras y programas no lo llenan o lo borran: no cuentes con él.
2. Cuándo se subió. El backend la recibe a las 14:03:05 UTC.
3. Cuándo se procesó. El gateway y Triton la clasifican unos milisegundos después. Si hubiera pasado por una cola, podrían ser minutos.
4. Cuándo llegó su etiqueta. Ana elige la categoría final un par de minutos más tarde; un moderador podría corregirla días después.

La hora en que algo pasó en el mundo es su event time (tiempo del evento). La hora en que un sistema lo procesa es su processing time (tiempo de procesamiento). Casi siempre van juntas, pero no siempre. La Ronda (M02) da el ejemplo clásico: un celular sin señal en el metro registra un pago a las 10:00:05, y el evento llega al sistema a las 10:07. Pasó a las 10:00; llegó siete minutos tarde.

¿Por qué importa? Porque las preguntas son sobre el mundo, no sobre tu sistema. «¿Cuántos pagos hizo esta tarjeta entre las 10:00 y las 10:05?» se responde con el event time. Por processing time, el pago del metro caería en la cuenta de 10:05 a 10:10, y un retraso de la red cambiaría tus features.

Ventanas: contar por pedazos de tiempo

Muchas features son conteos o sumas sobre un rato: pagos de la tarjeta en 10 minutos, fotos del vendedor en 24 horas, errores del servicio en 5 minutos. Ese rato es una ventana de tiempo (time window), y hay de varios tipos:

• Fijas (tumbling): pedazos pegados que no se enciman: 10:00–10:05, 10:05–10:10. Cada evento cae en una sola.
• Deslizantes (sliding o hopping): ventanas de cierto largo que avanzan a pasos más cortos: «la última hora, recalculada cada 5 minutos». Se enciman, y cada evento cae en varias: con 1 hora cada 5 minutos, en 12.
• De sesión (session): se cierran cuando hay un hueco sin actividad, por ejemplo de 30 minutos. Sirven para «lo que hizo una persona en una visita».

Una ventana «de 24 horas» en una feature de fraude no es «el día de hoy». C09, el caso de fraude con tarjetas, la define anclada al evento: los pagos con event time entre t − 24 h y t, sin contar el pago que se está decidiendo.

El watermark: cuánto esperar a los que llegan tarde

Un programa que cuenta en ventanas mientras llegan los eventos (un job de streaming, que lee un stream de eventos de la lección de colas) tiene un problema: ¿cuándo da por cerrada la ventana de 10:00 a 10:05? Si la cierra a las 10:05 en punto, el pago del metro no entra. Si espera una hora, sus features llegan una hora tarde.

El watermark es la respuesta: una hora de event time que dice «ya creo haber recibido todo lo anterior a esto». Lo más común es calcularlo como el event time más nuevo que se ha visto, menos un margen. Cuando el watermark pasa el final de una ventana, la ventana se cierra y emite su resultado.

Ese es el trato: un margen más grande da cuentas más completas y features más viejas. Lo que llega tarde se tira, se manda a una salida aparte para corregir o se cuenta en el cálculo de entrenamiento, que corre después, con todo ya llegado. El diagrama sigue los dos pagos por el sistema de fraude.

El problema: el dataset se arma después

Un modelo de fraude decide en el momento del pago. Su dataset de entrenamiento se arma semanas después, cuando ya se sabe qué pagos fueron fraude. Para cada pago viejo hay que poner sus features: «pagos de la tarjeta en la última hora», «monto promedio en 30 días»… Y aquí está la trampa: ¿con qué valor?

Si pones el valor que la feature tiene hoy, le das al modelo información que no existía cuando se tomó la decisión. Es leakage: el modelo aprende con el futuro, sale buenísimo en la validación y se cae en producción, donde el futuro no está. Es el mismo error que repartir train y validación sin respetar el tiempo, el split temporal de la lección de ejemplos, pero dentro de cada fila.

La regla se llama point-in-time correctness (corrección al instante): cada fila lleva el valor que cada feature tenía en el momento de la predicción, no el de hoy. La herramienta es un join as-of («a la fecha de»), una unión de dos tablas por hora: para cada evento, el último valor de la feature con timestamp menor o igual al del evento.

La hora que importa: cuándo estuvo disponible

Hay un detalle más fino. La Ronda (M09) lo dice así: el timestamp que importa no es cuándo terminó la ventana, sino cuándo el valor estuvo disponible para el servicio. Si el valor de las 10:30 tarda 2 minutos en llegar a la base de datos que lee el modelo, una decisión de las 10:31 todavía vio el de las 10:00. Un join as-of con la hora de cálculo le daría 7; el correcto, con la hora de disponibilidad, le da 3.

En pandas, la biblioteca de tablas de Python, la misma operación es pd.merge_asof, con un tolerance que pone un límite de antigüedad: en M09, ningún valor de más de 2 horas cuenta.

import bisect

# La feature «pagos de la tarjeta en la última hora», tal como se calculó cada vez
feature_ts = ["09:00", "10:00", "10:30", "11:00"]     # cuándo se calculó cada valor
valores    = [2,       3,       7,       4]
eventos    = ["10:10", "10:35"]                       # cuándo se tomó cada decisión

def as_of(t):
    i = bisect.bisect_right(feature_ts, t) - 1        # el último valor con hora ≤ t
    return (feature_ts[i], valores[i]) if i >= 0 else (None, None)

for t in eventos:
    print(f"decisión de las {t}: as-of → {as_of(t)} · el de hoy → {valores[-1]}")

# Si el valor tarda 2 minutos en estar disponible para el servicio:
disponible = ["09:02", "10:02", "10:32", "11:02"]
i = bisect.bisect_right(disponible, "10:31") - 1
print("a las 10:31, el servicio todavía veía el valor de las", feature_ts[i], "=", valores[i])

decisión de las 10:10: as-of → ('10:00', 3) · el de hoy → 4
decisión de las 10:35: as-of → ('10:30', 7) · el de hoy → 4
a las 10:31, el servicio todavía veía el valor de las 10:00 = 3

Tres reglas para no colar el futuro

• Las etiquetas también tienen fecha. Un contracargo (cuando el dueño de la tarjeta desconoce un cargo) llega semanas después del pago. C09 guarda las dos fechas, la del pago y la de llegada, y una feature como «contracargos de la tarjeta en 90 días» solo cuenta los que ya habían llegado antes de t.
• Nada de now() dentro de una feature. «Compras de los últimos 30 días» calculada con la hora actual funciona en la corrida diaria y está mal en cualquier backfill, el recálculo de días pasados. La fecha de referencia llega como parámetro.
• Guarda lo que el modelo vio. C08 escribe, con el request_id de cada recomendación, las features exactas que leyó el modelo, y el training set las une por ese id: entrenar y servir ven lo mismo. Un feature store, el almacén de features de la lección de almacenamiento, hace el join as-of por ti.

Qué es

Ya usaste hashes en varias lecciones: para repartir vendedores entre train y validación, para quitar fotos repetidas, para mandar los valores de una feature a un número fijo de casillas, para que un balanceador mande la misma conexión al mismo destino, para revisar los pesos de un modelo. Siempre con la misma idea: una cuenta que convierte unos datos en un número, siempre el mismo para los mismos datos. Aquí va la definición completa.

Una función hash toma una entrada de cualquier tamaño (un texto, los 200 KB de una foto, un archivo de 70 GB) y devuelve un número de tamaño fijo, el hash o huella. Tres propiedades la hacen útil:

1. Determinista. La misma entrada da siempre el mismo hash, en cualquier máquina y en cualquier año.
2. Tamaño fijo. SHA-256 devuelve siempre 256 bits, se le pase una letra o una película. Escritos en hexadecimal, con 4 bits por símbolo, son 64 caracteres.
3. Revuelve todo. Un cambio de un solo bit en la entrada cambia, en promedio, la mitad de los bits de la salida. «vend-00024» y «vend-00025» dan huellas que no se parecen en nada. A esto se le llama efecto avalancha.

La tercera es la que convierte un hash en un sorteo: aunque es una cuenta fija, su salida se ve al azar y se reparte pareja.

import hashlib, os, subprocess, sys

for texto in ("vend-00024", "vend-00025", "vend-00024"):
    huella = hashlib.sha256(texto.encode()).hexdigest()
    print(texto, "→", huella[:16], "…", len(huella), "caracteres")

# El hash() de Python, en dos programas distintos: ¿da lo mismo?
codigo = "print(hash('vend-00024'))"
def corrida(semilla):
    entorno = dict(os.environ, PYTHONHASHSEED=semilla)
    return subprocess.run([sys.executable, "-c", codigo], env=entorno,
                          capture_output=True, text=True).stdout
print("hash() con semilla al azar, ¿igual en dos corridas?", corrida("random") == corrida("random"))
print("hash() con PYTHONHASHSEED=0, ¿igual?", corrida("0") == corrida("0"))
print("hash(42) =", hash(42), "· los enteros no cambian")

vend-00024 → a0034b6501dd8870 … 64 caracteres
vend-00025 → 7ca8198c15366a56 … 64 caracteres
vend-00024 → a0034b6501dd8870 … 64 caracteres
hash() con semilla al azar, ¿igual en dos corridas? False
hash() con PYTHONHASHSEED=0, ¿igual? True
hash(42) = 42 · los enteros no cambian

La segunda parte muestra una trampa famosa. Python trae su propia función hash(), pero para textos y bytes cambia cada vez que arranca un programa: desde Python 3.3, le mezcla una semilla al azar que elige al arrancar, para que nadie pueda fabricar a propósito muchos textos que caigan en la misma casilla de un diccionario y hacerlo lento (un diccionario de Python, dict, guarda cada llave en la casilla que le indica su hash). La variable de entorno PYTHONHASHSEED sirve para fijar esa semilla (con un número) o apagarla (con 0), como hace el código de arriba. Los enteros no llevan semilla: no cambian entre corridas, y el hash de uno chico es el mismo número. Sirve dentro de un programa; para cualquier cosa que se guarde o que dos programas deban calcular igual, se usa hashlib.

Colisiones y la paradoja del cumpleaños

Hay infinitas entradas posibles y solo 2²⁵⁶ huellas, así que tiene que haber entradas distintas con la misma huella: una colisión. La pregunta útil es qué tan probable es toparse con una.

Empieza por un grupo de personas. ¿Cuántas hacen falta para que dos cumplan años el mismo día con probabilidad de 50 %? Con 365 días, la intuición dice unas 180. Son 23. El truco es que no se compara una persona contra las demás, sino cada par: 23 personas forman 253 pares, y cada par tiene su oportunidad. Es la paradoja del cumpleaños.

Con hashes pasa igual: cada huella posible es una casilla, como cada día del año. Con huellas de b bits hay N = 2ᵇ casillas, y la primera colisión se vuelve probable alrededor de √N elementos, no de N. Una huella de 32 bits tiene 4,294,967,296 casillas, pero con ≈ 77,000 elementos ya hay 50 % de que dos choquen.

Dos familias: hashes criptográficos y checksums

Un hash criptográfico, como SHA-256, promete además que nadie puede ir de la huella a la entrada ni fabricar dos entradas con la misma huella. Por eso sirve de identidad: dos archivos con el mismo SHA-256 son el mismo archivo. Un checksum (suma de verificación), como CRC32, solo promete detectar daños por accidente, como un bit volteado en un cable; es más corto y más rápido, pero cualquiera le fabrica un choque. Las dos familias, con código, están en la sección extra «Hashes a fondo».

hash(llave) mod N

Cuando los datos no caben en una máquina, o el tráfico es demasiado para una sola, se reparten entre varias. Repartir datos entre máquinas por una llave es sharding, y cada pedazo es un shard. La forma más simple de decidir dónde va cada llave:

shard = hash(llave) mod N

donde N es el número de máquinas y «mod» es el residuo de dividir (17 mod 5 = 2). Como el hash se ve al azar, los residuos se reparten parejos. Y como es determinista, cualquier programa que quiera leer el listing (la publicación) 8841 calcula el mismo shard sin preguntarle a nadie.

En la Ronda, C07 reparte su índice de búsqueda en 4 shards por hash del listing_id, y explica por qué no por rangos (del 1 al millón aquí, del millón al dos millones allá): con el hash, los shards quedan parejos y ninguno se «calienta» (recibe mucho más tráfico que los demás) cuando algo se pone de moda. Es la misma cuenta que reparte los mensajes de un tópico, el registro de mensajes de la lección de colas, entre sus pedazos, cada uno una partición. El cliente de Kafka para Java, por ejemplo, calcula el hash murmur2 de la llave y se queda con el residuo entre el número de particiones. C09 usa la tarjeta como llave para que todos los pagos de una tarjeta caigan en la misma partición, en orden.

El problema: cambiar N

Ahora C07 crece y pasa de 4 a 5 shards. Con mod N, ¿cuántas llaves cambian de máquina?

Y empeora con N: de 10 a 11 se mueve el 91 %; de 100 a 101, el 99 %. Lo mismo pasa con los tópicos: agregar particiones cambia a qué partición va cada llave, y los pagos de una tarjeta dejan de estar juntos durante el cambio.

El hashing consistente

El arreglo se llama hashing consistente (consistent hashing). En vez de dividir entre N, imagina todos los números de hash posibles en un círculo, como las horas de un reloj: después del más grande vuelve a empezar el 0. Cada máquina queda en un punto del círculo, el hash de su nombre. Cada llave queda en el punto de su propio hash y camina en el sentido del reloj hasta la primera máquina que encuentra: esa es su dueña. Al agregar una máquina, solo cambian de dueño las llaves del arco que le toca a ella; todas las demás se quedan donde estaban.

Con N máquinas que pasan a N + 1, se mueve en promedio ≈ 1/(N + 1) de las llaves: lo justo. Así reparten sus datos bases de datos distribuidas como Cassandra. El anillo en código, por qué cada máquina va en muchos puntos y una calculadora para comparar están en la sección extra «Hashes a fondo».

La asignación de un A/B, con la misma cuenta

En «Ruido, muestras y pruebas A/B» viste que C01 reparte a los vendedores de un A/B por vendedor, su unidad de aleatorización, con un hash. Esta es la asignación con hash:

cubeta = hash(sal + seller_id) mod 100; la cubeta (bucket) es un número de 0 a 99, y las cubetas de 0 a 49 van a A y las de 50 a 99 a B.

La sal (salt) es un texto que cambia en cada experimento, como «umbral-oct». Por qué así y no con una tabla que diga «vend-00024 → A»:

• Siempre igual, en todas partes. El backend, el job que mide los resultados y un analista con Python calculan el mismo brazo para Ana, hoy y en tres semanas, sin consultar nada. C01 lo calcula en el backend y lo manda en un header, X-Model-Arm.
• No hay tabla que guardar ni sincronizar. Con millones de vendedores, eso es una base de datos y una fuente de errores menos.
• Las rampas son ordenadas. Un canary (mandar primero el modelo nuevo a una parte chica del tráfico) al 5 % son las cubetas de 0 a 4; al subir a 25 %, las de 0 a 24. Quien ya estaba adentro se queda adentro.
• Cada experimento sortea distinto. Con otra sal, los vendedores se revuelven. Sin sal, los mismos caerían en el tratamiento de todos los experimentos y arrastrarían efectos de uno al otro.

import hashlib

def cubeta(sal, vendedor):                       # un número de 0 a 99, siempre el mismo
    h = hashlib.sha256(f"{sal}:{vendedor}".encode()).hexdigest()
    return int(h, 16) % 100

def brazo(sal, vendedor):
    return "A" if cubeta(sal, vendedor) < 50 else "B"

print("vend-00024:", cubeta("umbral-oct", "vend-00024"), brazo("umbral-oct", "vend-00024"),
      "· otra vez:", brazo("umbral-oct", "vend-00024"))

vendedores = [f"vend-{i:05d}" for i in range(10_000)]
en_b = [brazo("umbral-oct", v) == "B" for v in vendedores]
print("en B, de 10,000:", sum(en_b))
otro = [brazo("top5-nov", v) == "B" for v in vendedores]       # otro experimento, otra sal
print("en B en los dos experimentos:", sum(a and b for a, b in zip(en_b, otro)))

vend-00024: 58 B · otra vez: B
en B, de 10,000: 5148
en B en los dos experimentos: 2561

int(h, 16) lee la huella hexadecimal como un número entero, para poder sacarle el residuo. 5,148 de 10,000 no es exactamente la mitad: es un sorteo, y su ruido es el de esa lección. El error estándar de una mitad con 10,000 es √(0.5 × 0.5 ÷ 10,000) = 0.5 puntos, unos 50 vendedores; esta sal cayó ≈ 3 errores estándar arriba, un sorteo con poca suerte (con la sal «top5-nov» salen 5,011). Y en B de los dos experimentos quedan ≈ 2,560, cerca de la cuarta parte: como si se hubiera sorteado dos veces de manera independiente.

El problema de los nombres

Cada foto, cada request y cada evento necesita un nombre que nadie más tenga. Lo obvio es un contador: 1, 2, 3… Pero un contador vive en un solo lugar, y cada copia del gateway, cada teléfono y cada job tendría que preguntarle «¿qué número sigue?». Con 500 requests por segundo en el pico de C01, es un cuello de botella que, si se cae, para todo. Lo que se usa es un número tan grande y tan al azar que cada quien lo inventa sin chocar.

UUID: 128 bits que no se repiten

Un UUID (universally unique identifier, identificador único universal) es un número de 128 bits escrito en hexadecimal, en 5 grupos con guiones: f47ac10b-58cc-4372-a567-0e02b2c3d479. Son 32 símbolos de 4 bits (128 bits) más 4 guiones: 36 caracteres. Hay varias versiones; dos importan.

La versión 4 es casi toda al azar: de los 128 bits, 6 son fijos (dicen la versión y la variante, la familia de UUID a la que pertenece), y 122 salen al azar. ¿Qué tan seguido chocan? Es la paradoja del cumpleaños otra vez:

La versión 7 pone al principio la hora: los primeros 48 bits son el tiempo Unix en milisegundos, y el resto, fuera de los 6 de versión y variante, va al azar o lleva un contador que mantiene el orden dentro del mismo milisegundo. Así, ordenarlos los ordena por fecha de creación. Eso importa en una base de datos: un índice, la estructura con la que una base de datos encuentra rápido una fila, se guarda ordenado, y con UUID v4 cada id nuevo cae en un lugar al azar del índice; con v7, todos caen al final, en la parte que la base de datos ya tiene en memoria. A cambio, delata cuándo se creó cada cosa. La versión 7 se estandarizó en mayo de 2024, en el RFC 9562 (los RFC son los documentos donde se publican los estándares de internet), que reemplazó al RFC 4122 de 2005.

import uuid
from datetime import datetime, timezone

a = uuid.uuid4()                                # 122 bits al azar: cambia en cada corrida
print("versión", a.version, "·", len(str(a)), "caracteres ·", a.int.bit_length() <= 128)

x, y = uuid.uuid7(), uuid.uuid7()               # Python 3.14: la hora va al principio
print("versión", x.version, "· ¿el segundo va después del primero?", y > x)

ejemplo = uuid.UUID("017f22e2-79b0-7cc3-98c4-dc0c0c07398f")   # un UUID v7 de ejemplo del estándar
ms = ejemplo.int >> 80                          # los primeros 48 bits: milisegundos Unix
print("su hora:", ms, "ms →", datetime.fromtimestamp(ms / 1000, timezone.utc))

alerta = uuid.uuid5(uuid.NAMESPACE_URL, "sitio-3/camara-12/track-881/zona-2/14:00")
print("uuid5, siempre el mismo:", alerta)

versión 4 · 36 caracteres · True
versión 7 · ¿el segundo va después del primero? True
su hora: 1645557742000 ms → 2022-02-22 19:22:22+00:00
uuid5, siempre el mismo: 70f32a2c-6f39-5d00-8b9d-ab1b0742a62d

El request ID: el hilo que une los logs

Una request de C01 pasa por la app, el backend, el balanceador, el gateway y Triton. Cada uno escribe su log, con su reloj. Si algo sale mal, ¿cómo encuentras las cinco líneas de esa request entre millones?

Con un request ID: un identificador que se inventa una sola vez, al entrar, y que viaja con la request en un header, como el X-Request-ID: 9f2c41d0 de la lección de HTTP. En C01 lo pone el backend, y el gateway lo escribe en cada línea de su log y lo devuelve en la respuesta. Buscar «9f2c41d0» en los logs de todos los saltos da la historia completa.

El mismo id sirve para algo más que buscar fallas. La etiqueta de una foto llega minutos o días después, y se une a su predicción por ese id. La Ronda (M12) lo dice sin rodeos: si no guardaste el id en el momento de la predicción, no hay unión posible.

No lo confundas con la llave de idempotencia de la lección de fallas de red. El request ID sirve para seguir una request. La llave de idempotencia sirve para que una operación repetida no se haga dos veces: el cliente la crea una vez por operación y la repite igual en cada reintento. A veces el mismo valor hace las dos cosas.

1. Guardar horas sin zona

Un pipeline guarda 2026-11-06 08:03:05 sin zona, y otro lo lee como UTC. Todas las features quedan corridas 6 horas, como en el ejemplo de M09: «compras de la mañana» cuenta las de la madrugada.

Cómo evitarlo: timestamps con zona en todo el pipeline, en UTC; convertir a la hora local en un solo lugar, al mostrar. Que la validación de datos rechace horas sin zona.

2. Medir duraciones con el reloj de pared

fin − inicio con time.time() da latencias negativas o enormes cuando NTP corrige el reloj a media medición.

Cómo evitarlo: duraciones y timeouts con time.monotonic(). La hora de pared, solo para poner timestamps.

3. Ordenar eventos de varias máquinas por su hora

Con 80 ms de desfase, la respuesta aparece antes que la pregunta, y una latencia medida entre dos máquinas sale negativa.

Cómo evitarlo: unir los logs por request ID y ordenar por quién llamó a quién. Medir cada tramo con el reloj de su máquina. Vigilar el desfase con NTP.

4. Armar el training set con los valores de hoy

Un join normal entre los eventos y la tabla de features toma el último valor, que es del futuro. La validación sale espectacular; producción, no.

Cómo evitarlo: join as-of por la hora en que cada valor estuvo disponible, con un límite de antigüedad; etiquetas por fecha de llegada; nada de now() dentro de una feature.

5. Repartir con el hash() de Python

hash(seller_id) % 100 reparte distinto en cada corrida: los vendedores brincan entre train y validación, o entre brazos de un A/B.

Cómo evitarlo: hashlib.sha256 (u otro hash fijo) para todo lo que se guarde o lo calcule más de un programa, con una sal por experimento.

6. Cambiar el número de shards con mod N

Pasar de 10 a 11 máquinas con hash mod N mueve 91 % de los datos, y durante el traslado muchas lecturas fallan o van al lugar equivocado.

Cómo evitarlo: hashing consistente, o casillas fijas que se reparten entre máquinas. En un tópico, elegir desde el principio más particiones de las necesarias.

7. Ordenar horas como texto con formatos mezclados

Ordenar como texto funciona solo si todas las horas tienen la misma zona y la misma forma. …T14:03:05Z queda después de …T14:03:05.5Z, aunque sea medio segundo antes, porque el punto va antes que la Z. Y una hora con -06:00 se ordena por su hora local.

Cómo evitarlo: normalizar al guardar: todo en UTC, con la Z y con los mismos decimales (por ejemplo, siempre milisegundos). O guardar el timestamp como número o como tipo de fecha de la base de datos, y ordenar por ese.

Resuélvelos con lápiz antes de abrir la solución. Los de choques y de shards se pueden comprobar con las calculadoras.

1. 1Fácil

   Un evento tiene el tiempo Unix 1,793,973,785. ¿Cuántos días han pasado desde 1970? ¿Cómo se escribe ese instante en milisegundos? Si un sistema lo lee como milisegundos por error, ¿qué fecha cree que es, aproximadamente?

   Ver la solución paso a paso

   • Días: 1,793,973,785 ÷ 86,400 ≈ 20,764, unos 56.8 años: noviembre de 2026.
   • En milisegundos: 1,793,973,785,000, tres ceros más.
   • Leído como milisegundos, son 1,793,973 segundos ≈ 20.8 días después del 1 de enero de 1970: el 21 de enero de 1970. Por eso la unidad va en el contrato, o la hora viaja en ISO 8601.
2. 2Fácil

   Ana sube una foto a las 8:03 en CDMX el 6 de noviembre de 2026. (a) Escríbela en ISO 8601, en UTC y con su offset. (b) ¿Qué hora era en Tijuana? (c) Un programa ordena como texto 2026-11-06T09:30:00Z, la hora de Ana con su offset y 2026-11-06T14:00:00Z. ¿Acierta el orden?

   Ver la solución paso a paso

   • (a) CDMX es UTC−6: 8:03 + 6 h = 14:03 UTC. 2026-11-06T14:03:00Z, o con su offset, 2026-11-06T08:03:00-06:00. Es el mismo instante.
   • (b) Tijuana, el 6 de noviembre, ya está en horario de invierno, UTC−8: 14:03 − 8 h = 6:03.
   • (c) Letra por letra, la de Ana (…T08:03:00-06:00) queda primero. Pero en UTC es 14:03: es la última. No acierta, porque no todas están en UTC: ordenar como texto solo vale con la misma zona y el mismo formato.
3. 3Fácil

   Un SHA-256 escrito en hexadecimal tiene 64 caracteres. ¿Cuántos bits y cuántos bytes son? ¿Por qué no usas hash(texto) de Python para guardar huellas?

   Ver la solución paso a paso

   • Cada carácter hexadecimal son 4 bits: 64 × 4 = 256 bits, o 256 ÷ 8 = 32 bytes. Escrito como texto ocupa el doble, 64 bytes.
   • hash() de textos cambia en cada corrida de Python (salvo que fijes PYTHONHASHSEED): una huella guardada hoy no coincidiría mañana. Para huellas, hashlib.
4. 4Medio

   Una feature se calculó a las 08:00 (vale 5), 08:45 (vale 9), 09:30 (vale 6) y 10:15 (vale 2), y cada valor tarda 3 minutos en estar disponible. ¿Qué valor le toca a decisiones de las 08:46, 09:20 y 09:32? ¿Y a una de las 12:40 si el límite de antigüedad es de 2 horas?

   Ver la solución paso a paso

   • Disponibles a las 08:03, 08:48, 09:33 y 10:18.
   • 08:46: el último disponible es el de las 08:03 → 5 (el de las 08:45 todavía no llegaba).
   • 09:20: el último es el de las 08:48 → 9.
   • 09:32: el de las 09:30 llega a las 09:33, un minuto tarde → todavía 9.
   • 12:40: el último es el de las 10:15 (disponible desde las 10:18), calculado hace 2 h 25 min: pasa del límite → ninguno (un nulo, que el modelo tiene que saber manejar).
5. 5Medio

   Un sistema de eventos cuenta en ventanas fijas de 5 minutos, con un watermark igual al event time más nuevo visto menos 2 minutos. Ya vio un evento de las 10:16:30. ¿Qué ventanas están cerradas? Llega un evento con event time 10:12: ¿entra?

   Ver la solución paso a paso

   • Watermark = 10:16:30 − 2 min = 10:14:30.
   • Cerradas: todas las que terminan antes de 10:14:30, es decir, hasta la de 10:05 a 10:10. La de 10:10 a 10:15 sigue abierta.
   • El evento de las 10:12 cae en la de 10:10 a 10:15, que sigue abierta: sí entra. Si hubiera llegado después de que el watermark pasara 10:15, ya sería tarde.
6. 6Medio

   Un servicio con 8 shards por hash mod 8 pasa a 9. Tiene 200 millones de llaves. ¿Cuántas se mueven? ¿Y con hashing consistente?

   Ver la solución paso a paso

   • Con mod N, de N a N + 1 se mueve N ÷ (N + 1) = 8 ÷ 9 ≈ 88.9 %: ≈ 178 millones de llaves.
   • Con hashing consistente, ≈ 1 ÷ 9 ≈ 11.1 %: ≈ 22 millones, las que le tocan a la máquina nueva. Ocho veces menos.
7. 7Reto

   C01 lanza un modelo nuevo como canary al 5 % de los vendedores y planea subirlo a 25 % y luego a 100 %, como en la Ronda. Escribe la regla con hash. ¿Quiénes del primer 5 % siguen en el canary al subir? ¿Qué pasaría si a media rampa alguien cambia la sal?

   Ver la solución paso a paso

   • Regla: cubeta = sha256(sal + ":" + seller_id) mod 100; está en el canary si cubeta < porcentaje.
   • Al subir de 5 a 25 %, las cubetas 0 a 4 siguen siendo menores que 25: todos los del 5 % se quedan, y entran los de las cubetas 5 a 24. Al pasar a 100 %, entran todos los demás. Nadie entra y sale.
   • Con otra sal, las cubetas se revuelven: de los vendedores que estaban en el canary al 25 %, solo ≈ 25 % seguiría adentro, y ≈ 75 % regresaría al modelo viejo de golpe. Vería cambiar sus sugerencias y las métricas mezclarían dos grupos. La sal se fija al empezar el experimento y no se toca.
8. 8Reto

   Un equipo propone ids de 64 bits al azar en vez de UUID, «para ahorrar espacio», para los 10 millones de fotos diarias de C01 durante 100 años. ¿Cuántos choques esperas? ¿Y con UUID v4? ¿Qué propones si de verdad quieren 64 bits?

   Ver la solución paso a paso

   • n = 10⁷ × 365 × 100 = 3.65 × 10¹¹ ids.
   • Con 64 bits: n² ÷ (2 × 2⁶⁴) ≈ 1.33 × 10²³ ÷ 3.7 × 10¹⁹ ≈ 3,600 choques esperados. Ya en el primer año serían ≈ 0.36, y la probabilidad de algún choque, ≈ 30 %.
   • Con UUID v4 (122 bits al azar): ≈ 1.3 × 10⁻¹⁴: nunca.
   • Si quieren 64 bits, que no sean al azar: un esquema tipo Snowflake (hora en milisegundos + número de máquina + contador) no choca por construcción, porque cada máquina tiene su número y su contador. El precio es asignar y cuidar esos números de máquina.

En la Ronda:

• M02 · Patrones de inferencia usa todo esto en el streaming: event time, ventanas, watermark y particiones por llave. También arma llaves de caché y de idempotencia con sha256 y la versión del modelo.
• M09 · Datos y features pide timestamps con zona (CDMX, UTC−6), el join point-in-time del feature store con su tolerancia y la hora de disponibilidad, el split por hash del vendedor y la deduplicación por sha256.
• M15 · Seguridad y confiabilidad explica por qué un hash no anonimiza, cuándo hace falta un HMAC, cómo se verifica el sha256 de unos pesos y por qué una ventana deslizante evita el doble de tráfico en el borde de un límite por minuto.
• M12 · Monitoreo une predicciones y etiquetas por request ID.

En el Dojo: la estación 1, «Datos y etiquetas», usa el sha256 de cada foto para revisar que ninguna del golden set se cuele en las etiquetas. La 2, «Versionado y linaje», nombrará los datos por su huella cuando abra.

En Sensei: «Git: versiones del código» nombra cada versión con un hash; «Cifrado, llaves y certificados» presenta el HMAC, y «Ataques y cadena de suministro» verifica con hashes lo que descargas.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Qué es el tiempo Unix y qué pasa en 2038?Ver respuesta

   Los segundos desde el 1 de enero de 1970 a las 00:00 UTC. En un int32 llega a su tope el 19 de enero de 2038 y da la vuelta a 1901. En int64, no.

2. 2¿Por qué se guarda en UTC y no en la hora local?Ver respuesta

   UTC es la misma para todos y no cambia de horario; la local depende del lugar y tiene horas que no existen o se repiten. Se convierte al mostrar.

3. 3¿Con qué reloj mides cuánto tardó una request, y por qué?Ver respuesta

   Con el monotónico (time.monotonic()), que solo avanza. El de pared lo puede mover NTP o una persona, y una resta puede dar negativa.

4. 4¿Qué diferencia hay entre event time y processing time, y qué hace el watermark?Ver respuesta

   Event time es cuándo pasó; processing time, cuándo lo procesó el sistema. El watermark dice hasta qué event time se cree tener todo; cuando pasa el final de una ventana, la cierra.

5. 5¿Qué es un join point-in-time?Ver respuesta

   Unir a cada evento el último valor de cada feature disponible antes de su hora. Así el training set ve lo que vio el modelo, sin futuro.

6. 6¿Por qué con 32 bits de hash ya hay choques con unas 77,000 cosas, si hay 4,300 millones de casillas?Ver respuesta

   Por la paradoja del cumpleaños: chocan los pares, y n cosas forman ≈ n²/2 pares. La primera colisión se vuelve probable cerca de la raíz de las casillas.

7. 7¿Cómo asigna C01 un vendedor a un brazo del A/B, y por qué así?Ver respuesta

   Con cubeta = hash(sal + seller_id) mod 100: de 0 a 49 a A, de 50 a 99 a B. Es determinista, sin tabla, y con otra sal cada experimento sortea distinto.