千万用户股票量化平台设计

日期： 2026-07-10

状态： 已确认总体路线

架构路线： 云原生 Lakehouse + 流批一体 + 异步计算平面

1. 目标与容量基线

平台面向量化研究、因子生产、历史回测和 AI Research，不承担交易所级撮合或微秒级高频交易。

指标	目标值
注册用户	1,000 万
日活用户	100 万
峰值在线用户	10 万
API 峰值	20 万 QPS
标的范围	A 股约 6,000 个标的
行情粒度	分钟级，架构可扩展至 Tick
日回测任务	约 5 万个
核心查询可用性	99.95%
缓存命中 API 延迟	p95 < 100 ms
普通 API 延迟	p95 < 200 ms
分钟行情时效	分钟结束后 10 秒内可查询

2. 设计原则

1. Iceberg 数据湖是历史事实源，ClickHouse、Redis 和 OpenSearch 均为可重建索引。
2. 在线请求与因子、回测、AI 等重计算任务运行在隔离的资源池。
3. 所有研究结果绑定代码版本、参数、数据快照和成本模型，保证可复现。
4. 公共行情尽量由 CDN 和 Redis 承载，防止峰值流量穿透事务数据库。
5. Agent 只能调用受控工具，不直接访问生产数据库或执行任意代码。
6. 基础设施按阶段扩容，不按 1,000 万用户一次性采购。

3. 总体架构

flowchart TB
    subgraph Sources["数据源"]
        EX["交易所 / 行情供应商"]
        FIN["财务 / 公告 / 新闻"]
        ALT["宏观 / 舆情 / 另类数据"]
    end

    subgraph Ingestion["数据采集层"]
        COL["行情采集器集群"]
        CDC["CDC / 批量连接器"]
        MQ["Kafka 事件总线"]
        DQ["Schema Registry + 数据质量"]
    end

    subgraph Lake["数据湖与查询层"]
        OBJ["对象存储 S3 / OSS"]
        ICE["Apache Iceberg Lakehouse"]
        CAT["数据目录、血缘与权限"]
        CH["ClickHouse 实时分析"]
        OS["OpenSearch 文本与向量检索"]
    end

    subgraph Compute["量化计算平面"]
        FLINK["Flink 实时清洗与分钟因子"]
        SPARK["Spark 批量清洗与历史因子"]
        FACTOR["因子注册中心"]
        RAY["Ray 回测与参数搜索"]
    end

    subgraph AI["AI Research 与 Agent"]
        RAG["Research RAG"]
        LLM["LLM Gateway"]
        AGENT["Agent Orchestrator"]
        TOOLS["查询 / 因子 / 回测 / 报告工具"]
        GUARD["权限 / 沙箱 / 审计 / 成本限额"]
    end

    subgraph Serving["在线服务平面"]
        GW["CDN + WAF + API Gateway"]
        BFF["REST / GraphQL / WebSocket"]
        SVC["用户 / 策略 / 组合 / 任务服务"]
        CACHE["Redis Cluster"]
        DB["分片 PostgreSQL"]
        JOB["任务队列与调度器"]
    end

    subgraph Platform["Kubernetes 平台"]
        K8S["多可用区 Kubernetes"]
        OBS["Metrics / Logs / Traces"]
        IAM["IAM / KMS / Secrets"]
        CICD["GitOps / CI/CD"]
    end

    EX --> COL
    FIN --> CDC
    ALT --> CDC
    COL --> MQ
    CDC --> MQ
    MQ --> DQ
    MQ --> FLINK
    DQ --> OBJ
    OBJ --- ICE
    ICE --- CAT
    FLINK --> ICE
    FLINK --> CH
    SPARK <--> ICE
    SPARK --> FACTOR
    FACTOR --> ICE
    GW --> BFF
    BFF --> SVC
    BFF --> CACHE
    SVC --> DB
    SVC --> JOB
    JOB --> RAY
    RAY <--> ICE
    RAY --> OBJ
    ICE --> RAG
    OS --> RAG
    RAG --> LLM
    LLM --> AGENT
    AGENT --> GUARD
    GUARD --> TOOLS
    TOOLS --> CH
    TOOLS --> RAY
    TOOLS --> FACTOR
    K8S -.承载.-> Ingestion
    K8S -.承载.-> Compute
    K8S -.承载.-> AI
    K8S -.承载.-> Serving
    OBS -.监控.-> K8S
    IAM -.安全控制.-> K8S
    CICD -.部署.-> K8S

