7.数据中台 --- 数据开发：数据体系建设

7.1　数据体系规划
		各种系统产生的原始数据堆积在一起导致使用成本非常高，这类数据只能在某些数据技术基础非常好的部门使用，而且会经常出现
	命名不一、口径不一的问题，从而导致整个企业的数据无法真正用起来。数据中台数据体系是在全域原始数据的基础上，进行标准定义
	及分层建模，数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，可以方便的支撑数据应用。

		中台数据体系应具备以下特征：
			1.覆盖全域数据
				数据集中建设，覆盖所有业务过程数据，业务在中台数据体系中总能找到需要的数据。
			2.结构层次清晰
				纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解。
			3.数据准确一致
				定义一致性指标，统一命名、统一业务含义，统一计算口径，并有专业团队负责建模，保证数据的准确一致。
			4.性能提升
				统一的规划设计，选用合理的数据模型，清晰的定义并统一规范，并且考虑使用场景，使用整体性能更好。
			5.降低成本
				数据体系的建设使得数据能被业务共享，这避免了大量烟囱式的重复建设，节省了计算、存储和人力成本。
			6.方便易用
				易用的总体原则是越往后越能方便的直接使用数据，把一些复杂的处理尽可能前置，必要时做适当的冗余处理。比如在数据的
			使用中，可以通过维度冗余和事实冗余来提前进行相关处理，以避免使用时才计算，通过公共计算下沉、明细与汇总共存等为业务
			提供灵活性。统一数据体系的建设让整个企业的业务都有机会使用数据。


		为了使数据体系在建设使具备以上特征，需要一个体系化的数据层次架构，这个层次架构定义了数据分层及每一层的建模建设规范。数据
	体系架构是一套指导规范，在实施过程中应严格按照架构执行。数据中台体系架构涉及以下4个数据分层：
		1.贴源数据层ODS(Operational Data Store，操作数据层)
			对各业务系统数据进行采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合、非结构化数据结构化
		处理或者增加标识数据日期描述信息，不做深度清洗加工。

		2.统一数仓层DW(Data Warehouse)
			又分为 明细数据层DWD(Data Warehouse Detail)和汇总数据层DWS(Data Warehouse Summary)，与传统数据仓库功能基本
		一致，对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的，
		而统一数仓层从业务易理解的角度来重新组织，定义一致的指标、维度，各业务板块、业务域按照统一规范独立建设，从而形成统一规范的
		标准业务数据体系。

		3.标签数据层(Tag Data Model)
			面向对象建模，对跨业务板块、跨数据域的特定对象进行整合，通过ID-Mapping把各个业务板块、各个业务过程中的同一对象的数据
		打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。

		4.应用数据层(Application Data Store)
			按照业务的需要从统一数仓层、标签数据层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用
		组装应用数据。


		另外，建设过程中数据的读取也有严格的规范要求。按照规范，贴源数据层直接从业务系统或者日志系统中获取数据。贴源数据层的数据只被
	统一数仓使用，统一数仓层数据只被标签层和应用层使用、贴源数据层、统一数仓层只保存历史数据以及被标签层、应用层引用，不直接支撑业务，
	所有业务使用的数据均来源于标签层和应用层。

		由于贴源数据层仅做业务数据的同步和存储，应用数据层面只向特定业务组装数据，这2层没有太多的建模规范。


