Pular para o conteúdo principal
Este conector aproveita otimizações específicas do ClickHouse, como particionamento avançado e pushdown de predicados, para melhorar o desempenho das consultas e o processamento de dados. O conector é baseado no conector JDBC oficial do ClickHouse e gerencia seu próprio catálogo. Antes do Spark 3.0, o Spark não tinha um conceito nativo de catálogo, então os usuários normalmente dependiam de sistemas de catálogo externos, como Hive Metastore ou AWS Glue. Com essas soluções externas, os usuários precisavam registrar manualmente as tabelas da fonte de dados antes de acessá-las no Spark. No entanto, com a introdução do conceito de catálogo no Spark 3.0, o Spark agora pode descobrir tabelas automaticamente ao registrar plugins de catálogo. O catálogo padrão do Spark é spark_catalog, e as tabelas são identificadas por {catalog name}.{database}.{table}. Com o novo recurso de catálogo, agora é possível adicionar e trabalhar com vários catálogos em uma única aplicação Spark.

Escolhendo entre a Catalog API e a TableProvider API

O ClickHouse Spark connector oferece suporte a dois padrões de acesso: a Catalog API e a TableProvider API (acesso baseado em formato). Entender as diferenças ajuda a escolher a abordagem certa para seu caso de uso.

Catalog API vs TableProvider API

Requisitos

  • Java 8 ou 17 (Java 17+ é necessário para o Spark 4.0)
  • Scala 2.12 ou 2.13 (o Spark 4.0 oferece suporte somente ao Scala 2.13)
  • Apache Spark 3.3, 3.4, 3.5 ou 4.0

Matriz de compatibilidade

Instalação e configuração

Para integrar o ClickHouse ao Spark, há várias opções de instalação que se adaptam a diferentes configurações de projeto. Você pode adicionar o ClickHouse Spark connector como dependência diretamente no arquivo de build do seu projeto (como em pom.xml para Maven ou build.sbt para SBT). Como alternativa, você pode colocar os arquivos JAR necessários na pasta $SPARK_HOME/jars/ ou passá-los diretamente como uma opção do Spark usando a flag --jars no comando spark-submit. Ambas as abordagens garantem que o conector do ClickHouse esteja disponível no seu ambiente Spark.

Importar como dependência

Adicione o repositório abaixo se quiser usar a versão SNAPSHOT.

Baixe a biblioteca

O padrão de nomenclatura do JAR binário é:
Você pode encontrar todos os arquivos JAR de versões lançadas disponíveis no Maven Central Repository e todos os arquivos JAR SNAPSHOT de builds diárias no Sonatype OSS Snapshots Repository.
É essencial incluir o JAR do clickhouse-jdbc com o classificador “all”, pois o connector depende de clickhouse-http e clickhouse-client — ambos já vêm incluídos em clickhouse-jdbc:all. Como alternativa, você pode adicionar o JAR do clickhouse-client e clickhouse-http separadamente, caso prefira não usar o pacote JDBC completo.Em qualquer caso, verifique se as versões dos pacotes são compatíveis de acordo com a Compatibility Matrix.

Registrar o catálogo (obrigatório)

Para acessar suas tabelas do ClickHouse, você deve configurar um novo catálogo do Spark com as seguintes configurações: Essas configurações podem ser definidas de uma das seguintes maneiras:
  • Editar/criar spark-defaults.conf.
  • Passar a configuração para o comando spark-submit (ou para os comandos CLI spark-shell/spark-sql).
  • Adicionar a configuração ao inicializar seu contexto.
Ao trabalhar com um cluster do ClickHouse, você precisa definir um nome de catálogo exclusivo para cada instância. Por exemplo:
Dessa forma, você poderá acessar a tabela clickhouse1 <ck_db>.<ck_table> no Spark SQL por meio de clickhouse1.<ck_db>.<ck_table> e acessar a tabela clickhouse2 <ck_db>.<ck_table> por meio de clickhouse2.<ck_db>.<ck_table>.

Usando a TableProvider API (Acesso baseado em formato)

Além da abordagem baseada em catálogo, o ClickHouse Spark connector oferece suporte a um padrão de acesso baseado em formato por meio da TableProvider API.

Exemplo de leitura com base em formato

Exemplo de gravação baseado em formato

Recursos do TableProvider

A API TableProvider oferece vários recursos avançados:

Criação automática de tabela

