Cómo manejar conjuntos de datos masivos en cualquier computadora portátil

Comencé un proyecto de modelado climático asumiendo que estaría tratando con conjuntos de datos «grandes». Luego vi el tamaño real: 2 terabytes. Escribí un script NumPy sencillo, lo ejecuté y tomé un café. Mala idea. Cuando regresé, mi máquina se había congelado. Reinicié y probé una porción más pequeña. El mismo accidente. Mi flujo de trabajo habitual no iba a funcionar. Después de algunas pruebas y errores, finalmente llegué a Zarr, una biblioteca de Python para almacenamiento de matrices fragmentadas. Me permitió procesar todo ese conjunto de datos de 2 TB en mi computadora portátil sin fallas. Esto es lo que aprendí:

Cuando «grandes datos» realmente significa gran problema

Trabajar con terabytes no es sólo «más datos». Es una clase de problema completamente diferente que rompe todas las suposiciones normales.

La mayoría de las computadoras portátiles tienen entre 16 y 32 GB de RAM. Un solo terabyte equivale aproximadamente a 1.000 GB. Simplemente no puedes cargar eso en la memoria, sin importar cuán inteligente sea tu código. Incluso si de alguna manera pudieras introducirlo, las lecturas secuenciales a esta escala son tremendamente lentas.

Todas las soluciones habituales tienen graves inconvenientes. Podría alquilar un servidor en la nube de alta memoria con cientos de gigabytes de RAM, pero eso se vuelve costoso rápidamente, y actualizar personalmente la RAM de su máquina local ya no es una alternativa rentable. Los precios de la RAM se han triplicado aproximadamente desde mediados de 2025 debido a que los centros de datos de IA consumen la mayor parte del suministro.

Esa actualización de 64 GB que costó 200 dólares la primavera pasada ahora cuesta más de 700 dólares. Las bases de datos funcionan muy bien para datos tabulares, pero resultan incómodas para matrices multidimensionales. Dividir archivos manualmente en partes manejables funciona hasta que necesitas actualizar algo y luego se convierte en un desastre frágil.

Necesitaba algo diseñado específicamente para operaciones de matriz que no requiriera costosas actualizaciones de hardware. Más importante aún, necesitaba que los colaboradores accedieran a los resultados en sus máquinas normales sin descargar primero terabytes de archivos.

Conoce a Zarr (por fin, algo diseñado para esto)

Zarr es una biblioteca de Python diseñada para almacenamiento en matrices grandes y fragmentadas. La idea central es maravillosamente simple: dividir las matrices en fragmentos almacenados de forma independiente. Cada fragmento se puede comprimir por sí solo y leer por separado del resto. Interactúa con una matriz Zarr casi exactamente como una matriz NumPy, con una sintaxis familiar de división e indexación. Pero bajo el capó, Zarr sólo carga los fragmentos que realmente necesitas en la memoria.

La biblioteca admite discos locales, unidades de red y backends en la nube como S3, Google Cloud Storage o Azure Blob. Esto hizo posible procesar datos alojados en la nube sin descargar todo primero. Para un conjunto de datos de 2 TB, esa capacidad por sí sola cambió las reglas del juego.

Zarr es de código abierto, está mantenido activamente por la comunidad científica de Python y funciona bien con el ecosistema existente. La API resulta familiar, no como aprender un sistema completamente nuevo. Si conoce NumPy, ya ha recorrido la mayor parte del camino.

Deje de bloquear sus scripts de Python: cómo maneja Zarr matrices masivas

¿Estás cansado de que los errores de falta de memoria descarrilen tu análisis de datos? Existe una mejor manera de manejar matrices enormes en Python.

Poniéndolo a prueba con datos reales

Procesar un conjunto de datos climáticos de 2 TB con Zarr manteniendo el uso de memoria por debajo de 4 GB. La matriz se escribe y lee de forma incremental y solo se cargan en la RAM los fragmentos necesarios.

Mi conjunto de datos de prueba fue de aproximadamente 2 TB de resultados de simulación climática que abarcan miles de pasos de tiempo. El objetivo era sencillo: calcular los promedios regionales de toda la serie temporal. Configuré una matriz Zarr con tamaños de fragmentos cuidadosamente seleccionados. Esto requirió algo de experimentación. Los fragmentos que son demasiado pequeños añaden gastos generales al administrar demasiados archivos. Los fragmentos que son demasiado grandes frustran el propósito al obligarte a cargar gigabytes en la memoria a la vez.

Finalmente me decidí por fragmentos que coincidían con mis patrones de acceso, dividiendo por tiempo y región geográfica. El código real se parecía notablemente a mi script NumPy original:

import zarr
import numpy as np
# Create a chunked Zarr array
store = zarr.DirectoryStore('climate_data.zarr')
z = zarr.open(store, mode='w', shape=(10000, 1000, 2000), 
              chunks=(100, 500, 500), dtype='float32')
