Retos prácticos del almacenamiento y la gestión de datos de mercado

Question

Estoy tratando de almacenar los datos de entrada de los mercados de valores de Estados Unidos en una base de datos.

Cuáles son los problemas más comunes que surgen con respecto al almacenamiento y la gestión de un conjunto de datos tan grande. Algunos que ya conozco son:
1) Datos que faltan: puede añadir algunos datos ficticios o no incluirlos en el backtest.
2) La marca de tiempo no coincide.
3) Bloquear las operaciones/limpiar los datos.

¿Hay algo más que se me pueda escapar y, si es así, cómo puedo resolverlo?
El objetivo principal es hacer un backtest de las estrategias. Los datos no serán enormes: sólo datos de nivel 1 para unas 20 acciones.

Answer 1

He diseñado grandes almacenes de datos (con un hardware de entre 3 y 10 millones de dólares). Los retos que ha planteado @jharonfe son válidos, pero no me parece que sean los más interesantes en su caso (20 acciones, L1).

Por ejemplo, no hay ninguna razón para que tu sistema, incluso si está diseñado de forma muy ingenua y no está optimizado, se quede atrás con 20 símbolos.

También ha mencionado la falta de datos: es posible que haya visto esta cuestión en algunos de los textos más antiguos, disponibles públicamente, sobre cómo almacenar los datos del mercado. Tenga en cuenta que estos textos se escribieron hace años; hoy en día, cuando las redes de intercambio están muy sobreaprovisionadas, esto no es un problema.

He aquí algunas en las que vale la pena pensar:

1. Sesiones comerciales no homogéneas. Por ejemplo, IBM sigue cotizando hoy en día, pero hubo un periodo en el que su ticker dejó de cotizar debido a las investigaciones antimonopolio. La gente que diseña su almacenamiento de datos para gestionar los vencimientos (por ejemplo, las opciones) tiende a pensar más en estos temas, pero la renta variable tiene sus propias peculiaridades. Además, si sus acciones proceden de diferentes bolsas, los distintos mercados tienen diferentes calendarios de vacaciones.
2. Sesgo de supervivencia . Esto es bastante obvio. Si hoy sabes que no puedes operar con XYZ y lo dejas fuera de tu universo de símbolos, y sin embargo estabas recogiendo datos para XYZ hace 1 año, estás incurriendo en un sesgo de supervivencia al permitir que tu motor de backtesting sea consciente de esto y no pueda hacer backtest en XYZ hace 1 año o excluir XYZ de tu universo de búsqueda hace 1 año. La razón por la que esto se convierte en un reto es que es fácil de describir, pero implica la interconexión de varias piezas de software, que la gente tiende a evitar en la primera pasada de la arquitectura de su plataforma.
3. Rupturas comerciales . En ciertos lugares, se puede obtener información después de la impresión de que un comercio se ha anulado. Esto plantea problemas a la hora de decidir cómo manejar el relleno en su backtest, pero la gente suele ignorar este tipo de caso límite en su diseño de primera pasada.
4. Pérdida e historial transaccional. Como puedes ver en un tema común entre mis 3 puntos anteriores, la solución es a menudo simplemente ignorar el problema y preocuparse por él más tarde. Esto está bien siempre y cuando no se pierdan los datos cuando se vuelva a tratar el problema. Esta es una de las razones por las que el uso de un SGBD puede ser superior a un almacén plano, porque muchos SGBD son transaccionales y tienen un historial de confirmaciones.
5. Acciones corporativas. Las acciones pasan por fusiones y adquisiciones, desdoblamientos, etc.

Answer 2

He encontrado un par de problemas de ingeniería al persistir datos de ticks de alta frecuencia:

1. La base de datos puede crecer rápidamente. Por ejemplo, un símbolo de gran actividad como el SPY puede tener un par de cientos de miles de eventos comerciales en un día normal. Si se hace un seguimiento de todos los cambios de comilla NBBO, éstos son de 2 a 4 veces más numerosos que los eventos comerciales. Si se hace un seguimiento de todos los cambios de comilla BBO (que se incluyen en los datos de Nivel 1), entonces se multiplica el número de eventos por el número de centros de datos de mercado que se están siguiendo. Esto puede suponer unos cuantos millones de registros para un símbolo durante un día. Y en los días de alta volatilidad, este tráfico puede duplicarse, triplicarse o más.
2. Puede haber ocasiones en las que los datos de las garrapatas lleguen más rápido de lo que se puede persistir en la base de datos. El flujo de datos de ticks llega en ráfagas, y está particularmente ocupado en la apertura y el cierre del mercado. He encontrado que un procesador de colas que implementa el patrón productor-consumidor es el mejor diseño para representar este flujo de trabajo.
3. En los casos en los que los datos de garrapatas llegan demasiado rápido y su procesador se queda atrás, querrá tener métodos de inserción masiva para ayudar a su procesador a ponerse al día.
4. El diseño del modelo de datos para los datos intradiarios puede ser complicado. Los datos intradiarios son diferentes a los datos interdiarios. Por un lado, esto es obvio. Por otro lado, me parece que la mayoría de los ingenieros trabajan primero con datos interdiarios y se encuentran con problemas de datos intradía en segundo lugar (yo incluido). De ahí que traigan sus modelos de datos de lo que ha funcionado en los datos interdiarios, lo cual es natural. Aunque hay similitudes, los datos intradía a menudo violan muchas de las suposiciones que forman parte de los modelos de datos interdiarios. Mi sugerencia es que, al principio, el código sea lo más ágil posible. Sea deliberado a la hora de comprometerse con un diseño de modelo de datos. En la medida de lo posible, déjese flexibilidad para refactorizar.