Piénsalo como un CDC (Change Data Capture) nativo dentro de Delta Lake, sin necesidad de herramientas externas ni lectura de logs de base de datos. Los cambios quedan accesibles directamente vía Spark SQL o PySpark.

El esquema de eventos CDF

Al leer el CDF, obtienes las columnas de datos de tu tabla más tres columnas de metadatos automáticas:

Los cuatro valores posibles de _change_type son:

• insert — Fila nueva insertada

• update_preimage — Estado de la fila antes de la actualización

• update_postimage — Estado de la fila después de la actualización

• delete — Fila eliminada

Nota clave sobre updates: cada UPDATE genera dos filas: update_preimage y update_postimage. Esto es fundamental para SCD2, ya que tenemos el estado anterior y el nuevo con sus timestamps exactos.

Cómo habilitar el Change Data Feed en Fabric

CDF no está activo por defecto: debe activarse explícitamente. Además, solo captura cambios realizados después de su activación — el historial previo no queda registrado.

Hay tres formas de activarlo:

1. Al crear una tabla nueva

CREATE TABLE raw_productos (
    id       INT,
    nombre   STRING,
    precio   DECIMAL(10,2),
    stock    INT
)
TBLPROPERTIES (delta.enableChangeDataFeed = true);

2. En una tabla existente

ALTER TABLE raw_productos
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

3. Para todas las tablas nuevas de la sesión

spark.conf.set('spark.microsoft.delta.properties.defaults.enableChangeDataFeed', 'true')

Verificar que está habilitado

spark.sql("DESCRIBE DETAIL raw_productos") \
     .select('name', 'properties') \
     .show(truncate=False)

Resultado esperado en Fabric:

{delta.enableChangeDataFeed -> true, delta.stats.extended.collect -> true, ...}

Lectura de cambios

Puedes consultar los cambios por rango de versiones o por rango de timestamps. Ambos extremos del rango son inclusivos.

Spark SQL

-- Por rango de versiones
SELECT * FROM table_changes('raw_productos', 0, 10);

-- Desde una versión hasta la última disponible
SELECT * FROM table_changes('raw_productos', 0);

-- Por rango de timestamps
SELECT * FROM table_changes('raw_productos',
    '2026-01-01 00:00:00',
    '2026-03-05 09:30:55');

PySpark

# Por versiones
df = (spark.read
    .format('delta')
    .option('readChangeFeed', 'true')
    .option('startingVersion', 0)
    .option('endingVersion', 10)
    .table('raw_productos'))

# Por timestamps
df = (spark.read
    .format('delta')
    .option('readChangeFeed', 'true')
    .option('startingTimestamp', '2026-03-05 09:30:05')
    .option('endingTimestamp',   '2026-03-05 09:30:55')
    .table('raw_productos'))

# Desde una versión hasta la última disponible
df = (spark.read
    .format('delta')
    .option('readChangeFeed', 'true')
    .option('startingVersion', 0)
    .table('raw_productos'))

Ejemplo de salida real con una tabla de productos:

Almacenamiento de los datos de cambio

Delta Lake almacena los registros de cambio para operaciones UPDATE, DELETE y MERGE en la carpeta _change_datadentro del directorio de la tabla Delta en OneLake. Sin embargo, existen situaciones donde Delta Lake optimiza el proceso y no genera archivos en esta carpeta:

• Operaciones de solo inserción (INSERT): los cambios se calculan directamente desde el transaction log.

• Eliminaciones completas de partición: igualmente calculables sin archivos adicionales.

Los archivos en _change_data siguen la misma política de retención de la tabla. Si ejecutas VACUUM con el período de retención por defecto (7 días), también se limpiarán estos registros de cambio.

Caso de uso 1: Sincronización Silver → Gold

El primer caso de uso es el más frecuente en arquitecturas Medallion: propagar cambios desde la capa Silver a Gold procesando únicamente las filas que han cambiado.

Datos iniciales

Disponemos de dos tablas de productos (productos_silver y productos_gold) con los siguientes datos:

Y se generan los siguientes cambios sobre la tabla de silver:

# Actualizar precio del Laptop (bajada de precio)
spark.sql("""
    UPDATE productos_silver
    SET precio = 849.99, stock = 45
    WHERE producto_id = 1
""")

# Añadir nuevo producto al catálogo
nuevo = spark.createDataFrame([
    Row(5, 'Webcam HD', 'Perifericos', Decimal('59.99'), 180)
], schema)
nuevo.write.format('delta').mode('append').saveAsTable('productos_silver')

# Eliminar producto descatalogado
spark.sql("DELETE FROM productos_silver WHERE producto_id = 4")

Punto de partida: detectar la versión CDF inicial

Un problema práctico es saber desde qué versión empezar a leer el CDF. Consultar el historial de la tabla y buscar cuándo se habilitó delta.enableChangeDataFeed resuelve esto de forma robusta:

def get_cdf_start_version(table_name: str) -> int:
    """
    Obtiene la primera versión donde CDF fue habilitado en la tabla,
    consultando DESCRIBE HISTORY y buscando en operationParameters
    la propiedad delta.enableChangeDataFeed = true.
    """
    history_df = spark.sql(f"DESCRIBE HISTORY {table_name}")
    cdf_versions = []

    for row in history_df.collect():
        operation = row['operation'] or ''
        params    = row['operationParameters'] or {}

        if operation not in ('SET TBLPROPERTIES', 'CREATE TABLE',
                             'CREATE OR REPLACE TABLE AS SELECT'):
            continue

        raw_props = params.get('properties', '{}')
        try:
            props = json.loads(raw_props)
        except (json.JSONDecodeError, TypeError):
            props = {}

        if props.get('delta.enableChangeDataFeed') == 'true':
            cdf_versions.append(row['version'])

    if not cdf_versions:
        raise ValueError(
            f"CDF no está habilitado en '{table_name}'. "
            f"Ejecuta: ALTER TABLE {table_name} "
            f"SET TBLPROPERTIES (delta.enableChangeDataFeed = true)"
        )

    return min(cdf_versions)

El proceso de sincronización completo

Con los datos de Silver cargados y los cambios simulados (update de precio, insert de nuevo producto, delete de producto descatalogado), el proceso completo es:

from delta.tables import DeltaTable
from pyspark.sql import functions as F
from pyspark.sql.window import Window

# Obtener versión inicial del CDF
cdf_start_version = get_cdf_start_version('productos_silver')

# Leer todos los cambios
cambios_cdf = (spark.read
               .format('delta')
               .option('readChangeFeed', 'true')
               .option('startingVersion', cdf_start_version)
               .table('productos_silver'))

# Filtrar update_preimage (nos quedamos con el estado final)
cambios_filtrados = cambios_cdf.filter(
    F.col('_change_type') != 'update_preimage'
)

# Quedarse con la última operación por producto (en caso de múltiples cambios)
window = Window.partitionBy('producto_id').orderBy(F.col('_commit_version').desc())
ultimos_cambios = (cambios_filtrados
    .withColumn('rn', F.row_number().over(window))
    .filter(F.col('rn') == 1)
    .drop('rn'))

# Aplicar MERGE a Gold
gold   = DeltaTable.forName(spark, 'productos_gold')
upserts = ultimos_cambios.drop('_commit_version', '_commit_timestamp')

gold.alias('gold').merge(
    upserts.alias('silver'),
    'gold.producto_id = silver.producto_id'
).whenMatchedDelete(
    condition="silver._change_type = 'delete'"
).whenMatchedUpdateAll(
    condition="silver._change_type = 'update_postimage'"
).whenNotMatchedInsert(
    condition="silver._change_type = 'insert'",
    values={
        'producto_id': 'silver.producto_id',
        'nombre':      'silver.nombre',
        'categoria':   'silver.categoria',
        'precio':      'silver.precio',
        'stock':       'silver.stock',
    }
).execute()

El MERGE discrimina por _change_type dentro de cada cláusula whenMatched / whenNotMatched, propagando correctamente inserts, updates y deletes a Gold. Con row_number() resuelve el caso en que el mismo registro cambia varias veces entre dos ejecuciones — nos quedamos únicamente con su estado final.

select * from productos_gold

Puedes ver el notebook completo aquí: NB_cdf_sample.ipynb

Caso de uso 2: SCD Tipo 2 con CDF

El segundo caso de uso es más sofisticado: implementar Slowly Changing Dimension Type 2 (SCD2) aprovechando el preimage/postimage que proporciona CDF.

En SCD2, cada cambio genera una nueva fila en lugar de sobreescribir la existente, manteniendo el historial completo con columnas valid_from, valid_to e is_current.

CDF es ideal para SCD2 porque nos da exactamente lo que necesitamos: el estado anterior (update_preimage) y el nuevo (update_postimage) con el timestamp exacto del cambio.

Inicialización: snapshot inicial de Silver

En la primera ejecución no hay historial CDF que procesar — construimos Gold desde el snapshot de Silver en la versión donde se habilitó CDF:

SILVER_TABLE = 'productos_silver_scd2'
GOLD_TABLE   = 'productos_gold_scd2'

gold_exists = spark.catalog.tableExists(GOLD_TABLE)
cdf_start_version, cdf_start_timestamp = get_cdf_start_info(SILVER_TABLE)

if not gold_exists:
    # Primera ejecución: leemos el snapshot de silver exactamente en la versión
    # donde se habilitó CDF, usando Delta Time Travel. Así obtenemos el estado
    # inicial de la tabla sin depender de tipos de eventos CDF.
    silver_snapshot = (spark.read
                        .format('delta')
                        .option('versionAsOf', cdf_start_version)
                        .table(SILVER_TABLE))

    gold_df = (silver_snapshot
               .withColumn('valid_from', F.lit(cdf_start_timestamp).cast('timestamp'))
               .withColumn('valid_to',   F.lit(None).cast('timestamp'))
               .withColumn('is_current', F.lit(True)))

    gold_df.write.format('delta').mode('overwrite').saveAsTable(GOLD_TABLE)

    # Guardar watermark: la versión de silver que acabamos de procesar
    spark.sql(f"""
        ALTER TABLE {GOLD_TABLE}
        SET TBLPROPERTIES ('scd2.last_processed_version' = '{cdf_start_version}')
    """)

    print(f"[INIT] Tabla '{GOLD_TABLE}' creada desde snapshot v{cdf_start_version} ({cdf_start_timestamp}).")

else:
    print(f"[SKIP] Tabla '{GOLD_TABLE}' ya existe. Ejecuta el proceso incremental.")

display(spark.table(GOLD_TABLE).orderBy('producto_id'))

Patrón watermark: almacenar la última versión procesada como propiedad de la propia tabla Gold (scd2.last_processed_version) es una buena técnica — el estado del pipeline viaja junto con los datos, sin necesidad de tablas de control externas.

Simular cambios en Silver

# Actualizar precio del Laptop (bajada de precio)
spark.sql("""
    UPDATE productos_silver_scd2
    SET precio = 849.99, stock = 45
    WHERE producto_id = 1
""")

# Añadir nuevo producto al catálogo
nuevo = spark.createDataFrame([
    Row(5, 'Webcam HD', 'Perifericos', Decimal('59.99'), 180)
], schema)
nuevo.write.format('delta').mode('append').saveAsTable('productos_silver_scd2')

# Eliminar producto descatalogado
spark.sql("DELETE FROM productos_silver_scd2 WHERE producto_id = 4")

Proceso incremental SCD2

Una vez existe la tabla gold, el proceso incremental lee el CDF de silver desde la versión siguiente al watermark almacenado como propiedad de la tabla gold (scd2.last_processed_version).

Por cada lote de cambios aplica la lógica SCD2 en dos pasos:

1. Cerrar registros activos (is_current = True) en gold para los registros que han sido actualizados (update_preimage) o eliminados (delete) — se les asigna valid_to = _commit_timestamp e is_current = False mediante un MERGE.

2. Insertar nuevas versiones en gold para los registros nuevos (insert) o actualizados (update_postimage) — con valid_from = _commit_timestamp, valid_to = null e is_current = True.

Al finalizar, el watermark se actualiza con la última versión procesada.

SILVER_TABLE = 'productos_silver_scd2'
GOLD_TABLE   = 'productos_gold_scd2'

# Leer watermark: última versión de silver ya procesada
gold_props        = spark.sql(f"DESCRIBE DETAIL {GOLD_TABLE}").collect()[0]['properties']
last_version      = int(gold_props['scd2.last_processed_version'])
next_version      = last_version + 1

# Versión más reciente disponible en silver
silver_latest     = spark.sql(f"DESCRIBE HISTORY {SILVER_TABLE} LIMIT 1").collect()[0]['version']

if next_version > silver_latest:
    print(f"[SKIP] No hay cambios nuevos en silver desde la versión {last_version}.")
else:
    print(f"Procesando versiones {next_version} – {silver_latest} de silver...")

    cambios_df = (spark.read
                   .format('delta')
                   .option('readChangeFeed', 'true')
                   .option('startingVersion', next_version)
                   .table(SILVER_TABLE)
                   .cache())

    max_version = cambios_df.agg(F.max('_commit_version')).collect()[0][0]

    # ── Paso 1: cerrar registros activos en gold ──────────────────────────────
    # Para cada UPDATE (preimage) y DELETE buscamos el registro con is_current=True
    # y le ponemos valid_to = timestamp del commit en que dejó de ser válido.
    to_close = (cambios_df
                .filter(F.col('_change_type').isin(['update_preimage', 'delete']))
                .select('producto_id', '_commit_timestamp')
                .distinct())

    (DeltaTable.forName(spark, GOLD_TABLE).alias('gold')
     .merge(
         to_close.alias('c'),
         'gold.producto_id = c.producto_id AND gold.is_current = true'
     )
     .whenMatchedUpdate(set={
         'valid_to':   'c._commit_timestamp',
         'is_current': F.lit(False)
     })
     .execute())

    # ── Paso 2: insertar nuevas versiones en gold ─────────────────────────────
    # UPDATE postimage → nueva versión activa del registro modificado.
    # INSERT           → registro completamente nuevo en silver.
    new_records = (cambios_df
                   .filter(F.col('_change_type').isin(['update_postimage', 'insert']))
                   .withColumn('valid_from', F.col('_commit_timestamp'))
                   .withColumn('valid_to',   F.lit(None).cast('timestamp'))
                   .withColumn('is_current', F.lit(True))
                   .drop('_change_type', '_commit_version', '_commit_timestamp'))

    new_records.write.format('delta').mode('append').saveAsTable(GOLD_TABLE)

    # ── Paso 3: actualizar watermark ──────────────────────────────────────────
    spark.sql(f"""
        ALTER TABLE {GOLD_TABLE}
        SET TBLPROPERTIES ('scd2.last_processed_version' = '{max_version}')
    """)

    cambios_df.unpersist()
    print(f"[OK] Versiones {next_version}–{max_version} procesadas.")

display(spark.table(GOLD_TABLE).orderBy('producto_id', 'valid_from'))

Simular múltiples cambios sobre el mismo registro

El proceso incremental anterior funciona cuando cada producto cambia una sola vez por batch. Pero si el mismo producto_id recibe varios UPDATEs entre dos ejecuciones, el MERGE simple falla: después de cerrar el primer registro activo, el segundo preimage no encontrará ningún is_current = True y la cadena de versiones quedará rota.

Simulamos ese caso: dos bajadas de precio consecutivas sobre el producto 1 y un ajuste de stock en el producto 3, los tres en el mismo batch incremental.

# Primera bajada de precio del Laptop (commit independiente)
spark.sql("""
    UPDATE productos_silver_scd2
    SET precio = 799.99, stock = 30
    WHERE producto_id = 1
""")

# Segunda bajada de precio del Laptop (otro commit independiente)
spark.sql("""
    UPDATE productos_silver_scd2
    SET precio = 749.99, stock = 20
    WHERE producto_id = 1
""")

# Ajuste de stock en el Teclado
spark.sql("""
    UPDATE productos_silver_scd2
    SET stock = 180
    WHERE producto_id = 3
""")

Proceso incremental SCD2 con varias versiones

La solución al problema de múltiples cambios por producto es usar lead() sobre _commit_version en lugar del MERGE doble.

Lógica en dos pasos:

1. Cerrar el registro activo en gold usando el timestamp del primer evento del batch para ese producto (mínimo _commit_timestamp de preimages/deletes). Esto cierra exactamente una vez independientemente de cuántos cambios haya.

   cambios_df = (spark.read
                   .format('delta')
                   .option('readChangeFeed', 'true')
                   .option('startingVersion', next_version)
                   .table(SILVER_TABLE)
                   .cache())
   
   max_version = cambios_df.agg(F.max('_commit_version')).collect()[0][0]
   
   first_event = (cambios_df
                   .filter(F.col('_change_type').isin(['update_preimage', 'delete']))
                   .groupBy('producto_id')
                   .agg(F.min('_commit_timestamp').alias('first_change_ts')))
   
   (DeltaTable.forName(spark, GOLD_TABLE).alias('gold')
        .merge(
            first_event.alias('c'),
            'gold.producto_id = c.producto_id AND gold.is_current = true'
        )
        .whenMatchedUpdate(set={
            'valid_to':   'c.first_change_ts',
            'is_current': F.lit(False)
        })
        .execute())
   
   display(cambios_df.orderBy('_commit_timestamp'))
   
   display(first_event)
   

   

2. Construir todas las nuevas filas SCD2 a partir de los eventos update_postimage e insert, ordenados por _commit_version. Con lead(_commit_timestamp) calculamos el valid_to de cada fila: es el timestamp del siguiente evento para ese mismo producto_id. Si no hay siguiente evento (lead = null) es la versión activa (is_current = True). Los eventos delete se incluyen en la ventana para propagar su timestamp como valid_to de la última postimage, pero no generan fila propia.

   w = Window.partitionBy('producto_id').orderBy('_commit_version')
   
   new_rows = (cambios_df
               .filter(F.col('_change_type').isin(['insert', 'update_postimage', 'delete']))
               .withColumn('next_ts', F.lead('_commit_timestamp').over(w))
               .filter(F.col('_change_type') != 'delete')
               .withColumn('valid_from', F.col('_commit_timestamp'))
               .withColumn('valid_to',   F.col('next_ts'))
               .withColumn('is_current', F.col('next_ts').isNull())
               .drop('_change_type', '_commit_version', '_commit_timestamp', 'next_ts'))
   
   new_rows.write.format('delta').mode('append').saveAsTable(GOLD_TABLE)
   
   display(new_rows.orderBy('producto_id', 'valid_from'))
   

   

Resultado final

Reconstrucción completa de gold desde silver

En lugar de mantener el proceso incremental, a veces es útil (o necesario) reconstruir la tabla gold desde cero a partir de todo el historial CDF de silver.

La clave es que los eventos del CDF (insert, update_postimage, delete) forman una línea de tiempo ordenada por _commit_version para cada producto_id. Aplicando lead(_commit_timestamp) sobre esa ventana obtenemos directamente el valid_to de cada versión sin necesidad de MERGE ni watermark:

• insert / update_postimage → generan una fila en gold con valid_from = _commit_timestamp y valid_to = siguiente evento del mismo producto

• delete → no genera fila, pero su timestamp se propaga como valid_to de la última postimage gracias al lead()

• update_preimage → descartado (es el espejo del postimage anterior, no aporta información nueva)

El resultado es idéntico al que produce el proceso incremental acumulado, pero calculado en un único scan del CDF.

SILVER_TABLE    = 'productos_silver_scd2'
GOLD_TABLE_FULL = 'productos_gold_scd2_full'

cdf_start_version, _ = get_cdf_start_info(SILVER_TABLE)

# Leer todo el historial CDF desde la versión inicial
all_events = (spark.read
               .format('delta')
               .option('readChangeFeed', 'true')
               .option('startingVersion', cdf_start_version)
               .table(SILVER_TABLE))

# Ventana por producto ordenada por versión de commit (orden real de los cambios)
w = Window.partitionBy('producto_id').orderBy('_commit_version')

gold_full_df = (all_events
    # Conservamos insert, update_postimage y delete.
    # delete entra en la ventana para que su timestamp llegue como valid_to
    # de la última postimage/insert, pero no generará fila propia.
    .filter(F.col('_change_type').isin(['insert', 'update_postimage', 'delete']))
    # valid_to = timestamp del siguiente evento para este producto_id (o null si es el último)
    .withColumn('next_ts', F.lead('_commit_timestamp').over(w))
    # Eliminar los delete (no generan fila en gold)
    .filter(F.col('_change_type') != 'delete')
    .withColumn('valid_from', F.col('_commit_timestamp'))
    .withColumn('valid_to',   F.col('next_ts'))
    .withColumn('is_current', F.col('next_ts').isNull())
    .drop('_change_type', '_commit_version', '_commit_timestamp', 'next_ts'))

gold_full_df.write.format('delta').mode('overwrite').saveAsTable(GOLD_TABLE_FULL)

print(f"Tabla '{GOLD_TABLE_FULL}' generada con {gold_full_df.count()} filas.")
display(spark.table(GOLD_TABLE_FULL).orderBy('producto_id', 'valid_from'))

Puedes ver el notebook completo aquí: NB_cdf_scd2.ipynb

VACUUM y CDF: una convivencia que hay que gestionar

Una de las operaciones de mantenimiento más habituales en Delta Lake es VACUUM, que elimina los archivos físicos que ya no son necesarios para la versión actual de la tabla. En tablas con CDF activo, esta operación tiene consecuencias criticas que hay que entender bien antes de ejecutarla.

⚠️El problema central

VACUUM elimina tanto los archivos de datos de versiones antiguas como los archivos de la carpeta changedata. Una vez ejecutado, es imposible recuperar esos cambios: no existe ninguna operacion de rollback para datos fisicamente borrados.

CDF y VACUUM compiten directamente: CDF necesita el historial para ser util; VACUUM lo elimina para ahorrar almacenamiento.

Que ocurre si VACUUM elimina versiones que necesita CDF

# Despues de ejecutar VACUUM, esta lectura puede FALLAR:
spark.read \
    .format('delta') \
    .option('readChangeFeed', 'true') \
    .option('startingVersion', 0) \
    .table('productos_silver')

# Error: Error getting change data for range [0, 5].
# The provided starting version 0 is older than the
# earliest available version for this table.

Controlar la retención: dos propiedades clave

Delta Lake tiene dos propiedades distintas que controlan la retención. Ambas deben estar alineadas: si solo amplias el log pero no los archivos fisicos, el log registrara versiones para las que ya no existen datos:

# Ver la configuracion actual
spark.sql('DESCRIBE DETAIL productos_silver') \
     .select('properties') \
     .show(truncate=False)

# Ampliar retencion a 90 dias
spark.sql("""
    ALTER TABLE productos_silver
    SET TBLPROPERTIES (
        delta.logRetentionDuration         = 'interval 90 days',
        delta.deletedFileRetentionDuration = 'interval 90 days'
    )
""")

# delta.logRetentionDuration      -> conserva entradas del transaction log
# delta.deletedFileRetentionDuration -> conserva archivos fisicos eliminados incluida la carpeta _change_data)

Validar la versión disponible antes de leer CDF

Es recomendable comprobar que la versión de inicio del CDF sigue disponible antes de lanzar el pipeline, especialmente en entornos donde VACUUM se ejecuta de forma automática:

def get_oldest_available_version(table_name: str) -> int:
    """
    Devuelve la version mas antigua disponible en el historial.
    Util para detectar si VACUUM ha eliminado parte del historial CDF.
    """
    history_df = spark.sql(f'DESCRIBE HISTORY {table_name}')
    return history_df.agg({'version': 'min'}).collect()[0][0]


oldest = get_oldest_available_version('productos_silver')
print(f'Version mas antigua disponible: {oldest}')

if cdf_start_version < oldest:
    raise ValueError(
        f'La version de inicio del CDF ({cdf_start_version}) ya no esta disponible. '
        f'La version mas antigua en el historial es {oldest}. '
        f'Es posible que VACUUM haya eliminado parte del historial.'
    )

Recomendaciones y buenas prácticas

1. Activa CDF desde el inicio del ciclo de vida de la tabla

CDF no captura el historial previo a su activación. Actívalo al crear la tabla o lo antes posible. En Fabric, usa la configuración global de sesión para que todas las tablas nuevas lo hereden:

spark.conf.set('spark.microsoft.delta.properties.defaults.enableChangeDataFeed', 'true')

O bien pásalo como opción al escribir:

df.write.format('delta').option('delta.enableChangeDataFeed', 'true').saveAsTable('mi_tabla')

2. Usa siempre startingVersion, no startingTimestamp, en procesos incrementales

Los timestamps pueden tener problemas de zona horaria o precisión. La versión del log de Delta es determinista e inequívoca. Guarda el watermark como número de versión.

3. Verifica siempre si hay cambios nuevos antes de leer el CDF

Antes de llamar a readChangeFeed, comprueba que realmente hay versiones nuevas:

silver_latest = spark.sql(f"DESCRIBE HISTORY {SILVER_TABLE} LIMIT 1").collect()[0]['version']
if next_version > silver_latest:
    print("[SKIP] No hay cambios nuevos.")

Esto evita errores cuando no hay nada que procesar.

4. Filtra update_preimage lo antes posible

En la mayoría de casos de uso (sincronización simple, upserts), el update_preimage no es necesario. Filtrarlo lo antes posible reduce el volumen de datos que Spark tiene que manejar. En SCD2 sí lo necesitas, pero solo para extraer el timestamp del primer evento.

5. Usa cache() cuando el DataFrame de CDF se lee múltiples veces

En el proceso SCD2, el DataFrame de cambios se usa en dos pasos (cerrar registros + insertar nuevos). Cachearlo evita releer el CDF dos veces:

cambios_df = (spark.read
               .format('delta')
               .option('readChangeFeed', 'true')
               .option('startingVersion', next_version)
               .table(SILVER_TABLE)
               .cache())

# resto de código

cambios_df.unpersist()

6. Usa el patrón lead() para manejar múltiples cambios en el mismo batch

El MERGE simple de SCD2 solo funciona cuando cada registro cambia una vez por batch. Para el caso general, el patrón con lead(_commit_timestamp) sobre una ventana ordenada por _commit_version es la solución correcta y escalable.

7. Ten en cuenta el coste de almacenamiento

CDF genera archivos adicionales de cambios en _change_data/ dentro del directorio de la tabla. En tablas con alta frecuencia de escritura, esto puede aumentar el almacenamiento significativamente. Evalúa si necesitas CDF en todas las tablas o solo en las que son fuente de otros procesos.

8. CDF y VACUUM: precaución con la retención

Si ejecutas VACUUM con una retención baja, puedes perder archivos de cambios que todavía no has procesado. Asegúrate de que la retención de VACUUM sea mayor que el intervalo máximo entre ejecuciones de tu pipeline.

¿Qué es Sparkwise?

Sparkwise es una herramienta de diagnóstico y optimización para Apache Spark que proporciona análisis inteligentes, recomendaciones de configuración y perfilado completo de sesiones. Su objetivo es hacer que la optimización de Spark sea simple, efectiva y hasta divertida, eliminando la necesidad de ser un experto en configuraciones complejas.

¿Por qué usar Sparkwise?

La optimización de Spark en Microsoft Fabric puede ser costosa y compleja. Sparkwise aborda estos problemas ofreciendo:

• 💰 Optimización de costos: Detecta configuraciones que desperdician capacidad y aumentan el tiempo de ejecución

• ⚡ Maximización del rendimiento: Habilita optimizaciones específicas de Fabric como Native Engine, V-Order y perfiles de recursos

• 🎓 Aprendizaje simplificado: Asistente interactivo de Q&A para 133 configuraciones de Spark, Delta Lake y Fabric

• 🔍 Comprensión de workloads: Perfilado exhaustivo de sesiones, ejecutores, jobs y recursos

• ⏱️ Ahorro de tiempo: Detecta bloqueadores de Starter Pool para evitar cold-starts de 3-5 minutos

• 📊 Decisiones basadas en datos: Recomendaciones priorizadas con análisis de impacto

Puedes leer todas las características que incluye aquí: sparkwise · PyPI

Sparkwise en acción

Instalación y configuración

En tu notebook de Fabric, ejecuta:

%pip install sparkwise

Verificar la instalación

import sparkwise
print(f"Sparkwise versión: {sparkwise.__version__}")

Importar módulos necesarios

from sparkwise import (
    diagnose, 
    ask, 
    profile, 
    predict_scalability,
    analyze_efficiency,
    detect_skew
)

Análisis exhaustivo de la sesión actual

diagnose.analyze()

¿Qué verás?

El diagnóstico te mostrará 5 categorías de análisis:

1. Native Execution Engine: ¿Está usando Velox para acelerar queries?

2. Spark Compute: ¿Estás en Starter Pool o Custom Pool?

3. Data Skew: ¿Hay tareas desequilibradas?

4. Delta Optimizations: ¿Están habilitadas V-Order, Optimize Write?

5. Runtime Tuning: ¿Está habilitado AQE (Adaptive Query Execution)?

Interpretar los resultados

Supongamos que obtienes esta salida:

Esto significa:

• Native Engine deshabilitado: Tu workload no está aprovechando Velox, el motor de ejecución nativo de Fabric que puede acelerar consultas entre 3-8x. Esto es especialmente crítico para operaciones de agregación, filtrado y joins.

• AQE crítico: Sin Adaptive Query Execution, Spark no puede ajustar dinámicamente el plan de ejecución basándose en estadísticas reales. Estás perdiendo optimizaciones automáticas como:

  • Coalescing de particiones pequeñas

  • Optimización de joins sesgados

  • Mejor paralelización dinámica

• Tamaño de partición subóptimo: Con ejecutores de 56GB, particiones de 128MB son demasiado pequeñas. Esto genera overhead innecesario al procesar muchas particiones pequeñas en lugar de menos particiones más grandes y eficientes.

Resumen consolidado

Al final del diagnóstico, Sparkwise muestra un resumen consolidado que te permite ver de un vistazo el estado de tu configuración:

Cómo leer esta tabla:

• Status: Indica el estado general de cada categoría

  • ✅ Good: Configuración óptima sin problemas críticos

  • ⚠️ Issues: Hay problemas que requieren atención

  • ❌ Critical: Problemas graves que afectan significativamente el rendimiento

• Critical Issues: Número de configuraciones con prioridad CRITICAL que deben solucionarse inmediatamente

• Recommendations: Total de recomendaciones de mejora (incluye todos los niveles de prioridad)

Tabla de recomendaciones priorizadas

Después del resumen, Sparkwise presenta una tabla detallada con todas las recomendaciones ordenadas por prioridad:

Prioridades explicadas:

1. 🔴 CRITICAL: Problemas que impactan significativamente el rendimiento o costos. Deben aplicarse inmediatamente.

   • Ejemplo: AQE deshabilitado puede causar 30-50% más de tiempo de ejecución

2. 🟡 HIGH: Optimizaciones importantes con impacto medible y claro.

   • Ejemplo: Native Engine puede acelerar queries 3-5x

3. 🔵 MEDIUM: Mejoras relevantes para casos de uso específicos.

   • Ejemplo: V-Order beneficia principalmente a workloads de lectura intensiva

4. ⚪ LOW: Ajustes finos y optimizaciones menores.

   • Ejemplo: Ajustes de tamaño de partición para ejecutores específicos

Predicción de escalabilidad y costos

Una de las características más valiosas de Sparkwise es su capacidad para predecir costos y recomendar la configuración óptima de infraestructura. Después de ejecutar tu workload, puedes usar predict_scalability() para obtener un análisis detallado de costos y rendimiento.

# Predecir costos si ejecutas este job 100 veces al mes
predict_scalability(runs_per_month=100)

Obtendrás:

• Comparación entre Starter Pool vs Custom Pool

• VCore-horas mensuales

• Costos estimados

• Recomendación de configuración óptima

El resultado que me ha dado a mi ha sido este… tendré que probarlo más a fondo porque no realiza bien las comparativas.

Analizar eficiencia de cómputo

analyze_efficiency(runs_per_month=100)

Verás:

• Tiempo de cómputo activo vs desperdiciado

• Costo del desperdicio en VCore-horas

• Score de eficiencia (0-100%)

• Estrategia de reducción de desperdicios

Análisis avanzado de tus sesiones

Analizar la sesión completa

from sparkwise import profile, profile_executors, profile_jobs, profile_resources

profile.profile()

Analizar ejecutores, jobs y recursos

print("⚡ Perfil de Ejecutores:")
profile_executors.profile()

print("🚀 Perfil de Jobs:")
profile_jobs.profile()

print("💾 Perfil de Recursos:")
profile_resources.profile()

Entender configuraciones con el asistente Q&A

Preguntar sobre configuraciones

Si no entiendes alguna configuración, usa el asistente:

# Preguntar sobre perfiles de recursos
ask.config('spark.fabric.resourceProfile')

Obtendrás:

• Qué hace la configuración

• Valores recomendados para tu workload

• Ejemplos de uso

• Configuraciones relacionadas

Buscar configuraciones por tema

# Buscar todas las configuraciones relacionadas con "optimize"
ask.search('optimize')

Detección y solución de Data Skew

Detectar Skew Básico

skew_results = detect_skew()

Identificarás:

• Tareas que tardan mucho más que otras

• Particiones desbalanceadas

• Joins problemáticos

Análisis avanzado de Skew en DataFrames

Para un análisis más profundo a nivel de partición, usa AdvancedSkewDetector:

from sparkwise.core.advanced_skew_detector import AdvancedSkewDetector
detector = AdvancedSkewDetector()
detector.analyze_partition_skew(your_df, ["key_column"])

El análisis muestra dos secciones clave:

📊 Partition Size Distribution

Qué significa:

• Mean Size: Tamaño promedio por partición (1 fila) - extremadamente bajo

• Max Size: La partición más grande tiene 2.8M filas

• Min Size: La partición más pequeña tiene solo 1 fila

• Std Dev: Desviación estándar de 1,119 indica alta variabilidad

🎯 Skew Metrics (Métricas de Sesgo)

1. Skew Ratio: 1963143.87x 🔴

   • La partición más grande es casi 2 millones de veces más grande que la más pequeña

   • Esto es EXTREMADAMENTE CRÍTICO

   • Umbrales típicos:

     • < 3x: ✅ Aceptable

     • 3-10x: ⚠️ Moderado

     • 10-100x: 🔴 Alto

     • 100x: 🔴 CRÍTICO (tu caso: 1.9M x)

2. Variation: 77601.48%

   • Hay una variabilidad del 77,601% entre particiones

   • Indica que los datos están completamente desbalanceados

