【数据分层】方法论

1 OneData方法论介绍

1.1 OneData方法论简介

一般标准数据架构有(ODS、DWD、DWS、DIM、ADS)。OneData方法论提供了具体的实施途：1.需求调研、2.数据域划分、3.构建总线矩阵、4.明确统计指标、5.模型设计(规范定义/明细模型设计/汇总模型设计)、6.代码开发、7.部署运营。

1.2 可升级的方向

一般数据构架问题：
1.架构定位与边界不清楚，导致ADS烟囱化开发；
2.ADS集市缺少统一规划、混乱低效；
3.ADS集市指标口径急需要统一；
4.缺少高质量的设计标准，模型千人千样，事后问题频发;
5.规划缺少配套的产品化工具落地保障。

---

2 OneData规范升级方案

通常有这几个方向：
数据架构升级、明确各层次定位：
1）应用层专注支撑业务，提升服务业务的效率，确保口径一致性，核心内容的稳定性；
2）公共层通过抽象复用提升应用层的效率，同时共性逻辑下沉确保全局一致性；因內考虑复用性，服务多个集市下游，也需要关注模型设计的易用性和稳定性；
3）贴源层在数据合规的背景下，需要关注数据接入的合规性；同时贴源层不做太多的逻辑转化，通过工具来提升接入效率。
升级完善OneData规范。
产品能力升级，确保模型规范有效执行。

---

3 数据架构升级

3.1 架构建议

