Acelera las consultas sobre un acceso directo en tu Eventhouse

Acelera las consultas sobre un acceso directo en tu Eventhouse

Este mes de Noviembre viene cargado de novedades en Microsoft Fabric. Hoy voy a comentar una característica sobre la parte de Real-Time Intelligence que me parece muy interesante, la aceleración de consultas.

Como ya comenté en el artículo anterior, en el Eventhouse podemos crear accesos directos y consultarlos mediante la función external_table().

El artículo al que hago referencia lo podéis encontrar aquí. Eventhouse – El destino ideal para los datos en tiempo real – DataGym

Esto permite crear arquitecturas «híbridas» donde para analizar la información en el Eventhouse, nos tenemos que apoyar en datos almacenados en un Lakehouse, Warehouse o donde se encuentre (dentro de los permitidos, claro). Al crear el acceso directo, las consultas no eran optimas, ya que no se aprovechaban del potencial de indexación y de almacenamiento en caché del Eventhouse para mejorar el rendimiento. Ahora, habilitando esta funcionalidad, los datos se indexan y se almacenan en caché automáticamente, lo que permite ejecutar las consultas con un rendimiento hasta 50 veces más rápido.

Para habilitar la aceleración de consultas podemos hacerlo de dos formas: creando un acceso directo nuevo o sobre uno ya creado.

Habilitando la aceleración de consultas en un nuevo acceso directo

Nos posicionamos en nuestro Eventhouse y en la base de datos KQL en la que queremos crear el acceso directo

Seleccionamos el tipo de acceso directo

En mi caso, voy a realizar un acceso directo a una tabla delta de mi lakehouse

Ahora debemos de habilitar la funcionalidad con el siguiente botón

Con esto ya tenemos el acceso directo creado con la aceleración de consultas habilitada.

Habilitando la aceleración de consultas sobre un acceso directo existente

Seleccionamos el acceso directo y desde el menú Manage –> Data policies

Se nos abrirá el menú en la parte derecha para habilitar y configurar el periodo de caché

También se puede clicar con el botón derecho sobre el acceso directo y nos aparecerá la opción de Data policies

Consultando datos

Posicionándonos en Shortcuts, nos aparece una vista con todos los que se encuentran en la base de datos KQL y si utilizan la aceleración de consultas o no. Para la prueba tengo la misma tabla sin y con la aceleración de consultas habilitada.

He realizado dos pruebas que, aunque no son gran cosa, permite comprobar de manera rápida esta funcionalidad.

Primera prueba

He lanzado la consulta para que me devuelva el máximo permitido que son 500mil registros, cuando la tabla tiene más de 200 millones. Los resultados:

  • Sin aceleración de consultas: 18,743 segundos

  • Con aceleración de consultas: 9,794 segundos

Segunda prueba

La consulta realiza un count de la tabla, que son exactamente 211.875.108 registros. Los resultados:

  • Sin aceleración de consultas: 1,150 segundos

Como se puede observar en las estadísticas de la consulta, los datos no utilizan la caché de disco y en el json podemos ver como se descargan en la parte de external_data

