Guía de traducción de SQL de Snowflake

En este documento, se detallan las similitudes y diferencias que existen en la sintaxis de SQL entre Snowflake y BigQuery para ayudar a acelerar la planificación y ejecución de la transferencia de tu EDW (almacén de datos empresariales) a BigQuery. El almacenamiento de datos de Snowflake está diseñado para funcionar con la sintaxis de SQL específica de Snowflake. Es posible que las secuencias de comandos escritas para Snowflake necesiten modificarse antes de que puedas usarlas en BigQuery, ya que los dialectos de SQL varían según los servicios. Usa la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL de forma masiva o la traducción de SQL interactiva a fin de traducir consultas ad hoc. Snowflake SQL es compatible con ambas herramientas en la vista previa.

Nota: En algunos casos, no hay una asignación directa entre un elemento de SQL en Snowflake y en BigQuery. Sin embargo, en la mayoría de los casos, puedes obtener la misma funcionalidad en BigQuery que en Snowflake mediante un medio alternativo, como se muestra en los ejemplos de este documento.

Tipos de datos

En esta sección, se muestran los equivalentes entre los tipos de datos en Snowflake y en BigQuery.

Snowflake	BigQuery	Notas
NUMBER/ DECIMAL/NUMERIC	NUMERIC	El tipo de datos NUMBER en Snowflake admite 38 dígitos de precisión y 37 dígitos de escala. La precisión y el escalamiento se pueden especificar según el usuario. BigQuery admite NUMERIC y BIGNUMERIC con precisión y escala especificadas de forma opcional dentro de ciertos límites.
INT/INTEGER	BIGNUMERIC	INT/INTEGER y todos los demás tipos de datos similares a INT, como BIGINT, TINYINT, SMALLINT, BYTEINT, representan un alias para el tipo de datos NUMBER en el que no se pueden especificar la precisión y el escalamiento, y siempre es NUMBER(38, 0).
BIGINT	BIGNUMERIC
SMALLINT	BIGNUMERIC
TINYINT	BIGNUMERIC
BYTEINT	BIGNUMERIC
FLOAT/ FLOAT4/ FLOAT8	FLOAT64	El tipo de datos FLOAT en Snowflake establece “NaN” como > X, en el que X es cualquier valor FLOAT (que no sea “NaN”). El tipo de datos FLOAT en BigQuery establece “NaN” como < X, en el que X es cualquier valor FLOAT (distinto de “NaN” en sí).
DOUBLE/ DOUBLE PRECISION/ REAL	FLOAT64	El tipo de datos DOUBLE en Snowflake es sinónimo del tipo de datos FLOAT en Snowflake, pero suele mostrarse de forma incorrecta como FLOAT. Se almacena correctamente como DOUBLE.
VARCHAR	STRING	El tipo de datos VARCHAR en Snowflake tiene una longitud máxima de 16 MB (sin comprimir). Si no se especifica la longitud, el valor predeterminado es la longitud máxima. El tipo de datos STRING en BigQuery se almacena como Unicode codificado en UTF-8 de longitud variable. La longitud máxima es de 16,000 caracteres.
CHAR/CHARACTER	STRING	El tipo de datos CHAR en Snowflake tiene una longitud máxima de 1.
STRING/TEXT	STRING	El tipo de datos STRING en Snowflake es sinónimo de VARCHAR de Snowflake.
BINARY	BYTES
VARBINARY	BYTES
BOOLEAN	BOOL	El tipo de datos BOOL en BigQuery solo puede aceptar TRUE/FALSE, a diferencia del tipo de datos BOOL en Snowflake, que puede aceptar TRUE/FALSE/NULL.
DATE	DATE	El tipo DATE en Snowflake acepta los formatos de fecha más comunes, a diferencia del tipo DATE en BigQuery, que solo acepta fechas en el formato “AAAA-[M]M-[D]D”.
TIME	TIME	El tipo TIME en Snowflake admite entre 0 y 9 nanosegundos de precisión, mientras que el tipo TIME en BigQuery admite entre 0 y 6 nanosegundos de precisión.
TIMESTAMP	DATETIME	TIMESTAMP es un alias configurable por el usuario que se establece de forma predeterminada como TIMESTAMP_NTZ, que se asigna a DATETIME en BigQuery.
TIMESTAMP_LTZ	TIMESTAMP
TIMESTAMP_NTZ/DATETIME	DATETIME
TIMESTAMP_TZ	TIMESTAMP
OBJECT	JSON	El tipo OBJECT en Snowflake no admite valores de tipo explícito. Los valores son del tipo VARIANT.
VARIANT	JSON	El tipo OBJECT en Snowflake no admite valores de tipo explícito. Los valores son del tipo VARIANT.
ARRAY	ARRAY<JSON>	El tipo ARRAY en Snowflake solo puede admitir tipos VARIANT, mientras que el tipo ARRAY en BigQuery puede admitir todos los tipos de datos, excepto un array.

BigQuery también tiene los siguientes tipos de datos que no tienen un análogo de Snowflake directo:

• DATETIME
• GEOGRAPHY

Sintaxis de consulta y operadores de consulta

En esta sección, se abordan las diferencias que existen en la sintaxis de consultas en Snowflake y en BigQuery.

Declaración SELECT

La mayoría de las declaraciones SELECT de Snowflake son compatibles con BigQuery. En la siguiente tabla, se incluye una lista de diferencias menores.

Snowflake		BigQuery
SELECT TOP ... FROM table		SELECT expression FROM table ORDER BY expression DESC LIMIT number
SELECT x/total AS probability, ROUND(100 * probability, 1) AS pct FROM raw_data Nota: Snowflake admite la creación y referencia de un alias en la misma declaración SELECT.		SELECT x/total AS probability, ROUND(100 * (x/total), 1) AS pct FROM raw_data
SELECT * FROM ( VALUES (1), (2), (3) )		SELECT AS VALUE STRUCT(1, 2, 3)

Los identificadores y alias de Snowflake no distinguen entre mayúsculas y minúsculas de forma predeterminada. Para conservar las mayúsculas, escribe identificadores y alias con comillas dobles (“”).

BigQuery admite las siguientes expresiones en declaraciones SELECT, que no tienen un equivalente de Snowflake:

• EXCEPT
• REPLACE

Cláusula FROM

La cláusula FROM en una consulta especifica las tablas, vistas, subconsultas o funciones de tabla posibles que se usarán en una declaración SELECT. BigQuery admite todas estas referencias de tabla.

En la siguiente tabla, se incluye una lista de diferencias menores.

Snowflake		BigQuery
SELECT $1, $2 FROM (VALUES (1, 'one'), (2, 'two'));		WITH table1 AS ( SELECT STRUCT(1 as number, 'one' as spelling) UNION ALL SELECT STRUCT(2 as number, 'two' as spelling) ) SELECT * FROM table1
SELECT* FROM table SAMPLE(10)		SELECT* FROM table TABLESAMPLE BERNOULLI (0.1 PERCENT)
SELECT * FROM table1 AT(TIMESTAMP => timestamp) SELECT * FROM table1 BEFORE(STATEMENT => statementID)		SELECT * FROM table FOR SYSTEM_TIME AS OF timestamp Nota: BigQuery no tiene una alternativa directa al Snowflake de ANTES de usar un ID de instrucción. El valor de timestamp no puede ser más de 7 días antes de la marca de tiempo actual.
@[namespace]<stage_name>[/path]		BigQuery no admite el concepto de archivos almacenados en etapa intermedia.
SELECT* FROM table START WITH predicate CONNECT BY [PRIOR] col1 = [PRIOR] col2 [, ...] ...		BigQuery no ofrece una alternativa directa al CONNECT BY de Snowflake.

Se puede hacer referencia a las tablas de BigQuery en la cláusula FROM de las siguientes maneras:

• [project_id].[dataset_id].[table_name]
• [dataset_id].[table_name]
• [table_name]

BigQuery también admite referencias de tabla adicionales:

• Versiones históricas de la definición y las filas de la tabla con FOR SYSTEM_TIME AS OF
• Rutas de campo o cualquier ruta que se resuelva en un campo dentro de un tipo de datos (es decir, un STRUCT)
• Arrays planos.

Cláusula WHERE

La cláusula WHERE de Snowflake y la cláusula WHERE de BigQuery son idénticas, excepto por lo siguiente:

Snowflake		BigQuery
SELECT col1, col2 FROM table1, table2 WHERE col1 = col2(+)		SELECT col1, col2 FROM table1 INNER JOIN table2 ON col1 = col2 Nota: BigQuery no admite la sintaxis (+) para JOIN.

JOIN tipos

Snowflake y BigQuery admiten los siguientes tipos de unión:

• [INNER] JOIN
• LEFT [OUTER] JOIN
• RIGHT [OUTER] JOIN
• FULL [OUTER] JOIN
• CROSS JOIN y la “unión cruzada con coma” implícita equivalente

Snowflake y BigQuery admiten las cláusulas ON y USING.

En la siguiente tabla, se incluye una lista de diferencias menores.

Snowflake		BigQuery
SELECT col1 FROM table1 NATURAL JOIN table2		SELECT col1 FROM table1 INNER JOIN table2 USING (col1, col2 [, ...]) Nota: En BigQuery, las cláusulas JOIN requieren una condición JOIN, a menos que sea una CROSS JOIN o una de las tablas unidas es un campo dentro de un tipo de datos o un array.
SELECT ... FROM table1 AS t1, LATERAL ( SELECT* FROM table2 AS t2 WHERE t1.col = t2.col ) Nota: A diferencia del resultado de una unión no lateral, el resultado de una unión lateral incluye solo las filas generadas desde la vista en línea. No es necesario que las filas del lado izquierdo se unan a la derecha porque las filas del lado izquierdo ya se tomaron en cuenta cuando se pasaron a la vista en línea.		SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2 ON t1.col = t2.col Nota: BigQuery no admite una alternativa directa para LATERAL JOINs.

Cláusula WITH

Una cláusula WITH de BigQuery contiene una o más subconsultas con nombre que se ejecutan cada vez que una declaración SELECT posterior hace referencia a estas. Las cláusulas WITH de Snowflake se comportan de la misma manera que BigQuery, excepto que BigQuery no admite WITH RECURSIVE.

Cláusula GROUP BY

Las cláusulas GROUP BY de Snowflake son compatibles con las cláusulas GROUP BY, GROUP BY ROLLUP, GROUP BY GROUPING SETS yGROUP BY CUBE, mientras que las cláusulas GROUP BY de BigQuery admiten cláusulas GROUP BY yGROUP BY ROLLUP.

HAVING de Snowflake y HAVING de BigQuery son sinónimos. Ten en cuenta que HAVING ocurre después de GROUP BY y de la agregación, y antes de ORDER BY.

Snowflake		BigQuery
SELECT col1 as one, col2 as two FROM table GROUP BY (one, 2)		SELECT col1 as one, col2 as two FROM table GROUP BY (one, 2)
SELECT col1 as one, col2 as two FROM table GROUP BY ROLLUP (one, 2)		SELECT col1 as one, col2 as two FROM table GROUP BY ROLLUP (one, 2)
SELECT col1 as one, col2 as two FROM table GROUP BY GROUPING SETS (one, 2) Nota: Snowflake permite hasta 128 conjuntos de agrupación en el mismo bloque de consulta		BigQuery no admite una alternativa directa al GROUP BY GROUPING SETS de Snowflake.
SELECT col1 as one, col2 as two FROM table GROUP BY CUBE (one,2) Nota: Snowflake permite hasta 7 elementos (128 conjuntos de agrupación) en cada cubo.		BigQuery no admite una alternativa directa al GROUP BY CUBE de Snowflake.

Cláusula ORDER BY

Existen algunas diferencias menores entre las cláusulas ORDER BY de Snowflake y las cláusulas ORDER BY de BigQuery.

Snowflake		BigQuery
En Snowflake, los NULL se clasifican en último lugar de forma predeterminada (orden ascendente).		En BigQuery, los NULLS se clasifican primero de forma predeterminada (orden ascendente).
Puedes especificar si los valores NULL deben ordenarse primero o en último lugar mediante NULLS FIRST o NULLS LAST, respectivamente.		No hay un equivalente para especificar si los valores NULL deben ser los primeros o los últimos en BigQuery.

Cláusula LIMIT/FETCH

La cláusula LIMIT/FETCH en Snowflake restringe el número máximo de filas que muestra una declaración o subconsulta. LIMIT (sintaxis de Postgres) y FETCH (sintaxis ANSI) producen el mismo resultado.

En Snowflake y BigQuery, aplicar una cláusula LIMIT a una consulta no afecta la cantidad de datos leídos.

Snowflake		BigQuery
SELECT col1, col2 FROM table ORDER BY col1 LIMIT count OFFSET start SELECT ... FROM ... ORDER BY ... OFFSET start {[ROW | ROWS]} FETCH {[FIRST | NEXT]} count {[ROW | ROWS]} [ONLY] Nota: Se aceptan los valores NULL, de cadena vacía ('') y $$$$, y se tratan como "ilimitados". El uso principal es para conectores y controladores.		SELECT col1, col2 FROM table ORDER BY col1 LIMIT count OFFSET start NOTA: BigQuery no es compatible con FETCH. LIMIT reemplaza a FETCH. Nota: En BigQuery, se debe usar OFFSET junto con una cantidad de LIMIT count. Asegúrate de configurar el valor INT64 count como el mínimo de filas ordenadas necesarias para obtener el mejor rendimiento. Si ordenas todas las filas de resultados innecesariamente, el rendimiento de la ejecución de consultas será peor.

Cláusula QUALIFY

La cláusula QUALIFY en Snowflake te permite filtrar resultados para funciones analíticas similares a lo que HAVING hace con funciones agregadas y cláusulas GROUP BY.

Snowflake		BigQuery
SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;		La cláusula QUALIFY de Snowflake con una función analítica como ROW_NUMBER(), COUNT() y conOVER PARTITION BY se expresa en BigQuery como una cláusula WHERE en la subconsulta que contiene el valor analítico. Usando ROW_NUMBER(): SELECT col1, col2 FROM ( SELECT col1, col2 ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1; Usa ARRAY_AGG(), que admite particiones más grandes: SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1) [OFFSET(0)] FROM table GROUP BY col1 ) AS result;

Funciones

En las siguientes secciones, se enumeran las funciones de Snowflake y sus equivalentes de BigQuery.

Funciones de agregación

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de agregación, analítica agregada y agregación de Snowflake aproximada con sus equivalentes de BigQuery.

Snowflake	BigQuery
ANY_VALUE([DISTINCT] expression) [OVER ...] Nota: DISTINCT no tiene ningún efecto	ANY_VALUE(expression) [OVER ...]
APPROX_COUNT_DISTINCT([DISTINCT] expression) [OVER ...] Nota: DISTINCT no tiene ningún efecto	APPROX_COUNT_DISTINCT(expression) Nota: BigQuery no es compatible con APPROX_COUNT_DISTINCT con funciones analíticas.
APPROX_PERCENTILE(expression, percentile) [OVER ...] Nota: Snowflake no tiene la opción RESPECT NULLS	APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))] Nota: BigQuery no es compatible con APPROX_QUANTILES con funciones analíticas.
APPROX_PERCENTILE_ACCUMULATE (expression)	BigQuery no admite la capacidad de almacenar un estado intermedio cuando se predicen valores aproximados.
APPROX_PERCENTILE_COMBINE(state)	BigQuery no admite la capacidad de almacenar un estado intermedio cuando se predicen valores aproximados.
APPROX_PERCENTILE_ESTIMATE(state, percentile)	BigQuery no admite la capacidad de almacenar un estado intermedio cuando se predicen valores aproximados.
APPROX_TOP_K(expression, [number [counters]] Nota: Si no se especifica un parámetro numérico, el valor predeterminado es 1. Los contadores deben ser significativamente mayores que el número.	APPROX_TOP_COUNT(expression, number) Nota: BigQuery no es compatible con APPROX_TOP_COUNT con funciones analíticas.
APPROX_TOP_K_ACCUMULATE(expression, counters)	BigQuery no admite la capacidad de almacenar un estado intermedio cuando se predicen valores aproximados.
APPROX_TOP_K_COMBINE(state, [counters])	BigQuery no admite la capacidad de almacenar un estado intermedio cuando se predicen valores aproximados.
APPROX_TOP_K_ESTIMATE(state, [k])	BigQuery no admite la capacidad de almacenar un estado intermedio cuando se predicen valores aproximados.
APPROXIMATE_JACCARD_INDEX([DISTINCT] expression)	Puedes usar una UDF personalizada para implementar MINHASH con funciones hash distintas de k. Otro enfoque para reducir la varianza en MINHASH es mantener k de los valores mínimos de una función hash. En este caso, el índice de Jaccard puede aproximarse de la siguiente manera: WITH minhash_A AS ( SELECT DISTINCT FARM_FINGERPRINT(TO_JSON_STRING(t)) AS h FROM TA AS t ORDER BY h LIMIT k), minhash_B AS ( SELECT DISTINCT FARM_FINGERPRINT(TO_JSON_STRING(t)) AS h FROM TB AS t ORDER BY h LIMIT k) SELECT COUNT(*) / k AS APPROXIMATE_JACCARD_INDEX FROM minhash_A INNER JOIN minhash_B ON minhash_A.h = minhash_B.h
APPROXIMATE_SIMILARITY([DISTINCT] expression)	Es un sinónimo de APPROXIMATE_JACCARD_INDEX y se puede implementar de la misma manera.
ARRAY_AGG([DISTINCT] expression1) [WITHIN GROUP (ORDER BY ...)] [OVER ([PARTITION BY expression2])] Note: Snowflake does not support ability to IGNORE|RESPECT NULLS and to LIMIT directly in ARRAY_AGG.	ARRAY_AGG([DISTINCT] expression1 [{IGNORE|RESPECT}] NULLS] [ORDER BY ...] LIMIT ...]) [OVER (...)]
AVG([DISTINCT] expression) [OVER ...]	AVG([DISTINCT] expression) [OVER ...] Nota: AVG de BigQuery no realiza la conversión automática en STRING.
BITAND_AGG(expression) [OVER ...]	BIT_AND(expression) [OVER ...] Nota: Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano.
BITOR_AGG(expression) [OVER ...]	BIT_OR(expression) [OVER ...] Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano.
BITXOR_AGG([DISTINCT] expression) [OVER ...]	BIT_XOR([DISTINCT] expression) [OVER ...] Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano.
BOOLAND_AGG(expression) [OVER ...] Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	LOGICAL_AND(expression) [OVER ...]
BOOLOR_AGG(expression) [OVER ...] Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	LOGICAL_OR(expression) [OVER ...]
BOOLXOR_AGG(expression) [OVER ([PARTITION BY <partition_expr> ]) Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	Para la expresión numérica: SELECT CASE COUNT(*) WHEN 1 THEN TRUE WHEN 0 THEN NULL ELSE FALSE END AS BOOLXOR_AGG FROM T WHERE expression != 0 Para usar OVER, puedes ejecutar lo siguiente (se proporciona un ejemplo booleano): SELECT CASE COUNT(expression) OVER (PARTITION BY partition_expr) WHEN 0 THEN NULL ELSE CASE COUNT( CASE expression WHEN TRUE THEN 1 END) OVER (PARTITION BY partition_expr) WHEN 1 THEN TRUE ELSE FALSE END END AS BOOLXOR_AGG FROM T
CORR(dependent, independent) [OVER ...]	CORR(dependent, independent) [OVER ...]
COUNT([DISTINCT] expression [,expression2]) [OVER ...]	COUNT([DISTINCT] expression [,expression2]) [OVER ...]
COVAR_POP(dependent, independent) [OVER ...]	COVAR_POP(dependent, independent) [OVER ...]
COVAR_SAMP(dependent, independent) [OVER ...]	COVAR_SAMP(dependent, independent) [OVER ...]
GROUPING(expression1, [,expression2...])	BigQuery no admite una alternativa directa al GROUPING de Snowflake. Disponible a través de una función definida por el usuario.
GROUPING_ID(expression1, [,expression2...])	BigQuery no admite una alternativa directa al GROUPING_ID de Snowflake. Disponible a través de una función definida por el usuario.
HASH_AGG([DISTINCT] expression1, [,expression2]) [OVER ...]	SELECT BIT_XOR( FARM_FINGERPRINT( TO_JSON_STRING(t))) [OVER] FROM t
SELECT HLL([DISTINCT] expression1, [,expression2]) [OVER ...] Nota: Snowflake no te permite especificar la precisión.	SELECT HLL_COUNT.EXTRACT(sketch) FROM ( SELECT HLL_COUNT.INIT(expression) AS sketch FROM table ) Nota: BigQuery no es compatible con HLL_COUNT… con funciones analíticas. Un usuario no puede incluir varias expresiones en una sola función HLL_COUNT....
HLL_ACCUMULATE([DISTINCT] expression) Nota: Snowflake no te permite especificar la precisión.	HLL_COUNT.INIT(expresión [, precisión])
HLL_COMBINE([DISTINCT] state)	HLL_COUNT.MERGE_PARTIAL(boceto)
HLL_ESTIMATE(state)	HLL_COUNT.EXTRACT(sketch)
HLL_EXPORT(binary)	BigQuery no admite una alternativa directa al HLL_EXPORT de Snowflake.
HLL_IMPORT(object)	BigQuery no admite una alternativa directa al HLL_IMPORT de Snowflake.
KURTOSIS(expression) [OVER ...]	BigQuery no admite una alternativa directa al KURTOSIS de Snowflake.
LISTAGG( [DISTINCT] aggregate_expression [, delimiter] ) [OVER ...]	STRING_AGG( [DISTINCT] aggregate_expression [, delimiter] ) [OVER ...]
MEDIAN(expression) [OVER ...] Nota: Snowflake no admite la capacidad de IGNORE|RESPECT NULLS ni de LIMIT directamente en ARRAY_AGG.	PERCENTILE_CONT( value_expression, 0.5 [ {RESPECT | IGNORE} NULLS] ) OVER()
MAX(expression) [OVER ...] MIN(expression) [OVER ...]	MAX(expression) [OVER ...] MIN(expression) [OVER ...]
MINHASH(k, [DISTINCT] expressions)	Puedes usar una UDF personalizada para implementar MINHASH con funciones hash distintas de k. Otro enfoque para reducir la varianza en MINHASH es mantener k de los valores mínimos de una función hash: SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS MINHASH FROM t ORDER BY MINHASH LIMIT k
MINHASH_COMBINE([DISTINCT] state)	FROM ( SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TA AS t ORDER BY h LIMIT k UNION SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TB AS t ORDER BY h LIMIT k ) ORDER BY h LIMIT k
MODE(expr1) OVER ( [ PARTITION BY <expr2> ] )	SELECT expr1 FROM ( SELECT expr1, ROW_NUMBER() OVER ( PARTITION BY expr2 ORDER BY cnt DESC) rn FROM ( SELECT expr1, expr2, COUNTIF(expr1 IS NOT NULL) OVER (PARTITION BY expr2, expr1) cnt FROM t)) WHERE rn = 1
OBJECT_AGG(key, value) [OVER ...]	Puedes considerar usar TO_JSON_STRING para convertir un valor en una cadena con formato JSON.
PERCENTILE_CONT(percentile) WITHIN GROUP (ORDER BY value_expression) [OVER ...]	PERCENTILE_CONT( value_expression, percentile [ {RESPECT | IGNORE} NULLS] ) OVER()
PERCENTILE_DISC(percentile) WITHIN GROUP (ORDER BY value_expression) [OVER ...]	PERCENTILE_DISC( value_expression, percentile [ {RESPECT | IGNORE} NULLS] ) OVER()
REGR_AVGX(dependent, independent) [OVER ...]	SELECT AVG(independent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) )
REGR_AVGY(dependent, independent) [OVER ...]	SELECT AVG(dependent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) )
REGR_COUNT(dependent, independent) [OVER ...]	SELECT COUNT(*) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) )
REGR_INTERCEPT(dependent, independent) [OVER ...]	SELECT AVG(dependent) - COVAR_POP(dependent,independent)/ VAR_POP(dependent) * AVG(independent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_R2(dependent, independent) [OVER ...]	SELECT CASE WHEN VAR_POP(independent) = 0 THEN NULL WHEN VAR_POP(dependent) = 0 AND VAR_POP(independent) != 0 THEN 1 ELSE POWER(CORR(dependent, independent), 2) END AS ... FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_SLOPE(dependent, independent) [OVER ...]	SELECT COVAR_POP(dependent,independent)/ VAR_POP(dependent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_SXX(dependent, independent) [OVER ...]	SELECT COUNT(*)*VAR_POP(independent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_SYY(dependent, independent) [OVER ...]	SELECT COUNT(*)*VAR_POP(dependent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
SKEW(expression)	BigQuery no admite una alternativa directa al SKEW de Snowflake.
STDDEV([DISTINCT] expression) [OVER ...]	STDDEV([DISTINCT] expression) [OVER ...]
STDDEV_POP([DISTINCT] expression) [OVER ...]	STDDEV_POP([DISTINCT] expression) [OVER ...]
STDDEV_SAMP([DISTINCT] expression) [OVER ...]	STDDEV_SAMP([DISTINCT] expression) [OVER ...]
SUM([DISTINCT] expression) [OVER ...]	SUM([DISTINCT] expression) [OVER ...]
VAR_POP([DISTINCT] expression) [OVER ...] Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.	VAR_POP([DISTINCT] expression) [OVER ...]
VARIANCE_POP([DISTINCT] expression) [OVER ...] Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.	VAR_POP([DISTINCT] expression) [OVER ...]
VAR_SAMP([DISTINCT] expression) [OVER ...] Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.	VAR_SAMP([DISTINCT] expression) [OVER ...]
VARIANCE([DISTINCT] expression) [OVER ...] Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.	VARIANCE([DISTINCT] expression) [OVER ...]

BigQuery también ofrece las siguientes funciones de agregación, analítica agregada y agregación aproximada, que no tienen un análogo directo en Snowflake:

• COUNTIF
• ARRAY_CONCAT_AGG
• HLL_COUNT.MERGE

Funciones de expresión a nivel de bits

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de expresión de bits del Snowflake con sus equivalentes de BigQuery.

Si el tipo de datos de una expresión no es INTEGER, Snowflake intenta convertir en INTEGER. Sin embargo, BigQuery no intenta convertir en INTEGER.

Snowflake	BigQuery
BITAND(expression1, expression2)	BIT_ADD(x) FROM UNNEST([expression1, expression2]) AS x expression1 & expression2
BITNOT(expression)	~ expression
BITOR(expression1, expression2)	BIT_OR(x) FROM UNNEST([expression1, expression2]) AS x expression1 | expression2
BITSHIFTLEFT (expression, n)	expression << n
BITSHIFTRIGHT (expression, n)	expression >> n
BITXOR(expression, expression) Nota: Snowflake no es compatible con DISTINCT.	BIT_XOR([DISTINCT] x) FROM UNNEST([expression1, expression2]) AS x expression ^ expression

Funciones de expresión condicional

En la siguiente tabla, se muestran las asignaciones entre expresiones condicionales comunes del Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
expression [ NOT ] BETWEEN lower AND upper	(expression >= lower AND expression <= upper)
BOOLAND(expression1, expression2) Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	LOGICAL_AND(x) FROM UNNEST([expression1, expression2]) AS x expression1 AND expression2
BOOLNOT(expression1) Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	NOT expression
BOOLOR Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	LOGICAL_OR(x) FROM UNNEST([expression1, expression2]) AS x expression1 OR expression2
BOOLXOR Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.	BigQuery no admite una alternativa directa al BOOLXOR. de Snowflake.
CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END	CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END
COALESCE(expr1, expr2, [,...]) Nota: Snowflake requiere al menos dos expresiones. BigQuery solo requiere una.	COALESCE(expr1, [,...])
DECODE(expression, search1, result1, [search2, result2...] [,default])	CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END Nota: BigQuery admite subconsultas en las declaraciones de condición. Se puede usar para reproducir el objeto DECODE de Snowflake. El usuario debe usar IS NULL en lugar de = NULL para hacer coincidir expresiones de selección de NULL con expresiones de búsqueda NULL.
EQUAL_NULL(expression1, expression2)	BigQuery no admite una alternativa directa al EQUAL_NULL. de Snowflake.
GREATEST(expression1, [,expression2]...)	GREATEST(expression1, [,expression2]...)
IFF(condition, true_result, false_result)	IF(condition, true_result, false_result)
IFNULL(expression1, expression2)	IFNULL(expression1, expression2)
[ NOT ] IN ...	[ NOT ] IN ...
expression1 IS [ NOT ] DISTINCT FROM expression2	BigQuery no admite una alternativa directa al IS [ NOT ] DISTINCT FROM. de Snowflake.
expression IS [ NOT ] NULL	expression IS [ NOT ] NULL
IS_NULL_VALUE(variant_expr)	BigQuery no admite tipos de datos VARIANT.
LEAST(expression,...)	LEAST(expression,...)
NULLIF(expression1,expression2)	NULLIF(expression1,expression2)
NVL(expression1, expression2)	IFNULL(expression1,expression2)
NVL2(expr1,expr2,expr2)	IF(expr1 IS NOT NULL, expr2,expr3)
REGR_VALX(expr1,expr2)	IF(expr1 IS NULL, NULL, expr2) Nota: BigQuery no admite una alternativa directa a las funciones REGR... de Snowflake.
REGR_VALY(expr1,expr2)	IF(expr2 IS NULL, NULL, expr1) Nota: BigQuery no admite una alternativa directa a las funciones REGR... de Snowflake.
ZEROIFNULL(expression)	IFNULL(expression,0)

Funciones de contexto

En la siguiente tabla, se muestran las asignaciones entre las funciones de contexto comunes de Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
CURRENT_ACCOUNT()	SESSION_USER() Nota: No es una comparación directa. Snowflake muestra el ID de la cuenta, BigQuery muestra la dirección de correo electrónico del usuario.
CURRENT_CLIENT()	El concepto no se usa en BigQuery
CURRENT_DATABASE()	SELECT catalog_name FROM INFORMATION_SCHEMA.SCHEMATA Esto muestra una tabla de nombres de proyectos. No es una comparación directa.
CURRENT_DATE[()] Nota: Snowflake no aplica “()” después del comando CURRENT_DATE para cumplir con los estándares ANSI.	CURRENT_DATE([timezone]) Nota: CURRENT_DATE de BigQuery admite la especificación opcional de zona horaria.
CURRENT_REGION()	SELECT location FROM INFORMATION_SCHEMA.SCHEMATA Nota: INFORMATION_SCHEMA.SCHEMATA de BigQuery muestra referencias de ubicación más generalizadas que CURRENT_REGION() de Snowflake. No es una comparación directa.
CURRENT_ROLE()	El concepto no se usa en BigQuery
CURRENT_SCHEMA()	SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA Esto muestra una tabla de todos los conjuntos de datos (también llamados esquemas) disponibles en el proyecto o la región. No es una comparación directa.
CURRENT_SCHEMAS()	El concepto no se usa en BigQuery
CURRENT_SESSION()	El concepto no se usa en BigQuery
CURRENT_STATEMENT()	SELECT query FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar consultas por tipo de trabajo, tipo de inicio/finalización, etcétera.
CURRENT_TIME[([frac_sec_prec])] Nota: Snowflake permite una precisión de segundos fraccionarios opcional. Los valores válidos van de 0 a 9 nanosegundos. El valor predeterminado es 9. Para cumplir con el ANSI, se puede llamar sin “()”.	CURRENT_TIME()
CURRENT_TIMESTAMP[([frac_sec_prec])] Nota: Snowflake permite una precisión de segundos fraccionarios opcional. Los valores válidos van de 0 a 9 nanosegundos. El valor predeterminado es 9. Para cumplir con el ANSI, se puede llamar sin “()”. Configura TIMEZONE como un parámetro de sesión.	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Nota: CURRENT_DATETIME muestra el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP muestra tipos de datos TIMESTAMP:
CURRENT_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera.
CURRENT_USER[()] Nota: Snowflake no aplica “()” después del comando CURRENT_USER para cumplir con los estándares ANSI.	SESSION_USER() SELECT user_email FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: No es una comparación directa. Snowflake muestra el nombre de usuario; BigQuery muestra la dirección de correo electrónico del usuario.
CURRENT_VERSION()	El concepto no se usa en BigQuery
CURRENT_WAREHOUSE()	SELECT catalg_name FROM INFORMATION_SCHEMA.SCHEMATA
LAST_QUERY_ID([num])	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera.
LAST_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera.
LOCALTIME() Nota: Snowflake no aplica “()” después del comando LOCALTIME para cumplir con los estándares ANSI.	CURRENT_TIME()
LOCALTIMESTAMP()	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Nota: CURRENT_DATETIME muestra el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP muestra tipos de datos TIMESTAMP:

Funciones de conversión

En la siguiente tabla, se muestran las asignaciones entre las funciones de conversión comunes de Snowflake con sus equivalentes de BigQuery.

Ten en cuenta que las funciones que parecen idénticas en Snowflake y BigQuery pueden mostrar diferentes tipos de datos.

Snowflake	BigQuery
CAST(expression AS type) expression :: type	CAST(expression AS type)
TO_ARRAY(expression)	[expression] ARRAY(subquery)
TO_BINARY(expression[, format]) Nota: Snowflake admite la conversión HEX, BASE64 y UTF-8. Snowflake también admite TO_BINARY mediante el tipo de datos VARIANT. BigQuery no tiene una alternativa al tipo de datos VARIANT.	TO_HEX(CAST(expression AS BYTES)) TO_BASE64(CAST(expression AS BYTES)) CAST(expression AS BYTES) Nota: La conversión de STRING predeterminada de BigQuery usa la codificación UTF-8. Snowflake no tiene una opción para admitir la codificación BASE32.
TO_BOOLEAN(expression) Nota: INT64 TRUE: de lo contrario, FALSE: 0 STRING TRUE: "true"/"t"/"yes"/"y"/"on"/"1", FALSE: "false"/"f"/"no"/"n"/"off"/"0"	CAST(expression AS BOOL) Nota: INT64 TRUE: de lo contrario, FALSE: 0 STRING TRUE: "true", FALSE: "false"
TO_CHAR(expression[, format]) TO_VARCHAR(expression[, format]) Nota: Los modelos de formato de Snowflake se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.	CAST(expression AS STRING) Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT_DATE, FORMAT_DATETIME, FORMAT_TIME o FORMAT_TIMESTAMP.
TO_DATE(expression[, format]) DATE(expression[, format]) Nota: Snowflake admite la capacidad de convertir directamente tipos INTEGER a tipos DATE. Los modelos de formato de Snowflake se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.	CAST(expression AS DATE) Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT, FORMAT_DATETIME o FORMAT_TIMESTAMP.
TO_DECIMAL(expression[, format] [,precision[, scale]] TO_NUMBER(expression[, format] [,precision[, scale]] TO_NUMERIC(expression[, format] [,precision[, scale]] Nota: Los modelos de formato de Snowflake para los tipos de datos DECIMAL, NUMBER y NUMERIC se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.	ROUND(CAST(expression AS NUMERIC) , x) Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT.
TO_DOUBLE(expression[, format]) Nota: Los modelos de formato de Snowflake para los tipos de datos DOUBLE se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.	CAST(expression AS FLOAT64) Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT.
TO_JSON(variant_expression)	BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.
TO_OBJECT(variant_expression)	BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.
TO_TIME(expression[, format]) TIME(expression[, format]) Nota: Los modelos de formato de Snowflake para los tipos de datos STRING se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.	CAST(expression AS TIME) Nota: BigQuery no tiene una alternativa al tipo de datos VARIANT del Snowflake. La expresión de entrada de BigQuery puede formatearse con FORMAT, FORMAT_DATETIME, FORMAT_TIMESTAMP o FORMAT_TIME.
TO_TIMESTAMP(expression[, scale]) TO_TIMESTAMP_LTZ(expression[, scale]) TO_TIMESTAMP_NTZ(expression[, scale]) TO_TIMESTAMP_TZ(expression[, scale]) Nota: BigQuery no tiene una alternativa al tipo de datos VARIANT.	CAST(expression AS TIMESTAMP) Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT, FORMAT_DATE, FORMAT_DATETIME y FORMAT_TIME. La zona horaria se puede incluir o no incluir mediante los parámetros de FORMAT_TIMESTAMP.
TO_VARIANT(expression)	BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.
TO_XML(variant_expression)	BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.
TRY_CAST(expression AS type)	SAFE_CAST(expression AS type)
TRY_TO_BINARY(expression[, format])	TO_HEX(SAFE_CAST(expression AS BYTES)) TO_BASE64(SAFE_CAST(expression AS BYTES)) SAFE_CAST(expression AS BYTES)
TRY_TO_BOOLEAN(expression)	SAFE_CAST(expression AS BOOL)
TRY_TO_DATE(expression)	SAFE_CAST(expression AS DATE)
TRY_TO_DECIMAL(expression[, format] [,precision[, scale]] TRY_TO_NUMBER(expression[, format] [,precision[, scale]] TRY_TO_NUMERIC(expression[, format] [,precision[, scale]]	ROUND( SAFE_CAST(expression AS NUMERIC) , x)
TRY_TO_DOUBLE(expression)	SAFE_CAST(expression AS FLOAT64)
TRY_TO_TIME(expression)	SAFE_CAST(expression AS TIME)
TRY_TO_TIMESTAMP(expression) TRY_TO_TIMESTAMP_LTZ(expression) TRY_TO_TIMESTAMP_NTZ(expression) TRY_TO_TIMESTAMP_TZ(expression)	SAFE_CAST(expression AS TIMESTAMP)

BigQuery también ofrece las siguientes funciones de conversión, que no tienen un análogo directo en Snowflake:

• CODE_POINTS_TO_BYTES
• CODE_POINTS_TO_STRING
• FORMAT
• FROM_BASE32
• FROM_BASE64
• FROM_HEX
• SAFE_CONVERT_BYTES_TO_STRING
• TO_BASE32
• TO_CODE_POINTS

Funciones de generación de datos

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de generación de datos de Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
NORMAL(mean, stddev, gen)	BigQuery no admite una comparación directa con NORMAL. de Snowflake.
RANDOM([seed])	IF(RAND()>0.5, CAST(RAND()*POW(10, 18) AS INT64), (-1)*CAST(RAND()*POW(10, 18) AS INT64)) Nota: BigQuery no admite la propagación
RANDSTR(length, gen)	BigQuery no admite una comparación directa con RANDSTR. de Snowflake.
SEQ1 / SEQ2 / SEQ4 / SEQ8	BigQuery no admite una comparación directa con SEQ_. de Snowflake.
UNIFORM(min, max, gen)	CAST(min + RAND()*(max-min) AS INT64) Nota: Usa UDF persistentes para crear un equivalente al UNIFORM de Snowflake. Ejemplo aquí.
UUID_STRING([uuid, name]) Nota: Snowflake muestra 128 bits aleatorios. Snowflake admite los UUID de la versión 4 (aleatorio) y de la versión 5 (con nombre).	GENERATE_UUID() Nota: BigQuery muestra 122 bits aleatorios. BigQuery solo es compatible con los UUID de la versión 4.
ZIPF(s, N, gen)	BigQuery no admite una comparación directa con ZIPF. de Snowflake.

Funciones de fecha y hora

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de fecha y hora de Snowflake con sus equivalentes de BigQuery. Las funciones de tiempo y datos de BigQuery incluyen funciones de fecha, funciones de fecha y hora, funciones de tiempo y funciones de marca de tiempo.

Snowflake	BigQuery
ADD_MONTHS(date, months)	CAST( DATE_ADD( date, INTERVAL integer MONTH ) AS TIMESTAMP )
CONVERT_TIMEZONE(source_tz, target_tz, source_timestamp) CONVERT_TIMEZONE(target_tz, source_timestamp)	PARSE_TIMESTAMP( "%c%z", FORMAT_TIMESTAMP( "%c%z", timestamp, target_timezone ) ) Nota: source_timezone siempre es UTC en BigQuery
DATE_FROM_PARTS(year, month, day) Nota: Snowflake admite desbordamiento y fechas negativas. Por ejemplo, DATE_FROM_PARTS(2000, 1 + 24, 1) devuelve el 1 de enero de 2002. Esto no es compatible con BigQuery.	DATE(year, month, day) DATE(timestamp_expression[, timezone]) DATE(datetime_expression)
DATE_PART(part, dateOrTime) Nota: Snowflake admite los tipos de parte de día de la semana ISO, nanosegundo y segundo/milisegundo/microsegundo/nanosegundo del ciclo de entrenamiento. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.	EXTRACT(part FROM dateOrTime) Nota: BigQuery admite los tipos de parte de semana(<weekday>), microsegundo y milisegundo. Snowflake no lo hace. Consulta la lista completa de tipos de partes de BigQuery aquí y aquí.
DATE_TRUNC(part, dateOrTime) Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Nota: BigQuery es compatible con los tipos de parte de semana(<weekday>), semana ISO y año ISO. Snowflake no lo hace.
DATEADD(part, value, dateOrTime)	DATE_ADD(date, INTERVAL value part)
DATEDIFF( part, expression1, expression2 ) Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO.
DAYNAME(dateOrTimestamp)	FORMAT_DATE('%a', date) FORMAT_DATETIME('%a', datetime) FORMAT_TIMESTAMP('%a', timestamp)
EXTRACT(part FROM dateOrTime) Nota: Snowflake admite los tipos de parte de día de la semana ISO, nanosegundo y segundo/milisegundo/microsegundo/nanosegundo del ciclo de entrenamiento. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.	EXTRACT(part FROM dateOrTime) Nota: BigQuery admite los tipos de parte de semana(<weekday>), microsegundo y milisegundo. Snowflake no lo hace. Consulta la lista completa de tipos de partes de BigQuery aquí y aquí.
[HOUR, MINUTE, SECOND](timeOrTimestamp)	EXTRACT(part FROM timestamp [AT THE ZONE timezone])
LAST_DAY(dateOrTime[, part])	DATE_SUB( DATE_TRUNC( DATE_ADD(date, INTERVAL 1 part), part), INTERVAL 1 DAY)
MONTHNAME(dateOrTimestamp)	FORMAT_DATE('%b', date) FORMAT_DATETIME('%b', datetime) FORMAT_TIMESTAMP('%b', timestamp)
NEXT_DAY(dateOrTime, dowString)	DATE_ADD( DATE_TRUNC( date, WEEK(dowString)), INTERVAL 1 WEEK) Nota: Es posible que sea necesario cambiar el formato de dowString. Por ejemplo, “su” de Snowflake será “SUNDAY” en BigQuery.
PREVIOUS_DAY(dateOrTime, dowString)	DATE_TRUNC( date, WEEK(dowString) ) Nota: Es posible que sea necesario cambiar el formato de dowString. Por ejemplo, “su” de Snowflake será “SUNDAY” en BigQuery.
TIME_FROM_PARTS(hour, minute, second[, nanosecond) Nota: Snowflake admite tiempos de desbordamiento. Por ejemplo, TIME_FROM_PARTS(0, 100, 0) muestra 01:40:00… Esto no es compatible con BigQuery. BigQuery no admite nanosegundos.	TIME(hour, minute, second) TIME(timestamp, [timezone]) TIME(datetime)
TIME_SLICE(dateOrTime, sliceLength, part[, START] TIME_SLICE(dateOrTime, sliceLength, part[, END]	DATE_TRUNC( DATE_SUB(CURRENT_DATE(), INTERVAL value MONTH), MONTH) DATE_TRUNC( DATE_ADD(CURRENT_DATE(), INTERVAL value MONTH), MONTH) Nota: BigQuery no admite una comparación directa y exacta con TIME_SLICE de Snowflake. Usa DATETINE_TRUNC, TIME_TRUNC, TIMESTAMP_TRUNC para el tipo de datos adecuado.
TIMEADD(part, value, dateOrTime)	TIME_ADD(time, INTERVAL value part)
TIMEDIFF( part, expression1, expression2, ) Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO.
TIMESTAMP_[LTZ, NTZ, TZ _]FROM_PARTS (year, month, day, hour, second [, nanosecond][, timezone])	TIMESTAMP( string_expression[, timezone] | date_expression[, timezone] | datetime_expression[, timezone] ) Nota: BigQuery requiere que las marcas de tiempo se ingresen como tipos STRING. Ejemplo: "2008-12-25 15:30:00"
TIMESTAMPADD(part, value, dateOrTime)	TIMESTAMPADD(timestamp, INTERVAL value part)
TIMESTAMPDIFF( part, expression1, expression2, ) Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO.
TRUNC(dateOrTime, part) Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Nota: BigQuery es compatible con los tipos de parte de semana(<weekday>), semana ISO y año ISO. Snowflake no lo hace.
[YEAR*, DAY*, WEEK*, MONTH, QUARTER](dateOrTimestamp)	EXTRACT(part FROM timestamp [AT THE ZONE timezone])

BigQuery también ofrece las siguientes funciones de fecha y hora, que no tienen un análogo directo en Snowflake:

DATE_SUB PARSE_DATE DATETIME_ADD PARSE_DATETIME PARSE_TIME TIMESTAMP_SUB TIMESTAMP_SECONDS UNIX_SECONDS	DATE_FROM_UNIX_DATE UNIX_DATE DATETIME_SUB TIME_SUB STRING FORMAT_TIMESTAMP TIMESTAMP_MILLIS UNIX_MILLIS	FORMAT_DATE DATETIME FORMAT_DATETIME FORMAT_TIME TIMESTAMP_ADD PARSE_TIMESTAMP TIMESTAMP_MICROS UNIX_MICROS

Esquema de información y funciones de tabla

BigQuery no admite de manera conceptual muchas de las funciones de tabla y el esquema de información de Snowflake. Snowflake ofrece el siguiente esquema de información y funciones de tabla, que no tienen un análogo directo en BigQuery:

• AUTOMATIC_CLUSTERING_HISTORY
• COPY_HISTORY
• DATA_TRANSFER_HISTORY
• DATABASE_REFRESH_HISTORY
• DATABASE_REFRESH_PROGRESS, DATABASE_REFRESH_PROGRESS_BY_JOB
• DATABASE_STORAGE_USAGE_HISTORY
• EXTERNAL_TABLE_FILES
• EXTERNAL_TABLE_FILE_REGISTRATION_HISTORY
• LOGIN_HISTORY, LOGIN_HISTORY_BY_USER
• MATERIALIZED_VIEW_REFRESH_HISTORY
• PIPE_USAGE_HISTORY
• REPLICATION_USAGE_HISTORY
• STAGE_STORAGE_USAGE_HISTORY
• TASK_DEPENDENTS
• VALIDATE_PIPE_LOAD
• WAREHOUSE_LOAD_HISTORY
• WAREHOUSE_METERING_HISTORY

A continuación, se muestra una lista de las funciones de tabla y el esquema de información asociados de BigQuery y Snowflake.

Snowflake	BigQuery
QUERY_HISTORY QUERY_HISTORY_BY_*	INFORMATION_SCHEMA.JOBS_BY_* Nota: No es una alternativa directa.
TASK_HISTORY	INFORMATION_SCHEMA.JOBS_BY_* Nota: No es una alternativa directa.

BigQuery ofrece las siguientes funciones de tabla y esquema de información, que no tienen un análogo directo en Snowflake:

• INFORMATION_SCHEMA.SCHEMATA
• INFORMATION_SCHEMA.ROUTINES
• INFORMATION_SCHEMA.TABLES
• INFORMATION_SCHEMA.VIEWS

Funciones numéricas

En la siguiente tabla, se muestran las asignaciones entre las funciones numéricas comunes del Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
ABS(expression)	ABS(expression)
ACOS(expression)	ACOS(expression)
ACOSH(expression)	ACOSH(expression)
ASIN(expression)	ASIN(expression)
ASINH(expression)	ASINH(expression)
ATAN(expression)	ATAN(expression)
ATAN2(y, x)	ATAN2(y, x)
ATANH(expression)	ATANH(expression)
CBRT(expression)	POW(expression, ⅓)
CEIL(expression [, scale])	CEIL(expression) Nota: CEIL de BigQuery no admite la capacidad de indicar precisión o escalamiento. ROUND no te permite especificar para redondear.
COS(expression)	COS(expression)
COSH(expression)	COSH(expression)
COT(expression)	1/TAN(expression)
DEGREES(expression)	(expression)*(180/ACOS(-1))
EXP(expression)	EXP(expression)
FACTORIAL(expression)	BigQuery no tiene una alternativa directa a FACTORIAL de Snowflake. Usa una función definida por el usuario.
FLOOR(expression [, scale])	FLOOR(expression) Nota: FLOOR de BigQuery no admite la capacidad de indicar precisión o escalamiento. ROUND no te permite especificar para redondear. TRUNC funciona como sinónimo para números positivos, pero no negativos, ya que evalúa el valor absoluto.
HAVERSINE(lat1, lon1, lat2, lon2)	ST_DISTANCE( ST_GEOGPOINT(lon1, lat1), ST_GEOGPOINT(lon2, lat2) )/1000 Nota: No es una coincidencia exacta, pero es lo suficientemente similar.
LN(expression)	LN(expression)
LOG(base, expression)	LOG(expression [,base]) LOG10(expression) Nota: La base predeterminada para LOG es 10.
MOD(expression1, expression2)	MOD(expression1, expression2)
PI()	ACOS(-1)
POW(x, y) POWER(x, y)	POW(x, y) POWER(x, y)
RADIANS(expression)	(expression)*(ACOS(-1)/180)
ROUND(expression [, scale])	ROUND(expression, [, scale])
SIGN(expression)	SIGN(expression)
SIN(expression)	SIN(expression)
SINH(expression)	SINH(expression)
SQRT(expression)	SQRT(expression)
SQUARE(expression)	POW(expression, 2)
TAN(expression)	TAN(expression)
TANH(expression)	TANH(expression)
TRUNC(expression [, scale]) TRUNCATE(expression [, scale])	TRUNC(expression [, scale]) Nota: El valor que se muestra de BigQuery debe ser menor que la expresión; no admite igual.

BigQuery también ofrece las siguientes funciones mamáticas, que no tienen un análogo directo en Snowflake:

• IS_INF
• IS_NAN
• IEEE_DIVIDE
• DIV
• SAFE_DIVIDE
• SAFE_MULTIPLY
• SAFE_NEGATE
• SAFE_ADD
• SAFE_SUBTRACT
• RANGE_BUCKET

Funciones de datos semiestructurados

Snowflake	BigQuery
ARRAY_APPEND	Función personalizada definida por el usuario
ARRAY_CAT	ARRAY_CONCAT
ARRAY_COMPACT	Función personalizada definida por el usuario
ARRAY_CONSTRUCT	[ ]
ARRAY_CONSTRUCT_COMPACT	Función personalizada definida por el usuario
ARRAY_CONTAINS	Función personalizada definida por el usuario
ARRAY_INSERT	Función personalizada definida por el usuario
ARRAY_INTERSECTION	Función personalizada definida por el usuario
ARRAY_POSITION	Función personalizada definida por el usuario
ARRAY_PREPEND	Función personalizada definida por el usuario
ARRAY_SIZE	ARRAY_LENGTH
ARRAY_SLICE	Función personalizada definida por el usuario
ARRAY_TO_STRING	ARRAY_TO_STRING
ARRAYS_OVERLAP	Función personalizada definida por el usuario
AS_<object_type>	CAST
AS_ARRAY	CAST
AS_BINARY	CAST
AS_BOOLEAN	CAST
AS_CHAR , AS_VARCHAR	CAST
AS_DATE	CAST
AS_DECIMAL , AS_NUMBER	CAST
AS_DOUBLE , AS_REAL	CAST
AS_INTEGER	CAST
AS_OBJECT	CAST
AS_TIME	CAST
AS_TIMESTAMP_*	CAST
CHECK_JSON	Función personalizada definida por el usuario
CHECK_XML	Función personalizada definida por el usuario
FLATTEN	UNNEST
GET	Función personalizada definida por el usuario
GET_IGNORE_CASE	Función personalizada definida por el usuario
GET_PATH , :	Función personalizada definida por el usuario
IS_<object_type>	Función personalizada definida por el usuario
IS_ARRAY	Función personalizada definida por el usuario
IS_BINARY	Función personalizada definida por el usuario
IS_BOOLEAN	Función personalizada definida por el usuario
IS_CHAR , IS_VARCHAR	Función personalizada definida por el usuario
IS_DATE , IS_DATE_VALUE	Función personalizada definida por el usuario
IS_DECIMAL	Función personalizada definida por el usuario
IS_DOUBLE , IS_REAL	Función personalizada definida por el usuario
IS_INTEGER	Función personalizada definida por el usuario
IS_OBJECT	Función personalizada definida por el usuario
IS_TIME	Función personalizada definida por el usuario
IS_TIMESTAMP_*	Función personalizada definida por el usuario
OBJECT_CONSTRUCT	Función personalizada definida por el usuario
OBJECT_DELETE	Función personalizada definida por el usuario
OBJECT_INSERT	Función personalizada definida por el usuario
PARSE_JSON	JSON_EXTRACT
PARSE_XML	Función personalizada definida por el usuario
STRIP_NULL_VALUE	Función personalizada definida por el usuario
STRTOK_TO_ARRAY	SPLIT
TRY_PARSE_JSON	Función personalizada definida por el usuario
TYPEOF	Función personalizada definida por el usuario
XMLGET	Función personalizada definida por el usuario

Funciones binarias y de cadena

Snowflake	BigQuery
string1 || string2	CONCAT(string1, string2)
ASCII	TO_CODE_POINTS(string1)[OFFSET(0)]
BASE64_DECODE_BINARY	SAFE_CONVERT_BYTES_TO_STRING( FROM_BASE64(<bytes_input>) )
BASE64_DECODE_STRING	SAFE_CONVERT_BYTES_TO_STRING( FROM_BASE64(<string1>) )
BASE64_ENCODE	TO_BASE64( SAFE_CAST(<string1> AS BYTES) )
BIT_LENGTH	BYTE_LENGTH * 8 CHARACTER_LENGTH
CHARINDEX(substring, string)	STRPOS(string, substring)
CHR,CHAR	CODE_POINTS_TO_STRING([number])
COLLATE	Función personalizada definida por el usuario
COLLATION	Función personalizada definida por el usuario
COMPRESS	Función personalizada definida por el usuario
CONCAT(string1, string2)	CONCAT(string1, string2) Nota: CONCAT(…) de BigQuery admite la concatenación de cualquier cantidad de strings
CONTAINS	Función personalizada definida por el usuario
DECOMPRESS_BINARY	Función personalizada definida por el usuario
DECOMPRESS_STRING	Función personalizada definida por el usuario
EDITDISTANCE	Función personalizada definida por el usuario
ENDSWITH	Función personalizada definida por el usuario
HEX_DECODE_BINARY	SAFE_CONVERT_BYTES_TO_STRING( FROM_HEX(<string1>)
HEX_DECODE_STRING	SAFE_CONVERT_BYTES_TO_STRING( FROM_HEX(<string1>)
HEX_ENCODE	TO_HEX( SAFE_CAST(<string1> AS BYTES))
ILIKE	Función personalizada definida por el usuario
ILIKE ANY	Función personalizada definida por el usuario
INITCAP	INITCAP
INSERT	Función personalizada definida por el usuario
LEFT	Función definida por el usuario
LENGTH	LENGTH(expression)
LIKE	LIKE
LIKE ALL	Función personalizada definida por el usuario
LIKE ANY	Función personalizada definida por el usuario
LOWER	LOWER(string)
LPAD	LPAD(string1, length[, string2])
LTRIM	LTRIM(string1, trim_chars)
MD5,MD5_HEX	MD5(string)
MD5_BINARY	Función personalizada definida por el usuario
OCTET_LENGTH	Función personalizada definida por el usuario
PARSE_IP	Función personalizada definida por el usuario
PARSE_URL	Función personalizada definida por el usuario
POSITION	STRPOS(string, substring)
REPEAT	REPEAT(string, integer)
REPLACE	REPLACE(string1, old_chars, new_chars)
REVERSE number_characters )	REVERSE(expression)
RIGHT	Función definida por el usuario
RPAD	RPAD
RTRIM	RTRIM(string, trim_chars)
RTRIMMED_LENGTH	Función personalizada definida por el usuario
SHA1,SHA1_HEX	SHA1(string)
SHA1_BINARY	Función personalizada definida por el usuario
SHA2,SHA2_HEX	Función personalizada definida por el usuario
SHA2_BINARY	Función personalizada definida por el usuario
SOUNDEX	Función personalizada definida por el usuario
SPACE	Función personalizada definida por el usuario
SPLIT	SPLIT
SPLIT_PART	Función personalizada definida por el usuario
SPLIT_TO_TABLE	Función personalizada definida por el usuario
STARTSWITH	Función personalizada definida por el usuario
STRTOK	SPLIT(instring, delimiter)[ORDINAL(tokennum)] Nota: El argumento de string delimiter completo se usa como único delimitador. El delimitador predeterminado es una coma.
STRTOK_SPLIT_TO_TABLE	Función personalizada definida por el usuario
SUBSTR,SUBSTRING	SUBSTR
TRANSLATE	Función personalizada definida por el usuario
TRIM	TRIM
TRY_BASE64_DECODE_BINARY	Función personalizada definida por el usuario
TRY_BASE64_DECODE_STRING	SUBSTR(string, 0, integer)
TRY_HEX_DECODE_BINARY	SUBSTR(string, -integer)
TRY_HEX_DECODE_STRING	LENGTH(expression)
UNICODE	Función personalizada definida por el usuario
UPPER	UPPER

Funciones de cadena (expresiones regulares)

Snowflake	BigQuery
REGEXP	IF(REGEXP_CONTAINS,1,0)=1
REGEXP_COUNT	ARRAY_LENGTH( REGEXP_EXTRACT_ALL( source_string, pattern ) ) Si se especifica position: ARRAY_LENGTH( REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern ) ) Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
REGEXP_INSTR	IFNULL( STRPOS( source_string, REGEXP_EXTRACT( source_string, pattern) ), 0) Si se especifica position, haz lo siguiente: IFNULL( STRPOS( SUBSTR(source_string, IF(position <= 0, 1, position)), REGEXP_EXTRACT( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern) ) + IF(position <= 0, 1, position) - 1, 0) Si se especifica occurrence: IFNULL( STRPOS( SUBSTR(source_string, IF(position <= 0, 1, position)), REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern )[SAFE_ORDINAL(occurrence)] ) + IF(position <= 0, 1, position) - 1, 0) Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
REGEXP_LIKE	IF(REGEXP_CONTAINS,1,0)=1
REGEXP_REPLACE	REGEXP_REPLACE( source_string, pattern, "" ) Si se especifica replace_string: REGEXP_REPLACE( source_string, pattern, replace_string ) Si se especifica position: CASE WHEN position > LENGTH(source_string) THEN source_string WHEN position <= 0 THEN REGEXP_REPLACE( source_string, pattern, "" ) ELSE CONCAT( SUBSTR( source_string, 1, position - 1), REGEXP_REPLACE( SUBSTR(source_string, position), pattern, replace_string ) ) END Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
REGEXP_SUBSTR	REGEXP_EXTRACT( source_string, pattern ) Si se especifica position: REGEXP_EXTRACT( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern ) Si se especifica occurrence: REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern )[SAFE_ORDINAL(occurrence)] Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
RLIKE	IF(REGEXP_CONTAINS,1,0)=1

Funciones del sistema

Snowflake	BigQuery
SYSTEM$ABORT_SESSION	Función personalizada definida por el usuario
SYSTEM$ABORT_TRANSACTION	Función personalizada definida por el usuario
SYSTEM$CANCEL_ALL_QUERIES	Función personalizada definida por el usuario
SYSTEM$CANCEL_QUERY	Función personalizada definida por el usuario
SYSTEM$CLUSTERING_DEPTH	Función personalizada definida por el usuario
SYSTEM$CLUSTERING_INFORMATION	Función personalizada definida por el usuario
SYSTEM$CLUSTERING_RATIO — Deprecated	Función personalizada definida por el usuario
SYSTEM$CURRENT_USER_TASK_NAME	Función personalizada definida por el usuario
SYSTEM$DATABASE_REFRESH_HISTORY	Función personalizada definida por el usuario
SYSTEM$DATABASE_REFRESH_PROGRESS , SYSTEM$DATABASE_REFRESH_PROGRESS_BY_JOB	Función personalizada definida por el usuario
SYSTEM$GET_AWS_SNS_IAM_POLICY	Función personalizada definida por el usuario
SYSTEM$GET_PREDECESSOR_RETURN_VALUE	Función personalizada definida por el usuario
SYSTEM$LAST_CHANGE_COMMIT_TIME	Función personalizada definida por el usuario
SYSTEM$PIPE_FORCE_RESUME	Función personalizada definida por el usuario
SYSTEM$PIPE_STATUS	Función personalizada definida por el usuario
SYSTEM$SET_RETURN_VALUE	Función personalizada definida por el usuario
SYSTEM$SHOW_OAUTH_CLIENT_SECRETS	Función personalizada definida por el usuario
SYSTEM$STREAM_GET_TABLE_TIMESTAMP	Función personalizada definida por el usuario
SYSTEM$STREAM_HAS_DATA	Función personalizada definida por el usuario
SYSTEM$TASK_DEPENDENTS_ENABLE	Función personalizada definida por el usuario
SYSTEM$TYPEOF	Función personalizada definida por el usuario
SYSTEM$USER_TASK_CANCEL_ONGOING_EXECUTIONS	Función personalizada definida por el usuario
SYSTEM$WAIT	Función personalizada definida por el usuario
SYSTEM$WHITELIST	Función personalizada definida por el usuario
SYSTEM$WHITELIST_PRIVATELINK	Función personalizada definida por el usuario

Funciones de tabla

Snowflake		BigQuery
GENERATOR		Función personalizada definida por el usuario
GET_OBJECT_REFERENCES		Función personalizada definida por el usuario
RESULT_SCAN		Función personalizada definida por el usuario
VALIDATE		Función personalizada definida por el usuario

Funciones hash y de utilidad

Snowflake		BigQuery
GET_DDL		Solicitud de función
HASH		HASH es una función de propietario específica de Snowflake. No se puede traducir sin conocer la lógica subyacente usada por Snowflake.

Funciones analíticas

Snowflake		BigQuery
CONDITIONAL_CHANGE_EVENT		Función personalizada definida por el usuario
CONDITIONAL_TRUE_EVENT		Función personalizada definida por el usuario
CUME_DIST		CUME_DIST
DENSE_RANK		DENSE_RANK
FIRST_VALUE		FIRST_VALUE
LAG		LAG
LAST_VALUE		LAST_VALUE
LEAD		LEAD
NTH_VALUE		NTH_VALUE
NTILE		NTILE
PERCENT_RANK		PERCENT_RANK
RANK		RANK
RATIO_TO_REPORT		Función personalizada definida por el usuario
ROW_NUMBER		ROW_NUMBER
WIDTH_BUCKET		Función personalizada definida por el usuario

BigQuery también admite SAFE_CAST(expresión AS nombre de tipo), que muestra NULL si BigQuery no puede realizar una conversión (por ejemplo, ) SAFE_CAST(“manzana” AS INT64) muestra NULL.

Operadores

En las siguientes secciones, se enumeran los operadores de Snowflake y sus equivalentes de BigQuery.

Operadores aritméticos

En la siguiente tabla, se muestran las asignaciones entre los operadores aritméticos de Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
(Unary) (+'5')	CAST("5" AS NUMERIC)
a + b	a + b
(Unary) (-'5')	(-1) * CAST("5" AS NUMERIC) Nota: BigQuery admite menos unario estándar, pero no convierte los números enteros en formato de cadena al tipo INT64, NUMERIC o FLOAT64.
a - b	a - b
date1 - date2 date1 - 365	DATE_DIFF(date1, date2, date_part) DATE_SUB(date1, date2, date_part)
a * b	a * b
a / b	a / b
a % b	MOD(a, b)

Para ver los detalles de escala y precisión de Snowflake cuando se realizan operaciones aritméticas, consulta la documentación de Snowflake.

Operadores de comparación

Los operadores de comparación de Snowflake y los operadores de comparación de BigQuery son los mismos.

Operadores lógicos/booleanos

Los operadores lógicos/booleanos de Snowflake y operadores lógicos/booleanos de BigQuery son los mismos.

Configurar operadores

En la siguiente tabla, se muestran las asignaciones entre los operadores de conjuntos de Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
SELECT ... INTERSECT SELECT ...	SELECT ... INTERSECT DISTINCT SELECT...
SELECT ... MINUS SELECT ... SELECT ... EXCEPT SELECT … Nota: MINUS y EXCEPT son sinónimos.	SELECT ... EXCEPT DISTINCT SELECT ...
SELECT ... UNION SELECT ... SELECT ... UNION ALL SELECT ...	SELECT ... UNION DISTINCT SELECT ... SELECT ... UNION ALL SELECT ...

Operadores de subconsulta

En la siguiente tabla, se muestran las asignaciones entre los operadores de subconsulta de Snowflake con sus equivalentes de BigQuery.

Snowflake	BigQuery
SELECT ... FROM ... WHERE col <operator> ALL … SELECT ... FROM ... WHERE col <operator> ANY ...	BigQuery no admite una alternativa directa a ALL/ANY de Snowflake.
SELECT ... FROM ... WHERE [NOT] EXISTS...	SELECT ... FROM ... WHERE [NOT] EXISTS...
SELECT ... FROM ... WHERE [NOT] IN...	SELECT ... FROM ... WHERE [NOT] IN...
SELECT * FROM table1 UNION SELECT * FROM table2 EXCEPT SELECT * FROM table3	SELECT * FROM table1 UNION ALL ( SELECT * FROM table2 EXCEPT SELECT * FROM table3 ) Nota: BigQuery requiere paréntesis para separar diferentes operaciones de conjuntos. Si se repite el mismo operador de conjunto, no se necesitan los paréntesis.

Sintaxis de DML

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de administración de datos de Snowflake y de BigQuery.

Declaración INSERT

Snowflake ofrece una palabra clave DEFAULT configurable para las columnas. En BigQuery, el valor DEFAULT para las columnas que permiten valores es NULL y DEFAULT no es compatible con las columnas obligatorias. La mayoría de las declaraciones INSERT de Snowflake son compatibles con BigQuery. En la siguiente tabla, se muestran las excepciones.

Snowflake	BigQuery
INSERT [OVERWRITE] INTO table VALUES [... | DEFAULT | NULL] ... Nota: BigQuery no admite la inserción de objetos JSON con una declaración INSERT ..	INSERT [INTO] table (column1 [, ...]) VALUES (DEFAULT [, ...]) Nota: BigQuery no admite una alternativa directa al OVERWRITE de Snowflake. Utiliza DELETE en lugar de esta función.
INSERT INTO table (column1 [, ...]) SELECT... FROM ...	INSERT [INTO] table (column1, [,...]) SELECT ... FROM ...
INSERT [OVERWRITE] ALL <intoClause> ... INSERT [OVERWRITE] {FIRST | ALL} {WHEN condition THEN <intoClause>} [...] [ELSE <intoClause>] ... Nota: <intoClause> representa la INSERT statement estándar, que se enumera antes.	BigQuery no admite la tabla múltiple condicional y no condicional INSERTs.

BigQuery también admite la inserción de valores mediante una subconsulta (en la que uno de los valores se calcula mediante una subconsulta), lo cual no es compatible con Snowflake. Por ejemplo:

INSERT INTO table (column1, column2)
VALUES ('value_1', (
  SELECT column2
  FROM table2
))

Declaración COPY

Snowflake admite la copia de datos desde archivos de etapas a una tabla existente y desde una tabla a una etapa interna con nombre, una etapa externa con nombre y una ubicación externa (Amazon S3, Google Cloud Storage o Microsoft Azure).

• COPY INTO <table>
• COPY INTO <location>

BigQuery no usa el comando COPY de SQL para cargar datos, pero puedes usar cualquiera de las herramientas y opciones distintas de SQL para cargar datos en tablas de BigQuery. También puedes usar receptores de canalización de datos proporcionados en Apache Spark o Apache Beam para escribir datos en BigQuery.

Declaración UPDATE

La mayoría de las declaraciones UPDATE de Snowflake son compatibles con BigQuery. En la siguiente tabla, se muestran las excepciones.

Snowflake		BigQuery
UPDATE table SET col = value [,...] [FROM ...] [WHERE ...]		UPDATE table SET column = expression [,...] [FROM ...] WHERE TRUE Nota: Todas las declaraciones UPDATE en BigQuery requieren una palabra clave WHERE, seguida de una condición.

Declaraciones DELETE y TRUNCATE TABLE

Las declaraciones DELETE y TRUNCATE TABLE son alternativas para quitar filas de una tabla sin afectar el esquema ni los índices de esta.

En Snowflake, DELETE y TRUNCATE TABLE mantienen los datos borrados con Time Journey de Snowflake' para fines de recuperación del período de retención de datos. Sin embargo, DELETE no borra el historial de carga de archivos externos ni los metadatos de carga.

En BigQuery, la declaración DELETE debe tener una cláusula WHERE. Para obtener más información sobre DELETE en BigQuery, consulta los ejemplos de DELETEde BigQuery en la documentación del DML.

Snowflake	BigQuery
DELETE FROM table_name [USING ...] [WHERE ...] TRUNCATE [TABLE] [IF EXISTS] table_name	DELETE [FROM] table_name [alias] WHERE ... Nota: Las declaraciones DELETE de BigQuery requieren una cláusula WHERE .

Declaración MERGE

La declaración MERGE puede combinar declaraciones INSERT, UPDATE y DELETE en una sola declaración “upsert” y realizar las operaciones de forma automática. La operación MERGE debe vincular como máximo una fila de origen con cada fila de destino.

Las tablas de BigQuery tienen un límite de 1,000 declaraciones DML por día, por lo que debes consolidar de manera óptima las declaraciones INSERT, UPDATE y DELETE en una sola declaración MERGE, como se muestra en la siguiente tabla:

Snowflake	BigQuery
MERGE INTO target USING source ON target.key = source.key WHEN MATCHED AND source.filter = 'Filter_exp' THEN UPDATE SET target.col1 = source.col1, target.col1 = source.col2, ... Nota: Snowflake admite un parámetro de sesión ERROR_ON_NONDETERMINISTIC_MERGE para manejar resultados no deterministas.	MERGE target USING source ON target.key = source.key WHEN MATCHED AND source.filter = 'filter_exp' THEN UPDATE SET target.col1 = source.col1, target.col2 = source.col2, ... Nota: Todas las columnas se deben enumerar si se actualizan todas.

Declaraciones GET y LIST

La declaración GET descarga archivos de datos de una de las siguientes etapas de Snowflake en un directorio o carpeta local en una máquina cliente:

• Etapa interna con nombre
• Etapa interna para una tabla específica
• Etapa interna para el usuario actual

La declaración LIST (LS) muestra una lista de archivos que se habilitaron a etapas (es decir, se subieron desde un sistema de archivos local o se descargaron de una tabla) en una de las siguientes etapas de Snowflake:

• Etapa interna con nombre
• Etapa externa con nombre
• Etapa para una tabla específica
• Etapa para el usuario actual

BigQuery no es compatible con el concepto de etapa de pruebas y no tiene los equivalentes GET y LIST.

Declaraciones PUT y REMOVE

La declaración PUT sube (es decir, almacena en etapa intermedia) los archivos de datos desde un directorio o una carpeta local en una máquina cliente a una de las siguientes etapas de Snowflake:

• Etapa interna con nombre
• Etapa interna para una tabla específica
• Etapa interna para el usuario actual

La declaración (RM) REMOVE quita los archivos que se almacenaron en etapa intermedia en una de las siguientes etapas internas del Snowflake:

• Etapa interna con nombre
• Etapa para una tabla específica
• Etapa para el usuario actual

BigQuery no admite el concepto de almacenamiento en etapa intermedia y no tiene los equivalentes PUT y REMOVE.

Sintaxis del DDL

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de definición de datos en Snowflake y en BigQuery.

DDL de base de datos, esquema y uso compartido

La mayor parte de la terminología de Snowflake coincide con la de BigQuery, excepto que la base de datos de Snowflake es similar al conjunto de datos de BigQuery. Consulta la asignación detallada de terminología de Snowflake a BigQuery.

Declaración CREATE DATABASE

Snowflake admite la creación y administración de una base de datos a través d ecomandos de administración de bases de datos mientras que BigQuery ofrece varias opciones, como el uso de la consola, la CLI, las bibliotecas cliente, etcétera, para crear conjuntos de datos. En esta sección, se usarán los comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias.

Snowflake	BigQuery
CREATE DATABASE <name> Nota: Snowflake proporciona estos requisitos para asignar nombres a las bases de datos. Solo permite 255 caracteres en el nombre.	bq mk <name> Nota: BigQuery tiene requisitos de nombres de conjuntos de datos similares a Snowflake, excepto que permite 1,024 caracteres en el nombre.
CREATE OR REPLACE DATABASE <name>	En BigQuery, no se admite reemplazar el conjunto de datos.
CREATE TRANSIENT DATABASE <name>	No se admite la creación de un conjunto de datos temporal en BigQuery.
CREATE DATABASE IF NOT EXISTS <name>	El concepto no es compatible con BigQuery
CREATE DATABASE <name> CLONE <source_db> [ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]	Aún no se admite la clonación de conjuntos de datos en BigQuery.
CREATE DATABASE <name> DATA_RETENTION_TIME_IN_DAYS = <num>	La función de viaje en el tiempo a nivel de conjunto de datos no es compatible con BigQuery. Sin embargo, se admite la función de viaje en el tiempo para los resultados de las tablas y las consultas.
CREATE DATABASE <name> DEFAULT_DDL_COLLATION = '<collation_specification>'	La intercalación en DDL no es compatible con BigQuery.
CREATE DATABASE <name> COMMENT = '<string_literal>'	bq mk \ --description "<string_literal>" \ <name>
CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>	La creación de conjuntos de datos compartidos no es compatible con BigQuery. Sin embargo, los usuarios pueden compartir el conjunto de datos a través de la consola o la IU una vez creado el conjunto de datos.
CREATE DATABASE <name> AS REPLICA OF <region>.<account>.<primary_db_name> AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE } Nota: Snowflake ofrece la opción de mantenimiento automático en segundo plano de vistas materializadas en la base de datos secundaria que no es compatible con BigQuery.	bq mk --transfer_config \ --target_dataset = <name> \ --data_source = cross_region_copy \ --params=' {"source_dataset_id":"<primary_db_name>" ,"source_project_id":"<project_id>" ,"overwrite_destination_table":"true"}' Nota: BigQuery admite la copia de conjuntos de datos mediante el Servicio de transferencia de datos de BigQuery. Consulta aquí los requisitos previos para copiar un conjunto de datos.

BigQuery también ofrece las siguientes opciones de comando bq mk, que no tienen un análogo directo en Snowflake:

• --location <dataset_location>
• --default_table_expiration <time_in_seconds>
• --default_partition_expiration <time_in_seconds>

Declaración ALTER DATABASE

En esta sección, se usarán los comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias en las declaraciones ALTER.

Snowflake	BigQuery
ALTER DATABASE [ IF EXISTS ] <name> RENAME TO <new_db_name>	En BigQuery no se admite el cambio de nombre de conjuntos de datos, pero se admite la copia de conjuntos de datos.
ALTER DATABASE <name> SWAP WITH <target_db_name>	El intercambio de conjuntos de datos no es compatible con BigQuery.
ALTER DATABASE <name> SET [DATA_RETENTION_TIME_IN_DAYS = <num>] [ DEFAULT_DDL_COLLATION = '<value>']	En BigQuery, no se admite la administración de la retención y la intercalación de datos a nivel del conjunto de datos.
ALTER DATABASE <name> SET COMMENT = '<string_literal>'	bq update \ --description "<string_literal>" <name>
ALTER DATABASE <name> ENABLE REPLICATION TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]	El concepto no es compatible con BigQuery.
ALTER DATABASE <name> DISABLE REPLICATION [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	El concepto no es compatible con BigQuery.
ALTER DATABASE <name> SET AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE }	El concepto no es compatible con BigQuery.
ALTER DATABASE <name> REFRESH	El concepto no es compatible con BigQuery.
ALTER DATABASE <name> ENABLE FAILOVER TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]	El concepto no es compatible con BigQuery.
ALTER DATABASE <name> DISABLE FAILOVER [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	El concepto no es compatible con BigQuery.
ALTER DATABASE <name> PRIMARY	El concepto no es compatible con BigQuery.

Declaración DROP DATABASE

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando de Snowflake para abordar la diferencia en la declaración DROP.

Snowflake	BigQuery
DROP DATABASE [ IF EXISTS ] <name> [ CASCADE | RESTRICT ] Nota: En Snowflake, descartar una base de datos no la elimina de forma permanente del sistema. Se conserva una versión de la base de datos descartada durante la cantidad de días especificada por el parámetro DATA_RETENTION_TIME_IN_DAYS para la base de datos.	bq rm -r -f -d <name> Where -r permite quitar todos los objetos del conjunto de datos . -f is to skip confirmation for execution -d indica el conjunto de datos Nota: En BigQuery, la eliminación de un conjunto de datos es permanente. Además, la cascada no es compatible a nivel del conjunto de datos, ya que se borran todos los datos y objetos del conjunto de datos.

Snowflake también admite el comando UNDROP DATASET, que restablece la versión más reciente de un conjunto de datos descartado. Por el momento, esto no es compatible con BigQuery a nivel del conjunto de datos.

Declaración USE DATABASE

Snowflake proporciona la opción para configurar la base de datos para una sesión de usuario mediante el comando USE DATABASE. Esto elimina la necesidad de especificar nombres de objetos completamente calificados en los comandos de SQL. BigQuery no proporciona ninguna alternativa al comando USE DATABASE de Snowflake.

Declaración SHOW DATABASE

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando del Snowflake para abordar la diferencia en la declaración SHOW.

Snowflake	BigQuery
SHOW DATABASES Nota: Snowflake proporciona una sola opción para enumerar y mostrar detalles sobre todas las bases de datos, incluidas las bases de datos descartadas que se encuentran dentro del período de retención.	bq ls --format=prettyjson y/o bq show <dataset_name> Nota: En BigQuery, el comando ls solo proporciona información básica y nombres de conjuntos de datos, y el comando show proporciona detalles, como la marca de tiempo de la última modificación, las LCA y las etiquetas de un conjunto de datos. BigQuery también proporciona más detalles sobre los conjuntos de datos a través del esquema de información.
SHOW TERSE DATABASES Nota: Con la opción TERSE, Snowflake permite mostrar solo información o campos específicos sobre los conjuntos de datos.	El concepto no es compatible con BigQuery.
SHOW DATABASES HISTORY	El concepto de viaje en el tiempo no es compatible con BigQuery a nivel de conjunto de datos.
SHOW DATABASES [LIKE '<pattern>'] [STARTS WITH '<name_string>']	En BigQuery, no se admite el filtrado de resultados por nombres de conjuntos de datos. Sin embargo, se admite el filtrado por etiquetas.
SHOW DATABASES LIMIT <rows> [FROM '<name_string>'] Nota: De forma predeterminada, Snowflake no limita la cantidad de resultados. Sin embargo, el valor de LIMIT no puede ser superior a 10,000.	bq ls \ --max_results <rows> Nota: De forma predeterminada, BigQuery solo muestra 50 resultados.

BigQuery también ofrece las siguientes opciones de comando bq, que no tienen un análogo directo en Snowflake:

• bq ls --format=pretty: Muestra resultados con formato básico.
• *bq ls -a: *Solo muestra conjuntos de datos anónimos (los que comienzan con un guion bajo).
• bq ls --all: Muestra todos los conjuntos de datos, incluidos los anónimos.
• bq ls --filter labels.key:value: Muestra los resultados filtrados por etiqueta de conjunto de datos
• bq ls --d: Excluye los resultados del formulario de conjuntos de datos anónimos.
• bq show --format=pretty: Muestra resultados detallados con formato básico para todos los conjuntos de datos.

Administración de SCHEMA

Snowflake proporciona varios comandos de administración de esquemas similares a sus comandos de administración de bases de datos. Este concepto de creación y administración de esquemas no es compatible con BigQuery.

Sin embargo, BigQuery te permite especificar el esquema de una tabla cuando cargas datos en una tabla y cuando creas una tabla vacía. Como alternativa, puedes usar la detección automática de esquemas para los formatos de datos compatibles.

Administración de SHARE

Snowflake proporciona varios comandos de administración de recursos compartidos similares a sus comandos de administración de esquemas y base de datos. Este concepto de creación y administración de recursos compartidos no es compatible con BigQuery.

DDL de tabla, vista y secuencia

Declaración CREATE TABLE

La mayoría de las declaraciones CREATE TABLE de Snowflake son compatibles con BigQuery, excepto los siguientes elementos de la sintaxis, que no se usan en BigQuery:

Snowflake	BigQuery
CREATE TABLE table_name ( col1 data_type1 NOT NULL, col2 data_type2 NULL, col3 data_type3 UNIQUE, col4 data_type4 PRIMARY KEY, col5 data_type5 ) Nota: Las restricciones UNIQUE y PRIMARY KEY son informativas y no las aplica el sistema de Snowflake.	CREATE TABLE table_name ( col1 data_type1 NOT NULL, col2 data_type2, col3 data_type3, col4 data_type4, col5 data_type5, )
CREATE TABLE table_name ( col1 data_type1[,...] table_constraints ) en el que table_constraints son los siguientes: [UNIQUE(column_name [, ... ])] [PRIMARY KEY(column_name [, ...])] [FOREIGN KEY(column_name [, ...]) REFERENCES reftable [(refcolumn)] Nota: Las restricciones UNIQUE y PRIMARY KEY son informativas y no las aplica el sistema de Snowflake.	CREATE TABLE table_name ( col1 data_type1[,...] ) PARTITION BY column_name CLUSTER BY column_name [, ...] Nota: BigQuery no usa restricciones de tabla UNIQUE, PRIMARY KEY, FOREIGN o KEY. Para lograr una optimización similar que estas restricciones proporcionan durante la ejecución de la consulta, particiona y agrupa en clústeres tus tablas de BigQuery. CLUSTER BY admite hasta cuatro columnas.
CREATE TABLE table_name LIKE original_table_name	Consulta este ejemplo a fin de aprender a usar las tablas INFORMATION_SCHEMA para copiar nombres de columnas, tipos de datos y restricciones NOT NULL en una tabla nueva.
CREATE TABLE table_name ( col1 data_type1 ) BACKUP NO Nota: En Snowflake, la configuración BACKUP NO se especifica para “guardar el tiempo de procesamiento cuando se crean instantáneas y se restablecen a partir de las instantáneas, y para reducir el espacio de almacenamiento”.	La opción de tabla BACKUP NO no se usa ni es necesaria, ya que BigQuery conserva de forma automática hasta 7 días de versiones históricas de todas tus tablas, sin ningún efecto en el tiempo de procesamiento ni en el almacenamiento facturado.
CREATE TABLE table_name ( col1 data_type1 ) table_attributes en el que table_attributes son los siguientes: [DISTSTYLE {AUTO|EVEN|KEY|ALL}] [DISTKEY (column_name)] [[COMPOUND|INTERLEAVED] SORTKEY (column_name [, ...])]	BigQuery es compatible con el agrupamiento en clústeres, lo que permite almacenar claves en orden.
CREATE TABLE table_name AS SELECT ...	CREATE TABLE table_name AS SELECT ...
CREATE TABLE IF NOT EXISTS table_name ...	CREATE TABLE IF NOT EXISTS table_name ...

BigQuery también admite la declaración DDL CREATE OR REPLACE TABLE, que reemplaza una tabla si ya existe.

La declaración CREATE TABLE de BigQuery también admite las siguientes cláusulas, que no tienen un equivalente de Snowflake:

• PARTITION BY partition_statement
• CLUSTER BY clustering_column_list
• OPTIONS(table_options_list)

Para obtener más información sobre CREATE TABLE en BigQuery, consulta los ejemplos de CREATE de BigQuery en la documentación del DML.

Declaración ALTER TABLE

En esta sección, se usarán los comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias en las declaraciones ALTER de las tablas.

Snowflake	BigQuery
ALTER TABLE [ IF EXISTS ] <name> RENAME TO <new_name>	ALTER TABLE [IF EXISTS] <name> SET OPTIONS (friendly_name="<new_name>")
ALTER TABLE <name> SWAP WITH <target_db_name>	El intercambio de tablas no es compatible con BigQuery.
ALTER TABLE <name> SET [DEFAULT_DDL_COLLATION = '<value>']	La administración de la intercalación de datos para tablas no es compatible con BigQuery.
ALTER TABLE <name> SET [DATA_RETENTION_TIME_IN_DAYS = <num>]	ALTER TABLE [IF EXISTS] <name> SET OPTIONS (expiration_timestamp=<timestamp>)
ALTER TABLE <name> SET COMMENT = '<string_literal>'	ALTER TABLE [IF EXISTS] <name> SET OPTIONS (description='<string_literal>')

Además, Snowflake proporciona opciones de agrupamiento en clústeres, columnas y restricciones para alterar las tablas que no son compatibles con BigQuery.

Declaraciones DROP TABLE y UNDROP TABLE

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando del Snowflake para abordar la diferencia en las declaraciones DROP y UNDROP.

Snowflake	BigQuery
DROP TABLE [IF EXISTS] <table_name> [CASCADE | RESTRICT] Nota: En Snowflake, descartar una tabla no la elimina de forma permanente del sistema. Se conserva una versión de la tabla descartada durante la cantidad de días especificada por el parámetro DATA_RETENTION_TIME_IN_DAYS para la base de datos.	bq rm -r -f -d <dataset_name>.<table_name> Where -r permite quitar todos los objetos del conjunto de datos. -f permite omitir la confirmación de la ejecución. -d indica el conjunto de datos. Nota: En BigQuery, la eliminación de una tabla tampoco es permanente, pero una instantánea se mantiene solo por 7 días.
UNDROP TABLE <table_name>	bq cp \ <dataset_name>.<table_name>@<unix_timestamp> <dataset_name>.<new_table_name> Nota: En BigQuery, primero debes determinar una marca de tiempo UNIX de cuando existió la tabla (en milisegundos). Luego, copia la tabla en esa marca de tiempo a la tabla nueva. La tabla nueva debe tener un nombre distinto al de la tabla borrada.

Declaración CREATE EXTERNAL TABLE

BigQuery permite crear tablas externas permanentes y temporales y consultar datos directamente desde:

• Bigtable
• Cloud Storage
• Google Drive
• Cloud SQL (Beta)

Snowflake permite crear una tabla externa permanente que, cuando se consulta, lee datos de un conjunto de uno o más archivos en una etapa externa especificada.

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando del Snowflake para abordar las diferencias en la declaración CREATE EXTERNAL TABLE.

Snowflake	BigQuery
CREATE [OR REPLACE] EXTERNAL TABLE table ((<col_name> <col_type> AS <expr> ) | (<part_col_name> <col_type> AS <part_expr>)[ inlineConstraint ] [ , ... ] ) LOCATION = externalStage FILE_FORMAT = ({FORMAT_NAME='<file_format_name>' |TYPE=source_format [formatTypeOptions]}) Where: externalStage = @[namespace.]ext_stage_name[/path] Nota: Snowflake permite almacenar en etapa intermedia los archivos que contienen datos y especificar las opciones de tipo de formato para tablas externas. Tipos de formato Snowflake: CSV, JSON, AVRO, PARQUET y ORC son compatibles con BigQuery, excepto el tipo XML.	[1] bq mk \ --external_table_definition=definition_file \ dataset.table OR [2] bq mk \ --external_table_definition=schema_file@source_format={Cloud Storage URI | drive_URI} \ dataset.table OR [3] bq mk \ --external_table_definition=schema@source_format = {Cloud Storage URI | drive_URI} \ dataset.table Nota: BigQuery permite crear una tabla permanente vinculada a tu fuente de datos mediante un archivo de definición de tablas [1], un archivo de esquema JSON [2] o una definición de esquema intercalado [3]. BigQuery no admite el almacenamiento en estapa intermedia de los archivos que se leerán y la especificación de las opciones de tipo de formato.
CREATE [OR REPLACE] EXTERNAL TABLE [IF EXISTS] <table_name> ((<col_name> <col_type> AS <expr> ) [ , ... ] ) [PARTITION BY (<identifier>, ...)] LOCATION = externalStage [REFRESH_ON_CREATE = {TRUE|FALSE}] [AUTO_REFRESH = {TRUE|FALSE}] [PATTERN = '<regex_pattern>'] FILE_FORMAT = ({FORMAT_NAME = '<file_format_name>' | TYPE = { CSV | JSON | AVRO | ORC | PARQUET} [ formatTypeOptions]}) [COPY GRANTS] [COMMENT = '<string_literal>']	bq mk \ --external_table_definition=definition_file \ dataset.table Nota: En la actualidad, BigQuery no admite ninguna de las opciones de parámetros opcionales que proporciona Snowflake para crear tablas externas. Para la partición, BigQuery admite el uso de la seudocolumna _FILE_NAME a fin de crear tablas o vistas particionadas sobre las tablas externas. Para obtener más información, revisa Consulta la seudocolumna _FILE_NAME.

Además, BigQuery también admite consultas de datos particionados externamente en formatos AVRO, PARQUET, ORC, JSON y CSV que se almacenan en Google Cloud Storage con un diseño de partición de subárbol predeterminado.

Declaración CREATE VIEW

En la siguiente tabla, se muestran equivalencias de la declaración CREATE VIEW entre Snowflake y BigQuery.

Snowflake	BigQuery
CREATE VIEW view_name AS SELECT ...	CREATE VIEW view_name AS SELECT ...
CREATE OR REPLACE VIEW view_name AS SELECT ...	CREATE OR REPLACE VIEW view_name AS SELECT ...
CREATE VIEW view_name (column_name, ...) AS SELECT ...	CREATE VIEW view_name AS SELECT ...
No compatible	CREATE VIEW IF NOT EXISTS view_name OPTIONS(view_option_list) AS SELECT ...
CREATE VIEW view_name AS SELECT ... WITH NO SCHEMA BINDING	En BigQuery, para crear una vista, todos los objetos a los que se hace referencia ya deben existir. BigQuery te permite consultar fuentes de datos externas.

Declaración CREATE SEQUENCE

Las secuencias no se usan en BigQuery; esto se puede lograr de la siguiente manera por lotes. Para obtener más información sobre las claves subrogadas y el cambio lento de las dimensiones (SCD), consulta las siguientes guías:

• Claves subrogadas de BigQuery
• BigQuery y claves subrogadas: un enfoque práctico

INSERT INTO dataset.table SELECT *, ROW_NUMBER() OVER () AS id FROM dataset.table

DDL de carga y descarga de datos

Snowflake admite la carga y descarga de datos mediante comandos de administración de etapas, formato de archivo y canalización. BigQuery también ofrece varias opciones para eso, como bq load, el Servicio de transferencia de datos de BigQuery, bq extract, etc. En esta sección, se destacan las diferencias en el uso de estas metodologías para la carga y descarga de datos.

DDL de la cuenta y la sesión

Los conceptos de cuenta y sesión de Snowflake no son compatibles con BigQuery. BigQuery permite la administración de cuentas a través de Cloud IAM en todos los niveles. Además, las transacciones de varias declaraciones aún no son compatibles con BigQuery.

Funciones definidas por el usuario (UDF)

Una UDF te permite crear funciones para operaciones personalizadas. Estas funciones aceptan columnas de entrada, realizan acciones y muestran el resultado de esas acciones como un valor.

Snowflake y BigQuery admiten UDF mediante expresiones de SQL y código JavaScript.

Consulta el repositorio de GitHub GoogleCloudPlatform/bigquery-utils/ para ver una biblioteca de UDF comunes de BigQuery.

Sintaxis de CREATE FUNCTION

En la siguiente tabla, se abordan las diferencias que existen en la sintaxis de creación de UDF de SQL entre Snowflake y BigQuery.

Snowflake	BigQuery
CREATE [ OR REPLACE ] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition s	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) AS sql_function_definition Nota: En una UDF de SQL de BigQuery, el tipo de datos que se devuelve es opcional. BigQuery infiere el tipo de resultado de la función a partir del cuerpo de la función SQL cuando una consulta llama a la función.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS TABLE (col_name, col_data_type[,..]) AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: En la actualidad, la UDF de SQL de BigQuery no es compatible con el tipo de tabla que se muestra, pero está en la hoja de ruta del producto y estará disponible pronto. Sin embargo, BigQuery admite devolver ARRAY de tipo STRUCT.
CREATE [SECURE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: Snowflake ofrece una opción segura para restringir la definición de UDF y los detalles solo a los usuarios autorizados (es decir, usuarios a los que se les otorga el rol que posee la vista).	CREATE FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: La volatilidad de la función no es un parámetro configurable en BigQuery. BigQuery admite la creación de roles y permisos de IAM para restringir el acceso a los datos subyacentes y la definición de las funciones.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [ { CALLED ON NULL INPUT | { RETURNS NULL ON NULL INPUT | STRICT } } ] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: El comportamiento de la función para entradas nulas se maneja de forma implícita en BigQuery y no es necesario especificarlo como una opción independiente.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [VOLATILE | IMMUTABLE] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: La volatilidad de la función no es un parámetro configurable en BigQuery. Toda la volatilidad de la UDF de BigQuery es equivalente a la volatilidad IMMUTABLE de Snowflake (es decir, no realiza búsquedas en bases de datos ni usa información que no está directamente presente en su lista de argumentos).
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS [' | $$] sql_function_definition [' | $$]	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: El uso de comillas simples o una secuencia de caracteres como símbolos de ($$) no es obligatorio ni es compatible con BigQuery. BigQuery interpreta la expresión SQL de forma implícita.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [COMMENT = '<string_literal>'] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: En la actualidad, no se admite la adición de comentarios o descripciones en las UDF.
CREATE [OR REPLACE] FUNCTION function_name (x integer, y integer) RETURNS integer AS $$ SELECT x + y $$ Nota: Snowflake no admite ANY TYPE para SQL UDFs. Sin embargo, admite el uso de tipos de datos VARIANT.	CREATE [OR REPLACE] FUNCTION function_name (x ANY TYPE, y ANY TYPE) AS SELECT x + y Nota: BigQuery admite el uso de ANY TYPE como tipo de argumento. La función aceptará una entrada de cualquier tipo para este argumento. Para obtener más información, consulta Parámetro con plantilla en BigQuery.

BigQuery también admite la declaración CREATE FUNCTION IF NOT EXISTS, que trata la consulta como correcta y no realiza ninguna acción si ya existe una función con el mismo nombre.

La declaración CREATE FUNCTION de BigQuery también admite la creación de TEMPORARY or TEMP functions, que no tienen un equivalente de Snowflake. Consulta cómo llamar a las UDFs para obtener detalles sobre cómo ejecutar una UDF persistente de BigQuery.

Sintaxis de DROP FUNCTION

En la siguiente tabla, se abordan las diferencias que existen en la sintaxis de DROP FUNCTION entre Snowflake y BigQuery.

Snowflake	BigQuery
DROP FUNCTION [IF EXISTS] function_name ([arg_data_type, ... ])	DROP FUNCTION [IF EXISTS] dataset_name.function_name Nota: BigQuery no requiere el uso de la firma de la función (tipo de datos de argumento) para borrarla.

BigQuery requiere que especifiques el project_name si la función no se encuentra en el proyecto actual.

Comandos de funciones adicionales

En esta sección, se abordan los comandos de UDF adicionales compatibles con Snowflake que no están disponibles directamente en BigQuery.

Sintaxis de ALTER FUNCTION

Snowflake admite las siguientes operaciones mediante la sintaxis ALTER FUNCTION.

• Cambia el nombre de una UDF
• Convierte (o revierte de) una UDF segura
• Agrega, reemplaza o quita un comentario de una UDF

Debido a que la configuración de la seguridad de la función y la adición de comentarios de funciones no están disponibles en BigQuery, por el momento no se admite la sintaxis ALTER FUNCTION. Sin embargo, la declaración CREATE FUNCTION se puede usar para crear una UDF con la misma definición de función, pero con un nombre diferente.

Sintaxis de DESCRIBE FUNCTION

Snowflake admite la descripción de una UDF mediante el uso de la sintaxis DESC[RIBE] FUNCTION. Por el momento, esto no se admite en BigQuery. Sin embargo, pronto estará disponible la consulta de metadatos de la UDF a través de INFORMATION SCHEMA como parte de la hoja de ruta del producto.

Sintaxis de SHOW USER FUNCTIONS

En Snowflake, la sintaxis de SHOW USER FUNCTIONS se puede usar para enumerar todas las UDFs en las que los usuarios tienen privilegios de acceso. Por el momento, esto no se admite en BigQuery. Sin embargo, la consulta de metadatos de UDF a través de INFORMATION SCHEMA estará disponible pronto como parte de la hoja de ruta del producto.

Procedimientos almacenados

Los procedimientos almacenados de Snowflake se escriben en JavaScript, que puede ejecutar instrucciones de SQL mediante una llamada a una API de JavaScript. En BigQuery, los procedimientos almacenados se definen mediante un bloque de instrucciones de SQL.

Sintaxis de CREATE PROCEDURE

En Snowflake, un procedimiento almacenado se ejecuta con un comando Call mientras que en BigQuery, los procedimientos almacenados se ejecutan como cualquier otra función de BigQuery.

En la siguiente tabla, se abordan las diferencias que existen entre la sintaxis de creación de procedimientos almacenados en Snowflake y BigQuery.

Snowflake	BigQuery
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type AS procedure_definition; Nota: Snowflake requiere que los procedimientos almacenados muestren un solo valor. Por lo tanto, el tipo de datos que se muestra es una opción obligatoria.	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_mode arg_name arg_data_type[,..]]) BEGIN procedure_definition END; arg_mode: IN | OUT | INOUT Nota: BigQuery no admite un tipo de datos que se muestra para procedimientos almacenados. Además, requiere especificar el modo de argumento para cada argumento que se pasa.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type AS $$ javascript_code $$;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN statement_list END;
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [{CALLED ON NULL INPUT | {RETURNS NULL ON NULL INPUT | STRICT}}] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Nota: El comportamiento de procedimientos para entradas nulas se maneja de forma implícita en BigQuery y no es necesario especificar como una opción independiente.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [VOLATILE | IMMUTABLE] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Nota: La volatilidad de procedimiento no es un parámetro configurable en BigQuery. Es equivalente a la volatilidad IMMUTABLE de Snowflake.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [COMMENT = '<string_literal>'] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Nota: En la actualidad, no se admite la adición de comentarios o descripciones en las definiciones de procedimientos.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [EXECUTE AS { CALLER | OWNER }] AS procedure_definition; Nota: Snowflake admite la especificación del emisor o propietario del procedimiento para la ejecución	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Nota: Los procedimientos almacenados de BigQuery siempre se ejecutan como el emisor

BigQuery también admite la declaración CREATE PROCEDURE IF NOT EXISTS, que trata la consulta como correcta y no realiza ninguna acción si ya existe una función con el mismo nombre.

Sintaxis de DROP PROCEDURE

En la siguiente tabla, se abordan las diferencias que existen en la sintaxis de DROP FUNCTION entre Snowflake y BigQuery.

Snowflake	BigQuery
DROP PROCEDURE [IF EXISTS] procedure_name ([arg_data_type, ... ])	DROP PROCEDURE [IF EXISTS] dataset_name.procedure_name Nota: BigQuery no requiere el uso de la firma del procedimiento (tipo de datos de argumento) para borrarlo.

BigQuery requiere que especifiques el project_name si el procedimiento no se encuentra en el proyecto actual.

Comandos de procedimiento adicionales

Snowflake proporciona comandos adicionales, como los siguientes:ALTER PROCEDURE, DESC[RIBE] PROCEDURE y SHOW PROCEDURES para administrar los procedimientos almacenados. Por el momento, no son compatibles con BigQuery.

Instrucciones de SQL de transacciones y metadatos

Snowflake	BigQuery
BEGIN [ { WORK | TRANSACTION } ] [ NAME <name> ]; START_TRANSACTION [ name <name> ];	BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia en este documento.
COMMIT;	No se usa en BigQuery.
ROLLBACK;	No se usa en BigQuery.
SHOW LOCKS [ IN ACCOUNT ]; SHOW TRANSACTIONS [ IN ACCOUNT ]; Note: If the user has the ACCOUNTADMIN role, the user can see locks/transactions for all users in the account.	No se usa en BigQuery.

Instrucciones de SQL de varias instrucciones y varias líneas

Snowflake y BigQuery admiten transacciones (sesiones) y, por lo tanto, admiten declaraciones separadas por punto y coma que se ejecutan juntas de manera coherente. Para obtener más información, consulta Transacciones de varias declaraciones.

Columnas de metadatos para archivos almacenados en etapa intermedia

Snowflake genera metadatos de forma automática para archivos en etapas internas y externas. Estos metadatos se pueden consultar y cargar en una tabla junto con las columnas de datos regulares. Se pueden usar las siguientes columnas de metadatos:

• METADATA$FILENAME
• METADATA$FILE_ROW_NUMBER

Garantías de coherencia y aislamiento de transacción

Tanto Snowflake como BigQuery son atómicos, es decir, cumplen con el estándar ACID en un nivel por transformación en muchas filas.

Transacciones

A cada transacción de Snowflake se le asigna una hora de inicio única (incluye milisegundos) que se establece como el ID de transacción. Snowflake solo admite el nivel de aislamiento READ COMMITTED. Sin embargo, una declaración puede ver los cambios que realizó otra declaración si ambas están en la misma transacción, aunque esos cambios aún no se confirmaron. Las transacciones de Snowflake adquieren bloqueos en los recursos (tablas) cuando se modifica ese recurso. Los usuarios pueden ajustar el tiempo máximo que una declaración bloqueada esperará hasta que se agote el tiempo de espera de la declaración. Las declaraciones DML se confirman de forma automática si el parámetro AUTOCOMMIT está activado.

BigQuery también admite transacciones. BigQuery ayuda a garantizar el control de simultaneidad optimista (gana el primero en confirmarse) con el aislamiento de instantáneas, de modo que una consulta lea los últimos datos que se confirmaron antes de comenzar la consulta. Este enfoque garantiza el mismo nivel de coherencia por fila, por transformación y entre filas dentro de la misma declaración DML y evita los interbloqueos. En el caso de varias actualizaciones de DML en la misma tabla, BigQuery cambia al control de simultaneidad pesimista. Los trabajos de carga pueden ejecutarse de forma independiente por completo y agregarse a las tablas. Sin embargo, BigQuery aún no proporciona una sesión o un límite de transacción explícitos.

Revertir

Si la sesión de una transacción de Snowflake se cierra de forma inesperada antes de que la transacción se confirme o se revierta, la transacción queda en un estado desconectado. El usuario debe ejecutar SYSTEM$ABORT_TRANSACTION para anular la transacción desconectada o Snowflake revertirá la transacción desconectada después de cuatro horas inactivas. Si se produce un interbloqueo, Snowflake detecta el interbloqueo y selecciona la declaración más reciente para revertir. Si la declaración DML en una transacción abierta de manera explícita falla, los cambios se revierten, pero la transacción se mantiene abierta hasta que se confirma o se revierte. Las declaraciones DDL en Snowflake no se pueden revertir, ya que se confirman de forma automática.

BigQuery es compatible con la declaración ROLLBACK TRANSACTION. No hay una declaración ABORT en BigQuery.

Límites de bases de datos

Siempre consulta la documentación pública de BigQuery para conocer las cuotas y los límites actuales. Para aumentar las cuotas de los usuarios de gran volumen, comunícate con el equipo de Asistencia de Cloud.

Todas las cuentas de Snowflake tienen límites flexibles establecidos de forma predeterminada. Los límites flexibles se establecen durante la creación de la cuenta y pueden variar. Muchos límites flexibles de Snowflake se pueden aumentar a través del equipo de cuentas de Snowflake o un ticket de asistencia.

En la siguiente tabla, se muestra una comparación de los límites de bases de datos de Snowflake y BigQuery.

Límite	Snowflake	BigQuery
Tamaño del texto de la consulta	1 MB	1 MB
Cantidad máxima de consultas simultáneas	XS Warehouse - 8 S Warehouse - 16 M Warehouse - 32 L Warehouse - 64 XL Warehouse - 128	100