¿Cómo debo almacenar los datos de las garrapatas?

Question

¿Cómo debo almacenar los datos de las garrapatas? Por ejemplo, si tengo una cuenta de operaciones de IB, ¿cómo debo descargar y almacenar los datos de ticks directamente en mi ordenador? ¿Qué software debo utilizar?

Answer 1

Usar IBrokers de R va a ser la ruta más fácil. Un ejemplo rápido de captura de datos en el disco sería:

library(IBrokers)
tws <- twsConnect()
aapl.csv <- file("AAPL.csv", open="w")

# run an infinite-loop ( <C-c> to break )
reqMktData(tws, twsSTK("AAPL"), 
           eventWrapper=eWrapper.MktData.CSV(1), 
           file=aapl.csv)

close(aapl.csv)
close(tws)

Esto enviará una salida estilo CSV al disco. Además, los datos pueden almacenarse en objetos xts dentro del bucle, que pueden añadirse o rellenarse para proporcionar un objeto constante en memoria que se utilice para el análisis. Los objetos pueden ser compartidos con muchas herramientas - incluyendo el uso del paquete RBerkeley en CRAN para compartir objetos con otros programas con enlaces Berkeley DB. Este último enfoque, si se gestiona de forma inteligente es muy, muy rápido.

Dado el límite de símbolos de IB (100 concurrentes más o menos) y las actualizaciones de 250ms - R normalmente puede manejar todo esto sin romper a sudar (es decir, la JVM que ejecuta el TWS de IB o incluso el cliente IBGateway es probable que sea muy superior al proceso R/IBrokers en términos de uso de la CPU).

Incluso puede ampliar la sintaxis anterior para registrar más de un símbolo pasando una lista de Contratos, aumentando el número en el eWrapper, y asegurándose de tener una lista adecuada de archivos en los que escribir.

En términos de algo más cercano al almacenamiento/acceso a largo plazo, los paquetes a los que se refirió Josh (mmap e indexación) también son muy útiles. He dado charlas con algunos ejemplos de datos de opciones básicas que tienen un tamaño de 3-4GB sin columnas derivadas (12GB en total), y puedo sacar usando la sintaxis de subconjuntos al estilo de R cualquier subconjunto que necesite casi instantáneamente. por ejemplo, encontrar 90k+ contratos para AAPL en 2009 (de 70MM de filas) tomó decenas de milisegundos. Todo sin guardar nada en la RAM, y todo corriendo en un portátil con 2GB de RAM.

Es probable que pronto consiga reunir más material de presentación para estos últimos paquetes, y daré alguna charla en la próxima R/Finanzas conferencia en Chicago. También estoy planeando algunos talleres públicos a través de lemnica relacionados con R e IB para 2011.

Answer 2

¿Qué quieres hacer después con los datos de los ticks? ¿Ejecutar análisis? Puedes guardar los datos de los ticks en un archivo plano para que el software se preocupe, pero sería muy lento acceder a ellos más tarde.

En cambio, lo ideal es guardar los datos:

• Orientado a columnas: todos los elementos de un campo se almacenan de forma contigua para mejorar el almacenamiento en caché.
• Binario: todos los elementos están listos para su uso inmediato; no es necesario el reparto léxico

Hay varias bases de datos orientadas a las columnas, aunque por el momento no hay ninguna de calidad de producción que sea de código abierto. Puede probar la versión no comercial de q/kdb+ a ver qué te parece, aunque es una curva de aprendizaje enorme si no estás acostumbrado.

Otra cosa que hay que tener en cuenta a la hora de almacenar los datos de las garrapatas es el soporte físico. Lo ideal sería:

• Almacenamiento local - la búsqueda a través de NFS va a ser dolorosa
• Estado sólido: la recuperación del disco también es dolorosa

Answer 3

Si está planeando analizar los datos más tarde en R, debería echar un vistazo a la función paquetes de indexación y mmap . Aunque, como @chrisaycock Dicho esto, tendrá que guardar los datos en un formato binario orientado a columnas.

Si está descargando los datos de IB con R, utilizando IBrokers Si lo desea, puede escribir su propio eWrapper para almacenar los datos en el formato que desee.

Answer 4

Estoy utilizando sólo un sistema de archivos para almacenar los datos brutos de los ticks. Estoy usando búferes de protocolo para permitir fácilmente que varios idiomas consuman los datos. Parte de la razón es que estoy moviendo más cosas en EC2 de Amazon para utilizar sus instancias de computación GPU y el almacenamiento de datos en blobs permite una fácil integración con S3. Me encantaría tener un almacén de columnas adecuado, pero por el momento esto ha funcionado bien con poca sobrecarga de desarrollo.

También hemos ajustado nuestras cargas de trabajo para sortear estas limitaciones. Normalmente, los datos se trabajan durante minutos u horas después de ser recuperados. Hacemos un desarrollo puro de algo y no tenemos (ni necesitamos) un acceso de baja latencia en una interfaz de usuario.

Answer 5

Estoy planeando utilizar una plataforma de procesamiento de eventos complejos como Esper o StreamBase para manejar los datos de tick entrantes para generar eventos de compra/venta. Los datos de los ticks también serían enviados a través de una cola (0MQ o RabbitMQ) para ser escritos en un almacén de datos (archivo o base de datos SQL). De este modo, dispongo de los datos necesarios para realizar un backtest o un análisis en R o MATLAB, a la vez que puedo actuar sobre los datos en "tiempo real". Parece que, dependiendo de los volúmenes y la frecuencia de las transacciones, una base de datos SQL puede convertirse en un cuello de botella si se quiere actuar sobre los datos casi en tiempo real, ya que el uso de una base de datos SQL requeriría que se eligiera un disparador o un período de tiempo para generar una consulta.