从page137往下.
数据体系建设：
所谓数据体系建设，数据采用的体系结构，数据的建设方法。
7.1 数据体系规划
本节介绍了：数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，在全域原始数据的基础上，进行标准定义及分层建模。避免部门中间数据命名不一、口径不一的问题。
中台数据体系应该具备以下特征：
覆盖全域数据：数据集中建设，覆盖所有业务过程数据，业务在中台数据体系中总能找到需要的数据。
结构层次清晰：纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解。
所谓纵向分层：
https://xie.infoq.cn/article/116ecd94861a531fae61c3452
纵向分层的目的是：1. 搭建一个其他的专门用于分析的数据库，解决性能损失问题 2.将散落在各个应用系统的数据，在该专门用于分析的数据库里再存储一份 ，比如上面链接介绍了几个层：ODS 贴源层->DWD 明细层-> DWS 轻聚合层->DW/ADS 层 。有一个专门的分析数据层，可以方便各个业务直接从这个分析数据层调取数据。
所谓主题域：
https://www.sohu.com/a/477641946_114819
主题域的目的是：让各个业务部门，或者不同的数据分析的角色可以基于自己的使用需求来构建一个主题域并使用资源。比如：对于一个erp系统而言，“销售分析”就是一个分析领域，这个“销售分析”所涉及到的分析对象有商品、供应商、顾客、仓库等，那么数仓主题就确定为商品主题、供应商主题、顾客主题、仓库主题，“销售分析”就可以作为一个主题域；
如果“产品分析”是一个分析领域，“产品分析”所涉及到的分析对象为商品、地域、时间、类别等，那么数仓的主题可以确定为商品主题、地域主题、时间主题、类别主题，“产品分析”可以作为一个主题域。
上面的链接：主题域划分个人比较推荐按照业务系统划分或者bu部门来划分主题域（一级主题），这样的话边界较为清晰，数据仓库开发过程也不会因为模型主题的归属引发扯皮和不同意见，然后根据各个系统中的业务过程抽象整合出主题（叫二级主题域也可以）
数据准确一致：定义一致性指标，统一命名，统一业务含义，统一计算口径，并有专业团队负责建模，保证数据的准确一致。
性能提升：统一的规划设计，选用合理的数据模型，清晰地定义并统一规范，并且考虑使用场景，使整体性能更好。
降低成本：数据体系的建设使得数据能被业务共享，这避免了大量烟囱式的重复建设，节约了计算、存储和人力成本。
方便易用：易用的总体原则是越往后越能方便地直接使用数据，把一些复杂的处理尽可能前置，必要时做适当的冗余处理。比如在数据的使用中，可以通过维度冗余和事实冗余来提前进行相关处理，以避免使用时才计算，通过公共计算下沉、明细与汇总共存等为业务提供灵活性。统一数据体系的建设让整个企业的业务都有机会使用数据。
------
摘自知乎：
https://zhuanlan.zhihu.com/p/137454121
数仓的建模方式：维度建模
2、维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo，而且相对来说便于理解、提高查询性能、对称并易扩展。
维度建模：
用于度量的事实表，事实表一般会有两个或者多个外键与维度表的主键进行关联。事实表的主键一般是组合健，表达多对多的关系。
用于描述环境的维度表，单一主键。维度表的属性是所有查询约束和报表标示的来源。维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组。
所以维度建模表示每个业务过程包含的事实表，事实表里面存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生的实际存在的文本环境。
从图表中能看出来，维度模型（星型模型）比较简单，而且适于变化，各个维度的地位相同。可根据业务情况进行新增或者修改（只要维度的单一值已经存在事实表中）。
目前常见的维度模型：
星型模型
每一个维表都与都与事实表相关联。数据冗余量较大
雪花模型
有些维表可能不与事实表直接关联，而是通过其他维表关联到事实表。数据冗余量较小
星座模型
由多个事实表相组合，维表是公共的。企业中一般都是星座模型
-------------------------------
为了使数据体系在建设时具备以上特征，需要一个体系化的数据层次架构，这个层次架构定义了数据分层及每一层的模型建设规范。数据体系架构是一套指导规范，实施过程中应严格按照架构执行。下面以某地产公司为例，来分析适合绝大多数企业的数据中台数据体系架构。
上图设计了以下四个数据分层：
贴源数据层ODS（Operational Data Store）,又称操作数据层：对个业务系统数据进行采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。
统一数仓层DW(Data Warehouse）：又细分为明细数据层DWD（dataware house Detail）和汇总数据层DWS（Data Warehouse summary），与传统数据仓库功能基本一致,对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的，而统一数仓层从业务易理解的视角来重新组织，定义一致的指标、维度，各业务版块、业务域按照统一规范独立建设，从而形成统一规范的标准业务数据体系。
标签数据层TDM（Tag Data Model）：面向对象建模，对跨业务版块、跨数据域的特定对象数据进行整合，通过ID-Mapping 把各个业务板块、各个业务过程中的同一对象的数据打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。
应用数据层ADS（Application Data store）：按照业务的需要从统一数仓层、标签数据层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用组装应用数据。
另外，建设过程中数据的读取也有严格的规范要求。按照规范，贴源数据层直接从业务系统或日志系统中获取数据。贴源数据层的数据只被统一数仓层使用，统一数仓层数据只被标签层和应用层使用。贴源层、统一数仓层只保存历史数据以及被标签层、应用层引用，不直接支撑业务，所有业务使用的数据均来源于标签层和应用层。
由于贴源数据层仅做业务数据的同步与存储，应用数据层面向特定业务组装数据，这两层没有太多的建模规范，故只做简单介绍。下面将重点介绍统一数仓层与标签层的建设，尤其是标签数据层，因为它是更能体现大数据能力的一层。
---------------------------
这张图感觉蛮形象的，也转过来。
自：
https://zhuanlan.zhihu.com/p/137454121
1、ODS原始层是存放原始数据，主要是埋点数据（日志数据）和业务操作数据（binlong），数据源主要是Mysql、HDFS、Kafka等
2、DW中间层主要存放ETL和主题汇总之后的中间层数据，这块又分为：
DWD：事实表（data warehouse detail） 数据仓库明细表，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。
DWS：事实表 （data warehouse summary） 数据仓库轻度汇总层，按照各个业务域进行轻度汇总成分析某一个主题域的服务数据，一般是宽表。
DIM：维度表，公共维度层，基于维度建模理念思想，建立整个业务过程的一致性维度，主要使用 MySQL、Hbase、Redis 三种存储引擎，对于维表数据比较少的情况可以使用 MySQL，对于单条数据大小比较小，查询 QPS 比较高的情况，可以使用 Redis 存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用HBase 存储。
3、DM数据集市层，以数据域+业务域的理念建设公共汇总层，对于DM层比较复杂，需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式，分为轻度汇总层和高度汇总层。
轻度汇总层以宽表的形式存在，主要是针对业务域进行快速方便的查询；
高度汇总层由明细数据层或轻度汇总层通过聚合计算后写入到存储引擎中，产出一部分实时数据指标需求，灵活性比较差，主要做大屏展现。
4、理论上上面还一APP层，应用层，主要是通过这几层之后，生成轻度或者高度汇总的数据，然后根据业务域进行接口封装提供给上层使用。
看到page 140页。
明天从7.2 开始看。