Ao gravar em uma tabela que não existe, o conector cria automaticamente a tabela com um esquema apropriado. O conector fornece valores padrão inteligentes:
  • Engine: Usa MergeTree() por padrão, se nenhum for especificado. Você pode especificar um engine diferente usando a opção engine (por exemplo, ReplacingMergeTree(), SummingMergeTree(), etc.)
  • ORDER BY: Obrigatório - Você deve especificar explicitamente a opção order_by ao criar uma nova tabela. O conector valida se todas as colunas especificadas existem no esquema.
  • Suporte a chave Nullable: Adiciona automaticamente settings.allow_nullable_key=1 se o ORDER BY contiver colunas Nullable
ORDER BY obrigatório: A opção order_by é obrigatória ao criar uma nova tabela por meio da TableProvider API. Você deve especificar explicitamente quais colunas usar na cláusula ORDER BY. O conector valida se todas as colunas especificadas existem no esquema e gerará um erro se alguma coluna estiver ausente.Seleção de engine: O engine padrão é MergeTree(), mas você pode especificar qualquer engine de tabela do ClickHouse usando a opção engine (por exemplo, ReplacingMergeTree(), SummingMergeTree(), AggregatingMergeTree(), etc.).

Opções de conexão do TableProvider

Ao usar a API baseada em formatos, as seguintes opções de conexão estão disponíveis:

Opções de conexão

Opções de criação de tabela

Estas opções são usadas quando a tabela não existe e precisa ser criada:
  • A opção order_by é obrigatória ao criar uma nova tabela. Todas as colunas especificadas devem existir no esquema. ** Definido automaticamente como 1 se o ORDER BY contiver colunas Nullable e não for fornecido explicitamente.
Melhor prática: no ClickHouse Cloud, defina explicitamente settings.allow_nullable_key=1 se as colunas do ORDER BY puderem ser Nullable, pois o ClickHouse Cloud exige essa configuração.

Modos de gravação

O conector do Spark (tanto a TableProvider API quanto a Catalog API) oferece suporte aos seguintes modos de gravação do Spark:
  • append: Adiciona dados à tabela existente
  • overwrite: Substitui todos os dados da tabela (trunca a tabela)
Sobrescrita de partição sem suporte: No momento, o connector não oferece suporte a operações de sobrescrita no nível da partição (por exemplo, modo overwrite com partitionBy). Esse recurso está em desenvolvimento. Consulte a issue #34 no GitHub para acompanhar o progresso desse recurso.

Configurando opções do ClickHouse

Tanto a Catalog API quanto a TableProvider API permitem configurar opções específicas do ClickHouse (não opções do conector). Essas opções são repassadas ao ClickHouse ao criar tabelas ou executar consultas. As opções do ClickHouse permitem configurar definições específicas, como allow_nullable_key, index_granularity e outras configurações no nível da tabela ou da consulta. Elas são diferentes das opções do conector (como host, database, table), que controlam como o conector se conecta ao ClickHouse.

Usando a TableProvider API

Com a TableProvider API, use o formato de opção settings.<key>:

Usando a Catalog API

Com a Catalog API, use o formato spark.sql.catalog.<catalog_name>.option.<key> na configuração do Spark:
Ou defina essas configurações ao criar tabelas via Spark SQL:

Configurações do ClickHouse Cloud

Ao se conectar ao ClickHouse Cloud, certifique-se de habilitar o SSL e definir o modo de SSL adequado. Por exemplo:

Ler dados

Gravar dados

Sobrescrita de partição sem suporte: Atualmente, a Catalog API não oferece suporte a operações de sobrescrita em nível de partição (por exemplo, o modo overwrite com partitionBy). Esse recurso está sendo desenvolvido. Consulte a issue #34 no GitHub para acompanhar o andamento desse recurso.

Operações DDL

Você pode executar operações DDL na sua instância do ClickHouse usando o Spark SQL, com todas as alterações sendo persistidas imediatamente no ClickHouse. O Spark SQL permite escrever consultas exatamente como no ClickHouse, para que você possa executar diretamente comandos como CREATE TABLE, TRUNCATE e outros, sem nenhuma modificação, por exemplo:
Ao usar o Spark SQL, apenas uma instrução pode ser executada por vez.
Os exemplos acima demonstram consultas em Spark SQL, que você pode executar no seu aplicativo usando qualquer API — Java, Scala, PySpark ou shell.

Trabalhando com VariantType

