Preguntas frecuentes sobre Cloud Infrastructure Streaming

Streaming es un servicio sin servidor que descarga la gestión de la infraestructura que va desde la red hasta el almacenamiento y la configuración necesaria para transmitir sus datos. No tiene que preocuparse por el aprovisionamiento de la infraestructura, el mantenimiento continuo o la aplicación de parches de seguridad. El servicio Streaming replica datos de forma sincrónica en tres dominios de disponibilidad, lo que proporciona alta disponibilidad y durabilidad de los datos. En regiones con un solo dominio de disponibilidad, los datos se replican en tres dominios de fallo.

Streaming facilita la recopilación, el almacenamiento y el procesamiento de datos generados en tiempo real a partir de cientos de fuentes. El número de casos de uso es casi ilimitado, desde la mensajería hasta el procesamiento de flujos de datos complejos. A continuación se muestran algunos de los numerosos usos posibles de Streaming:

• Mensajería: use Streaming para desacoplar los componentes de sistemas grandes. Los productores y consumidores pueden utilizar Streaming como un bus de mensajes asincrónico y actuar de forma independiente y a su propio ritmo.
• Ingesta de métricas y logs : use Streaming como alternativa a los enfoques tradicionales de extracción de archivos para conseguir que los datos operativos esenciales estén disponibles rápidamente para la indexación, el análisis y la visualización.
• Ingesta de datos de actividad móvil o web: use Streaming para capturar la actividad de sitios web o aplicaciones móviles, como visitas a páginas, búsquedas u otras acciones del usuario. Puede utilizar esta información para supervisar y analizar en tiempo real, así como en sistemas de almacenamiento de datos para procesar y crear informes sin conexión.
• Procesamiento de eventos de aplicaciones e infraestructura: use Streaming como punto de entrada unificado para los componentes en la nube con el fin de informar sobre sus eventos de ciclo de vida para auditoría, contabilidad y actividades relacionadas.

Puede comenzar a usar Streaming de la siguiente manera:

1. Cree un flujo utilizando la consola de Oracle Cloud Infrastructure o la operación API de CreateStream.
2. Configure productores para publicar mensajes en el flujo. Consulte Publicar mensajes.
3. Cree consumidores para leer y procesar los datos del flujo. Consulte Consumir mensajes.

También puede usar las API de Kafka para producir y consumir desde un flujo. Para obtener más información, consulte Uso de Streaming con Apache Kafka.

El rendimiento de Streaming está diseñado para escalar sin límites añadiendo particiones a un flujo. Sin embargo, existen ciertos límites a tener en cuenta al usar Streaming:

• El período máximo de retención de mensajes en un flujo es de siete días.
• El tamaño máximo de un mensaje único que se puede generar en un flujo es de 1 megabyte (MB).
• Cada partición puede manejar hasta 1 MB por segundo de rendimiento con cualquier número de solicitudes de escritura.
• Cada partición admite una velocidad máxima total de escritura de datos de 1 MB por segundo y una velocidad de lectura de 2 MB por segundo.

Streaming proporciona semántica basada en flujos. La semántica de flujos proporciona garantías estrictas de ordenación por partición, capacidad de reproducción de mensajes, cursores en el lado del cliente y escala horizontal masiva de rendimiento. Las colas no ofrecen estas características. Las colas se pueden diseñar para proporcionar garantías de pedidos si se utilizan colas FIFO, pero solo a costa de agregar una sobrecarga significativa en el rendimiento.

Un flujo es un registro de mensajes con particiones, que solo se puede anexar, en el que las aplicaciones productoras escriben datos y desde el cual las aplicaciones del consumidor leen datos.

Un grupo de flujos es una agrupación que puede utilizar para organizar y administrar flujos. Los grupos de flujos brindan facilidad operativa, ya que facilitan la capacidad de compartir ajustes de configuración en múltiples flujos. Por ejemplo, los usuarios pueden compartir configuraciones de seguridad como claves de cifrado personalizadas en el grupo de flujos para cifrar los datos de todos los flujos dentro del grupo. Un grupo de flujos también le permite crear un punto final privado para los flujos, ya que restringe el acceso a Internet a todos los flujos dentro de un grupo de flujos. Para aquellos clientes que utilizan la función de compatibilidad de Streaming con Kafka, el grupo de flujos sirve como raíz de un clúster virtual de Kafka, lo que permite que cada acción de dicho clúster virtual tenga el alcance del grupo de flujos.

