Formatos de entrada
- Analisar os dados fornecidos às instruções
INSERT - Executar consultas
SELECTem tabelas baseadas em arquivo, comoFile,URLouHDFS - Ler dicionários
- O formato Native é o formato de entrada mais eficiente, oferecendo a melhor compressão, o menor uso de recursos e a menor sobrecarga de processamento no lado do servidor.
- A compressão é essencial - LZ4 reduz o tamanho dos dados com custo mínimo de CPU, enquanto ZSTD oferece maior compressão às custas de uso adicional de CPU.
- A pré-ordenação tem impacto moderado, já que o ClickHouse já ordena com eficiência.
- O processamento em lotes melhora significativamente a eficiência - lotes maiores reduzem a sobrecarga de inserção e melhoram a taxa de transferência.
Formatos de saída
- Organizar os resultados de uma consulta
SELECT - Realizar operações de
INSERTem tabelas baseadas em arquivo
Visão geral dos formatos
Esquema de formato
format_schema.
É necessário definir essa configuração ao usar um dos formatos Cap'n Proto e Protobuf.
O esquema de formato é uma combinação de um nome de arquivo e do nome de um tipo de mensagem nesse arquivo, separados por dois-pontos,
por exemplo, schemafile.proto:MessageType.
Se o arquivo tiver a extensão padrão do formato (por exemplo, .proto para Protobuf),
ela poderá ser omitida e, nesse caso, o esquema de formato ficará como schemafile:MessageType.
Se você inserir ou gerar dados por meio do client no modo interativo, o nome do arquivo especificado no esquema de formato
pode conter um caminho absoluto ou um caminho relativo ao diretório atual no client.
Se você usar o client no batch mode, o caminho para o esquema deverá ser relativo por motivos de segurança.
Se você inserir ou gerar dados por meio da interface HTTP, o nome do arquivo especificado no esquema de formato
deve estar localizado no diretório especificado em format_schema_path
na configuração do servidor.
Ignorar erros
CSV, TabSeparated, TSKV, JSONEachRow, Template, CustomSeparated e Protobuf, podem ignorar uma linha inválida se ocorrer um erro de parsing e continuar o parsing a partir do início da próxima linha. Veja as configurações input_format_allow_errors_num e
input_format_allow_errors_ratio.
Limitações:
- Em caso de erro de parsing,
JSONEachRowignora todos os dados até a quebra de linha (ou EOF), portanto as linhas devem ser delimitadas por\npara que os erros sejam contados corretamente. TemplateeCustomSeparatedusam o delimitador após a última coluna e o delimitador entre linhas para localizar o início da próxima linha, portanto ignorar erros só funciona se pelo menos um deles não estiver vazio.