🌐 Data Engineering Hub

Después de revisar DROP & RECREATE e INSERT OVERWRITE, llegamos a una de las operaciones más importantes cuando necesitamos sincronizar información entre tablas: 🔀 MERGE Si hemos trabajado anteriormente con SQL Server, PostgreSQL u otros motores relacionales, probablemente este concepto nos resulte familiar. La principal característica de es que permite combinar diferentes operaciones sobre una tabla destino: ➕ INSERT 🔄 UPDATE 🗑️ DELETE Todo a partir de la comparación entr

En el capítulo anterior vimos DROP & RECREATE TABLE, una estrategia sencilla pero que implica eliminar la tabla y, con ello, perder la continuidad de su historial. Ahora veremos una alternativa mucho más interesante: 🔄 INSERT OVERWRITE. Y, a diferencia de DROP & RECREATE, INSERT OVERWRITE permite reemplazar el contenido de una Delta Table sin destruir la tabla ni su historial de versiones. Cada ejecución genera una nueva transacción dentro del deltalog. 🗑️ Estado anterior ↓

Hasta ahora hemos explorado diferentes formas de escribir información en Delta Tables, tanto desde fuentes externas como desde archivos almacenados dentro de Databricks. Pero en un escenario real aparece una pregunta fundamental: 🤔 ¿Siempre debemos actualizar una Delta Table de la misma manera? La respuesta es no, la estrategia de escritura dependerá del proceso, el volumen de información, la frecuencia de actualización y el comportamiento que necesitemos sobre los datos. Po

