5.业务架构·应用架构·数据架构实战 --- 业务驱动的数据架构设计

第5章 业务驱动的数据架构设计 
5.1 什么是数据架构（DA） 
	数据架构是通过对企业战略得到的数据资产管理蓝图。具体而言，该蓝图用于指导如何分析数据需求，如何做好相应设计。

	数据架构描述企业的：1)主要数据类型及其来源；2)逻辑数据资产；3)物理数据资产；4)数据管理资产；5)上述所有内容的结构和交互

	综上可见：
		1.数据架构的终极目标，是支撑战略
		2.数据架构的具体内容包括数据需求，数据设计，数据管理这三大块
		3.其中数据设计的内容，远远超过了数据模型设计，一般包括数据模型设计，数据存储设计，数据流设计

	数据架构的设计内容可以总结为五大方面：	
		1.数据类型及来源
		2.数据模型
		3.数据存储
		4.数据流
		5.数据管理

5.2 数据架构在全球的快速发展 
	【技术】从OLTP，到BI，到BigData
		数据库=文件+存取引擎+编程API

	【管理】从"数据架构"到"企业数据管理"

5.3 解读TOGAF的数据架构方法 
	【1】DA设计内容
	在TOGAF中，列举了如下目标数据架构设计内容：
		1.定义业务数据模型
		2.定义逻辑数据模型
		3.确定数据满足业务
		4.定义数据交换格式
		5.规定数据管理过程
		6.编写相关架构文档

	【2】DA设计步骤
		1.确定设计哪些视点
		2.开发基线数据架构
		3.开发目标数据架构
		4.进行差距分析
		5.识别能力增量
		6.架构影响评估
		7.干系人评审
		8.敲定数据架构
		9.创建架构文档

	TOGAF推荐的数据架构设计过程如下：	
		1.分析业务与应用需求
		2.定义合理的数据需求
		3.数据模型设计
		4.数据生命周期，数据流，数据接口，数据存储设计

5.4 实践攻略：数据架构的实际工作内容 
	【落地】实际的数据架构内容模型
	数据战略：
		1.需求
			数据类型及其来源(生产库，历史库，BI库，主数据，参考数据)
			(文本，日志，邮件，图片，声音，视频，IM，帖子，网页，位置，传感器)
			(元数据)
		2.设计
			逻辑模型(数据模型，数据生命周期)
			物理存储及其分布(数据存储，数据分布)
			数据流(数据流，数据沿袭，数据交换格式)
		3.管理
			数据管理(数据标准，数据质量，数据安全)

	【要点】数据需求=需要管理哪些数据类型
		需求规定做什么，设计规定怎么做。

		数据架构整个规划和设计过程，最重要的一点就是要做什么，即做好数据需求的分析。
			1.根据不同领域的业务需求，要识别生产库，历史库，BI库对应的数据类型。
			2.要做跨部门跨业务的分析，识别主数据对应的数据类型。
			3.大数据风潮已来，每个企业都在探索大数据的深度应用场景。这就需要识别类型广泛的非结构化数据和半结构化数据。

	【要点】静态设计=逻辑数据模型+物理存储与分布
		数据架构的静态设计方面，总的来说包括4点：
			1.数据模型设计
			2.数据生命周期设计
			3.数据存储策略设计
			4.数据分布策略设计

		逻辑数据模型，一般采用ER图设计。它和具体的物理数据模型独立，可以映射成不同的物理结构。

		在设计数据模型的同时设计数据生命周期。

	【要点】动态设计=数据流+数据沿袭+数据接口
		数据架构的动态设计包含3点：
			1.数据流 --- 定义数据传递与使用路径
			2.数据沿袭 --- BI 领域多见数据的抽取，转换，装载，清洗，脱敏，而数据沿袭用于明确数据和数据源头之间的追踪关系
			3.数据接口 --- 定义数据交换格式

	【要点】数据管理=数据标准+数据质量+数据安全
		数据管理包括：
			1.数据标准
				是指保证数据定义和使用的 一致性，准确性和完整性的规范性约束。例如，对企业数据的分类标准；数据的命名，数据类型，长度，
			业务含义，计算口径，归属部门等统一规范；数据质量标准。
				在数据标准中，规定数据的类型或数据域的划分最为常见。

			2.数据质量
				数据质量是围绕数据标准展开的检查，分析，提升工作，一个企业如果没有数据标准，它可怎么管理数据质量呢。

			3.数据安全
				数据安全包括 数据安全标准与策略，数据安全管理规范，数据安全审计规范等。其中<<数据安全标准>>可以认为是<<数据标准>>
			的子集，包含横跨技术维，系统维，管理维等数据安全规定。

