Guia de tradução de SQL do Snowflake

Neste documento, detalhamos as semelhanças e diferenças de sintaxe de SQL entre o Snowflake e o BigQuery para acelerar o planejamento e a execução da migração do armazenamento de dados corporativos (EDW, na sigla em inglês) para o BigQuery. O armazenamento de dados do Snowflake foi projetado para funcionar com a sintaxe de SQL específica do Snowflake. Os scripts criados para o Snowflake talvez precisem ser alterados antes de serem usados no BigQuery, porque os dialetos de SQL variam entre os serviços. Use a tradução de SQL em lote para migrar seus scripts SQL em massa ou a tradução de SQL interativo para traduzir consultas ad hoc. O SQL do Snowflake é compatível com as duas ferramentas na prévia.

Tipos de dados

Esta seção mostra os equivalentes entre os tipos de dados do Snowflake e do BigQuery.



Snowflake BigQuery Observações
NUMBER/ DECIMAL/NUMERIC NUMERIC/BIGNUMERIC Pode ser mapeado como NUMERIC ou BIGNUMERIC, dependendo da precisão e da escala.

O tipo de dados NUMBER do Snowflake aceita 38 dígitos de precisão e 37 dígitos de escala. A precisão e a escala podem ser especificadas de acordo com o usuário.

O BigQuery é compatível com NUMERIC e BIGNUMERIC com precisão e escala especificadas opcionalmente dentro de determinados limites.
INT/INTEGER BIGNUMERIC INT/INTEGER e todos os outros tipos de dados semelhantes a INT, como BIGINT, TINYINT, SMALLINT, BYTEINT, representam um alias para o tipo de dados NUMBER em que a precisão e a escala não podem ser especificadas e são sempre NUMBER(38, 0)

O BigQuery converte INTEGER em INT64 por padrão. Para configurar a tradução de SQL e convertê-la em outros tipos de dados, use a opção de configuração REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER.
BIGINT BIGNUMERIC
SMALLINT BIGNUMERIC
TINYINT BIGNUMERIC
BYTEINT BIGNUMERIC
FLOAT/
FLOAT4/
FLOAT8		 FLOAT64 O tipo de dados FLOAT do Snowflake estabelece "NaN" como > X, em que X é qualquer valor FLOAT diferente de "NaN".

O tipo de dados FLOAT do BigQuery estabelece "NaN" como < X, em que X é qualquer valor FLOAT diferente de "NaN".
DOUBLE/
DOUBLE PRECISION/
REAL		 FLOAT64 O tipo de dados DOUBLE do Snowflake é equivalente ao tipo FLOAT do Snowflake, mas geralmente é exibido incorretamente como FLOAT. Ele é armazenado corretamente como DOUBLE.
VARCHAR STRING O tipo de dados VARCHAR do Snowflake tem um tamanho máximo de 128 MB, não compactado. Se o tamanho não estiver especificado, o padrão é o tamanho máximo.

O tipo de dados STRING do BigQuery é armazenado como Unicode codificado em UTF-8 de tamanho variável. Para mais informações sobre limites de colunas e linhas, consulte Jobs de consulta.
CHAR/CHARACTER STRING
STRING/TEXT STRING O tipo de dados STRING do Snowflake é equivalente ao VARCHAR do Snowflake.
BINARY BYTES
VARBINARY BYTES
BOOLEAN BOOL O tipo de dados BOOL do BigQuery só aceita TRUE/FALSE, ao contrário do tipo de dados BOOL do Snowflake, que aceita TRUE/FALSE/NULL.
DATE DATE O tipo DATE do Snowflake aceita os formatos de data mais comuns, ao contrário do tipo DATE do BigQuery, que aceita apenas datas no formato YYYY-[M]M-[D]D.
TIME TIME O tipo TIME do Snowflake aceita de 0 a 9 nanossegundos de precisão, enquanto o tipo TIME do BigQuery aceita de 0 a 6 nanossegundos de precisão.
TIMESTAMP DATETIME TIMESTAMP é um alias configurável pelo usuário que tem como padrão TIMESTAMP_NTZ, mapeado para DATETIME no BigQuery.
TIMESTAMP_LTZ TIMESTAMP
TIMESTAMP_NTZ/DATETIME
DATETIME
TIMESTAMP_TZ TIMESTAMP
OBJECT JSON
VARIANT JSON
ARRAY ARRAY<JSON> O serviço de tradução de SQL preserva o tipo de dados para matrizes tipadas. Para matrizes sem tipo, como ARRAY<VARIANT>, o BigQuery as converte em ARRAY<JSON>

O BigQuery também tem os seguintes tipos de dados que não têm um análogo direto do Snowflake:

Sintaxe de CREATE FUNCTION

A tabela a seguir aborda as diferenças da sintaxe de criação de UDF em SQL entre o Snowflake e o 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


Observação: na UDF em SQL do BigQuery, o tipo de dados retornados é opcional. O BigQuery infere o tipo de resultado da função a partir do corpo da função do SQL, quando uma consulta chama a função.

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


Observação:na UDF em SQL do BigQuery, retornar tipo de tabela não é compatível, mas está na estratégia do produto para ser disponibilizado em breve. No entanto, o BigQuery aceita o retorno de ARRAY do tipo STRUCT.

CREATE [SECURE] FUNCTION

function_name

([sql_arg_name sql_arg_data_type[,..]])

RETURNS data_type

AS sql_function_definition


Observação: o Snowflake oferece uma opção segura para restringir a definição de UDF e os detalhes apenas a usuários autorizados, ou seja, usuários que recebem o papel que é proprietário da visualização.

CREATE FUNCTION

function_name

([sql_arg_name sql_arg_data_type[,..]])

RETURNS data_type

AS sql_function_definition


Observação: a segurança de função não é um parâmetro configurável no BigQuery. O BigQuery permite a criação de papéis e permissões de IAM para restringir o acesso a dados subjacentes e definição de função.

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


Observação: o comportamento da função para entradas nulas é processado implicitamente no BigQuery e não precisa ser especificado como uma opção separada.

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


Observação: a volatilidade de função não é um parâmetro configurável no BigQuery. Toda a volatilidade de UDF no BigQuery é equivalente à volatilidade de IMMUTABLE do Snowflake, ou seja, ele não faz pesquisas no banco de dados nem usa informações que não estejam diretamente presentes na 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


Observação: use aspas simples ou uma sequência de caracteres, como aspas de dólar ($$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression.

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


Note: Adding comments or descriptions in UDFs is not supported in BigQuery.

CREATE [OR REPLACE] FUNCTION function_name

(x integer, y integer)

RETURNS integer

AS $$

SELECT x + y

$$


Note: Snowflake does not support ANY TYPE for SQL UDFs. However, it supports using VARIANT data types.

CREATE [OR REPLACE] FUNCTION function_name

(x ANY TYPE, y ANY TYPE)

AS

SELECT x + y



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 EXISTSstatement which treats the query as successful and takes no action if a function with the same name already exists.

BigQuery's CREATE FUNCTIONstatement 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

DROP FUNCTION [IF EXISTS]

function_name

([arg_data_type, ... ])

DROP FUNCTION [IF EXISTS] dataset_name.function_name


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 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 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 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

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

AS procedure_definition;


Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option.		 CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_mode arg_name arg_data_type[,..]])

BEGIN

procedure_definition

END;


arg_mode: IN | OUT | INOUT


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

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;


Observação: o comportamento do procedimento para entradas nulas é processado implicitamente no BigQuery e não precisa ser especificado como uma opção separada.
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;


Observação: a volatilidade de função não é um parâmetro configurável no BigQuery. É equivalente à volatilidade IMMUTABLE do 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;


Observação: não é possível adicionar comentários ou descrições em definições de procedimento no BigQuery.
CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

[EXECUTE AS { CALLER | OWNER }]

AS procedure_definition;


Observação: o Snowflake permite especificar o autor da chamada ou o proprietário do procedimento para execução.

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

BEGIN

procedure_definition

END;


Observação: os procedimentos armazenados no BigQuery são sempre executados como o autor da chamada.

O BigQuery também oferece suporte à instrução CREATE PROCEDURE IF NOT EXISTS, que trata a consulta como bem-sucedida e não realiza nenhuma ação se já houver uma função com o mesmo nome.

Sintaxe de DROP PROCEDURE

A tabela a seguir mostra as diferenças da sintaxe DROP FUNCTION do Snowflake e do BigQuery.

Snowflake BigQuery

DROP PROCEDURE [IF EXISTS]

procedure_name

([arg_data_type, ... ])

DROP PROCEDURE [IF EXISTS] dataset_name.procedure_name


Observação: o BigQuery não exige a assinatura do procedimento (tipo de dados de argumento) para excluir o procedimento.

O BigQuery exige que você especifique o project_name se o procedimento não estiver localizado no projeto atual.

Outros comandos de procedimento

O Snowflake fornece outros comandos, como ALTER PROCEDURE, DESC[RIBE] PROCEDURE e SHOW PROCEDURES, para gerenciamento de procedimentos armazenados. Eles não são aceitos no BigQuery.

Instruções SQL de metadados e transações

Snowflake BigQuery

BEGIN [ { WORK | TRANSACTION } ] [ NAME <name> ]; START_TRANSACTION [ name <name> ];

O BigQuery sempre usa o isolamento de snapshot. Para conferir detalhes, consulte Garantias de consistência em outras partes deste documento.

COMMIT;

Não usado no BigQuery.

ROLLBACK;

Não usado no 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.

Não usado no BigQuery.

Instruções SQL com várias instruções e linhas

O Snowflake e o BigQuery aceitam transações (sessões) e, portanto, são compatíveis com instruções separadas por ponto e vírgula que são executadas consistentemente em conjunto. Para mais informações, consulte Transações de várias instruções.

Colunas de metadados para arquivos preparados

O Snowflake gera metadados automaticamente para arquivos em estágios internos e externos. Esses metadados podem ser consultados e carregados em uma tabela com as colunas de dados comuns. As colunas de metadados a seguir podem ser utilizadas:

Garantias de consistência e isolamento da transação

O Snowflake e o BigQuery são atômicos, ou seja, estão em conformidade com ACID (na sigla em inglês) em um nível por mutação em muitas linhas.

Transações

Cada transação do Snowflake recebe um horário de início exclusivo (inclui milissegundos), que é definido como o ID da transação. O Snowflake só aceita o nível de isolamento READ COMMITTED. No entanto, uma instrução pode acessar as alterações feitas por outra instrução se ambas estiverem na mesma transação, mesmo que essas alterações ainda não tenham sido confirmadas. As transações do Snowflake adquirem bloqueios em recursos (tabelas) quando eles estão sendo modificados. Os usuários podem ajustar o tempo máximo que uma instrução bloqueada deve aguardar até que a instrução expire. As instruções DML serão confirmadas automaticamente se o parâmetro AUTOCOMMIT estiver ativado.

O BigQuery também tem suporte a transações. O BigQuery ajuda a garantir o controle de simultaneidade otimista (ganha o primeiro que confirmar) com o isolamento de snapshot, em que uma consulta lê os últimos dados confirmados antes do início da consulta. Essa abordagem garante o mesmo nível de consistência por linha, por mutação e em todas as linhas da mesma instrução DML, evitando impasses. No caso de várias atualizações de DML na mesma tabela, o BigQuery alterna para controle de simultaneidade pessimista. Os jobs de carregamento podem ser executados de forma totalmente independente e anexados às tabelas. No entanto, o BigQuery não fornece um limite de transação ou sessão explícita.

Reversão

Se uma sessão de transação do Snowflake for encerrada inesperadamente antes de uma confirmação ou reversão, a transação ficará em um estado removido. O usuário precisa executar SYSTEM$ABORT_TRANSACTION para cancelar a transação removida. Caso contrário, o Snowflake reverte a transação removida após quatro horas de inatividade. Se ocorrer um impasse, o Snowflake detecta o impasse e seleciona a instrução mais recente para reverter. Se a instrução DML de uma transação explicitamente aberta falhar, as alterações são revertidas, mas a transação é mantida aberta até que seja confirmada ou revertida. As instruções DDL do Snowflake não podem ser revertidas porque são confirmadas automaticamente.

O BigQuery oferece suporte à instrução ROLLBACK TRANSACTION. Não há instrução ABORT no BigQuery.

Limites de bancos de dados

Sempre verifique as cotas e os limites mais recentes na documentação pública do BigQuery. Muitas cotas para usuários de grandes volumes podem ser geradas entrando em contato com a equipe de suporte do Cloud.

Todas as contas do Snowflake têm limites flexíveis definidos por padrão. Os limites flexíveis são definidos durante a criação da conta e podem variar. Muitos limites flexíveis do Snowflake podem ser aumentados pela equipe de conta do Snowflake ou por um tíquete de suporte.

A tabela a seguir mostra uma comparação dos limites de banco de dados do Snowflake e do BigQuery.

Limite Snowflake BigQuery
Tamanho do texto da consulta 1 MB 1 MB
Número máximo de consultas simultâneas XS Warehouse - 8
S Warehouse - 16
M Warehouse - 32
L Warehouse - 64
XL Warehouse - 128		 100