Una partición es una unidad de rendimiento base en un flujo que permite la escala horizontal y el paralelismo de producción y consumo de un flujo. Una partición proporciona una capacidad de datos de 1 MB/seg. y una salida de datos de 2 MB/seg. Cuando crea un flujo, especifica el número de particiones que necesita en función de los requisitos de rendimiento de su aplicación. Por ejemplo, puede crear un flujo con diez particiones, en cuyo caso puede lograr un rendimiento de entrada de 10 MB/seg. y un rendimiento de salida de 20 MB/seg. a partir de un flujo.

Un mensaje es una unidad de datos codificada en Base64 almacenada en un flujo. El tamaño máximo de un mensaje que puede producir en una partición en un flujo es de 1 MB.

Una clave es un identificador utilizado para agrupar mensajes relacionados. Los mensajes con la misma clave se escriben en la misma partición. Streaming se asegura de que todo consumidor de una partición determinada lea siempre los mensajes de dicha partición exactamente en el mismo orden en que fueron escritos.

Un productor es una aplicación cliente que puede escribir mensajes en un flujo.

Un consumidor es una aplicación cliente que puede leer mensajes de uno o más flujos. Un grupo de consumidores es un conjunto de instancias que coordina los mensajes de todas las particiones de un flujo. En un momento dado, los mensajes de una partición específica solo pueden ser consumidos por un único consumidor del grupo.

Un cursor es un puntero a una ubicación en un flujo. Esta ubicación puede ser un puntero a un desplazamiento o momento específicos de una partición, o bien a la ubicación actual de un grupo.

Cada mensaje de una partición tiene un identificador llamado desplazamiento. Los consumidores pueden leer mensajes a partir de un desplazamiento específico y se les permite leer desde cualquier punto de desplazamiento que elijan. Los consumidores también pueden confirmar el último desplazamiento procesado a fin de poder reanudar su trabajo sin reproducir o perder un mensaje si detienen y luego reinician la tarea.

Streaming proporciona cifrado de datos de forma predeterminada, tanto en reposo como en tránsito. Streaming está completamente integrado con Oracle Cloud Infrastructure Identity and Access Management (IAM), que le permite utilizar políticas de acceso para otorgar permisos de forma selectiva a usuarios y grupos de usuarios. Al usar las API REST, también puede PUT y GET de forma segura sus datos de Streaming a través de puntos finales SSL con el protocolo HTTPS. Además, Streaming proporciona un aislamiento completo de datos a nivel de inquilino sin ningún problema tipo "vecino ruidoso".

Los datos de Streaming se cifran tanto en reposo como en tránsito; además, la integridad del mensaje está garantizada. Puede dejar que Oracle gestione el cifrado o puede utilizar Oracle Cloud Infrastructure Vault para almacenar y administrar de forma segura sus propias claves de cifrado si necesita cumplir con estándares específicos de cumplimiento o seguridad.

Puedes editar la configuración de cifrado de datos del grupo de flujos en cualquier momento si deseas cambiar entre el uso de "Cifrado proporcionado por claves de Oracle" y "Cifrado gestionado por claves administradas por el cliente". Streaming no impone ninguna restricción sobre cuántas veces se puede realizar esta actividad.

Streaming está completamente integrada con Oracle Cloud Infrastructure IAM. Cada flujo tiene un compartimento asignado. Los usuarios pueden especificar políticas de control de acceso basadas en roles que se pueden usar para describir reglas detalladas a nivel de inquilino, de compartimento o de flujo único.

La política de acceso se especifica en forma de “Allow <subject> to <verb> <resource-type> in <location> where <conditions>”.

La autenticación con el protocolo Kafka utiliza tokens de autenticación y el mecanismo SASL/PLAIN. Puede generar tokens en la página de detalles de usuario de la consola. Consulte Trabajar con tokens de autenticación para obtener más información. Le recomendamos que cree un grupo/usuario específico y otorgue a ese grupo permiso para administrar flujos en el compartimiento o inquilino apropiado. Luego puede generar un token de autenticación para el usuario que haya creado y usarlo en la configuración de su cliente de Kafka.