3. Severity: CRITICAL

   • Requiere acción inmediata

   • Este nivel de skew puede causar:

     • 1 tarea tomando horas mientras las demás terminan en segundos

     • Out of Memory (OOM) en el ejecutor con la partición grande

     • Subutilización masiva de recursos (99% de ejecutores ociosos)

Impacto en el rendimiento

Con un skew de 1.9M x:

• Escenario sin skew: 10 ejecutores × 100 tareas = todas terminan en ~5 minutos

• Escenario con tu skew: 9 ejecutores terminan en 5 segundos (procesar 1 fila) 1 ejecutor tarda 2+ horas (procesar 2.8M filas)

• Resultado:

  • 99% de recursos desperdiciados esperando

  • Runtime total = tiempo del ejecutor más lento

  • Costo = 10 ejecutores × 2 horas (aunque 9 están ociosos)

Estrategias de mitigación

Sparkwise te proporciona 4 estrategias ordenadas por efectividad para este caso:

🔴 Estrategia 1: Salting (MÁS RECOMENDADA para skew crítico)

El salting distribuye artificialmente las claves sesgadas

Impacto esperado:

• Reducción de runtime: 80-95%

• Distribución: En lugar de 1 partición con 2.8M filas, tendrás 20 particiones con ~140K filas cada una

• Utilización de recursos: Pasarás de 1 ejecutor trabajando a 10-20 ejecutores en paralelo

¿Por qué funciona?

• Convierte 1 clave problemática en 20 claves diferentes

• Spark puede distribuir esas 20 claves entre múltiples ejecutores

• Todos los ejecutores procesan cargas similares (~140K filas)

⚠️ Estrategia 2: Filter Before Join

Reduce el volumen de datos antes de operaciones costosas

Impacto:

• Reducción de 30-70% en tiempo de procesamiento

• Menos shuffle de datos

• Solo útil si puedes filtrar sin perder datos necesarios

🔄 Estrategia 3: Repartition by Multiple Columns

Distribuye por múltiples dimensiones para mejor balance

Cuándo usar:

• Cuando tienes otra columna con buena cardinalidad

• Para operaciones posteriores de groupBy por múltiples columnas

• Menos efectivo que salting para skew extremo como en este ejemplo

📡 Estrategia 4: Use Broadcast Join for Small Tables

Si estás haciendo join con una tabla pequeña

Limitación:

• Solo funciona si una tabla es pequeña (<100MB por defecto)

• No resuelve el skew dentro de una tabla, solo evita shuffle en joins

Optimización de almacenamiento

Análisis completo de almacenamiento

# Analizar tabla Delta completa
sparkwise.analyze_storage("Tables/green_taxi_location_analysis")

Esto ejecuta 3 análisis:

1. Detección de archivos pequeños

2. ROI de VACUUM

3. Efectividad de particiones

Solucionar problema de archivos pequeños

Primero, detectar el problema

sparkwise.check_small_files("Tables/green_taxi_location_analysis", threshold_mb=10)

Seguir recomendaciones de optimización

spark.sql("OPTIMIZE delta.`Tables/green_taxi_location_analysis`")

# Habilitar auto-optimización para el futuro
spark.conf.set("spark.databricks.delta.optimizeWrite.enabled", "true")
spark.conf.set("spark.databricks.delta.autoCompact.enabled", "true")

Calcular ROI de VACUUM

Analizar beneficio de limpiar versiones antiguas

sparkwise.vacuum_roi("Tables/green_taxi_location_analysis", retention_hours=168)

Analizar efectividad de particiones

sparkwise.check_partitions("Tables/green_tripdata_2017")

Análisis de planes de consulta SQL

from sparkwise import analyze_query

df = spark.sql("""
    SELECT VendorID, payment_type, 
           SUM(fare_amount) as total_fare,
           AVG(trip_distance) as avg_distance
    FROM delta.`Tables/green_tripdata_2017`
    WHERE fare_amount > 10
    GROUP BY VendorID, payment_type
""")

# Analizar el plan de ejecución
analyze_query(df)

Detectarás:

• Productos cartesianos accidentales

• Full table scans innecesarios

• Shuffles excesivos

• Compatibilidad con Native Engine

Conclusión

Sparkwise transforma la compleja tarea de optimizar Apache Spark en Microsoft Fabric en un proceso guiado, automatizado y basado en datos. Ya seas ingeniero de datos, científico de datos o administrador de plataforma, esta librería te proporciona las herramientas necesarias para maximizar el rendimiento, minimizar costos y tomar decisiones informadas sobre tu infraestructura de datos.

Con su combinación de diagnósticos automatizados, análisis avanzados, optimización de almacenamiento y un asistente interactivo de configuración, sparkwise se posiciona como una herramienta esencial en el toolkit de cualquier profesional que trabaje con Spark en Fabric.

Agradecimiento especial

Un sincero agradecimiento a Santhosh Ravindran. Ha construido una herramienta que democratiza la optimización de Apache Spark, haciendo accesible para ingenieros de datos de todos los niveles lo que antes requería años de experiencia especializada.

¿Cómo funcionan los Deletion Vectors?

Tradicionalmente, Delta Lake utiliza un enfoque Copy-on-Write:
cuando se elimina, actualiza o mergea una fila dentro de un archivo Parquet, el archivo completo debe reescribirse, excluyendo las filas afectadas. Esto es costoso en E/S, especialmente para archivos grandes o modificaciones puntuales.

Con los Deletion Vectors, Delta introduce un modelo Merge-on-Read:

• Los archivos Parquet originales no se reescriben.

• Las filas eliminadas se registran en un archivo auxiliar comprimido (un .bin).

• Durante la lectura, el motor aplica el vector de eliminación y descarta esas posiciones lógicamente.

• El coste de reescritura total se pospone a operaciones posteriores como OPTIMIZE o REORG TABLE ... APPLY (PURGE).

Este enfoque reduce de manera drástica la E/S asociada a las operaciones de DELETE/UPDATE/MERGE.

🛠️ Ejemplo Práctico en Microsoft Fabric

A continuación definimos dos tablas Delta:
una sin Deletion Vectors (Copy-on-Write) y otra con DV habilitado (Merge-on-Read).

Preparación y creación de tablas

Primero, creamos los datos base y luego las dos tablas, una sin la propiedad Deletion Vectors y otra con esta propiedad habilitada.

data = [
    (1, "Ana", "Ventas"), 
    (2, "Luis", "IT"), 
    (3, "Marta", "Marketing"), 
    (4, "Carlos", "Ventas"), 
    (5, "Elena", "IT")
]
columns = ["id", "nombre", "departamento"]
df = spark.createDataFrame(data, columns)

# --- Tabla SIN Deletion Vectors (Comportamiento Predeterminado) ---
print("Creando tabla SIN Deletion Vectors...")
df.coalesce(1).write.format("delta").mode("overwrite").saveAsTable("tabla_sin_dv")

# --- Tabla CON Deletion Vectors ---
print("Creando tabla CON Deletion Vectors...")
df.coalesce(1).write.format("delta").mode("overwrite") \
  .option("overwriteSchema", "true") \
  .option("delta.enableDeletionVectors", "true") \
  .saveAsTable("tabla_con_dv")

Puedes verificar la configuración de cada tabla con:

SHOW TBLPROPERTIES tabla_sin_dv;
SHOW TBLPROPERTIES tabla_con_dv;

📂 Comportamiento SIN Deletion Vectors (Copy-on-Write)

Antes del DELETE, la tabla contiene un único Parquet.

Se puede ver que existe un único fichero parquet y un commit en la carpeta _delta_log. Tras ejecutar:

spark.sql(f"DELETE FROM tabla_sin_dv WHERE id = 3")

Delta:

1. marca el archivo original como remove en _delta_log,

2. genera un archivo Parquet nuevo con 4 filas,

3. registra el add correspondiente.

Ejemplo mínimo del commit JSON:

{
    ...
        "operationMetrics": {
            "numRemovedFiles": "1",
            "numCopiedRows": "4",
            "numDeletionVectorsAdded": "0",
            "numDeletionVectorsRemoved": "0",
            "numAddedChangeFiles": "0",
            "numDeletionVectorsUpdated": "0",
            "numDeletedRows": "1",
            "numAddedFiles": "1",
            ...
        ...
}
{
    "remove": {
        "path": "part-00000-ff53dcfe-e9ee-44c5-ae25-c9e90ba6ff46-c000.snappy.parquet",
        "deletionTimestamp": 1764081601227,
        ...
    }
}
{
    "add": {
        "path": "part-00000-3c93366e-b599-49fe-99e0-f2087490b294-c000.snappy.parquet",
        "modificationTime": 1764081601092,
        ...
    }
}

📂 Comportamiento CON Deletion Vectors (Merge-on-Read)

Antes del DELETE, la tabla también tiene un único Parquet.

Se puede ver que también existe un único fichero parquet y un commit en la carpeta _delta_log. Tras ejecutar:

spark.sql(f"DELETE FROM tabla_con_dv WHERE id = 3")

Haciendo el mismo borrado pero para la tabla con Deletion Vectors habilitado, el contenido de la carpeta es el siguiente:

Delta:

1. mantiene el archivo Parquet tal cual,

2. añade un archivo deletion_vector_....bin con la posición invalidada,

3. actualiza el commit indicando el DeletionVector aplicado.

Nuestro nuevo commit contendría lo siguiente, donde se elimina la referencia al archivo Parquet existente y se añade un puntero al mismo archivo Parquet con un vector de eliminación:

{
    ...
        "operationMetrics": {
            ...
            "numRemovedFiles": "0",
            "numCopiedRows": "0",
            "numDeletionVectorsAdded": "1",
            "numDeletionVectorsRemoved": "0",
            "numAddedChangeFiles": "0",
            "numDeletionVectorsUpdated": "0",
            "numDeletedRows": "1",
            "numAddedFiles": "0",
            ...
        },
        ...
}
{
    "add": {
        "path": "part-00000-67be0c96-23bd-48e4-97a1-c0b43f615ad3-c000.snappy.parquet",
        ...
        "deletionVector": {
            "storageType": "u",
            "pathOrInlineDv": "5+[vtVR%EkPn{Xs}UU8<",
            "offset": 1,
            "sizeInBytes": 34,
            "cardinality": 1
        }
    }
}
{
    "remove": {
        "path": "part-00000-67be0c96-23bd-48e4-97a1-c0b43f615ad3-c000.snappy.parquet",
        ...
    }
}

Resumen de los dos comportamientos

📊 Análisis del impacto en rendimiento

Ahora que comprendemos cómo funcionan conceptualmente los vectores de eliminación, veamos el impacto real en el rendimiento.

Para ello, he utilizado un conjunto de datos idéntico de 100 millones de filas en dos tablas Delta diferentes, una con vectores de eliminación habilitados y otra sin. Las pruebas que he realizado para medir el impacto en el rendimiento son:

• Borrado de un registro

• Borrado del 25% de la tabla

• Actualización del 5% de la tabla

• MERGE de un nuevo dataset que contiene 2 millones de filas (2%) en la tabla existente

• SELECT COUNT(1) WHERE

• SELECT SUM()

• OPTIMIZE

• VACUUM

Las operaciones se han hecho en el mismo orden que aparecen en el listado y los resultados han sido los siguientes:

⏱️ Resultados principales

• DELETE (1 fila): La tabla con Deletion Vectors realiza el borrado 6.2x más rápido

• DELETE (25M): La tabla con Deletion Vectors realiza el borrado 3.2x más rápido

• UPDATE (5M): La tabla con Deletion Vectors realiza el update 3.5x más lento

• MERGE (2M): rendimiento similar, ligera penalización con DV

• OPTIMIZE: Deletion Vectors es 208x más rápido

• VACUUM: Deletion Vectors es 1.6x más rápido

• SELECT COUNT(1): DV es 5.9x más lento

• SELECT SUM(price): DV es 1.8x más lento

Esto nos lleva a un punto clave:
el beneficio de DV es enorme en escritura, pero las lecturas pueden penalizarse seriamente.

🔍 ¿Por qué las lecturas son más lentas con Deletion Vectors?

La causa no es el DV en sí, sino el modelo Merge-on-Read, donde el lector debe:

1. Leer los archivos Parquet originales

2. Leer los vectores de eliminación asociados

3. Combinar ambas fuentes

4. Filtrar las filas inválidas

5. Reconstruir el dataset resultante.

Cuantos más deletes/updates acumula una tabla, más trabajo deben hacer los lectores.

📈 El efecto se amplifica si no se ejecuta OPTIMIZE

En las pruebas:

• SELECT COUNT(1) → 5.9x más lento

• SELECT SUM() → 1.8x más lento

Esto se debe a que el motor debe leer más datos de los necesarios, incluyendo registros ya invalidados.

🧹 El remedio: compactación

Después de un:

OPTIMIZE <tabla>

o

REORG TABLE <tabla> APPLY (PURGE)

la tabla queda físicamente limpia y las lecturas vuelven a ser rápidas.

🧭 ¿Cuándo habilitar Deletion Vectors?

✔️ Casos recomendados

1. Capas Bronze y Silver

Ideal cuando:

• hay ingestas frecuentes

• existen deletes/updates parciales

• se realizan merges incrementales

• la prioridad es la velocidad de ingestión.

2. Workloads MoR donde la E/S es el cuello de botella

DV evita reescrituras costosas en Parquet.

3. Cuando hay una estrategia de optimización establecida

Es imprescindible:

• Programar OPTIMIZE o REORG ... APPLY (PURGE)

• Ejecutar VACUUM periódicamente

❌ Casos NO recomendados

1. Tablas con pocas escrituras y muchas lecturas

Ejemplos:

• tablas Gold

• modelos de agregación

• capas analíticas puras

• dashboards con baja latencia

• Power BI Direct Lake

Aquí CoW suele ser más eficiente.

2. Problemas de compatibilidad

DV requiere:

• Delta Lake 2.3+

• Reader version ≥ 3

• Writer version ≥ 7

3. Fabric Copy Data Activity (limitación temporal)

Copy Data ignora Deletion Vectors → pueden reaparecer filas “borradas”.
Esto se resolverá (si no se ha resuelto ya) cuando Fabric actualice el soporte a esta funcionalidad.

💡 Conclusión

Los Deletion Vectors representan una innovación clave en Delta Lake que mejora la eficiencia de las operaciones de escritura y reduce la E/S del sistema de forma drástica. Sin embargo, su adopción implica entender claramente las implicaciones del modelo Merge-on-Read, especialmente en términos de rendimiento de lectura.

En escenarios con cargas frecuentes y actualizaciones parciales —especialmente en capas Bronze y Silver— los DV proporcionan mejoras significativas. En contrapartida, en modelos orientados a lectura intensiva como las capas Gold, puede ser preferible mantener el enfoque tradicional Copy-on-Write o aplicar un mantenimiento regular que elimine los vectores acumulados.

En resumen:

• DV aceleran la escritura

• Penalizan las lecturas si no hay mantenimiento

• Ofrecen el mejor rendimiento total cuando se combinan con OPTIMIZE.

Por suerte, gracias a la librería Semantic-Link-Labs, podemos automatizar esta tarea y actualizar el environment de nuestros notebooks de manera sencilla y programática.

Semantic-Link-Labs nos ofrece varias funciones muy útiles para esta tarea:

• list_notebooks → lista los notebooks dentro de un área de trabajo.

• list_environments → muestra los entornos definidos en el workspace (o en otro que especifiques).

• get_notebook_definition → obtiene la definición completa de un notebook.

• update_notebook_definition → actualiza un notebook con los cambios que necesitemos.

Para la prueba, tengo en un área de trabajo un environment y un notebook asociado a este

Lo primero es instalar la librería en nuestro notebook:

%pip install semantic-link-labs

Obteniendo la definición del notebook

Utilizamos la función get_notebook_definition para ver el contenido del notebook:

import sempy_labs as labs

labs.get_notebook_definition(notebook_name="Notebook 1", format="ipynb")

La salida será un JSON parecido a este:

{
    "cells": [
        {
            "cell_type": "code",
            "source": [
                "# Welcome to your new notebook\\n",
                "# Type here in the cell editor to add code!\\n"
            ],
            "outputs": [],
            "execution_count": null,
            "metadata": {
                "microsoft": {
                    "language": "python",
                    "language_group": "synapse_pyspark"
                }
            },
            "id": "9e2b1999-7e8f-4163-a6cd-33a4fe23ffff"
        }
    ],
    "metadata": {
        "kernel_info": {
            "name": "synapse_pyspark"
        },
        "kernelspec": {
            "name": "synapse_pyspark",
            "display_name": "synapse_pyspark"
        },
        "language_info": {
            "name": "python"
        },
        "microsoft": {
            "language": "python",
            "language_group": "synapse_pyspark",
            "ms_spell_check": {
                "ms_spell_check_language": "en"
            }
        },
        "nteract": {
            "version": "nteract-front-end@1.0.0"
        },
        "spark_compute": {
            "compute_id": "/trident/default",
            "session_options": {
                "conf": {
                    "spark.synapse.nbs.session.timeout": "1200000"
                }
            }
        },
        "dependencies": {
            "environment": {
                "environmentId": "49277563-ad74-49a1-b791-247964afa14a",
                "workspaceId": "69445ea5-e0e6-456d-810b-a291e9b8cae9"
            }
        }
    },
    "nbformat": 4,
    "nbformat_minor": 5
}

La parte que nos interesa está dentro de dependencies, donde se encuentra el environment asignado al notebook.
Si tuvieras un Lakehouse vinculado, también aparecería aquí.

Eliminando el environment

Si lo que queremos es cambiar el environment al predeterminado, basta con eliminar la referencia actual:

import sempy_labs as labs
import json

notebook_name = "Notebook 1"

definition = labs.get_notebook_definition(notebook_name=notebook_name, format="ipynb")
definition = json.loads(definition)

if (
    "metadata" in definition and
    "dependencies" in definition["metadata"] and
    "environment" in definition["metadata"]["dependencies"]
):
    print(f"Actualizando notebook: {notebook_name}")
    definition["metadata"]["dependencies"]["environment"] = {}

    updated_definition_str = json.dumps(definition)

    labs.update_notebook_definition(name =notebook_name, notebook_content =updated_definition_str, format="ipynb")

Al abrir el notebook de nuevo, verás que aparece el environment por defecto.

Asignando un nuevo environment

También podemos cambiar el notebook para que apunte a otro environment (incluso en otra área de trabajo):

notebook_name = "Notebook 1"
environment_id = "38d5bb5e-897e-44d7-927c-e902590da88c"
workspace_id = "e42acae6-20f9-4929-a0b8-345b096b0217"

definition = labs.get_notebook_definition(notebook_name=notebook_name, format="ipynb")
definition = json.loads(definition)

if (
    "metadata" in definition and
    "dependencies" in definition["metadata"] and
    "environment" in definition["metadata"]["dependencies"]
):
    print(f"Actualizando notebook: {notebook_name}")

    definition["metadata"]["dependencies"]["environment"] = {"environmentId": environment_id, "workspaceId": workspace_id}
    updated_definition_str = json.dumps(definition)

    labs.update_notebook_definition(name =notebook_name, notebook_content =updated_definition_str, format="ipynb")

Al reabrir el notebook, verás el nuevo environment asignado.

¿Cómo puedo obtener el environmentId?

Con la función list_environments podemos listar fácilmente todos los entornos disponibles:

Si no pasamos ningún parámetro, se buscarán los environments en el área de trabajo actual.
También podemos especificar otro workspace si queremos reutilizar environments definidos en otro lugar.

Automatización para todos los notebooks de un área de trabajo

Si trabajamos en proyectos grandes con decenas o cientos de notebooks, lo ideal es automatizar el proceso. Con este ejemplo, actualizamos en bloque todos los notebooks de un área de trabajo:

notebooks_df = labs.list_notebooks()

for _, row in notebooks_df.iterrows():
    notebook_id = row["Notebook Id"]
    notebook_name = row["Notebook Name"]
    print(f"{notebook_id} - {notebook_name}")

    definition = labs.get_notebook_definition(notebook_name=notebook_name, format="ipynb")
    definition = json.loads(definition)

    if (
        "metadata" in definition and
        "dependencies" in definition["metadata"] and
        "environment" in definition["metadata"]["dependencies"]
    ):
        print(f"Actualizando notebook: {notebook_name}")

        definition["metadata"]["dependencies"]["environment"] = {}
        updated_definition_str = json.dumps(definition)

        labs.update_notebook_definition(
            name =notebook_name,
            notebook_content =updated_definition_str,
            format="ipynb"
        )
    else:
        print("Este notebook no tiene environment definido.")

Y ojo, que responder a eso tiene su miga. Con un montón de workspaces, cada uno con sus cosas (Lakehouses, Warehouses, Modelos Semánticos, Bases de Datos KQL...), saber exactamente qué ocupa cada cosa es un pequeño lío.

Para abordar este desafío, he desarrollado un notebook de PySpark dentro de Microsoft Fabric que nos permite automatizar este proceso, ofreciendo una visión detallada del uso del almacenamiento en OneLake.

El desafío: Ver claro entre tanta cosa

OneLake es la casa de muchos tipos de artefactos de Fabric. Algunos, como las Lakehouses, son como carpetas y archivos que puedes ver y tocar fácilmente. Pero otros, como los Modelos Semánticos o los Warehouses, son un poco más "caja negra"; su tamaño no es solo sumar archivos, sino que Fabric los maneja a su manera.

Ir mirando esto a mano, workspace por workspace, es una locura, y más si tu empresa tiene unos cuantos.

La solución: Un notebook de PySpark al rescate

El notebook aprovecha el poder de PySpark en el entorno de Microsoft Fabric y las capacidades de la librería sempy para interactuar programáticamente con los workspaces y artefactos. El proceso general que sigue el notebook es el siguiente:

• Listar Workspaces: Utiliza sempy.fabric.list_workspaces() para obtener una lista de todos los workspaces a los que el usuario tiene acceso.

• Listar artefactos por workspace: Para cada workspace, emplea sempy.fabric.list_items() para inventariar todos los artefactos.

• Determinar el tipo de artefacto: Identifica el tipo de cada artefacto (Lakehouse, Warehouse, SemanticModel, KQLDatabase, etc.).

• Calcular el tamaño:

  • Modelos Semánticos: Intenta obtener el tamaño utilizando la función sempy_labs.get_semantic_model_size(). Es importante destacar que el usuario debe disponer de permisos para ejecutar esta función. Si esta función falla o no devuelve un tamaño, se registra un marcador.

  • 

  • Artefactos basados en archivos (Lakehouse, Warehouse, etc.): Para artefactos cuyo almacenamiento es directamente accesible como archivos y carpetas en OneLake (a través de rutas ABFSS), el notebook implementa una función recursiva (get_file_details_recursive). Esta función utiliza notebookutils.fs.ls() para navegar por la estructura de directorios del artefacto y sumar el tamaño de cada archivo individual.

  • Otros tipos de artefactos: Para tipos de artefactos donde el tamaño no se obtiene directamente de los archivos ABFSS (por ejemplo, Report, Notebook, DataPipeline), el script actualmente los omite o permite añadir un marcador de tamaño cero, ya que su "tamaño" en OneLake suele ser despreciable en comparación con los artefactos de datos.

• Almacenar en una tabla delta: Finalmente, el DataFrame se guarda en una tabla Delta dentro de un Lakehouse.

import sempy_labs as labs
import sempy.fabric as fabric
import pandas as pd
from pyspark.sql.types import *
from pyspark.sql.functions import col

def get_file_details_recursive(folder_path):
    """
    Escanea recursivamente una carpeta en OneLake y devuelve una lista con detalles
    (ruta completa ABFSS, tamaño en bytes) de cada archivo encontrado.

    Utiliza mssparkutils.fs.ls para listar el contenido.

    Args:
        folder_path (str): La ruta ABFSS de la carpeta a escanear.
                           Ej: "abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<item_id>/Files/"

    Returns:
        list: Una lista de diccionarios [{'path': str, 'size_bytes': int}],
              o una lista vacía si ocurre un error al listar la carpeta
              o si la carpeta está vacía o no contiene archivos directamente.
              Los errores en subcarpetas se registran pero no detienen el escaneo general.
    """

    file_details_list = []
    try:
        # print(f"DEBUG: Escaneando carpeta: {folder_path}") # Descomentar para depuración detallada
        items = notebookutils.fs.ls(folder_path)

        for item in items:
            # Asegurarse de que la ruta del item es completa (ABFSS)
            item_path_full = item.path
            if not item_path_full.startswith("abfss://"):
                 # Si la ruta no es completa, intentar reconstruirla (puede no ser siempre necesario/correcto)
                 # Esto es una suposición basada en cómo a veces se devuelven las rutas
                 if folder_path.endswith('/'):
                     item_path_full = folder_path + item.name
                 else:
                     item_path_full = folder_path + '/' + item.name

            if not item.isDir:
                # Es un archivo, añadir sus detalles
                file_details_list.append({'path': item_path_full, 'size_bytes': item.size})
            else:
                # Es un directorio, llamar recursivamente si no es la misma carpeta (evitar bucles)
                # Comprobamos la ruta completa normalizada para evitar errores por barras finales
                current_folder_normalized = folder_path.rstrip('/')
                item_folder_normalized = item_path_full.rstrip('/')

                if item_folder_normalized != current_folder_normalized:
                    sub_dir_files = get_file_details_recursive(item_path_full)
                    if sub_dir_files:
                        file_details_list.extend(sub_dir_files)

    except Exception as e:
        # Imprime el error específico de esta carpeta pero permite que el proceso general continúe.
        # No se añadirán archivos de esta ruta específica si falla el 'ls'.
        #print(f"WARN: Error al escanear la carpeta '{folder_path}': {e}. Omitiendo esta ruta.")
        print(f"WARN: Error al escanear la carpeta '{folder_path}'. Omitiendo esta ruta.")
        return [] # Devuelve lista vacía en caso de error en esta carpeta específica

    return file_details_list

# Lista para almacenar los datos de todos los archivos encontrados
all_files_data = []

# Contador para mostrar progreso
processed_workspaces = 0
total_workspaces = 0

print("Iniciando escaneo de workspaces...")

try:
    # Obtener todos los workspaces accesibles
    workspaces_pd = fabric.list_workspaces()
    total_workspaces = len(workspaces_pd)
    print(f"Se encontraron {total_workspaces} áreas de trabajo accesibles.")

    # Iterar sobre cada workspace encontrado
    for ws_index, ws_row in workspaces_pd.iterrows():
        workspace_name = ws_row['Name']
        workspace_id = ws_row['Id']
        processed_workspaces += 1
        print(f"\n[{processed_workspaces}/{total_workspaces}] 📂 Procesando Workspace: '{workspace_name}' (ID: {workspace_id})")

        try:
            # Listar todos los artefactos (items) dentro del workspace actual
            items_pd = fabric.list_items(workspace=workspace_id)
            print(f"  -> Se encontraron {len(items_pd)} artefactos escaneables en '{workspace_name}'.")

            # Iterar sobre cada artefacto del workspace
            for item_index, item_row in items_pd.iterrows():
                artifact_type = item_row['Type']
                artifact_name = item_row['Display Name']
                artifact_id = item_row['Id']

                # Construir la ruta raíz ABFSS para el artefacto
                # Nota: La estructura interna puede variar. Generalmente '/Files' o '/Tables' son puntos de entrada comunes.
                #       Probamos escanear desde la raíz del artefacto.
                artifact_root_path = f"abfss://{workspace_id}@onelake.dfs.fabric.microsoft.com/{artifact_id}"

                print(f"    -> 🔍 Escaneando artefacto: '{artifact_name}' (Tipo: {artifact_type}, ID: {artifact_id})")

                # Inicializar la lista de archivos para ESTE artefacto en CADA iteración
                files_in_artifact = []

                # Variable para almacenar el tamaño si se obtiene de forma especial (p.ej. Semantic Model)
                special_size_bytes = -1 # Usar -1 como indicador inicial (no determinado/error)

                try:
                    # Obtener la lista de archivos y sus tamaños recursivamente
                    if artifact_type == 'SemanticModel':
                        print(f"      -> Intentando obtener tamaño para Semantic Model '{artifact_name}'...")
                        size = labs.get_semantic_model_size(artifact_id, workspace_id)
                        if size is not None:
                            special_size_bytes = int(size)

                        print(f"      => Tamaño obtenido de sempy_labs: {special_size_bytes} bytes.")

                        all_files_data.append({
                                "WorkspaceID": workspace_id, 
                                "WorkspaceName": workspace_name,
                                "ArtifactType": artifact_type, 
                                "ArtifactName": artifact_name, 
                                "ArtifactID": artifact_id,
                                "ScannedRootPath": artifact_root_path,
                                "FilePath": f"{artifact_root_path}",
                                "SizeBytes": special_size_bytes,
                                "SizeMB": float(special_size_bytes / (1024 * 1024)) if special_size_bytes > 0 else 0.0
                        })
                    else:
                        files_in_artifact = get_file_details_recursive(artifact_root_path + "/") # Añadir '/' por si acaso es necesario

                    if files_in_artifact and artifact_type != 'SemanticModel':
                        print(f"      => Se encontraron {len(files_in_artifact)} archivos para '{artifact_name}'.")
                        # Procesar y añadir la información de cada archivo a la lista global
                        for file_detail in files_in_artifact:
                            file_size_bytes = int(file_detail['size_bytes'])
                            # Evitar división por cero si el tamaño es 0
                            file_size_mb = float(file_size_bytes / (1024 * 1024)) if file_size_bytes > 0 else 0.0

                            all_files_data.append({
                                "WorkspaceID": workspace_id,
                                "WorkspaceName": workspace_name,
                                "ArtifactType": artifact_type,
                                "ArtifactName": artifact_name,
                                "ArtifactID": artifact_id,
                                "ScannedRootPath": artifact_root_path, # Ruta base desde donde se escaneó
                                "FilePath": file_detail['path'],       # Ruta completa del archivo
                                "SizeBytes": file_size_bytes,
                                "SizeMB": file_size_mb
                            })
                    else:
                        # Si no se encontraron archivos (puede ser normal para ciertos tipos o si está vacío)
                        print(f"      => No se encontraron archivos accesibles vía ABFSS para '{artifact_name}' o está vacío.")

                except Exception as scan_error:
                    # Captura errores durante el escaneo de un artefacto específico
                    print(f"      => ERROR escaneando el artefacto '{artifact_name}' en '{artifact_root_path}'.")
                    #print(f"      => ERROR escaneando el artefacto '{artifact_name}' en '{artifact_root_path}'. Error: {scan_error}")
                    all_files_data.append({
                                "WorkspaceID": workspace_id,
                                "WorkspaceName": workspace_name,
                                "ArtifactType": artifact_type,
                                "ArtifactName": artifact_name,
                                "ArtifactID": artifact_id,
                                "ScannedRootPath": artifact_root_path,
                                "FilePath": "ERROR_SCANNING_ARTIFACT",
                                "SizeBytes": -1, # Indicador de error
                                "SizeMB": -1.0
                            })

        except Exception as item_error:
            # Captura errores al listar los artefactos de un workspace
            print(f"  -> ERROR al listar artefactos para el workspace '{workspace_name}': {item_error}")
            continue # Continuar con el siguiente workspace

except Exception as ws_error:
    print(f"FATAL: Error crítico al obtener la lista de workspaces: {ws_error}")

print(f"\n📊 Escaneo completado. Se recopilaron {len(all_files_data)} registros de archivos.")

Notebook completo: GitHub

Beneficios

Esta tabla es un recurso valioso para:

• Gobernanza del almacenamiento: Identificar qué workspaces, artefactos o incluso qué rutas específicas dentro de un Lakehouse están consumiendo más espacio.

• Mantenimiento y limpieza: Detectar datos obsoletos, innecesariamente grandes o duplicados que podrían ser archivados o eliminados.

• Informes y dashboards: Conectar Power BI directamente a esta tabla Delta para crear visualizaciones interactivas del uso del almacenamiento.

• Automatización: Al ser un notebook, puede programarse su ejecución periódica para tener un seguimiento continuo del crecimiento del almacenamiento.

Consideraciones y Limitaciones

Es importante tener en cuenta algunos aspectos:

• La función get_semantic_model_size puede no devolver el tamaño si el usuario no tiene los permisos suficientes.

• Tamaño lógico vs. físico: Para artefactos como Modelos Semánticos en modo Direct Lake o Warehouses, la suma de los tamaños de los archivos Delta subyacentes accesibles vía ABFSS puede no coincidir exactamente con el tamaño lógico que Fabric gestiona internamente o reporta en otras interfaces. El notebook proporciona el tamaño de lo "visible" y accesible desde Spark a través del sistema de archivos.

• Permisos: La identidad que ejecuta el notebook (el usuario o un Service Principal) necesita los permisos adecuados para listar workspaces, ítems dentro de esos workspaces y, crucialmente, acceder a las rutas ABFSS de los artefactos.

• Rendimiento: En entornos con una cantidad masiva de workspaces, artefactos y archivos, la ejecución del notebook podría llevar un tiempo considerable. Se podrían explorar optimizaciones adicionales si esto se convierte en un problema.

• Tipos de Artefactos: El script se enfoca en artefactos que almacenan volúmenes significativos de datos. Otros tipos, como informes o flujos de datos, generalmente no se escanean por su tamaño de archivo individual.

Referencias

NotebookUtils (former MSSparkUtils) for Fabric - Microsoft Fabric | Microsoft Learn

How much data is being stored in my Fabric OneLake (Lakehouse files and tables) - FourMoo | Microsoft Fabric | Power BI

Lakehouse Folder Size Calculation

Entre estos nuevos 5 orígenes encontramos el conector de Real-Time Weather (origen meteorológico en tiempo real). Este conector nos permite obtener datos meteorológicos de diferentes ubicaciones seleccionando una ciudad específica o coordenadas de latitud y longitud para recibir información meteorológica.

Los datos que se obtienen son de temperatura, humedad y velocidad del viento.

Una vez seleccionado el conector, se debe especificar la localización de la que queremos obtener los datos meteorológicos

Los mayoría de los datos están en formato JSON

Aunque esto sabemos que no es problema con KQL y podemos realizar las transformaciones necesarias en tiempo real para desgranar la información de estas columnas

De esta forma, podemos construir un Dashboard con información meteorológica en tiempo real de nuestra zona de una manera rápida y sencilla :)

