docs(kb): 新增 12-同步方案.md

kb/12-同步方案.md

@@ -0,0 +1,119 @@
+# 业务数据同步方案
+
+> 本文档记录 `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 契约、类型映射参考