# Write data in chunks
for i in range(100):
    chunk_data = process_raw_data(i)
    z[i*100:(i+1)*100] = chunk_data
# Read and process specific slices
regional_avg = z[:, 200:300, 500:600].mean(axis=0)

La primera ejecución completa se completó con éxito en unas pocas horas. El uso de memoria de mi computadora portátil se mantuvo en alrededor de 4 GB todo el tiempo. Sin bloqueos ni bloqueos, solo un progreso constante a través del conjunto de datos.

Aprenda los conceptos básicos de Python: creemos un rastreador de gastos simple

Tome control de sus finanzas mientras aprende a codificar en Python.

Las características de Zarr que realmente importan

La compresión fue sorprendentemente efectiva sin ningún ajuste. Zarr usa Blosc de forma predeterminada, lo que redujo mi conjunto de datos de 2 TB a menos de 400 GB. Para datos científicos con patrones y repeticiones, relaciones de compresión como ésta son comunes. Las lecturas parciales hicieron posible el análisis exploratorio. Podría cargar solo datos de enero, o solo una región específica, sin tocar el resto. Lo que antes era imposible se convirtió en rutina.

La compatibilidad con el almacenamiento en la nube elimina los cuellos de botella del disco local. Moví la matriz final a Google Cloud Storage. Los colaboradores podían abrirlo directamente sin descargas y dejé de preocuparme por las estrategias de copia de seguridad para archivos de varios terabytes.

Las escrituras paralelas me permiten dividir el procesamiento entre varios scripts o máquinas. Diferentes procesos podrían escribir en fragmentos separados simultáneamente sin conflictos. Esto convirtió un trabajo secuencial de varios días en algo que podía terminar en horas. Finalmente, mi flujo de trabajo cambió. En lugar de «procesar todo y luego guardar», cambié a «procesar y guardar de forma incremental». Zarr funciona tan bien para construir matrices pieza por pieza como para leerlas.

Donde Zarr te hace trabajar un poco más duro

A pesar de sus muchas ventajas, Zarr no está exento de desventajas. Aún es necesario pensar detenidamente sobre el tamaño de los fragmentos y los patrones de acceso. Las malas decisiones pueden hacer que las cargas de trabajo pequeñas sean más lentas que NumPy simple. El acceso aleatorio intenso a través de muchos fragmentos es caro. Si estás constantemente saltando de manera impredecible, pagarás el costo de cargar diferentes fragmentos repetidamente. Algunos problemas requieren repensar su enfoque.

Existe una verdadera curva de aprendizaje en torno al ajuste del rendimiento.

La documentación es sólida pero está distribuida en Zarr, Xarray para matrices etiquetadas y Dask para computación paralela. Averiguar qué herramienta maneja qué lleva tiempo. En la práctica, Zarr suele funcionar mejor combinado con Dask para operaciones paralelas o Xarray para etiquetas de dimensiones. La superposición entre herramientas puede resultar confusa para los recién llegados. Para mi carga de trabajo, que involucraba principalmente acceso secuencial y agregaciones regionales, las compensaciones valieron la pena. Pero si su problema ya cabe cómodamente en la RAM, quédese con NumPy.

Alejar: por qué esto cambió mi flujo de trabajo predeterminado

Zarr no es la única solución. HDF5 existe desde hace más tiempo. TileDB aborda problemas similares con diferentes opciones de diseño. NetCDF4 sigue siendo el estándar en la ciencia climática. Lo que hizo que Zarr se destacara fue la naturalidad con la que encajaba en el ecosistema de Python. Xarray agrega etiquetas de dimensión y sistemas de coordenadas, y Dask agrega paralelismo y computación distribuida. Las piezas se conectan suavemente.

Trabajar a una escala de terabytes ya no me parecía inusual, y uso Zarr por defecto una vez que los conjuntos de datos superan unos pocos gigabytes, incluso si técnicamente caben en la RAM. La conveniencia de la compresión y el almacenamiento en la nube por sí sola hace que valga la pena. La pila científica de Python ha madurado hasta convertirse en una importante plataforma de big data. Ya no necesita Hadoop o Spark para cargas de trabajo de matrices.


Zarr salvó el proyecto y probablemente salvó mi cordura. Lo que parecía imposible en mi computadora portátil se volvió manejable. Si trabaja con matrices grandes y sigue alcanzando límites de memoria, vale la pena explorar Zarr. La curva de aprendizaje se amortiza rápidamente, especialmente considerando que los precios actuales de la RAM hacen que las actualizaciones de hardware sean prohibitivamente costosas.

Comience con la documentación oficial de Zarr y primero experimente con estrategias de fragmentación en conjuntos de datos más pequeños. Puede empezar poco a poco y ampliar según sea necesario sin tener que reescribirlo todo. Una vez que se sienta cómodo con lo básico, el ecosistema más amplio de Xarray y Dask abre aún más posibilidades.

We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.
Accept