Расшифровка сгоревшей программной свечи

Жжёт код? Расшифровка сгоревшей программной свечи раскроет тайны битых данных! Спасём проект и зажжём свет заново.

Сгоревшая программная свеча – термин, который стал популярным среди трейдеров, аналитиков и разработчиков торговых систем; Он обозначает ситуацию, когда данные о ценовом движении (обычно в виде candlestick‑chart) повреждены, обрезаны или полностью «сгорели» в результате сбоев программного обеспечения, проблем с хранением или некорректного экспорта.

В этой статье мы разберём:

  • Что такое программная свеча и какие данные она содержит;
  • Типичные причины «сгорания» свечи;
  • Методы восстановления и расшифровки повреждённого файла;
  • Практический пример восстановления данных;
  • Лучшие практики профилактики потери информации.

Программная свеча: базовые понятия

В контексте финансовых рынков свеча (англ. candle или candlestick) – графический элемент, отображающий четыре ключевых цены за выбранный интервал:

  1. Open – цена открытия;
  2. High – максимальная цена;
  3. Low – минимальная цена;
  4. Close – цена закрытия.

Программные свечи – это запись этих четырёх параметров в бинарном или текстовом файле, часто в виде массивов JSON, CSV, HDF5 или proprietary‑форматов (например, .candles, .tck).

Структура типичного файла свечей

{
 "symbol": "EURUSD",
 "interval": "1m",
 "candles": [
 {"timestamp": 1714281600, "open":1.0745, "high":1.0750, "low":1.0740, "close":1.0748},
 {"timestamp": 1714281660, "open":1.0748, "high":1.0753, "low":1.0745, "close":1.0750},
 ...
 ]
}

Если файл повреждён, часть записей может быть обрезана, заменена мусором или полностью исчезнуть – именно это называют «сгоревшей свечой».

Почему «сгорает» программная свеча?

Существует несколько типичных сценариев, приводящих к потере данных:

  • Аппаратные сбои: падения питания, сбои SSD/HDD, ошибки контроллера.
  • Системные ошибки: некорректное завершение процесса (SIGKILL), отсутствие flush‑операций.
  • Ошибки сериализации: несоответствие схемы данных, попытка записать NaN или Infinity в бинарный формат.
  • Конфликты доступа: одновременная запись нескольких потоков без блокировок.
  • Неправильный экспорт/импорт: использование устаревших библиотек, потеря байтов при конвертации в CSV.

Подходы к расшифровке (восстановлению) сгоревшей свечи

Существует три основных стратегии:

Восстановление из резервных копий

Самый надёжный способ – использовать резервные копии (snapshot, ежедневные бэкапы). Если они есть, задача сводится к простому копированию.

Реконструкция из «мусорных» байтов

Когда копий нет, необходимо попытаться вычленить полезные куски из повреждённого файла. Основные шаги:

  1. Определить границы записи: в большинстве форматов каждая свеча имеет фиксированную длину (например, 32 байта в бинарном виде). Поиск шаблона timestamp (обычно 4‑8 байт) помогает найти начала записей.
  2. Отбросить «шум»: использовать CRC, контрольные суммы или простую проверку диапазонов (price ∈ [0, 10 000]) для фильтрации некорректных записей.
  3. Восстановить пропущенные поля: если в записи отсутствует high или low, их можно оценить из соседних свечей (интерполяция).
  4. Перезаписать в чистый контейнер: сформировать новый JSON/CSV файл.

Использование специализированных утилит

Для популярных форматов (MetaTrader .hst, NinjaTrader .ticks) существуют готовые инструменты:

  • HSTRepair – восстанавливает файлы .hst от MetaTrader.
  • TickFixer – восстанавливает бинарные тик‑файлы NinjaTrader.
  • Библиотеки pandas, numpy в Python можно использовать для «чистки» CSV‑файлов.

Пошаговый гайд: восстановление CSV‑файла со сгоревшими свечами

Шаг 1. Оценка повреждения

