Skip to main content

​
Fuentes de datos compatibles

​
Nivel de aislamiento

El nivel de aislamiento del consumidor de Kafka determina si un ClickPipe lee e inserta únicamente los mensajes confirmados por una transacción de Kafka. Habilite la configuración kafka_read_committed para usar read_committed y omitir los mensajes de transacciones de Kafka canceladas. Deshabilítela para usar read_uncommitted y leer todos los mensajes. Puede configurar esta opción en Configuración avanzada.

​
Formatos de datos admitidos

Los formatos admitidos son:

​
Tipos de datos compatibles

​
Tipos estándar

Actualmente, ClickPipes admite los siguientes tipos de datos estándar de ClickHouse:
  • Tipos numéricos básicos: [U]Int8/16/32/64, Float32/64 y BFloat16
  • Tipos enteros grandes: [U]Int128/256
  • Tipos Decimal
  • Boolean
  • String
  • FixedString
  • Date, Date32
  • DateTime, DateTime64 (solo zonas horarias UTC)
  • Enum8/Enum16
  • UUID
  • IPv4
  • IPv6
  • Time, Time64
  • JSON
  • todos los tipos LowCardinality de ClickHouse
  • Map con claves y valores que usan cualquiera de los tipos anteriores (incluidos los Nullable)
  • Tuple y Array con elementos que usan cualquiera de los tipos anteriores (incluidos los Nullable, solo un nivel de profundidad)
  • tipos SimpleAggregateFunction (para destinos AggregatingMergeTree o SummingMergeTree)

​
Compatibilidad con el tipo Variant

ClickPipes admite el tipo Variant en las siguientes circunstancias:
  • Unions de Avro. Si su esquema de Avro contiene una unión con varios tipos no nulos, ClickPipes inferirá el tipo Variant adecuado. En otros casos, los tipos Variant no se admiten para datos Avro.
  • Campos JSON. Puede especificar manualmente un tipo Variant (como Variant(String, Int64, DateTime)) para cualquier campo JSON en el flujo de datos de origen. No se admiten subtipos complejos (arrays/maps/tuples). Además, debido a la forma en que ClickPipes determina el subtipo Variant correcto que debe usar, en la definición de Variant solo puede usarse un tipo entero o de fecha y hora; por ejemplo, Variant(Int64, UInt32) no se admite.

​
Compatibilidad con el tipo JSON

ClickPipes admiten el tipo JSON en los siguientes casos:
  • Los campos Avro Record y Protobuf Message siempre se pueden asignar a una columna JSON.
  • Los campos Avro String y Bytes se pueden asignar a una columna JSON si el campo Avro contiene realmente cadenas JSON que representan objetos.
  • Los campos Protobuf de tipo String y Bytes se pueden asignar a una columna JSON si el campo Protobuf contiene realmente cadenas JSON que representan objetos.
  • Los campos JSON que siempre son un objeto JSON se pueden asignar a una columna JSON de destino.
Ten en cuenta que tendrás que cambiar manualmente la columna de destino al tipo JSON deseado, incluidas las rutas fijas o omitidas.

​
Avro

​
Tipos de datos Avro compatibles

ClickPipes admite todos los tipos primitivos y complejos de Avro, así como todos los tipos lógicos de Avro, excepto local-timestamp-millis y local_timestamp-micros. Los tipos record de Avro se convierten en Tuple, los tipos array en Array y map en Map (solo claves de cadena). En general, están disponibles las conversiones indicadas aquí. Recomendamos usar una correspondencia exacta de tipos para los tipos numéricos de Avro, ya que ClickPipes no comprueba el overflow ni la pérdida de precisión durante la conversión de tipos. Como alternativa, todos los tipos de Avro se pueden insertar en una columna String y, en ese caso, se representarán como una cadena JSON válida.

​
Tipos Nullable y uniones de Avro

