feat: add market data architecture and complete migration through build 039
This commit is contained in:
@@ -0,0 +1,585 @@
|
||||
# Market Intelligence Research Methodology
|
||||
|
||||
## Контроль документа
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Документ | Market Intelligence Research Methodology |
|
||||
| Тип документа | Engineering Standard |
|
||||
| Версия | 1.0 |
|
||||
| Статус | Release |
|
||||
| Проект | Dzentra |
|
||||
| Подсистема | Market Intelligence |
|
||||
| Язык | Русский |
|
||||
|
||||
---
|
||||
|
||||
# Назначение
|
||||
|
||||
Настоящий документ определяет единую методологию исследования источников рыночной информации.
|
||||
|
||||
Методология применяется при исследовании любых источников данных независимо от:
|
||||
|
||||
- биржи;
|
||||
- транспортного протокола;
|
||||
- версии API;
|
||||
- способа получения данных.
|
||||
|
||||
Настоящий документ определяет общий порядок проведения исследований, но не содержит перечень конкретных проверок.
|
||||
|
||||
Конкретные проверки определяются специализированными документами Research Checklist.
|
||||
|
||||
---
|
||||
|
||||
# Фундаментальная модель исследования
|
||||
|
||||
Подсистема Market Intelligence строится на трех последовательно связанных уровнях.
|
||||
|
||||
```text
|
||||
ФАКТЫ
|
||||
│
|
||||
▼
|
||||
ЗНАНИЯ
|
||||
│
|
||||
▼
|
||||
РЕШЕНИЯ
|
||||
```
|
||||
|
||||
Каждый следующий уровень может строиться исключительно на основании предыдущего.
|
||||
|
||||
---
|
||||
|
||||
## Уровень 1. Факты
|
||||
|
||||
Факты представляют собой объективную информацию, получаемую непосредственно от биржи.
|
||||
|
||||
На данном уровне отсутствует какая-либо интерпретация данных.
|
||||
|
||||
Примеры фактов:
|
||||
|
||||
- bid;
|
||||
- ask;
|
||||
- volume;
|
||||
- trade;
|
||||
- candle;
|
||||
- order book;
|
||||
- funding rate;
|
||||
- open interest;
|
||||
- liquidation.
|
||||
|
||||
Результатом данного уровня являются подтвержденные информационные сущности (Information Facts).
|
||||
|
||||
---
|
||||
|
||||
## Уровень 2. Знания
|
||||
|
||||
Знания представляют собой интерпретацию подтвержденных фактов.
|
||||
|
||||
На данном уровне строится модель состояния рынка.
|
||||
|
||||
Примеры знаний:
|
||||
|
||||
- тренд;
|
||||
- импульс;
|
||||
- ликвидность;
|
||||
- волатильность;
|
||||
- дисбаланс стакана;
|
||||
- направление движения;
|
||||
- фаза рынка;
|
||||
- вероятность продолжения движения;
|
||||
- вероятность разворота.
|
||||
|
||||
Знания никогда не извлекаются непосредственно из API.
|
||||
|
||||
Они формируются исключительно на основании подтвержденных фактов.
|
||||
|
||||
---
|
||||
|
||||
## Уровень 3. Решения
|
||||
|
||||
Решения представляют собой результат работы торговой системы.
|
||||
|
||||
Примеры решений:
|
||||
|
||||
- открыть позицию;
|
||||
- закрыть позицию;
|
||||
- увеличить позицию;
|
||||
- уменьшить позицию;
|
||||
- изменить Stop Loss;
|
||||
- изменить Take Profit;
|
||||
- отказаться от входа в рынок.
|
||||
|
||||
Решения принимаются исключительно на основании знаний.
|
||||
|
||||
Факты не используются для принятия торговых решений напрямую.
|
||||
|
||||
---
|
||||
|
||||
# Основные архитектурные принципы
|
||||
|
||||
## Принцип последовательного построения знаний
|
||||
|
||||
Построение подсистемы Market Intelligence всегда выполняется в следующем порядке:
|
||||
|
||||
1. Исследование фактов.
|
||||
2. Подтверждение фактов.
|
||||
3. Построение модели знаний.
|
||||
4. Принятие решений.
|
||||
|
||||
Нарушение данной последовательности считается архитектурной ошибкой.
|
||||
|
||||
---
|
||||
|
||||
## Принцип отсутствия предположений
|
||||
|
||||
Подсистема Market Intelligence не использует предположения в качестве знаний.
|
||||
|
||||
Любая информационная сущность должна иметь подтвержденный источник происхождения.
|
||||
|
||||
Любое знание должно иметь подтвержденную зависимость от фактов.
|
||||
|
||||
Любое решение должно иметь подтвержденную зависимость от знаний.
|
||||
|
||||
---
|
||||
|
||||
## Принцип полной трассируемости
|
||||
|
||||
Любое торговое решение должно быть полностью прослеживаемо до фактов, полученных непосредственно от биржи.
|
||||
|
||||
Для любого решения должна существовать непрерывная цепочка происхождения информации.
|
||||
|
||||
```text
|
||||
Биржа
|
||||
│
|
||||
▼
|
||||
Факты
|
||||
│
|
||||
▼
|
||||
Знания
|
||||
│
|
||||
▼
|
||||
Решение
|
||||
```
|
||||
|
||||
Каждый переход между уровнями должен быть объяснимым и проверяемым.
|
||||
|
||||
---
|
||||
|
||||
## Принцип воспроизводимости
|
||||
|
||||
Любой вывод, содержащийся в документации Market Intelligence, должен быть воспроизводим.
|
||||
|
||||
Повторное выполнение исследования должно приводить к тем же результатам при одинаковых исходных условиях.
|
||||
|
||||
---
|
||||
|
||||
# Цель исследования
|
||||
|
||||
Любое исследование должно ответить на главный вопрос.
|
||||
|
||||
> **Какие факты о состоянии рынка предоставляет исследуемый источник данных?**
|
||||
|
||||
Исследование не должно ограничиваться описанием структуры API.
|
||||
|
||||
Результатом исследования является выявление подтвержденных информационных сущностей, содержащихся в исследуемом источнике данных.
|
||||
|
||||
---
|
||||
|
||||
# Основные принципы исследования
|
||||
|
||||
## Исследуется источник информации
|
||||
|
||||
Объектом исследования является не программный интерфейс API, а информация, передаваемая данным источником.
|
||||
|
||||
---
|
||||
|
||||
## Исследуются фактические данные
|
||||
|
||||
Все выводы должны подтверждаться одновременно:
|
||||
|
||||
- официальной документацией;
|
||||
- фактическими сообщениями биржи;
|
||||
- экспериментальными исследованиями.
|
||||
|
||||
Если подтверждение отсутствует, вывод считается неподтвержденным.
|
||||
|
||||
---
|
||||
|
||||
## Исследуются информационные факты
|
||||
|
||||
Исследование должно отвечать не на вопрос
|
||||
|
||||
> Какие поля содержит JSON?
|
||||
|
||||
а на вопрос
|
||||
|
||||
> Какие факты о состоянии рынка передает данный источник?
|
||||
|
||||
---
|
||||
|
||||
## Исследования являются воспроизводимыми
|
||||
|
||||
Каждый вывод должен подтверждаться экспериментом, который может быть повторен независимо от автора исследования.
|
||||
|
||||
---
|
||||
|
||||
## Принцип минимально необходимого исследования
|
||||
|
||||
Исследование должно проводиться в объеме, достаточном для подтверждения или опровержения информации, содержащейся в официальной документации.
|
||||
|
||||
Если официальная документация содержит однозначное описание исследуемого аспекта и фактическое поведение API соответствует этому описанию, дополнительные эксперименты не проводятся.
|
||||
|
||||
Экспериментальные исследования выполняются только в случаях, когда:
|
||||
|
||||
- документация отсутствует;
|
||||
- документация неоднозначна;
|
||||
- документация противоречит фактическому поведению API;
|
||||
- требуется определить неописанное поведение системы.
|
||||
|
||||
---
|
||||
|
||||
# Общий процесс исследования
|
||||
|
||||
Любое исследование выполняется в строго определенной последовательности.
|
||||
|
||||
Каждый следующий этап может начинаться только после завершения предыдущего.
|
||||
|
||||
---
|
||||
|
||||
## Этап 1. Изучение официальной документации
|
||||
|
||||
Цель этапа — определить ожидаемое назначение исследуемого источника данных.
|
||||
|
||||
Результат этапа:
|
||||
|
||||
- понимание назначения endpoint;
|
||||
- понимание способа взаимодействия;
|
||||
- понимание ожидаемой структуры сообщений;
|
||||
- определение перечня исследуемых сущностей.
|
||||
|
||||
На данном этапе не делаются выводы о фактическом поведении источника данных.
|
||||
|
||||
---
|
||||
|
||||
## Этап 2. Получение фактических данных
|
||||
|
||||
Цель этапа — получить реальные сообщения исследуемого источника.
|
||||
|
||||
Получение данных выполняется посредством специализированных Probe.
|
||||
|
||||
Результат этапа:
|
||||
|
||||
- реальные сообщения биржи;
|
||||
- реальные ответы endpoint;
|
||||
- реальные особенности поведения;
|
||||
- материал для последующего анализа.
|
||||
|
||||
---
|
||||
|
||||
## Этап 3. Определение типов сообщений
|
||||
|
||||
Для исследуемого источника необходимо определить:
|
||||
|
||||
- все типы сообщений;
|
||||
- назначение каждого типа сообщений;
|
||||
- сообщения, содержащие рыночную информацию;
|
||||
- служебные сообщения;
|
||||
- сообщения управления;
|
||||
- сообщения об ошибках.
|
||||
|
||||
Результатом этапа является классификация сообщений исследуемого источника.
|
||||
|
||||
---
|
||||
|
||||
## Этап 4. Исследование структуры сообщений
|
||||
|
||||
Для каждого типа сообщений необходимо определить:
|
||||
|
||||
- перечень полей;
|
||||
- тип каждого поля;
|
||||
- обязательность поля;
|
||||
- допустимые значения;
|
||||
- ограничения;
|
||||
- взаимное расположение данных.
|
||||
|
||||
Результатом этапа является описание структуры каждого типа сообщений.
|
||||
|
||||
---
|
||||
|
||||
## Этап 5. Исследование семантики
|
||||
|
||||
Для каждого поля необходимо определить:
|
||||
|
||||
- фактическое назначение;
|
||||
- происхождение информации;
|
||||
- ограничения использования;
|
||||
- степень достоверности;
|
||||
- взаимосвязь с другими полями.
|
||||
|
||||
На данном этапе запрещается использовать предположения как подтвержденные знания.
|
||||
|
||||
---
|
||||
|
||||
## Этап 6. Выделение информационных фактов
|
||||
|
||||
На основании исследованных сообщений необходимо определить:
|
||||
|
||||
- какие информационные факты содержит источник;
|
||||
- какие факты можно вычислить непосредственно из сообщения;
|
||||
- какие факты отсутствуют.
|
||||
|
||||
Результатом этапа является перечень информационных фактов, предоставляемых исследуемым источником.
|
||||
|
||||
---
|
||||
|
||||
## Этап 7. Исследование поведения
|
||||
|
||||
Для исследуемого источника необходимо определить:
|
||||
|
||||
- особенности изменения данных;
|
||||
- последовательность сообщений;
|
||||
- взаимосвязь изменений;
|
||||
- особенности временного поведения;
|
||||
- ограничения источника;
|
||||
- особенности протокола.
|
||||
|
||||
Результатом этапа является описание поведения исследуемого источника.
|
||||
|
||||
---
|
||||
|
||||
## Этап 8. Сравнение с другими источниками
|
||||
|
||||
Для каждого информационного факта необходимо определить:
|
||||
|
||||
- существует ли аналогичный источник;
|
||||
- подтверждается ли эквивалентность;
|
||||
- имеются ли различия;
|
||||
- какой источник является приоритетным.
|
||||
|
||||
Эквивалентность считается подтвержденной только после экспериментальной проверки.
|
||||
|
||||
---
|
||||
|
||||
## Этап 9. Формирование экспериментальных выводов
|
||||
|
||||
После завершения исследования все выводы должны быть разделены на следующие категории:
|
||||
|
||||
- подтвержденные;
|
||||
- предварительно подтвержденные;
|
||||
- гипотезы;
|
||||
- опровергнутые.
|
||||
|
||||
Только подтвержденные выводы могут использоваться при построении Information Mapping.
|
||||
|
||||
---
|
||||
|
||||
## Этап 10. Подготовка Endpoint Research
|
||||
|
||||
Результаты исследования оформляются отдельным документом Endpoint Research.
|
||||
|
||||
Документ должен содержать:
|
||||
|
||||
- описание источника;
|
||||
- результаты исследований;
|
||||
- подтвержденные информационные факты;
|
||||
- особенности поведения;
|
||||
- результаты сравнений;
|
||||
- экспериментальные выводы.
|
||||
|
||||
Endpoint Research является основным документом, описывающим исследуемый источник данных.
|
||||
|
||||
---
|
||||
|
||||
## Этап 11. Обновление Information Mapping
|
||||
|
||||
После подтверждения информационных фактов обновляется документ:
|
||||
|
||||
> Dzengi Market Intelligence Information Mapping.
|
||||
|
||||
В Information Mapping включаются только подтвержденные информационные факты.
|
||||
|
||||
---
|
||||
|
||||
## Этап 12. Обновление Information Model
|
||||
|
||||
Если исследование выявило новые информационные факты или новые взаимосвязи между ними, обновляется документ:
|
||||
|
||||
> Dzentra Market Intelligence Information Model.
|
||||
|
||||
---
|
||||
|
||||
## Этап 13. Обновление Knowledge Catalogue
|
||||
|
||||
Если исследование позволило сформировать новые знания о рынке, обновляется документ:
|
||||
|
||||
> Dzentra Market Knowledge Catalogue.
|
||||
|
||||
Knowledge Catalogue никогда не строится непосредственно на данных API.
|
||||
|
||||
Он строится исключительно на основании подтвержденных информационных фактов и Information Model.
|
||||
|
||||
---
|
||||
|
||||
## Этап 14. Завершение исследования
|
||||
|
||||
Исследование считается завершенным только при выполнении всех следующих условий:
|
||||
|
||||
- подготовлен Endpoint Research;
|
||||
- обновлен Information Mapping;
|
||||
- при необходимости обновлена Information Model;
|
||||
- при необходимости обновлен Knowledge Catalogue;
|
||||
- все выводы имеют степень подтверждения.
|
||||
|
||||
После завершения исследования результаты могут использоваться другими подсистемами Dzentra.
|
||||
|
||||
---
|
||||
|
||||
# Степени подтверждения
|
||||
|
||||
Любой вывод, содержащийся в документации Market Intelligence, должен иметь явно указанную степень подтверждения.
|
||||
|
||||
Использование неподтвержденных выводов в качестве знаний запрещается.
|
||||
|
||||
| Статус | Описание |
|
||||
|---------|----------|
|
||||
| Не исследовано | Исследование соответствующего вопроса не проводилось. |
|
||||
| Гипотеза | Имеется предположение, основанное на документации или наблюдениях, но отсутствует экспериментальное подтверждение. |
|
||||
| Предварительно подтверждено | Подтверждено ограниченным количеством экспериментов. Требуется дополнительная проверка. |
|
||||
| Подтверждено | Подтверждено официальной документацией и экспериментальными исследованиями либо многократно подтверждено экспериментально. |
|
||||
| Опровергнуто | Экспериментально доказано отсутствие соответствия первоначальному предположению. |
|
||||
|
||||
---
|
||||
|
||||
# Критерии качества исследования
|
||||
|
||||
Исследование считается качественно выполненным, если выполняются все следующие условия.
|
||||
|
||||
## Полнота
|
||||
|
||||
Исследованы все типы сообщений исследуемого источника.
|
||||
|
||||
Исследованы все поля сообщений.
|
||||
|
||||
Исследованы все информационные факты.
|
||||
|
||||
---
|
||||
|
||||
## Подтверждаемость
|
||||
|
||||
Каждый вывод имеет экспериментальное подтверждение либо явно обозначен как гипотеза.
|
||||
|
||||
---
|
||||
|
||||
## Воспроизводимость
|
||||
|
||||
Любой эксперимент может быть повторен другим разработчиком и привести к тем же результатам.
|
||||
|
||||
---
|
||||
|
||||
## Трассируемость
|
||||
|
||||
Каждый информационный факт имеет подтвержденный источник происхождения.
|
||||
|
||||
Каждое знание имеет подтвержденную зависимость от информационных фактов.
|
||||
|
||||
Каждое торговое решение должно быть объяснимо через цепочку:
|
||||
|
||||
```text
|
||||
Биржа
|
||||
│
|
||||
▼
|
||||
Информационные факты
|
||||
│
|
||||
▼
|
||||
Знания
|
||||
│
|
||||
▼
|
||||
Решение
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Документированность
|
||||
|
||||
Все результаты исследования отражены в соответствующих документах:
|
||||
|
||||
- Endpoint Research;
|
||||
- Information Mapping;
|
||||
- Information Model;
|
||||
- Knowledge Catalogue.
|
||||
|
||||
---
|
||||
|
||||
# Жизненный цикл исследований
|
||||
|
||||
Исследование источников рыночной информации является непрерывным процессом.
|
||||
|
||||
Появление новых возможностей API, изменение поведения биржи или обнаружение новых фактов требует повторного проведения соответствующих исследований.
|
||||
|
||||
Исследование никогда не считается завершенным окончательно.
|
||||
|
||||
Каждый исследованный источник может быть повторно исследован при появлении новых обстоятельств.
|
||||
|
||||
---
|
||||
|
||||
## Основания для повторного исследования
|
||||
|
||||
Повторное исследование выполняется при возникновении одного или нескольких следующих событий:
|
||||
|
||||
- выпуск новой версии API;
|
||||
- изменение структуры сообщений;
|
||||
- появление новых полей;
|
||||
- изменение семантики существующих полей;
|
||||
- обнаружение противоречий между источниками;
|
||||
- получение новых экспериментальных данных;
|
||||
- обнаружение ошибок предыдущих исследований;
|
||||
- изменение архитектурных требований Dzentra.
|
||||
|
||||
---
|
||||
|
||||
# Использование результатов исследований
|
||||
|
||||
Результаты исследований используются исключительно как источник подтвержденных информационных фактов.
|
||||
|
||||
Настоящий документ не определяет:
|
||||
|
||||
- архитектуру Engine;
|
||||
- алгоритмы анализа рынка;
|
||||
- методы прогнозирования;
|
||||
- торговые стратегии;
|
||||
- правила управления капиталом;
|
||||
- правила открытия или закрытия позиций.
|
||||
|
||||
Указанные вопросы рассматриваются отдельными архитектурными документами Dzentra.
|
||||
|
||||
---
|
||||
|
||||
# Связанные документы
|
||||
|
||||
Настоящий документ используется совместно со следующими документами:
|
||||
|
||||
- Market Intelligence Stream Research Checklist;
|
||||
- Market Intelligence REST Research Checklist;
|
||||
- Market Intelligence WebSocket Request Research Checklist;
|
||||
- Endpoint Research;
|
||||
- Dzengi Market Intelligence Information Mapping;
|
||||
- Dzentra Market Intelligence Information Model;
|
||||
- Dzentra Market Knowledge Catalogue.
|
||||
|
||||
---
|
||||
|
||||
# Заключение
|
||||
|
||||
Настоящая методология определяет единый инженерный подход к исследованию источников рыночной информации.
|
||||
|
||||
Все знания, используемые подсистемой Market Intelligence, должны быть построены исключительно на основании подтвержденных информационных фактов.
|
||||
|
||||
Таким образом обеспечиваются:
|
||||
|
||||
- воспроизводимость исследований;
|
||||
- объяснимость полученных знаний;
|
||||
- трассируемость торговых решений;
|
||||
- независимость знаний от конкретной реализации API;
|
||||
- возможность повторного исследования при изменении источников данных.
|
||||
|
||||
Следование настоящей методологии является обязательным требованием при разработке и сопровождении подсистемы Market Intelligence проекта Dzentra.
|
||||
@@ -0,0 +1,341 @@
|
||||
# Stream Research Protocol — marketData.subscribe
|
||||
|
||||
## Контроль документа
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Документ | Stream Research Protocol — marketData.subscribe |
|
||||
| Тип документа | Research Protocol |
|
||||
| Версия | 2.0 |
|
||||
| Статус | Draft |
|
||||
| Проект | Dzentra |
|
||||
| Подсистема | Market Intelligence |
|
||||
| Биржа | Dzengi |
|
||||
| Endpoint | `marketData.subscribe` |
|
||||
| Транспорт | WebSocket Stream |
|
||||
| Основан на | Market Intelligence Stream Research Standard |
|
||||
| Язык | Русский |
|
||||
|
||||
---
|
||||
|
||||
# 1. Исследование подключения
|
||||
|
||||
## 1.1 Подключение
|
||||
|
||||
### 1.1.1 Корректность подключения
|
||||
|
||||
- [x] корректность подключения — подтверждена.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
Получено успешное подключение к WebSocket API Dzengi.
|
||||
|
||||
Получено подтверждение подписки.
|
||||
|
||||
После подтверждения подписки начинают поступать сообщения `internal.quote`.
|
||||
|
||||
---
|
||||
|
||||
### 1.1.2 Требования к соединению
|
||||
|
||||
- [x] URL подключения — соответствует документации.
|
||||
- [x] используемый транспорт (WS/WSS) — соответствует документации.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
**URL подключения**
|
||||
|
||||
Production: `wss://api-adapter.dzengi.com/connect`
|
||||
Demo: `wss://demo-api-adapter.dzengi.com/connect`
|
||||
|
||||
**Используемый транспорт**
|
||||
|
||||
`WSS (WebSocket Secure)`
|
||||
|
||||
---
|
||||
|
||||
### 1.1.3 Требования к авторизации
|
||||
|
||||
- [x] требуется ли авторизация — соответствует документации.
|
||||
- [x] механизм авторизации — соответствует документации.
|
||||
- [x] обязательные заголовки авторизации — соответствует документации.
|
||||
- [x] возможность работы без авторизации — соответствует документации.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
Публичный поток `marketData.subscribe` доступен без передачи данных авторизации.
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Подписка
|
||||
|
||||
- [x] формат подписки — частично соответствует документации;
|
||||
- [x] подтверждение подписки — соответствует документации;
|
||||
- [x] сообщения об ошибках — определено экспериментально;
|
||||
- [х] повторная подписка — определено экспериментально;
|
||||
- [x] подписка на несколько инструментов — определено экспериментально.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
**Формат подписки**
|
||||
|
||||
Документация описывает только содержимое `payload`:
|
||||
|
||||
```
|
||||
{
|
||||
"symbols": [
|
||||
"string"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Фактический формат сообщения, передаваемого через WebSocket /connect:
|
||||
|
||||
```
|
||||
{
|
||||
"correlationId": "...",
|
||||
"destination": "marketData.subscribe",
|
||||
"payload": {
|
||||
"symbols": [
|
||||
"BTC/USD_LEVERAGE"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Подтверждение подписки**
|
||||
|
||||
```
|
||||
{
|
||||
"destination": "marketData.subscribe",
|
||||
"status": "OK",
|
||||
"payload": {
|
||||
"subscriptions": {
|
||||
"BTC/USD_LEVERAGE": "PROCESSED"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Сообщения об ошибках**
|
||||
|
||||
Экспериментально зафиксированы варианты ошибок:
|
||||
|
||||
- `INVALID/SYMBOL` возвращает `status = OK`, но в `payload.subscriptions` указывается `ERROR: INVALID/SYMBOL not found`.
|
||||
- пустой `symbols` возвращает `status = ERROR`, `code = -1128`.
|
||||
- отсутствующий `symbols` возвращает `status = ERROR`, `code = -1128`.
|
||||
- отсутствующий `payload` возвращает `status = ERROR`, `code = -1128`.
|
||||
- неверный `destination` возвращает `status = ERROR`, `errorCode = BAD_REQUEST`.
|
||||
|
||||
**Повторная подписка**
|
||||
|
||||
- первая подписка получает статус `PROCESSED`;
|
||||
- повторные подписки получают статус `ALREADY_SUBSCRIBED`;
|
||||
- сообщения об ошибке не формируются;
|
||||
- повторная подписка работает без предварительной отмены;
|
||||
- в проведенных экспериментах признаков дублирования сообщений `internal.quote` не обнаружено.
|
||||
|
||||
**Подписка на несколько инструментов**
|
||||
|
||||
Экспериментально установлено:
|
||||
|
||||
- команда `marketData.subscribe` принимает несколько торговых инструментов;
|
||||
- подтверждение подписки содержит отдельный статус для каждого инструмента;
|
||||
- поток `internal.quote` передает сообщения для всех подписанных инструментов через одно WebSocket-соединение;
|
||||
- принадлежность сообщения к инструменту определяется полем `payload.symbolName`.
|
||||
|
||||
---
|
||||
|
||||
# 2. Исследование структуры потока
|
||||
|
||||
## 2.1 Типы сообщений
|
||||
|
||||
- [ ] назначение;
|
||||
- [ ] содержит ли рыночную информацию;
|
||||
- [ ] содержит ли служебную информацию;
|
||||
- [ ] содержит ли ошибки;
|
||||
- [ ] содержит ли подтверждение подписки;
|
||||
- [ ] содержит ли подтверждение отписки.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 2.2 Структура сообщений
|
||||
|
||||
- [ ] обязательные поля;
|
||||
- [ ] необязательные поля;
|
||||
- [ ] тип каждого поля;
|
||||
- [ ] допустимые значения;
|
||||
- [ ] диапазоны значений;
|
||||
- [ ] ограничения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 3. Классификация сообщений
|
||||
|
||||
- [ ] рыночное сообщение;
|
||||
- [ ] служебное сообщение;
|
||||
- [ ] сообщение управления;
|
||||
- [ ] сообщение об ошибке;
|
||||
- [ ] сообщение подтверждения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 4. Исследование семантики полей
|
||||
|
||||
- [ ] фактическое назначение;
|
||||
- [ ] источник происхождения;
|
||||
- [ ] обязательность;
|
||||
- [ ] изменяемость;
|
||||
- [ ] диапазон допустимых значений;
|
||||
- [ ] взаимосвязь с другими полями;
|
||||
- [ ] ограничения использования;
|
||||
- [ ] степень подтверждения семантики.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 5. Исследование информационных фактов
|
||||
|
||||
- [ ] какие информационные факты содержит сообщение;
|
||||
- [ ] какие информационные факты могут быть вычислены непосредственно из сообщения;
|
||||
- [ ] какие информационные факты отсутствуют;
|
||||
- [ ] какие информационные факты являются первичными;
|
||||
- [ ] какие информационные факты являются производными.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 5.1 Первичные информационные факты
|
||||
|
||||
- [ ] источник происхождения;
|
||||
- [ ] поле сообщения;
|
||||
- [ ] степень подтверждения;
|
||||
- [ ] ограничения использования.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 5.2 Производные информационные факты
|
||||
|
||||
- [ ] формула вычисления;
|
||||
- [ ] необходимые исходные данные;
|
||||
- [ ] ограничения вычисления;
|
||||
- [ ] степень достоверности.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 6. Исследование поведения потока
|
||||
|
||||
## 6.1 Частота сообщений
|
||||
|
||||
- [ ] минимальная частота;
|
||||
- [ ] максимальная частота;
|
||||
- [ ] средняя частота;
|
||||
- [ ] пиковая частота;
|
||||
- [ ] условия изменения частоты.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 6.2 Последовательность сообщений
|
||||
|
||||
- [ ] порядок поступления сообщений;
|
||||
- [ ] последовательность timestamp;
|
||||
- [ ] наличие пропусков;
|
||||
- [ ] наличие повторяющихся сообщений;
|
||||
- [ ] возможность нарушения порядка.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 6.3 Полнота сообщений
|
||||
|
||||
- [ ] полный снимок состояния;
|
||||
- [ ] инкрементальные изменения;
|
||||
- [ ] смешанный режим передачи;
|
||||
- [ ] обязательность всех полей;
|
||||
- [ ] возможность частичных обновлений.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 7. Исследование поведения данных
|
||||
|
||||
- [ ] условия появления;
|
||||
- [ ] условия изменения;
|
||||
- [ ] условия исчезновения;
|
||||
- [ ] частота изменения;
|
||||
- [ ] взаимосвязь с другими фактами.
|
||||
|
||||
---
|
||||
|
||||
## Дополнительно определить
|
||||
|
||||
- [ ] какие факты изменяются одновременно;
|
||||
- [ ] какие факты никогда не изменяются одновременно;
|
||||
- [ ] какие факты являются независимыми;
|
||||
- [ ] какие факты являются производными от других.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 8. Проверка эквивалентности
|
||||
|
||||
- [ ] существует ли аналогичный источник;
|
||||
- [ ] полностью ли совпадает значение;
|
||||
- [ ] совпадает ли семантика;
|
||||
- [ ] совпадает ли точность;
|
||||
- [ ] совпадает ли момент обновления;
|
||||
- [ ] имеются ли расхождения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 8.1 Альтернативные источники
|
||||
|
||||
- [ ] REST endpoint;
|
||||
- [ ] WebSocket Request;
|
||||
- [ ] другие Stream;
|
||||
- [ ] внутренние вычисления.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 8.2 Приоритет источников
|
||||
|
||||
- [ ] основной источник;
|
||||
- [ ] резервный источник;
|
||||
- [ ] допустимые альтернативы;
|
||||
- [ ] причины выбора приоритетного источника.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 9. Исследование производительности
|
||||
|
||||
- [ ] средний размер сообщения;
|
||||
- [ ] максимальный размер сообщения;
|
||||
- [ ] средняя скорость передачи;
|
||||
- [ ] максимальная скорость передачи;
|
||||
- [ ] объём данных в минуту;
|
||||
- [ ] объём данных в час.
|
||||
|
||||
#### Журнал исследования
|
||||
@@ -0,0 +1,46 @@
|
||||
### 1.1.4 Дополнительные требования клиента
|
||||
|
||||
- [x] обязательный формат сообщений — частично соответствует документации;
|
||||
- [ ] поддержание соединения;
|
||||
- [x] heartbeat / keepalive / ping-pong — определено экспериментально;
|
||||
- [ ] автоматическое закрытие соединения;
|
||||
- [ ] idle timeout;
|
||||
- [ ] требования к кодировке;
|
||||
- [ ] другие обязательные требования.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
**Обязательный формат сообщений**
|
||||
|
||||
Документация указывает формат payload (json):
|
||||
|
||||
```
|
||||
{
|
||||
"symbols": [
|
||||
"string"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Фактический формат сообщения через WebSocket /connect:
|
||||
|
||||
```
|
||||
{
|
||||
"correlationId": "...",
|
||||
"destination": "marketData.subscribe",
|
||||
"payload": {
|
||||
"symbols": ["BTC/USD_LEVERAGE"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Поддержание соединения**
|
||||
|
||||
Документация требований не содержит.
|
||||
|
||||
За время наблюдения получены сообщения только следующих типов:
|
||||
|
||||
- `marketData.subscribe`
|
||||
- `internal.quote`
|
||||
|
||||
Специальные сообщения heartbeat / keepalive / ping / pong не обнаружены.
|
||||
@@ -0,0 +1,269 @@
|
||||
# Dzengi API Endpoint Research — marketData.subscribe
|
||||
|
||||
## Контроль документа
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Документ | Dzengi API Endpoint Research — marketData.subscribe |
|
||||
| Тип документа | Endpoint Research |
|
||||
| Версия | 1.0 |
|
||||
| Статус | Draft |
|
||||
| Степень верификации | Runtime Research |
|
||||
| Проект | Dzentra |
|
||||
| Подсистема | Market Intelligence |
|
||||
| Источник | Dzengi API |
|
||||
| Endpoint | `marketData.subscribe` |
|
||||
| Транспорт | WebSocket Stream |
|
||||
| Язык | Русский |
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
Настоящий документ содержит результаты исследования endpoint `marketData.subscribe`, выполненного посредством анализа официальной документации Dzengi и фактических сообщений, полученных от биржи.
|
||||
|
||||
Документ предназначен для определения информационных сущностей, передаваемых данным endpoint, без интерпретации состояния рынка.
|
||||
|
||||
---
|
||||
|
||||
## Цель исследования
|
||||
|
||||
Цель настоящего исследования — определить:
|
||||
|
||||
- назначение endpoint;
|
||||
- структуру протокола обмена сообщениями;
|
||||
- типы сообщений;
|
||||
- семантику сообщений;
|
||||
- информационные сущности, содержащиеся в сообщениях;
|
||||
- особенности поведения потока данных;
|
||||
- взаимосвязь с другими endpoint API Dzengi.
|
||||
|
||||
---
|
||||
|
||||
## Основной вопрос исследования
|
||||
|
||||
> **Какую информацию о состоянии рынка предоставляет поток `marketData.subscribe`?**
|
||||
|
||||
---
|
||||
|
||||
## Источники исследования
|
||||
|
||||
Исследование основано на:
|
||||
|
||||
- официальной документации Dzengi;
|
||||
- OpenAPI (Swagger);
|
||||
- официальных примерах сообщений;
|
||||
- фактических сообщениях, полученных посредством Dzengi API Probe.
|
||||
|
||||
---
|
||||
|
||||
# 1. Назначение endpoint
|
||||
|
||||
## Описание документации
|
||||
|
||||
Согласно документации Dzengi, endpoint `marketData.subscribe` предназначен для получения потока рыночных котировок выбранных торговых инструментов.
|
||||
|
||||
---
|
||||
|
||||
## Назначение по результатам исследования
|
||||
|
||||
Исследование подтверждает, что `marketData.subscribe` является командой подписки на поток рыночных котировок.
|
||||
|
||||
После успешного выполнения подписки биржа начинает передавать поток сообщений с актуальными котировками выбранных инструментов.
|
||||
|
||||
Сам endpoint не является типом рыночного сообщения.
|
||||
|
||||
---
|
||||
|
||||
# 2. Способ получения данных
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Транспорт | WebSocket Stream |
|
||||
| Тип взаимодействия | Подписка |
|
||||
| Endpoint | `marketData.subscribe` |
|
||||
| Формат сообщений | JSON |
|
||||
|
||||
---
|
||||
|
||||
# 3. Параметры подписки
|
||||
|
||||
| Параметр | Тип | Обязательный | Назначение |
|
||||
|----------|-----|--------------|------------|
|
||||
| symbols | array | Да | Список торговых инструментов |
|
||||
|
||||
---
|
||||
|
||||
# 4. Протокол взаимодействия
|
||||
|
||||
Исследование показало, что взаимодействие состоит из двух независимых этапов.
|
||||
|
||||
```text
|
||||
Клиент
|
||||
│
|
||||
│ marketData.subscribe
|
||||
▼
|
||||
Биржа
|
||||
│
|
||||
│ Subscription confirmation
|
||||
▼
|
||||
Биржа
|
||||
│
|
||||
│ internal.quote
|
||||
│ internal.quote
|
||||
│ internal.quote
|
||||
▼
|
||||
Клиент
|
||||
```
|
||||
|
||||
Команда `marketData.subscribe` используется исключительно для оформления подписки.
|
||||
|
||||
Информация о состоянии рынка передается сообщениями другого типа — `internal.quote`.
|
||||
|
||||
---
|
||||
|
||||
# 5. Типы сообщений
|
||||
|
||||
## 5.1 Subscription confirmation
|
||||
|
||||
### Назначение
|
||||
|
||||
Подтверждение успешного оформления подписки.
|
||||
|
||||
### Пример сообщения
|
||||
|
||||
```json
|
||||
{
|
||||
"correlationId": "probe-market-data-subscribe",
|
||||
"destination": "marketData.subscribe",
|
||||
"payload": {
|
||||
"subscriptions": {
|
||||
"BTC/USD_LEVERAGE": "PROCESSED"
|
||||
}
|
||||
},
|
||||
"status": "OK"
|
||||
}
|
||||
```
|
||||
|
||||
### Семантика
|
||||
|
||||
Сообщение подтверждает регистрацию подписки.
|
||||
|
||||
Рыночной информации не содержит.
|
||||
|
||||
---
|
||||
|
||||
## 5.2 Quote update (`internal.quote`)
|
||||
|
||||
### Назначение
|
||||
|
||||
Передача актуальных рыночных котировок.
|
||||
|
||||
### Пример сообщения
|
||||
|
||||
```json
|
||||
{
|
||||
"destination": "internal.quote",
|
||||
"payload": {
|
||||
"bid": 62055.80,
|
||||
"bidQty": 5.0,
|
||||
"ofr": 62055.90,
|
||||
"ofrQty": 5.0,
|
||||
"symbolName": "BTC/USD_LEVERAGE",
|
||||
"timestamp": 1783537924352
|
||||
},
|
||||
"status": "OK"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 6. Анализ структуры сообщения
|
||||
|
||||
| Поле | Тип | Изменяется | Назначение | Статус |
|
||||
|------|-----|------------|------------|--------|
|
||||
| bid | Number | Да | Лучшая цена покупки | Подтверждено |
|
||||
| bidQty | Number | Да | Объем на лучшей цене покупки | Предварительно подтверждено |
|
||||
| ofr | Number | Да | Лучшая цена продажи | Подтверждено |
|
||||
| ofrQty | Number | Да | Объем на лучшей цене продажи | Предварительно подтверждено |
|
||||
| symbolName | String | Нет | Торговый инструмент | Подтверждено |
|
||||
| timestamp | Long | Да | Время формирования сообщения биржей | Подтверждено |
|
||||
|
||||
---
|
||||
|
||||
# 7. Информационные сущности, извлекаемые из сообщений
|
||||
|
||||
| Information ID | Источник (JSON Path) | Статус |
|
||||
|----------------|----------------------|--------|
|
||||
| best_bid_price | `payload.bid` | Подтверждено |
|
||||
| best_bid_quantity | `payload.bidQty` | Предварительно подтверждено |
|
||||
| best_ask_price | `payload.ofr` | Подтверждено |
|
||||
| best_ask_quantity | `payload.ofrQty` | Предварительно подтверждено |
|
||||
| instrument_symbol | `payload.symbolName` | Подтверждено |
|
||||
| quote_timestamp | `payload.timestamp` | Подтверждено |
|
||||
|
||||
---
|
||||
|
||||
# 8. Поведение потока
|
||||
|
||||
## Подтвержденные наблюдения
|
||||
|
||||
- Подписка выполняется один раз.
|
||||
- После подтверждения подписки биржа начинает передавать поток сообщений `internal.quote`.
|
||||
- Каждое сообщение содержит полный набор исследованных полей.
|
||||
- Сообщения поступают только при изменении котировки.
|
||||
- Каждое сообщение относится к одному торговому инструменту.
|
||||
|
||||
---
|
||||
|
||||
## Требует дополнительного исследования
|
||||
|
||||
- Всегда ли `bidQty` соответствует объему первого уровня стакана.
|
||||
- Всегда ли `ofrQty` соответствует объему первого уровня стакана.
|
||||
- Возможны ли сообщения без изменения цены.
|
||||
- Возможны ли сообщения с одинаковым `timestamp`.
|
||||
|
||||
---
|
||||
|
||||
# 9. Связь с другими endpoint
|
||||
|
||||
| Потенциальная информационная сущность | Endpoint | Поле | Статус |
|
||||
|--------------------------------------|----------|------|--------|
|
||||
| best_bid_price | REST `/api/v1/depth` | `bids[0][0]` | Подтверждено |
|
||||
| best_bid_price | WSS `/api/v1/depth` | `payload.bids[0][0]` | Подтверждено |
|
||||
| best_bid_price | `marketData.subscribe` | `payload.bid` | Подтверждено |
|
||||
| best_ask_price | REST `/api/v1/depth` | `asks[0][0]` | Подтверждено |
|
||||
| best_ask_price | WSS `/api/v1/depth` | `payload.asks[0][0]` | Подтверждено |
|
||||
| best_ask_price | `marketData.subscribe` | `payload.ofr` | Подтверждено |
|
||||
| best_bid_price | REST `/api/v1/ticker/24hr` | `bidPrice` | Требует исследования |
|
||||
| best_ask_price | REST `/api/v1/ticker/24hr` | `askPrice` | Требует исследования |
|
||||
|
||||
---
|
||||
|
||||
# 10. Итоги исследования
|
||||
|
||||
По результатам исследования подтверждено, что endpoint `marketData.subscribe` не является источником отдельных запросов к бирже, а представляет собой механизм подписки на поток рыночных котировок.
|
||||
|
||||
Фактическая рыночная информация передается сообщениями типа `internal.quote`.
|
||||
|
||||
Исследование также подтвердило эквивалентность информационных сущностей `best_bid_price` и `best_ask_price`, получаемых посредством `marketData.subscribe`, REST `/api/v1/depth` и WSS `/api/v1/depth`.
|
||||
|
||||
Эквивалентность соответствующих полей endpoint `/api/v1/ticker/24hr` на момент подготовки настоящей редакции документа не подтверждена.
|
||||
|
||||
---
|
||||
|
||||
# 11. Связь с архитектурой Dzentra
|
||||
|
||||
Результаты настоящего исследования используются при формировании:
|
||||
|
||||
- Dzengi Market Intelligence Information Mapping;
|
||||
- Dzentra Market Intelligence Information Model;
|
||||
- Dzentra Market Knowledge Catalogue.
|
||||
|
||||
Настоящий документ не определяет:
|
||||
|
||||
- знания о рынке;
|
||||
- интерпретацию состояния рынка;
|
||||
- алгоритмы анализа;
|
||||
- торговые стратегии;
|
||||
- архитектуру Engine.
|
||||
@@ -0,0 +1,261 @@
|
||||
# Market Intelligence REST Research Standard
|
||||
|
||||
## Контроль документа
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Документ | Market Intelligence REST Research Standard |
|
||||
| Тип документа | Engineering Standard |
|
||||
| Версия | 1.0 |
|
||||
| Статус | Release |
|
||||
| Проект | Dzentra |
|
||||
| Подсистема | Market Intelligence |
|
||||
| Язык | Русский |
|
||||
|
||||
---
|
||||
|
||||
# Назначение
|
||||
|
||||
Настоящий документ определяет единый стандарт исследования REST-источников рыночной информации.
|
||||
|
||||
Настоящий стандарт применяется совместно с документом:
|
||||
|
||||
> **Market Intelligence Research Methodology**
|
||||
|
||||
Методология определяет общий процесс проведения исследований.
|
||||
|
||||
Настоящий документ определяет перечень исследований, выполняемых для REST endpoint.
|
||||
|
||||
---
|
||||
|
||||
# Область применения
|
||||
|
||||
Настоящий стандарт применяется при исследовании REST endpoint, возвращающих рыночную информацию.
|
||||
|
||||
Примеры:
|
||||
|
||||
- `/api/v1/time`;
|
||||
- `/api/v1/exchangeInfo`;
|
||||
- `/api/v1/depth`;
|
||||
- `/api/v1/ticker/24hr`;
|
||||
- `/api/v1/aggTrades`;
|
||||
- `/api/v1/klines`.
|
||||
|
||||
---
|
||||
|
||||
# Цель исследования
|
||||
|
||||
Для каждого REST endpoint необходимо определить:
|
||||
|
||||
- какие информационные факты предоставляет endpoint;
|
||||
- какие параметры влияют на ответ;
|
||||
- является ли ответ снимком состояния;
|
||||
- насколько актуальны получаемые данные;
|
||||
- как данные связаны с другими источниками;
|
||||
- каким образом endpoint может использоваться подсистемой Market Intelligence.
|
||||
|
||||
---
|
||||
|
||||
# 1. Исследование endpoint
|
||||
|
||||
## 1.1 Назначение endpoint
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] официальное назначение endpoint;
|
||||
- [ ] фактическое назначение по результатам исследования;
|
||||
- [ ] тип возвращаемой информации;
|
||||
- [ ] относится ли endpoint к Market Intelligence.
|
||||
|
||||
---
|
||||
|
||||
## 1.2 Параметры запроса
|
||||
|
||||
Для каждого параметра определить:
|
||||
|
||||
- [ ] имя параметра;
|
||||
- [ ] тип;
|
||||
- [ ] обязательность;
|
||||
- [ ] допустимые значения;
|
||||
- [ ] значение по умолчанию;
|
||||
- [ ] влияние на ответ;
|
||||
- [ ] ошибки при некорректном значении.
|
||||
|
||||
---
|
||||
|
||||
## 1.3 Формат ответа
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] тип ответа;
|
||||
- [ ] структуру ответа;
|
||||
- [ ] обязательные поля;
|
||||
- [ ] необязательные поля;
|
||||
- [ ] возможные значения;
|
||||
- [ ] диапазоны значений;
|
||||
- [ ] поведение при пустом результате.
|
||||
|
||||
---
|
||||
|
||||
# 2. Исследование семантики полей
|
||||
|
||||
Для каждого поля определить:
|
||||
|
||||
- [ ] фактическое назначение;
|
||||
- [ ] источник происхождения;
|
||||
- [ ] тип данных;
|
||||
- [ ] обязательность;
|
||||
- [ ] диапазон допустимых значений;
|
||||
- [ ] связь с другими полями;
|
||||
- [ ] ограничения использования;
|
||||
- [ ] степень подтверждения семантики.
|
||||
|
||||
---
|
||||
|
||||
# 3. Исследование информационных фактов
|
||||
|
||||
Для каждого ответа определить:
|
||||
|
||||
- [ ] какие информационные факты содержит ответ;
|
||||
- [ ] какие информационные факты могут быть вычислены непосредственно из ответа;
|
||||
- [ ] какие информационные факты отсутствуют;
|
||||
- [ ] какие факты являются первичными;
|
||||
- [ ] какие факты являются производными.
|
||||
|
||||
---
|
||||
|
||||
## 3.1 Первичные информационные факты
|
||||
|
||||
Для каждого первичного информационного факта определить:
|
||||
|
||||
- [ ] endpoint;
|
||||
- [ ] параметр запроса;
|
||||
- [ ] поле ответа;
|
||||
- [ ] степень подтверждения;
|
||||
- [ ] ограничения использования.
|
||||
|
||||
---
|
||||
|
||||
## 3.2 Производные информационные факты
|
||||
|
||||
Для каждого производного информационного факта определить:
|
||||
|
||||
- [ ] формулу вычисления;
|
||||
- [ ] необходимые исходные данные;
|
||||
- [ ] ограничения вычисления;
|
||||
- [ ] степень достоверности.
|
||||
|
||||
---
|
||||
|
||||
# 4. Исследование актуальности данных
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] является ли ответ текущим снимком состояния;
|
||||
- [ ] содержит ли ответ исторические данные;
|
||||
- [ ] содержит ли ответ агрегированную статистику;
|
||||
- [ ] как часто обновляется ответ;
|
||||
- [ ] есть ли timestamp данных;
|
||||
- [ ] есть ли задержка обновления;
|
||||
- [ ] можно ли использовать ответ как источник текущего состояния рынка.
|
||||
|
||||
---
|
||||
|
||||
# 5. Проверка эквивалентности
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] существует ли аналогичный источник;
|
||||
- [ ] полностью ли совпадает значение;
|
||||
- [ ] совпадает ли семантика;
|
||||
- [ ] совпадает ли точность;
|
||||
- [ ] совпадает ли момент обновления;
|
||||
- [ ] имеются ли расхождения.
|
||||
|
||||
---
|
||||
|
||||
## 5.1 Альтернативные источники
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] WebSocket Request;
|
||||
- [ ] WebSocket Stream;
|
||||
- [ ] другие REST endpoint;
|
||||
- [ ] внутренние вычисления.
|
||||
|
||||
---
|
||||
|
||||
## 5.2 Приоритет источников
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] основной источник;
|
||||
- [ ] резервный источник;
|
||||
- [ ] допустимые альтернативы;
|
||||
- [ ] причины выбора приоритетного источника.
|
||||
|
||||
---
|
||||
|
||||
# 6. Исследование поведения endpoint
|
||||
|
||||
Проверить:
|
||||
|
||||
- [ ] повторяемость ответа при одинаковом запросе;
|
||||
- [ ] изменение ответа во времени;
|
||||
- [ ] поведение при частых запросах;
|
||||
- [ ] ограничения частоты запросов;
|
||||
- [ ] ошибки при превышении лимитов;
|
||||
- [ ] поведение при недоступности данных;
|
||||
- [ ] поведение при несуществующем инструменте.
|
||||
|
||||
---
|
||||
|
||||
# 7. Исследование производительности
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] среднее время ответа;
|
||||
- [ ] максимальное время ответа;
|
||||
- [ ] минимальное время ответа;
|
||||
- [ ] средний размер ответа;
|
||||
- [ ] максимальный размер ответа;
|
||||
- [ ] влияние параметров запроса на размер ответа;
|
||||
- [ ] влияние параметров запроса на время ответа.
|
||||
|
||||
---
|
||||
|
||||
# 8. Практическая ценность
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] какие информационные факты предоставляет endpoint;
|
||||
- [ ] какие факты отсутствуют;
|
||||
- [ ] может ли endpoint быть основным источником;
|
||||
- [ ] может ли endpoint быть резервным источником;
|
||||
- [ ] какие подсистемы Dzentra потенциально могут использовать endpoint;
|
||||
- [ ] ограничения использования в runtime.
|
||||
|
||||
---
|
||||
|
||||
# 9. Ограничения исследования
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] что подтверждено;
|
||||
- [ ] что предварительно подтверждено;
|
||||
- [ ] что осталось гипотезой;
|
||||
- [ ] что опровергнуто;
|
||||
- [ ] что невозможно определить данным исследованием.
|
||||
|
||||
---
|
||||
|
||||
# 10. Итоги исследования
|
||||
|
||||
По результатам исследования определить:
|
||||
|
||||
- [ ] степень пригодности endpoint;
|
||||
- [ ] степень полноты исследования;
|
||||
- [ ] сильные стороны;
|
||||
- [ ] ограничения;
|
||||
- [ ] рекомендации по использованию;
|
||||
- [ ] необходимость дополнительных исследований.
|
||||
@@ -0,0 +1,334 @@
|
||||
# Market Intelligence Stream Research Standard
|
||||
|
||||
## Контроль документа
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Документ | Market Intelligence Stream Research Standard |
|
||||
| Тип документа | Engineering Standard |
|
||||
| Версия | 2.0 |
|
||||
| Статус | Release |
|
||||
| Проект | Dzentra |
|
||||
| Подсистема | Market Intelligence |
|
||||
| Язык | Русский |
|
||||
|
||||
---
|
||||
|
||||
# Назначение
|
||||
|
||||
Настоящий документ определяет единый стандарт исследования потоковых (Streaming) источников рыночной информации.
|
||||
|
||||
Настоящий стандарт применяется совместно с документом:
|
||||
|
||||
> **Market Intelligence Research Methodology**
|
||||
|
||||
Методология определяет общий процесс проведения исследований.
|
||||
|
||||
Настоящий документ определяет перечень исследований, выполняемых для любого потокового источника рыночной информации.
|
||||
|
||||
---
|
||||
|
||||
# Область применения
|
||||
|
||||
Настоящий стандарт применяется при исследовании любых потоковых источников рыночной информации независимо от:
|
||||
|
||||
- биржи;
|
||||
- версии API;
|
||||
- реализации клиента.
|
||||
|
||||
Примеры:
|
||||
|
||||
- WebSocket Stream;
|
||||
- Push API;
|
||||
- Market Data Feed;
|
||||
- Streaming Gateway.
|
||||
|
||||
Настоящий стандарт **не исследует транспортный уровень** (WebSocket, TCP, TLS и т.д.).
|
||||
|
||||
Исследование транспортного уровня выполняется отдельным стандартом:
|
||||
|
||||
> **Market Intelligence WebSocket Transport Research Standard**
|
||||
|
||||
---
|
||||
|
||||
# Цель исследования
|
||||
|
||||
Для каждого потокового источника необходимо определить:
|
||||
|
||||
- какие информационные факты предоставляет поток;
|
||||
- каким образом изменяются данные;
|
||||
- насколько достоверны получаемые данные;
|
||||
- как данные связаны с другими источниками;
|
||||
- каким образом поток может использоваться подсистемой Market Intelligence.
|
||||
|
||||
---
|
||||
|
||||
# 1. Исследование подключения
|
||||
|
||||
## 1.1 Подключение
|
||||
|
||||
### 1.1.1 Корректность подключения
|
||||
|
||||
- [ ] корректность подключения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
### 1.1.2 Требования к соединению
|
||||
|
||||
- [ ] URL подключения;
|
||||
- [ ] используемый транспорт (WS/WSS).
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
### 1.1.3 Требования к авторизации
|
||||
|
||||
- [ ] требуется ли авторизация;
|
||||
- [ ] механизм авторизации;
|
||||
- [ ] обязательные заголовки авторизации;
|
||||
- [ ] возможность работы без авторизации.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 1.2 Подписка
|
||||
|
||||
- [ ] формат подписки;
|
||||
- [ ] подтверждение подписки;
|
||||
- [ ] сообщения об ошибках;
|
||||
- [ ] повторную подписку;
|
||||
- [ ] подписку на несколько инструментов;
|
||||
- [ ] отмену подписки;
|
||||
- [ ] ограничения подписки (если документированы).
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 2. Исследование структуры потока
|
||||
|
||||
## 2.1 Типы сообщений
|
||||
|
||||
Для каждого типа сообщений определить:
|
||||
|
||||
- [ ] назначение;
|
||||
- [ ] содержит ли рыночную информацию;
|
||||
- [ ] содержит ли служебную информацию;
|
||||
- [ ] содержит ли ошибки;
|
||||
- [ ] содержит ли подтверждение подписки;
|
||||
- [ ] содержит ли подтверждение отписки.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 2.2 Структура сообщений
|
||||
|
||||
Для каждого типа сообщений определить:
|
||||
|
||||
- [ ] обязательные поля;
|
||||
- [ ] необязательные поля;
|
||||
- [ ] тип каждого поля;
|
||||
- [ ] допустимые значения;
|
||||
- [ ] диапазоны значений;
|
||||
- [ ] ограничения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 3. Классификация сообщений
|
||||
|
||||
Для каждого типа сообщений определить:
|
||||
|
||||
- [ ] рыночное сообщение;
|
||||
- [ ] служебное сообщение;
|
||||
- [ ] сообщение управления;
|
||||
- [ ] сообщение об ошибке;
|
||||
- [ ] сообщение подтверждения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 4. Исследование семантики полей
|
||||
|
||||
Для каждого поля определить:
|
||||
|
||||
- [ ] фактическое назначение;
|
||||
- [ ] источник происхождения;
|
||||
- [ ] обязательность;
|
||||
- [ ] изменяемость;
|
||||
- [ ] диапазон допустимых значений;
|
||||
- [ ] взаимосвязь с другими полями;
|
||||
- [ ] ограничения использования;
|
||||
- [ ] степень подтверждения семантики.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 5. Исследование информационных фактов
|
||||
|
||||
Для каждого типа рыночных сообщений определить:
|
||||
|
||||
- [ ] какие информационные факты содержит сообщение;
|
||||
- [ ] какие информационные факты могут быть вычислены непосредственно из сообщения;
|
||||
- [ ] какие информационные факты отсутствуют;
|
||||
- [ ] какие информационные факты являются первичными;
|
||||
- [ ] какие информационные факты являются производными.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 5.1 Первичные информационные факты
|
||||
|
||||
Для каждого первичного информационного факта определить:
|
||||
|
||||
- [ ] источник происхождения;
|
||||
- [ ] поле сообщения;
|
||||
- [ ] степень подтверждения;
|
||||
- [ ] ограничения использования.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 5.2 Производные информационные факты
|
||||
|
||||
Для каждого производного информационного факта определить:
|
||||
|
||||
- [ ] формулу вычисления;
|
||||
- [ ] необходимые исходные данные;
|
||||
- [ ] ограничения вычисления;
|
||||
- [ ] степень достоверности.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 6. Исследование поведения потока
|
||||
|
||||
## 6.1 Частота сообщений
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] минимальную частоту;
|
||||
- [ ] максимальную частоту;
|
||||
- [ ] среднюю частоту;
|
||||
- [ ] пиковую частоту;
|
||||
- [ ] условия изменения частоты.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 6.2 Последовательность сообщений
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] порядок поступления сообщений;
|
||||
- [ ] последовательность timestamp;
|
||||
- [ ] наличие пропусков;
|
||||
- [ ] наличие повторяющихся сообщений;
|
||||
- [ ] возможность нарушения порядка.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 6.3 Полнота сообщений
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] полный снимок состояния;
|
||||
- [ ] инкрементальные изменения;
|
||||
- [ ] смешанный режим передачи;
|
||||
- [ ] обязательность всех полей;
|
||||
- [ ] возможность частичных обновлений.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 7. Исследование поведения данных
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] условия появления;
|
||||
- [ ] условия изменения;
|
||||
- [ ] условия исчезновения;
|
||||
- [ ] частоту изменения;
|
||||
- [ ] взаимосвязь с другими фактами.
|
||||
|
||||
---
|
||||
|
||||
## Дополнительно определить
|
||||
|
||||
- [ ] какие факты изменяются одновременно;
|
||||
- [ ] какие факты никогда не изменяются одновременно;
|
||||
- [ ] какие факты являются независимыми;
|
||||
- [ ] какие факты являются производными от других.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 8. Проверка эквивалентности
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] существует ли аналогичный источник;
|
||||
- [ ] полностью ли совпадает значение;
|
||||
- [ ] совпадает ли семантика;
|
||||
- [ ] совпадает ли точность;
|
||||
- [ ] совпадает ли момент обновления;
|
||||
- [ ] имеются ли расхождения.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 8.1 Альтернативные источники
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] REST endpoint;
|
||||
- [ ] WebSocket Request;
|
||||
- [ ] другие Stream;
|
||||
- [ ] внутренние вычисления.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
## 8.2 Приоритет источников
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] основной источник;
|
||||
- [ ] резервный источник;
|
||||
- [ ] допустимые альтернативы;
|
||||
- [ ] причины выбора приоритетного источника.
|
||||
|
||||
#### Журнал исследования
|
||||
|
||||
---
|
||||
|
||||
# 9. Исследование производительности
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] средний размер сообщения;
|
||||
- [ ] максимальный размер сообщения;
|
||||
- [ ] среднюю скорость передачи;
|
||||
- [ ] максимальную скорость передачи;
|
||||
- [ ] объём данных в минуту;
|
||||
- [ ] объём данных в час.
|
||||
|
||||
#### Журнал исследования
|
||||
@@ -0,0 +1,274 @@
|
||||
# Market Intelligence WebSocket Request Research Standard
|
||||
|
||||
## Контроль документа
|
||||
|
||||
| Свойство | Значение |
|
||||
|----------|----------|
|
||||
| Документ | Market Intelligence WebSocket Request Research Standard |
|
||||
| Тип документа | Engineering Standard |
|
||||
| Версия | 1.0 |
|
||||
| Статус | Release |
|
||||
| Проект | Dzentra |
|
||||
| Подсистема | Market Intelligence |
|
||||
| Язык | Русский |
|
||||
|
||||
---
|
||||
|
||||
# Назначение
|
||||
|
||||
Настоящий документ определяет единый стандарт исследования источников рыночной информации, использующих модель **WebSocket Request / Response**.
|
||||
|
||||
Настоящий стандарт применяется совместно с документом:
|
||||
|
||||
> **Market Intelligence Research Methodology**
|
||||
|
||||
Методология определяет общий процесс проведения исследований.
|
||||
|
||||
Настоящий документ определяет перечень исследований, выполняемых для WebSocket Request endpoint.
|
||||
|
||||
---
|
||||
|
||||
# Область применения
|
||||
|
||||
Настоящий стандарт применяется при исследовании WebSocket endpoint, использующих модель "запрос → ответ".
|
||||
|
||||
Примеры:
|
||||
|
||||
- `wss:/api/v1/depth`
|
||||
- `wss:/api/v1/ticker/24hr`
|
||||
- `wss:/api/v1/aggTrades`
|
||||
- `wss:/api/v1/klines`
|
||||
- `wss:/api/v1/time`
|
||||
- `wss:/api/v1/exchangeInfo`
|
||||
|
||||
---
|
||||
|
||||
# Цель исследования
|
||||
|
||||
Для каждого WebSocket Request endpoint необходимо определить:
|
||||
|
||||
- какие информационные факты предоставляет endpoint;
|
||||
- каким образом формируется запрос;
|
||||
- каким образом формируется ответ;
|
||||
- отличается ли ответ от REST;
|
||||
- как данные связаны с другими источниками;
|
||||
- каким образом endpoint может использоваться подсистемой Market Intelligence.
|
||||
|
||||
---
|
||||
|
||||
# 1. Исследование подключения
|
||||
|
||||
## 1.1 WebSocket-соединение
|
||||
|
||||
Проверить:
|
||||
|
||||
- [ ] корректность подключения;
|
||||
- [ ] требования к соединению;
|
||||
- [ ] требования к авторизации;
|
||||
- [ ] timeout подключения;
|
||||
- [ ] ограничения соединения;
|
||||
- [ ] возможность повторного подключения.
|
||||
|
||||
---
|
||||
|
||||
## 1.2 Формат запроса
|
||||
|
||||
Для каждого запроса определить:
|
||||
|
||||
- [ ] destination;
|
||||
- [ ] correlationId;
|
||||
- [ ] payload;
|
||||
- [ ] обязательные поля;
|
||||
- [ ] необязательные поля;
|
||||
- [ ] допустимые значения;
|
||||
- [ ] ограничения.
|
||||
|
||||
---
|
||||
|
||||
## 1.3 Формат ответа
|
||||
|
||||
Для каждого ответа определить:
|
||||
|
||||
- [ ] структуру ответа;
|
||||
- [ ] обязательные поля;
|
||||
- [ ] необязательные поля;
|
||||
- [ ] типы данных;
|
||||
- [ ] диапазоны значений;
|
||||
- [ ] сообщения об ошибках.
|
||||
|
||||
---
|
||||
|
||||
# 2. Исследование семантики полей
|
||||
|
||||
Для каждого поля определить:
|
||||
|
||||
- [ ] фактическое назначение;
|
||||
- [ ] источник происхождения;
|
||||
- [ ] обязательность;
|
||||
- [ ] диапазон значений;
|
||||
- [ ] взаимосвязь с другими полями;
|
||||
- [ ] ограничения использования;
|
||||
- [ ] степень подтверждения семантики.
|
||||
|
||||
---
|
||||
|
||||
# 3. Исследование информационных фактов
|
||||
|
||||
Для каждого ответа определить:
|
||||
|
||||
- [ ] какие информационные факты содержит ответ;
|
||||
- [ ] какие информационные факты могут быть вычислены;
|
||||
- [ ] какие информационные факты отсутствуют;
|
||||
- [ ] какие факты являются первичными;
|
||||
- [ ] какие факты являются производными.
|
||||
|
||||
---
|
||||
|
||||
## 3.1 Первичные информационные факты
|
||||
|
||||
Для каждого факта определить:
|
||||
|
||||
- [ ] destination;
|
||||
- [ ] поле ответа;
|
||||
- [ ] степень подтверждения;
|
||||
- [ ] ограничения использования.
|
||||
|
||||
---
|
||||
|
||||
## 3.2 Производные информационные факты
|
||||
|
||||
Для каждого производного факта определить:
|
||||
|
||||
- [ ] формулу вычисления;
|
||||
- [ ] необходимые исходные данные;
|
||||
- [ ] ограничения вычисления;
|
||||
- [ ] степень достоверности.
|
||||
|
||||
---
|
||||
|
||||
# 4. Исследование поведения запросов
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] время ответа;
|
||||
- [ ] повторяемость ответов;
|
||||
- [ ] влияние параметров запроса;
|
||||
- [ ] возможность параллельных запросов;
|
||||
- [ ] ограничения частоты запросов;
|
||||
- [ ] поведение при ошибках.
|
||||
|
||||
---
|
||||
|
||||
# 5. Исследование поведения ответов
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] является ли ответ снимком состояния;
|
||||
- [ ] содержит ли ответ агрегированные данные;
|
||||
- [ ] содержит ли ответ исторические данные;
|
||||
- [ ] содержит ли timestamp;
|
||||
- [ ] отличается ли ответ от REST.
|
||||
|
||||
---
|
||||
|
||||
# 6. Проверка эквивалентности
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] существует ли аналогичный REST endpoint;
|
||||
- [ ] существует ли аналогичный Stream;
|
||||
- [ ] полностью ли совпадает значение;
|
||||
- [ ] совпадает ли семантика;
|
||||
- [ ] совпадает ли точность;
|
||||
- [ ] совпадает ли момент формирования данных;
|
||||
- [ ] имеются ли расхождения.
|
||||
|
||||
---
|
||||
|
||||
## 6.1 Альтернативные источники
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] REST endpoint;
|
||||
- [ ] WebSocket Stream;
|
||||
- [ ] другие WebSocket Request;
|
||||
- [ ] внутренние вычисления.
|
||||
|
||||
---
|
||||
|
||||
## 6.2 Приоритет источников
|
||||
|
||||
Для каждого информационного факта определить:
|
||||
|
||||
- [ ] основной источник;
|
||||
- [ ] резервный источник;
|
||||
- [ ] допустимые альтернативы;
|
||||
- [ ] причины выбора приоритетного источника.
|
||||
|
||||
---
|
||||
|
||||
# 7. Исследование протокола
|
||||
|
||||
Проверить:
|
||||
|
||||
- [ ] correlationId;
|
||||
- [ ] destination;
|
||||
- [ ] обработку ошибок;
|
||||
- [ ] timeout;
|
||||
- [ ] повторный запрос;
|
||||
- [ ] повторное подключение;
|
||||
- [ ] потерю соединения;
|
||||
- [ ] восстановление соединения;
|
||||
- [ ] обработку нескольких одновременных запросов;
|
||||
- [ ] гарантии получения ответа.
|
||||
|
||||
---
|
||||
|
||||
# 8. Исследование производительности
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] среднее время ответа;
|
||||
- [ ] максимальное время ответа;
|
||||
- [ ] минимальное время ответа;
|
||||
- [ ] средний размер ответа;
|
||||
- [ ] максимальный размер ответа;
|
||||
- [ ] влияние параметров запроса на производительность.
|
||||
|
||||
---
|
||||
|
||||
# 9. Практическая ценность
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] какие информационные факты предоставляет endpoint;
|
||||
- [ ] какие факты отсутствуют;
|
||||
- [ ] может ли endpoint быть основным источником;
|
||||
- [ ] может ли endpoint быть резервным источником;
|
||||
- [ ] какие подсистемы Dzentra потенциально могут использовать endpoint;
|
||||
- [ ] ограничения использования в runtime.
|
||||
|
||||
---
|
||||
|
||||
# 10. Ограничения исследования
|
||||
|
||||
Определить:
|
||||
|
||||
- [ ] что подтверждено;
|
||||
- [ ] что предварительно подтверждено;
|
||||
- [ ] что осталось гипотезой;
|
||||
- [ ] что опровергнуто;
|
||||
- [ ] что невозможно определить данным исследованием.
|
||||
|
||||
---
|
||||
|
||||
# 11. Итоги исследования
|
||||
|
||||
По результатам исследования определить:
|
||||
|
||||
- [ ] степень пригодности endpoint;
|
||||
- [ ] степень полноты исследования;
|
||||
- [ ] сильные стороны;
|
||||
- [ ] ограничения;
|
||||
- [ ] рекомендации по использованию;
|
||||
- [ ] необходимость дополнительных исследований.
|
||||
Reference in New Issue
Block a user