import pandas as pd

try:
 df = pd.read_csv('candles_broken.csv')
except pd.errors.ParserError as e:
 print('Ошибка парсинга:', e)

Если парсер выдаёт ParserError, значит файл содержит строки с неправильным числом колонок.

Шаг 2. Чтение «по кускам»

chunks = []
for chunk in pd.read_csv('candles_broken.csv', chunksize=1000, error_bad_lines=False):
 # Оставляем только корректные строки
 valid = chunk.dropna(subset=['timestamp','open','high','low','close'])
 chunks.append(valid)

df_clean = pd.concat(chunks, ignore_index=True)

Параметр error_bad_lines=False (в новых версиях on_bad_lines='skip') позволяет пропустить ошибочные строки.

Шаг 3. Проверка диапазонов цен

# Оставляем только строки, где цены в разумных пределах
mask = (df_clean['open'] > 0) & (df_clean['high'] > df_clean['open']) & (df_clean['low'] < df_clean['open'])
df_clean = df_clean[mask]

Шаг 4. Заполнение пропусков

# Линейная интерполяция временных рядов
df_clean = df_clean.set_index('timestamp')
df_clean = df_clean.interpolate(method='linear')
df_clean = df_clean.reset_index

Шаг 5. Сохранение восстановленного файла

df_clean.to_csv('candles_restored.csv', index=False)
print('Восстановлено записей:', len(df_clean))

Пример восстановления бинарного файла .hst (MetaTrader)

Формат .hst состоит из заголовка (128 байт) и последовательных записей по 32 байта:

struct HSTRecord {
 uint32 time; // timestamp
 double open;
 double high;
 double low;
 double close;
 uint32 volume;
};

Если файл обрезан, последние записи могут быть «половинчатыми». Ниже – простой скрипт на Python, который читает только полные записи.

import struct

RECORD_SIZE = 32
HEADER_SIZE = 128

def read_hst(path):
 with open(path, 'rb') as f:
 header = f.read(HEADER_SIZE) # можно сохранить в отдельный файл
 data = f.read
 records = []
 for i in range(0, len(data) ⏤ len(data) % RECORD_SIZE, RECORD_SIZE):
 chunk = data[i:i+RECORD_SIZE]
 time, open_, high, low, close, volume = struct.unpack('<IdddddI', chunk)
 records.append({
 'timestamp': time,
 'open': open_,
 'high': high,
 'low': low,
 'close': close,
 'volume': volume

 })
 return records
records = read_hst('EURUSD_1M.hst')
print('Прочитано записей:', len(records))

Полученный список records можно экспортировать в CSV и далее обработать как в пункте 4.

Лучшие практики профилактики «сгорания» свечей

  • Регулярные резервные копии: каждый день сохранять копию в облаке (AWS S3, Azure Blob).
  • Флеш‑буфер и fsync: после записи вызвать file.flush; os.fsync(file.fileno) для гарантии записи на диск.
  • Контроль целостности: хранить CRC32 или SHA‑256 для каждой партии данных.
  • Транзакционная запись: использовать базы данных (SQLite, PostgreSQL) вместо «сырых» файлов.
  • Логирование ошибок: фиксировать любые исключения записи; при повторных ошибках переключаться на резервный файл.
  • Ограничение доступа: обеспечить, чтобы одновременно не писали несколько процессов без блокировок.

«Сгоревшая программная свеча» – реальная проблема, с которой сталкиваются как индивидуальные трейдеры, так и крупные брокеры. Однако, вооружившись правильными методами анализа бинарных/текстовых форматов, можно восстановить большую часть утраченных данных. Ключевые шаги: определить структуру, отсеять мусор, применить интерполяцию и, главное, наладить систему резервного копирования, чтобы в будущем избежать подобных ситуаций.

Помните: лучше предотвратить потерю данных, чем потом тратить часы на их восстановление.


Статья написана в 2026 году, основана на актуальных практиках работы с финансовыми данными и общих принципах восстановления файлов.