• 数据仓库：存储历史数据的地方，用于为了更好地管理和使用数据。

  
  

• 数据仓库：数据仓库扮演着历史数据存储、离线数据汇聚整合、公共数据统一加工发布的角色，数据仓库将公司所有结构化数据，包括内部数据和外部购买的数据，进行整合和基础加工，为各数据使用人员提供统一的数据支持。

• 根据我们对数据的需求，可以将数据系统分为两种，分别是交易型数据系统和分析型数据系统：

  交易型数据系统多用于交易，用于业务，操作时提取的数据量少，经常是精确或小批量提取，操作上主要是增删改。在交易型数据系统中，存放数据的地方，是数据库。常用库软件如oracle、mysql、SQL Server。 分析型数据系统多用于分析，需要用到历史数据，操作时提取的数据量巨大，经常是批量提取，不需要数据能够实时更新，要求大批量数据查询速度快。在分析型数据系统中，存放数据的地方，是数据仓库。常用库软件如GaussDB。按笔者现在理解，数据仓库是分析性数据系统的一部分。

• 交易型数据系统通过和用户的交互产生数据；分析型数据系统从交易型数据系统获得数据，加工分析后衍生数据。

• 分析型数据系统所存储的数据量非常大，为了更好的管理，我们常对其进行分层，分别是：

  1 操作数据存储层(Operational Data Store, ODS)

  2 公共数据存储层(Global Data Store,GDS),也可以称之为数据明细层(Data WareHouse Detail, DWD)

  3 业务数据存储层(Business Data Store, BDS),也可以称之为数据服务层(Data WareHouse Service, DWS)

  4 应用数据存储层(Application Data Store, ADS)

1 ODS:

分析系统需要从交易系统取数，首先面临以下问题：

• 不同的交易系统可能使用不同的存储方式，如数据库存储、excel存储、txt存储；同样使用数据库存储的，可能使用不同的数据库，如mysql、oracle；同样使用txt文件存储的，可能使用不同的存储方式，如utf-8、gbk。

• 数据仓库的工作人员，可能存在多个部门同时从同一个交易系统中取数的情况，也可能存在先后从交易系统中抽取同一数据的情况。当多个部门同时从交易系统中取数，势必会对交易系统的运行造成压力，当多个部门先后从交易系统中同样的数据，势必会造成存储浪费。

ODS从数据源中取数，源数据经过抽取、转换、加载，即ETL后，装入ODS层。为了便于数据追溯等原因，ODS层除了做一些去除回车符、无效空格等操作外，几乎不对数据做任何内容上的清洗，只将数据原封不动的装载进来供下游人员取用。ODS实时或准实时的从源系统进行抽取数据。

2 GDS:

对于同一类型的数据，不同系统可能有着不同的存储格式，以时间为例，有的存储格式为20210124，有的则为2021-01-24；对于同一个指标，不同系统可能使用着不同的码值，以性别为例，有的直接命名为男、女，有的则以1代表男，0代表女。 GDS一般按照主题划分，开发落地各种表单以供BDS各个集市使用，同时将BDS各集市共用或复用性比较高的表单落地到GDS，提高开发效率。GDS可以细分为两部分:公共明细层(GDS-D[Detail])、公共汇总层(GDS-S[Summary])：

• GDS-D: 1 指标的格式统一，如时间统一用连续的数字表示，并存储为字符串格式。 2 指标的码值统一，统一用1代替男，0代替女 3 用代理键作为主键。 需要注意的是，GDS只进行格式统一和码值统一等工作，但不制定格式和码值，即GDS是作为执行者，不是立法者，指定格式和码值等比较公用型的工作另有部门负责。
• GDS-S: 1 轻度维度退化:将维度表退化至事实表，减少关联，提高查询效率 2 轻度数据聚合:关联多个事实表，形成宽表供下游使用，提升公用指标的复用性，减少重复加工 3 轻度指标衍生:衍生BDS中各个集市公用程度高的新指标，方便其使用
• GDS-S在进行维度退化，数据聚合，指标衍生的时候，主要从下游,即集市的角度考虑，主要为两点： 1 BDS各集市公用程度比较高的指标:各集市需要拼接同样或重复性高的几张表，应考虑由GDS-S层先进行统一加工，从而减少表拼接操作。 2 BDS各集市均需要从GDS取同一张表，对其衍生同样或类似的指标后使用，或进行同样的筛选条件，应考虑由GDS-S层先进行统一加工。

