Устная история Bank Python: как работают внутренние платформы инвестбанков

Bank Python, это категория собственных разработок Python-платформ, которые используют крупные инвестиционные банки. Это не стандартный Python, а полноценные proprietary форки всей экосистемы. Автор (разработчик, работавший с такими системами) описывает вымышленный, но типичный пример, банковскую систему Minerva.

Мinerva построена на нескольких ключевых компонентах:

Barbara, глобальное иерархическое хранилище ключ-значение, построенное на pickle+zip. Вся база данных объектов банка (трейды, инструменты, рыночные данные) хранится в Barbara. Это центральный источник истины. Barbara использует несколько «rings» (пространств имён) и работает как DynamoDB/BigTable с eventual consistency. Она настолько простая и надёжная, что отказы редки.
Dagger, управление графом зависимостей финансовых инструментов. Финансовые инструменты (облигации, свопы, дериватьи и т.п.) образуют иерархию с зависимостями. Когда базовый инструмент меняется (например, при понижении кредитного рейтинга), Dagger автоматически пересчитывает стоимость всех зависимых инструментов. Это похоже на Excel, но с версионированием, тестами и под контролем.
Walpole, bankwide job runner, центральный сервис для запуска периодических работ (end-of-day скрипты, обновление данных, отправка отчётов). Walpole работает как мега-Jenkins + мега-systemd, разумеет зависимости между jobами. Ключевой бонус: любой может задеплоить приложение через простой ini-файл конфига, без согласований и месячного ожидания железа.
Исходный код в Barbara, революционный момент: исходный код хранится не на диске, а в Barbara (специальный ring), что меняет весь workflow.
MnTable, встроенная таблочная библиотека для работы с плотными (memory-dense) структурами данных, в отличие от хэш-таблиц, которые разреженны и требуют предварительного знания access patterns.

Система прошла эволюцию: старые поколения (Athena, Quartz на других банках) были похожей архитектуры. Bank Python, это внутренний мир тысяч разработчиков, скрытый от публики, редко упоминаемый в открытых источниках.

Ключевые факты

Bank Python, proprietary форки Python, используемые в крупных банках; Minerva, типичный пример такой системы
Barbara, глобальное key-value хранилище на pickle+zip, центральный источник всех данных банка (трейды, инструменты, рыночные данные)
Dagger, система управления зависимостями финансовых инструментов; автоматически пересчитывает стоимость дериватов при изменении базовых инструментов
Walpole, bankwide job runner, упрощает деплой любому разработчику через ini-файл, без месячного ожидания согласований
Исходный код хранится в Barbara, а не на диске, что требует революционного подхода к версионированию и деплою

Почему это важно

Bank Python показывает, как крупные финансовые учреждения решают фундаментальные проблемы: управление зависимостями между тысячами финансовых инструментов, деплой без бюрократии, единая глобальная база данных. Это демонстрирует, что стандартный Python/Cloud-Native слишком сложен для domain-специалистов (финансовых аналитиков, риск-менеджеров). Простота Barbara и ini-файл Walpole, результат многолетней эволюции, прагматизм vs. сложность облачных решений.

Кому это важно

Разработчикам в инвестиционных банках, архитекторам больших систем обработки данных, специалистам по финансовым вычислениям. Также интересно для тех, кто проектирует internal tools и платформы, как организовать простоту при масштабе тысяч пользователей.

Как это применить

Для своих проектов: рассмотреть простоту barbara-подхода (key-value store + иерархия) для управления сложными зависимостями данных. Использовать Dagger-подобную идею (граф зависимостей, автоматический пересчёт) в любых системах с вычисляемыми значениями. Упростить деплой до ini-файла, если текущий процесс требует месячных согласований. Хранить исходный код в системе версионирования, связанной с самими данными, чтобы избежать рассинхрона.

Можно ли доверять

Автор, разработчик, работавший внутри банковских систем; он раскрывает типичную архитектуру под вымышленным именем Minerva и менял названия компонентов для конфиденциальности. Описание технически точно и совпадает с известными старыми системами типа Athena/Quartz. Однако деталей он не знает в полноте (как он сам оговаривает), поэтому описание, обоснованная реконструкция, а не полная техническая спецификация.

Риски и подводные камни

Barbara имеет мягкий лимит на размер объектов (~16MB сжатых pickled), что требует регулярного архивирования старых данных. Отсутствие файловой системы усложняет интеграцию с внешними инструментами. Proprietary форк Python означает полную изоляцию от open-source экосистемы и сложность при наёме людей, незнакомых с внутренней системой. Простота Barbara может обернуться производительностью на больших датасетах, автор сам рекомендует переходить на SQL или kdb+ при растущем размере. Centrale Walpole, single point of failure для всех job'ов в банке.