Unir y anexar consultas en Power Query: la diferencia que casi nadie usa bien
En cualquier proyecto de Business Intelligence serio, la fase de preparación de datos consume el 80% del tiempo. En el ecosistema de Microsoft, Power Query es el motor que soporta este peso. Sin embargo, observo con frecuencia una confusión técnica persistente: confundir la anexión (append) con la combinación (merge), o lo que es peor, usar combinaciones cuando el modelo en estrella dictaría una estrategia diferente.
Como consultores, nuestro objetivo no es solo que los datos «lleguen» al informe, sino que lo hagan de forma eficiente. Una mala elección entre estas dos operaciones puede degradar el rendimiento del refresco de minutos a horas, o generar errores silenciosos de duplicidad que invalidan cualquier KPI financiero. En este artículo vamos a desglosar cuándo usar cada técnica, cómo auditar los resultados y qué impacto tienen en el plegado de consultas (Query Folding).
Antes de entrar en código, recordad que la limpieza previa es innegociable. Si no habéis gestionado los nulos o los nombres de las columnas, cualquier operación posterior fallará. Para esto, recomiendo revisar la Gestión proactiva de errores en Power Query: el patrón de la tabla de control.
Anexar consultas (Append): Crecimiento vertical
Anexar consiste en apilar tablas. Es la operación clásica cuando recibimos un CSV mensual de ventas y necesitamos consolidarlos en una única tabla de hechos. No buscamos relaciones entre filas, sino aumentar el volumen de registros manteniendo (idealmente) la misma estructura de columnas.
El motor de Power Query utiliza la función Table.Combine para esta tarea. Un error de principiante es pensar que los nombres de las columnas no importan si el orden es el mismo. Error. Power Query es sensible a mayúsculas y minúsculas (case-sensitive). Si en la Tabla A la columna se llama «Importe» y en la Tabla B se llama «importe», el resultado tendrá dos columnas distintas, llenando de nulos los registros correspondientes.
// Ejemplo de anexión de tres tablas de ventas regionales
let
Origen = Table.Combine({Ventas_Norte, Ventas_Sur, Ventas_Este}),
// Es vital homogeneizar tipos de datos antes de este paso
TiposCambiados = Table.TransformColumnTypes(Origen, {{"Fecha", type date}, {"Importe", type number}})
in
TiposCambiadosCuándo evitar la anexión excesiva
He visto proyectos en el sector retail donde se anexan 50 archivos de Excel individuales. Esto es ineficiente. Si los datos están en una carpeta o en un SharePoint, usad el conector de carpeta. Anexar manualmente consultas individuales satura el panel de navegación y dificulta el mantenimiento del linaje de datos. Además, recordad que cada consulta independiente puede disparar una conexión al origen, lo cual podéis monitorizar siguiendo la Guía de Diagnóstico sobre cuánto tarda cada paso en Power Query.
Combinar consultas (Merge): Relaciones horizontales
Combinar es el equivalente al JOIN de SQL. Aquí el objetivo es buscar una correspondencia entre una o varias columnas (claves) para traer información adicional de otra tabla. Es la base para desnormalizar dimensiones o para enriquecer la tabla de hechos antes de cargarla al modelo.
A diferencia de SQL, Power Query realiza esta operación en dos pasos: primero genera una columna de tipo Table (unión anidada) y luego el analista debe expandir o agregar esa columna. Esta distinción es fundamental para el rendimiento.
Tipos de combinaciones y su impacto
| Tipo de Join | Resultado técnico | Uso recomendado |
|---|---|---|
| Left Outer (Externa izquierda) | Todas las de la izquierda y las que coincidan de la derecha. | El estándar para traer atributos de dimensiones a hechos. |
| Inner (Interna) | Solo filas que coincidan en ambas tablas. | Limpieza de datos: eliminar transacciones sin maestro de productos. |
| Left Anti (Anti izquierda) | Filas de la izquierda que NO están en la derecha. | Auditoría: detectar ventas con IDs de cliente inexistentes. |
| Full Outer (Externa completa) | Todas las filas de ambas tablas. | Integración de presupuestos vs realidad si las claves no coinciden. |
El uso de Left Anti Join es una de mis herramientas favoritas en consultoría para depurar datos antes de que lleguen al usuario final. Si el modelo presenta ambigüedades, a menudo el problema nace de una combinación mal resuelta. Consultad más sobre Relaciones y dirección del filtro cruzado para entender cómo afecta esto una vez cargado el modelo.
El peligro de la duplicidad y la granularidad
Este es el punto donde fallan la mayoría de informes. Si realizas un Merge entre una tabla de Ventas y una de Productos, y en la tabla de Productos tienes el mismo ID_Producto duplicado (quizás por un error en el origen o por versiones históricas mal gestionadas), la tabla de Ventas multiplicará sus filas. Si tenías 1.000 ventas, tras el join podrías tener 1.200. Tus totales de ingresos serán erróneos y el error será difícil de detectar si solo miras los dashboards.
Para evitar esto, antes de combinar, aseguraos de que la tabla de la derecha (la que aporta la información) tiene valores únicos en la clave de unión. Podéis usar Table.Distinct o agrupar previamente.
// Asegurar unicidad en la tabla de dimensiones antes del Merge
let
Origen = Excel.Workbook(File.Contents("C:\Maestro.xlsx"), null, true),
Productos_Tabla = Origen{[Item="Productos",Kind="Sheet"]}[Data],
LimpiezaDuplicados = Table.Distinct(Productos_Tabla, {"SKU_ID"})
in
LimpiezaDuplicadosRendimiento y Query Folding
Si vuestros orígenes son bases de datos SQL, Power Query intentará traducir el Merge o el Append a una sentencia SQL nativa. Esto es el Query Folding. Sin embargo, hay acciones que rompen este plegado, obligando a Power Query a descargar millones de filas a la memoria local (o al motor de Mashup en el servicio de Power BI) para hacer la unión manualmente.
Acciones que suelen romper el plegado en combinaciones:
- Combinar tablas de orígenes distintos (SQL vs Excel).
- Usar comparaciones de texto con transformaciones intermedias (ej. combinar tras poner en mayúsculas en el mismo paso).
- Joins basados en columnas calculadas complejas.
Cuando trabajéis con grandes volúmenes en entornos corporativos, es preferible crear una Vista en SQL que ya realice el Join o el Union, en lugar de procesarlo en Power Query. Si no tenéis acceso a la base de datos, tratad de usar tablas de referencia y parámetros para mantener el código limpio y facilitar que el motor optimice las consultas.
Errores frecuentes en proyectos reales
Tras años auditando modelos en los sectores de energía e industria, estos son los errores más repetidos al unir datos:
- Tipos de datos inconsistentes: Intentar combinar una columna de texto «123» con una numérica 123. Power Query no dará error, simplemente no encontrará coincidencias (nulls).
- Espacios en blanco: Claves con espacios al final («ID_01 » vs «ID_01»). Siempre aplicad un Trim (Recortar) antes de una combinación.
- Anexar sin normalizar: Anexar tablas donde una tiene la moneda en EUR y otra en USD sin añadir una columna de conversión o identificador de moneda.
- Uso de Fuzzy Matching sin control: La concordancia aproximada es potente pero peligrosa; puede unir «Juan Pérez» con «Joan Pérez» cuando son personas distintas, arruinando la integridad del dato.
Checklist de validación
- ¿He verificado que los nombres de las columnas coinciden exactamente antes de anexar?
- ¿He eliminado duplicados en la tabla de búsqueda (lado 1) antes de realizar el merge?
- ¿He comprobado el recuento de filas antes y después de la expansión para detectar explosiones de granularidad?
- ¿He verificado si el paso de combinación mantiene el Query Folding (botón derecho sobre el paso)?
- ¿He gestionado los valores nulos resultantes de un Left Join para evitar que afecten a los cálculos DAX posteriores?
Preguntas frecuentes
¿Qué es mejor, combinar en Power Query o crear relaciones en el modelo de Power BI?
Como norma general, si necesitas los datos para filtrar o agrupar, usa relaciones en el modelo (Star Schema). Si necesitas los datos para un cálculo a nivel de fila o para reducir el número de tablas cargadas, haz la combinación en Power Query. Recuerda que cargar tablas excesivamente anchas también tiene un coste en memoria.
¿Por qué mi anexión de consultas genera tantas columnas con nulos?
Esto ocurre porque las tablas que estás anexando tienen nombres de columna diferentes o espacios adicionales. Power Query no intenta adivinar; si una columna se llama «Fecha_Venta» y otra «Fecha Venta», creará dos columnas y pondrá nulos donde no haya coincidencia exacta de nombre.
¿Cuándo debería usar la función de Agregación en lugar de Expansión tras un Merge?
Usa la agregación si solo necesitas un valor resumido de la tabla relacionada (como el total de ventas por cliente o la fecha de la última visita). Esto es mucho más eficiente que expandir todas las filas y luego volver a agrupar en pasos posteriores.
