{"id":1294,"date":"2025-06-10T10:28:41","date_gmt":"2025-06-10T10:28:41","guid":{"rendered":"https:\/\/cloudlab.urv.cat\/catedracloud\/?p=1294"},"modified":"2025-06-10T10:28:47","modified_gmt":"2025-06-10T10:28:47","slug":"comprendiendo-delta-lake-como-un-transaction-log-permite-garantias-acid-sobre-un-object-storage","status":"publish","type":"post","link":"https:\/\/cloudlab.urv.cat\/catedracloud\/2025\/06\/10\/comprendiendo-delta-lake-como-un-transaction-log-permite-garantias-acid-sobre-un-object-storage\/","title":{"rendered":"Comprendiendo Delta Lake: \u00bfC\u00f3mo un transaction log permite garant\u00edas ACID sobre un object storage?"},"content":{"rendered":"\n

En nuestra publicaci\u00f3n anterior, exploramos el concepto de una tabla Lakehouse, un enfoque moderno que combina la escalabilidad de los data lakes con las funciones de gesti\u00f3n de datos de los data warehouse tradicionales. Las tablas lakehouse permiten evoluci\u00f3n de schema, transacciones ACID, y time travel, todo sobre un object storage y un query engine como Apache Spark. Pero \u00bfc\u00f3mo logran las tablas lakehouse estas caracter\u00edsticas?<\/p>\n\n\n\n

Para responder a esto, profundizaremos en los aspectos internos de Delta Lake, el formato Lakehouse m\u00e1s ampliamente adoptado. Delta Lake logra esto mediante el uso de un registro de transacciones y una disposici\u00f3n inteligente de archivos de datos en almacenamiento de objetos.<\/p>\n\n\n\n

El problema: La weak consistency de los object storage<\/h2><\/div>\n\n\n\n

Antes de adentrarnos en los mecanismos de Delta Lake, debemos entender por qu\u00e9 estos mecanismos son necesarios en primer lugar.<\/p>\n\n\n\n

Cuando se trabaja con archivos Parquet sin procesar en object storage (como Amazon S3, Azure Blob o Google Cloud Storage), r\u00e1pidamente se encuentran varias limitaciones. Los object storage son altamente disponible y eventualmente consistente, pero no garantizan operaciones at\u00f3micas ni una consistencia fuerte. Esto significa que:<\/p>\n\n\n\n

\n
<\/path><\/svg><\/span>No existe el concepto de bloqueo o transacciones.<\/span><\/div>\n\n\n\n
<\/path><\/svg><\/span>Los escritores concurrentes pueden corromper los datos o sobrescribirse entre s\u00ed.<\/span><\/div>\n\n\n\n
<\/path><\/svg><\/span>Los lectores pueden ver resultados parciales o desactualizados durante una actualizaci\u00f3n.<\/span><\/div>\n\n\n\n
<\/path><\/svg><\/span>No hay una forma integrada de aplicar esquemas o rastrear cambios a lo largo del tiempo.<\/span><\/div>\n\n\n\n
<\/path><\/svg><\/span>Una escritura fallida puede dejar la tabla en un estado inconsistente o corrupto. <\/span><\/div>\n<\/div><\/div>\n\n\n\n

Estas caracter\u00edsticas hacen que sea casi imposible construir sistemas de datos confiables con m\u00faltiples escritores y lectores directamente sobre almacenamiento de objetos.<\/p>\n\n\n\n

\n\n\n\n

La soluci\u00f3n: Un transaction log<\/h2>\n\n\n\n

Para superar las limitaciones descritas, Delta Lake introduce un registro de transacciones<\/strong>, conocido como Delta Log<\/strong> (_delta_log\/<\/code>). Este registro es el n\u00facleo de cada tabla Delta y es lo que permite caracter\u00edsticas como transacciones ACID, evoluci\u00f3n de schema y time travel.<\/p>\n\n\n\n

\u00bfQu\u00e9 es el Delta Log?<\/h3>\n\n\n\n

En esencia, el Delta Log es una secuencia ordenada de archivos JSON de solo anexado<\/strong> que registra cada cambio realizado en una tabla Delta. Se almacena junto a los archivos de datos en el mismo almacenamiento de objetos, dentro del directorio _delta_log\/<\/code>.<\/p>\n\n\n\n

Cada archivo en el registro corresponde a una transacci\u00f3n y contiene metadatos sobre:<\/p>\n\n\n\n

    \n
  • Adiciones de archivos<\/strong>: qu\u00e9 nuevos archivos Parquet se agregaron a la tabla.<\/li>\n<\/ul>\n\n\n\n
      \n
    • Eliminaciones de archivos<\/strong>: qu\u00e9 archivos fueron eliminados l\u00f3gicamente (aunque pueden seguir existiendo f\u00edsicamente).<\/li>\n\n\n\n
    • Metadatos de la tabla<\/strong>: cambios en el data schema, informaci\u00f3n de particionamiento y propiedades de la tabla.<\/li>\n\n\n\n
    • Versiones de transacci\u00f3n<\/strong>: seguimiento de la operaci\u00f3n y su origen (por ejemplo, qu\u00e9 Spark job realiz\u00f3 el cambio).<\/li>\n\n\n\n
    • Versiones de protocolo<\/strong>: asegurando la compatibilidad entre lectores\/escritores de Delta.<\/li>\n<\/ul>\n\n\n\n

      El transaction log act\u00faa como la \u00fanica fuente de verdad<\/strong> sobre el estado de la tabla. Para leer la instant\u00e1nea actual, un query engine, como Apache Spark, simplemente reproduce<\/strong> todas las entradas del registro hasta la \u00faltima transacci\u00f3n confirmada.<\/p>\n\n\n\n

      Habilitaci\u00f3n de Transacciones ACID con el Delta Log<\/h3>\n\n\n\n

      Delta Lake proporciona garant\u00edas ACID<\/strong>\u2014Atomicidad, Consistencia, Aislamiento y Durabilidad\u2014mediante una gesti\u00f3n cuidadosa del registro de transacciones:<\/p>\n\n\n\n

        \n
      • Atomicidad<\/strong>: Cada transacci\u00f3n agrega un nuevo archivo de registro que incluye todos sus cambios. Estos solo se hacen visibles una vez que la entrada completa del registro se ha escrito con \u00e9xito, asegurando que nunca se expongan escrituras parciales.<\/li>\n\n\n\n
      • Consistencia<\/strong>: Los almacenes de objetos como S3 o Azure Blob no garantizan consistencia de lectura despu\u00e9s de escritura. Esto significa que un archivo reci\u00e9n escrito puede no ser inmediatamente visible para los lectores posteriores. Delta Lake maneja esto mediante el uso de un \u00fanico archivo de registro por transacci\u00f3n, de modo que solo un archivo necesita ser visible para se\u00f1alar una confirmaci\u00f3n. Delta lake permite que los query engine esperen o reintenten la lectura de la \u00faltima versi\u00f3n del registro para asegurarse de que ven el estado m\u00e1s reciente.<\/li>\n\n\n\n
      • Aislamiento<\/strong>: Delta emplea control de concurrencia optimista para garantizar que los escritores concurrentes no interfieran con los cambios de los dem\u00e1s. Las transacciones solo se confirman si no han ocurrido actualizaciones conflictivas en el \u00ednterin.<\/li>\n\n\n\n
      • Durabilidad<\/strong>: Una vez que una transacci\u00f3n se escribe en el Delta Log, se persiste de manera confiable en el almac\u00e9n de objetos subyacente, que est\u00e1 dise\u00f1ado para una alta durabilidad.<\/li>\n<\/ul>\n\n\n\n

        Control de Concurrencia Optimista<\/h3>\n\n\n\n

        Delta Lake utiliza control de concurrencia optimista (OCC)<\/strong> para coordinar m\u00faltiples escritores. As\u00ed es como funciona:<\/p>\n\n\n\n

          \n
        1. Cada escritor lee el estado actual<\/strong> de la tabla reproduciendo el registro de transacciones.<\/li>\n\n\n\n
        2. Prepara los cambios<\/strong> (por ejemplo, agregar o eliminar archivos de datos) bas\u00e1ndose en esa instant\u00e1nea.<\/li>\n\n\n\n
        3. Intenta confirmar<\/strong> una nueva transacci\u00f3n escribiendo una nueva entrada en el registro con un n\u00famero de versi\u00f3n m\u00e1s alto.<\/li>\n\n\n\n
        4. Antes de confirmar<\/strong>, Delta verifica si otro escritor ya ha confirmado una versi\u00f3n m\u00e1s reciente del registro.<\/li>\n<\/ol>\n\n\n\n
            \n
          • Si no, la transacci\u00f3n se confirma con \u00e9xito.<\/li>\n\n\n\n
          • Si s\u00ed, hay un conflicto<\/strong>, y la transacci\u00f3n se reintenta (generalmente despu\u00e9s de volver a leer la \u00faltima instant\u00e1nea).<\/li>\n<\/ul>\n\n\n\n

            Este enfoque evita bloqueos y permite un alto rendimiento para cargas de trabajo concurrentes<\/strong>, haciendo que Delta Lake sea ideal para canalizaciones de datos distribuidas modernas.<\/p>\n\n\n\n

            \n\n\n\n

            Organizaci\u00f3n de Datos en Delta Lake: Archivos, Transacciones y el Registro<\/h2>\n\n\n\n

            Ahora que entendemos el papel del registro de transacciones, veamos c\u00f3mo Delta Lake organiza los datos y metadatos en el almacenamiento<\/strong>.<\/p>\n\n\n\n

            Estructura de Directorios<\/h3>\n\n\n\n

            Una tabla Delta almacenada en object storage consta de dos componentes principales:<\/p>\n\n\n\n

            \/mi-tabla\/\n\u251c\u2500\u2500 part-00000-...snappy.parquet\n\u251c\u2500\u2500 part-00001-...snappy.parquet\n\u251c\u2500\u2500 ...\n\u2514\u2500\u2500 _delta_log\/\n    \u251c\u2500\u2500 00000000000000000000.json\n    \u251c\u2500\u2500 00000000000000000001.json\n    \u251c\u2500\u2500 ...\n    \u251c\u2500\u2500 00000000000000000010.checkpoint.parquet\n    \u2514\u2500\u2500 ...<\/code><\/pre>\n\n\n\n
              \n
            • La ra\u00edz contiene archivos de datos Parquet<\/strong>, que representan las filas de la tabla, opcionalmente particionados en carpetas (por ejemplo, \/date=2024-01-01\/<\/code>).<\/li>\n\n\n\n
            • La carpeta _delta_log\/<\/code> almacena archivos de registro de transacciones<\/strong>, con un archivo JSON por cada transacci\u00f3n confirmada.<\/li>\n\n\n\n
            • Peri\u00f3dicamente, Delta escribe un checkpoint<\/strong> (una instant\u00e1nea compacta en formato Parquet del estado de la tabla) para acelerar la recuperaci\u00f3n y evitar la reproducci\u00f3n de demasiados registros JSON.<\/li>\n<\/ul>\n\n\n\n
              C\u00f3mo es un Archivo de Registro de Transacciones<\/h3>\n\n\n\n
              Cada archivo JSON en _delta_log\/<\/code> representa una transacci\u00f3n \u00fanica<\/strong> y contiene una lista de acciones en formato JSON. Cada acci\u00f3n describe un cambio en la tabla.<\/p>\n\n\n\n
              Por ejemplo:<\/p>\n\n\n\n
              [\n  {\n    \"add\": {\n      \"path\": \"part-00000-abc.snappy.parquet\",\n      \"size\": 123456,\n      \"modificationTime\": 1717000000000,\n      \"dataChange\": true,\n      \"partitionValues\": { \"date\": \"2025-06-01\" }\n    }\n  },\n  {\n    \"remove\": {\n      \"path\": \"part-00001-def.snappy.parquet\",\n      \"deletionTimestamp\": 1717000001234,\n      \"dataChange\": true\n    }\n  },\n  {\n    \"metaData\": {\n      \"id\": \"abcd1234\",\n      \"format\": \"parquet\",\n      \"schemaString\": \"{\\\"type\\\":\\\"struct\\\",\\\"fields\\\":[{\\\"name\\\":\\\"id\\\",\\\"type\\\":\\\"long\\\"}]}\",\n      \"partitionColumns\": [\"date\"],\n      \"configuration\": {\n        \"delta.enableChangeDataFeed\": \"true\"\n      }\n    }\n  }\n]<\/code><\/pre>\n\n\n\n
              Un archivo de transacci\u00f3n puede contener:<\/p>\n\n\n\n
                \n
              • add<\/code><\/strong>: Archivos Parquet nuevos agregados en la transacci\u00f3n.<\/li>\n\n\n\n
              • remove<\/code><\/strong>: Archivos eliminados l\u00f3gicamente (siguen existiendo hasta que se ejecuta un VACUUM<\/code>).<\/li>\n\n\n\n
              • metaData<\/code><\/strong>: Actualizaciones opcionales del esquema y configuraci\u00f3n de la tabla.<\/li>\n\n\n\n
              • txn<\/code><\/strong>: Rastrea la versi\u00f3n de la transacci\u00f3n para garantizar idempotencia (especialmente importante en escrituras en streaming).<\/li>\n\n\n\n
              • protocol<\/code><\/strong>: Especifica las versiones m\u00ednimas de lectores\/escritores que pueden acceder a la tabla.<\/li>\n<\/ul>\n\n\n\n
                En el ejemplo anterior, se muestra una transacci\u00f3n que a\u00f1ade el fichero part-00000-abc.snappy.parquet<\/code> a la tabla y elimina el fichero part-00001-def.snappy.parquet<\/code> .<\/p>\n\n\n\n
                C\u00f3mo se ve una Transacci\u00f3n Delta en la Pr\u00e1ctica<\/h3>\n\n\n\n
                Supongamos que ejecutas un simple INSERT<\/code> en SQL:<\/p>\n\n\n\n
                INSERT INTO mi_tabla VALUES (1, 'foo', '2025-06-01')<\/code><\/pre>\n\n\n\n
                Delta realizar\u00e1 los siguientes pasos:<\/p>\n\n\n\n
                  \n
                1. Escribir\u00e1 un nuevo archivo Parquet con esa fila (por ejemplo, part-00042-xyz.parquet<\/code>).<\/li>\n\n\n\n
                2. Crear\u00e1 un nuevo archivo de registro de transacci\u00f3n JSON (por ejemplo, 00000000000000000042.json<\/code>) con una acci\u00f3n add<\/code> que contiene la ruta del archivo y los valores de partici\u00f3n.<\/li>\n\n\n\n
                3. Opcionalmente eliminar\u00e1 archivos antiguos si la operaci\u00f3n implica sobrescritura o actualizaci\u00f3n.<\/li>\n\n\n\n
                4. Actualizar\u00e1 la instant\u00e1nea para que la pr\u00f3xima lectura incluya solo los archivos m\u00e1s recientes.<\/li>\n<\/ol>\n\n\n\n
                  C\u00f3mo Son los Archivos Parquet<\/h3>\n\n\n\n
                  Delta Lake no modifica el formato Parquet; simplemente lo usa como un formato de almacenamiento columnar<\/strong>. Cada archivo Parquet:<\/p>\n\n\n\n
                    \n
                  • Almacena un subconjunto de las filas de la tabla.<\/li>\n\n\n\n
                  • Puede estar organizado por partici\u00f3n y ordenado por claves de consulta comunes.<\/li>\n\n\n\n
                  • Es inmutable: las nuevas versiones de las filas se escriben como nuevos archivos, y los archivos antiguos se marcan para eliminaci\u00f3n.<\/li>\n<\/ul>\n\n\n\n
                    Este dise\u00f1o permite un almacenamiento inmutable de solo anexado<\/strong>, lo que se alinea bien con las capacidades del almacenamiento de objetos y simplifica las garant\u00edas transaccionales.<\/p>\n\n\n\n
                    Integrando Todo<\/h3>\n\n\n\n
                    En cualquier momento, el motor Delta puede reconstruir el estado completo de la tabla mediante:<\/p>\n\n\n\n
                      \n
                    1. Comenzar desde el \u00faltimo checkpoint<\/strong> (si est\u00e1 disponible).<\/li>\n\n\n\n
                    2. Leer todos los registros JSON de transacciones m\u00e1s recientes<\/strong>.<\/li>\n\n\n\n
                    3. Construir la lista actual de archivos Parquet activos<\/strong> (agregados menos eliminados).<\/li>\n\n\n\n
                    4. Leer solo esos archivos<\/strong> para devolver los resultados de la consulta.<\/li>\n<\/ol>\n\n\n\n
                      Este enfoque estructurado en capas basado en registros es lo que le da a Delta Lake su escalabilidad<\/strong>, fiabilidad<\/strong> y sem\u00e1ntica ACID<\/strong>, todo sobre almacenamiento de objetos econ\u00f3mico y escalable.<\/p>\n\n\n\n
                      \n\n\n\n
                      En este blog hemos visto c\u00f3mio Delta Lake aporta orden y confiabilidad al caos de los data lakes al introducir un registro de transacciones sobre object storage. Delta lake Resuelve las principales limitaciones de los data lakes tradicionales\u2014falta de consistencia, atomicidad y aislamiento\u2014permitiendo transacciones ACID, evoluci\u00f3n de data schemas y escrituras concurrentes sin sacrificar escalabilidad.<\/p>\n\n\n\n
                      Delta Lake convierte el almacenamiento de objetos en una base para an\u00e1lisis de alto rendimiento y calidad de producci\u00f3n.<\/p>\n\n\n\n
                      Comprender c\u00f3mo funciona Delta Lake internamente ayuda a los ingenieros y arquitectos de datos a razonar sobre el comportamiento de las tablas, optimizar el rendimiento y construir con confianza canalizaciones de datos confiables en una arquitectura Lakehouse.<\/p>\n\n\n\n
                      En futuras publicaciones, exploraremos otros formatos de lakehouse como Apache Hudi o Apache Iceberg.<\/p>\n","protected":false},"excerpt":{"rendered":"
                      En nuestra publicaci\u00f3n anterior, exploramos el concepto de una tabla Lakehouse, un enfoque moderno que combina la escalabilidad de los data lakes con las funciones de gesti\u00f3n de datos de los data warehouse tradicionales. Las tablas lakehouse permiten evoluci\u00f3n de schema, transacciones ACID, y time travel, todo sobre un object storage y un query engine […]<\/p>\n","protected":false},"author":6,"featured_media":1298,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","_swt_meta_header_display":false,"_swt_meta_footer_display":false,"_swt_meta_site_title_display":false,"_swt_meta_sticky_header":false,"_swt_meta_transparent_header":false,"footnotes":""},"categories":[34,41,113,1],"tags":[],"class_list":["post-1294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-almacenamiento","category-big-data","category-cloud-computing","category-uncategorized"],"jetpack_featured_media_url":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861.png","uagb_featured_image_src":{"full":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861.png",320,180,false],"thumbnail":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861-150x150.png",150,150,true],"medium":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861-300x169.png",300,169,true],"medium_large":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861.png",320,180,false],"large":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861.png",320,180,false],"1536x1536":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861.png",320,180,false],"2048x2048":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/06\/1734364154861.png",320,180,false]},"uagb_author_info":{"display_name":"Aitor Arjona","author_link":"https:\/\/cloudlab.urv.cat\/catedracloud\/author\/aitor\/"},"uagb_comment_info":4,"uagb_excerpt":"En nuestra publicaci\u00f3n anterior, exploramos el concepto de una tabla Lakehouse, un enfoque moderno que combina la escalabilidad de los data lakes con las funciones de gesti\u00f3n de datos de los data warehouse tradicionales. Las tablas lakehouse permiten evoluci\u00f3n de schema, transacciones ACID, y time travel, todo sobre un object storage y un query engine…","_links":{"self":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/comments?post=1294"}],"version-history":[{"count":4,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1294\/revisions"}],"predecessor-version":[{"id":1300,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1294\/revisions\/1300"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/media\/1298"}],"wp:attachment":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/media?parent=1294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/categories?post=1294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/tags?post=1294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}