Los tipos Nullable en Avro se definen mediante un esquema union de (T, null) o (null, T), donde T es el tipo base de Avro. Durante la inferencia de esquemas, estas uniones se asignan a una columna “Nullable” de ClickHouse. Ten en cuenta que ClickHouse no admite los tipos Nullable(Array), Nullable(Map) ni Nullable(Tuple). Las uniones con null de Avro para estos tipos se asignan a versiones no anulables (los tipos Record de Avro se asignan a un Tuple con nombre de ClickHouse). Los valores “null” de Avro para estos tipos se insertarán como:
  • Un Array vacío para un array de Avro nulo
  • Un Map vacío para un Map de Avro nulo
  • Un Tuple con nombre con todos los valores predeterminados o cero para un Record de Avro nulo

​
Protobuf

​
Tipos de datos de Protobuf compatibles

ClickPipes admite todos los tipos de Protobuf 2 y 3, excepto el tipo group de proto 2, que lleva tiempo obsoleto. Las conversiones básicas de tipos usan las siguientes correspondencias:
También se admiten las variantes Array, Map y Nullable de todos los tipos básicos.
Para los tipos numéricos, se recomienda una correspondencia exacta para evitar desbordamientos o pérdida de precisión.
También se admiten los siguientes tipos conocidos:

​
Protobuf oneof

Durante la inferencia de esquemas, los campos oneof de Protobuf se asignan de forma predeterminada a un Tuple con nombre, donde como máximo un campo contendrá un valor distinto del predeterminado. Estos campos también pueden asignarse automáticamente a una columna Variant, donde el valor activo adopta el tipo del campo constituyente que esté establecido. Como alternativa, cada campo constituyente puede asignarse manualmente a su propia columna de ClickHouse; dado que los campos oneof son mutuamente excluyentes, solo se rellenará una columna por registro.

​
Listas de mensajes

Si el esquema Protobuf de nivel superior definido para el ClickPipe contiene un único campo repetido que a su vez es un Message de protobuf, la inferencia de esquemas y la asignación de columnas se basarán en el campo Message «contenido». El mensaje de Kafka se procesará como una lista de esos mensajes, y un único mensaje de Kafka se desglosará en múltiples filas de ClickHouse.

​
Columnas virtuales de Kafka

Las siguientes columnas virtuales son compatibles con las fuentes de datos de streaming compatibles con Kafka. Al crear un nuevo destino, se pueden añadir columnas virtuales a la tabla de destino mediante el botón Add Column. Ten en cuenta que la columna _raw_message solo se recomienda para datos JSON. En los casos de uso en los que solo se necesita la cadena JSON (por ejemplo, al usar las funciones JsonExtract* de ClickHouse para poblar una vista materializada de destino), eliminar todas las columnas “no virtuales” puede mejorar el rendimiento de ClickPipes.

​
Claves de mensajes estructurados

La asignación de _key a una columna String almacena la clave original del mensaje de Kafka. Esta asignación omite la decodificación de la clave y la consulta del esquema. Para extraer campos de una clave estructurada, asigne campos de origen que comiencen por _key.. Por ejemplo, para la clave JSON {"customer":{"id":42}}, asigne _key.customer.id a una columna de destino como customer_id. Para las asignaciones _key.* o una asignación directa de _key a un tipo distinto de String, ClickPipes comprueba primero si la clave se codificó mediante el registro de esquemas configurado. Si no es así, ClickPipes comprueba si la clave es un objeto JSON. Una clave codificada mediante un registro debe usar el mismo formato y la misma familia de registros que el valor del registro, aunque puede usar un ID de esquema diferente. Los cambios en el esquema de la clave se detectan automáticamente. Cuando la decodificación está habilitada, las claves sin procesar, los escalares o arrays JSON y los JSON malformados no rellenan los campos de clave anidados; sus columnas de destino reciben los valores predeterminados del tipo. Si ClickPipes reconoce una clave codificada mediante un registro, pero no puede recuperar o aplicar su esquema, escribe el registro de Kafka en la tabla de errores de ClickPipes. Una clave Avro también puede tener un esquema raíz que no sea de registro, como un tipo primitivo, array, map o fijo. Para decodificarla, asigne _key directamente a un tipo de destino compatible distinto de String. Los esquemas que no son de registro no pueden rellenar campos de clave anidados.
Última modificación el 18 de agosto de 2026