O suporte a VariantType está disponível no Spark 4.0+ e requer o ClickHouse 25.3+ com os tipos JSON/Variant experimentais habilitados.
O conector oferece suporte ao VariantType do Spark para trabalhar com dados semiestruturados. O VariantType é mapeado para os tipos JSON e Variant do ClickHouse, permitindo armazenar e consultar com eficiência dados com esquema flexível.
Esta seção se concentra especificamente no mapeamento e uso do VariantType. Para uma visão geral completa de todos os tipos de dados compatíveis, consulte a seção Tipos de dados compatíveis.

Mapeamento de tipos do ClickHouse

Lendo dados do VariantType

Ao ler do ClickHouse, as colunas JSON e Variant são mapeadas automaticamente para o VariantType do Spark:

Gravando dados VariantType

Você pode gravar dados VariantType no ClickHouse usando tipos de coluna JSON ou Variant:

Criando tabelas do tipo VariantType com Spark SQL

Você pode criar tabelas do tipo VariantType usando DDL do Spark SQL:

Configurando os tipos Variant

Ao criar tabelas com colunas VariantType, você pode especificar quais tipos do ClickHouse devem ser usados:

Tipo JSON (padrão)

Se nenhuma propriedade variant_types for especificada, a coluna usará, por padrão, o tipo JSON do ClickHouse, que aceita apenas objetos JSON:
Isso cria a seguinte consulta do ClickHouse:

Tipo Variant com múltiplos tipos

Para dar suporte a primitivos, arrays e objetos JSON, especifique os tipos na propriedade variant_types:
Isso cria a seguinte consulta do ClickHouse:

Tipos de Variant compatíveis

Os seguintes tipos do ClickHouse podem ser usados em Variant():
  • Primitivos: String, Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64, Float32, Float64, Bool
  • Arrays: Array(T), em que T é qualquer tipo compatível, incluindo arrays aninhados
  • JSON: JSON para armazenar objetos JSON

Configuração do formato de leitura

Por padrão, as colunas JSON e Variant são lidas como VariantType. Você pode alterar esse comportamento para lê-las como strings:

Suporte ao formato de gravação

O suporte à gravação para VariantType varia de acordo com o formato: Configure o formato de gravação:
Se você precisar gravar em um tipo Variant do ClickHouse, use o formato JSON. O formato Arrow só oferece suporte à gravação apenas no tipo JSON.

Melhores práticas

  1. Use o tipo JSON para dados exclusivamente em JSON: Se você armazena apenas objetos JSON, use o tipo JSON padrão (sem a propriedade variant_types)
  2. Especifique os tipos explicitamente: Ao usar Variant(), liste explicitamente todos os tipos que você pretende armazenar
  3. Habilite recursos experimentais: Verifique se o ClickHouse está com allow_experimental_json_type = 1 habilitado
  4. Use o formato JSON para escritas: O formato JSON é recomendado para dados do VariantType, por oferecer melhor compatibilidade
  5. Considere os padrões de consulta: Os tipos JSON/Variant oferecem suporte às consultas de caminho JSON do ClickHouse para uma filtragem eficiente
  6. Column hints para desempenho: Ao usar campos JSON no ClickHouse, adicionar column hints melhora o desempenho da consulta. No momento, não há suporte para adicionar column hints via Spark. Consulte a GitHub issue #497 para acompanhar esse recurso.

Exemplo: Fluxo de trabalho completo

Configurações

A seguir estão as configurações ajustáveis disponíveis no conector.
Uso das configurações: estas são opções de configuração no nível do Spark que se aplicam tanto à Catalog API quanto à TableProvider API. Elas podem ser definidas de duas formas:
  1. Configuração global do Spark (aplica-se a todas as operações):
  2. Substituição por operação (somente na TableProvider API — pode sobrescrever as configurações globais):
Como alternativa, defina essas opções em spark-defaults.conf ou ao criar a sessão do Spark.

Tipos de dados compatíveis

Esta seção apresenta o mapeamento dos tipos de dados entre o Spark e o ClickHouse. As tabelas abaixo servem como referência rápida para a conversão de tipos de dados ao ler dados do ClickHouse no Spark e ao inserir dados do Spark no ClickHouse.

Lendo dados do ClickHouse no Spark

Inserindo dados do Spark no ClickHouse

Contribuições e suporte

Se você quiser contribuir com o projeto ou relatar algum problema, ficaremos felizes com sua colaboração! Visite nosso repositório no GitHub para abrir uma issue, sugerir melhorias ou enviar um pull request. Contribuições são bem-vindas! Consulte as diretrizes de contribuição no repositório antes de começar. Agradecemos por ajudar a melhorar nosso ClickHouse Spark connector!
Última modificação em 25 de junho de 2026