Antes de pensar en BigQuery, en Dataflow o en cualquier pipeline sofisticado, casi todos los proyectos de datos en Google Cloud empiezan por el mismo sitio: un cubo de Cloud Storage. Vamos a ver cómo se organiza un data lake sobre este servicio y por qué no hace falta mover un solo byte para empezar a consultarlo.
Un data lake es, ante todo, una decisión de organización
Cloud Storage es almacenamiento de objetos: guarda archivos (CSV, JSON, Parquet, Avro, lo que sea) agrupados en buckets, sin esquema ni estructura de tablas. Eso lo hace perfecto como capa base de un data lake, porque acepta datos en crudo tal y como llegan de origen, sin transformarlos primero. La parte de «arquitectura» no la pone el servicio, la pones tú: cómo nombras los buckets, cómo organizas las carpetas y qué clase de almacenamiento usas para cada dato.
Clases de almacenamiento: pagar según la frecuencia de acceso
Cloud Storage ofrece varias clases pensadas para distintos patrones de acceso, todas con la misma durabilidad y la misma API, pero con precio y condiciones distintas. La decisión correcta depende de con qué frecuencia se va a leer ese dato, no de su tamaño ni de su antigüedad en sí.
| Clase | Pensada para | Detalle relevante |
|---|---|---|
| Standard | Datos de acceso frecuente («hot») | Sin coste de recuperación ni duración mínima de almacenamiento |
| Nearline | Acceso aproximado a una vez al mes | Duración mínima de 30 días, coste de acceso a los datos |
| Coldline | Acceso aproximado a una vez al trimestre | Duración mínima de 90 días, coste de acceso mayor |
| Archive | Copias de seguridad y retención a largo plazo | Duración mínima de 365 días, el coste de almacenamiento más bajo |
Lo interesante es que estas clases se pueden combinar con reglas de Object Lifecycle Management: un objeto puede nacer en Standard y, pasados N días sin que nadie lo toque, moverse solo a Nearline o Coldline. Así el propio bucket «envejece» los datos sin intervención manual.
Organizar el lake por zonas
La convención más habitual (y la que uso en mis propios proyectos) es separar el lake en zonas dentro de la misma jerarquía de buckets, normalmente identificadas por prefijo o por bucket dedicado:
Datos tal como llegan de la fuente (extracciones, exports, eventos). Inmutables: no se sobrescriben ni se limpian aquí.
Datos ya validados o con un primer tipado aplicado, normalmente convertidos a un formato columnar como Parquet.
Datos modelados y listos para el consumo analítico: agregaciones, dimensiones, tablas de negocio.
Esta separación no es una exigencia técnica de Cloud Storage, es disciplina de equipo. Pero es la que evita que, seis meses después, nadie sepa si un archivo en el bucket es la fuente original o el resultado de tres transformaciones encadenadas.
De Cloud Storage a BigQuery sin cargar nada
Aquí está la pieza que conecta el data lake con el mundo analítico: las tablas externas de BigQuery. Una tabla externa apunta a archivos en Cloud Storage (CSV, JSON, Avro, ORC o Parquet) y permite lanzar consultas SQL contra ellos sin haberlos cargado antes en el almacenamiento propio de BigQuery. Es habitual usarlas sobre la zona raw o staging para explorar datos nuevos, o cuando el origen cambia con tanta frecuencia que no compensa mantener una copia sincronizada.
El matiz importante: para consultar una tabla externa necesitas permisos tanto sobre la propia tabla en BigQuery como sobre los objetos en Cloud Storage. Y el rendimiento de estas consultas suele ser inferior al de una tabla nativa, así que para las cargas de trabajo curadas y de alto uso lo normal es acabar cargando los datos en BigQuery de verdad.
En resumen: el data lake sobre Cloud Storage no es más que almacenamiento barato y bien organizado por zonas, con la clase adecuada para cada patrón de acceso, y una puerta de entrada directa a BigQuery cuando toca analizar. La parte difícil no es la infraestructura, es mantener la disciplina de zonas a medida que el equipo crece.
¿Ya tienes el lake organizado y quieres exprimir el rendimiento de las consultas sobre esos datos? Te cuento cómo funcionan el particionado y el clustering en BigQuery.
Leer sobre particionado y clustering en BigQuery