Jinghe Information

1. Client Introduction

Shanghai Jinghe Information Technology Co., Ltd. focuses on financial big data, providing comprehensive data products and analysis services to the capital market through its self-developed quantitative financial data platform. Its core business includes developing database and software products based on the capital market, as well as offering financial big-data mining, modeling and analysis services.

Jinghe has built a leading financial data warehouse and analytics platform covering stocks, funds, research reports, patents, social media and financial news, with continuous real-time updates. Its products and services are widely used by investment institutions, research institutions, academic institutions and regulators, helping users access timely, accurate and complete financial data and analysis results around the clock.

The platform originally ran on GCP, combining VM clusters and object storage to build a data lake that handled core tasks such as real-time market-data ingestion, historical data cleansing and archiving, quantitative strategy backtesting, and end-user interactive analytics. As the business expanded, issues such as global access latency, insufficient elasticity and cost pressure became prominent.

2. Project Background

Customer Requirements

1. Migrate entirely to AWS: Move the quantitative financial data platform from GCP to AWS, building an elastic, highly available, cloud-native data infrastructure with global service capabilities.
2. Strengthen data security & compliance: The platform handles massive market data, trade orders and sensitive financial data, requiring AWS's permission management, encryption and auditing to meet fintech compliance.
3. Elastic compute & cost optimization: Quantitative analytics and backtesting have clear periodic peaks; the platform should scale dynamically with load and schedule resources on demand.
4. Global low-latency access: As services extend to overseas financial institutions and research users, multi-region deployment and disaster recovery are needed to ensure end-user experience.

Source Architecture (GCP)

3. Business Requirements

3.1 Core Pain Points

1. Cross-region latency: GCP has nodes in Japan, but its coverage of Europe, America and Southeast Asia is less dense than AWS, leading to a poor experience for overseas users.
2. Insufficient elasticity: The Spark cluster ran on fixed-spec VMs — insufficient at peaks, wasted at troughs.
3. Cost control difficulty: Billing by fixed specs means paying for unused capacity; big-data compute costs stayed high.
4. Data silos: Structured data in Cloud SQL and unstructured data in GCS meant two storage systems with high management overhead and cross-system retrieval for analytics.

3.2 Optimization Goals

4. AWS Service Mapping

5. Architecture Design

The target architecture is built in the AWS Tokyo region (ap-northeast-1), adopting a compute-storage separated data-lake pattern to support multi-region global access.

Key Design Decisions

• Unified data-lake storage: Data previously scattered across GCS and Cloud SQL is consolidated into S3 after migration, stored in Parquet/ORC format for direct EMR analysis, eliminating data silos.
• Compute-storage separation: The EMR cluster can scale independently, no longer bound to fixed VM specs — scale out at peaks, release at troughs.
• Multi-region deployment: Core business in the Tokyo region; overseas access served via CloudFront for static content, dynamic requests routed by Route 53 to the nearest region.
• Security & compliance: All data is encrypted in transit and at rest with KMS, and CloudTrail records all operation logs, meeting financial data security audit requirements.

6. Non-Functional Requirements

7. Migration Plan

The overall migration is divided into five phases, expected to complete in 14 weeks. Migrate non-core data first, then core business, and finally cut over traffic.

Migration Risks & Mitigations

8. Project Team

Key Milestones