# 业务数据同步方案

> 本文档记录 `poyee-data-warehouse` 业务数据从云上生产库同步到自建 Hive 集群的阶段性方案与演进路径。
> 当前作用域：云上 RDS PostgreSQL → 自建 Hive。ES 埋点库同步方案另行规划。

## 1. 涉密字段处理策略

**背景**：业务表中存在涉及商业机密和用户隐私的敏感字段，需要在方案设计前明确处理策略。该决策会直接影响后续所有同步链路的字段清单、脱敏逻辑、以及 Hive 表结构设计。

| 方案 | 核心思路 | 优势 | 风险 | 是否采纳 |
|------|---------|------|------|---------|
| **方案一：同步端裁剪/脱敏** | 在 DataX / CSV / Flink CDC 同步过程中剔除涉密字段，或做不可逆脱敏（哈希、掩码）后入仓 | 数仓侧彻底无涉密数据，安全风险最低；合规审计简单 | 数仓失去"统一数据归档"的完整性，未来若有合规的分析需求（反欺诈、用户画像）需要原始字段时无法回溯 | **是** |
| 方案二：全量同步 + 数仓侧权限控制 | 涉密字段原样入仓，通过 Ranger 做库/表/列/底层文件级权限控制和动态脱敏 | 保留完整数据资产，数仓真正承担"统一归档"职责；不同角色按需看不同精度的数据 | 原始涉密数据落在自建集群，需要完善的权限体系、审计日志、数据加密（HDFS 透明加密）和运维管控 |  |

## 2. 整体策略

采用**基线 + 增量 + 历史归档（仅订单）**的分阶段同步思路，后续演进到实时同步：

- **存量同步**：选定某个日期为基线，一次性同步基线前的全部历史数据
- **增量同步**：基线后的数据通过每日定时任务增量同步
- **历史归档数据导入**：离线硬盘中 2022–2023 年的历史数据，通过离线方式导入并用 Spark 解析入仓（下一阶段）
- **实时同步**：后续演进为基于 CDC 的准实时同步（下一阶段）

## 3. 存量同步方案选型

| 方案 | 可行性 | 说明 |
|------|--------|------|
| DTS 数据传输服务 | ❌ 不可行 | 不支持 PG → Hive/HDFS，仅支持数据库间同步 |
| **RDS PG 同步工单** | ⚠️ 已弃用 | 支持自定义列和 SQL、导出 CSV |
| Dataphin | ❌ 不采用 | 成本高、体量重、接入复杂，性价比低 |
| **DataX** | 已采纳 | 阿里开源，原生支持 PG → HDFS/Hive |

**RDS PG 同步工单优劣：**

- 需要开发 Spark 解析脚本（开发调试约 1 天工时）
- 需要提供字段剪裁 SQL，在阿里云 PG 产品后台管理操作工单
- ⚠️ **风险点**：存量数据体量大，瓶颈在工单导出至本地的带宽

**DataX 优劣：**

- 使用同步配置剪裁字段，使用 JDBC 连接源端 PG，目标端写入 HDFS/Hive
- 需要配置云 RDS PG 实例的防火墙策略，放通自建集群出口 IP
- ⚠️ **风险点**：存量数据体量大，预估同步耗时较长（可能跨数天），需做好分片、断点续传和失败重试策略

## 4. 增量同步方案

**方案：DataX 定时增量同步**

- 每日凌晨 6 点定时触发，同步当日增量/变更数据
- 通过 JDBC 拉取，依赖云端到自建集群的网络链路
- 增量识别依赖业务表的 `update_time` 等增量标识字段（部分表没有，但字段名已统一；依赖后端改造相关服务）
- 删除识别依赖 `is_deleted` 软删除字段（部分表没有）

**待推进的数据库规范：**

1. `create_time` / `update_time` 必须存在
2. 必须有软删除字段（目前不统一，后期要统一字段名）

## 5. 历史归档数据导入（下一阶段）

**背景**：2022–2023 年的订单历史数据当前存放于离线硬盘，未进入在线库，需要一次性导入 Hive 做历史回溯分析。

**已确认**该部分数据与线上 PG 存量数据存在时间范围和记录上的重叠，需要做去重合并处理。

**方案：离线硬盘 → HDFS → Spark 解析 → 数据合并 → Hive**

执行步骤：

1. **数据探查**：硬盘中数据格式已确认为 insert 语句
2. **落盘到 HDFS**：将硬盘数据上传至 HDFS 临时目录，避免重复搬运
3. **Spark 解析入临时表**：根据格式编写 Spark 作业完成解析、清洗、字段对齐，先写入 Hive 临时归档表（不直接进最终表）
4. **数据合并与去重**：与 DataX 同步的存量数据按主键合并，**以 `update_time` 最新的记录为准**
5. **一致性校验**：合并后抽样核对主键数量、关键字段分布，确认无缺失或异常重复
6. **写入最终归档分区**：确认无误后写入 Hive 最终表，清理临时数据

### 5.1 待确认事项

- 硬盘数据规模：约 30G
- 字段 schema 是否与当前线上 PG 表一致：可兼容
- 所有业务表是否都有可靠的 `update_time` 字段：待探查。如没有，默认填 2010 年防止覆盖已有数据

## 6. 实时同步方案（下一阶段演进）

| 方案 | 对源库影响 | 改造成本 | 说明 |
|------|-----------|---------|------|
| DTS → Kafka → 下游消费 | 无 | 中 | 由 DTS 订阅 PG 变更写入 Kafka，下游用 Flink/Spark 消费入 Hive |
| Flink CDC 直连主库 | **有**（需开启 WAL，影响写性能） | 低 | 仅适合业务写入量较小的场景 |
| **Flink CDC 接从库**（PG 从库是否支持订阅逻辑复制待确认） | **无**（主库零影响） | 中 | PG 开启主从，从库只读，Flink CDC 订阅从库 |

**倾向方案：Flink CDC + PG 只读从库**

核心优势是**对主库零影响**，同时保留 CDC 的低延迟能力，兼顾稳定和实时。

## 7. 整体架构示意

```
现阶段（T+1）：
  云 RDS PG ──(DataX/CSV 基线全量)──> Hive（存量分区）
  云 RDS PG ──(DataX 每日增量)──> Hive（每日凌晨 3 点）

下阶段（历史归档 + 准实时）：
  离线硬盘(2022-2023) ──> HDFS ──(Spark 解析)──> Hive(历史归档分区)
  云 RDS PG(主) ──> PG(只读从库) ──(Flink CDC)──> Kafka/Hive
```

## 8. 待确认事项汇总

- 存量 DataX 同步需做小表试点测速后推算总耗时（影响 DataX 分片策略和同步时长预估）
- 增量字段的可用性（是否所有业务表都有可靠的 `update_time`）✓
- 网络带宽限制（云到自建机房的专线或公网带宽）✓
- 防火墙配置：大数据集群 IP 漂移处理（前期规模小先用 jump 中转）✓
- 离线硬盘数据的格式、规模、schema 待探查 
- RDS PG → Polar PG 迁移路径

## 9. 相关文档

- [数据资产](11-数据资产.md) — 业务库与埋点数据源清单
- [数仓分层与建模](20-数仓分层与建模.md) §6 — 数据同步策略、快照类型决策
- [数仓分层与建模](20-数仓分层与建模.md) §8 — raw / ods 契约、类型映射参考