Los puntos finales privados restringen el acceso a una red virtual en la nube (VCN) específica dentro de su inquilino para que no se pueda acceder a sus flujos a través de Internet. Los puntos finales privados asocian una dirección IP privada dentro de una VCN al grupo de flujos, lo que permite que el tráfico de Streaming evite atravesar Internet. Para crear un punto final privado para Streaming, necesita acceso a una VCN con una subred privada en el momento de crear el grupo de flujos. Consulte Información sobre puntos finales privados y VCN y subredes para obtener más información.

Puede escribir el contenido de un flujo directamente en un depósito de Object Storage, normalmente para conservar los datos en el flujo para su almacenamiento a largo plazo. Esto se puede lograr usando Kafka Connect para S3 con Streaming. Para obtener más información, consulte la publicación del blog Publicar en Object Storage desde Oracle Streaming Service.

Puede asimilar datos desde una tabla en una instancia de Oracle Autonomous Transaction Processing. Para obtener más información, consulte la publicación en el blog Uso de Kafka Connect con Oracle Streaming Service y Autonomous Database.

Puede usar los SDK de Kafka para producir y consumir mensajes de Streaming, y puede usar el soporte integrado de Micronaut para Kafka. Para obtener más información, consulte la entrada en el blog Mensajería sencilla con Kafka Support de Micronaut y Oracle Streaming Service.

Para obtener más información, consulte la publicación en el blog Asimilar datos de IoT de brokers MQTT en OCI-Oracle Streaming Service, OCI-Kafka Connect Harness y Oracle Kubernetes Engine.

Oracle GoldenGate for Big Data ya cuenta con la certificación necesaria para integrarse con Streaming. Para obtener más información, consulte Conexión a Oracle Streaming Service en la documentación de Oracle GoldenGate for Big Data.

Debe utilizar Kafka JDBC Sink Connect para transportar directamente datos de transmisión a Oracle Autonomous Data Warehouse.

• La publicación del blog Uso de Kafka Connect con Oracle Streaming Service y Autonomous DB explica cómo usar un conector de fuente Kafka Connect, que envía datos de Oracle Autonomous Data Warehouse a flujos. Necesita lo contrario, un conector receptor.
• La publicación del blog Datos OSS a ADW casi en tiempo real explica cómo usar una tabla externa con una ruta de almacenamiento de objetos para obtener datos en Oracle Autonomous Data Warehouse.

Streaming utiliza un servicio Pay As You Go (pago por consumo), de modo que solo pagará por los recursos que use sin ningún costo por adelantado. Las dimensiones de precios incluyen:

• Precio de solicitud GET/PUT (gigabytes de datos transferidos)
• Precio del almacenamiento, determinado por la cantidad de horas del período de retención utilizadas para retener sus datos (gigabytes de almacenamiento por hora).

Consulte la Página de producto Streaming para obtener la información más reciente sobre precios.

Los precios líderes en la industria de Streaming se aseguran de que usted solo pague cuando use el servicio. Esto significa que no pagará ningún costo adicional por aquellos recursos que no use.

Streaming no cobra ningún costo adicional por mover datos dentro y fuera del servicio. Además, los usuarios pueden aprovechar el poder del Service Connector Hub para mover datos hacia y desde Streaming sin servidor sin costo adicional.

Streaming no cuenta actualmente con ninguna opción gratuita.

Identity and Access Management le permite controlar quién tiene acceso a sus recursos en la nube. Para usar los recursos de Oracle Cloud Infrastructure, debe tener el tipo de acceso requerido en una política escrita por un administrador, tanto si usa la consola o la API REST con un SDK, CLI u otras herramientas. La política de acceso se especifica en forma de

Allow <subject> to <verb> <resource-type> in <location> where <conditions>

Los administradores de una tenencia pueden usar la política

Allow group StreamAdmins to manage streams in tenancy

Esta política permite a un grupo específico de StreamAdmins hacer de todo con Streaming, desde crear, actualizar, enumerar hasta eliminar flujos y sus recursos relacionados. Sin embargo, siempre puede especificar políticas más granulares para que solo los usuarios seleccionados de un grupo utilicen solamente un subconjunto de actividades que pueden realizar en un flujo determinado. Si es nuevo en materia de políticas, consulte Introducción a las políticas y Políticas comunes. Si deseas profundizar en la redacción de políticas para Streaming, consulta Detalles del servicio Streaming en la referencia de las políticas de IAM.

