How WeChat Built a Scalable Security Data Warehouse: Architecture, Evolution, and Data‑Quality Practices

Business Background

WeChat, with over a billion monthly active users, requires robust security capabilities. Without sufficient feature data, security policies are ineffective. The security data warehouse serves as the central store for feature data, handling trillions of read/write requests daily and underpinning all security policies.

Security Strategy Development Process

The workflow consists of feature data collection, policy authoring, and policy evaluation. High‑quality feature data is essential because it directly impacts policy effectiveness.

Why a Dedicated Data Warehouse?

Before the warehouse, teams stored computed features in ad‑hoc KV clusters, leading to fragmented storage, inconsistent management, and poor data quality. Consolidating features into a unified warehouse improves sharing, management, and reliability.

Architecture Evolution

The warehouse has progressed through several versions:

Version 1.0 : Deployed shared real‑time and offline KV clusters with an access layer that abstracts KV details and provides a unified read/write API.

Version 2.0 : Added read/write separation and multi‑IDC synchronization. Offline features are synchronized via shared files; real‑time features use a distributed queue.

Version 2.1 : Replaced the public distributed queue with an internal lightweight message queue (MQ) for asynchronous writes, improving isolation and control.

Version 3.0 : Introduced an operations system that automates feature request, launch, management, analysis, value query/modification, and data‑quality monitoring.

Storage Selection

Two main feature types are supported:

Offline features : Computed in batch, loaded into KV for online reads; no real‑time writes.

Real‑time features : Require low‑latency read/write access.

WeChat uses self‑developed KV services:

Offline write / real‑time read KV : Optimized for massive key updates with versioning and excellent read performance.

Real‑time read‑write KV : Strong consistency, ACID guarantees, TTL support.

Unified Access Layer

The access layer hides KV specifics, assigns each feature a unique identifier <sceneId, columnId>, and provides unified read/write methods. It also handles configuration management, parameter validation, module and permission checks, flow reporting, and PV statistics.

Read/Write Separation & Multi‑IDC Sync

Read traffic far exceeds write traffic, so reads and writes are split into separate modules. Data is replicated across multiple IDC clusters to avoid cross‑IDC latency. Offline feature sync uses shared files; real‑time feature sync uses the internal MQ to propagate changes across IDC sites.

Asynchronous Write & MQ Replacement

To reduce the performance impact of synchronous writes, an asynchronous MQ module was introduced, replacing the public distributed queue. This lightweight, internally managed queue ensures reliable multi‑IDC synchronization without interference from other services.

Operations System

The operations system streamlines feature lifecycle:

Feature request : Users submit requests via a web UI, which are approved through a generic workflow.

Feature launch : Approved features are automatically deployed without manual configuration.

Feature management : Metadata (business category, type, owner, tags) can be queried and edited.

Feature analysis : Tracks source data, computation steps, data flow, and storage details.

Feature value query & modification : Provides web‑based read/write of feature values.

Data‑quality management : Integrated into the workflow (described below).

Data‑Quality Assurance

Feature Standardization

All features must conform to a documented specification, including type, business classification, and other metadata. The system validates submissions against this spec, rejecting non‑compliant entries. C++ programming guidelines and examples are provided to ensure consistent implementation.

Empty‑Run System for Offline Features

Before an offline feature file is loaded into production KV, an empty‑run process validates the file:

Business uploads the data to a standby offline KV (empty‑run table).

The system samples live read traffic, routes a portion to the empty‑run table, and compares results.

If the difference exceeds a threshold, the upload is blocked; otherwise it proceeds.

After passing the empty‑run checks, the file’s integrity is verified before final loading into the production KV. Any failure triggers alerts for manual intervention.

Conclusion

By centralizing feature data, providing a unified access interface, enforcing standardization, and implementing rigorous quality checks, the security data warehouse has become a foundational component for WeChat's security policies, dramatically improving efficiency, reliability, and overall data value.