{
  "QueryHash": ";;d2d98445e3738cc4",
  "ExecutionTime": 0.9732389,
  "resource_usage": {
    "cache": {
      "shards": {
        "hot": {
          "hitbytes": 0,
          "missbytes": 0,
          "retrievebytes": 0
        },
        "cold": {
          "hitbytes": 0,
          "missbytes": 0,
          "retrievebytes": 0
        },
        "bypassbytes": 0
      }
    },
    "cpu": {
      "user": "00:00:00.1406250",
      "kernel": "00:00:00",
      "total cpu": "00:00:00.1406250",
      "breakdown": {
        "query execution": "00:00:00.1406250",
        "query planning": "00:00:00"
      }
    },
    "memory": {
      "peak_per_node": 2116000
    },
    "network": {
      "inter_cluster_total_bytes": 2668,
      "cross_cluster_total_bytes": 0
    }
  },
  "input_dataset_statistics": {
    "extents": {
      "total": 0,
      "scanned": 0,
      "scanned_min_datetime": "0001-01-01T00:00:00.0000000Z",
      "scanned_max_datetime": "0001-01-01T00:00:00.0000000Z"
    },
    "rows": {
      "total": 0,
      "scanned": 0
    },
    "rowstores": {
      "scanned_rows": 0,
      "scanned_values_size": 0
    },
    "shards": {
      "queries_generic": 8,
      "queries_specialized": 0
    },
    "external_data": {
      "downloaded_items": 8,
      "downloaded_bytes": 524288,
      "iterated_artifacts": 8
    }
  },
  "dataset_statistics": [
    {
      "table_row_count": 1,
      "table_size": 8
    }
  ],
  "cross_cluster_resource_usage": {}
}
  • Con aceleración de consultas: 0,101 segundos

En este caso, se puede ver como se utiliza la caché y en el json podemos observar como en el uso de recursos (resource_usage), se utiliza la caché hot

{
  "QueryHash": ";;d2d98445e3738cc4",
  "ExecutionTime": 0,
  "resource_usage": {
    "cache": {
      "shards": {
        "hot": {
          "hitbytes": 3117,
          "missbytes": 0,
          "retrievebytes": 0
        },
        "cold": {
          "hitbytes": 0,
          "missbytes": 0,
          "retrievebytes": 0
        },
        "bypassbytes": 0
      }
    },
    "cpu": {
      "user": "00:00:00",
      "kernel": "00:00:00",
      "total cpu": "00:00:00",
      "breakdown": {
        "query execution": "00:00:00",
        "query planning": "00:00:00"
      }
    },
    "memory": {
      "peak_per_node": 2627808
    },
    "network": {
      "inter_cluster_total_bytes": 7834,
      "cross_cluster_total_bytes": 0
    }
  },
  "input_dataset_statistics": {
    "extents": {
      "total": 3,
      "scanned": 3,
      "scanned_min_datetime": "2024-11-21T20:10:08.1377326Z",
      "scanned_max_datetime": "2024-11-21T20:10:08.1377326Z"
    },
    "rows": {
      "total": 24,
      "scanned": 24
    },
    "rowstores": {
      "scanned_rows": 0,
      "scanned_values_size": 0
    },
    "shards": {
      "queries_generic": 0,
      "queries_specialized": 0
    }
  },
  "dataset_statistics": [
    {
      "table_row_count": 1,
      "table_size": 9
    }
  ],
  "cross_cluster_resource_usage": {}
}

Aunque las pruebas son de lo más sencillas, se puede ver como con la aceleración de consultas habilitada reduce los tiempos significativamente.

Consideraciones y limitaciones

Al habilitar esta funcionalidad, la facturación es igual que la de los datos en caché del Eventhouse, considerando que el almacenamiento es OneLake Premium. Por eso es importante establecer el periodo de caché cuando se habilita la aceleración de consultas. El periodo se establece en días, y aplica a los datos a partir de la modificationTime en el registro delta (más información).

Algunas de las limitaciones más importantes son:

  • En la versión preliminar, si la tabla delta externa tiene particiones, el rendimiento de las consultas puede no ser óptimo.

  • Las características de la tabla delta no cambian. Es decir, no debe cambiar la estructura (columnas), particiones… etc. Si hay que modificar algo, se deshabilita la funcionalidad y, una vez realizado el cambio, se vuelve a habilitar.

  • Los archivos Parquet con un tamaño comprimido superior a 6 GB no se almacenarán en caché.

Documentación

Query acceleration for OneLake shortcuts – overview (preview) – Microsoft Fabric | Microsoft Learn

Query acceleration over OneLake shortcuts (preview) – Microsoft Fabric | Microsoft Learn