Criação de UDFs de Java¶

Mapeamentos de tipos de dados SQL-Java para tipos de parâmetros e retorno¶

A tabela abaixo mostra os mapeamentos de tipo entre SQL e Java. Esses mapeamentos geralmente se aplicam tanto aos argumentos passados à UDF de Java quanto aos valores retornados da UDF. Entretanto, há algumas exceções, que estão listadas em notas de rodapé.

Alguns tipos de dados de SQL (por exemplo, NUMBER) são compatíveis com vários tipos de dados de Java (por exemplo, int, long, etc.). Nesses casos, você pode usar qualquer tipo de dados de Java que tenha capacidade suficiente para manter os valores reais que serão passados. Se você passar um valor de SQL para um tipo de dados de Java incompatível (ou vice-versa), o Snowflake gerará um erro.

1(1,2)

O formato corresponde ao formato de carimbo de data/hora da internet (RFC) DY, DD MON YYYY HH24:MI:SS TZHTZM, conforme descrito em Formatos de carimbo de data/hora. Se uma diferença de fuso horário (o componente TZHTZM) estiver presente, normalmente são dígitos (por exemplo, -0700 indica 7 horas atrás de UTC). Se a diferença do fuso horário for Z (de “Zulu”) e não dígitos, isso é sinônimo de “+0000” (UTC).

2

O formato corresponde ao formato de carimbo de data/hora da internet (RFC) DY, DD MON YYYY HH24:MI:SS, conforme descrito em Formatos de carimbo de data/hora. Se a cadeia de cadeia de caracteres for seguida por um espaço e Z (de “Zulu”), isso indica explicitamente que a diferença é “+0000” (UTC).

3(1,2,3,4,5,6,7,8)

Embora o Snowflake possa armazenar valores de tempo com precisão de nanossegundos, a biblioteca de tempo java.sql.time mantém apenas uma precisão de milissegundos. A conversão entre os tipos de dados do Snowflake e do Java pode reduzir a precisão efetiva para milissegundos.

4(1,2,3,4,5,6)

Esse tipo de mapeamento é suportado na conversão de argumentos de SQL para Java, mas não na conversão de tipos de retorno de Java para tipos de SQL.

5

O Java não tem um tipo de dados Geography nativo. O tipo de dados Geography referido aqui é uma classe do pacote Snowpark. Para obter mais informações, consulte Tipos suportados do pacote Snowpark.

Tipos suportados do pacote Snowpark¶

Em uma função definida pelo usuário, é possível usar um subconjunto específico de tipos que estão incluídos no pacote do Snowflake Snowpark Java package. Embora estes tipos sejam projetados para uso em código do Snowpark, alguns também são suportados para uso em UDFs pela conveniência que podem proporcionar. (Para obter mais informações sobre o Snowpark, consulte a documentação Snowpark.)

Os tipos do Snowpark na tabela a seguir são suportados em código de UDF. Você não deve usar outros tipos do Snowpark em código de UDF; eles não são suportados lá.

Valores TIMESTAMP_LTZ e fusos horários¶

Uma UDF de Java fica bastante isolada do ambiente no qual é chamada. Entretanto, o fuso horário é herdado do ambiente de chamada. Se a sessão do chamador definir um fuso horário padrão antes de chamar a UDF de Java, a UDF de Java tem o mesmo fuso horário padrão. A UDF de Java utiliza os mesmos dados da base de dados de fuso horário IANA usados pelo TIMEZONE SQL do Snowflake nativo (isso é, dados do lançamento 2021a do banco de dados de fuso horário).

Valores NULL¶

O Snowflake oferece suporte para dois valores NULL distintos: SQL NULL e JSON de VARIANT null. (Para obter mais informações sobre o VARIANT NULL do Snowflake, consulte Valores NULL).

O Java oferece suporte para um valor null, que é apenas para tipos de dados não-primitivos.

Um argumento SQL NULL para uma UDF de Java é convertido para o valor de Java null, mas somente para tipos de dados de Java que oferecem suporte para null.

Um valor de Java null retornado é convertido de volta para um NULL de SQL.

Arrays e número variável de argumentos¶

UDFs de Java podem receber arrays de qualquer um dos seguintes tipos de dados de Java:

• Cadeia de caracteres

• booleano

• double

• float

• int

• long

• short

O tipo de dados dos valores de SQL passados deve ser compatível com o tipo de dados de Java correspondente. Para obter mais detalhes sobre compatibilidade de tipos de dados, consulte Mapeamentos de tipos de dados SQL-Java para tipos de parâmetros e retorno.

As seguintes regras adicionais se aplicam para cada um dos tipos de dados de Java especificados:

• boolean: a ARRAY do Snowflake deve conter somente elementos BOOLEAN, e não deve conter nenhum valor NULL.

• int/short/long: a ARRAY do Snowflake deve conter somente elementos de ponto fixo com uma escala de 0, e não deve conter nenhum valor NULL.

• float/double: a ARRAY do Snowflake deve conter um dos seguintes:

  • Elementos FLOAT.

  • Elementos de ponto fixo (com qualquer escala).

  A ARRAY não deve conter nenhum valor NULL.

Os métodos de Java podem receber essas arrays de uma das duas maneiras a seguir:

• Usando o recurso de array do Java.

• Usando o recurso varargs (número variável de argumentos) do Java.

Em ambos os casos, seu código de SQL deve passar uma ARRAY.

Memória¶

Evite consumir memória demais.

