Feeds de datos de mercado: plan de 30 días para valorar cada tick

Al final de una semana complicada, un responsable de operaciones estudia un panel: el gasto en feeds ha aumentado, una estrategia informa de precios obsoletos y el registro de incidentes muestra dos eventos de recuperación. La cifra principal es la de paquetes por segundo. No muestra qué actualizaciones fueron importantes, cuánto costaron ni dónde se perdió tiempo.

Una revisión útil mide el costo de una actualización que permite tomar decisiones, no solo el costo de la factura de un proveedor. En 30 días, el equipo puede establecer esa medida, detectar cuellos de botella y tomar una decisión controlada sobre la profundidad, el modo de entrega o el proveedor.

Definir cuánto cuesta un tick

"Tick" puede referirse a un mensaje de una bolsa, un cambio en un precio mostrado o una actualización consumida por una estrategia. No son conceptos intercambiables. Un mensaje puede actualizar varios niveles del libro. Una estrategia puede rechazar una actualización por obsoleta, ignorarla porque el instrumento está inactivo o usarla para modificar una orden.

Empiece por calcular el costo mensual total de cada mercado y ruta del feed. Incluya las tarifas de las bolsas por visualización y uso no visualizado, los cargos por usuarios profesionales, los derechos de redistribución, los cargos del proveedor y de conectividad, y la infraestructura asignada a la captura, la recuperación y la normalización.

El modelo exacto de tarifas depende de la bolsa, los permisos y el contrato. No dé por sentado que una suscripción a un feed incluye permiso para redistribuir datos a clientes o usarlos en todos los sistemas internos.

Después, presente por separado dos medidas: el costo por actualización aceptada y el costo por actualización utilizada por una estrategia. La primera ayuda a comparar rutas de feeds. La segunda muestra si los datos son pertinentes para una carga de trabajo concreta. Indique en el informe el denominador y el periodo. Un promedio mensual puede ocultar un mercado con actividad concentrada en ráfagas o un conjunto de instrumentos con poco volumen.

Un feed barato que llega después de la ventana de decisión no es barato para esa estrategia.

Para conocer el contexto más amplio de las plataformas, la cobertura de infraestructura de Trading Technology aborda las cuestiones operativas que influyen en la elección de proveedores y plataformas.

Establecer una referencia de latencia y capacidad

Antes de cambiar nada, capture los mismos eventos en la interfaz de red, el gestor del feed, el normalizador y la entrada de la estrategia. Registre las marcas de tiempo de la bolsa cuando estén disponibles, las marcas de tiempo locales de recepción, los números de secuencia y el instrumento.

Use relojes sincronizados, pero mantenga la hora de la bolsa y el tiempo de procesamiento local en campos separados. La diferencia entre dos marcas de tiempo no equivale automáticamente a la latencia de red.

Los rangos que aparecen a continuación son valores habituales para la planificación, no garantías de servicio. Varían según el mercado, la combinación de mensajes, el hardware, la ubicación y el límite de medición. El ancho de banda corresponde a cada mercado en periodos de alta actividad. La demora añadida se mide desde el punto de acceso indicado del proveedor o desde la recepción del paquete hasta el gestor que lo consume, por lo que las comparaciones deben hacerse con medidas equivalentes.

Use estas cifras como referencia para dimensionar, no como especificación de compra. Un feed puede ser rápido en un día tranquilo y aun así fallar durante una subasta de apertura o un episodio de volatilidad.

Registre la demora p50, p99 y máxima, además de las brechas de secuencia, la duración de la recuperación, los paquetes descartados y la profundidad de la cola. Mantenga métricas separadas para cada mercado y gestor del feed. Para más información sobre ingeniería, consulte Trading Technology.

Ejecutar la implementación de 30 días

Concéntrese durante el primer mes. No cambie a la vez el feed, el hardware y los parámetros de la estrategia, o la comparación no permitirá saber qué provocó el cambio en el resultado.