Puede aprovisionar un flujo y todos sus componentes asociados, como políticas de IAM, particiones, configuraciones de cifrado, etc., usando Oracle Cloud infrastructure Resource Manager o el proveedor Terraform para Oracle Cloud Infrastructure. Para obtener más información sobre el proveedor de Terraform, consulte Tema sobre Terraform para el servicio Streaming.

Cuando crea un flujo, debe especificar cuántas particiones tiene el flujo. El rendimiento esperado de su aplicación puede ayudarle a determinar la cantidad de particiones para su flujo. Multiplique el tamaño medio de los mensajes por el número máximo de mensajes escritos por segundo para estimar el rendimiento esperado. Dado que una sola partición está limitada a una velocidad de escritura de 1 MB por segundo, un mayor rendimiento requiere particiones adicionales para evitar la limitación. Para ayudarle a administrar los picos de aplicación, le recomendamos que asigne particiones ligeramente más altas que su rendimiento máximo.

Usted crea particiones cada vez que crea un flujo, tanto en la consola como mediante programación.

Interfaz de usuario de la consola:

Mediante programación:

Crear un flujo

CreateStreamDetails streamDetails =

        CreateStreamDetails.builder()

                .compartmentId(compartmentId)

                .name(streamName)

                .partitions(partitions)

                .build();

SDK proporciona un ejemplo más detallado.

Streaming gestiona las particiones de forma interna para que usted no tenga que administrarlas. Un usuario no puede eliminar directamente una partición. Cuando elimina un flujo, se eliminan todas las particiones asociadas a dicho flujo.

El rendimiento de un flujo de Oracle Cloud Infrastructure está definido por una partición. Una partición proporciona 1 MB de entrada de datos por segundo y 2 MB de salida de datos por segundo.

El rendimiento de un flujo de Oracle Cloud Infrastructure se puede escalar agregando más particiones. No hay límites superiores teóricos en el número de particiones que puede contener un flujo. Sin embargo, cada tenencia de Oracle Cloud Infrastructure viene con un límite de particiones predeterminado de 5 para cuentas de tipo Universal Credits. Si necesita más particiones, siempre puede solicitar que se aumenten sus límites del servicio.

Siga estos pasos para solicitar un aumento de los límites del servicio:

1. En la esquina superior derecha de la consola, abra el menú Usuario y haga clic en Arrendamiento: <tenancy_name> .
   
   
2. Haga clic en Límites del servicio y, luego, haga clic en Solicitar un aumento del límite del servicio.
   
   
3. Complete el formulario, seleccionando Otros por Categoría de servicio y Otros límites por Recurso. En Razón de la solicitud, solicite aumentar el número de particiones para el servicio Streaming en su tenencia.

A continuación, se muestran algunas prácticas recomendadas para tener en cuenta a la hora de crear un flujo:

• Los nombres de los flujos deben ser únicos dentro de un grupo de flujos. Esto significa que puede crear dos flujos con el mismo nombre en el mismo compartimento solo si se encuentran en diferentes grupos de flujos.
• Una vez creado el flujo, no puede cambiar el número de particiones que contiene. Recomendamos asignar un número de particiones ligeramente más alto que su rendimiento máximo. Esto le ayudará a administrar los picos de aplicaciones.
• El período de retención de un flujo no puede cambiarse después de su creación. Por defecto, los datos se almacenan en un flujo durante 24 horas. Sin embargo, puede configurarse para retener los datos de 24 a 168 horas. La cantidad de datos almacenados en un flujo no tiene ningún impacto en el rendimiento del flujo.

Una vez creado el flujo y con el estado "Activo", puede comenzar a generar mensajes. Puede producir a un flujo utilizando la consola o mediante API.

Para la consola, vaya a la sección del servicio Streaming de la consola, ubicada en la pestaña Soluciones y plataforma > Análisis. Si ya ha creado flujos, seleccione un flujo en un compartimento y vaya a la página "Detalles del flujo". Haz clic en el botón "Producir mensaje de prueba" en la consola. Esto asignará aleatoriamente una clave de partición al mensaje y escribirá en una partición en el flujo. Puede ver este mensaje en la sección Mensajes recientes haciendo clic en el botón Cargar mensajes.