• Grandes valores de dados (normalmente tipo de dados BINARY, VARCHAR longos ou ARRAY ou OBJECT ou VARIANT grandes) podem consumir uma grande quantidade de memória.

• Uma profundidade de pilha excessiva pode consumir uma grande quantidade de memória. O Snowflake testou chamadas de funções simples com aninhamento de 50 níveis de profundidade sem erros. O limite máximo prático depende de quanta informação é colocada na pilha.

UDFs retornam um erro se elas consumirem memória demais. O limite específico está sujeito a mudanças.

Hora¶

Evite algoritmos que demorem muito tempo por chamada.

Se uma UDF leva tempo demais para ser concluída, o Snowflake interrompe a instrução SQL e retorna um erro ao usuário. Isso limita o impacto e o custo de erros como loops infinitos.

Bibliotecas¶

Embora seu método de Java possa usar classes e métodos nas bibliotecas padrão de Java, as restrições de segurança do Snowflake desabilitam algumas capacidades, tais como escrever em arquivos. Para obter mais detalhes sobre restrições de bibliotecas, consulte a seção intitulada Boas práticas de segurança.

Introdução¶

O Snowflake espera que o UDFs escalares seja processadas de forma independente. Confiar em um estado compartilhado entre invocações pode resultar em comportamento inesperado, pois o sistema pode processar linhas em qualquer ordem e espalhar essas invocações por várias JVMs. UDFs devem evitar confiar em um estado compartilhado entre diferentes chamadas para o método do manipulador. Entretanto, há duas situações em que você pode querer que uma UDF armazene um estado compartilhado:

• Código que contém uma lógica de inicialização cara que você não quer repetir para cada linha.

• Código que use um estado compartilhado em linhas diferentes, como um cache.

Se você precisar compartilhar o estado em várias linhas, e se esse estado não mudar com o tempo, use um construtor para criar um estado compartilhado definindo variáveis em nível de instância. O construtor é executado apenas uma vez por instância, enquanto o manipulador é chamado uma vez por linha. Portanto, inicializar no construtor é mais barato quando um manipulador processa várias linhas. E como o construtor é chamado apenas uma vez, o construtor não precisa ser escrito de forma a ser thread-safe.

Se sua UDF armazena um estado compartilhado que muda, seu código deve estar preparado para lidar com o acesso simultâneo a esse estado. As duas próximas seções fornecem mais informações sobre paralelismo e estados compartilhados.

Entendendo a paralelização de UDF de Java¶

Para melhorar o desempenho, o Snowflake paraleliza tanto entre JVMs diferente quanto dentro de JVMs.

• Entre JVMs diferentes:

  O Snowflake paralela entre os trabalhadores em um warehouse. Cada trabalhador executa uma (ou mais) JVMs. Isso significa que não existe um estado global compartilhado. No máximo, o estado só pode ser compartilhado dentro de uma única JVM.

• Dentro de JVMs:

  • Cada JVM pode executar vários threads que podem chamar o mesmo método do manipulador da mesma instância em paralelo. Isso significa que cada método do manipulador precisa ser thread-safe.

  • Se uma UDF é IMMUTABLE e uma instrução SQL chama a UDF mais de uma vez com os mesmos argumentos para a mesma linha, a UDF retorna o mesmo valor para cada chamada para aquela linha. Por exemplo, o código a seguir retorna o mesmo valor duas vezes para cada linha se a UDF for IMMUTABLE:

    select
           my_java_udf(42),
           my_java_udf(42)
        from table1;
    

    Se você quiser que múltiplas chamadas retornem valores independentes mesmo quando passarem os mesmos argumentos não quiser declarar a função como VOLATILE, ligue diferentes chamadas a UDFs separadas ao mesmo método do manipulador. Por exemplo:

    1. Crie um arquivo JAR chamado @java_udf_stage/rand.jar com o código:

       class MyClass {
       
           private double x;
       
           // Constructor
           public MyClass()  {
               x = Math.random();
           }
       
           // Handler
           public double myHandler() {
               return x;
           }
       }
       

    2. Crie UDFs de Java da forma mostrada abaixo. Essas UDFs têm nomes diferentes, mas usam o mesmo arquivo JAR e o mesmo manipulador dentro desse arquivo JAR.

       create function my_java_udf_1()
           returns double
           language java
           imports = ('@java_udf_stage/rand.jar')
           handler = 'MyClass.myHandler';
       
       create function my_java_udf_2()
           returns double
           language java
           imports = ('@java_udf_stage/rand.jar')
           handler = 'MyClass.myHandler';
       

    3. O código a seguir chama ambas as UDFs. As UDFs apontam para o mesmo arquivo e manipulador JAR. Essas chamadas criam duas instâncias da mesma classe. Cada instância retorna um valor independente, portanto o exemplo abaixo retorna dois valores independentes em vez de retornar o mesmo valor duas vezes:

       select
               my_java_udf_1(),
               my_java_udf_2()
           from table1;
       

Como armazenar informações de estado de uma JVM¶

Uma razão para evitar confiar no estado dinâmico compartilhado é que as linhas não são necessariamente processadas em uma ordem previsível. Cada vez que uma instrução SQL é executada, o Snowflake pode variar o número de lotes, a ordem em que os lotes são processados e a ordem das linhas dentro de um lote. Se uma UDF escalar for projetada para que uma linha afete o valor de retorno para uma linha posterior, a UDF pode retornar resultados diferentes cada vez que a UDF for executada.