1. Días 1-5, inventario. Enumere los mercados, productos, rutas de feeds, permisos, consumidores, puntos de conexión y cargos mensuales. Identifique las suscripciones duplicadas y los feeds que no sirven a ninguna carga de trabajo activa. Confirme si cada uso corresponde a visualización, uso no visualizado o redistribución.
2. Días 6-12, instrumentación. Añada métricas de brechas de secuencia, pérdida de paquetes y recuperación. Marque la hora de recepción del paquete, la finalización de la decodificación, la normalización y la entrega a la estrategia. Si la captura completa es demasiado costosa, tome muestras de mensajes, pero conserve los contadores y registros completos de los eventos de brecha.
3. Días 13-20, medir bajo carga. Recopile datos de una sesión normal y de al menos un periodo de alta actividad. Compare las tasas de mensajes y las distribuciones de latencia con el uso de CPU, los paquetes descartados por la NIC, la profundidad de la cola y la recolección de basura o la presión de memoria. Reproduzca ráfagas capturadas en un entorno de prueba para comprobar si el gestor se pone al día tras un pico.
4. Días 21-26, probar una alternativa. Compare un proveedor, una suscripción de profundidad reducida o la consolidación con la ruta actual. Use los mismos instrumentos, periodo y consumidor. Revise la pérdida de actualizaciones y las decisiones de la estrategia, además del ancho de banda y la latencia p99.
5. Días 27-30, decidir y documentar. Calcule el costo mensual por actualización aceptada y por actualización utilizada por una estrategia. Registre el riesgo operativo, el impacto en los permisos, el método de reversión y el responsable. Mantenga el feed actual hasta que la alternativa haya superado las pruebas de recuperación y conmutación por error.

Hacer que las métricas sean operativas

Un panel solo es útil si permite actuar. Fije umbrales a partir de las referencias observadas y las necesidades de la estrategia, y genere alertas ante un deterioro sostenido, no por una única muestra ruidosa. Entre las comprobaciones habituales se incluyen:

• Brechas de secuencia por canal, con las horas de inicio y finalización de la recuperación.
• Paquetes descartados en la NIC y profundidad de la cola de la aplicación, para distinguir la pérdida de red de la sobrecarga del gestor.
• Latencia desde la bolsa hasta la recepción y desde la recepción hasta la estrategia, con valores p99 y máximos.
• Mensajes recibidos frente a actualizaciones aceptadas y consumidas, desglosados por mercado y grupo de instrumentos.
• Cambios en los permisos o las conexiones que puedan afectar los derechos de visualización, el uso no visualizado o la redistribución.

Concilie los contadores. Si el gestor informa de más actualizaciones aceptadas que mensajes recibidos, las definiciones son incorrectas o la instrumentación cuenta dos veces. Si el feed tiene poca actividad mientras el recuento de paquetes sigue siendo alto, revise las retransmisiones, las rutas duplicadas y los instrumentos irrelevantes. Asigne un responsable a cada alerta y documente la acción de recuperación, incluido cuándo cambiar a una línea secundaria.

Elegir el feed según la carga de trabajo

Más profundidad no siempre es mejor. Una estrategia de horizonte corto puede necesitar cambios completos del libro de órdenes y una latencia de cola baja. Un control de riesgo o un flujo de ejecución más lento puede funcionar con datos del mejor nivel del libro o con una consolidación controlada. La decisión depende de si las actualizaciones omitidas cambian una orden, un límite de riesgo o un precio mostrado al cliente, no de la preferencia por el feed más completo.

Considere también el costo operativo. El multicast directo puede reducir la demora de entrega, pero la empresa asume más trabajo de decodificación, secuenciación, recuperación y supervisión. Un feed gestionado puede simplificar la integración, pero añade dependencia del proveedor, un límite de latencia distinto y posibles restricciones a la recuperación personalizada. Compare la cobertura de soporte y el comportamiento ante fallos, además de las tarifas recurrentes.

Conserve la referencia resultante junto con el inventario de feeds y revísela después de cambios en los mercados, lanzamientos de estrategias y renovaciones de contratos. Para una estrategia sensible a cambios de precios de corta duración, use 5 ms como referencia de planificación, no como objetivo universal. Compare su propia latencia p99 desde el feed hasta la estrategia con 5 ms.

#latencia de datos de mercado #costes de datos de mercado #datos de ticks #tarifas de datos de los mercados #datos de mercado multicast #gestor de feeds #infraestructura de datos de mercado #supervisión de feeds de datos