数据中台第7章数据体系建设：数仓分层设计、数据建模、数 据标准
数据中台数据体系是在全域原始数据的基础上，进⾏标准定义及分层建模，数据体系建设最终呈现的结果是⼀套完整、规范、准确的数据体系，可以⽅便⽀撑数据应⽤。
中台数据体系应具备以下特征：
·覆盖全域数据：数据集中建设，覆盖所有业务过程数据，业务在中台数据体系中总能到需要的数据。 ·结构层次清晰：纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解。
·数据准确⼀致：定义⼀致性指标，统⼀命名、统⼀业务含义、统⼀计算⼝径，并有专业团队负责建模，保证数据的准确⼀致。
·降低成本，共享复⽤：数据体系的建设使得数据能被业务共享，这避免了⼤量烟囱式的重复建设，节约了计算、存储和⼈⼒成本。
·
⽅便易⽤：易⽤的总体原则是越往后越能⽅便地直接使⽤数据，把⼀些复杂的处理尽可能前置，必要时做适当的冗余处理。⽐如在数据的使⽤中，可以通过维度冗余和事实冗余来提前进⾏相关处理，以避免使⽤时才计算，通过公共计算下沉、明细与汇总共存等为业务提供灵活性。统⼀数据体系的建设让整个企业的业务都有机会使⽤数据。 ·性能提升：统⼀的规划设计，选⽤合理的数据模型，清晰地定义并统⼀规范，并且考虑使⽤场景，使整体性能更好。
为了使数据体系在建设时具备以上特征，需要⼀个体系化的数据层次架构，这个层次架构定义了数据分层及每⼀层的模型建设规范。数据体系架构是⼀套指导规范，实施过程中应严格按照架构执⾏。下⾯以某地产公司为例，来分析适合绝⼤多数企业的数据中台数据体系架构
贴源数据层ODS（Operational Data Store，⼜称操作数据层）：对各业务系统数据进⾏采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持⼀致，仅做简单整合、⾮结构化数据结构化处理或者增加标识数据⽇期描述信息，不做深度清洗加⼯。
·统⼀数仓层DW（Data Warehouse）：⼜细分为明细数据层DWD（DataWarehouse Detail）和汇总数据层DWS（Data
Warehouse Summary），与传统数据仓库功能基本⼀致，对全历史业务过程数据进⾏建模存储。对来源于业务系统的数据进⾏重新组织。业务系统是按照业务流程⽅便操作的⽅式来组织数据的，⽽统⼀数仓层从业务易理解的视⾓来重新组织，定义⼀致的指标、维度，各业务板块、业务域按照统⼀规范独⽴建设，从⽽形成统⼀规范的标准业务数据体系。
·标签数据层TDM（Tag Data Model）：⾯向对象建模，对跨业务板块、跨数据域的特定对象数据进⾏整合，通过ID-Mapping把各个业务板块、各个业务过程中的同⼀对象的数据打通，形成对象的全域标签体系，⽅便深度分析、挖掘、应⽤。
·应⽤数据层ADS（Application Data Store）：按照业务的需要从统⼀数仓层、标签数据层抽取数据，并⾯向业务的特殊需要加⼯业务特定数据，以满⾜业务及性能需求，向特定应⽤组装应⽤数据。
7.2 贴源数据层建设ODS——全域数据统⼀存储
针织牛仔布贴源数据层会对企业各业务系统数据进⾏汇聚整合，保留企业全量业务原始数据，并作为统⼀数仓层建设的数据源。贴源数据层数据不仅是业务数据库中产⽣的数据，跟企业相关的所有数据都应该汇聚到贴源数据层，包括业务系统数据、业务运⾏的⽇志数据、机器运转产⽣的⽇志数据、⽹络爬⾍或者其他⽅式获取的外部数据
按照数据结构类型的不同，贴源数据可以分为三类：
·结构化数据：主要是关系型数据库中的数据，直接从业务系统DB抽取到贴源数据层。
·半结构化数据：⼀般是纯⽂本数据，以各种⽇志数据为主，半结构化数据保留贴源数据的同时也做结构化处理，为后续使⽤做准备。
常见如JSON、XML等形式表达的复杂结构。
·⾮结构化数据：主要是图⽚、⾳频、视频，⼀般保留在⽂件系统中，由于这类数据量⼀般⽐较庞⼤，⽽且没有太多挖掘分析价值，所以贴源数据层不保留原始⽂件，只保留对原始数据⽂件的描述，⽐如地址、名称、类型、分辨率等。
7.2.2 贴源数据表设计
贴源数据层中的数据表与对应的业务系统数据表原则上保持⼀致，数据结构上⼏乎不做修改，所以参考业务系统数据表结构来设计贴源数据层表结构即可，结构设计上没有太多的规范要求。考虑到业务系统数据的多样性，贴源数据层数据表的设计要遵循⼀定的规范。
贴源数据层数据表设计规范如下：
微冻技术·贴源数据层表的命名采⽤前缀+业务系统表名的⽅式。⽐如，ODS_系统简称_业务系统表名，这样既可以最⼤限度保持与业务系统命名⼀致，⼜可以有清晰的层次，还可以区分来源。
·贴源数据层表的字段名与业务系统字段名保持⼀致，在ODS层不做字段命名归⼀。字段类型也尽可能保持⼀致，如果数据中台没有与业务系统对应的数据类型则⽤⼀个可以兼容的数据类型。⽐如，业务系统的数据类型是float，数据中台的存储系统没有float类型，则可以⽤double代替。
·对于⼀些数据量较⼤的业务数据表，如果采⽤增量同步的⽅式，则要同时建⽴增量表和全量表，增量表利⽤后缀标识。⽐如，ODS_系统简称_业务系统表名_delta，汇聚到增量表的数据通过数据加⼯任务合并⽣成全量表数据。
·对于⽇志、⽂件等半结构化数据，不仅要存储原始数据，为了⽅便后续的使⽤还要对数据做结构化处理，并存储结构化之后的数据。原始数据可以按⾏存储在⽂本类型的⼤字段中，然后再通过解析任务把数据解析到结构化数据表中。
通过以上建设规范，可保障企业所有业务数据按照⼀致的存储⽅式存储到数据中台
7.3 统⼀数仓层建设DW——标准化的数据底座
统⼀数仓层站在业务的视⾓，不考虑业务系统流程，从业务完整性的⾓度重新组织数据。统⼀数仓层的⽬标是建设⼀套覆盖全域、全历史的企业数据体系，利⽤这套数据体系可以还原企业任意时刻的业务运转状态。只要能达到这个⽬标，利⽤范式建模、维度建模、实体建模中任意⼀种建模⽅法都是可以的，这⾥主要介绍维度建模，因为它更适合⼤数据时代数据量巨⼤的特点。
7.3.2 数据域划分、划分主题域
第⼀阶段：调研。
·业务调研：确定项⽬要涵盖的业务领域和业务线，以及各个业务线可以细分成哪⼏个业务模块各业务模块具体的业务流程是怎样的，通过跟业务专家访谈或进⾏资料⽂档收集，梳理主要业务流程、业务边界、专业术语等。
·数据调研：调研全部数据⽬录信息，梳理数据流与业务过程关联关系。
第⼆阶段：业务分类。·业务过程提取：根据调研结果抽取出全部业务过程。
·业务过程拆分：将组合型的业务过程拆分成⼀个个不可分割的⾏为事件，如下单、⽀付、收货、退款。
·业务过程分类：按照业务分类规则，将相似特征的业务过程分为⼀类，且每⼀个业务过程只能唯⼀归属于⼀类。
第三阶段：数据域定义。
·业务分类确认：对业务分类结果再次确认，避免分类范围中出现业务特征明显与其他业务过程⽆关的情况。
·数据域定义：根据业务分类的规律总结出划分业务范围的标准定义。
·数据域命名：为每个数据域起⼀个专属名称，并附上英⽂全称和简称。
第四阶段：总线矩阵构建 。
·关系梳理：明确每个数据域下有哪些业务过程，并梳理出业务过程与哪些维度相关。
·矩阵构建：定义⼀张⼆维矩阵，将数据域下的业务过程与维度信息如实记录下来。
7.3.3 指标设计
指标就是在企业业务运转过程中产⽣的度量事实，⼀致性指标设计是为了在企业内外部使指标的命名、计算⽅法、业务理解达到⼀致，避免不同部门同⼀个指标的数据对不上或者对同⼀个指标的数据理解不⼀致。⼀致性指标的定义为，描述原⼦指标、修饰词、时间周期和派⽣指标的含义、类型、命名、算法，被⽤于模型设计，是建模的基础。派⽣指标的⽣成过程如图7-5所⽰。
7.3.4 维度建模
维度建模具备以下特点：
模型简单易理解：仅有维度、事实两种类型数据，站在业务的⾓度组织数据。
·性能好：维度建模使⽤的是可预测的标准框架，允许数据库系统和最终⽤户通过查询⼯具在数据⽅⾯⽣成强⼤的假设条件，这些数据主要在表现和性能⽅⾯起作⽤。
·可扩展性好：具有⾮常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。可以在不改变模型粒度的情况下，很⽅便地增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变⽽重新编码。良好的可扩展性意味着以前的所有应⽤都可以继续运⾏，并不会产⽣不同的结果。
·数据冗余：由于在构建事实表星型模式之前需要进⾏⼤量的数据预处理，因此会导致⼤量的数据处理⼯作。⽽且，当业务发⽣变化，需要重新进⾏维度的定义时，往往需要重新进⾏维度数据的预处理。⽽在这些预处理过程中，往往会导致⼤量的数据冗余。
7.3.4 维度表设计
维度是维度建模的基础和灵魂，维度表设计得好坏直接决定了维度建模的好坏。维度表包含了事实表
所记录的业务过程度量的上下⽂和环境，它们除了记录5W等信息外，通常还包含了很多描述属性字段。每个维度表都包含单⼀的主键列。维度设计的核⼼是确定维度属性，维度属性是查询约束条件（SQL where条件）、分组（SQL group语句）与报表标签⽣成的基本来源。维度表通常有多列或者说多个属性。维度表通常⽐较宽，是扁平型⾮规范表，包含⼤量细粒度的⽂本属性。实际应⽤中，包含⼏⼗甚⾄上百个属性的维度并不少见。维度表应该尽可能包括⼀些有意义的⽂字性描述，以⽅便下游⽤户使⽤。维度属性尽可能丰富。维度属性设计中会有⼀些反规范化设计，把相关维度的属性也合并到主维度属性中，达到易⽤、少关联的效果。维度表设计主要包括选择维度、确定主维表、梳理关联维表、定义维度属性等过程。
1. 选择维度：维度既可以从报表需求中分析获取，也可以从与业务⼈员的交谈中
发现。
2. 确定主维表： 主维表⼀般直接从业务系统同步⽽来，是分析事实时所需环境描述的最基础、最频繁的维度属性集合。
3. 梳理关联维表： 根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表⽤于⽣成维度属性
斜导柱4. 定义维度属性：过程中尽量⽣成更丰富、更通⽤的维度属性
7.3.5 事实表设计
事实表是统⼀数仓层建设的主要产出物，统⼀数仓层绝⼤部分表都是事实表。⼀般来说事实表由两部分组成：⼀部分是由主键和外键组成的键值部分，另⼀部分是⽤来描述业务过程的事实度量。事实表的键值部分确定了事实表的粒度，事实表通过粒度和事实度量来描述业务过程。事实表的外键总是对应某个维度表的主键，实际建设和试⽤过程中，为了提升事实表的易⽤性和性能，不仅会存储维度主键，还会把关键的维度属性存储在实施表中。这样事实表就包含表达粒度的键值部分、事实度量及退化的维度属性。⼀切数据应⽤和分析都是围绕事实表来展开的，稳定的数据模型能⼤幅提⾼数据复⽤性。
在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表。
·事务事实表：事务事实表描述业务过程事务层⾯的事实，每条记录代表⼀个事务事件，保留事务事件活动的原始内容。事务事实表中的数据在事务事件发⽣后记录，⼀般记录后数据就不再进⾏更改，其更新⽅式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务⾏为进⾏详细分析。
·周期快照事实表：周期快照事实表以具有规律性、可预见的时间间隔产⽣快照来记录事实，每⾏代表
某个时间周期的⼀条记录，记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容⼀般在所表达的时间周期结束后才会产⽣，⼀般记录后数据就不再更改，其更新⽅式为增量更新。周期快照事实表⼀般是建⽴在事务事实表之上的聚集，维度⽐事务事实表少，粒度⽐事务事实表粗，但是由于对事实进⾏了多种形式的加⼯从⽽产⽣了新的事实，故⼀般事实会⽐事务事实表多。
·累计快照事实表：累积快照事实表覆盖⼀个事务从开始到结束之间所有的关键事件，覆盖事务的整个⽣命周期，通常具有多个⽇期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意⼀个的产⽣都要做记录，由于周期快照事实表涉及的多个事件的⾸次加载和后续更新时间是不确定的，因此在⾸次加载后允许对记录进⾏更新，⼀般采⽤全量刷新的⽅式更新。累计快照事实表⼀般⽤于追踪某个业务的全⽣命周期及状态转换，⽐如交易业务，涉及下单、⽀付、发货、确认收货，这些相关事件在不同的事务事实表中，通过事务事实表很难看到不同事件之间的转化及状态变化，通过累计快照事实表可把相关事件串起来放在⼀条记录中，这样很容易解决了。
节能炉子不管哪种类型的事实表，设计⽅法都类似，事实表设计可以遵循以下步骤：
第⼀步：确定业务过程。
企业业务是由⼀个个业务过程组成的，事实表就是为了记录这些业务过程产⽣的事实，以便还原任意时刻的业务运转状态。所以设计事实表，第⼀步就是确定实施所要表达的是哪⼀个或者⼏个业务过程。
笔者理解业务过程是企业活动事件，⽐如注册、登录、下单、投诉等都是业务过程，最基本的是每⼀个业务过程对应⼀张事实表，这样最容易理解。但是实际开发过程中，业务过程和事实表会存在多对多的关系。
第⼆步：定义粒度。
牙刷加工不管事实表对应⼀个还是多个业务过程，粒度必须是确定的，每个事实表都有且只能有唯⼀的粒度，粒度是事实表的每⼀⾏所表⽰的业务含义，是事实的细节级别。在实际设计过程中，粒度与主键等价，粒度更偏向业务，⽽主键是站在技术⾓度说的。虽然粒度在最终的事实表中很难被体现，但是定义粒度是必不可少的步骤，这样可避免整个事实表的业务含义模糊。
第三步：确定维度。
定义粒度之后，事实表每⼀⾏的业务含义就确定了。那么业务⼈员会站在哪些⾓度来描述事实度量？这就要确定维度了，常见的维度有时间、区域、客户、产品、员⼯等。维度依附于粒度，是粒度的环境描述。
第四步：确定事实。
事实就是事实表度量的内容，也就是业务过程产⽣的事实度量的计算结果，⽐如注册量、登录次数、
交易⾦额、退款量等。事实表的所有事实度量都与事实表所表达的业务过程相关，所有事实必须满⾜第⼆步所定义的粒度。
第五步：冗余维度属性。
事实表的设计要综合考虑数据来源和使⽤需求，在满⾜业务事实记录的同时也要满⾜使⽤的便利性和性能要求。⼤数据时代，事实表记录数动辄亿级，甚⾄数⼗亿、数百亿，维表也有可能达到亿级甚⾄更多。利⽤标准维度模型会经常出现维表与事实表关联的情况，这种对亿级表的关联计算，在性能上是灾难性的。为了满⾜业务需求，降低资源消耗，建议适当冗余维度属性数据到事实表，直接利⽤事实表就可以完成绝⼤部分业务的使⽤需求，这样下游使⽤时可减少⼤表关联，提升效率。所以⼤数据时代，适当进⾏维度冗余是可取的。
注意：维度属性冗余与模型的稳定性是有⽭盾的，因为维度的属性是有可能改变的，如果属性已经冗余到事实表中，那么维度属性就与事实⼀起被记录到事实表中。如果后续维度属性值改变，由于事实表已经⽣成，事实表的内容基本不会再做改变，这样就会出现已记录的维度属性与真实的维度属性不⼀致，导致数据错误的情况。属性的冗余是⼀种优化建议，冗余带来的收益与弊端要综合考虑。
7.3.6 模型落地实现
经过以上数据域的划分、指标的定义、维表设计、事实表设计，就完成了整个统⼀数仓层的设计⼯作。接下来要在数据开发平台结合数据平台⼯具，进⾏统⼀数仓层的物理层⾯的建设。模型结构与内容已经确定，仅仅需要代码和运维层⾯的实施。
落地实施的具体步骤如下：
1）按照命名规范创建表，包括维表和事实表；
2）开发⽣成维表和事实表的数据的逻辑代码；
3）进⾏代码逻辑测试，验证数据加⼯逻辑的正确性；
4）代码发布，加⼊⽣产调度，并配置相应的质量监控和报警机制；
5）持续任务运维监控。
7.4 标签数据层建设TDM——数据价值魅⼒所在
标签数据层是⾯向对象建模，把⼀个对象各种标识打通归⼀，把跨业务板块、数据域的对象数据在同⼀个粒度基础上组织起来打到对象上。标签数据层建设，⼀⽅⾯让数据变得可阅读、易理解，⽅便业
务使⽤；另⼀⽅⾯通过标签类⽬体系将标签组织排布，以⼀种适⽤性更好的组织⽅式来匹配未来变化的业务场景需求。
7.4.2 确定对象
进⾏标签建设，⾸先要清楚对哪类对象建设标签，也就是确定对象。对象是客观世界中研究⽬标的抽象，有实体的对象，也有虚拟的对象。在企业经营过程中可以抽象出⾮常多的对象，这些对象在不同业务场景下交叉产⽣联系，是企业的重要资产，需要全⾯刻画了解
明确了对象的定义和分类，就可以根据业务的需要确定要对哪些对象建⽴标签体系。企业的对象⾮常多，不会对所有对象都建⽴标签体系，⼀般都是选择典型的对象建⽴标签体系，⽐如客户、员⼯、产品、设备等。⼀种对象标签体系的建设并不会影响另⼀种对象标签体系的建设，可以根据资源和业务紧急度，合理安排标签体系建设的前后关系。
7.4.3 对象ID打通
四头精雕机在确认对象后，由于存在同⼀个对象在多个不同业务中的标识ID不同的情况，因此需要将同⼀个具体对象的不同ID标识打通，以便所有业务数据都能在该对象上打通，完成对该对象的全⾯数据的刻画。⽐如⼀个⾃然⼈，他本⾝由⾝份证进⾏唯⼀识别，但是他看病时⽤的是医保账号进⾏挂号缴费；缴纳⽔电煤费⽤时，⼜有不同的⽔表账号、电表账号、天然⽓账号；购买了⼿机⼜有⼿机的设备账号；上⽹购物会有电商账号，上⽹聊天会有聊天应⽤账号……通过不同账号，⼜记录了各⾃账号下的⼤量⾏为记录，如果需要对⼀个对象进⾏全⾯的数据收集、完整刻画、辨别真伪，就需要将多⽅数据进⾏融合打通。要完成对象的ID打通，⼀般会给每个对象设置⼀个超级ID，⽐如SUPER-ID作为唯⼀识别该对象的标识码，业务系统中不同的对象标识ID都通过⼀定的算法规则与这个SUPER-ID打通，进⽽完成对象所有业务标识ID的打通。