7.2　贴源数据层建设——全域数据统一存储
		贴源数据层会对企业各业务系统数据进行汇聚整合，保留企业全量业务原始数据，并作为统一数仓层建设的数据源。贴源数据层数据不仅是
	业务数据库中产生的数据，跟企业相关的所有数据都应该汇聚到贴源数据层，包括业务系统数据、业务运行的日志数据、机器运转产生的日志数据、
	网络爬虫或者其他方式获得的数据。

	1.相关概念
		贴源数据层，是数据体系架构中最接近数据源的一层。并不对业务数据进行过多的清洗加工，尽可能保留数据的原始状态。贴源数据层建设的目标
	就是把企业的全域原始数据都汇聚到数据中台，从而能在数据中台查询到所有的企业数据，为后面的统一数仓层、标签数据层、应用数据层建设做准备。

		数据中台的贴源数据层数据获取方式与传统数仓的ETL过程类似，但也有不同。传统数仓的ETL过程是在抽取和装载的过程中进行清洗转换操作，
	装载到数仓的是清洗转换后的数据。这样的方式如果转换规则复杂，就会导致在ETL过程中消耗大量的计算资源，另外如果转换有错误，由于没有保留
	原始数据，则会导致在数仓层面无法追溯问题。在进入大数据时代，由于存储成本降低和数据量增大，导致ETL过程中的复杂处理非常耗时，因此建议
	采用ELT方式，即将所有原始数据都抽取到数据中台的贴源数据层，在数据中台内部再利用大数据底层平台的计算能力进行转换操作。这样既可让数据
	的抽取过程尽可能简单，又保留了所有原始数据，以便于问题的追溯，还能充分利用大数据的计算能力。

		按照数据结构类型的不同，贴源数据可以分为三类：
			1.结构化数据
			2.半结构化数据
			3.非结构化数据

	2.贴源数据表设计
		贴源数据层中的数据表与对应的业务系统数据表原则上保持一致，数据结构上几乎不做修改，所以参考业务系统数据表结构来设计贴源数据层表
	结构即可。考虑到业务系统数据的多样性，贴源数据层数据表的设计要遵循一定的规范：
		a) 贴源数据层表的命名采用前缀+业务系统表名的方式。比如，ODS_系统简称_业务系统表名，这样既可以最大限度的保持与业务系统命名一致，
		又可以有清晰的层次，还可以区分来源。

		b) 贴源数据层表的字段名与业务系统字段名保持一致，在ODS层不做字段命名归一。字段类型也尽可能保持一致，如果数据中台没有与业务系统
		对应的类型则可以用一个可以兼容的数据类型。

		c) 对一些数据量比较大的业务数据表，如果采用增量同步的方式，则要同时建立增量表和全量表，增量表利用后缀标识。比如，ODS_系统简称_
		业务系统表名_delta，汇聚到增量表的数据通过数据加工任务合并生成全量表数据。

		d) 对于日志、文件等半结构化数据，不仅要存储原始数据，为了方便后续的使用还要对数据做结构化处理，并存储结构化之后的数据。原始数据
		可以按行存储在文本类型的大字段中，然后再通过解析任务把数据解析到结构化数据表中。

	3.贴源数据表实现
		贴源数据层一般采用数据同步工具实现数据的同步落地，具体的实现步骤如下：
			1.确定业务系统源表与贴源数据层目标表
			2.配置数据字段映射关系，目标表可能会增加采集日期、分区、原系统标识等必要信息，业务相关内容不做转换
			3.如果是增量同步或者有条件同步部分数据，则配置数据同步条件
			4.清理目标表对应数据
			5.启动同步任务，往贴源数据层目标表导入数据
			6.严重任务是否可以正确运行，并且采集到准确数据
			7.发布采集任务，加入生产调度，并配置相关限速、容错、质量监控、告警机制