4. 技术选型

领域	推荐技术	说明
API 入口	CDN、WAF、Envoy Gateway 或 Kong	鉴权、限流、灰度和 WebSocket
在线服务	Go/Java；量化和 AI 使用 Python	隔离在线性能与研究生态
消息总线	Kafka、Schema Registry	顺序消费、解耦和行情回放
实时计算	Flink、Flink Kubernetes Operator	有状态计算和一致性检查点
数据湖	S3/OSS、Iceberg、Parquet	快照、时间旅行和低成本存储
批量计算	Spark on Kubernetes	清洗、历史因子和数据回填
因子计算	Spark、Flink、Python、Numba	支持日频和分钟级因子
回测	Ray、Kubernetes Jobs	参数搜索和弹性资源调度
实时查询	ClickHouse	K 线、因子截面和回测分析
缓存	Redis Cluster	热点行情、会话和限流计数
事务数据	PostgreSQL 16，多分片多副本	用户、权限、策略和任务元数据
搜索与 RAG	OpenSearch	公告、研报、新闻和混合检索
Agent 工作流	Temporal、自研 Orchestrator	持久状态、重试和人工审批
数据编排	Airflow 或 Dagster	日终任务和依赖调度
可观测性	Prometheus、Grafana、Loki、Tempo	指标、日志和链路追踪
交付	Kubernetes、Argo CD、Terraform	GitOps 和环境一致性

优先选用云厂商的托管 Kafka、PostgreSQL、Redis、对象存储和 KMS。Flink、Spark、Ray 与业务服务保持 Kubernetes 可移植性，降低跨云切换成本。

5. 数据模型与数据流

数据分为四层：

• raw：供应商原始数据，只追加，不覆盖。
• standardized：完成时区、交易日历、代码映射、去重、复权和质量标记。
• feature：因子值、标签、横截面标准化结果及版本元数据。
• serving：写入 ClickHouse、Redis 和 OpenSearch 的查询优化副本。

sequenceDiagram
    participant V as 数据供应商
    participant K as Kafka
    participant F as Flink
    participant L as Iceberg
    participant C as ClickHouse
    participant R as 因子/回测集群
    participant A as AI Agent
    participant G as API Gateway
    participant U as 用户

    V->>K: 行情、财务、公告、新闻
    K->>F: 实时校验、去重、复权、聚合
    F->>L: 原始层和标准层
    F->>C: 实时行情与分钟因子
    L->>R: 固定版本的数据快照
    R->>L: 因子值、回测结果和制品
    U->>G: 查询、研究或提交回测
    G->>C: 查询热点数据
    G->>R: 异步提交计算任务
    A->>L: 检索可信数据
    A->>R: 调用受控因子和回测工具
    A-->>U: 带引用的结论、报告和任务状态

Kafka 事件和 Iceberg 表都携带 source、schema_version、event_time、ingest_time、trading_date 和 quality_flags。因子结果额外携带 factor_version、code_commit、data_snapshot_id 和 parameters_hash。

6. 扩容方案

6.1 服务与 Kubernetes

• 在线、流处理、批量回测、AI 使用独立节点池和资源配额。
• API 按 CPU、QPS 和延迟使用 HPA；消费者按 Kafka Lag 使用 KEDA。
• 回测节点池可缩容到零，普通任务优先使用 Spot/抢占式实例。
• PodDisruptionBudget、TopologySpreadConstraints 和反亲和保证跨可用区部署。

6.2 数据系统