5.5 实践攻略：业务驱动的数据架构设计步骤 
	【落地】设计步骤
		业务驱动，落地的数据架构设计过程：
			1.上接业务
				分析数据需求，识别数据类型。
			2.静态设计
				设计数据模型，定义生命周期。
				规划数据存储，设计数据分布。
			3.动态设计
				数据流，数据沿袭，数据交换格式设计。
			4.数据管理
				根据需要，定义数据标准，数据质量，数据安全等规程。

	【揭秘】业务驱动的数据建模
		数据模型是数据架构的核心。

		数据建模是业务驱动的。业务是果，数据是因，业务驱动就是以果导因。

		不同粒度的业务定义能驱动不同粒度的数据建模：
			1.业务主题，业务域【巨粒度】 --- 发现数据域
			2.业务流程【粗粒度】 --- 发现数据实体，属性，关系
			3.功能、特性【中粒度】 --- 细化数据实体，属性，关系
			4.业务规则【细粒度】 --- 细化数据实体，属性，关系

5.6 实践案例：电商系统——业务驱动的数据建模串讲 
	【1】巨粒度 --- 业务主题驱动的数据建模
		UC 矩阵可以作为发现数据域，识别数据类型的主力工具 --- 为数据建模"打头炮"。它的纵横两维：
			1.每行 --- 代表一个巨粒度的业务主题或者业务功能域
			2.每列 --- 代表一个巨粒度的数据域

		C 代表创建(Create)，U 代表使用(Use)。

	【2】粗粒度 --- 业务流程驱动的数据建模
		业务域包含一组业务功能，而每个业务功能都由业务流程来实现和支撑。此时，就该让业务流程驱动数据实体，属性，关系的发现了。

		业务流程驱动的数据建模能否成功，依赖于"完整的主干流程+穷举了分支流程"这个条件是否满足。

	【3】中粒度 --- 功能特性驱动的数据建模
		功能特性更细粒度一些。或者说，业务流程说到底还是围绕业务，而功能特性却是"业务能力+系统能力"无所不包。所以，功能特性提供了更多
	的信息量。
		功能特性驱动的数据建模，用于推动数据实体，属性，关系模型的优化。

	【4】细粒度 --- 业务规则驱动的数据建模
		数据建模还没结束，因为还有数不胜数的业务规则需要支持，有的业务规则需要特定的数据模型的支持才能实现。所以，接下来架构师要做的，
	就是明确业务规则，并逐条确认数据模型是否支持它。
		相反，数据建模若是缺乏了业务规则驱动这一环，结果只能是模型不完整，模型质量差，研发后期不断"擦屁股"，改模型，改程序。

5.7 实践案例：数字化服务转型——分析数据需求，识别数据类型 
	【推进】数据架构设计的起跑线
		数据架构设计是业务驱动的，数据架构师的第一步工作是分析数据需求，识别数据类型。全面识别数据类型，具体做法有二：
			1.认真的做法 --- 用UC矩阵，细细梳理每个业务功能产生什么数据，消费什么数据。
			2.粗犷的做法 --- 直接将业务功能域借过来当做数据域，分析每个数据域需要的数据类型。

	【推进】识别结构化数据类型
	【推进】识别非结构化数据类型

5.8 实践案例：数字化服务转型——设计数据模型，定义生命周期 
	【推进】设计票源库数据模型
		1.功能分析
		2.设计构想
		3.设计模型
		4.设计思想

	【推进】评价模型的优缺点

	【推进】设计生命周期，解决问题

5.9 实践案例：数字化服务转型——抢到票后死机，怎么处理 
	抢到票后，后台立即生成订单。支持用户换终端完成支付。

5.10 实践案例：数字化服务转型——规划数据存储，设计数据分布 
	先将生产数据与历史数据分离，再将结构化数据与非结构化数据分离，将音频等文件单独保存，在接线记录数据库表里保存其地址。

5.11 实践案例：数字化服务转型——数据流、数据沿袭、数据交换格式设计