7.3　统一数仓层建设——标准化的数据底座
		贴源数据层只对企业各个来源的数据做汇聚、整合，并没有做过多的加工处理，数据基本还是原始结构。且业务系统更多的是按照流程组织数据，
	为保证流程的完整、方便，没有按照业务的本质来组织数据，贴源数据并不方便业务理解，更不适合做分析、挖掘。

		统一数仓层站在业务的视角，不考虑业务系统流程，从业务完整性的角度重新组织数据。统一数仓层的目标是建设一套覆盖全域、全历史的企业数据
	体系，利用这套数据体系可以还原企业任意时刻的业务运转状态。只要能达到这个目标，利用 范式建模、维度建模、实体建模 中任意一种建模方式都是
	可以的。这里主要介绍维度建模，因为它更合适大数据时代数据量巨大的特点。

		维度建模 用事实表、维度表来组织数据。有以下特点：
			1.模型简单易理解
				仅有维度、事实两种类型数据，站在业务的角度组织数据。

			2.性能好
				维度建模使用的是可预测的标准框架，允许数据库系统和最终用户通过查询工具在数据方面生成强大的假设条件，这些数据主要在表现
			和性能方面起作用。

			3.可扩展性好
				具有非常好的可扩展性，以便容纳不可预测的新数据源和新的设计决策。可以在不改变模型粒度的情况下，很方便的增加新的分析维度和
			事实，不需要重载数据，也不需要为了适应新的改变而重新编码。良好的可扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的
			结果。

			4.数据冗余
				由于在构建维度事实表星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新
			进行维度定义时，往往需要重新进行维度数据的预处理。而在这些预处理过程中，往往会导致大量的数据冗余。


	1.相关概念
		统一数仓层建设过程以 维度建模 为理论基础，构建总线矩阵，划分业务板块，定义数据域、业务过程、维度、原子指标、修饰类型、修饰词、
	时间周期、派生指标，进而确定维度表、事实表的模型设计。
		1.业务板块
			根据业务的属性划分出的相对独立的业务板块，业务板块是一种大的划分，各业务板块中的业务重叠度低，数据独立建设，比如地产板块、
		金融板块、医疗板块等。

		2.模型设计
			以建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实，同时设计出一套表命名规范。

		3.数据域
			数据域是统一数仓层的顶层设计，是一个较高层次的数据归类标准，是对企业业务过程进行抽象、提炼、组合的集合，面向业务分析，
		一个数据域对应一个宏观分析领域，比如采购域、供应链域、HR域等。数据域是抽象的、提炼出来的，并且不能轻易改动，既能覆盖当前
		所有业务需求，又能在新业务进入时无影响的将其分配到已有的数据域中，只有当所有分类都不合适时才会扩展新的数据域。数据域是
		有效归纳、组织业务过程的方式，同时方便定位指标/度量。

		4.业务过程
			业务过程是一种企业的业务活动事件，且是企业经营过程中不可拆分的行为事件，比如下单、银行转账、账号注册都是业务过程。业务
		过程产生度量，并且会被转化为最终的事实表中的事实。业务过程一般与事实表一一对应，也有一对多或者多对一的特殊情况，比如累计快照
		事实表就会把多个业务过程产生的事实在一张表中表达。

		5.修饰词
			修饰词指除统计维度意外的对指标进行限定抽象的业务场景词语，修饰词隶属于一个修饰类型。比如，在日志域的访问终端下，有修饰词
		pc、无线端。修饰类型的出现是为了方便管理、使用修饰词。

		6.原子指标
			原子指标是针对某一业务事件行为的度量，是一种不可拆分的指标，具有明确业务含义，比如支付金额。原子指标有确定的字段名称、
		数据类型、算法说明、所属数据域和业务过程。原子指标名称一般采用"动作+度量"方式命名，比如支付金额、注册用户数。

		7.派生指标
			派生指标可以理解为对原子指标业务统计范围的圈定，比如最近1天北京买家支付金额("最近1天"是时间周期，"北京"是修饰词，修饰词
		"买家"是维度)。派生指标=1个原子指标+多个修饰词+时间修饰词。

		8.计算方法
			指标的数学计算方式，比如汇总、平均、最大、最小等。

		9.维度表
			维度是观察事物的角度，提供某一业务过程事件所涉及的用于过滤及分类事实的描述性属性，用于描述与"谁，什么，哪里，何时，为什么，
		如何"(5W1H)有关的事件。比如"早上小王在小卖部花费5元购买了一个面包"，以购买为业务过程进行分析，可从这段信息中提取3个维度，
		即时间维度(早上)、地点维度(小卖部)和商品维度(面包)。维度表是统一设计的，在整个数据仓库中共享，所有数据域、业务过程都需要用到
		维度，都可以在公共维度表中获取相关维度属性。

		10.事实表
			事实是观察事务得到的事实数据，事实涉及来自业务过程事件的度量，基本都是以数量值表示，比如一次购买行为就可以理解为一个事实，
		5元就是事实信息。在确定数据域与业务过程后，就可以根据业务过程涉及的维度、度量及粒度，设计相关的事实表。事实表不涉及数据域，根据
		需要，一个事实表可能对应同数据域下一个或者多个业务过程。事实表又分为事实明细表和汇总事实表。事实明细表记录事务层面的事实，保存
		的是原子数据，数据的粒度通常是每个事务一条记录，明细事实表数据被插入，数据就不再进行更改，其更新方式为增量。汇总事实表就是把
		明细事实表聚合形成的事实表，包括以具有规律性的、可预见的时间间隔来记录事实的周期快照事实表和以不确定的周期来记录事实的累计快照
		事实表。

		11.粒度
			粒度是指统一数仓层数据的细化或综合程度，对各事实表行实际代表的内容给出明确的说明，用于确定某一事实表中的行代表什么。确定
		维度或者事实之前必须声明粒度，因为每个维度和事实都必须与定义的粒度保持一致。原子粒度是最低级别的粒度，是对业务过程最详细的刻画，
		原子粒度事实必须保留。

		12.一致性指标定义
			指标归属到具体数据域，定义指标的含义、命名、类型、计算方法，确定指标的全局一致性。


	2.数据域划分
		数据域是指面向业务或数据进行本质分析，归纳总结出的数据集合。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不
	轻易变动。在划分数据域时，既能覆盖当前所有业务需求，又能在新业务进入时无影响的将其插进已有的数据域中或者扩展新的数据域。具体数据域划分
	过程如下：
		第一阶段：数据调研
			a)业务调研
				确定项目要覆盖的业务领域和业务线，以及各个业务线可以细分为哪几个业务模块，各个业务模块具体的业务流程是怎样的，通过跟
			业务专家访谈或进行资料文档收集，梳理主要业务流程、业务边界、专业术语等。

			b)数据调研
				调研全部数据目录信息，梳理数据流与业务过程关联关系。

		第二阶段：业务分类
			a)业务过程提取
				根据调研结果抽取出全部业务过程。

			b)业务过程拆分
				将组合型的业务过程拆分成一个个不可分割的行为事件，如下单、支付、收货、退款。

			c)业务过程分类
				按照业务分类规则，将相似特征的业务过程分为一类，且每一个业务过程只能唯一归属于一类。

		第三阶段：数据域定义
			a)业务分类确认
				对业务分类结果再次确认，避免分类范围中出现业务特征明显与其他业务过程无关的情况。

			b)数据域定义
				根据业务分类的规律总结出划分业务范围的标准定义。

			c)数据域命名
				为每个业务域起一个专属名称，并附上英文全称和简称。

		第四阶段：总线矩阵构建
			a)关系梳理
				明确每个数据域下有哪些业务过程，并梳理出业务过程与哪些维度有关。
			
			b)矩阵构建
				定义一张二维矩阵，将数据域下的业务过程与维度信息如实记录下来。


	3.指标设计
		指标就是在企业业务运转过程中产生的度量事实，一致性指标设计是为了在企业内外部使指标的命名、计算方法、业务理解达成一致，避免不同
	部门同一个指标的数据对不上或者对同一个指标的数据理解不一致。	

		一致性指标的定义为，描述原子性指标、修饰词、时间周期和派生指标的含义、类型、命名、算法，被用于模型设计，是建模的基础。

		一致性指标设计是事实表模型设计的来源，有了一致性的指标定义，在设计事实表模型时引用定义好的一致性指标，可达到指标的一致性与标志性。


	4.维度表设计
		维度是维度建模的基础和灵活，维度表设计的好坏直接决定了维度建模的好坏。维度表包含了事实表所记录的业务过程度量的上下文和环境，它除了
	记录5W等信息外，通常还包括了很多描述性字段。每个维度表都包含单一的主键列。维度设计的核心是确定维度属性，维度属性是查询约束条件(SQL 
	where 条件)、分组(SQL group 语句)与报表标签生成的基本来源。维度表通常有多列或者说多个属性。维度表通常比较宽，是扁平型非规范表，
	包含大量细粒度的文本属性。实际应用中，包含几十甚至上百个属性的维度并不少见。维度表