Después de revisar cómo crear Delta Tables a partir de archivos almacenados en Volúmenes, aún quedaban dos enfoques por explorar para completar el panorama de escritura en Databricks: 🔄 CTAS + read_files() 🐍 PySpark 🔄 CTAS + read_files() En capítulos anteriores vimos que USING + OPTIONS permite crear tablas directamente desde un archivo, pero con una limitación importante: únicamente genera External Tables. Para superar esta restricción, podemos combinar CTAS (Create Table

En los capítulos anteriores exploramos cómo consultar archivos almacenados dentro de un Volumen utilizando tanto Spark SQL como PySpark. Sin embargo, en un entorno real de Data Engineering, el objetivo rara vez es quedarse únicamente con la lectura de los datos. Lo habitual es transformar esas fuentes de información y almacenarlas en Delta Tables, aprovechando las capacidades de Delta Lake, como el versionamiento, las transacciones ACID y la integración con Unity Catalog. En

Introducción En la primera parte de esta serie exploramos cómo consultar archivos almacenados en Volumes utilizando Spark SQL. En esta segunda parte realizaremos el mismo proceso, pero empleando PySpark, una de las herramientas más utilizadas por los Data Engineers para desarrollar procesos de transformación de datos dentro de Databricks. Dos formas de leer archivos PySpark ofrece dos enfoques principales para consultar archivos almacenados en un Volume: La primera consiste e

Introducción Hasta este punto la mayoría de los laboratorios estuvieron enfocados en Delta Tables, aprovechando las capacidades que ofrece Delta Lake para gestionar información dentro de Unity Catalog. Sin embargo, antes de convertir los datos en tablas, normalmente trabajamos con archivos como CSV, JSON, Parquet o Excel. Es aquí donde aparecen los Volumes, una forma gobernada de almacenar archivos en su estado original dentro de Unity Catalog. En esta primera parte de la ser

Introducción A medida que los proyectos de Data Engineering crecen, las consultas SQL suelen volverse más complejas. Es común trabajar con múltiples JOIN, agregaciones, subconsultas y funciones de ventana, haciendo que la lógica sea difícil de mantener y reutilizar. Para resolver este problema, Databricks incorpora las Views, un mecanismo que permite encapsular consultas SQL y reutilizarlas posteriormente como si fueran tablas. Un aspecto importante es que una vista no almace

Introducción En proyectos de Data Engineering es muy común necesitar una copia de una tabla para realizar pruebas, desarrollar nuevas transformaciones o incluso crear respaldos. Para ello, Databricks incorpora la funcionalidad Clone, que permite generar una nueva Delta Table a partir de otra ya existente. Sin embargo, antes de clonar una tabla conviene responder una pregunta: 👉 ¿Necesitamos únicamente una nueva definición lógica o una copia completamente independiente de los

Cuando comenzamos a trabajar con Delta Lake es normal asumir que los constraints funcionan igual que en una base de datos relacional. Sin embargo, Databricks adopta un enfoque diferente y podemos agruparlos en dos categorías principales: ✅ Enforced Constraints: Son restricciones que Delta Lake sí valida durante la escritura de datos., es decir, si un registro incumple alguna de estas condiciones, la operación es rechazada. Entre ellas encontramos: CHECK NOT NULL ℹ️ Informati

Cuando comenzamos a trabajar con SQL, normalmente creamos una tabla definiendo manualmente cada una de sus columnas mediante CREATE TABLE. Sin embargo, en proyectos reales de Data Engineering existe una alternativa mucho más práctica: CTAS (Create Table As Select). ¿Qué es un CTAS? CTAS permite crear una nueva tabla directamente a partir del resultado de una consulta SQL. En una sola operación, Databricks: Ejecuta la consulta. Infiere automáticamente el esquema. Crea la nueva

📖 Introducción Uno de los desafíos más interesantes al aprender procesamiento de datos en tiempo real es dar el salto desde escenarios basados en archivos hacia arquitecturas capaces de consumir y procesar eventos conforme estos son generados. Con ese objetivo desarrollé este proyecto utilizando Amazon Kinesis Data Streams como fuente de eventos y Databricks Structured Streaming como motor de procesamiento. A lo largo de la implementación se construyó un flujo completo de st

Introducción Después de comprender las diferencias entre Managed Tables y External Tables, surge una pregunta muy importante: 👉 ¿Qué sucede cuando eliminamos una tabla por error? La respuesta depende del tipo de tabla que estemos utilizando. 📦 Recuperando una Managed Table Las Managed Tables son administradas completamente por Databricks. Esto significa que Databricks controla tanto: Los metadatos registrados en Unity Catalog. Los archivos físicos almacenados en Delta Lake.

Introducción Una vez comprendido cómo funcionan Delta Lake y Unity Catalog, aparece una de las decisiones más importantes al momento de crear tablas en Databricks: 👉 ¿Managed Table o External Table? Aunque muchas personas piensan que la diferencia está relacionada con el formato de almacenamiento, la realidad es otra. La principal diferencia radica en quién administra los archivos físicos de la información. 📦 Managed Tables Las Managed Tables son tablas donde Databricks adm

Después de entender cómo funcionan las Delta Tables, el Transaction Log y el Time Travel, surge una pregunta bastante natural: 👉 ¿Qué ocurre con los archivos antiguos cuando realizamos cambios sobre una tabla? La respuesta está relacionada con una característica fundamental de Delta Lake: los archivos son inmutables. Por ello, operaciones como: INSERT UPDATE DELETE MERGE OPTIMIZE no modifican archivos existentes. En su lugar: 📦 Se generan nuevos archivos Parquet. 📝 Se regi

Después de explorar Time Travel y Restore Table, decidí revisar uno de los mecanismos más importantes para mejorar el rendimiento de una Delta Table: OPTIMIZE. Y, a medida que una tabla recibe operaciones como INSERT, UPDATE, DELETE, MERGE o procesos de Streaming, es común que se generen múltiples archivos pequeños (small files). Aunque Spark es un motor distribuido, leer miles de archivos pequeños puede generar un costo adicional asociado a la gestión y coordinación de esas

Después de revisar⏪Time Travel y comprender cómo consultar versiones históricas de una Delta Table, el siguiente paso natural es aprender a recuperar esos estados anteriores. Para ello, Delta Lake incorpora la operación RESTORE TABLE, una funcionalidad que permite reconstruir una tabla completa a partir de una versión específica o de una fecha y hora determinada. 🚨 Esta capacidad resulta especialmente útil cuando ocurren situaciones como: ❌ Actualizaciones incorrectas. ❌ Eli

Uno de los conceptos más interesantes de Delta Lake es la capacidad de consultar información histórica mediante la funcionalidad conocida como Time Travel. En este notebook práctico estuve revisando dos formas de acceder a versiones anteriores de una Delta Table: Consulta por número de versión. Consulta por fecha y hora específica (timestamp). Esta característica es posible gracias al historial de transacciones almacenado en el Transaction Log (_delta_log), que permite recons

Después de revisar la arquitectura de Databricks, tale como: Apache Spark, Delta Lake y Unity Catalog, decidí dar el siguiente paso: llevar toda esa teoría a la práctica. En este laboratorio construyo una Delta Table desde cero utilizando Spark SQL y una estructura gobernada mediante Catalog, Schema y Table. Además, realizo una primera inspección utilizando dos comandos fundamentales: DESCRIBE DETAIL Permite obtener información técnica sobre la tabla, incluyendo ubicación, fo

Introducción En el post anterior vimos cómo los datos recorren las distintas capas de Databricks hasta terminar almacenados físicamente como archivos Parquet dentro de una Delta Table. Sin embargo, esto nos lleva a realizar una serie de preguntas muy importantes: Si los archivos Parquet ya existen físicamente, ¿quién decide cuáles forman parte de la tabla? ¿Quién mantiene el historial de cambios? ¿Cómo sabe Delta Lake qué información es válida? La respuesta está en uno de los