数据中台建设优化

发表于

优化点：

一、字段分类：

​ 1、目的：

1
2
3
4
5
聚焦到模型核心字段的理解上，区分出工作重心，合理的利用资源。
避免调入以下两个误区：
1、对所有字段都理解透彻后才能有产出，低效率误区。
2、对所有字段都理解都是同样的深度，同等重要误区。
对数据的认识，是随着时间的变化，场景的变化，业务需求的变化，而逐渐迭代完善的，并非是一次性的工作。

​ 2、方法：

1
2
3
4
5
6
7
8
9
10
字段分类:
A类：主键或索引类，与数据业务高度相关，尤其会觉得数据的特性，是衡量数据唯一的标准，
     理解不到位，可能会涉及到数据量的变化、重复数据的产生。
B类：下游数据的生成核心依据类，
     可能是生成下游数据的筛选条件、判断条件、关联条件；
     可能是生成下游数据的计算条件、分组条件、排序条件；
				例如：拉链表依据的业务时间
	 理解不到位，可能会导致下游数据无法正常生成，错误生成。
C类：描述属性，仅在本表独立使用，即使错误也仅仅影响当前的数据，不会对下游数据造成影响；
	 一对一的直接使用，下游使用时不存在转换，不涉及到处理逻辑，即使错误也仅仅是影响到单一字段的数据内容，不会对其他字段数据造成影响。

​ 3、标准：

1
2
3
4
5
6
7
8
整个建设过程中，应该重点分析，深入研究的是A、B两类字段，调低C类字段的较真优先级；
C类字段：需要达到数据能正确入库；
B类字段：需要在C类的基础上，加深对业务的理解。完整的表述在生成下游数据时候的逻辑规则，
         涉及到码值转换的，需要提供完整（至少是能支撑生成下游数据）的码表，及其转换规则
         涉及到计算逻辑的，需要正确体现，数据类型，精度（例如：计算平均值，不能直接使用字符类型）
         涉及到条件筛选的，需要明确数据的全量与筛选数据的关系（例如：性别总量 = 男 + 女 ？性别总量 = 性别总量 - 男 ）
         尤其是在涉及到数据逻辑时，一定要遵循：【MECE法则：ME-相互独立、CE-完全穷尽】
A类字段：尽可能贴近真实的业务数据，而非按照自己的想法，阅历，想当然的敲定。一定要通过业务数据进行验证。
二、模型使用流程：

​ 1、目的：

1
2
3
数据中台建设已经有一定的沉淀，尤其是数仓的全业务域，后续的迭代方式不再是从0做起，而是从非0做起，可能不全面，不完善，甚至可能有错，但绝对不是0.
改变我们的建设流程，先从数仓的全业务域中查找需要用到的业务数据，而非直接从原始的业务模型中阐述逻辑。
先当我们自身的全业务域中无法查找，或者

​ 2、方法：

1
2
3
4
5
通过字段信息、表信息，从全业务域中查询需要使用的数据项，识别出当前全业务域中的对应数据是否满足业务需求，
满足则直接将全业务域模型当做等同于业务数据模型进行使用。
部分满足，则提出整改意见，先完善全业务域对应的模型，再将全业务域模型当做等同于业务数据模型进行使用。
不满足，则提出新增要求，先增加全业务域对应的模型，再将全业务域模型当做等同于业务数据模型进行使用。
只有通过我们自身将全业务域模型用起来，才能发现全业务域数据的不足，逐渐的完善、优化全业务域模型，让他能真正的被用起来。

​ 3、标准：

1
2
3
1、完善全业务域模型与业务模型的对应关系，加强全业务域模型的描述内容，提高产品经理对模型的认识和理解
2、只有将全业务域模型设计前置，在先完善全业务域模型的基础上，产品和设计都基于相同的模型进行后续的数仓应用设计，主题指标设计，才能真正的减少依赖关系，体现出数仓分层的数据隔离特性。
   当前的情况是，产品经理从业务模型开始需求设计，当需求评审通过后，再发起全业务域模型的建设要求，全业务域模型建设完成后，放过来指导产品设计。这个过程中就存在，全业务域模型的与产品经理理解的业务模型可能存在差异，而没有及时同步信息。
三、统一血缘关系输出物：

​ 1、目的：

1
为保证理解的一致性，产品、研发与测试需要基于同一份文档，表述表间关系、字段间关系。只有先统一了材料，才能更好的进行协同，和维护。

​ 2、方法：

1
2
3
通过xlsx的文档，体现出表与表之间的关系，表字段与表字段之间的关系。
必须体现表间的逻辑关系，尽可能的体现出字段级关系。
有能力者应该在关系后面体现出计算逻辑信息。

​ 3、标准：

1
2
3
4
5
6
7
8
参照data.csv文件格式
至少包含4列信息：
ssort     源表类别（可以是业务域或者数仓层级）
source    源表名称
target    目标表名称
tsort     目标表类别（可以是业务域或者数仓层级）
存储方式： UTF-8(逗号分隔)(*.csv)
可直接转为关系图。

流程优化，不同环节的聚焦内容：

一、产品输出：

​ 1、加强输出物内容的一致性，原型、需规、业务模型中的核心内容，至少满足拷贝粘贴后能查询出相同的信息。

​ 2、在先扩展数仓模型的基础上，进行后续的业务、指标设计。不能重复的造轮子，至少需要理解全域数据中心，有能力的可以理解OneId体系，和主题域的模型

二、需求理解：

​ 1、重点放在实现上，针对A、B类字段进行深入探讨，对C类字段，尽可能的调低预期要求，降低产品的业务识别压力。

三、产品设计：

​ 1、重点体现出关系，表之间的关联关系，字段之间的关联关系，尤其是A、B类字段的关联关系。有能力者应该在关系后面体现出计算逻辑信息。

​ 2、可以有自己的惯用文档，但必须要形成一份共用的文档，只有使用同一份文档，才易于维护、协同和传承。

四、用例设计：

​ 扩展三个视野：

​ 1、数据的异步到达场景，有相关性的数据，未按照业务发生的顺序归集数据，当数据都归集到位后，是否能生成预期数据。

​ 2、数据指标间的逻辑等值性，不仅仅是同一个界面的指标才需要关注等值性，更应该关注到系统内，不同界面，同类指标间的逻辑等值性。

​ 3、数据间的关系检查，有关系的数据，改变或者删除某一个源信息，对结果数据的影响是否满足预期，检测关联关系：强关联，左关联。

五、需求沟通：

​ 1、沟通的成果必须有输出，保证结论、过程的可追溯性。重点内容一定是有WIKI记录的。

​ 2、沟通的成果，及时更新到对应的输出物中，并做好修改记录。

六、研发跟踪：

​ 加强设计与实现的一致性检查，重点检查事前设计和事后实现的血缘对应关系。

​ 1、通过对比事前设计和执行后的数据血缘关系图进行验证。

​ 2、通过改变部分源头数据，检查结果数据进行验证。

​ 只有设计与实现一一对应，才能说明研发成果与设计是相符的，即使真有实现优于设计的情况发生，也需要及时的更新设计，保持设计与实现的一致性检查，才能在设计的基础上进行后续的迭代。