“…bien, usemos la nube, se ve todo simple, que puede salir mal?” - 1 mes después una mega factura por varias decenas de miles de dólares.

La nube facilita la creación de servicios, y eso hace sentir a los developers como creadores de universos, los hace sentir poderosos, sin límites.

Sin embargo, sin un control adecuado, ese poder se puede ir rápidamente. Los costos pueden ser mayores a los ingresos del negocio y se rompe la promesa de que la nube ayuda al negocio. Se puede pasar fácilmente a la sensación de tenerlo todo a tenerlo nada.

Por eso es clave ser responsable en los costos de la nube, y también conocer las distintas estrategias.

Dentro de esas el provisionamiento es muy útil, obviamente eso genera un compromiso de uso, pero ofrece buenos descuentos y a la vez motiva a ser más controlado al conocer un límite, algo que con Pay as you Go no ocurre ya que da la sensación de que el límite no existiera.

Lo importante es que la estrategia tener la nube controlada de forma que sea la organización quien dirija a la nube y no que la nube dirija a la organización.

En fin, si quieres saber más como gestionar mejor los costos de la nube, puedes buscarme en mis redes sociales y contactarme :-)

Las imágenes de este post fueron creadas usando Google Gemini AI

Pero primero algunos conceptos.

¿Qué es Iceberg?

Iceberg es un formato de tabla que usa storage y la propia estructura de directorios para armar el catálogo. Digamos que tenemos un data lake storage s3 o adls con la siguiente carpeta:

/warehouse/database/table

donde warehouse sería la ruta del catálogo definido en configuración spark, equivalente a como si fuera un servidor de base de datos, database la base de datos y table la tabla de la base de datos. Si quiera consultar en el catálogo podría usar simple spark SQL de la siguiente forma:

SELECT col1, col2 FROM database.table

en este sentido es un esquema autoorganizado. Pero hay más, Iceberg ofrece versionamiento, evolución de esquema y no es necesario definir índices ya que los crea el mismo. Esto es gracias a su estructura que aprovecha el mismo storage y logs.

Click en imagen para abrir más grande en nueva pestaña

¿Qué es Minio?

Minio es un object storage compatible con el API de Amazon S3, se puede usar la misma api para la creación, actualización, modificación y eliminación de objetos y al ser open este permite tener su propio storage. Provee una interfaz web donde se pueden ver los objetos así como usar las mismas tools de las apis compatibles S3 y por lo tanto es compatible también con Spark.

Ejecución y revisión de datalake

Procedemos a importar el docker compose del artículo al equipo local y desde la ruta que lo guardamos lo ejecutamos con docker-compose up:

Click en imagen para abrir más grande en nueva pestaña

al ejecutar aparece una URL local al notebook jupyter:

Click en imagen para abrir más grande en nueva pestaña

vamos al notebook y se ve que este viene con varios ejemplos:

Click en imagen para abrir más grande en nueva pestaña

nos vamos al notebook Getting Started y ejecutamos hasta el SQL que crea una base de datos, una tabla y carga datos de un parquet a la tabla:

Click en imagen para abrir más grande en nueva pestaña

luego nos vamos a la interfaz de Minio, esta se entra en http://localhost:9001/, el usuario y password se ve en el archivo docker-compose.

Click en imagen para abrir más grande en nueva pestaña

entramos a la ruta warehouse y podemos ver que se crea la carpeta de la base de datos nyc y la tabla taxis, finalmente al entrar están las dos carpetas de metadata y data.

Click en imagen para abrir más grande en nueva pestaña

en la carpeta data se puede ver archivos parquet de la tabla, como se insertó una vez solo se ve uno, pero a medida que se agreguen aparecerán más.

Click en imagen para abrir más grande en nueva pestaña

y en la carpeta metadata está el log de la tabla en que mezcla archivos json y avro

Click en imagen para abrir más grande en nueva pestaña

finalmente revisamos el archivo json con la metadata

Click en imagen para abrir más grande en nueva pestaña

El notebook getting started tiene harta información sobre como ingestar datos, modificar tablas. También en los mismos notebooks hay ejemplo para consultar via DuckDB con PyIceberg y también escribir tablas sin necesidad de tener PySpark.

Espero que esta info les sea muy útil. Nos leemos!!

En el data engineering se puede trabajar con plataformas ya establecidas como Databricks, Bigquery o Fabric o de forma ad-hoc adaptando al negocio.

Usando plataformas:

La curva de aprendizaje es menor, lo que si tienes un equipo con mucha gente es útil ya que se reducen los costos de capacitación. Sin embargo, hay que tener mucho control de costos ya que al ser más fácil de usar, también es más fácil de ejecutar sin medir. Ya hay muchos casos de queries costosas en BigQuery, exceso de clusters en Databricks o sobreutilización de la capacidad en Fabric. Un beneficio adicional es que la seguridad viene en la plataforma, lo que facilita su gestión.

AD-HOC

Se puede armar una plataforma propia de datos usando Open Source: Hadoop, Spark, minio, Hudi, Iceberg, Flink, etc. Acá las cosas son más controlables, pero la curva de aprendizaje es más alta y requiere tener gente de muy alta expertise. Es una opción muy buena si hablamos de una Startup donde es un grupo reducido de personas con gran talento y capacidades que a la vez quieren mantener a raya el control de costos o llegar a niveles de optimizaciones más potentes. La seguridad también debe ser implementada y esto puede generar dolores de cabeza si no se tiene a personas con consciencia en estos temas.

Conclusiones

No hay opción mala o buena, pero unas reglas simples: Si tienes mucha gente y necesitas estandarizar la forma de trabajo, mejor optar por una plataforma. En cambio, tienes poca gente, muy talentosa y capaz y el rendimiento es clave para tu empresa, la opción ad-hoc es la mejor.

This is my blog.