云原生数据中台（让数据用起来|数据中台第7章数据体系建设:数仓分层设计、数据建模、数据标准） data|安全架构|云计算|big

数据中台数据体系是在全域原始数据的基础上，进行标准定义及分层建模，数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，可以方便支撑数据应用。
中台数据体系应具备以下特征：

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

为了使数据体系在建设时具备以上特征，需要一个体系化的数据层次架构，这个层次架构定义了数据分层及每一层的模型建设规范。数据体系架构是一套指导规范，实施过程中应严格按照架构执行。下面以某地产公司为例，来分析适合绝大多数企业的数据中台数据体系架构

云原生数据中台（让数据用起来|数据中台第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语句）与报表标签生成的基本来源。维度表通常有多列或者说多个属性。维度表通常比较宽，是扁平型非规范表，包含大量细粒度的文本属性。实际应用中，包含几十甚至上百个属性的维度并不少见。维度表应该尽可能包括一些有意义的文字性描述，以方便下游用户使用。维度属性尽可能丰富。维度属性设计中会有一些反规范化设计，把相关维度的属性也合并到主维度属性中，达到易用、少关联的效果。维度表设计主要包括选择维度、确定主维表、梳理关联维表、定义维度属性等过程。

选择维度：维度既可以从报表需求中分析获取，也可以从与业务人员的交谈中
发现。
确定主维表：主维表一般直接从业务系统同步而来，是分析事实时所需环境描述的最基础、最频繁的维度属性集合。
梳理关联维表：根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性
定义维度属性：过程中尽量生成更丰富、更通用的维度属性

7.3.5　事实表设计
【云原生数据中台（让数据用起来|数据中台第7章数据体系建设:数仓分层设计、数据建模、数据标准）】事实表是统一数仓层建设的主要产出物，统一数仓层绝大部分表都是事实表。一般来说事实表由两部分组成：一部分是由主键和外键组成的键值部分，另一部分是用来描述业务过程的事实度量。事实表的键值部分确定了事实表的粒度，事实表通过粒度和事实度量来描述业务过程。事实表的外键总是对应某个维度表的主键，实际建设和试用过程中，为了提升事实表的易用性和性能，不仅会存储维度主键，还会把关键的维度属性存储在实施表中。这样事实表就包含表达粒度的键值部分、事实度量及退化的维度属性。一切数据应用和分析都是围绕事实表来展开的，稳定的数据模型能大幅提高数据复用性。
在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的打通。
ID打通，首先必须有ID-ID之间的两两映射打通关系，通过ID-ID之间两两映射关系表，将多种ID之间的关联打通。比如手机号、身份证号码可以打通，手机号、邮箱账号可以打通，这样通过手机号就可以把身份证号码和邮箱账号也打通了。完全孤立的ID是无法进行打通的。通过ID-ID间的两两映射，打通整个ID关系，看似简单，实则计算复杂，计算量非常大。想象一下，假如某种对象有数亿个个体，每个个体又有数十种不同的ID标识，任意两种ID之间都可能有打通关系，想要完成这类对象的所有个体ID打通需要数亿亿次的计算，一般的机器甚至大数据集群都无法完成。大数据领域中的ID-Mapping技术就是用机器学习算法来取代野蛮计算，解决对象数据打通的问题。基于输入的ID关系对，利用机器学习算法做稳定性和收敛性计算，输出关系稳定的ID关系对，并生成一个SUPER-ID作为唯一识别该对象的标识码。另外要说明的是，通过算法打通对象的不同ID标识，两两ID之间的打通关系有一定的误差，通过置信度来描述这个误差，置信度越高则误差越小，反之则越大。不同业务根据业务自身的需要，选择不同的置信度，比如要做财务统计，就要100%置信度才行，但是如果是做营销推广，可能80%的置信度就可以了。一般来说，ID打通是标签体系建设的前提，没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面标签化刻画
7.4.4　标签类目设计
企业业务需要使用的标签项一般都会非常之多，当标签项超过50个时，业务人员要使用或查找标签就开始变得麻烦，管理标签也会变得困难。因此笔者借鉴了图书管理学中的经典方法：海量图书需要有专门的图书分类体系对书本进行编号并按照编号分柜排放，阅读者在查阅图书时只需要按编号索引即可快速找到自己所需图书，图书管理员也可以方便、有效地理清所有图书状况。笔者也通过建立对象标签类目体系来对对象的标签进行分类管理。

文章图片

文章图片

7.4.5　标签设计
通过标签类目设计，已经有了某类对象的标签体系框架，只是还没有具体的标签内容。标签设计就是设计合适的标签并将其挂载到标签类目。前面介绍标签按照产生和计算方式的不同可以分为属性标签、统计标签、算法标签，每一类标签深挖下去，都可以有无数个。

文章图片

7.5 应用数据层建设ADS——灵活支撑业务需求统一数仓层和标签数据层数据相对稳定，然而最终用户的需求和使用方式是千变万化的，统一数仓层和标签数据层无法灵活适应各类用户的使用需求。另外最终用户使用数据也需要灵活性和高性能，而这与规范是矛盾的，因为按规范进行建设就会把数据按照各种域、业务过程、维度、粒度等拆分，使用的时候需要各种连接，这样就无法满足对灵活、高性能的要求。为了解决规范稳定与灵活、高性能之间的矛盾，要增加应用数据层。
7.5.2　应用数据表设计
应用数据层是在统一数仓层、标签数据层都已经建设好的基础上，面向特定业务需求而准备的个性数据组装层，除了特殊的业务个性标签需要单独加工外，其他尽可能复用统一数仓层和标签数据层的建设成果。应用数据层的建设是强业务驱动的，业务部门需要参与到应用数据层的建设中来。推荐的工作方式是，业务部门的业务专家把业务需求告知数据部门的数据工程师，然后在建模过程中深入沟通，这样最终形成的应用数据层的表设计才能既满足业务需求又符合整体的规范。
因此应用数据层的特点就是考虑使用场景，其有以下几种结构：

1）应用场景是多维的即席分析，一般为了减少连接、提升性能，会采用大宽表的形式组织。
2）如果是特定指标的查询，可以采用K-V表形式组织，涉及此类表的时候需要深入了解具体的查询场景，例如是否有模糊查询，以便于选择最适合的数据结构。
3）有些场景下一次要查询多种信息，也可能会用复杂数据结构组织。

7.5.3　应用数据表实现
应用数据层建设步骤如下：
1）调研业务应用对数据内容、使用方式、性能的要求，需要明确业务应用需要哪些数据，数据是怎么交互的，对于请求的响应速度和吞吐量等有什么期望。这个时候需要参与沟通的可能不仅仅是业务部门的业务专家，业务系统的研发人员也需要参与讨论。
2）盘点现有统一数仓层、标签数据层数据是否满足业务数据需求，如果满足则直接跳到第3步；如果有个性化指标需求，统一数仓层、标签数据层数据无法满足，则进行个性化数据加工。
3）组装应用层数据。组装考虑性能和使用方式，比如应用层是多维的自由聚合分析，那就把统一数仓层、标签数据层以及个性化加工的指标组装成大宽表；如果是特定指标的查询，可以考虑组装成K-V结构数据。