量化金融
经禾信息
深耕金融大数据领域，从 GCP 迁移至 AWS，构建弹性数据湖架构，支撑全球量化分析与回测业务。
项目概述
经禾信息是一家专注金融大数据的高科技公司，核心产品是量化金融数据平台。数据涵盖股票、基金、研报、专利、社交媒体、财经新闻等多个领域，7×24×365 为投资机构、研究机构、学术单位和监管部门提供服务。
平台原来运行在 GCP 上，基于 Apache Spark 构建数据湖，存储约 25TB 金融数据，同时维护着约 20GB 的结构化数据库。随着业务规模扩大和国际化需求，GCP 的跨域延迟、弹性不足、成本控制等问题逐渐显现。经禾信息决定将平台整体迁移至 AWS，以 Amazon EMR 替代原有 Spark 集群，用 S3 承接数据湖存储，同时借助 AWS 的全球基础设施优化海外访问体验。
1. 客户简介
上海经禾信息技术有限公司专注于金融大数据领域，依托自主研发的量化金融数据平台，为资本市场提供全面的数据产品与分析服务。核心业务包括开发基于资本市场的数据库和软件产品，提供金融大数据挖掘、建模和分析等服务。
经禾信息已构建起领先的财经数据仓库和分析平台，数据内容涵盖股票、基金、研报、专利、社交媒体、财经新闻等领域，并持续实时更新。产品和服务广泛应用于投资机构、研究机构、学术机构和监管部门，帮助用户全天候获取及时、准确、完整的财经数据和各类分析结果。
原来平台运行在 GCP 上，结合虚拟机集群和对象存储构建数据湖，承担实时行情采集处理、历史数据清洗归档、量化策略回测模拟、终端用户交互分析等核心任务。随着业务扩展，全球访问延迟、弹性不足、成本压力等问题逐渐突出。
2. 项目背景
客户需求
- 整体迁移至 AWS：将 GCP 上的量化金融数据平台迁移至 AWS，构建弹性、高可用、具备全球服务能力的云原生数据基础设施。
- 强化数据安全与合规：平台涉及海量行情数据、交易订单及敏感金融数据，需要借助 AWS 的权限管理、加密和审计能力，满足金融科技行业合规要求。
- 弹性计算与成本优化：量化分析与回测业务有明显周期性波动，希望平台能根据负载动态扩缩容，按需调度资源。
- 全球低延迟访问：服务对象拓展至海外金融机构与科研用户，需要多区域部署与灾备能力，确保终端用户体验。
源架构（GCP）
当前 GCP 架构组成
负载均衡
Cloud Load Balancing（全局 HTTP(S) 负载均衡器），支撑前端 Web Server 与应用层的高可用
应用层
三层架构，Web Server 与 Application Server 部署在 Compute Engine 虚拟机上，规格 n2-standard-8（8 vCPU / 32GB 内存）
数据库层
Cloud SQL for MySQL，8 vCPU / 32GB 内存，高可用主备架构。数据库总量约 20 GB
数据分析层
基于 Apache Spark 开源框架，运行在 GCP 虚拟机上，结合 Cloud Storage (GCS) 构建数据湖，存储行情、交易、舆情等数据，总量约 25 TB
3. 业务需求
3.1 核心痛点
- 跨域延迟难解决：GCP 在日本有节点，但对欧美和东南亚覆盖不如 AWS 密集，海外用户访问体验差。
- 弹性不足：Spark 集群运行在固定配置的虚拟机上，高峰时资源不够用，低谷时又白白浪费。
- 成本控制困难：按固定配置计费，无法按实际使用量付费，大数据计算成本居高不下。
- 数据孤岛：结构化数据在 Cloud SQL，非结构化数据在 GCS，两套存储体系管理成本高，分析时需要跨系统取数。
3.2 优化目标
目标：以 Amazon EMR + S3 为核心构建统一数据湖，实现计算与存储分离、弹性扩缩容、全球低延迟访问，同时满足金融数据安全合规要求。
4. AWS 服务映射
| AWS 服务 | 用途 | 优先级 |
|---|
| Amazon EMR |
替代 GCP 上的 Spark 集群，作为大数据计算核心，支持 Spark、Hive、Presto 等引擎 |
P0 |
| Amazon S3 |
替代 GCS，作为统一数据湖存储，承载 25TB 历史数据及增量数据 |
P0 |
| Amazon RDS (MySQL) |
替代 Cloud SQL，承载 20GB 结构化业务数据，保留原有应用接口 |
P1 |
| Amazon EC2 |
替代 Compute Engine，承载 Web Server 和应用层服务 |
P1 |
| Application Load Balancer |
替代 Cloud Load Balancing，提供七层负载均衡和健康检查 |
P1 |
| Amazon CloudWatch |
监控 EMR 集群、EC2 实例、RDS 数据库的运行状态和性能指标 |
P2 |
| AWS Lambda |
自动化任务编排：数据导入导出、集群启停、备份调度 |
P2 |
| Amazon Route 53 |
域名解析与流量管理，支持多区域故障转移 |
P3 |
| AWS Certificate Manager |
SSL 证书管理，为各区域服务提供 HTTPS 加密 |
P3 |
| AWS KMS |
数据加密密钥管理，满足金融数据安全合规要求 |
P1 |
| Amazon VPC |
网络隔离，划分私有子网、公共子网，管控访问安全 |
P1 |
5. 架构设计
目标架构基于 AWS 日本区域（ap-northeast-1）构建，采用计算存储分离的数据湖模式，支撑全球多区域访问。
目标架构分层
接入层
Route 53
ACM 证书
CloudFront（全球 CDN）
ALB
应用层
EC2 (Web/App Server)
Auto Scaling
VPC 私有子网
数据层
Amazon RDS MySQL
Amazon S3 数据湖
AWS KMS 加密
计算层
Amazon EMR
Spark / Hive
Spot 实例降本
弹性扩缩容
运维与监控
CloudWatch
CloudTrail 审计
Lambda 自动化
关键设计决策
- 数据湖统一存储：原来分散在 GCS 和 Cloud SQL 的数据，迁移后统一存放在 S3，结构化数据用 Parquet/ORC 格式存储，便于 EMR 直接分析，消除数据孤岛。
- 计算存储分离：EMR 集群可以独立扩缩容，不再受限于固定虚拟机配置，高峰时临时扩容，低谷时释放资源。
- 多区域部署：核心业务在日本区域，海外访问通过 CloudFront 分发静态内容，动态请求通过 Route 53 路由到就近区域。
- 安全合规：所有数据在传输和静态时都经过 KMS 加密，CloudTrail 记录所有操作日志，满足金融数据安全审计要求。
6. 非功能需求
可用性
核心服务目标 99.9%，EMR 集群支持多可用区部署，RDS 启用多 AZ 高可用，S3 提供 99.99% 耐久性。
性能
实时行情数据从采集到可查询延迟 < 5 分钟，批量回测任务支持并行执行，EMR 集群峰值吞吐满足 TB 级数据处理。
安全性
VPC 隔离、Security Group 最小权限、KMS 数据加密、CloudTrail 操作审计，符合金融数据安全规范。
成本
EMR 使用 Spot 实例处理批任务，按需实例处理实时任务，S3 智能分层自动归档冷数据，预计降低 30-40% 计算成本。
可维护性
基础设施即代码（CloudFormation/Terraform），自动化备份与恢复流程，监控告警覆盖所有关键组件。
可扩展性
S3 存储容量无上限，EMR 集群支持动态增减节点，应用层 Auto Scaling 自动响应流量变化。
7. 迁移方案
整体迁移分五个阶段，预计 14 周完成。先迁移非核心数据，再迁移核心业务，最后切换流量。
阶段一 · 准备 (Week 1-2)
环境搭建与基线评估
在 AWS 搭建 VPC、子网、安全组等基础网络；创建 RDS 实例并配置备份策略；评估现有 GCP 资源使用情况和数据量级，制定详细迁移清单。
阶段二 · 数据迁移 (Week 3-6)
历史数据迁移
将 GCS 中 25TB 数据迁移至 S3，使用 AWS DataSync 或 AWS Snowball 分批迁移；将 Cloud SQL 中 20GB 数据迁移至 RDS，采用逻辑备份 + 增量同步方式，确保数据一致性。
阶段三 · 应用迁移 (Week 7-9)
服务部署与联调
在 EC2 上部署 Web Server 和应用层服务；搭建 EMR 集群并验证 Spark 任务兼容性；完成应用与 RDS、S3 的连接测试；更新域名解析指向 AWS 环境。
阶段四 · 割接上线 (Week 10-11)
流量切换与验证
通过 Route 53 逐步将流量从 GCP 切换至 AWS；先切换只读流量，再切换写流量；全程监控数据一致性和业务可用性，保留 GCP 环境作为回滚备份。
阶段五 · 收尾 (Week 12-14)
优化与运维移交
调整 EMR 集群规格和 Auto Scaling 策略；配置 CloudWatch 告警规则；完成运维文档和应急预案；确认 GCP 环境停止计费后关停。
迁移风险与应对
| 风险 | 影响 | 应对措施 |
|---|
| 25TB 数据迁移时间长 |
迁移窗口超出预期 |
使用 Snowball 搬运冷数据，DataSync 同步热数据；分批次迁移，优先迁移近期数据 |
| Spark 任务兼容性问题 |
数据分析功能异常 |
迁移前在测试环境全量跑一遍历史任务，记录差异点并修复 |
| 迁移期间数据不一致 |
业务数据丢失或重复 |
采用双写策略，迁移期间 GCP 和 AWS 同时写入，割接前校验数据一致性 |
| 回滚需求 |
业务中断 |
保留 GCP 环境运行至 AWS 稳定后 30 天，期间可随时切回 |
8. 项目团队
项目经理
张明远
统筹项目进度，协调客户与内部资源
架构师
李浩然
AWS 架构设计，EMR 数据湖方案，迁移技术评审
大数据工程师
王启航
Spark 任务迁移适配，EMR 集群搭建与调优
DevOps 工程师
陈晓薇
自动化迁移脚本，监控告警配置，运维交接
关键里程碑
| 里程碑 | 时间 | 交付 |
|---|
| 迁移方案评审通过 | Week 2 | 架构设计文档、迁移计划 |
| 数据迁移完成 | Week 6 | 数据一致性校验报告 |
| 应用部署完成 | Week 9 | 环境验收报告、测试记录 |
| 割接上线 | Week 11 | 上线确认书、运行监控报告 |
| 项目验收 | Week 14 | 运维文档、项目总结 |
有云迁移或架构优化需求？
我们可以帮你做一次免费的架构评估，找出成本优化的空间。
联系我们
