En este artículo, exploraremos la creación de un algoritmo para gestionar datos financieros en nuestro datalake, utilizando ArcticDB como backend y el proveedor de datos End Of Day Historical (EODH). Este algoritmo cumplirá con los siguientes requisitos:

Requisitos

1. Formato universal estilo Pandas.
2. ArcticDB como backend.
3. Gestión automática de bases de datos dentro del datalake.
4. Gestión de metadatos.

Datos Utilizados

La información almacenada en el datalake se utilizará como fuente de datos para el motor de backtesting. Utilizaremos EODH como nuestra data bróker debido a su asequibilidad y atención al cliente. Sus fuentes de datos de calidad y la variedad de información que proporcionan lo hacen una elección sólida.

EODHD, compra packs de datos a mercados, y los redistribuye entre sus clientes, no se dedica al 100% a la recolección de datos, pero esto es una ventaja, dado que es más fácil que un data-bróker pequeño tenga un fallo en la recolección de datos, pero que NASDAQ lo haga es más difícil, porque en caso de que ocurriera, más gente está utilizando estos datos de forma profesional, y solucionarían el error.

¿De dónde obtiene EODHD los datos?

Pues citando lo que comentan en su website:

For end-of-day (EOD) and delayed data, we have direct contracts with several exchanges for their corresponding data streams. We get USA data from Nasdaq Cloud API.

The UK data is derived directly from the London Stock Exchange Group (LSE), with more than 22,000 tickers in total.

We get European markets’ data from Cboe Europe Equities (Cboe) which covers more than 60 exchanges from Western and Eastern European markets.

For Australian feeds, we have a direct agreement with the Australian Stock Exchange (ASX). Delayed and End of Day NEO Exchange Data for NEO and TSX/TSXV powered by Quotemedia.com.

Tipos de Datos

Dentro de los datos que nos ofrece él data-bróker, encontramos una infinidad de categorías, pero básicamente los podríamos clasificar en estos grandes grupos.

Datos descriptivos

Los datos descriptivos, es un subconjunto de datos fundamentales, donde se consideran los más relevantes, para poder establecer las características de la compañía con la que se está tratando.

Estos datos incluyen, el exchange, la divisa, la fecha de la IPO, su sector, subsector, número de trabajadores, market cap etc.

Se utiliza para crear universos desde metadata de los tickers. Como, por ejemplo, crear un universo con las acciones con una IPO superior a 1960 y del sector financiero. O cualquier otra combinación de características.

Datos de Precio

Los datos de OHLCV (Open, High, Low, Close, Volume) serán fundamentales para nuestro análisis. Es la forma básica en el cual se distribuye la información de precio, y la más cotidiana

Datos de Eventos Corporativos

Los eventos corporativos incluyen información exógena al precio, pero necesaria para entender los datos no ajustados. Se recomienda realizar el ajuste de los datos en el propio backtester, y no utilizar jamás datos ajustados.

En el primer caso, vemos los splits, y en el segundo los dividendos.

Dentro de los dividendos, vemos que hay diferentes fechas, pero en la siguiente imagen se representa el ciclo de dividendo.

Datos Fundamentales

Información obtenida de los estados contables de las compañías, que incluyen ratios contables, sectores y competidores, etc. En este caso la información es una snapshot actual. Pero se podría ajustar la base de datos, para que guardara estos valores por cada dia, para poder realizar modelos en función de datos fundamentales.

Datos Alternativos

Los datos alternativos incluye información como noticias, sentimiento de mercado, relaciones en la cadena de suministro, entre otros, datos de los cuales se puede descubrir alpha, dados que es la tendencia actual el incluirlos, tradicionalmente no se han utilizado.

Los datos alternativos hacen referencia a toda la información, correlacionada en algún sentido con objeto de estudio actual, y que mediante su inclusión en los modelos, se obtienen nuevas formas de extraer alpha del activo. Podríamos hablar de noticias, como de pronósticos de ventas, o cualquier tipo de información que, modelizada, puede crear o añadir alpha a un modelo concreto.

Algoritmo para Alimentar el Datalake

Vamos a diseñar un algoritmo para gestionar nuestras bases de datos en el datalake y transformar los datos del bróker a nuestro formato de datalake, generando precios y metadatos. La estructura del algoritmo será similar a la siguiente:

• Recopilar símbolos
• Recopilar datos de esos símbolos en el data-broker
• Transformar esa información a un formato Pandas-Like
• Enviar esa información a nuestro datalake mediante arcticdb

all_tickers = recopile_symbols_by_filter_results
for each symbol in all_tickers:
    download, transform, and send price data to datalake
    download, transform, and send dividend and split data to datalake
    download, transform, and send metadata to datalake

Gestionando las Bases de Datos dentro del Datalake

Un datalake está compuesto por muchas librerías (databases). Para trabajar en nuestro datalake, necesitamos tener unas databases para creadas, para poder poner un orden, dentro de toda la información volcada en el datatake

Implementaremos un mecanismo simple para gestionar las bases de datos en el datalake usando ArcticDB. El siguiente código verifica la consistencia del datalake:

dataz = ['prices.stocks.us.stable', 'divs.stocks.us.stable', 'splits.stocks.us.stable', 'meta.stable']

for d in dataz:
    if d not in ac.list_libraries():
        ac.create_library(d)
        print('[DATA CHECK]:', d.upper(), 'CREATING NEW DATASTORAGE')
        print('DATA STORAGE CREATED!')
    else:
        print('[DATA CHECK]:', d.upper(), 'IS IN THE DATALAKE')
        print('Listing Symbols:', ac.get_library(d).list_symbols())

print('[QA] - DATALAKE v2 carnivore READY :) :) :)')

Este código asegura que las bases de datos necesarias existan en el datalake y las crea si no existen.

Filtrado de Tickers

El filtrado de tickers se puede realizar de varias maneras, ya sea consultando metadatos o manualmente. En este ejemplo, filtramos acciones pertenecientes al Nasdaq Stock Exchange:

# Pseudocódigo
ts = pd.DataFrame(call.get_exchange_symbols('US'))
ts = ts[ts['Exchange'] == 'NASDAQ']
ts = ts[ts['Type'] == 'Common Stock']
all_tickers = ts['Code'].tolist()
tickers_in_lake = prices.list_symbols()
all_tickers = [valor + ".US" for valor in all_tickers]
tickers = [ticker for ticker in all_tickers if ticker not in tickers_in_lake]

Este proceso evita la descarga de tickers duplicados y ahorra tiempo y consultas API.

Conclusiones Finales

Una vez que tenemos algunos tickers en nuestro datalake, el siguiente paso es construir un entorno de trabajo profesional basado en tecnologías como Docker, JupyterLab, Zipline y Linux para realizar tareas de investigación y backtesting.

¡La cantidad de información disponible hoy en día es invaluable! ArcticDB resuelve todos los problemas relacionados con la infraestructura para almacenar y consultar dataframes de gran escala con una latencia insignificante, permitiendo trabajar incluso en timeframes muy pequeños. Este artículo proporciona una base sólida para implementar un datalake compatible con herramientas como Zipline en el futuro.

¡Para descargar el código completo, deberás estar registrado!

Código Completo