Conceptos de ingesta de Zerobus

Esta página describe los conceptos fundamentales de Zerobus Ingest en Lakeflow Connect: cómo funciona el servicio, sus flujos, servidor y clientes, y los tipos de datos que soporta.

Ir a un concepto:

• Cómo funciona Zerobus Ingest: el flujo de extremo a extremo, desde el productor hasta la tabla consultable.
• Servidor: de qué es responsable el servicio de Ingesta Zerobus.
• Cliente: de qué es responsable tu productor.
• Streams: la conexión que abre tu cliente para ingerir datos.
• Cómo escala Zerobus Gest: por qué escala sin planificación de capacidad.
• Requisitos de la mesa: qué debe cumplir tu mesa y espacio de trabajo objetivo.
• Tipos de datos soportados: mapeo de tipos Delta a Protobuf.

Cómo funciona la ingesta de Zerobus

Un productor de datos primero abre un flujo hacia la API de Ingesta de Zerobus y especifica una tabla Delta objetivo, construye un mensaje que coincida con su esquema y luego envía el mensaje a través del flujo abierto. El servicio hace que los datos sean duraderos y reconoce el mensaje del cliente. Luego materializa los datos en la tabla Delta, de forma optimizada, como un paso separado. El reconocimiento confirma la durabilidad, no la posibilidad de consulta. Consulta Comunicación asíncrona para ver cómo funciona esto y qué significa para tu cliente.

Zerobus Ingest es un servicio serverless que escala elásticamente con tu carga de trabajo. Para ver cómo escala, consulta cómo escala Zerobus Ingest más abajo.

Esta sección también cubre las formas en que te conectas a Zerobus Ingest y las formas que pueden adoptar tus datos:

• Protocolos API: Los protocolos API, gRPC con SDKs, REST y OpenTelemetry, y cuándo usar cada uno.
• Tipos de mensajes: Los formatos de registro, JSON, búferes de protocolo (protobuf) y Apache Arrow, y cuándo usar cada uno.

Server

El servicio de ingesta de Zerobus no crea ni manipula automáticamente tablas. Los usuarios deben crear la propia tabla. Las tablas y sus esquemas son los orígenes autoritativos de las expectativas de los datos entrantes.

El servidor Zerobus Ingest acepta los datos enviados por los clientes y valida que encajan en el esquema de la tabla objetivo. Si el registro encaja, el servidor lo hace duradero y lo reconoce ante el cliente. Materializar el registro en la tabla Delta, para que sea consultable, ocurre como un paso separado poco después.

Las responsabilidades del servicio incluyen:

• Validación del esquema del mensaje frente a la tabla.
• Hacer que el registro sea persistente y confirmarlo al cliente. El reconocimiento confirma la durabilidad, aunque el registro aún no es consultable.
• Materializar los datos en la tabla de destino en el momento oportuno, que es cuando pasan a ser consultables. Para las cifras de latencia, véase Latencia.

Client

Un cliente se conecta a Zerobus Ingest, envía registros y confirma que son duraderos. Cuando usas un SDK de Ingesta de Zerobus, el SDK se encarga de la mayor parte de esto por ti, así que ayuda a separar lo que configuras de lo que hace el SDK automáticamente.

Configuras o implementas:

• Selección de una tabla de destino.
• Abriendo un flujo hacia el servicio Zerobus Ingest.
• Construir un mensaje compatible con el esquema y enviarlo.

El SDK gestiona automáticamente:

• Acuses de recibo de mensajes. El SDK ejecuta el bucle de reconocimiento por ti y muestra confirmaciones de durabilidad mediante desplazamientos o una llamada de confirmación. Solo bloqueas un registro concreto cuando tu aplicación lo necesita. Véase Comunicación asincrónica.
• Recuperación. Por defecto, el SDK se reconecta y reproduce registros no reconocidos en fallos transitorios.
  • Puedes desactivar la recuperación integrada e implementar tu propio mecanismo de recuperación. Para saber qué activa la recuperación, las opciones de configuración y los patrones de recuperación personalizados, consulta Patrones de recuperación y reintentos.

