业务数据同步方案

本文档记录 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 软删除字段（部分表没有）

待推进的数据库规范：

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

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

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

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

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

执行步骤：

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

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

12-同步方案.md 6.7 KB Geçmiş Ham