Para las API, puede utilizar las API de Oracle Cloud Infrastructure Streaming o las API de Kafka para producir en un flujo. El mensaje se publicará en una partición del flujo. Si hay más de una partición, especifique una clave para elegir a qué partición enviar el mensaje. De lo contrario, si no especifica ninguna clave, Streaming le asignará una al generar un UUID y enviará el mensaje a una partición aleatoria. De este modo, se asegura de que los mensajes sin clave se distribuyan uniformemente en todas las particiones. Sin embargo, le recomendamos que especifique siempre una clave de mensaje para que pueda controlar explícitamente la estrategia de partición de sus datos.

Los ejemplos de cómo producir mensajes a un flujo mediante Streaming SDK están disponibles en la documentación.

Al usar las API de Oracle Cloud Infrastructure para producir un mensaje, la lógica de la creación de particiones estará controlada por Streaming. Esto se conoce como creación de particiones en el lado del servidor. Como usuario, tú eliges a qué partición enviar en función de la clave. La clave se codifica y el valor resultante se usa para determinar el número de particiones al que enviar el mensaje. Los mensajes con la misma clave van a la misma partición. Los mensajes con claves diferentes pueden ir a particiones diferentes o a la misma partición.

Sin embargo, si usa las API de Kafka para producir a un flujo, el cliente de Kafka controla la partición y el particionador en el cliente de Kafka se responsabiliza de la lógica de la creación de particiones. Esto se conoce como creación de particiones en el lado del cliente.

Para garantizar una distribución uniforme de los mensajes, necesita un valor eficaz para las claves de sus mensajes. Para su creación, tenga en cuenta la selectividad y la cardinalidad de los datos de transmisión.

• Cardinalidad: tenga en cuenta la cantidad total de claves únicas que podrían generarse para el caso de uso concreto. Una cardinalidad de claves más alta suele significar que la distribución es mejor.
• Selectividad: tenga en cuenta la cantidad de mensajes con cada clave. Cuanto más alta sea la selectividad, más mensajes habrá por clave, lo que puede generar puntos calientes.

El objetivo es siempre lograr una alta cardinalidad y una baja selectividad.

Streaming garantiza lecturas y escrituras linealizables dentro de una partición. Si deseas asegurarte de que los mensajes con el mismo valor vayan a la misma partición, debes usar la misma clave para esos mensajes.

Una partición proporciona una velocidad de entrada de datos de 1 MB/seg. y admite hasta 1000 mensajes PUT por segundo. Por lo tanto, si el tamaño del registro es inferior a 1 KB, la velocidad de entrada de datos real de una partición será inferior a 1 MB/seg., limitada por el número máximo de mensajes PUT por segundo. Le recomendamos que produzca mensajes en lotes por las siguientes razones:

• Reduce el número de solicitudes PUT enviadas al servicio, lo que evita la aceleración.
• Ofrece mejor rendimiento.

El tamaño de un lote de mensajes no debe superar 1 MB. Si se supera este límite, se activa el mecanismo de aceleración.

Puede usar fragmentación o enviar el mensaje mediante Oracle Cloud Infrastructure Object Storage.

• Fragmentación: puede dividir cargas útiles grandes en múltiples fragmentos más pequeños que Streaming puede aceptar. Los fragmentos se almacenan en el servicio de la misma manera que los mensajes ordinarios no fragmentados. La única diferencia es que el consumidor debe conservar los fragmentos y combinarlos en el mensaje cuando se hayan recopilado todos los fragmentos. Los fragmentos de la partición se pueden entrelazar con mensajes ordinarios.
• Almacenamiento de objetos: se coloca una carga útil grande en al almacenamiento de objetos y solo se transfiere el puntero a esos datos. El receptor reconoce este tipo de carga útil de puntero, lee de forma transparente los datos de Object Storage y se los proporciona al usuario final.

Cuando un productor produce a una velocidad superior a 1 MB por segundo, la solicitud se acelera y se envía el error 429, demasiadas solicitudes al cliente avisándole de que se están recibiendo demasiadas solicitudes por segundo por partición.

