Day38-19｜19.6.3 某证券公司大数据系统：实时行情、风控与监管分析一体化
Day38-19｜19.6.3 某证券公司大数据系统：实时行情、风控与监管分析一体化
对应教材目录：第 19 章 大数据架构设计理论与实践 → 19.6 大数据架构设计案例分析 → 19.6.3 某证券公司大数据系统
学习目标：理解证券公司大数据系统的业务数据、实时性和合规特点；掌握行情、交易、客户、风控、清算和监管数据的架构设计；能够用 Lambda 或混合大数据架构处理实时监测、历史分析、模型训练、对账和灾备。
一、证券大数据系统的业务背景
证券公司同时处理行情、交易、账户、持仓、资金、风控、清算、客户服务和监管数据。市场开盘和重大行情波动期间，行情和交易事件会高速增长；风险控制要求在很短时间内发现异常；清算、结算和监管报表又要求准确、可追溯和可复核。
行情源/交易所 -> 接入与标准化 -> 实时风控/行情服务
客户/账户/交易 -> 事件平台 -> 实时指标/告警
|
+--> 历史归档/批处理
-> 清算、报表、模型、监管证券系统的架构不能只追求吞吐和低延迟，还必须保证交易数据不可抵赖、资金和持仓完整、权限隔离、监管可追溯以及故障时不发生错误交易。
二、主要数据来源
1. 市场行情
包括证券报价、成交、指数、盘口、行业和市场状态。行情数据具有高频、连续、顺序和低延迟特征，通常需要按证券、市场和时间分区处理。
2. 交易与委托
包括委托、撤单、成交、拒单、订单状态和渠道信息。交易事件是业务事实，必须有唯一编号、时间、来源、状态和完整性校验。
3. 账户、资金和持仓
包括客户资料、账户状态、资金流水、持仓、融资融券和资产估值。这些数据敏感且与资金权益相关，需要严格的机密性、完整性和访问审计。
4. 风险和合规数据
包括异常交易、反洗钱、适当性、集中度、涨跌停、保证金、黑名单和监管规则。风控模型和规则应版本化、审批和可解释。
5. 外部和研究数据
包括新闻、公告、行业、宏观和第三方数据。外部数据需要标识来源、授权、时间和可信度，不能与交易事实混为一谈。
三、证券大数据系统面临的挑战
1. 高吞吐和低延迟
行情和交易事件在开盘、收盘及异常波动时集中到达。实时风控和交易监测需要秒级甚至更低延迟，历史分析则需要大规模扫描和复杂计算。
2. 数据正确性
行情乱序、重复或丢失会影响指标和策略；交易重复处理可能造成严重业务后果；资金和持仓错误会直接影响客户权益。因此需要序列、幂等、校验、对账和人工复核。
3. 强监管和可追溯
监管机构可能要求保留订单、成交、风控决策和操作证据。系统要能够回答某时刻使用了什么数据、规则、模型和配置，谁做了什么操作。
4. 多系统一致性
交易、账户、清算、风控、客户和报表系统需要共享关键事实。实时指标和最终账务可以存在暂时差异，但必须可解释、可对账和最终收敛。
四、总体架构
交易所/行情源/柜台/账户/客户/外部数据
|
接入、校验、标准化、签名
|
事件总线/持久化日志
/ \
/ \
实时层：行情、风控、监测 原始数据湖/归档
| |
实时视图、告警、策略服务 批处理/湖仓/模型训练
\ /
\ /
数据服务、报表、清算、监管、研究
|
身份、权限、审计、密钥、灾备对于资金、持仓和清算，应保留核心交易数据库或账务系统作为权威系统；大数据平台负责实时分析、服务和历史处理，不应绕过账务边界直接修改资金事实。
五、实时行情处理
1. 接入与顺序
行情消息应携带证券、市场、序列号、事件时间、来源和校验信息。接入层检测序列缺口、重复和异常时间，必要时向上游请求补发。
2. 实时计算
速度层计算最新价、涨跌幅、成交量、盘口指标、指数、行业统计和异常波动。不同用户对延迟和准确性的要求不同，行情服务要区分实时快照、确认数据和历史收盘数据。
3. 缓存和服务
实时行情通常写入低延迟存储和缓存，通过订阅、推送和查询接口服务交易终端、移动端和研究系统。缓存要带时间戳和版本，过期行情不能无标识地继续展示。
六、交易和实时风控
1. 订单事件
委托、撤单、成交和拒单事件形成完整链路。交易服务应保证唯一订单号、状态机、签名、幂等和顺序，实时风控读取事件进行额度、频率、集中度和异常行为检查。
2. 风控特征
实时特征包括账户余额、持仓、可用资金、近期成交、撤单频率、价格偏离、设备和渠道。部分特征需要从账务系统实时获取，部分特征可由事件流维护。
3. 决策和人工复核
风控结果可以是放行、拦截、增强认证、延迟处理或人工审核。高风险规则和模型必须记录版本、输入特征、决策原因和操作人员，不能只保存一个“拒绝”标志。
七、批处理和历史分析
批处理层负责：
- 交易和行情历史归档。
- 日终清算和资金持仓对账。
- 监管报表和合规数据准备。
- 客户画像、资产分析和产品分析。
- 历史行情、策略回测和风险模型训练。
- 异常交易调查和事件重建。
批处理使用经过确认的数据和版本化规则，结果要记录计算范围、代码、模型、规则和时间。监管报表发布前进行数据质量和账务对账，不能直接使用未确认的实时估算。
八、Lambda 的应用方式
1. 速度层
处理行情、委托和成交事件，生成实时快照、风险指标、账户特征、异常告警和实时监控。
2. 批处理层
读取完整历史事件，进行去重、修正、日终统计、归因、回测、报表和模型训练。
3. 服务层
按用户和业务提供实时行情、风险结果、历史查询、监管数据和研究数据。服务层要区分实时预估、交易确认和账务最终结果。
九、数据一致性、对账和恢复
证券系统应建立多层对账：
交易所/柜台成交
<-> 交易系统
<-> 账户与持仓
<-> 清算与资金
<-> 大数据平台/报表对账发现差异后，需要区分延迟、重复、丢失、规则差异和真实业务调整。修复要经过审批，保留原始流水和补偿记录，不允许直接覆盖历史账务。
灾备恢复时，优先恢复身份、网络、交易状态和权威账务，再恢复实时分析、报表和研究服务。恢复后的交易、资金和持仓必须先对账，再逐步开放高风险操作。
十、数据安全和权限
客户资料、资金、持仓、交易、策略和研究数据分级保护。交易和账户服务采用服务级身份和最小权限，研究人员不能访问全量客户敏感信息，外部合作方只能访问授权字段和范围。
关键操作包括修改风控规则、调整额度、人工放行、资金处理、报表发布和数据导出，必须多因素认证、职责分离、临时授权和审计。密钥、证书、备份和日志独立管理，保证数据机密性和抗抵赖。
十一、模型与规则治理
风控模型、行情指标和合规规则都要版本化。模型上线前进行回测、压力测试和误报评估，上线后灰度和监控；规则变更需要审批、发布窗口和回滚。
决策结果应保存模型或规则版本、输入特征摘要、风险等级和原因。历史重算时使用指定版本，不能用今天的模型直接解释过去的监管决定。
十二、案例分析：证券公司大数据平台建设
某证券公司原有交易系统能够完成下单和清算，但实时风险监测能力弱，客户画像和历史回测分散在多个系统。公司要求建设统一数据平台。
建设方案：
- 交易、行情、账户和外部数据通过统一接入层进入事件平台，保留来源和版本。
- 速度层提供实时行情、风险特征、异常交易检测和告警。
- 批处理层进行日终对账、监管报表、历史回测、客户画像和模型训练。
- 数据服务层按研究、运营、风控、管理和监管提供不同视图和权限。
- 交易和账务系统仍是资金、持仓和最终交易状态的权威来源。
- 通过事件 ID、序列、幂等、对账和审计确保大数据结果不破坏账务完整性。
- 关键赛事或市场波动期间预留弹性资源，降低非核心批任务优先级。
- 建立双机房或多区域灾备、密钥恢复、日志保护和演练机制。
十三、案例题答题模板
证券大数据案例可以按以下结构回答：
- 识别行情、交易、账户、资金、持仓、风控和监管资产。
- 说明实时低延迟、数据正确、监管追溯和高可用目标。
- 设计数据接入、事件总线、速度层、批处理层和服务层。
- 说明实时风控、行情服务、历史分析、模型和报表。
- 说明权威账务边界、对账、幂等、顺序和恢复。
- 说明权限、加密、审计、模型规则治理和隐私。
- 说明开盘峰值、网络故障、数据修正、灾备和降级。
十四、课后练习
练习 1
为什么大数据平台不能直接作为资金和持仓的唯一权威系统？
参考答案：资金和持仓需要严格事务、完整性、审计和清算边界，实时大数据平台更适合分析、服务和监测；应以交易或账务系统作为权威来源，通过事件、对账和确认结果向数据平台同步。
练习 2
证券实时风控需要哪些实时特征？
参考答案：账户余额、持仓、可用资金、近期交易、撤单频率、价格偏离、集中度、设备、渠道、历史风险和异常行为等，具体按业务选取。
练习 3
监管报表为什么要使用批处理和对账后的结果？
参考答案：实时数据可能重复、迟到、修正或未完成清算；批处理可以完成去重、核算、对账和版本确认，保证监管结果准确、可追溯和可复核。
练习 4
论文题：论“证券公司大数据系统的架构设计”。
参考答案要点：行情接入、交易事件、实时风控、批量清算、数据湖/仓、模型、监管、权限、审计、对账、灾备、峰值和安全治理。
十五、今日复盘
- 我能否区分行情、交易、账户、账务和分析数据？
- 我是否能说明实时风控和批量监管的分工？
- 我能否设计证券数据的对账、幂等和恢复机制？
- 我是否考虑模型、规则、权限、审计和隐私？
- 我能否在案例题中保护权威账务边界？
证券公司大数据系统案例的核心结论是：速度层承担行情、风控和实时监测，批处理承担清算、对账、监管和历史分析，服务层按业务提供实时与确认结果；大数据平台必须与交易、账户和账务权威系统清晰分工，并通过事件、版本、对账、审计和灾备保证金融数据可信。
