数仓模型也就是数据模型（Data Model）是数据特征的抽象，它从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架。数据模型所描述的内容有三部分，分别是数据结构、数据操作和数据约束。本题涉及的建模即Hive数据仓房体系中数据模型的构建，大家要区别其他的模型构建。其他的模型构建还有：算法建模、业务流程建模等，这些描述的又是其他方面的内容。模型可更形象、直观地揭示事物的本质特征，使人们对事物有一个更加全面、深入的认识，从而可以帮助人们更好地解决问题。利用模型对事物进行描述是人们在认识和改造世界过程中广泛采用的一种方法。计算机不能直接处理现实世界中的客观事物，而数据库系统正是使用计算机技术对客观事物进行管理，因此就需要对客观事物进行抽象、模拟，以建立适合于数据库系统进行管理的数据模型。数据模型是对现实世界数据特征的模拟和抽象。数据模型按不同的应用层次分成三种类型：分别是概念数据模型、逻辑数据模型、物理数据模型。概念数据模型概念数据模型（Conceptual Data Model），是一种面向用户、面向客观世界的模型，主要用来描述世界的概念化结构，它是数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的数据管理系统（Database Management System，简称DBMS）无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。在概念数据模型中最常用的是E-R模型、扩充的E-R模型、面向对象模型及谓词模型 。逻辑数据模型逻辑数据模型（Logical Data Model），是一种面向数据库系统的模型，是具体的DBMS所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系统，主要用于数据库管理系统（DBMS）的实现。物理数据模型物理数据模型（Physical Data Model），是一种面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构。数仓建模在学习数仓前需要知道，当今的数据处理系统，主要分两大类：OLAP与OLTP。OLAP（On-Line Analytical Processing）：联机分析处理OLTP (On-Line Transaction Processing):联机事务处理联机分析处理是数据仓库的主要应用，主要是支持企业的决策需要提供数据支持。联机事务处理系统侧重系统的日常操作，例如用户交易、用户账户注册、注销等。对于事务型需求场景来说,一般采用三范式规则构建数据模型，而对于分析型的场景多采用维度模型或宽表模型，但也不是绝对的，需要具体问题具体分析。接下来我们先去认识一下这几个模型：三范式模型关系：数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。所以在数据库中，通过表间的关系作为现实中的实体关系的映射。通过表间的关系，也是构造出数据模型的基础，这样才能表达出丰富的业务关系。关系数据模型从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模 ;但是建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性以及性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此这种建模方式适用于数据规模相对较小，数据表也比较少的场景，并且技术架构采用关系型数据库实现的数据仓库。维度模型按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式、雪花模型等。- 优点：对于维度建模，针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。- 缺点：由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。这种建模方式适用于基于Hive构建的数据仓库平台上。宽表模型宽表模型又称单例模型，宽表是指一种大表，是将事实表和维度表进行合并形成的表。比如日期维度，将对应的日期维度的列，直接添加到事实表中，或者商品维度的列也同步加入到事实表中。那么这样事实表的列就非常的多，它所涉及到的维度基本都涵盖在了一张表中，俗称All in one。对于这样的表，就称为宽表。基于宽表，我们可以针对这一个表完成许多业务指标的开发。- 优点：在数据仓库建设中，组织相关和相似数据，采用明细宽表，减少数据扫描，提高明细数据表的易用性，以及查询性能。--数据冗余，由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，对存储是个挑战。--灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大。--开发流程变长，我们需要去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘。从规范化的角度来讲，数据仓库的设计者是希望越规范越好，因为这样会减少数据的冗余，而且也便于模型的扩展。从反规范化的角度来讲，数据仓库的使用者是希望使用越方便越好，他们并不太关心规范不规范冗余不冗余，只要用着方便就好。这种情况在工作中是十分常见的，那么该怎样来解决它？下面有两个思路：- 两种方式都存。虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。
- 只存多个维度表，通过视图来创建宽表。这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。
鉴于以上的一些考量，在数仓底层可以使用星型模型，而宽表则可以存在于更靠后的层次。数据仓库的分层原因有以下几点：- 把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单任务，方便定位问题。
- 减少重复开发：规范数据分层，通过中间层数据，能够减少大量的重复计算，增加一次计算结果的复用性。
- 隔离原始数据：不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。
数据仓库分层设计不同的公司对数仓的层级考量不完全一致，不过业界比较通用的有这么几个层级：ODS层操作数据存储层又称贴源层，数据与原始数据的形态一致，用于存储各个系统经ETL同步过来的原始数据（crm、系统日志等）。在ETL的过程中会对数据进行清洗处理，比如去除或更正数据中的错误值、异常值，客户年龄登记为1000岁等各种失误造成的错误数据。处理数据中存在的缺失数据：统一缺失的样式，在文本文件中可能是\N NULL 或者 / - 等表现形式，在进行ETL的时候将格式统一，也可以去分析一些缺失的原因，并对缺失数据进行补救性的恢复工作。DW层这是数据仓库的核心层，在这一层会对原始数据进行更进一步的加工处理。具体的又可以划分为这么几个层次：- 数据明细层DWD：明细层的数据粒度与ods层一致，只是做了更进一步的清洗和规范化操作。还可能将一些维度退化到事实表，从而进一步提高后续应用的便利性。
- 数据汇总层DWS：根据数据明细层做一些汇总操作，生成中间结果，减少后续应用的重复加工、重复计算。根据分析主题对数据进行进一步的整合，一般来说是宽表。也可使用维度模型，可参考宽表与维度模型的差异，视情况采用不同策略。
ADS层数据应用层（或数据集市层），为报表、用户画像等数据应用提供数据支撑（数据通过CDM层经过进一步加工而来），一般会将ADS层的数据同步到关系型数据库，并将同步ADS数据后的关系型数据库也视为数据集市层。后续用户一般是基于同步到关系型数据库中的数据做分析及应用的。了解更多数据分析知识、与更多优秀的人一起进群交流请扫码
|