No tienes que escribir a mano la lógica de acuse de recibo o recuperación cuando usas un SDK. Para integraciones personalizadas que no usan SDK, el repositorio Zerobus SDK es una referencia para la estructura de integración y el manejo de la recuperación.

Flujos

Un flujo es una conexión directa entre tu cliente y el servidor Zerobus Ingest, establecida sobre una conexión gRPC persistente y bidireccional. Los SDK usan flujos para facilitar conexiones de alto rendimiento y de larga duración.

• Los flujos solo se usan en la API de gRPC con los SDK.
• Un flujo ingiere datos en una sola tabla de destino.
• Abre flujos adicionales para escribir en diferentes tablas o para escalar el rendimiento de un solo cliente hasta el nivel que requiera tu carga de trabajo.

Los flujos también son la unidad de orden (véase Garantías de orden) y la unidad según la cual Zerobus Ingest escala (véase Cómo escala Zerobus Ingest).

Garantías de pedido

El pedido está garantizado por stream. Los registros se escriben en la tabla de destino en el orden en que se ponen en cola en un único flujo. No hay un orden global entre corrientes. De esto se derivan varios puntos de diseño:

• Si repartes los registros en varios flujos (por ejemplo, round-robin), no hay garantía de orden entre esos flujos.
• Si tu caso de uso requiere un único orden total entre muchos productores o flujos, impón ese orden en tu aplicación (por ejemplo, con una marca de tiempo o un número de secuencia en los que se basen tus consultas) en lugar de depender del orden de ingesta.

Por qué el streaming gRPC

Como la conexión gRPC de un flujo permanece abierta, el cliente evita el coste de configuración por solicitud de un protocolo sin estado y puede enviar un flujo continuo y de alto volumen de registros por un solo canal. Esto es lo que hace que los SDK sean la forma de ingesta con mayor rendimiento. Para las otras interfaces (REST y OpenTelemetry) y cuándo elegir cada una, véase protocolos API.

Cómo escala Zerobus Ingest

Zerobus Ingest está diseñado para una alta escalabilidad, y alcanza esa escala sin que tengas que planificar la capacidad. Dos decisiones de diseño hacen esto posible:

• No tiene servidor. El servicio aumenta y reduce la capacidad automáticamente a medida que cambia la carga, por lo que no es necesario dimensionar los brokers ni aprovisionar particiones. Puedes abrir tantos flujos concurrentes y escribir en tantas tablas como necesite tu carga de trabajo.
• Los flujos son unidades dinámicas de partición. En lugar de un conjunto fijo de particiones que deben volver a particionarse y reequilibrarse para escalar horizontalmente, los flujos pueden abrirse, cerrarse y rotarse. Rotar los flujos permite que el servicio reequilibre la capacidad y los recursos a medida que cambia la demanda, así que escalas abriendo más canales y gestionando más productores mientras el servicio absorbe el resto.

El resultado práctico es que un cliente "hola mundo" y una carga de trabajo a escala petabyte ejecutan esencialmente el mismo código. La diferencia está en cuántos productores y streams gestionas. Este diseño ha permitido la ingesta sostenida de más de 1 billón de registros en una sola tabla Delta. Para conocer los antecedentes técnicos, consulta la entrada de blog Ingerir la Vía Láctea: a escala de petabytes con Zerobus Ingest.

Tabla de requisitos

Zerobus Ingest escribe en una tabla Delta que creas y posees. La mesa y el espacio de trabajo objetivo deben cumplir estos requisitos:

• Zerobus Ingest escribe solo en tablas Delta gestionadas. No se admite la escritura en el almacenamiento predeterminado.
• Zerobus Ingest no escribe en recursos de almacenamiento protegidos mediante un punto de conexión de red privado.
• Zerobus Ingest no soporta recrear una tabla objetivo.
• Los nombres de las tablas solo pueden contener letras, números y guiones bajos ASCII.
• El espacio de trabajo y la tabla objetivo deben estar ambos en una de las regiones soportadas.

Para saber cómo se validan los registros frente al esquema de la tabla, véase Gestión de esquemas. Para características de tabla como particionamiento y agrupamiento de líquidos, véase características de tabla Delta.

Tipos de datos admitidos

La siguiente tabla muestra los tipos de Delta compatibles y sus tipos Protobuf correspondientes para la ingesta.