pod

docs/bottom-up/0-intro.md

@@ -0,0 +1,4 @@
+---
+title:
+date: 2023-08-02
+---

docs/quant-dev/quant-dev-in-pod.md

@@ -0,0 +1,74 @@
+---
+title: Pod 模式的量化交易系统
+date: 2023-09-17
+---
+
+量化交易属于金融行业，再细说，属于二级市场，即交易的标的物通常是公开交易的产品，比如股票、期货、期权、债券等等。
+量化行业里面其实也分了很多类别，比如股票量化、期货量化、固定收益类产品等等。
+这些类别中，其实也可以按照频率分成高频、中频和低频。
+各个门类之间有区别也有联系，但是总体来说，作为个人，通常是专精其中某个领域。
+
+## Pod 是什么
+
+各大量化公司的运营模式也不尽相同，今天我们讲到的 Pod 就是其中一类。
+一个 Pod 可大可小，多则数十人，少则几人。这群人有自己的专精领域，交易某类或者某几类策略或者标的物。
+他们会得到母公司不同程度的支持（这里我们只从技术角度思考），比如基本的数据源、数据库、计算机资源、交易接口等等。
+他们通常会自负盈亏，但也会共同进退。
+
+## Pod 模式的量化交易系统需求
+
+Pod 模式的量化交易系统设计跟其他模式有什么区别呢？或者说 Pod 模式的量化系统设计有需求呢？
+
+- 针对某类交易策略设计，并不需要非常好的通用性，但是需要很好的专用性
+- 不是为很多程序员一起工作设计的，而是为了团队的所有成员，包括 Quant，Trader 和 其他程序员
+- 系统需要对接不同种类的数据源和交易基础设施，最好系统可以以最小的代价接入不同的公司的基础设施
+- 系统不能过于复杂，且具有良好的可操作性，换句话说，他的接口不应该是仅仅面对程序员的，也是面对 Quant 和 Operation 人员的
+- 要有一定的拓展能力，这种拓展在不同策略类型前提下可能会有不同的需求，比如一个中频统计套利系统跟高频套利系统在很多方面都是迥异的
+
+## 如何设计呢？
+
+一些通用原则：
+
+- 仅开发必要的功能
+- 面向接口编程
+- 按照业务逻辑设计模块
+- 分离配置和计算逻辑
+- 版本控制配置文件
+- 格式化日志
+- 通过日志和警报增加系统可见性
+- 通过 GUI 增加系统的可操作性
+
+## 技术栈
+
+- 语言
+  - Python
+  - C++
+  - Cython
+  - Numba
+- 数据库
+  - PostgreSQL
+  - DataFrame Store ( hand made or ArcticDB )
+- 中间件
+  - Redis
+  - Kafka/RedPanda
+- 计算
+  - Ray
+  - Dask
+- 监控
+  - Grafana
+  - Prometheus
+  - Front End
+- 编排
+  - Airflow
+  - K8s
+  - Docker
+
+## 组件
+
+- 计算图和计算图的运行时
+    - Batch Based
+    - Event Based
+- Prompt，用来跟系统进行实时互动，人为干涉
+- Alert，用来发送警报、异常等等
+- Monitor
+  - Report

mkdocs.yml

@@ -112,6 +112,7 @@ nav:
     - 如何成为 Quant Dev - 语言: "./quant-dev/quant-dev-language.md"
     - 如何成为 Quant Dev - 框架: "./quant-dev/quant-dev-framework.md"
     - 如何成为 Quant Dev - 数据库: "./quant-dev/quant-dev-db.md"
+    - Quant Dev - Pod: "./quant-dev/quant-dev-in-pod.md"
   - Quant 入门: "research-intro.md"
   - 资源: 
     - 相关 Kaggle 竞赛和数据: "kaggle.md"