银行的 STG 缓冲层（Stage Layer）、数据备份、数据脱敏

银行的STG缓冲层

银行的STG缓冲层（Stage Layer），是银行数据仓库中的临时数据“中转站”和“缓冲区”。

为了方便理解，可以把数仓的数据处理想象成一个后厨做菜的过程，那么 STG 层就是刚从菜市场买回来、还没来得及清洗的“毛菜”。

📌 STG层在数据仓库中的位置

在银行的数据仓库架构中，STG 层是数据进入的第一站，位于数据源和 ODS（操作数据层）之间。

它的定位类似于一个短暂停留的数据准备区或贴源缓存区。

✅ STG层的主要作用

STG 层的设计目的是为了将数据采集与数据处理解耦，它在银行的大数据场景中扮演着几个关键角色：

• 数据缓存与减压：业务系统（如核心交易系统、信贷系统）的数据往往是实时或高频变化的。STG 层就像一个大容量的“蓄水池”，先把原始数据“倾倒”进来，避免频繁地直接读取业务库，从而减轻对上游业务系统的压力。

• 保持原始“凭证”：最关键的一点是，STG 层会最大程度地保持数据与源系统一致，几乎不做复杂的转换和清洗。这样做的好处是，万一后续数据处理出了问题，可以从 STG 层找到最原始的数据进行恢复或重跑，相当于提供了一个“后悔药”。

• 数据清洗与预处理：虽然是缓冲区，但 STG 层通常会进行一些最基础的“粗加工”，比如：

  • 过滤垃圾数据：剔除格式明显错误、乱码或空值的关键字段。

  • 数据标准化初筛：为下游的 ODS 层准备好干净的数据。

• 临时存储与中转：对于从日志、文件等异构数据源抽取的数据，STG 层提供了一个统一格式的临时落地点，方便后续 ETL（抽取、转换、加载）流程统一调度。

🏦 银行业的特点

相比互联网行业，银行对数据的准确性、稳定性和可追溯性要求极高。因此，银行的数仓分层会更精细，STG 层的作用也更突出。

例如，恒丰银行的架构中，与 STG 层定位相似的ODM（源数据缓存区）就是专门用来缓存结构化原始数据的。

📊 STG层与ODS层的对比

STG 层与它的下游——ODS 层——常被混淆，但两者的核心区别如下：

💎 总结

简单来说，银行的STG 缓冲层就是大数据平台接收原始数据的“第一落地点”。它像一道“防火墙”，既保护了上游的业务系统，又为下游的精确加工提供了稳定、可靠的原始数据来源。

银行的数据备份

银行的数据备份是一个体系化的工程，和你理解的数据仓库（数仓）处理逻辑很不一样。

简单来说，备份是为了“恢复原样”，追求百分百的一致性和完整性；而数仓是为了“分析价值”，会进行清洗和转换。

针对你的问题，我把核心要点整理如下：

📌 1. 备份频率与保留时长

银行采用分级分类的策略，根据数据的重要性灵活调整。

• 核心交易数据（极高频率）：这类数据最重要，通常用实时同步（双活/主备），RPO（恢复点目标）接近0，确保数据几乎不丢。同时配合每日全量备份和实时归档日志，以实现任意时间点的恢复。

• 非核心/日志数据（中低频率）：系统日志、配置文件等变化慢的数据，采用每周全量+每日增量的策略。

• 保留期限：主要依据监管红线。例如，业务凭证（如转账凭证）需保留5年，账户档案和台账需保留10年，风险管理文件则要保留15年。

💿 2. 备份在哪？存多久？是“原封不动”吗？

• 存储位置：必须遵循“两地三中心”原则。即一份数据会同时在本地生产中心、同城备份中心（应对火灾、机房故障）和异地备份中心（应对地震、洪水）各存一份。

• 存储介质：通常是磁盘阵列（快速恢复）和磁带/蓝光（长期低成本归档）的组合。

• 数据形态：必须是“原封不动”的物理备份。这是为了应对“误删数据”或“数据库崩溃”等突发状况，必须保证恢复出来的数据和出事前一模一样。

⚙️ 3. 备份与数仓的关系：完全的顺序无关，但逻辑分离

这是一个很好的问题，两者虽然都处理数据，但目标和时序是独立的：

• 关系：完全顺序无关。它们是两条数据流。

• 备份：发生在生产系统（如核心交易库）。它是OLTP（联机事务处理）层面的事情，目标是容灾。

• 数仓：发生在大数据平台。它是OLAP（联机分析处理）层面的事情，从生产库复制一份数据过来，然后进行清洗、转换（ETL），最后进入ODS/DWD层。

• 核心差异：备份是把数据一股脑打包，用来“救命”；数仓是把数据解包、拆解、规范成“范式模型”或“星型模型”，用来“分析”。

🔗 4. 备份需要拉链表吗？

不需要，但在数据仓库中需要。

• 在生产端（备份对象）：不需要。备份是物理级的块复制，不做逻辑处理。