Un consumidor es una entidad que lee mensajes de uno o más flujos. Esta entidad puede existir individualmente o formar parte de un grupo de consumidores. Para consumir mensajes, debe crear un cursor y usarlo posteriormente para leer los mensajes. Un cursor señala una ubicación en un flujo. Esta ubicación puede ser un desplazamiento o momento específicos en una partición, o bien la ubicación actual de un grupo. Según la ubicación desde la que desee leer, hay varios tipos de cursor disponibles: TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME y LATEST.

Para obtener más información, consulte la documentación sobre Consumir mensajes.

El método getLimit( ) de la clase GetMessagesRequest devuelve el número máximo de mensajes. Puede especificar cualquier valor hasta 10 000. De forma predeterminada, el servicio devuelve todos los mensajes que sea posible. Tenga en cuenta el tamaño medio de sus mensajes para evitar superar el rendimiento en el flujo. Los tamaños de lote de GetMessages se basan en el tamaño medio de los mensajes producidos en el flujo específico.

Streaming proporciona semántica de entrega "al menos una vez" a los consumidores. Recomendamos que las aplicaciones de consumidor se encarguen de los duplicados. Por ejemplo, cuando una instancia previamente inactiva del grupo de consumidores se vuelve a unir al grupo y comienza a consumir mensajes que no han sido confirmados por la instancia previamente asignada, es posible que se produzcan duplicados.

Se dice que un consumidor se está retrasando si produce más rápido de lo que puede consumir. Para determinar si su consumidor se está retrasando, puede utilizar la marca de tiempo del mensaje. Si el consumidor se está retrasando, considere la posibilidad de generar un nuevo consumidor para que se haga cargo de algunas de las particiones del primer consumidor. Si se está retrasando en una sola partición, la recuperación no es posible.

Considere las siguientes opciones:

• Aumentar el número de particiones en el flujo.
• Si el problema se debe a un punto caliente, cambie la estrategia de clave de mensaje.
• Reducir el tiempo de procesamiento de mensajes o gestionar solicitudes en paralelo.

Si deseas saber cuántos mensajes quedan por consumir en una partición determinada, usa un cursor de tipo LATEST, obtén el desplazamiento del siguiente mensaje publicado, y calcula el delta con el desplazamiento que estás consumiendo actualmente. Dado que no tenemos densidad de desplazamiento, solo podrá obtener una estimación aproximada. Sin embargo, si el productor dejó de producir, no podrá obtener dicha información porque nunca obtendrá el desplazamiento del siguiente mensaje publicado.

Se pueden configurar los consumidores de forma que consuman los mensajes como parte de un grupo. Las particiones de flujo se distribuyen entre los miembros de un grupo para que los mensajes de cualquier partición individual se envíen solamente a un único consumidor. Las asignaciones de partición se reequilibran a medida que los consumidores se unen al grupo o lo abandonan. Para obtener más información, consulte la documentación sobre Grupos de consumidores.

Los grupos de consumidores ofrecen estas ventajas:

• Cada instancia de un grupo de consumidores recibe mensajes de una o más particiones que se le asignan "automáticamente", y el resto de instancias no recibe los mismos mensajes (asignadas a diferentes particiones). Así podemos ampliar o reducir el número de instancias hasta el número de particiones de forma que una instancia lea una sola partición. En este caso, una nueva instancia que se una al grupo estará en estado inactivo, sin asignar a ninguna partición.
• Disponer de instancias que forman parte de diferentes grupos de consumidores significa que se proporciona un patrón de publicación-suscripción en el que los mensajes de particiones se envían a todas las instancias de los distintos grupos.
  Dentro del mismo grupo de consumidores, las reglas son las que se muestran en la siguiente imagen:
  
  
  En grupos diferentes, las instancias reciben los mismos mensajes, como se muestra en la siguiente imagen:
  
  Esto resulta útil cuando los mensajes dentro de una partición son de interés para aplicaciones diferentes que los procesarán de formas distintas. Queremos que todas las aplicaciones interesadas reciban los mismos mensajes de la partición.