• Kafka 初始设置 192 至 384 个分区，按市场和证券代码哈希分配，Broker 跨三个可用区。
• Flink 并行度跟随 Kafka 分区和消费延迟调整，扩缩容通过 Savepoint 完成。
• Iceberg 按交易日期分区、证券代码分桶，周期性合并小文件和清理过期快照。
• ClickHouse 使用 4 至 8 个分片、每分片 2 个副本，近期数据放本地 SSD，历史数据放对象存储。
• PostgreSQL 按 user_id 分片，读副本承担非强一致查询，避免跨分片事务。
• CDN 与 Redis 的公共行情缓存命中率目标不低于 80%。

6.3 租户和任务治理

• 每个租户设置 API、并发回测、CPU 小时、存储和 LLM Token 配额。
• 回测队列区分交互式、批量和内部任务，采用加权公平调度。
• 对参数组合数、最大回测区间、单任务运行时间和输出大小设置硬限制。

7. 容灾方案

数据等级	方案	RPO	RTO
用户、策略、权限	跨可用区同步复制，异地 WAL 归档	5 分钟	30 分钟
Kafka 行情流	三副本，MirrorMaker 跨地域复制	5 分钟	30 分钟
Iceberg 数据湖	版本控制和跨地域对象复制	1 小时	2 小时
ClickHouse/OpenSearch	双副本，可从数据湖重建	15 分钟	2 小时
回测任务	Temporal 持久状态，失败后重调度	15 分钟	4 小时

主地域部署三个可用区，异地保持 20% 至 30% 温备容量。Terraform 状态、GitOps 仓库、镜像仓库和密钥备份必须独立于主地域。每月执行备份恢复，每季度执行地域切换、Kafka 重放和节点故障演练。

8. AI Research 与 Agent

Research RAG 使用关键词与向量混合检索，答案必须带数据日期、来源和文档引用。LLM Gateway 负责模型路由、缓存、脱敏、Token 预算、超时和降级。

Agent 工具采用显式 JSON Schema，限定可查询数据集和最大结果量。外部研报作为不可信输入处理。高成本回测、大规模导出以及未来可能增加的实盘操作必须经过人工审批。所有工具调用写入不可篡改审计日志。

9. 失败处理与质量保障

• 采集失败进入重试主题和死信主题；恢复后按事件时间重放。
• 数据质量门禁覆盖完整性、唯一性、价格边界、交易日历和跨源对账。
• 因子发布前检查未来函数、幸存者偏差、缺失率、极值和稳定性。
• 回测采用确定性随机种子，并验证手续费、滑点、停牌、涨跌停和公司行动。
• 下游索引写入采用幂等键，失败后从 Iceberg 快照重建。
• 发布前执行容量压测、故障注入和完整地域恢复演练。

10. 成本估算

以下为满负载月度人民币估算，不含税，实际成本受云厂商折扣、平均 QPS、回测 CPU 小时和模型调用量影响。

项目	月成本（万元）
在线 Kubernetes、Gateway、CDN	45-90
Kafka、Flink	25-55
对象存储、Iceberg、目录服务	10-30
ClickHouse	25-60
PostgreSQL、Redis、OpenSearch	25-60
Spark、Ray 弹性计算	50-180
网络、监控、安全	25-70
异地容灾	40-100
LLM 推理或 API	30-200
合计	275-845

行情、公告和研报授权通常另需 20 至 200 万元以上/月。MVP 阶段预计 20 至 50 万元/月，增长阶段预计 80 至 180 万元/月。预留实例、Spot 回测节点、冷热分层和模型路由预计可降低 30% 至 50% 的可优化成本。

11. 分阶段交付

1. 基础期：日线/分钟线数据湖、批量因子、单策略回测、基础 API 和统一身份。
2. 增长期：Flink 实时链路、ClickHouse、分布式 Ray 回测、租户配额和完整可观测性。
3. 智能期：Research RAG、受控 Agent、报告生成和模型成本治理。
4. 规模期：数据库分片、跨地域温备、20 万 QPS 压测和自动扩缩容优化。

每一阶段均以可观测的容量阈值触发下一阶段，而不是仅以注册用户数判断扩容。