Referencias

Fabric March 2025 Feature Summary | Microsoft Fabric Blog | Microsoft Fabric

New Eventstream sources: MQTT, Solace PubSub+, Azure Data Explorer, Weather & Azure Event Grid  | Microsoft Fabric Blog | Microsoft Fabric

Adición de un origen meteorológico en tiempo real a un eventstream - Microsoft Fabric | Microsoft Learn

El código tiene la misma funcionalidad que el anterior, automatizar la creación de las áreas de trabajo y lakehouses necesarios para nuestra arquitectura medallion. Además, también tienes la posibilidad de almacenar los secretos en Azure Key Vault.

La configuración es sencilla. En una celda encontrarás todas las variables necesarias que deberás de configurar con tus valores. En el caso de que azureKeyVault sea True, deberás de establecer valor en las siguientes variables y deberás crear una app registration con permisos de Azure Key Vault para poder almacenar los secretos. Los valores los puedes poner directamente en el código.

La variable medallionInOneWorkspace indica si queremos crear una sola área de trabajo y todos los lakehouses de cada capa en él. En caso contrario, se creará un área de trabajo y lakehouse por capa.

El código lo podéis encontrar en GitHub a través del siguiente enlace:

blogs/Microsoft Fabric/Semantic Link (SemPy)_ Automatiza la creación de tu arquitectura Medallion.ipynb at main · kilianbs/blogs

