Partekatu honen bidez:

Recomendaciones de rendimiento de la federación de Lakehouse

En este artículo se proporcionan instrucciones para mejorar el rendimiento de las consultas de federación de Lakehouse.

Combinación de varios predicados mediante el AND operador

Databricks Runtime intenta insertar predicados en el motor de base de datos remoto para reducir el número de registros que se capturan a través de la red. Si no se puede insertar un predicado, la consulta ejecutada en el motor de base de datos remoto excluye el predicado, por lo que el filtrado debe realizarse mediante Databricks Runtime. Sin embargo, si no se puede trasladar una parte determinada del filtro hacia abajo, se puede trasladar otra parte del filtro si están unidos por el operador AND.

Ejemplo 1

Consulta de Databricks:

SELECT * FROM foreign_catalog.schema.table WHERE name ILIKE 'john'

La ILIKE expresión no se puede insertar en la base de datos remota (por ejemplo, MySQL) porque no hay ninguna traducción adecuada. El filtrado debe realizarse mediante Databricks Runtime.

La consulta enviada a la base de datos remota devuelve todos los registros:

SELECT * FROM catalog.schema.table

Ejemplo 2

Consulta de Databricks:

SELECT * FROM foreign_catalog.schema.table WHERE name ILIKE 'john' AND date > '2025-05-01'

La expresión ILIKE no se puede propagar a la base de datos remota (por ejemplo, MySQL) porque no existe una traducción adecuada, pero se puede propagar la comparación de fechas. El filtrado de nombres todavía debe realizarse mediante Databricks Runtime, pero la comparación de fechas debe reducir el número de registros que se capturan.

La consulta enviada a la base de datos remota devuelve un subconjunto de registros:

SELECT * FROM catalog.schema.table WHERE date > '2025-05-01'

Comprobar qué consulta se ejecutará en la base de datos remota

Para ver qué consulta se enviará a la base de datos remota, ejecute el EXPLAIN comando FORMATTED .

Importante

La consulta real puede diferir de la consulta en la EXPLAIN FORMATTED salida debido a la ejecución de consultas adaptables.

Establecer el tamaño de los lotes capturados desde la base de datos remota

Puede configurar los siguientes conectores, que usan el protocolo de transferencia JDBC, para controlar cómo capturan datos de sistemas remotos.

  • Databricks
  • Microsoft SQL Server
  • Microsoft Azure Synapse
  • MySQL (en inglés)
  • Oráculo
  • PostgreSQL
  • Datos de Salesforce 360
  • Teradatos

El tamaño de captura de JDBC determina el número de filas que se van a capturar por recorrido de ida y vuelta. De forma predeterminada, la mayoría de los conectores JDBC capturan datos de forma atómica. Esto puede hacer que la cantidad de datos supere la memoria disponible.

Para evitar errores de memoria insuficiente, establezca el fetchSize parámetro . Cuando fetchSize se establece en un valor distinto de cero, el conector lee los datos en lotes. El número máximo de filas por lote es igual al valor de fetchSize. Databricks recomienda especificar un valor grande fetchSize (por ejemplo, 100,000) porque el tiempo de ejecución general de la consulta puede prolongarse si el número de filas en lotes es demasiado pequeño.

Este parámetro permite que los nodos de trabajo lean los datos en lotes, pero no en paralelo.

Requisitos de proceso:

  • Debe usar el proceso en Databricks Runtime 16.1 o superior. Los almacenes de SQL deben ser Pro o Sin servidor y deben usar 2024.50.
SELECT * FROM mySqlCatalog.schema.table WITH ('fetchSize' 100000)

Configurar el parámetro de tamaño de partición (Snowflake)

Snowflake permite capturar datos en varias particiones, lo que permite la interacción de varios ejecutores y procesamiento paralelo. Es importante elegir un tamaño de partición adecuado estableciendo el partition_size_in_mb parámetro . Este parámetro especifica el tamaño no comprimido recomendado para cada partición. Para reducir el número de particiones, especifique un valor mayor. El valor predeterminado es 100 (MB).

El partition_size_in_mb parámetro establece un tamaño recomendado; el tamaño real de las particiones puede variar.

Requisitos de proceso:

  • Debe usar el proceso en Databricks Runtime 16.1 o superior. Los almacenes de SQL deben ser Pro o Sin servidor y deben usar 2024.50.
SELECT * FROM snowflakeCatalog.schema.table WITH ('partition_size_in_mb' 1000)

Habilitación de lecturas paralelas para conectores JDBC

Los conectores que admiten el protocolo de transferencia JDBC pueden leer datos en paralelo mediante la creación de particiones de la consulta. Puede configurar lecturas paralelas para los siguientes conectores:

  • Databricks
  • Microsoft SQL Server
  • Microsoft Azure Synapse
  • MySQL (en inglés)
  • Oráculo
  • PostgreSQL
  • Redshift
  • Datos de Salesforce 360
  • Teradatos

Esto permite que varios ejecutores capturen datos simultáneamente, lo que mejora significativamente el rendimiento de las tablas grandes.

Para habilitar las lecturas paralelas, especifique los parámetros siguientes:

  • numPartitions: número de particiones que se usarán para paralelismo.
  • partitionColumn: el nombre de una columna numérica utilizada para particionar la consulta.
  • lowerBound: el valor mínimo de partitionColumn usado para decidir el intervalo de partición de partitionColumn.
  • upperBound: el valor máximo de partitionColumn usado para decidir el intervalo de partición.

Importante

Los valores lowerBound y upperBound solo se utilizan para decidir el stride de partición, no para filtrar las filas de la tabla. Todas las filas de la tabla serán particionadas y devueltas.

