O armazenamento de dados históricos é a retenção de eventos passados de mercado e de trading em um formato que possa ser consultado ou reproduzido.
Essa definição esconde a questão operacional: pode ser barato manter um ano de arquivos comprimidos, mas caro ou demorado demais transformá-los em um teste válido. A resposta depende do que cada evento registra, de como a reprodução trata o timing e o estado, e da rapidez com que as equipes precisam obter resultados.
Defina a reprodução antes de calcular o custo do arquivo
Comece decidindo o que significa "reprodução" para a carga de trabalho. Um backtest de research pode precisar de trades e cotações de top of book. A reprodução de um incidente de execução pode exigir atualizações de profundidade completa, confirmações de ordens, execuções, rejeições, alterações de configuração e os timestamps exatos usados pelo sistema em produção.
São conjuntos de dados diferentes, com demandas distintas de armazenamento e processamento. Um fluxo de cotações pode ser útil para simular preços, mas não comprova como uma decisão de matching ou roteamento se comportou diante de mudanças na profundidade do livro de ofertas. Da mesma forma, apenas os logs da aplicação podem mostrar que uma ordem foi enviada, sem preservar o estado do mercado e as entradas da decisão interna que explicam o motivo.
Registre as fontes de eventos e o nível de fidelidade necessário antes de estimar a capacidade. Inclua feeds das venues, eventos internos de ordens e execuções, dados de referência, informações de relógio e sequência, além da versão das regras de normalização.
Mantenha as mensagens brutas dos fornecedores quando as licenças permitirem. Registros normalizados são mais fáceis de consultar, mas as mensagens brutas ajudam a diagnosticar alterações no parser e a reproduzir defeitos nos dados.
Deixe explícita a semântica dos horários. Armazene o horário do evento na exchange e o horário de recebimento local, e preserve os números de sequência quando disponíveis.
Uma reprodução que ordena tudo por um único timestamp pode ocultar falhas no feed, desvios de relógio ou mensagens atrasadas. Em investigações, esses detalhes podem ser mais importantes do que o número de casas decimais em um campo de preço.
Converta as taxas de eventos em capacidade anual
Estime o volume com base nas taxas médias e de pico medidas, não em um único dia tranquilo. Registre os bytes por evento depois de incluir enquadramento, metadados e índices.
Em seguida, calcule a ingestão diária, o número de pregões, os anos de retenção e o número de réplicas. Para uma primeira estimativa, 250 sessões é uma premissa anual útil de planejamento para um mercado que opera nos dias úteis, mas inclua fins de semana e logs de tempo corrido se o sistema os registrar.
Os números abaixo são faixas típicas de planejamento para um conjunto de dados lógico, não números auditados de nenhum fornecedor. Os volumes diários variam conforme o número de instrumentos, a cobertura de venues, a profundidade e a atividade. Os números anuais usam 250 sessões e excluem backups, réplicas e índices derivados.
| Conjunto de dados | Volume bruto típico por sessão | Volume comprimido típico por sessão | Volume comprimido típico por ano | Taxa típica de reprodução sequencial |
|---|---|---|---|---|
| Cotações L1 e trades | 10-100 GB | 3-30 GB | 0.75-7.5 TB | 20-200 MB/s |
| Atualizações do livro de ofertas L2 | 0.2-2 TB | 60-800 GB | 15-200 TB | 50-500 MB/s |
| Eventos de ordens e execuções | 2-30 GB | 0.5-10 GB | 0.1-2.5 TB | 5-100 MB/s |
As taxas de compressão não são fixas. Formatos colunares e codificação delta podem reduzir campos repetitivos, enquanto payloads de alta entropia comprimem menos. Meça a taxa em sessões movimentadas e tranquilas que sejam representativas. Reserve capacidade para mudanças de schema, correções tardias e gravações paralelas. Um conjunto de dados nominal de 100 TB pode exigir duas ou três vezes essa capacidade quando réplicas, snapshots e cópias de trabalho são contabilizados.
Para um modelo aproximado, multiplique os bytes comprimidos médios por sessão pelo número de sessões por ano, pelos anos de retenção e pelo fator de replicação. Acrescente os índices e a saída temporária da reprodução separadamente. Essa última etapa evita que as equipes tratem o custo do arquivo como se fosse o custo total de um backtest.
Calcule o custo das camadas de armazenamento, não apenas dos bytes
O NVMe local de alta velocidade é útil para conjuntos de reprodução ativos e índices. O armazenamento de objetos costuma ser adequado para o arquivo principal, pois escala sem exigir o gerenciamento de uma grande infraestrutura de discos. Camadas de arquivo frio podem reduzir o custo de armazenamento, mas o tempo e as taxas de recuperação tornam-nas inadequadas para um conjunto de dados que pesquisadores esperam abrir imediatamente.
Para um planejamento amplo, as faixas típicas de mercado são de aproximadamente US$80-250 por TB-mês para armazenamento provisionado de alto desempenho, US$15-30 para armazenamento de objetos acessado com frequência e US$1-5 para arquivo frio, antes das taxas de recuperação e requisição. Os preços variam conforme a região, a redundância, o desempenho e o contrato. Use-os como ponto de partida e, depois, calcule o custo do desenho real com o fornecedor relevante.
Para 100 TB, essas faixas implicam cerca de US$96,000-300,000 por ano em armazenamento de alto desempenho, US$18,000-36,000 em armazenamento de objetos acessado com frequência ou US$1,200-6,000 em cobranças de arquivo frio, antes da recuperação. Se os 100 TB forem apenas uma cópia, duas réplicas duplicam o volume armazenado. Se a reprodução exigir a preparação de 20 TB do arquivo toda semana, os custos de recuperação e armazenamento temporário podem eliminar boa parte da economia aparente.
Separe o modelo de custos nestes componentes:
- Dados primários: eventos comprimidos, mensagens brutas, dados de referência e conjuntos de dados derivados.
- Proteção: réplicas, snapshots, retenção de backups e cópias entre regiões.
- Acesso: recuperação, requisições, transferência de rede e espaço de preparação.
- Processamento: descompressão, validação, indexação e workers de simulação.
Defina a retenção conforme a finalidade. Um operador pode manter uma janela curta de dados em armazenamento rápido para investigações diárias, um histórico mais longo em armazenamento de objetos para research e um conjunto mais restrito de registros de compliance conforme a política de retenção da empresa.
Não presuma que um único período de retenção deve valer para todas as classes de eventos. Verifique as licenças de dados das venues e os requisitos regulatórios antes de reduzir ou mover registros.
A velocidade de reprodução é um problema de processamento e do fluxo de dados
Um ano com 250 sessões de 6.5 horas por sessão contém 1,625 horas de tempo de mercado. Na velocidade normal, o processamento serial leva cerca de 68 dias. A dez vezes a velocidade normal, a duração teórica cai para cerca de 6.8 dias.
A cem vezes a velocidade normal, são cerca de 16 horas. Esses números excluem inicialização, validação, lacunas, feriados de mercado e o tempo gasto para gravar os resultados.
Uma reprodução mais rápida não depende apenas da largura de banda do armazenamento. O gargalo pode estar na descompressão, na decodificação de eventos, em uma estratégia de thread único, em bloqueios, em gravações no banco de dados ou na necessidade do simulador de preservar a ordem dos eventos.
Meça o fluxo completo. Um leitor de arquivos que transmite a 500 MB/s não adianta se o processador de eventos só consegue lidar com uma fração da taxa de mensagens resultante.
Paralelize entre datas, instrumentos ou estratégias independentes quando a lógica do teste permitir. Evite dividir uma estratégia com estado em pontos arbitrários, a menos que cada worker possa reconstruir o estado necessário a partir de um checkpoint.
Para reproduzir um incidente, uma janela limitada em torno do evento costuma ser mais útil do que uma execução de um ano. Para testes de risco anuais, checkpoints diários podem reduzir o tempo de reinicialização, mas valide se as execuções com checkpoints e as contínuas produzem resultados equivalentes.
Registre quatro métricas para cada carga de reprodução: bytes comprimidos lidos por segundo, eventos decodificados por segundo, utilização de CPU por etapa e tempo total de execução. Registre o conjunto de dados de teste, a versão do software e o número de workers. Assim, é possível comparar mudanças no desempenho da reprodução, em vez de depender de impressões. A cobertura de infraestrutura de trading da Trading Technology oferece um contexto mais amplo para as decisões de plataforma relacionadas a esse trabalho.
Faça o arquivo funcionar na operação
O armazenamento só é útil se os operadores puderem localizar, validar e restaurar os dados. Atribua a cada partição um manifesto com seu intervalo de datas, venue, feed, versão do schema, compressão, checksums e cobertura de sequências. Mantenha o manifesto separado dos arquivos que descreve e monitore partições ausentes e mudanças inesperadas de volume.
Antes de definir um nível de serviço, teste uma restauração real. A recuperação de uma camada fria pode levar minutos ou horas, enquanto o diagnóstico de um índice corrompido ou de um schema incompatível pode demorar mais.
Defina metas separadas para research de rotina e resposta a incidentes. A segunda pode justificar uma cópia em armazenamento de acesso rápido das sessões recentes, mesmo que a maior parte do arquivo fique em um armazenamento de menor custo.
Use esta lista de verificação na primeira análise de capacidade:
- Meça pelo menos cinco sessões representativas, incluindo uma sessão movimentada e outra volátil.
- Calcule o volume anual comprimido por conjunto de dados e, depois, acrescente réplicas, índices e preparação temporária.
- Faça benchmark da reprodução na mesma instância e camada de armazenamento propostas para uso em produção.
- Execute uma restauração e uma reprodução de ponta a ponta a partir de dados arquivados, não de uma cópia local de desenvolvimento.
- Configure alertas para lacunas de ingestão, falhas de checksum, vencimento da retenção e crescimento do armazenamento acima da previsão.
Mantenha visível a linhagem dos dados brutos e transformados. Se o normalizador mudar, registre quais partições foram reconstruídas e quais testes usaram a saída anterior. Isso permite que engenharia e operações diferenciem o comportamento do mercado das mudanças no pipeline quando um resultado se altera.
Nesta semana, meça uma sessão movimentada da ingestão à reprodução e use seus bytes, taxa de eventos e tempo de conclusão para montar o primeiro modelo anual de capacidade.
Perguntas frequentes
Quanto armazenamento é necessário para um ano de dados de ticks?
Depende da cobertura de venues, da profundidade, do formato dos eventos e da compressão. As faixas típicas de planejamento podem ir de menos de 1 TB para um conjunto de dados L1 restrito a centenas de terabytes para um histórico L2 amplo ao longo de 250 sessões, antes de réplicas e índices.
Quanto tempo leva para reproduzir um ano de dados de mercado?
Um ano com 250 sessões de 6.5 horas por sessão corresponde a 1,625 horas na velocidade normal, ou cerca de 68 dias se executado em série. A reprodução a dez vezes a velocidade normal reduz o tempo teórico para cerca de 6.8 dias, mas os limites de processamento e a lógica com estado podem tornar as execuções reais mais lentas.
O armazenamento de objetos é adequado para o histórico de trading?
O armazenamento de objetos acessado com frequência pode ser adequado para o arquivo principal quando as cargas de reprodução toleram sua latência e taxa de transferência. Mantenha conjuntos de dados ativos ou janelas de resposta a incidentes em armazenamento mais rápido se prepará-los a partir do arquivo impedir o cumprimento das metas operacionais.
O que deve ser retido para uma reprodução válida do mercado?
Retenha os fluxos de eventos necessários ao teste, além de timestamps, informações de sequência, dados de referência relevantes e a versão da normalização. Investigações de execução também podem precisar de confirmações de ordens, execuções, rejeições e entradas das decisões internas.
Como uma equipe pode estimar os custos de armazenamento de dados históricos?
Meça sessões representativas, calcule o volume anual comprimido e multiplique pelos anos de retenção e pelo número de réplicas. Acrescente índices, snapshots, recuperação, preparação, transferência de rede e processamento da reprodução como itens separados.
Plataformas · Software · Provedores · Mercados