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.
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 la escala se pueden especificar según el usuario.BigQuery admite NUMERIC y BIGNUMERIC con precisión y escalamiento especificados de forma opcional dentro de ciertos límites. |
INT/INTEGER |
BIGNUMERIC |
INT/INTEGER y todos los demásINT como los tipos de datos, comoBIGINT, TINYINT, SMALLINT, BYTEINT representan un alias para elNUMBER tipo de datos en el que la precisión y la escala no se pueden especificar y siempre estánNUMBER(38, 0) |
BIGINT |
BIGNUMERIC |
|
SMALLINT |
BIGNUMERIC |
|
TINYINT |
BIGNUMERIC |
|
BYTEINT |
BIGNUMERIC |
|
FLOAT/ |
FLOAT64 |
El tipo de datos FLOAT en Snowflake establece “NaN” como > X, en el que X es cualquier valor FLOAT (distinto de “NaN” en sí).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/ 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 configura de forma predeterminada en TIMESTAMP_NTZ y 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 con tipos explícitos. Los valores son del tipo VARIANT . |
VARIANT |
JSON |
El tipo OBJECT en Snowflake no admite valores con tipos explícitos. 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 en sí. |
BigQuery también tiene los siguientes tipos de datos que no tienen un análogo de Snowflake directo:
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 | |
---|---|---|
|
|
|
Nota: Snowflake admite la creación y referencia de un alias en la misma declaración SELECT . |
|
|
|
|
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 (“”).
Cláusula FROM
Una cláusula FROM
en una consulta especifica las posibles tablas, vistas, subconsultas o funciones de tabla para usar 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 | |
---|---|---|
|
WITH table1 AS |
|
|
|
|
|
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. |
|
|
BigQuery no admite el concepto de archivos almacenados en etapa intermedia. |
|
|
BigQuery no ofrece una alternativa directa a |
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 los siguientes detalles:
Snowflake | BigQuery | |
---|---|---|
|
SELECT col1, col2 Nota: BigQuery no admite la sintaxis de (+) para JOIN s |
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 | |
---|---|---|
|
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. |
|
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. |
LATERAL JOIN . |
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 admiten GROUP
BY
,
GROUP BY
ROLLUP
,
GROUP BY GROUPING
SETS
yGROUP BY
CUBE
, mientras que las cláusulas GROUP BY
de BigQuery admiten GROUP
BY
,
GROUP BY
ALL
, GROUP
BY ROLLUP
,
GROUP BY GROUPING
SETS
yGROUP BY
CUBE
.
Snowflake
HAVING
y BigQuery
HAVING
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 | |
---|---|---|
|
|
|
|
|
|
Nota: Snowflake permite hasta 128 conjuntos de agrupación en el mismo bloque de consulta |
|
|
Nota: Snowflake permite hasta 7 elementos (128 conjuntos de agrupación) en cada cubo. |
|
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 equivalente para especificar si los valores NULL deben ser primeros o últimos en BigQuery. |
Cláusula LIMIT/FETCH
La cláusula LIMIT/FETCH
en Snowflake restringe la cantidad máxima 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 | |
---|---|---|
Nota: Se aceptan los valores $$$$ , de cadena vacía ('') NULL y se tratan como "ilimitados". El uso principal es para conectores y controladores. |
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 de forma innecesaria, empeorará el rendimiento de la ejecución de consultas. |
Cláusula QUALIFY
La cláusula QUALIFY
en Snowflake te permite filtrar resultados para funciones analíticas similares a lo que hace HAVING
con funciones agregadas y cláusulas GROUP BY
.
Snowflake | BigQuery | |
---|---|---|
|
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
Usa ARRAY_AGG() , que admite particiones más grandes:
|
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 |
---|---|
Nota: DISTINCT no tiene ningún efecto. |
|
Nota: DISTINCT no tiene ningún efecto. |
Nota: BigQuery no es compatible con APPROX_COUNT_DISTINCT con funciones analíticas. |
Nota: Snowflake no tiene la opción RESPECT NULLS |
Nota: BigQuery no es compatible con APPROX_QUANTILES con funciones analíticas. |
|
BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados. |
|
BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados. |
|
BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados. |
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. |
Nota: BigQuery no es compatible con APPROX_TOP_COUNT con funciones analíticas. |
|
BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados. |
|
BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados. |
|
BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados. |
|
Puedes usar una UDF personalizada para implementar MINHASH con funciones hash distintas de k . Otro enfoque para reducir la varianza en MINHASH es mantenerk de los valores mínimos de una función hash. En este caso, el índice de Jaccard puede aproximarse de la siguiente manera:
|
|
Es un sinónimo de APPROXIMATE_JACCARD_INDEX y se puede implementar de la misma manera. |
|
|
|
Nota: AVG de BigQuery no realiza la conversión automática en STRING . |
|
INTEGER más cercano. |
|
Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano. |
|
Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano. |
Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero. |
|
Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero. |
|
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:
Para usar OVER , puedes ejecutar lo siguiente (se proporciona un ejemplo booleano):
|
|
|
|
|
|
|
|
|
|
BigQuery no tiene una alternativa directa a GROUPING de Snowflake. Disponible a través de una función definida por el usuario. |
|
BigQuery no tiene una alternativa directa a GROUPING_ID de Snowflake. Disponible a través de una función definida por el usuario. |
|
SELECT BIT_XOR( FARM_FINGERPRINT( TO_JSON_STRING(t))) [OVER] FROM t |
Nota: Snowflake no te permite especificar la precisión. |
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... . |
Nota: Snowflake no te permite especificar la precisión. |
HLL_COUNT.INIT (expression [, precision]) |
|
HLL_COUNT.MERGE_PARTIAL (boceto) |
|
|
|
BigQuery no tiene una alternativa directa a HLL_EXPORT de Snowflake. |
|
BigQuery no tiene una alternativa directa a HLL_IMPORT de Snowflake. |
|
BigQuery no tiene una alternativa directa a KURTOSIS de Snowflake. |
|
|
Nota: Snowflake no admite la capacidad de IGNORE|RESPECT NULLS ni de LIMIT directamente en ARRAY_AGG. |
|
|
|
|
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
|
|
<code<select 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 |
|
|
|
Puedes considerar usar TO_JSON_STRING para convertir un valor en una cadena con formato JSON. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BigQuery no tiene una alternativa directa a SKEW de Snowflake. |
|
|
|
|
|
|
|
|
Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante. |
|
Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante. |
|
Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante. |
|
Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante. |
|
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:
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 |
---|---|
|
|
|
|
|
|
|
|
BITSHIFTRIGHT
|
|
Nota: Snowflake no es compatible con DISTINCT. |
|
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 |
---|---|
|
|
Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero. |
|
Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero. |
|
BOOLOR Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero. |
|
BOOLXOR Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero. |
BigQuery no tiene una alternativa directa a BOOLXOR. de Snowflake. |
|
|
Nota: Snowflake requiere al menos dos expresiones. BigQuery solo requiere una. |
|
|
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 . |
|
BigQuery no tiene una alternativa directa a EQUAL_NULL. de Snowflake. |
|
|
|
|
|
|
|
|
|
BigQuery no tiene una alternativa directa a IS [ NOT ] DISTINCT FROM. de Snowflake. |
|
|
|
BigQuery no admite tipos de datos VARIANT . |
|
|
|
|
|
|
|
|
|
REGR... de Snowflake. |
|
Nota: BigQuery no admite una alternativa directa a las funciones REGR... de Snowflake. |
|
|
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 |
---|---|
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. |
|
El concepto no se usa en BigQuery |
|
Esto muestra una tabla de nombres de proyectos. No es una comparación directa. |
|
Nota: Snowflake no aplica “()” después del comando CURRENT_DATE para cumplir con los estándares ANSI. |
Nota: CURRENT_DATE de BigQuery admite la especificación opcional de zona horaria. |
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. |
|
El concepto no se usa en BigQuery |
|
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. |
|
El concepto no se usa en BigQuery |
|
El concepto no se usa en BigQuery |
|
Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar consultas por tipo de trabajo, tipo de inicio/finalización, etcétera. |
|
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 “()”. |
|
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. |
Nota:
CURRENT_DATETIME muestra el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP muestra tipos de datos TIMESTAMP : |
INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera. |
|
Nota: Snowflake no aplica “()” después del comando CURRENT_USER para cumplir con los estándares ANSI. |
|
El concepto no se usa en BigQuery |
|
|
|
|
Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera. |
Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera. |
|
Nota: Snowflake no aplica “()” después del comando LOCALTIME para cumplir con los estándares ANSI. |
|
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 |
---|---|
|
|
|
|
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 . |
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 . |
Nota:
|
Nota:
|
Nota: Los modelos de formato de Snowflake se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT . |
Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT_DATE , FORMAT_DATETIME , FORMAT_TIME o FORMAT_TIMESTAMP . |
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 . |
Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT , FORMAT_DATETIME o FORMAT_TIMESTAMP . |
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 . |
Nota: La expresión de entrada de BigQuery puede formatearse con 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 . |
Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT. |
|
BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake. |
|
BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake. |
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 . |
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 . |
Nota: BigQuery no tiene una alternativa al tipo de datos VARIANT . |
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 . |
|
BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake. |
|
BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 |
---|---|
|
BigQuery no admite una comparación directa con NORMAL. de Snowflake. |
|
Nota: BigQuery no admite la propagación |
|
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. |
|
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). |
Nota: BigQuery muestra 122 bits aleatorios. BigQuery solo es compatible con los UUID de la versión 4. |
|
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 |
---|---|
|
|
|
Nota: source_timezone siempre es UTC en BigQuery |
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. |
|
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í
. |
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í. |
Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí
. |
Nota: BigQuery es compatible con los tipos de parte de semana(<weekday>), semana ISO y año ISO. Snowflake no lo hace. |
|
|
Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función. |
Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO. |
|
|
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í
. |
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í. |
|
|
|
|
|
|
|
Nota: Es posible que sea necesario cambiar el formato de dowString. Por ejemplo, “su” de Snowflake será “SUNDAY” en BigQuery. |
|
Nota: Es posible que sea necesario cambiar el formato de dowString. Por ejemplo, “su” de Snowflake será “SUNDAY” en BigQuery. |
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. |
|
|
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. |
|
|
Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función. |
Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO. |
|
Nota: BigQuery requiere que las marcas de tiempo se ingresen como tipos STRING . Ejemplo: "2008-12-25 15:30:00" |
|
|
Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función. |
Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO. |
Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí
. |
Nota: BigQuery es compatible con los tipos de parte de semana(<weekday>), semana ISO y año ISO. Snowflake no lo hace. |
|
|
BigQuery también ofrece las siguientes funciones de fecha y hora, que no tienen un análogo directo en Snowflake:
Esquema de información y funciones de la tabla
BigQuery no admite de manera conceptual muchas de las funciones de la tabla y el esquema de información de Snowflake. Snowflake ofrece el siguiente esquema de información y funciones de la 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 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nota: CEIL de BigQuery no admite la capacidad de indicar precisión o escalamiento. ROUND no te permite especificar para redondear. |
|
|
|
|
|
|
|
|
|
|
|
BigQuery no tiene una alternativa directa a FACTORIAL de Snowflake. Usa una función definida por el usuario. |
|
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. |
|
Nota: No es una coincidencia exacta, pero es lo suficientemente similar. |
|
|
|
Nota: La base predeterminada para LOG es 10. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 |
|
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 |
---|---|
|
|
ASCII |
|
BASE64_DECODE_BINARY |
|
BASE64_DECODE_STRING |
|
BASE64_ENCODE |
|
BIT_LENGTH |
CHARACTER_LENGTH |
|
|
CHR,CHAR |
|
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 (…) 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 |
EDIT_DISTANCE |
ENDSWITH |
Función personalizada definida por el usuario |
HEX_DECODE_BINARY |
|
HEX_DECODE_STRING |
|
HEX_ENCODE |
|
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 |
|
LIKE |
LIKE |
LIKE ALL |
Función personalizada definida por el usuario |
LIKE ANY |
Función personalizada definida por el usuario |
LOWER |
|
LPAD |
|
LTRIM |
|
|
|
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 |
|
REPEAT |
|
REPLACE |
|
REVERSE
|
|
RIGHT |
Función definida por el usuario |
RPAD |
RPAD |
RTRIM |
|
RTRIMMED_LENGTH |
Función personalizada definida por el usuario |
SHA1,SHA1_HEX |
|
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 |
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 |
|
TRY_HEX_DECODE_BINARY |
|
TRY_HEX_DECODE_STRING |
|
UNICODE |
Función personalizada definida por el usuario |
|
UPPER |
Funciones de cadena (expresiones regulares)
Snowflake | BigQuery |
---|---|
REGEXP |
|
REGEXP_COUNT |
Si se especifica position :
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 |
Si se especifica position , haz lo siguiente:
Si se especifica occurrence :
Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular. |
|
|
REGEXP_REPLACE |
Si se especifica replace_string :
Si se especifica position :
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 |
Si se especifica position :
Si se especifica 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 |
|
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
("apple"
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 |
---|---|
|
|
|
|
|
Nota: BigQuery admite menos unario estándar, pero no convierte los números enteros en formato de cadena al tipo INT64 , NUMERIC o FLOAT64 . |
|
|
|
|
|
|
|
|
|
|
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 |
---|---|
|
INTERSECT DISTINCT
|
Nota: MINUS y EXCEPT son sinónimos. |
|
|
|
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 |
---|---|
|
BigQuery no admite una alternativa directa a ALL/ANY de Snowflake. |
|
|
|
|
|
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 |
---|---|
Nota: BigQuery no admite la inserción de objetos JSON con una declaración INSERT . . |
VALUES (DEFAULT [, ...])
Nota: BigQuery no admite una alternativa directa a las funciones OVERWRITE de Snowflake. Utiliza DELETE en lugar de esta función. |
|
|
... 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).
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 | |
---|---|---|
|
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 DELETE
de BigQuery en la documentación del DML.
Snowflake | BigQuery |
---|---|
|
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 |
---|---|
Nota: Snowflake admite un parámetro de sesión ERROR_ON_NONDETERMINISTIC_MERGE para manejar resultados no deterministas. |
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 especificada
- 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 de una tabla especificada
- Etapa del usuario actual
BigQuery no admite el concepto de almacenamiento en etapa intermedia 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 especificada
- 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 de una tabla especificada
- Etapa del 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 |
---|---|
Nota: Snowflake proporciona estos requisitos para asignar nombres a las bases de datos. Solo permite 255 caracteres en el nombre. |
Nota: BigQuery tiene requisitos de nombres de conjuntos de datos similares a Snowflake, excepto que permite 1,024 caracteres en el nombre. |
|
En BigQuery, no se admite reemplazar el conjunto de datos. |
|
No se admite la creación de un conjunto de datos temporal en BigQuery. |
|
El concepto no es compatible con BigQuery |
|
Aún no se admite la clonación de conjuntos de datos en BigQuery. |
|
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. |
|
La intercalación en DDL no es compatible con BigQuery. |
|
|
|
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. |
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. |
|
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 |
---|---|
|
En BigQuery no se admite el cambio de nombre de conjuntos de datos, pero se admite la copia de conjuntos de datos. |
|
El intercambio de conjuntos de datos no es compatible con BigQuery. |
|
En BigQuery, no se admite la administración de la retención y la intercalación de datos a nivel del conjunto de datos. |
|
|
|
El concepto no es compatible con BigQuery. |
|
El concepto no es compatible con BigQuery. |
|
El concepto no es compatible con BigQuery. |
|
El concepto no es compatible con BigQuery. |
|
El concepto no es compatible con BigQuery. |
|
El concepto no es compatible con BigQuery. |
|
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 |
---|---|
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. |
-r permite quitar todos los objetos del conjunto de datos.
-d indica el conjunto de datosNota: 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 ofrece la opción de configurar la base de datos para una sesión de usuario con 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 |
---|---|
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=prettyjsony/o
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. |
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. |
El concepto de viaje en el tiempo no es compatible con BigQuery a nivel de conjunto de datos. | |
SHOW DATABASES
|
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
Nota: De forma predeterminada, Snowflake no limita la cantidad de resultados. Sin embargo, el valor de LIMIT no puede ser superior a 10,000. |
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 guión 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 con formato básico detallados para todos los conjuntos de datos.
Administración de SCHEMA
Snowflake proporciona varios comandos de administración de esquema 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 bases 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 |
---|---|
Nota: Las restricciones UNIQUE y PRIMARY KEY son informativas y no las aplica el sistema de Snowflake. |
|
en el que table_constraints son los siguientes:
Nota: Las restricciones
UNIQUE y PRIMARY KEY son informativas y no las aplica el sistema de Snowflake. |
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. |
|
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. |
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. |
en el que table_attributes son los siguientes:
|
BigQuery es compatible con el agrupamiento en clústeres, lo que permite almacenar claves en orden. |
|
|
|
|
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:
Para obtener más información sobre CREATE TABLE
en BigQuery, consulta los ejemplos de sentencias CREATE TABLE
en la documentación del DDL.
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 |
---|---|
|
|
|
El intercambio de tablas no es compatible con BigQuery. |
|
La administración de la intercalación de datos para tablas no es compatible con BigQuery. |
|
|
|
|
Además, Snowflake proporciona opciones de agrupamiento en clústeres, columnas y restricciones para modificar 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 |
---|---|
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. |
-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. |
|
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 los siguientes recursos:
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
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. |
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. |
|
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 para crear tablas o vistas particionadas sobre las tablas externas. Para obtener más información, visita
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 OR REPLACE VIEW
|
|
|
No compatible | CREATE VIEW IF NOT EXISTS
|
|
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:
|
---|
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 obtener 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 |
---|---|
|
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. |
|
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. |
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). |
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. |
|
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. |
|
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
Nota: Usar comillas simples o una secuencia de caracteres como símbolos de dólares$$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression. |
|
Note:Adding comments or descriptions in UDFs is currently not supported in BigQuery. |
|
Note: BigQuery supports using ANY TYPE as argument type. The function will accept an input of any type for this argument. For more information, see templated parameter in BigQuery. |
BigQuery also supports the CREATE FUNCTION IF NOT EXISTS
statement
which treats the query as successful and takes no action if a function with the
same name already exists.
BigQuery's CREATE FUNCTION
statement also supports creating
TEMPORARY or TEMP functions
,
which do not have a Snowflake equivalent. See
calling UDFs
for details on executing a BigQuery persistent UDF.
DROP FUNCTION
syntax
The following table addresses differences in DROP FUNCTION syntax between Snowflake and BigQuery.
Snowflake | BigQuery |
---|---|
|
Note: BigQuery does not require using the function's signature (argument data type) for deleting the function. |
BigQuery requires that you specify the project_name
if
the function is not located in the current project.
Additional function commands
This section covers additional UDF commands supported by Snowflake that are not directly available in BigQuery.
ALTER FUNCTION
syntax
Snowflake supports the following operations using
ALTER FUNCTION
syntax.
- Renaming a UDF
- Converting to (or reverting from) a secure UDF
- Adding, overwriting, removing a comment for a UDF
As configuring function security and adding function comments is not available in BigQuery, ALTER FUNCTION syntax is currently not supported. However, the CREATE FUNCTION statement can be used to create a UDF with the same function definition but a different name.
DESCRIBE FUNCTION
syntax
Snowflake supports describing a UDF using DESC[RIBE] FUNCTION syntax. This is currently not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.
SHOW USER FUNCTIONS
syntax
In Snowflake, SHOW USER FUNCTIONS syntax can be used to list all UDFs for which users have access privileges. This is currently not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.
Stored procedures
Snowflake stored procedures are written in JavaScript, which can execute SQL statements by calling a JavaScript API. In BigQuery, stored procedures are defined using a block of SQL statements.
CREATE PROCEDURE
syntax
In Snowflake, a stored procedure is executed with a CALL command while in BigQuery, stored procedures are executed like any other BigQuery function.
The following table addresses differences in stored procedure creation syntax between Snowflake and BigQuery.
Snowflake | BigQuery |
---|---|
Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option. |
CREATE [OR REPLACE] PROCEDURE
Note: BigQuery doesn't support a return type for stored procedures. Also, it requires specifying argument mode for each argument passed. |
|
|
|
CREATE [OR REPLACE] PROCEDURE
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
|
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
|
Nota: En la actualidad, no se admite la adición de comentarios o descripciones en las definiciones de procedimientos. |
CREATE [OR REPLACE] PROCEDURE
Nota: Snowflake admite la especificación del emisor o propietario del procedimiento para la ejecución |
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 |
---|---|
|
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 |
---|---|
|
BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia en este documento. |
|
No se usa en BigQuery. |
|
No se usa en BigQuery. |
|
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:
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 |