La columna de partición debe ser:

  • Una columna numérica
  • Distribuido uniformemente a lo largo del rango
  • Una columna indizada para mejorar el rendimiento

Requisitos de proceso:

  • Debe usar los recursos de computación en Databricks Runtime 17.1 o superior. Los almacenes de SQL deben ser pro o sin servidor y deben usar 2025.25.

En el ejemplo siguiente, la consulta se dividirá en 4 particiones paralelas en función de la id columna, con cada partición procesando un intervalo de aproximadamente 250 identificadores (suponiendo que haya un único registro para cada uno id entre 1 y 1000).

SELECT * FROM mySqlCatalog.schema.table WITH (
  'numPartitions' 4,
  'partitionColumn' 'id',
  'lowerBound' 1,
  'upperBound' 1000
)

Integración de uniones en la federación de Lakehouse

Importante

Esta característica está en versión preliminar pública.

Obtenga información sobre cómo funciona el pushdown de uniones en Databricks Lakehouse Federation.

Introducción a la optimización de combinación

La optimización de combinación es una técnica de optimización de consultas en la que Databricks empuja las operaciones de unión al motor de base de datos remoto en lugar de recuperar datos y realizar la combinación localmente. Esto reduce significativamente el tráfico de red y mejora el rendimiento de las consultas aprovechando las funcionalidades de unión integrada de la base de datos remota.

Orígenes de datos compatibles

Los orígenes de datos siguientes admiten la inserción de combinación:

  • Oráculo
  • PostgreSQL
  • MySQL (en inglés)
  • SQL Server
  • Teradatos
  • Redshift
  • Snowflake
  • BigQuery

Esta característica está disponible con carácter general y está habilitada de forma predeterminada para Redshift, Snowflake y BigQuery. Las siguientes limitaciones y requisitos solo se aplican a los conectores Oracle, PostgreSQL, MySQL, SQL Server y Teradata.

Requisitos

  • Debe usar recursos de cómputo en Databricks Runtime 17.2 o superior.
  • Los almacenes de SQL deben ser Pro o Sin servidor y deben usar 2025.30.
  • En la página Vistas previas de la interfaz de usuario de Databricks, debe activar Impulsión de unión para consultas federadas (Versión preliminar pública).

Limitaciones

  • Solo se admiten uniones internas, uniones externas izquierdas y uniones externas derechas.
  • Los alias en los elementos secundarios de una unión solo se admiten en Databricks Runtime, versión 17.3 o posteriores.

Requisitos de jerarquía de nodos

Para que una combinación se inserte hacia abajo, todos los nodos de las ramas secundarias izquierda y derecha también deben ser pushables. Se aplican las reglas siguientes:

  • Nodos secundarios admitidos: Solo las combinaciones, los filtros, la muestra y los nodos de escaneo pueden aparecer debajo de una combinación en el plan de consulta para que la optimización se realice con éxito.
  • Nodos secundarios no admitidos: si las operaciones de límite, desplazamiento o agregado aparecen en la rama izquierda o derecha debajo de una combinación, la combinación no se puede insertar.
  • Operaciones sobre combinaciones: Las operaciones de agregado, límite y desplazamiento se pueden desplazar hacia abajo cuando se aplican encima de una combinación.

Examples

-- Supported: Join two table scans
SELECT *
FROM table1
INNER JOIN table2
ON col_from_table1 = col_from_table2 + 1

-- Supported: Join two table scans with a nested select query
SELECT *
FROM (SELECT a FROM table1) q1
INNER JOIN (SELECT a FROM table2) q2
ON q1.a = q2.a + 1

-- Supported: Child subqueries with aliases in projection (:re[DBR] 17.3+)
SELECT *
FROM (SELECT a AS a1 FROM table1) t1
INNER JOIN (SELECT a AS a2 FROM table2) t2
ON t1.a1 = t2.a2 + 1

-- Supported: Join with filters below
SELECT *
FROM (SELECT * FROM table1 WHERE a > 10) t1
INNER JOIN (SELECT * FROM table2 WHERE b < 20) t2
ON t1.id = t2.id

-- Supported: Aggregate on top of join
SELECT COUNT(*)
FROM table1 t1
INNER JOIN table2 t2
ON t1.id = t2.id

-- Not supported: Join on top of aggregate
SELECT *
FROM (SELECT id, COUNT(*) as cnt FROM table1 GROUP BY id) t1
INNER JOIN table2 t2
ON t1.id = t2.id

-- Not supported: Join on top of limit
SELECT *
FROM (SELECT * FROM table1 LIMIT 100) t1
INNER JOIN table2 t2
ON t1.id = t2.id

Observability

Use EXPLAIN FORMATTED para comprobar que su unión está siendo optimizada:

EXPLAIN FORMATTED
SELECT *
FROM foreign_catalog.schema.table1 t1
INNER JOIN foreign_catalog.schema.table2 t2
ON t1.id = t2.id

Salida de ejemplo que muestra la optimización de combinación exitosa:

== Physical Plan ==
*(1) Scan JDBCRelation
PushedFilters: [id = id_1],
PushedJoins:
   [L]: Relation: foreign_catalog.schema.table1
        PushedFilters: [ID IS NOT NULL]
   [R]: Relation: foreign_catalog.schema.table2
        PushedFilters: [ID IS NOT NULL]

En esta salida:

  • id_1 es un alias que Databricks genera automáticamente para resolver la ambigüedad cuando las columnas tienen nombres duplicados.
  • Lo PushedFilters de arriba PushedJoins representa las condiciones de unión reales que se transmiten a la base de datos remota.
  • El PushedFilters en cada relación ([L] y [R]) indica predicados de filtro adicionales aplicados a cada tabla.
  • Last updated on