3 BDS:

不同公司有不同的业务集市划分方法，以银行为例，可划分为零售业务集市，对公业务集市，风险业务集市，运营业务集市。

• 零售集市: 面向零售业务线，加工个人客户的数据，提供各主题的指标汇总，如客户、地域、资产、协议、交易等主题的数据汇总。
• 对公集市: 面向对公业务线，加工公司客户的数据，提供各主题的指标汇总，如客户、地域、资产、协议、交易等主题的数据汇总。
• 风险集市: 提供信贷、信用卡、风险相关的经营、考核、监控等指标模型，既包括个人的，也包括公司的。 与零售和对公集市相比，风险集市主要加工贷款、征信等方面的数据。 零售与对公集市如若涉及风险方面数据，大多只是纪录粗粒度信息，如客户是否有贷款以及贷款总金额等；风险集市纪录具体信息，如贷款额合同内容、签约时间、借据号、还款方、利息、逾期情况、在其他公司贷款等等。
• 运营集市: 沉淀内部资金定价、成本均摊、资产管理、绩效管理等系统的公共数据需求，提供统一数据支撑。 如记录公司内部各机构组织，柜面每日交易记录，自助设备，利率汇率等信息，同业之间往来明细，公司员工明细、各种设备资金流动情况等。 运营集市一般以内部各对象为中心，比如以机构为中心，以设备为中心，以利率为中心等进行汇总记录，其下游应用部门，主要是对内服务。

4 ADS：

领导想要知道本月有多少有效户，有效户的定义是：月日均aum>1000 + 最近15天发生动账 + 最近15天登陆了手机银行。 为了得到有效户这个口径：

1. ODS从源系统抽取了相关数据，并进行同一转码
2. GDS从ODS接入数据并进行基本加工，如加工了aum月日均字段。
3. BDS根据GDS的数据，直接抽取了aum月日均字段，自己加工了最近15天是否动账，最近15天是否登陆手机银行3个字段
4. ADS从BDS取出3个相关字段进行判断后，加工出是否有效户字段。

ODS、GDS和BDS大多时候接收的是中间数据，产出的也是中间数据，ADS接收的是中间数据，产出的是业务人员或领导直接需要的信息。

本文将数据分析系统分为了4层，分别是ODS,GDS,BDS.ADS。从ADS部分的示例来看，为了加工出一个指标，经历了4层。在这里，我们可以思考：

1. 当业务部门对ADS提出需求后，ADS是否可以不经过BDS，直接从GDS取数加工出有效户指标？
2. 假设ADS加工了一个新指标m，BDS知道了后表示需要用，是否可以直接从ADS抽取？

针对上述问题的发生，可能会有以下开发规定，以规范开发：

1. ODS从各个交易系统取数。
2. GDS应从ODS取数，不能从其他层取数。
3. BDS应从GDS取数，不应该从ADS或ODS取数。
4. ADS应从BDS取数。

以上规范中，不允许逆向取数（比如不允许BDS从ADS取数）的规范容易执行，但是规范不允许顺向跨层取数时，容易造成以下情况：当业务部门提出一个指标时，开发周期长。

但是若允许ADS从GDS取数，可能会出现BDS被架空的情况，即BDS开发需求少。

done！

以上ODS–>GDS–>BDS–>ADS的架构方便了数据管理，减少了数据冗余，但是造成了数据开发周期长、或者某个部门被“跨过”的问题。

那么，是否有办法可以两者兼得？或者根据自己的实际情况，调整架构？

读者若有疑问或感觉不妥之处，欢迎沟通交流。微信： xiaojian625800335