• Cuando una instancia se une a un grupo, si el número de particiones disponibles es suficiente (es decir, no se ha alcanzado el límite de una instancia por partición), se inicia un reequilibrado. Las particiones se reasignan a las instancias actuales, y a la nueva. Del mismo modo, si una instancia sale de un grupo, las particiones se reasignan a las instancias restantes.
• Las confirmaciones de desplazamiento se gestionan automáticamente.

Hay un límite de 50 grupos de consumidores por flujo. Los grupos de consumidores son efímeros. Desaparecen cuando no se utilizan durante el período de retención del flujo.

Los siguientes componentes de Streaming tienen tiempos de espera:

• Cursor: mientras siga consumiendo mensajes, no es necesario que cree un cursor. Si se detiene el consumo de mensajes durante más de 5 minutos, debe volver a crear el cursor.
• Instancia: si una instancia deja de consumir mensajes durante más de 30 segundos, se elimina del grupo de consumidores y su partición se reasigna a otra instancia. Esto se conoce como reequilibrado.

El reequilibrado es el proceso en el que un grupo de instancias —que pertenecen al mismo grupo de consumidores— se coordina para poseer un conjunto de particiones mutuamente excluyentes que pertenecen a un flujo concreto. Cuando una operación de reequilibrado se completa correctamente para un grupo de consumidores, cada partición del flujo es propiedad de una o más instancias de consumidores dentro del grupo.

Cuando una instancia de un grupo de consumidores se vuelve inactiva porque no envía ningún latido durante más de 30 segundos o el proceso finaliza, se activa una actividad de reequilibrado dentro del grupo de consumidores. Esto se hace para manejar las particiones previamente consumidas por la instancia inactiva y reasignarla a una instancia activa. Del mismo modo cuando una instancia de un grupo de consumidores previamente inactivo se une al grupo, se activa un reequilibrado para asignar una partición desde la que comenzar a consumir. El servicio Streaming no ofrece ninguna garantía para reasignar la instancia a la misma partición cuando se vuelve a unir al grupo.

Para recuperarse de un error, debe almacenar el desplazamiento del último mensaje procesado para cada partición de forma que pueda empezar a consumir desde ese mensaje si necesita reiniciar el consumidor.

Nota: No almacene el cursor; los cursores caducan al cabo de 5 minutos.

No proporcionamos ninguna guía para almacenar el desplazamiento del último mensaje que haya procesado, por lo que puede usar el método que desee. Por ejemplo, puede almacenar el cursor en otro flujo, un archivo en una máquina virtual, o bien un depósito de Object Storage. Cuando se reinicia el consumidor, usted lee el desplazamiento del último mensaje procesado, crea un cursor de tipo AFTER_OFFSET y especifica el desplazamiento que acaba de recibir.

El servicio Streaming proporciona un punto final Kafka que pueden utilizar sus aplicaciones existentes basadas en Apache Kafka. Todo lo necesario es un cambio de configuración para tener una experiencia Kafka completamente administrada. La compatibilidad de Kafka con Streaming ofrece una alternativa a la ejecución de su propio clúster Kafka. Streaming es compatible con Apache Kafka 1.0 y las versiones de cliente más recientes y funciona con sus aplicaciones, herramientas y marcos existentes de Kafka.

Los clientes con aplicaciones Kafka existentes podrán migrar a Streaming simplemente cambiando los siguientes parámetros de su archivo de configuración Kafka.

security.protocol: SASL_SSL

sasl.mechanism: PLAIN

sasl.jaas.config: org.apache.kafka.common.security.plain.PlainLoginModule required username="{username}" password="{pwd}";

bootstrap.servers: kafka.streaming.{region}.com:9092

# Application settings

topicName: [streamOcid]

Para utilizar sus conectores Kafka con Streaming, cree una configuración de Kafka Connect utilizando la consola o la interfaz de línea de comandos (CLI). La API de Streaming llama a estas configuraciones arneses. Las configuraciones de Kafka Connect creadas en un compartimento determinado funcionan solo para los flujos del mismo compartimento. Puede utilizar múltiples conectores Kafka con la misma configuración de Kafka Connect. En aquellos casos en los que sea necesario producir o consumir flujos en compartimentos separados, o cuando se requiera más capacidad para evitar alcanzar los límites del acelerador en la configuración de Kafka Connect (por ejemplo, demasiados conectores o conectores con demasiados trabajadores), tú puedes crear más configuraciones de Kafka Connector.

