BigQuery: ahora ya se puede usar la sintaxis SQL con pipes

¿Qué es Pipe Query Syntax?

• Es una extensión de GoogleSQL que permite escribir consultas con una estructura lineal, más fácil de leer y mantener
• Soporta las mismas operaciones que GoogleSQL existente (selección, agrupación, joins, filtrado, etc.)
• Permite definir libremente el orden de las operaciones y escribir consultas complejas sin subconsultas anidadas

Standard SQL vs Pipe Query Syntax

• Standard SQL
  • Debe seguir un orden de sintaxis específico
  • Si se usan múltiples agregaciones, se requieren CTE (Common Table Expression) o subconsultas anidadas
  • Hay que repetir columnas duplicadas en SELECT, GROUP BY y ORDER BY
• Pipe Query Syntax
  • Los operadores pipe se pueden aplicar en cualquier orden
  • Permite hacer múltiples agregaciones de forma simple solo agregando operadores pipe
  • Solo hace falta declarar la columna una vez

Estructura básica de Pipe Query Syntax

• 1. Comienza con la cláusula FROM
• 2. Después de |> (operador pipe), agrega operaciones
• 3. Encadena varios operadores |> para construir la consulta por etapas
     (Ej.: se puede cambiar el orden entre filtrado → agregación → join)
• Características principales
  • Se puede agregar el operador pipe a cualquier consulta → es posible extender una consulta existente de GoogleSQL agregando un operador |> al final
  • El orden de las operaciones es libre → se pueden aplicar operadores en el orden y la cantidad que se desee
  • Se puede usar en todos los entornos compatibles con GoogleSQL → consultas, vistas, funciones con retorno de tabla, etc.
  • Se puede mezclar con la sintaxis SQL existente → las subconsultas pueden escribirse con Standard SQL y la consulta principal con sintaxis pipe
  • Se puede hacer referencia a todos los alias definidos en la etapa anterior
  • Puede comenzar con la cláusula FROM → después se pueden agregar operadores |> para expandir gradualmente la consulta

Diferencias entre Pipe Query Syntax y Standard SQL

• La consulta puede comenzar con la cláusula FROM
• El operador pipe SELECT no realiza agregaciones. Las agregaciones se hacen por separado con el operador pipe AGGREGATE
• El operador pipe WHERE realiza el filtrado. Integra en uno solo el comportamiento de WHERE, HAVING y QUALIFY de Standard SQL. Se puede filtrar en cualquier etapa → permite escribir consultas más flexibles

Ventajas de Pipe Query Syntax

• Permite escribir consultas en un orden lógico → mejora la legibilidad
• Facilita el mantenimiento → permite realizar operaciones complejas sin subconsultas anidadas
• Orden flexible de operaciones → se pueden aplicar en el orden deseado
• El filtrado es más intuitivo → se puede usar WHERE para filtrar datos en distintas etapas
• Permite escribir consultas de agregación complejas con mayor facilidad → usando el operador AGGREGATE para hacer agregaciones de forma clara

Se ofrece con soporte en etapa Pre-GA, por lo que todavía tiene compatibilidad limitada

[carnoxen]

https://github.com/tc39/proposal-pipeline-operator

Es un operador que se ve bastante familiar.

[halfenif]

Después de ver primero prql y luego la sintaxis de canalización de Google, se siente un poco dispersa.

[GN⁺]

Comentarios de Hacker News

• La sintaxis de tuberías de SQL fue implementada en Databricks el 30 de enero de 2025

  • Antes era difícil extender SQL y las funciones de valor de tabla eran complejas
  • Ahora es posible hacer enriquecimiento de datos, predicción, agrupación y más con funciones de orden superior
  • Por ejemplo, se pueden filtrar pedidos posteriores a una fecha específica, agregar el gasto total por cliente, luego filtrar a los clientes por encima de cierto monto y hacer un join con la información del cliente
  • El SQL iterativo usando tuberías podría funcionar mejor junto con GenAI

• PRQL es una idea similar que compila a SQL

  • Por ejemplo, se pueden filtrar datos de facturas, calcular comisiones y luego filtrar los datos cuyos ingresos superen cierta cantidad

• Si la expansión de la sintaxis de SQL continúa, la complejidad podría aumentar

  • Me gustaría que quienes implementan SQL se enfocaran en cosas como source maps para poder dar mejor soporte a sintaxis alternativas externas
  • Eso permitiría que cada proyecto o persona elija la variante de sintaxis SQL que mejor le convenga

• Cuando se anunció por primera vez la sintaxis de tuberías, el equipo de SQLite la probó

  • Descubrieron que el carácter de tubería no era indispensable y que la sintaxis también funciona cuando el carácter de tubería es opcional
  • Personalmente, creo que esta forma se ve mejor

• PRQL es una sintaxis orientada a tuberías para bases de datos SQL, y como es un lenguaje nuevo no tiene compatibilidad retroactiva con SQL

  • No cuenta con el respaldo de una gran empresa como Google, pero su sintaxis es más limpia

• También se puede usar en DuckDB

• Tener que escribir ">" después de la tubería puede resultar molesto

• El lenguaje Malloy no usa sintaxis de tuberías, pero tiene una sintaxis analítica similar

  • Fue desarrollado por Lloyd Tabb, cofundador de Looker

• Desde que usé Kusto Query Language, he esperado que SQL tenga capacidades como estas

  • Si suficientes bases de datos lo soportan como extensión, podría volverse una posibilidad