• 在数仓端（备份策略无关）：需要。拉链表是数仓建模的经典工具，用于高效记录维度数据的历史变化（如客户的地址、手机号变更），这与备份完全是两个维度的技术。

💎 总结

• 生产数据备份：是银行的“保险柜”，追求完整和速度（原样拷贝），遵循“两地三中心”的物理隔绝策略。

• 数据仓库（数仓）：是银行的“分析室”，追求整洁和历史追溯（清洗转换），利用拉链表等技术进行逻辑建模。

因此，备份发生在大数据平台之外，它是数据进入数仓前的源头保障，确保即使原始数据出了问题，也有最可靠的副本可以恢复。

之所以会问备份，是因为我以为STG层就是备份，银行大数据开发，数据脱敏在哪一步进行

这个问题问得很精准，确实容易混淆。我来帮你理清这两个关键点。

1. 为什么你会觉得 STG 层就是备份？

因为从流程上看，STG 层确实很像一个“备份”：它把生产数据几乎原封不动地拷贝过来，形成一个原始数据的副本。但它们在目的和保障上有本质区别：

一句话区别：STG 层是“数据处理的起点”，而真正的备份是“系统失效的最后一道防线”。

2. 银行大数据开发中，数据脱敏在哪一步进行？

数据脱敏通常有3 个主要环节，它们的位置决定了不同的脱敏策略。

最常见的实践是第 2 步（ETL 过程中）或第 4 步（数据服务层）。

各步骤的具体情况：

银行业的常见做法：

• 生产 → STG：不做脱敏。STG 层保留原始格式，用于 ETL 排错和重跑。

• STG → DWD：做脱敏。这是最常见的脱敏点。例如，将身份证号、手机号在 ETL 过程中进行替换、掩码或哈希，生成不可逆的伪数据。

• DWD → 下游：根据需要可能再次脱敏。例如，在 ADS 层针对不同报表做精细化控制（如大屏展示用掩码，数据导出用加密）。

💎 总结

1. STG 层不是备份，它只是一个临时缓冲区。真正的备份发生在生产系统侧，是独立于数仓的“容灾保险”。

2. 数据脱敏的核心位置是 ETL 过程（STG → DWD）。这是成本最低、管控最集中的环节。此外，在数据服务出口（API/BI）也常做二次脱敏以满足不同场景需求。

3. 顺序关系：备份（生产侧） → STG（明文） → 脱敏（ETL过程） → DWD及下游（脱敏后数据）。备份与脱敏是两个独立阶段，备份是前置保障，脱敏是合规要求。

STG的数据是来源于备份，还是直接来自生产端，拉数据对生产端有影响吗

STG 层的数据是直接从生产端拉取的，不是来源于备份。

这是一个很重要的区分，直接关系到你的第二问：拉数据对生产端的影响。

1. STG 数据来源：直连生产，不经过备份

银行的数仓系统（大数据平台）为了获取最及时的业务数据，通常会直接与生产数据库建立数据同步链路，而不是从备份系统中恢复数据。

主要原因包括：

• 时效性：备份系统主要用于灾难恢复，数据有延迟。数仓需要准实时或 T+1 的数据进行分析，直接从生产同步更快。

• 数据量级：备份是大块头的物理文件，恢复成本高。数仓通过逻辑同步（如解析数据库日志）只拉取需要的数据，更轻量。

• 流程独立：备份服务于容灾，数仓服务于分析，两者是并行且独立的系统。

2. 拉数据对生产端有影响吗？

答案是：有，而且这是大数据开发中必须重点关注和规避的风险。

直接从生产库拉取数据，如果控制不当，确实会拖慢核心交易系统的响应速度，甚至造成业务抖动。

但从技术实践来看，这些风险是完全可控的。

银行通常采用以下几种成熟策略来降低影响：

3. 真正的“备份”在哪里？

你在上一个问题中认为“STG 就是备份”，这个直觉其实很接近实际——STG 充当了数仓体系的“数据保险箱”：

• 对于数仓自身：如果后续的清洗（ETL）逻辑写错了，或者表结构需要重跑，可以直接从 STG 层重新拉取原始数据恢复，不需要再去生产系统要数据。

• 对于生产系统：STG 层承担了数据缓冲作用，避免了下游分析任务直接冲击生产库。

但在银行整体的 IT 容灾体系中，真正的备份是指生产系统侧独立的物理备份（如磁带库、CDM 副本等），用于应对机房断电、存储损坏等极端灾难。

💎 总结

1. STG 来源：直接来自生产端同步（如从库、日志同步），不是从备份恢复的。

2. 对生产的影响：有影响，但可规避。通过“读写分离、错峰调度、增量抽取”等手段，可以将影响降到最低。

3. 角色定位：STG 是数仓的原始数据缓冲区，而生产备份是银行的灾难恢复保险。两者职责不同，但 STG 确实承担了为数仓“兜底”的角色。