En proyectos con Microsoft Fabric y siguiendo las buenas prácticas con la famosa arquitectura medallion, lo primero que hacemos es crear las áreas de trabajo y lakehouses de cada capa. El siguiente código realiza estas tareas de forma automática y además, tiene la opción de guardar los secretos en Azure Key Vault.

El código necesita que las siguientes variables estén definidas para que se ejecute con éxito, en caso contrario, aparecerá un mensaje de error comentando la variable que se necesita configurar.

• $tenantId

• $subscriptionId

• $projectName → Nombre que se asignará a las áreas de trabajo

• $layers → Definición de las distintas capas que tendrá nuestro proyecto. Los valores se añadirán al nombre de las áreas de trabajo (projectName_layer)

Las variables tenantId y subscriptionId son necesarias porque de momento la conexión se realiza con usuario y no como service principal.

También existen unas variables que se pueden configurar dependiendo de lo siguiente:

• $medallionInOneWorkspace: por defecto, su valor es false. Esta variable especifica si la arquitectura medallion se crea en distintas áreas de trabajo o en uno solo. Crear todo en una área de trabajo puede tener sentido para pruebas, donde el área de trabajo se llamará con el nombre de la variable $projectName y se crearán tantos lakehouses como capas definidas en la variable $layers

• $azureKeyVault: por defecto, su valor es false. Si quieres almacenar los secretos en Azure Key Vault, debes configurar el valor a true y establecer el nombre del key vault donde se van a almacenar.

La variable $capacityId es “opcional”, si no sabes el id de la capacidad puedes dejarla en blanco y se listarán las capacidades disponibles para que selecciones la deseada

Ejemplo de resultado

Ejecución para crear una arquitectura medallion de 3 capas almacenando los secretos en Azure Key Vault.

Código

######################################################################################################################################
## Asegúrese de que los módulos Az están instalados en su sistema ejecutando 'Install-Module Az'
######################################################################################################################################

$tenantId = "tenantId"
$subscriptionId = "subscriptionId"
$capacityId = ""
$projectName = "projectName"
$layers = @("01_Bronze","02_Silver","03_Gold") # Cambiar nombre de las capas y añadir o quitar según necesidad
$medallionInOneWorkspace = $false
$azureKeyVault = $false
$azureKeyVaultName = "azureKeyVaultName"

if (-not $tenantId) {
    Write-Error "El parámetro 'tenantId' es obligatorio. Por favor, configúralo en el script antes de ejecutarlo."
    exit 1 
}
elseif (-not $subscriptionId){
    Write-Error "El parámetro 'subscriptionId' es obligatorio. Por favor, configúralo en el script antes de ejecutarlo."
    exit 1 
}
elseif (-not $projectName){
    Write-Error "El parámetro 'projectName' es obligatorio. Por favor, configúralo en el script antes de ejecutarlo."
    exit 1 
}
elseif (-not $layers -or $layers.Count -eq 0){
    Write-Error "El parámetro 'layers' es obligatorio y debe contener al menos un elemento."
    exit 1 
}

if($azureKeyVault -and -not $azureKeyVaultName)
{
    Write-Error "Error: Se requiere el parámetro 'azureKeyVaultName' cuando 'azureKeyVault' está habilitado (true). Configure 'azureKeyVaultName' y vuelva a ejecutar el script."
    exit 1
}


# URL base de la api de Microsoft Fabric
$baseFabricUrl = "https://api.fabric.microsoft.com"

# Inicio de sesión en Fabric
Connect-AzAccount -TenantId $tenantId -Subscription $subscriptionId | Out-Null

# Obtenemos el token
$fabricToken = (Get-AzAccessToken -ResourceUrl $baseFabricUrl).Token

# Crear cabeceras para las llamadas a la API
$headerParams = @{'Authorization'="Bearer {0}" -f $fabricToken}
$contentType = @{'Content-Type' = "application/json"}


$seleccionCapacidad = $false
$opcionesCapacidades = @()

if (-not $capacityId) {
    Write-Host "Es necesario especificar el id de la capacidad que se va a utilizar. A continuación se muestran las capacidades disponibles, selecciona cual quieres utilizar:"
    Write-Host ""
    $capacitiesUri = "{0}/v1/capacities" -f $baseFabricUrl
    $capacitiesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $capacitiesUri

    foreach ($capacity in $capacitiesList.value) {
        Write-Host "ID de la capacidad: $($capacity.id)"
        Write-Host "Nombre de la capacidad: $($capacity.displayName)"
        Write-Host "SKU: $($capacity.sku)"
        Write-Host "Region: $($capacity.region)"
        Write-Host "Estado: $($capacity.state)"
        Write-Host ""
        $opcionesCapacidades += $capacity.displayName
    }

    $opcionesCapacidades += "Salir"
    $valorSeleccionado = $null

    while (-not $seleccionCapacidad) {
        # Mostramos las opciones
        Write-Host "Por favor, escribe el nombre de la capacidad que quieres utilizar:"
        $opcionesCapacidades | ForEach-Object { Write-Host "- $_" }

        # Pedimos seleccionar la capacidad
        $valorSeleccionado = Read-Host "Ingrese su elección"

        # Validar la selección
        if ($opcionesCapacidades -contains $valorSeleccionado) {
            if ($valorSeleccionado -eq "Salir") {
                Write-Host "Has decidido finalizar la ejecución. Saliendo..." -ForegroundColor Red
                Exit
            } else {
                Write-Host "Has seleccionado: $valorSeleccionado" -ForegroundColor Green
                foreach ($capacity in $capacitiesList.value){
                    if($capacity.displayName -eq $valorSeleccionado){
                        $capacityId = $capacity.id
                        Write-Host "El ID de la capacidad seleccionada es: $($capacity.id)" -ForegroundColor Green
                    }
                }
                $seleccionCapacidad = $true

            }
        } else {
            Write-Host "Selección no válida. Inténtalo de nuevo." -ForegroundColor Yellow
        }
    }

}

Write-Host ""

$workspacesDisponibles = @()
$workspaceId = ""