数据分层建议
• ODS(操作数据层)：把操作系统数据几乎无处理的存放在数据仓库系统中，采用增量或全量同步。
它主要关注数据安全合规、业务系统的稳定性、数据存储成本。
• 公共层：公共层通过抽象集市复用逻辑，按业务过程重新定义数据，提升应用层的开发效率。
主要有DWD(明细层）、DIM（统一维度层）DWS（汇总层）。
• 集市层：数据集市是满足特定的部门或者用户需求，按照业务角度组织数据，快速满足业务的数据层。数据集市需关注研发效率、口径一致性，以及核心应用的稳定性。
主要有ADS、MDS。

公共层数据域建议
a.数据域的抽象原则，根据高内聚低耦合的基础原则，以数据消费的内聚性、数据来源的内聚性、數据加工的内聚性进行抽象定义数据域标准；
b.数据域的划分需统一标准，尽量符合MECE原则（相互独立，完全穷尽）。

应用层集市域建议
a. 集市的划分原则，以业务场景或者服务对象作为划分原则，对相似数据业务场景内聚抽象进行分类；
b.集市域的划分需统一标准，尽量符合MECE原则。

3.2 模式设计基础原则

1. 高内聚和低耦合，主要从以下两个角度来考虑：a.业务特性（将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型）；b.访问特性（将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储）。
2. 核心模型与扩展模型分离
3. 公共处理逻辑下沉及单一
4. 指标一致性
5. 命名清晰可理解
6. 合理的层次依赖：
   a.dwd避严格遵守层次依赖，理沦上只可引用ODS、DIM和部分DWD数据，不可引用处于下游层次的ADS等数据;
   b.dws应严格遵守层次依赖，理论上只可引用DIM、DWD数据，不可引用处于下游层次的ADS等数据。

---

4 贴源层设计原则

ODS主要实现统一接入，在合规的基础上实现接入效率和性能稳定。
设计过程使用数据集成工具实现接入高效性和唯一性；并且只做简单清洗，不做过度加工，保持与业务库的一致性；采用合理的同步方式，保障数据的时效性。

---

5 公共层设计原则

5.1 数据域并不是一成不变，数据域随着业务也需要迭代。

5.2 公共层准入门槛是否有共性逻辑。

公共层在架构中的定位为抽象复用，降低应用层的开发成本，并确保口径一致性，因此公共层的准入门槛在于需求上是否是共性逻辑。公共层共性需求的识别方法一般由事前专家经验判断、事后沉淀。
1）DWS准入逻辑：DWS核心是通过空间换时间，提升效率节约成本的同时实现数据口径的统一。
专家经验：判断指标是否业务的KPI指标，或者实现KPI指标的核心过程指标；
事后沉淀：需求指标是否已经覆盖了>=2个以上的稳定产品或应用。
2）DWD准入逻辑：DWD核心是以维度建模重构基础模型，降低统计分析中频繁关联，提升基础数据模型的易用性。
专家经验：判断是否是业务核心业务过程（如电商主干业务过程浏览、加购、交易等）；
事后沉淀：是否覆盖下游>=5稳定的应用场景。

5.3 公共层模型需要进行复用性抽象以提升通用性。

1）DWS模型因其为汇总表，复用性的抽象需要从指标复用性、粒度复用性两方面进行考虑。
2）DWD模型抽象复用：事实表模型设计尽量分解不可加事实为可加事实。
3）DIM模型抽象复用：适当构建分析维表，以满足分析维度统一和复用性问题。

5.4 公共层需要考虑成本与效率的平衡。

公共层逻辑是以空间换时间，根据数据量不同情况，需要考虑增加的成本与效率之间的平衡。
1）数据体量小的，牺牲小资源成本获得极大的扩展性，带来人员效率提升和成本降低。
2）数据体量大的，需要平衡成本与效率。

5.5 公共层需要进行易用性考量以提升应用研发的效率

1） DWS模型易用性上，通过冗余维度属性、采用大宽表方式构建，以提升下游易用性。
2） DWD模型易用性上，通过采用星型模型、维度冗余和信息完善度进行设计，以提升下游易用性。

5.6 通过必要的稳定性设计以满足核心应用的时效性要求

1）扁平化设计提升稳定性：公共层整体需扁平化设计
2）DWS稳定性设计：结合访问热度、数据稳定情况，进行必要的解耦设计，以提升DWS模型的稳定性；

6 应用层设计原则

6.1 应用层需要进行集市域划分，降低各集市的复杂度

6.2 应用集市需要扁平化设计提升稳定性降低运维成本

造成深度过深原因一般有：
a、缺少扁平化设计导致ADS依赖链路深，如多种长周期累计型指标场景1D->7D->1M->1Q-1Y；
b、为了快速响应业务，导致不同场景间互相依赖引用；
c、缺少共性集市中间层的沉淀构建，导致ADS依赖深度加深。

6.3 应用层的设计遵循需求驱动，不做过度的扩展设计以需求驱动构建集市

6.4 需要识别变化的需求进行差异化的应用层策略支持。

需要对业务场景的变化进行必要预判，将变化的需求转变成不变的需求提升扩展性，通过轻量化设计降低研发成本。
1）稳定和变化的识别：稳定需求、变化需求、需求承接方式
2）在变化需求中寻找不变的设计思路：维度变化、指标变化。
3）针对业务临时探查、E商业分析、数据科学探索等场票，适当构建细粒度的大宽表，用于提升日与业务分析同学的效率，同时规避口径不一致的风险。
4）尽量避免变化传递，降低变化带来的改造成本：如行业类目、商家分层、统计类的分析维度属于易变分析维度，应缩短多节点间沉淀依赖，降低变化维度带来的回刷和变更改造成本。

6.5 尽量减少对贴源层的依赖，以规避系統变更带来的影响

6.6 应用层设计上也需要进行共性抽象下沉，以提升效率和口径一致性。

1）集市内构建MDS确保集市内口径一致性和研发效率。
2）跨集市共性指标下沉DWS确保全域口径一致性
a）事前-专家经验判断下沉：基于业务目标和策略拆解出来的KPI和KP|过程指标，各业务团队会重点关注，可以提前进
b）事后：致据吸动判断下況：从两个箱度判断，一是因不合理的跨集市依赖驱动下沉DWS，二是根据救据選银相似度评估，结合专系经验判断进行广办。

6.7 MDS需要适当构建分析维表，方便分析维度统一

MDS层是集市内部的可复用中间层，不仅包括明细和汇总，也包括维表。在不同的分析场景中，如果包含相同维度的定义、归类、映射等，应构建集市内部的分析维表，避免在不同的场景中造成数据的不一致。

---

7 公共层共建机制

7.1 机制目标

提高协同效率、降低开发成本，提升数据开发质量。

7.2 核心角色

有业务方、应用层数据开发、公共层数据开发。

7.3 协作流程

分为六个环节：需求收集、方案设计、数据开发、数据测试、数据运维、數据治理。

7.4 协作分工

为了提高协同效率，分为2种模式：
1.公共层研发主导开发
针对DWD、DIM核心模型或整体性的公共层开发，由公共层同学主导设计和开发，确保公共层设计的复用性和易用性。
2.应用层研发主导开发
1）针对一些DWD、DIM非核心模型或离散型的公共层需求或者口径变更，应用层研发主导开发。
2） 针对DWS数据，可以由应用层开发直接对公共层数据进行开发，但是必须由对应的公共层开发进行评审，同时进行代码Review，实现公共层数据的稳定性和变更的灵活性的兼顾，当DWS数据跨集市复用后转交给公共层研发开发和维护。

7.5 机制保障

为了保障共建机制的有效执行，通过以下方式进行管控：
1.统一方法论
2.统一使用智能建模
公共层开发统一使用智能建横工具，从产品测进行设计、开发、发布保障，通过评审流程、开发推荐、上线管控等方式实现设计和开发的规范。
3.评估体系&治理
4.统一数据专辑