4 votos

Manejo y abstracción de datos de backtesting frente a la negociación en vivo

Soy un individuo tratando de construir un sistema de comercio que idealmente será eventualmente escalable a 1-15 segundos de resolución estrategias de comercio intradía. Estoy teniendo algunos problemas para entender la diferencia entre los feeds de datos aplicados a un backtest y los feeds de datos aplicados al comercio en vivo y tengo algunas preguntas específicas:

¿Las pruebas retrospectivas y las operaciones en vivo suelen basarse en la misma abstracción o funcionan con el mismo motor de negociación/procesamiento?

Mi primer pensamiento es que sí, ya que lo ideal sería que funcionaran de forma idéntica para la precisión y el realismo del backtesting

¿Las fuentes de datos en vivo y los conjuntos de datos históricos suelen ofrecer una interfaz idéntica en sus respectivos manejadores para consultar/recuperar sus conjuntos de datos?

El estado actual de mi sistema sólo funciona con datos históricos para las pruebas retrospectivas, con el motor de negociación actualizando el paso de tiempo del propio manejador de datos. Esto no parece ser una solución viable para los datos de mayor frecuencia en tiempo real, ya que se basa en el motor de comercio para actualizar la alimentación de datos en lugar de la alimentación de datos de controlador. Después de algunas investigaciones, parece que un mecanismo basado en consultas sería más adecuado para los datos en tiempo real, ya que da el control de la gestión de datos al manipulador. Aunque tengo problemas para entender cómo los datos históricos estáticos podrían cargarse en el flujo de datos para ser procesados de forma idéntica.

¿Cómo se procesan los flujos de datos de forma más eficaz?

Bajo el supuesto de que tanto los datos históricos como los datos en vivo se introducen en los flujos de eventos. Tengo problemas para entender cómo esos flujos se hacen para ser consultados o de otra manera predecible recuperable por el motor de comercio. Una base de datos de series de tiempo parece ser la más lógica debido a su capacidad para manejar el volumen de datos y almacenar suficientes datos retrospectivos, pero la mayoría de las bases de datos de series de tiempo son bastante caras para un individuo, y no estoy seguro de que sea la forma más rentable de procesar el volumen de datos. ¿Qué otras opciones hay para proporcionar un motor de consulta eficaz tanto para los datos históricos como para los vivos?

Probablemente estoy un poco fuera de mi profundidad aquí ya que todavía soy bastante nuevo en esto, así que por favor dígame si estoy tomando el enfoque equivocado a esto. También me gustaría tener más información sobre cómo se diseñan estos sistemas, o cualquier otro recurso/libro para leer sobre los métodos de manejo de datos.

5voto

Diondon Puntos 1

Sí, recomiendo hacer backtests históricos y operaciones en vivo tan similares como sea posible. De este modo, se reduce la fuente de variabilidad cuando inevitablemente se observan resultados diferentes en las pruebas retrospectivas y en vivo.

¿Las fuentes de datos en vivo y los conjuntos de datos históricos suelen ofrecer una interfaz idéntica en sus respectivos manejadores para consultar/recuperar sus conjuntos de datos?

¿Las pruebas retrospectivas y las operaciones en vivo suelen basarse en el mismo motor de negociación/procesamiento?

Son dos cosas diferentes. Ambas son importantes.

Tener la misma interfaz le permite reutilizar el mismo código tanto para el backtest como para la producción. Podría decirse que esto es un poco más importante porque:

  • La mayoría de las estrategias son máquinas de estado muy complejas, y es muy difícil implementar la misma estrategia dos veces con dos conjuntos diferentes de interfaces.
  • De todos modos, es casi imposible utilizar exactamente el mismo "motor de procesamiento" para el backtest y la producción, ya que el primero lee de un archivo mientras que el segundo lee de una suscripción multidifusión/unicast, y el primero pasa la mayor parte del tiempo esperando mientras que el segundo puede seguir leyendo. He visto a algunas empresas llegar a extremos para unificar los dos, incluso haciendo que su plataforma de backtesting reproduzca capturas de paquetes enteros sólo para hacer backtest de 1 símbolo, con beneficios insustanciales.
  • El propósito de un "backtest" no es necesariamente obtener métricas precisas como el PnL, y podría haber muchos otros objetivos que le hagan diseñar su bucle de backtest (presumiblemente una parte importante de su "motor de procesamiento") para priorizar la velocidad (rendimiento) sobre la precisión, o el paralelismo sobre el procesamiento en serie, asíncrono sobre síncrono, etc.

¿Cómo se procesan los flujos de datos de forma más eficaz?

Consulte mis otras publicaciones sobre bases de datos.

Finanhelp.com

FinanHelp es una comunidad para personas con conocimientos de economía y finanzas, o quiere aprender. Puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X