# Si la variable es true, generamos todo en un área de trabajo
if ($medallionInOneWorkspace)
{
    ######################################################################################################################################
    ## ÁREA DE TRABAJO
    ##
    ## Se comprueba si existe el área de trabajo. Si existe, obtenemos el workspaceId, sino, creamos el área de trabajo
    ## y obtenemos el workspaceId.
    ##
    ######################################################################################################################################

    Write-Host "El script está configurado para crear todo en una área de trabajo"
    Write-Host "Inicializando la creación del área de trabajo..."
    Write-Host ""

    # Listamos las áreas de trabajo
    $workspacesUri = "{0}/v1/workspaces" -f $baseFabricUrl
    $workspacesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $workspacesUri
    foreach ($workspace in $workspacesList.value) 
    {
        $workspacesDisponibles += $workspace.displayName
    }

    if ($workspacesDisponibles -contains $projectName)
    {
        Write-Host "El workspace $($projectName) ya existe. Se crearán los objetos sobre esta área de trabajo."
        foreach ($workspace in $workspacesList.value) 
        {
            if($workspace.displayName -eq $projectName)
            {
                $workspaceId = $workspace.id
                Write-Host "Workspace Name: $($workspace.displayName)" -ForegroundColor Cyan
                Write-Host "Workspace ID: $($workspace.id)" -ForegroundColor Cyan
                Write-Host "Capacity ID: $($workspace.capacityId)" -ForegroundColor Cyan
                Write-Host ""
            }
        }

        if($azureKeyVault)
        {
            # Establecer los valores de los secretos del Workspace al KeyVault
            $body = @{
                "value" = $workspace.id
            } | ConvertTo-Json -Depth 1

            try{
                #Invoke-RestMethod -Headers $headerParams -Method Put -Uri "$($vaultUri)/secrets/fabric-workspace-id" -Body $body
                $secureStringValue = ConvertTo-SecureString -String $workspaceId -AsPlainText -Force
                Set-AzKeyVaultSecret -VaultName $azureKeyVaultName -Name "$($projectName)-workspace-id".ToLower().Replace("_", "-") -SecretValue $secureStringValue
            }
            catch {
                Write-Host "Error al establecer el valor del secreto: $($_.Exception.Message)" -ForegroundColor Red
                exit 1 
            }
        }        
    }
    else
    {
        Write-Host "Creando área de trabajo $($projectName)..."
        $body = @{
            "displayName" = $projectName;
            "capacityId" = $capacityId
        } | ConvertTo-Json -Depth 10

        try {
            $response = Invoke-RestMethod -Headers $headerParams -Method POST -Uri $workspacesUri -Body $body -ContentType "application/json"
            Write-Host "Área de trabajo creada con éxito:" -ForegroundColor Green
            Write-Host "ID del área de trabajo: $($response.id)" -ForegroundColor Green
            Write-Host ""
            $workspaceId = $response.id

            if($azureKeyVault)
            {
                # Establecer los valores de los secretos del Workspace al KeyVault
                $body = @{
                    "value" = $response.id
                } | ConvertTo-Json -Depth 1

                try{
                    #Invoke-RestMethod -Headers $headerParams -Method Put -Uri "$($vaultUri)/secrets/fabric-workspace-id" -Body $body
                    $secureStringValue = ConvertTo-SecureString -String $response.id -AsPlainText -Force
                    Set-AzKeyVaultSecret -VaultName $azureKeyVaultName -Name "$($projectName)-workspace-id".ToLower().Replace("_", "-") -SecretValue $secureStringValue
                }
                catch {
                    Write-Host "Error al establecer el valor del secreto: $($_.Exception.Message)" -ForegroundColor Red
                    exit 1 
                }
            }
        } 
        catch {
            Write-Host "Error al crear el área de trabajo: $($_.Exception.Message)" -ForegroundColor Red
            exit 1 
        }

    }

    ######################################################################################################################################
    ## LAKEHOUSE
    ##
    ## Se crean tantos lakehouse como capas se hayan definido con la nomenclatura (projectName)_(layer)
    ##
    ######################################################################################################################################

    Write-Host "Inicializando la creación de los lakehouses..."
    Write-Host ""

    $lakehousesUri = "{0}/v1/workspaces/{1}/lakehouses" -f $baseFabricUrl, $workspaceId
    $lakehousesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $lakehousesUri
    $lakehousesExistentes = @()

    try {
        $lakehousesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $lakehousesUri
        if (-not $lakehousesList) 
        {
            Write-Host "La API no devolvió ningún lakehouse." -ForegroundColor Yellow
        } 
        else 
        {
            foreach ($lakehouse in $lakehousesList.value) {
                $lakehousesExistentes += $lakehouse.displayName
            }
        }
    } 
    catch {
        Write-Host "Error al obtener los lakehouses: $($_.Exception.Message)" -ForegroundColor Red
    }

    foreach ($layer in $layers) 
    {
        $lakehouseName = "$projectName`_$layer`_lh"

        if($lakehousesExistentes -notcontains $lakehouseName)
        {
            Write-Host "Creando lakehouse $($lakehouseName)..."
            $body = @{
                "displayName" = $lakehouseName
            } | ConvertTo-Json -Depth 10

            try {
                $response = Invoke-RestMethod -Headers $headerParams -Method POST -Uri $lakehousesUri -Body $body -ContentType "application/json"
                Write-Host "Lakehouse $($lakehouseName) creado con éxito:" -ForegroundColor Green
                Write-Host "ID del lakehouse: $($response.id)" -ForegroundColor Green

                if($azureKeyVault)
                {
                    $body = @{
                        "value" = $response.id
                    } | ConvertTo-Json -Depth 1

                    try{
                        $secureStringValue = ConvertTo-SecureString -String $response.id -AsPlainText -Force
                        Set-AzKeyVaultSecret -VaultName $azureKeyVaultName -Name "$projectName-$layer-lh-id".ToLower().Replace("_", "-") -SecretValue $secureStringValue
                    }
                    catch {
                        Write-Host "Error al establecer el valor del secreto: $($_.Exception.Message)" -ForegroundColor Red
                        exit 1 
                    }
                }
            } 
            catch {
                Write-Host "Error al crear el lakehouse: $($_.Exception.Message)" -ForegroundColor Red
            }
        }
        else{
            Write-Host "El lakehouse $($lakehouseName) ya existe." -ForegroundColor Yellow
        }
        Write-Host ""
    }

}
# Si la variable es false, generamos cada capa en un área de trabajo distinta
else
{
    ######################################################################################################################################
    ## ÁREA DE TRABAJO
    ##
    ## Se comprueba si existe el área de trabajo. Si existe, obtenemos el workspaceId, sino, creamos el área de trabajo
    ## y obtenemos el workspaceId.
    ##
    ######################################################################################################################################

    Write-Host "El script está configurado para crear un área de trabajo para cada capa"
    Write-Host "Inicializando la creación del área de trabajo..."
    Write-Host ""

    # Listamos las áreas de trabajo
    $workspacesUri = "{0}/v1/workspaces" -f $baseFabricUrl
    $workspacesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $workspacesUri
    foreach ($workspace in $workspacesList.value) 
    {
        $workspacesDisponibles += $workspace.displayName
    }

    foreach ($layer in $layers) {
        $WorkspaceName = "$projectName`_$layer"

        if ($workspacesDisponibles -contains $WorkspaceName) {
            Write-Host "El workspace $($WorkspaceName) ya existe. Se crearán los objetos sobre esta área de trabajo."
            foreach ($workspace in $workspacesList.value) 
            {
                if($workspace.displayName -eq $WorkspaceName)
                {
                    $workspaceId = $workspace.id
                    Write-Host "Workspace Name: $($workspace.displayName)" -ForegroundColor Cyan
                    Write-Host "Workspace ID: $($workspace.id)" -ForegroundColor Cyan
                    Write-Host "Capacity ID: $($workspace.capacityId)" -ForegroundColor Cyan
                    Write-Host ""
                }
            }

            if($azureKeyVault)
            {
                # Establecer los valores de los secretos del Workspace al KeyVault
                $body = @{
                    "value" = $workspace.id
                } | ConvertTo-Json -Depth 1

                try{
                    $secureStringValue = ConvertTo-SecureString -String $workspaceId -AsPlainText -Force
                    Set-AzKeyVaultSecret -VaultName $azureKeyVaultName -Name "$($projectName)-$($layer)-workspace-id".ToLower().Replace("_", "-") -SecretValue $secureStringValue
                }
                catch {
                    Write-Host "Error al establecer el valor del secreto: $($_.Exception.Message)" -ForegroundColor Red
                    exit 1 
                }
            }
        } else {
            Write-Host "Creando área de trabajo $($WorkspaceName)..."
            $body = @{
                "displayName" = $WorkspaceName;
                "capacityId" = $capacityId
            } | ConvertTo-Json -Depth 10

            try {
                $response = Invoke-RestMethod -Headers $headerParams -Method POST -Uri $workspacesUri -Body $body -ContentType "application/json"
                Write-Host "Área de trabajo creada con éxito:" -ForegroundColor Green
                Write-Host "ID del área de trabajo: $($response.id)" -ForegroundColor Green
                Write-Host ""
                $workspaceId = $response.id

                if($azureKeyVault)
                {
                    # Establecer los valores de los secretos del Workspace al KeyVault
                    $body = @{
                        "value" = $response.id
                    } | ConvertTo-Json -Depth 1

                    try{
                        #Invoke-RestMethod -Headers $headerParams -Method Put -Uri "$($vaultUri)/secrets/fabric-workspace-id" -Body $body
                        $secureStringValue = ConvertTo-SecureString -String $response.id -AsPlainText -Force
                        Set-AzKeyVaultSecret -VaultName $azureKeyVaultName -Name "$($projectName)-$($layer)-workspace-id".ToLower().Replace("_", "-") -SecretValue $secureStringValue
                    }
                    catch {
                        Write-Host "Error al establecer el valor del secreto: $($_.Exception.Message)" -ForegroundColor Red
                        exit 1 
                    }
                }
            } 
            catch {
                Write-Host "Error al crear el área de trabajo: $($_.Exception.Message)" -ForegroundColor Red
                exit 1 
            }
        }


        ######################################################################################################################################
        ## LAKEHOUSE
        ##
        ## Se crea el lakehouse correspondiente de la capa
        ##
        ######################################################################################################################################

        Write-Host "Inicializando la creación del lakehouse..."
        Write-Host ""

        $lakehousesUri = "{0}/v1/workspaces/{1}/lakehouses" -f $baseFabricUrl, $workspaceId
        $lakehousesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $lakehousesUri
        $lakehousesExistentes = @()

        try {
            $lakehousesList = Invoke-RestMethod -Headers $headerParams -ContentType $contentType -Method GET -Uri $lakehousesUri
            if (-not $lakehousesList) 
            {
                Write-Host "La API no devolvió ningún lakehouse." -ForegroundColor Yellow
            } 
            else 
            {
                foreach ($lakehouse in $lakehousesList.value) {
                    $lakehousesExistentes += $lakehouse.displayName
                }
            }
        } 
        catch {
            Write-Host "Error al obtener los lakehouses: $($_.Exception.Message)" -ForegroundColor Red
        }


        $lakehouseName = "$projectName`_$layer`_lh"
        if($lakehousesExistentes -notcontains $lakehouseName)
        {
            Write-Host "Creando lakehouse $($lakehouseName)..."
            $body = @{
                "displayName" = $lakehouseName
            } | ConvertTo-Json -Depth 10

            try {
                $response = Invoke-RestMethod -Headers $headerParams -Method POST -Uri $lakehousesUri -Body $body -ContentType "application/json"
                Write-Host "Lakehouse $($lakehouseName) creado con éxito:" -ForegroundColor Green
                Write-Host "ID del lakehouse: $($response.id)" -ForegroundColor Green

                if($azureKeyVault)
                {
                    $body = @{
                        "value" = $response.id
                    } | ConvertTo-Json -Depth 1

                    try{
                        $secureStringValue = ConvertTo-SecureString -String $response.id -AsPlainText -Force
                        Set-AzKeyVaultSecret -VaultName $azureKeyVaultName -Name "$($projectName)-$($layer)-lh-id".ToLower().Replace("_", "-") -SecretValue $secureStringValue
                    }
                    catch {
                        Write-Host "Error al establecer el valor del secreto: $($_.Exception.Message)" -ForegroundColor Red
                        exit 1 
                    }
                }
            } 
            catch {
                Write-Host "Error al crear el lakehouse: $($_.Exception.Message)" -ForegroundColor Red
            }
        }
        else{
            Write-Host "El lakehouse $($lakehouseName) ya existe." -ForegroundColor Yellow
        }
        Write-Host ""


    }
}

spark.sparkContext.getConf().getAll()

• spark.sparkContext accede al contexto de Spark de tu sesión

• getConf() devuelve las configuraciones de Spark

• getAll() devuelve una lista clave-valor con todas las configuraciones actuales de la sesión, incluyendo aquellas configuraciones por defecto y las que se hayan sobrescrito.

Para obtener un valor específico:

spark.conf.get("spark.driver.cores")

Con este comando también podemos acceder configuraciones internas de Microsoft Fabric. Para ello, se utiliza el parámetro trident.

spark.conf.get("trident.tenant.id")

trident: Es un valor que representa una característica, servicio, o contexto específico en el que estás trabajando.
En entornos de Microsoft Fabric, "Trident" es un nombre en clave interno usado para referirse a ciertas funcionalidades de integración y configuración en Fabric, especialmente cuando se interactúa con servicios como OneLake, Key Vault, o Azure Active Directory.

import sempy.fabric as fabric

default_lakehouse_id    = 'No default lakehouse' if spark.conf.get("trident.lakehouse.id") == '' else spark.conf.get("trident.lakehouse.id")
default_lakehouse_name  = 'No default lakehouse' if spark.conf.get("trident.lakehouse.name") == '' else spark.conf.get("trident.lakehouse.name")
notebook_item_id        = spark.conf.get("trident.artifact.id")
notebook_item_name      = fabric.resolve_item_name(notebook_item_id)
pool_executor_cores     = spark.sparkContext.getConf().get("spark.executor.cores")
pool_executor_memory    = spark.sparkContext.getConf().get("spark.executor.memory")
pool_min_executors      = spark.sparkContext.getConf().get("spark.dynamicAllocation.minExecutors")
pool_max_executors      = spark.sparkContext.getConf().get("spark.dynamicAllocation.maxExecutors")
pool_number_of_nodes    = len(str(sc._jsc.sc().getExecutorMemoryStatus().keys()).replace("Set(","").replace(")","").split(", "))
spark_app_name          = spark.conf.get("spark.app.name")
workspace_id            = spark.conf.get("trident.workspace.id")
workspace_name          = fabric.resolve_workspace_name(workspace_id)

print(f'default_lakehouse_id:   {default_lakehouse_id}')
print(f'default_lakehouse_name: {default_lakehouse_name}')
print(f'notebook_item_id:       {notebook_item_id}')
print(f'notebook_item_name:     {notebook_item_name}')
print(f'spark_app_name:         {spark_app_name}')
print(f'pool_executor_cores:    {pool_executor_cores}')
print(f'pool_executor_memory:   {pool_executor_memory}')
print(f'pool_min_executors:     {pool_min_executors}')
print(f'pool_max_executors:     {pool_max_executors}')
print(f'pool_number_of_nodes:   {pool_number_of_nodes}')
print(f'workspace_id:           {workspace_id}')
print(f'workspace_name:         {workspace_name}')

Puedes cambiar el valor de la configuración de la sesión de Spark utilizando el método spark.conf.set. Este método permite establecer configuraciones específicas para tu sesión actual de Spark

spark.conf.set("<spark.conf.name>", value)

Azure Key Vault

Una de las buenas prácticas es almacenar los ids o datos sensibles en Azure Key Vault y acceder a ellos mediante notebook. A continuación os muestro un ejemplo:

En Azure tengo un Key Vault con la siguiente información

Para obtener el valor del secreto en un notebook utilizaremos NotebookUtils

notebookutils.credentials.getSecret('https://<name>.vault.azure.net/', 'secret name')

Como se puede ver, al acceder a un secreto aparece el valor [REDACTED]. Esto se debe a que, por razones de seguridad, Microsoft Fabric oculta automáticamente los valores de los secretos en las salidas de los notebooks para evitar exposiciones accidentales.

Aunque no se pueda ver el valor del secreto, si que podemos utilizarlo: