Esta página foi traduzida pela API Cloud Translation.

Transforme traduções de SQL com ficheiros YAML de configuração

Este documento mostra como usar ficheiros YAML de configuração para transformar código SQL ao migrá-lo para o BigQuery. Fornece diretrizes para criar os seus próprios ficheiros YAML de configuração e exemplos de várias transformações de tradução suportadas por esta funcionalidade.

Quando usa o tradutor de SQL interativo do BigQuery, usa a API BigQuery Migration ou faz uma tradução de SQL em lote, pode fornecer ficheiros YAML de configuração para modificar uma tradução de consulta SQL. A utilização de ficheiros YAML de configuração permite uma maior personalização quando traduz consultas SQL da base de dados de origem.

Pode especificar um ficheiro YAML de configuração para usar numa tradução de SQL das seguintes formas:

Se estiver a usar o tradutor de SQL interativo, especifique o caminho do ficheiro para o ficheiro de configuração ou o ID da tarefa de tradução em lote nas definições de tradução.
Se estiver a usar a API BigQuery Migration, coloque o YAML de configuração no mesmo contentor do Cloud Storage que os ficheiros SQL de entrada.
Se estiver a fazer uma tradução SQL em lote, coloque o YAML de configuração no mesmo contentor do Cloud Storage que os ficheiros SQL de entrada.
Se estiver a usar o cliente Python de tradução em lote, coloque o ficheiro YAML de configuração na pasta de entrada de tradução local.

O tradutor de SQL interativo, a API BigQuery Migration, o tradutor de SQL em lote e o cliente Python de tradução em lote suportam a utilização de vários ficheiros YAML de configuração num único trabalho de tradução. Consulte o artigo Aplicar várias configurações YAML para mais informações.

Requisitos do ficheiro YAML de configuração

Antes de criar um ficheiro YAML de configuração, reveja as seguintes informações para garantir que o ficheiro YAML é compatível com o serviço de migração do BigQuery:

Tem de carregar os ficheiros YAML de configuração para o diretório raiz do contentor do Cloud Storage que contém os seus ficheiros de entrada de tradução SQL. Para ver informações sobre como criar contentores e carregar ficheiros para o Cloud Storage, consulte os artigos Crie contentores e Carregue objetos a partir de um sistema de ficheiros.
O tamanho do ficheiro de um único ficheiro YAML de configuração não pode exceder 1 MB.
O tamanho total dos ficheiros YAML de configuração usados num único trabalho de tradução de SQL não pode exceder 4 MB.
Se estiver a usar a sintaxe regex para a correspondência de nomes, use RE2/J.
Todos os nomes de ficheiros YAML de configuração têm de incluir uma extensão .config.yaml, por exemplo, change-case.config.yaml.
- config.yaml não é um nome válido para o ficheiro de configuração.

Diretrizes para criar um ficheiro YAML de configuração

Esta secção fornece algumas diretrizes gerais para criar um ficheiro YAML de configuração:

Cada ficheiro de configuração tem de conter um cabeçalho que especifique o tipo de configuração. O tipo object_rewriter é usado para especificar traduções de SQL num ficheiro YAML de configuração. O exemplo seguinte usa o object_rewritertipo para transformar a capitalização de um nome:

type: object_rewriter
global:
  case:
    all: UPPERCASE

Seleção de entidades

Para fazer transformações específicas da entidade, especifique a entidade no ficheiro de configuração. Todas as propriedades match são opcionais. Use apenas as propriedades match necessárias para uma transformação. A configuração YAML seguinte expõe propriedades a serem correspondidas para selecionar entidades específicas:

match:
  database: <literal_name>
  schema: <literal_name>
  relation: <literal_name>
  attribute: <literal_name>
  databaseRegex: <regex>
  schemaRegex: <regex>
  relationRegex: <regex>
  attributeRegex: <regex>

Descrição de cada propriedade match:

database ou db: o componente project_id.
schema: o componente do conjunto de dados.
relation: o componente de tabela.
attribute: o componente de coluna. Válido apenas para a seleção de atributos
databaseRegex ou dbRegex: corresponde a uma propriedade database com uma expressão regular (pré-visualização).
schemaRegex: faz corresponder as propriedades schema a expressões regulares (pré-visualização).
relationRegex: corresponde às propriedades relation com expressões regulares (pré-visualização).
attributeRegex: corresponde às propriedades attribute com expressões regulares. Apenas válido para a seleção de atributos (Pré-visualização).

Por exemplo, o YAML de configuração seguinte especifica as matchpropriedades para selecionar a tabela testdb.acme.employee para uma transformação de tabela temporária.

type: object_rewriter
relation:
-
  match:
    database: testdb
    schema: acme
    relation: employee
  temporary: true

Pode usar as propriedades databaseRegex, schemaRegex, relationRegex e attributeRegex para especificar expressões regulares de modo a selecionar um subconjunto de entidades. O exemplo seguinte altera todas as relações do esquema tmp_schema em testdb para temporárias, desde que o respetivo nome comece por tmp_:

type: object_rewriter
relation:
-
  match:
    schema: tmp_schema
    relationRegex: "tmp_.*"
  temporary: true

As propriedades literais e regex são correspondidas de forma não sensível a maiúsculas e minúsculas. Pode aplicar a correspondência sensível a maiúsculas e minúsculas através de um regex com uma flag i desativada, como no exemplo seguinte:

match:
  relationRegex: "(?-i:<actual_regex>)"

Também pode especificar entidades totalmente qualificadas através de uma sintaxe de string curta equivalente. Uma sintaxe de string curta espera exatamente 3 (para seleção de relações) ou 4 (para seleção de atributos) segmentos de nomes delimitados com pontos, como no exemplo testdb.acme.employee. Os segmentos são, depois, interpretados internamente como se tivessem sido transmitidos como database, schema, relation e attribute, respetivamente. Isto significa que a correspondência dos nomes é feita literalmente, pelo que as expressões regulares não são permitidas na sintaxe abreviada. O exemplo seguinte mostra a utilização da sintaxe de string curta para especificar uma entidade totalmente qualificada num ficheiro YAML de configuração:

type: object_rewriter
relation:
-
  match : "testdb.acme.employee"
  temporary: true

Se uma tabela contiver um ponto no nome, não pode especificar o nome através de uma sintaxe curta. Neste caso, tem de usar uma correspondência de objetos. O exemplo seguinte altera a tabela testdb.acme.stg.employee para temporária:

type: object_rewriter
relation:
-
  match:
    database: testdb
    schema: acme
    relation: stg.employee
  temporary: true

O YAML de configuração aceita key como um alias de match.

Base de dados predefinida

Alguns dialetos SQL de entrada, nomeadamente o Teradata, não suportam database-name no nome qualificado. Neste caso, a forma mais fácil de fazer a correspondência de entidades é omitir a propriedade database em match.

No entanto, pode definir a propriedade default_database do serviço de migração do BigQuery e usar essa base de dados predefinida no match.

Tipos de atributos de destino suportados

Pode usar o ficheiro YAML de configuração para fazer transformações do tipo de atributo, em que transforma o tipo de dados de uma coluna do tipo de origem num tipo de destino. O ficheiro YAML de configuração suporta os seguintes tipos de alvos:

BOOLEAN
TINYINT
SMALLINT
INTEGER
BIGINT
FLOAT
DOUBLE
NUMERIC (Suporta precisão e escala opcionais, como NUMERIC(18, 2))
TIME
TIMETZ
DATE
DATETIME
TIMESTAMP
TIMESTAMPTZ
CHAR (Suporta precisão opcional, como CHAR(42))
VARCHAR (Suporta precisão opcional, como VARCHAR(42))

Exemplos de YAML de configuração

Esta secção fornece exemplos para criar vários ficheiros YAML de configuração para usar com as suas traduções de SQL. Cada exemplo descreve a sintaxe YAML para transformar a tradução SQL de formas específicas, juntamente com uma breve descrição. Cada exemplo também fornece o conteúdo de um ficheiro teradata-input.sql ou hive-input.sql e um ficheiro bq-output.sql para que possa comparar os efeitos de um YAML de configuração numa tradução de consulta SQL do BigQuery.

Os exemplos seguintes usam o Teradata ou o Hive como o dialeto de SQL de entrada e o SQL do BigQuery como o dialeto de saída. Os exemplos seguintes também usam testdb como a base de dados predefinida e testschema como o caminho de pesquisa do esquema.

Alterar a capitalização do nome do objeto

A seguinte configuração YAML altera as letras maiúsculas ou minúsculas dos nomes dos objetos:

type: object_rewriter
global:
  case:
    all: UPPERCASE
    database: LOWERCASE
    attribute: LOWERCASE

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int); select * from x;
`bq-output.sql`	CREATE TABLE testdb.TESTSCHEMA.X ( a INT64 ) ; SELECT X.a FROM testdb.TESTSCHEMA.X ;

Torne a tabela temporária

A seguinte configuração YAML altera uma tabela normal para uma tabela temporária:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    temporary: true

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int);
`bq-output.sql`	CREATE TEMPORARY TABLE x ( a INT64 ) ;

Torne a tabela efémera

A seguinte configuração YAML altera uma tabela normal para uma tabela efémera com um prazo de validade de 60 segundos.

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    ephemeral:
      expireAfterSeconds: 60

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( expiration_timestamp=timestamp_add(current_timestamp(), interval 60 SECOND) );

Defina a validade da partição

A seguinte configuração YAML altera a expiração de uma tabela particionada para 1 dia:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    partitionLifetime:
      expireAfterSeconds: 86400

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int, b int) partition by (a);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a INT64, b INT64 ) CLUSTER BY a OPTIONS( partition_expiration_days=1 );

Altere a localização ou o formato externo de uma tabela

A seguinte configuração YAML altera a localização e a formação externas de uma tabela:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    external:
      locations: "gs://path/to/department/files"
      format: ORC

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int);
`bq-output.sql`	CREATE EXTERNAL TABLE testdb.testschema.x ( a INT64 ) OPTIONS( format='ORC', uris=[ 'gs://path/to/department/files' ] );

Defina ou altere a descrição da tabela

O YAML de configuração seguinte define a descrição de uma tabela:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    description:
      text: "Example description."

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( description='Example description.' );

Defina ou altere a partição de tabelas

A seguinte configuração YAML altera o esquema de partição de uma tabela:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    partition:
      simple:
        add: [a]
  -
    match: "testdb.testschema.y"
    partition:
      simple:
        remove: [a]

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

teradata-input.sql

    create table x(a date, b int);
    create table y(a date, b int) partition by (a);

bq-output.sql

    CREATE TABLE testdb.testschema.x
    (
      a DATE,
      b INT64
    )
    PARTITION BY a;
    CREATE TABLE testdb.testschema.y
    (
      a DATE,
      b INT64
    )
    ;

Defina ou altere o agrupamento de tabelas

A seguinte configuração YAML altera o esquema de agrupamento de uma tabela:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    clustering:
      add: [a]
  -
    match: "testdb.testschema.y"
    clustering:
      remove: [b]

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

hive-input.sql

    create table x(a int, b int);
    create table y(a int, b int) clustered by (b) into 16 buckets;

bq-output.sql

    CREATE TABLE testdb.testschema.x
    (
      a INT64,
      b INT64
    )
    CLUSTER BY a;
    CREATE TABLE testdb.testschema.y
    (
      a INT64,
      b INT64
    )
    ;

Altere o tipo de um atributo de coluna

A seguinte configuração YAML altera o tipo de dados de um atributo de uma coluna:

type: object_rewriter
attribute:
  -
    match:
      database: testdb
      schema: testschema
      attributeRegex: "a+"
    type:
      target: NUMERIC(10,2)

Pode transformar o tipo de dados de origem em qualquer um dos tipos de atributos de destino suportados.

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int, b int, aa int);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a NUMERIC(31, 2), b INT64, aa NUMERIC(31, 2) ) ;

Adicione uma associação a um data lake externo

A configuração YAML seguinte marca a tabela de origem como uma tabela externa que aponta para dados armazenados num data lake externo, especificado por uma ligação de data lake.

type: object_rewriter
relation:
-
  key: "testdb.acme.employee"
  external:
    connection_id: "connection_test"

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`hive-input.sql`	CREATE TABLE x ( a VARCHAR(150), b INT );
`bq-output.sql`	CREATE EXTERNAL TABLE x ( a STRING, b INT64 ) WITH CONNECTION `connection_test` OPTIONS( );

Altere a codificação de carateres de um ficheiro de entrada

Por predefinição, o serviço de migração do BigQuery tenta detetar automaticamente a codificação de carateres dos ficheiros de entrada. Nos casos em que o serviço de migração do BigQuery pode identificar incorretamente a codificação de um ficheiro, pode usar uma configuração YAML para especificar explicitamente a codificação de carateres.

O YAML de configuração seguinte especifica a codificação de caracteres explícita do ficheiro de entrada como ISO-8859-1.

type: experimental_input_formats
formats:
- source:
    pathGlob: "*.sql"
  contents:
    raw:
      charset: iso-8859-1

Conversão de tipo global

A seguinte configuração YAML altera um tipo de dados para outro em todos os scripts e especifica um tipo de dados de origem a evitar no script transpilado. Isto é diferente da configuração Alterar o tipo de um atributo de coluna, em que apenas o tipo de dados de um único atributo é alterado.

O BigQuery suporta as seguintes conversões de tipos de dados:

DATETIME a TIMESTAMP
TIMESTAMP para DATETIME (aceita fuso horário opcional)
TIMESTAMP WITH TIME ZONE para DATETIME (aceita fuso horário opcional)
CHAR a VARCHAR

No exemplo seguinte, o YAML de configuração converte um TIMESTAMP tipo de dados em DATETIME.

type: experimental_object_rewriter
global:
  typeConvert:
    timestamp: DATETIME

Em dialetos como o Teradata, as funções relacionadas com data/hora, como current_date, current_time ou current_timestamp, devolvem indicações de tempo com base no fuso horário configurado, seja local ou de sessão. Por outro lado, o BigQuery devolve sempre datas/horas em UTC. Para garantir um comportamento consistente entre os dois dialetos, é necessário configurar o fuso horário em conformidade.

No exemplo seguinte, o YAML de configuração converte um tipo de dados TIMESTAMP e um tipo de dados TIMESTAMP WITH TIME ZONE em DATETIME, com o fuso horário de destino definido como Europe/Paris.

type: experimental_object_rewriter
global:
  typeConvert:
    timestamp:
      target: DATETIME
      timezone: Europe/Paris
    timestamptz:
      target: DATETIME
      timezone: Europe/Paris

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

teradata-input.sql

      create table x(a timestamp);
      select a from x where a > current_timestamp(0);

bq-output.sql

      CREATE TABLE x
      (
        a TIMESTAMP
      )
      ;
      SELECT
          x.a
        FROM
          test.x
        WHERE x.a > datetime_trunc(current_datetime('Europe/Paris'), SECOND)
      ;

Selecione a modificação do extrato

A seguinte configuração YAML altera a projeção de estrelas, as cláusulas GROUP BY e ORDER BY nas declarações SELECT.

O starProjection suporta as seguintes configurações:

ALLOW
PRESERVE (predefinição)
EXPAND

O groupBy e o orderBy suportam as seguintes configurações:

EXPRESSION
ALIAS
INDEX

No exemplo seguinte, a configuração YAML configura a projeção de estrelas para EXPAND.

type: experimental_statement_rewriter
select:
  starProjection: EXPAND

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int, b TIMESTAMP); select * from x;
`bq-output.sql`	CREATE TABLE x ( a INT64, b DATETIME ) ; SELECT x.a x.b FROM x ;

Especificação de FDU

O YAML de configuração seguinte especifica a assinatura das funções definidas pelo utilizador (UDFs) que são usadas nos scripts de origem. Tal como os ficheiros ZIP de metadados, as definições de FDU podem ajudar a produzir uma tradução mais precisa dos scripts de entrada.

type: metadata
udfs:
  - "date parse_short_date(dt int)"

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(dt int); select parse_short_date(dt) + 1 from x;
`bq-output.sql`	CREATE TABLE x ( dt INT64 ) ; SELECT date_add(parse_short_date(x.dt), interval 1 DAY) FROM x ;

Definir a rigidez da precisão decimal

Por predefinição, o serviço de migração do BigQuery aumenta a precisão numérica para a precisão mais elevada disponível para uma determinada escala. A seguinte configuração YAML substitui este comportamento configurando a rigidez da precisão para reter a precisão decimal da declaração de origem.

type: experimental_statement_rewriter
common:
  decimalPrecision: STRICT

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a decimal(3,0));
`bq-output.sql`	CREATE TABLE x ( a NUMERIC(3) ) ;

Mapeamento de nomes de saída

Pode usar o YAML de configuração para mapear nomes de objetos SQL. Pode alterar diferentes partes do nome consoante o objeto que está a ser mapeado.

Mapeamento de nomes estático

Use o mapeamento de nomes estático para mapear o nome de uma entidade. Se só quiser alterar partes específicas do nome, mantendo as outras partes do nome iguais, então inclua apenas as partes que precisam de ser alteradas.

A seguinte configuração YAML altera o nome da tabela de my_db.my_schema.my_table para my_new_db.my_schema.my_new_table.

type: experimental_object_rewriter
relation:
-
  match: "my_db.my_schema.my_table"
  outputName:
    database: "my_new_db"
    relation: "my_new_table"

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table my_db.my_schema.my_table(a int);
`bq-output.sql`	CREATE TABLE my_new_db.my_schema.my_new_table ( a INT64 )

Pode usar o mapeamento de nomes estático para atualizar a região usada pelos nomes nas funções definidas pelo utilizador públicas.

O exemplo seguinte altera os nomes no UDF bqutil.fn de usar a região múltipla us predefinida para usar a região europe_west2:

type: experimental_object_rewriter
function:
-
  match:
    database: bqutil
    schema: fn
  outputName:
    database: bqutil
    schema: fn_europe_west2

Mapeamento dinâmico de nomes

Use o mapeamento de nomes dinâmico para alterar vários objetos em simultâneo e criar novos nomes com base nos objetos mapeados.

A configuração YAML seguinte altera o nome de todas as tabelas adicionando o prefixo stg_ às que pertencem ao esquema staging e, em seguida, move essas tabelas para o esquema production.

type: experimental_object_rewriter
relation:
-
  match:
    schema: staging
  outputName:
    schema: production
    relation: "stg_${relation}"

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table staging.my_table(a int);
`bq-output.sql`	CREATE TABLE production.stg_my_table ( a INT64 ) ;

Especificar o caminho de pesquisa da base de dados e do esquema predefinidos

O YAML de configuração seguinte especifica uma base de dados predefinida e um caminho de pesquisa de esquemas.

type: environment
session:
  defaultDatabase: myproject
  schemaSearchPath: [myschema1, myschema2]

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	SELECT * FROM database.table SELECT * FROM table1
`bq-output.sql`	SELECT * FROM myproject.database.table. SELECT * FROM myproject.myschema1.table1

Reescrita do nome de saída global

A seguinte configuração YAML altera os nomes de saída de todos os objetos (base de dados, esquema, relação e atributos) no script de acordo com as regras configuradas.

type: experimental_object_rewriter
global:
  outputName:
    regex:
      - match: '\s'
        replaceWith: '_'
      - match: '>='
        replaceWith: 'gte'
      - match: '^[^a-zA-Z_].*'
        replaceWith: '_$0'

Uma tradução SQL com este ficheiro YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table "test special chars >= 12"("42eid" int, "custom column" varchar(10));
`bq-output.sql`	CREATE TABLE test_special_chars_employees_gte_12 ( _42eid INT64, custom_column STRING ) ;

Otimize e melhore o desempenho do SQL traduzido

As transformações opcionais podem ser aplicadas ao SQL traduzido para introduzir alterações que podem melhorar a consulta em termos de desempenho ou custo. Estas otimizações dependem estritamente da capitalização e devem ser avaliadas em função do resultado do SQL não modificado para avaliar o respetivo efeito real no desempenho.

O YAML de configuração seguinte ativa as transformações opcionais. A configuração aceita uma lista de otimizações e, para otimizações que aceitam parâmetros, uma secção com valores de parâmetros opcionais.

type: optimizer
transformations:
  - name: PRECOMPUTE_INDEPENDENT_SUBSELECTS
  - name: REWRITE_CTE_TO_TEMP_TABLE
    parameters:
      threshold: 1

Optimização	Parâmetro opcional	Descrição
`PRECOMPUTE_INDEPENDENT_SUBSELECTS`	`scope: [PREDICATE, PROJECTION]`	Reescreve a consulta adicionando uma declaração `DECLARE` para substituir uma expressão nas cláusulas `PREDICATE` ou `PROJECTION` por uma variável pré-calculada. Isto é identificado como um predicado estático que permite reduzir a quantidade de dados lidos. Se o âmbito for omitido, o valor predefinido é `PREDICATE` (ou seja, cláusula `WHERE` e `JOIN-ON`). A extração de uma subconsulta escalar para uma declaração `DECLARE` torna o predicado original estático e, por conseguinte, elegível para um planeamento de execução melhorado. Esta otimização vai introduzir novas declarações SQL.
`REWRITE_CTE_TO_TEMP_TABLE`	`threshold: N`	Reescreve expressões de tabelas comuns (CTE) em tabelas temporárias quando existem mais de `N` referências à mesma expressão de tabela comum. Isto reduz a complexidade da consulta e força a execução única da expressão de tabela comum. Se `N` for omitido, o valor predefinido é 4. Recomendamos a utilização desta otimização quando são feitas referências várias vezes a CTEs não triviais. A introdução de tabelas temporárias tem uma sobrecarga que pode ser superior às várias execuções eventuais de um CTE de baixa complexidade ou baixa cardinalidade. Esta otimização vai introduzir novas declarações SQL.
`REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER`	`bigint: N`	Reescreve os atributos `NUMERIC/BIGNUMERIC` de escala zero para o tipo `INT64` se a precisão estiver dentro de `N`. Se `N` for omitido, o valor predefinido é `18`. Recomendamos a utilização desta otimização quando traduzir de dialetos de origem que não tenham tipos de números inteiros. A alteração dos tipos de colunas requer a revisão de todas as utilizações posteriores para verificar a compatibilidade de tipos e as alterações semânticas. Por exemplo, divisões fracionárias que se tornam divisões inteiras, código que espera valores numéricos
`DROP_TEMP_TABLE`		Adiciona declarações `DROP TABLE` para todas as tabelas temporárias criadas num script e não eliminadas no final do mesmo. Isto reduz o período de faturação do armazenamento da tabela temporária de 24 horas para o tempo de execução do script. Esta otimização vai introduzir novas declarações SQL. Recomendamos que use esta otimização quando não se acede a tabelas temporárias para processamento adicional após o fim da execução do script. Esta otimização vai introduzir novas declarações SQL.
`REGEXP_CONTAINS_TO_LIKE`		Reescreve algumas categorias de `REGEXP_CONTAINS`padrões de correspondência para expressões `LIKE`. Recomendamos a utilização desta otimização quando nenhum outro processo, como a substituição de macros, depende da preservação inalterada dos literais de padrões de expressões regulares no SQL de saída.
`ADD_DISTINCT_TO_SUBQUERY_IN_SET_COMPARISON`		Adiciona a cláusula `DISTINCT` a subconsultas usadas como conjunto de valores para o operador `[NOT] IN`. Recomendamos a utilização desta otimização quando a cardinalidade (número distinto de valores) do resultado da subconsulta for significativamente inferior ao número de valores. Quando esta pré-condição não é cumprida, esta transformação pode ter efeitos negativos no desempenho.

Crie um ficheiro YAML de configuração baseado no Gemini

Para gerar resultados de IA, o diretório de origem que contém a entrada de tradução de SQL tem de incluir um ficheiro YAML de configuração.

Requisitos

O ficheiro YAML de configuração para resultados de IA tem de ter o sufixo .ai_config.yaml. Por exemplo, rules_1.ai_config.yaml.

Campos suportados

Pode usar os seguintes campos para configurar o resultado da tradução de IA:

suggestion_type (opcional): especifique o tipo de sugestão de IA a ser gerada. Os seguintes tipos de sugestões são suportados:
- QUERY_CUSTOMIZATION (predefinição): gera sugestões de IA para código SQL com base nas regras de tradução especificadas no ficheiro YAML de configuração.
- TRANSLATION_EXPLANATION: gera texto que inclui um resumo da consulta GoogleSQL traduzida e as diferenças e inconsistências entre a consulta SQL de origem e a consulta GoogleSQL traduzida.
rewrite_target (opcional): especifique SOURCE_SQL se quiser aplicar a regra de tradução ao seu SQL de entrada ou TARGET_SQL (predefinição) se quiser aplicar a regra de tradução ao seu SQL de saída.
instruction (opcional): em linguagem natural, descreva uma alteração ao SQL de destino. A tradução de SQL melhorada pelo Gemini avalia o pedido e faz a alteração especificada.
examples (opcional): forneça exemplos de SQL de como quer que o padrão de SQL seja modificado.

Pode adicionar mais translation_rules e mais examples, conforme necessário.

Exemplos

Os exemplos seguintes criam ficheiros YAML de configuração baseados no Gemini que pode usar com as suas traduções de SQL.

Remova a função upper na consulta de saída de tradução predefinida

translation_rules:
- instruction: "Remove upper() function"
  examples:
  - input: "upper(X)"
    output: "X"

Crie várias regras de tradução para personalizar o resultado da tradução

translation_rules:
- instruction: "Remove upper() function"
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL
  examples:
  - input: "upper(X)"
    output: "X"
- instruction: "Insert a comment at the head that explains each statement in detail.
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL

Remova os comentários SQL da consulta de entrada de tradução

translation_rules:
- instruction: "Remove all the sql comments in the input sql query."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: SOURCE_SQL

Gere explicações de traduções através do comando do MDG predefinido

Este exemplo usa os comandos do GML predefinidos fornecidos pelo serviço de tradução para gerar explicações de texto:

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"

Gera explicações de traduções usando os seus próprios comandos de linguagem natural

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
  instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."

Vários tipos de sugestões num único ficheiro YAML de configuração

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
  instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."
- instruction: "Remove upper() function"
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL
  examples:
  - input: "upper(X)"
    output: "X"
- instruction: "Remove all the sql comments in the input sql query."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: SOURCE_SQL

Aplicar várias configurações YAML

Quando especifica um ficheiro YAML de configuração numa tradução SQL interativa ou em lote, pode selecionar vários ficheiros YAML de configuração num único trabalho de tradução para refletir várias transformações. Se várias configurações entrarem em conflito, uma transformação pode substituir outra. Recomendamos que use diferentes tipos de definições de configuração em cada ficheiro para evitar transformações em conflito na mesma tarefa de tradução.

O exemplo seguinte apresenta dois ficheiros YAML de configuração separados que foram fornecidos para uma única tarefa de tradução de SQL, um para alterar o atributo de uma coluna e o outro para definir a tabela como temporária:

change-type-example.config.yaml:

type: object_rewriter
attribute:
  -
    match: "testdb.testschema.x.a"
    type:
      target: NUMERIC(10,2)

make-temp-example.config.yaml:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    temporary: true

Uma tradução SQL com estes dois ficheiros YAML de configuração pode ter o seguinte aspeto:

`teradata-input.sql`	create table x(a int);
`bq-output.sql`	CREATE TEMPORARY TABLE x ( a NUMERIC(31, 2) ) ;

Transforme traduções de SQL com ficheiros YAML de configuração

Requisitos do ficheiro YAML de configuração

Diretrizes para criar um ficheiro YAML de configuração

Cabeçalho

Seleção de entidades

Base de dados predefinida

Tipos de atributos de destino suportados

Exemplos de YAML de configuração

Alterar a capitalização do nome do objeto

Torne a tabela temporária

Torne a tabela efémera

Defina a validade da partição

Altere a localização ou o formato externo de uma tabela

Defina ou altere a descrição da tabela

Defina ou altere a partição de tabelas

Defina ou altere o agrupamento de tabelas

Altere o tipo de um atributo de coluna

Adicione uma associação a um data lake externo

Altere a codificação de carateres de um ficheiro de entrada

Conversão de tipo global

Selecione a modificação do extrato

Especificação de FDU

Definir a rigidez da precisão decimal

Mapeamento de nomes de saída

Mapeamento de nomes estático

Mapeamento dinâmico de nomes

Especificar o caminho de pesquisa da base de dados e do esquema predefinidos

Reescrita do nome de saída global

Otimize e melhore o desempenho do SQL traduzido

Crie um ficheiro YAML de configuração baseado no Gemini

Requisitos

Campos suportados

Exemplos

Remova a função upper na consulta de saída de tradução predefinida

Crie várias regras de tradução para personalizar o resultado da tradução

Remova os comentários SQL da consulta de entrada de tradução

Gere explicações de traduções através do comando do MDG predefinido

Gera explicações de traduções usando os seus próprios comandos de linguagem natural

Vários tipos de sugestões num único ficheiro YAML de configuração

Aplicar várias configurações YAML