Gracias a la compatibilidad de Kafka Connect con Streaming, puede aprovechar los muchos conectores existentes propios y de terceros para mover datos desde sus fuentes a sus destinos. Los conectores Kafka para productos Oracle incluyen:

• Oracle Cloud Infrastructure Object Storage (mediante el uso de Kafka Connect for S3)
• Conector de fuente Kafka Connect Amazon S3, para productores
• Conector receptor Kafka Connect Amazon S3, para consumidores
• Oracle Integration Cloud
• Oracle Database (mediante el uso de Kafka Connect JDBC)
• Oracle GoldenGate

Para obtener una lista completa de conectores de fuente y conectores receptores Kafka de terceros, consulte el centro oficial de Confluent Kafka.

Streaming está completamente integrado con Oracle Cloud Infrastructure Monitoring. En la consola, seleccione el flujo que quiera supervisar. En la página Detalles del flujo, vaya a la sección Recursos y haga clic en Producir gráficos de seguimiento para supervisar las solicitudes de los productores, o bien haga clic en Consumir gráficos de seguimiento para supervisar las métricas del lado del consumidor. Las métricas están disponibles a nivel de flujo y no a nivel de partición. Para obtener una descripción de las métricas de Streaming compatibles, consulte la documentación.

Cada métrica disponible en la consola proporciona las siguientes estadísticas:

• Rate (relación), Sum (suma) y Mean (media)
• Min (mínimo), Max (máximo) y Count (recuento)
• P50, P90, P95, P99 y P99.9

Estas estadísticas se ofrecen para los siguientes intervalos de tiempo:

• Automoción
• 1 minuto
• 5 minutos
• 1 hora

Para los productores, considere la posibilidad de configurar alarmas en las siguientes métricas:

• Latencia de mensajes PUT: un aumento en la latencia significa que los mensajes están tardando más en publicarse, lo que podría indicar problemas de red.
• Rendimiento total de los mensajes PUT:
  • Un aumento importante del rendimiento total podría indicar que se alcanzará el límite de 1 MB por segundo por partición y que ese evento activará el mecanismo de aceleración.
  • Una disminución importante podría significar que el productor del cliente tiene un problema o está a punto de detenerse.
• Registros regulados de mensajes PUT: es importante recibir notificaciones cuando se regulen los mensajes.
• Mensajes PUT fallidos: es importante recibir notificaciones si los mensajes PUT empiezan a fallar, a fin de que el equipo de operaciones pueda empezar a investigar los motivos.

Para los consumidores, considere la posibilidad de configurar las mismas alarmas basándose en las siguientes métricas:

• Latencia de Get Messages
• Rendimiento total de Get Messages
• Solicitudes aceleradas de Get Messages
• Error de Get Messages

Un flujo está en buen estado cuando está en estado Activo. Si puede producir en su flujo, y si la respuesta obtenida es correcta, significa que el flujo está en buen estado. Una vez producidos los datos en el flujo, los consumidores podrán acceder a ellos durante el período de retención configurado. Si las llamadas a la API de Get Messages devuelven niveles elevados de errores internos del servidor, significa que el servicio no está en buen estado.

Un flujo en buen estado también tiene métricas en buen estado:

• La latencia de Put Messages es baja.
• El rendimiento total de Put Messages se aproxima a 1 MB por segundo por partición.
• El número de registros acelerados de Put Messages se aproxima a 0.
• El número de errores de Put Messages se aproxima a 0.

• La latencia de Get Messages es baja.
• El rendimiento total de Get Messages se aproxima a 2 MB por segundo por partición.
• El número de solicitudes aceleradas se aproxima a 0.
• El número de errores de Get Messages se aproxima a 0.

La aceleración indica que el flujo es incapaz de manejar nuevas lecturas o escrituras. El mecanismo de aceleración se activa cuando se superan los siguientes umbrales:

• GetMessages: cinco llamadas por segundo o 2 MB por segundo por partición
• PutMessages: 1 MB por segundo por partición
• Operaciones en el plano de gestión y control, como CreateCursor, ListStream, etc.: cinco llamadas por segundo por flujo

Los detalles sobre los errores de la API están en la documentación.