1. 简述数据仓库架构 ？
数据仓库的核心功能从源系统抽取数据，通过清洗、转换、标准化，将数据加载到BI平台，进而满足业 务用户的数据分析和决策支持。
数据仓库架构包含三个部分：数据架构、应用程序架构、底层设施
1）底层设施
底层设施为架构提供了基础，底层设施包括硬件、数据库平台、网络和桌面系统。
（1）硬件
硬件主要指服务器硬件，主要有数据库服务器、ETL服务器、调度服务器、报表服务器、BI门户服务 器、接口服务器。
（2）数据库平台
数据库平台分为二大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing），主要有Oracel，MySQL。OLAP是为数据分析而设计的数据库管理系统。主要有Teradata, Greenplum，Hive，Kudu。
（3）桌面系统
数据仓库不同的应用对桌面系统也有不同的要求，开发工具主要有Window、Mac面系统，部署服务器主 要有Unix桌面系统，系统BI应用程序主要有Window、Mac、移动设备桌面系统。
（4）网络
网络是底层设施的基础，特别是大数据时代对网络的要求越来越高。
2）BI应用程序架构
数据仓库是数据处理的后台，业务用户并不关心后台怎么处理。BI应用是数据呈现的前台，是业务用户 进行查询的入口。BI应用程序的体验也是衡量数据仓库是否成功的主要因素。
（1） BI分析周期
业务分析从监视活动开始识别某个问题或时机，进而采取行动，最终回到监视该活动产生的结果上来， 达到数据驱动业务增长的目的。分析周期把这个过程分为五个不同的阶段。
（2） BI应用分类接口查询
数据以接口的形式提供给上下游系统，供上下业务系统进行查询。主要有推和拉二种模式。
即席查询
业务用户根据自己的需求，自定义查询请求，后台自动组织SQL语句访问维度模型。 标准报表
根据业务用户的需求，进行定制报表。仪表盘
它是向企业展示度量信息和关键业务指标现状的数据可视化工具。数据挖掘
为数据挖掘工具提供标准基础数据。运营查询
为了减少业务系统的大数据量查询压力，数据仓库为业务系统提供实时的查询。
（3）数据存储
为了提高查询性能，BI工具需要把数据存储在本地服务器上
OLAP多维模型需要把数据存储成Cube格式把数据存储成文件格式，放在其他服务器上
3）数据结构
数据架构主要描述数据从源系统抽取数据，然后经过清洗、规范化、提交形成标准模型，最终提交给业 务用户，以及对数据的管理。
（1）源系统
数据仓库一般会面临多个、异构数据源的问题，主要分为结构化，半结构化以及非结构化数据。为了便 于管理需要对源系统建立元数据信息。
（2）抽取
因为源系统的多样性，源抽取阶段一般选择使用工具。在抽取之前还要做以下工作：
数据剖析是对数据的技术性分析，对数据的内容、一致性和结构进行描述。对源系统的数据质量进行评 估。
数据剖析
变化数据捕获策略
为了减少对源系统的影响，一般只抽取变化的数据，也需要识别物理删除的数据。CDC策略主要有： 添加审计列
在源系统追加日期字段，当数据发生变化的时候，系统会自动更新该值。如果由后台人员手工修改 数据，可能就发生遗漏。
数据比较
比较源系统和数据仓库的数据，只抽取变化的数据。这种方法需要全量的数据，比较耗费资源。可 以视数据量的大小而定。
读取日志
读取数据库操作日志信息，同步到数据仓库中。一般日志的有效期比较短，一旦发生要重跑的情 况，可能以前的日志已经被清空了。
消息队列
把事务信息放到消息队列里，以流的形式同步到数据仓库。这种方式即可以减轻源系统的压力，又 能做到实时同步。
（3）数据转换
数据从源系统抽取过来之后，就要进入数据转换阶段。 这一阶段是数据仓库开发核心阶段。主要有以下步骤：
清洗
数据清洗是制定转换规则，筛选数据并纠正数据的过程。清洗的目的是改进源系统的数据质量，但是不 要在数据仓库做过多的清洗，源系统的数据质量应该在源头处理。清洗的主要内容包括：
制定数据转换规则提交错误事实表
规范化
规范化就是整合各个源系统的数据，把数据统一命名，统一取值，建立企业标准版本数据。主要内容包 括：
数据标准化删除重复数据数据共存策略
（4）提交
提交就要根据维度模型生成维度表和事实表。 提交主要内容包括： 选择合适的缓慢变化维类型
为维表生成代理键
管理不同粒度的层次维管理专项维
生成维度桥接表生成代理键管道
选择合适的事实表类型处理延迟到达的事实
生成维度表生成事实表
（5）聚集
聚集是指根据事务事实表进行更高粒度的聚合以及生成相对应的维度表。主要内容包括： 数据聚合
缩小维度表
生成OLAP多维数据集
（6）数据存储
数据存储是指在在数据的生命周期内对数据的管理，主要内容包括： 数据备份
历史数据归档
ETL过程中数据分层存储
2. 简述数仓架构设计的方法和原则 ？
1）数据设计方法
数据仓库建立之前，就必须考虑其实现方法，通常有自顶向下、自底向上和两者结合进行的这样三种实 现方案。
（1）自顶向下实现
自顶向下的实现需要在项目开始时完成更多计划和设计工作，这就需要涉及参与数据仓库实现的每个工 作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据 模型的有关决策一般需要在真正的实现开始之前就完成。
（2）自底向上实现
自底向上的实现包含数据仓库的规划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意 味着不会开发更大业务范围的数据仓库设计；随着初始数据仓库实现的扩展，将逐渐增加对它的构建。 现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩 展更大业务范围实现的证明。
（3）两者结合的折中实现
每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定 业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。 在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接 一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好 地适用于业务。在这种方法中，可以把数据集市理解为整个数据仓库系统的逻辑子集，换句话说数据仓 库就是一致化了的数据集市的集合。
2）数仓架构争论
关于Inmon 和 Kimball的大辩论：Ralph Kimball 和 Bill Inmon 一直是商业智能领域中的革新者，开发并测试了新的技术和体系结构。在BI/DW领域中，围绕"哪一种数据仓库架构（Data Warehouse
Architecture）最佳？"的争论一直没有休止，这个问题同时也是企业在建立DW时需要决策的关键问题： Bill Inmon的集线器架构/企业信息工厂架构（Hub and Spoke / CIF -- Corporate Information Factory）与Ralph Kimball的数据集市/数据仓库总线架构（Data Mart Bus Architecture/Data Warehouse Bus
Architecture）则是DW架构的争论焦点。
Bill Inmon 将数据仓库定义为"一个面向主题的、集成的、非易变的、随时间变化的用于支持管理的决策过程的数据集合"；他通过"面向主题"表示应该围绕主题来组织数据仓库中的数据，例如客户、销售、产 品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题，并且当需要容易 地访问多个主题时，应该创建以数据仓库为来源的数据集市。换言之，某个特定数据集市中的所有数据 都应该来自于面向主题的数据存储。 Inmon 的方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资 源和工作
3）数仓架构选型
数据仓库架构的选取，与其所处的企业环境和业务的发展有着密切的关系：Inmon提倡的数据仓库建设 方法，需要数据仓库建设人员自顶向下进行建设，数据仓库开发人员需要在数据仓库建设之前对企业各 业务线进行深入的调研，有着非常全面的了解，然后根据企业各业务特点进行主题域划分。这种建设方 式建设周期比较长，规划设计比较复杂，但是一旦建成，这个集中式的体系结构将提供更强的一致性和 灵活性，并且从长远来看将真正节省资源和工作；Kimball提倡的数据仓库仅仅是构成它的数据集市的联 合，各部门或业务可以根据自身的发展，建设符合自身主题的数据集市，并持续丰富完善这些数据集 市。在应对企业级数据需求时，将这些数据集市的维度信息进行统一整理规范，然后通过一致的维度信 息，将这些数据集市连接起来，使数据集市形成一个覆盖企业所有部门或业务的数据仓库，对外提供服务。
根据企业发展阶段和业务发展的速度建议：传统的、业务成熟的企业可以考虑采用Inmon方法建设数据 仓库；业务复杂而且差异较大、发展速度又非常快的企业可以考虑Kimball方法建设数据仓库。
4）企业发展中的数据仓库建设变迁
企业或新部门，在初期发展过程中业务量少、组织形式相对简单。使得数仓建设人员可以站在全局的高 度，俯视整个公司的业务流程，对其进行梳理归类，并抽取数据模型。以自上而下的方式建设数据仓 库。所以在初期数据仓库建设的过程中基本采用了Inmon提倡的数据仓库建设方法，采用了DataSource--
ODS→EDW→DM-->APP的结构。即由ODS层完成各部门数据源的集成，在ODS的基础上建设了覆盖公司 所有业务的包含众多主题的统一的数据仓库，然后由这个统一的数据仓库作为唯一的数据源，为各部门 的数据集市提供数据支持
但是一旦企业或部门发展速度非常快，业务量急剧增大，而且业务的组织形式趋于复杂，不同的业务之 间可能存在巨大的差距。数据仓库的建设如果再继续沿用自伤而下的方式就会带来很多困难，例如在
Inmon模式下EDW规划复杂、建设周期长，不能非常快速的响应各部门的需求，所以该方案逐步不能适 应公司的发展。为了适应企业的发展，经过数仓开发人员的不断探索尝试，基本上倾向于采用混合模式 建设数据仓库，即采用Inmon+Kimball的变种模式
3. 简述数据仓库分层（层级划分），每层做什么？分层的好处 ？
首先，我要知道数据仓库分层架构的目标是什么？是为了实现维度建模，进而支撑决策分析目标。
数据分层从关系型在线交易系统到面向主题的数据仓库系统，从范式建模到维度建模的必经之路。
数据分层是一套让我们的数据体系更有序的行之有效的数据组织和管理方法。数据分层不是银弹，也没 有绝对标准，当然也不能包治百病，不能解决所有的数据问题，但是，数据分层却可以给我们带来如下 的好处：
隔离原始数据：不论是数据的异常还是数据敏感度，使真实数据与统计数据解耦开。
数据结构化更清晰：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。
数据血缘追踪：提供给外界使用的是一张业务表，但是这张业务表可能来源很多张表。如果有一张来源 表出问题了，我们可以快速准确的定位到问题，并清楚每张表的作用范围。
增强数据复用能力：减少重复开发，通过数据分层规范化，开发一些通用的中间层数据，能够减少重复 计算，提高单张业务表的使用率，提升系统的执行效率。
简化复杂的问题：把一个复杂的业务分成多个步骤实现，每一层只处理单一的步骤，比较简单和容易理 解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的 步骤开始修复。
减少业务的影响：业务可能会经常变化，这样做就不必改一次业务就需要重新接入数据。 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径。
分层的核心思想就是解耦，再解耦，把复杂的问题简单化。
一个公司可能有多个业务系统，而数据仓库就是将所有的业务系统按照某种组织架构整合 起来，形成一个仓储平台，也就是数仓。
1、四层分层
第一层：
ODS------原始数据层：存放原始数据
ODS层即操作数据存储，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也 就说传说中的ETL之后，装入本层；一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化 后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类， 一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需 要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚 至全量保存；数据在装入本层前需要做以下工作：去噪、去重、提脏、业务提取、单位统一、砍字段、 业务判别。
第二层：
DWD------数据明细层：对ODS层数据进行清洗、维度退化、脱敏等。覆盖所有系统的、完整的、干净的、具有一致性的数据层。
该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证，在ODS的基础上对数据进行加 工处理，提供更干净的数据。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，当 一个维度没有数据仓库需要的任何数据时，就可以退化维度，将维度退化至事实表中，减少事实表和维 表的关联。例如：订单id,这种量级很大的维度，没必要用一张维度表来进行存储，而我们一般在进行数 据分析时订单id又非常重要，所以我们将订单id冗余在事实表中，这种维度就是退化维度。
第三层：
DWS------数据服务层： 对DWD层数据进行一个轻度的汇总。
DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，会针对度量值进行汇总，目的是避免重 复计算。该层数据表会相对比较少，大多都是宽表(一张表会涵盖比较多的业务内容，表中的字段较
多)。按照主题划分，如订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分 析，数据分发等。
第四层：
DM------数据集市层：为各种统计报表提供数据。
存放的是轻度聚合的数据，也可以称为数据应用层，基于DWD、DWS上的基础数据，整合汇总成分析某 一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据，通常根据业务需求，划分成流 量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。从数 据粒度来说，这层的数据是汇总级的数据，也包括部分明细数据。从数据的时间跨度来说，通常是DW 层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几 年的即可。从数据的广度来说，仍然覆盖了所有业务数据。
2、三层分层
上述四层数仓，如果是问的三层数仓，就相当于是把DWD、DWS合并成DW层，往细的方面分，DW还包括DWM层（数据中间层），三层分层如下：
第一层：
ODS------原始数据层：存放原始数据第二层：
DW------数据仓库层：数据清洗，初步汇总
本层将从 ODS 层中获得的数据按照主题建立各种数据模型，每一个主题对应一个宏观的分析领域，数据仓库层排除对决策无用的数据，提供特定主题的简明视图。在DW层会保存BI系统中所有的历史数据， 例如保存10年的数据。
第三层：
DM------数据集市层
3、五层分层
五层分层如下：
第一层：
ODS------原始数据层：存放原始数据第二层：
DWD------数据明细层：对ODS层数据进行清洗、维度退化、脱敏等。第三层：
DWS------数据汇总层： 对DWD层数据进行一个轻度的汇总。第四层：
ADS------数据应用层：为各种统计报表提供数据
该层是基于DW层的数据，整合汇总成主题域的服务数据，用于提供后续的业务查询等。第五层：
DIM------维表层：基于维度建模理念思想，建立整个企业的一致性维度。维表层主要包含两部分数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或 者几千几万。
4. 简述数据分层是根据什么 ？
数据分层没有标准，数据分层要结合当下的技术，当前的数据量，业务的复杂度通盘考量。操作型数据 存储（ODS）、数据仓库（DW）、数据集市（DM）其实就是数据分层的原始的指导建议，其中操作型 数据存储是满足多个业务系统获取数据并制作操作型报表的需求，保留半年以内的明细准实时数据；数 据仓库是为了管理决策、战略分析和计划提供单一整合点，保留长期的明细和汇总数据；数据集市是用 于特定部门或公共分析需求并定制的，采用维度建模方式保留中期的明细和汇总数据
5. 简述数仓分层的原则与思路 ？
数据仓库分层没有绝对的规范，适合的就是最好的，至于分几层，建议按照目前的业务和建设现状，进 行合理解构和分层设计，一般刚开始做，建议3、4层。规划1-1.5年的架构，然后不断的建设、优化、再 优化。不断逼近满足所有需求。
下面针对一些场景说下分层的想法： 场景一：时间紧任务重，急于看结果
这种场景，直接连各个业务数据库，抽取数据到大数据平台，根据需求组合join或者汇总count、sum就 行，就不要分层了，有的公司项目就是将各个业务系统数据抽取到oracle，你看都没有大数据平台就做 了。
场景二：公司业务简单，且相对比较固定，数据来源不多，结构也很清晰，需求也不多
直接使用通用的数仓架构就行，ODS起到解耦业务数据库+异构数据源的问题，DWD解决数据脏乱差的 问题，DWS服用的指标计算，ADS直接面向前台业务需求。
场景三：公司业务复杂，业务变化较快
可以考虑多一层DWT层做汇总，多一层解耦，业务变化的时候，我们只改DWS层就好了，最多穿透到
DWT层。业务变化的时候调整一下，工作量也不会太大，最重要的是能保证底层结构的稳定和数据分析 的可持续性。
场景四：公司业务较为复杂，集团性公司，下辖多个部门业务部门事业线，业务部门间业务内容交叉不 大
可以在数仓通用分层架构上，增加一层DM层，也就是数据集市层，各个数据集市层，单独供数，甚至 有单独的计算资源，这样可以避免因为计算任务代码混在一起、数据权限拆分等问题带来的数据变更成 本。
一个好的数仓模型分层，应该具备的要素
一个好的数仓模型分层，应该具备的要素是数据模型可复用，完善且规范的。
完善度：
DWD： 跨 层 引 用 率 DWS/ADS/DM：汇总数据查询比例
复用度：
DWD/DWS：模型引用系数
规范度：
有多少表没有主题域、业务过程归属模型命名不规范
字段命名不规范
好的数仓设计标准：数据比较丰富完善、数据复用性强、规范性强。
从完善度上来讲，主要衡量DWD层和汇总层两块的完善度，DWD层完善度，主要是希望DWD等尽可能被汇总层引用，ODS层被除了DWD层外的尽可能少的引用，最好是没有。
从复用度上来讲，我们希望80%需求由20%的表来支持。直接点讲，就是大部分（80%以上）的需求， 都用DWS的表来支持。
从规范度上来讲，主要从表名、字段名来看，一个规范的表名应该包括层级、主题域、分区规则，抽取 类型等信息。字段规范应该是和词根一致，同字段同名等。
数据仓库分层没有绝对的规范，适合的就是最好的，数据仓库分层的核心逻辑是解耦，在有限时间、资 源等条件下满足业务需求，同时又要兼顾业务的快速变化。所以我们作为数据架构师，需要兼顾业务的 复杂变化，以及开发的复杂度和可维护性，在两者之间做一个平衡和取舍，选择合适的分层架构。
另外分层架构是需要不断的优化调整的，不能超前太多，也不能脱离业务。按照Inmon和Kimball吵了十 几年的经验上看，建议架构设计时，按超越当前实际情况1~1.5年的设计是比较合适的。
6. 数仓建模常用模型吗？区别、优缺点？
数据仓库建模的目标是通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之 间找到最佳平衡点。
现在数据处理大致可以分为两大类：
操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作 的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主 要手段，主要用于操作型处理。
分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing），一般针对某些主题的历史数据进行分析，支持管理决策。
OLTP与OLAP的主要异同如下表：
操作型处理 分析型处理
细节的 综合的或提炼的
实体-关系（ER）模型 星型或雪花模型
存取瞬间数据 存储历史数据，不包含最近的数据
可更新的 只读，只追加
一次操作一个单元 一次操作一个集合
性能要求高，响应时间短 性能要求宽松
面向事务 面向分析
一次操作数据量小 一次操作数据量大
支持日常操作 支持决策需求
数据量小 数据量大
客户订单、库存水平和银行账户等 客户收益分析、市场细分等
1、关系（ER实体）建模
严格遵循第三范式，从图中可以看出，较为松散、零碎，物理表数量多，而数据冗 余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要 应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式 的。
这是数据仓库之父Bill Inmon提出的建模方法，即实体关系（Entity Relationship，ER）模型。这是从全企业的高度设计一个3NF模型，用实体关系模型来描述企业业务，在范式理论上符合3NF。
关系模型主要应用于OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是 遵循第三范式的。
特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解 耦，易维护，缺点是开发周期一般比较长，维护成本高。
范式理论：
范式可以理解为设计一张数据表的表结构，符合的标准级别，也就是规范和要求。 优点：关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性。缺点：范式的缺点是获取数据时，需要通过Join拼接出最后的数据。
分类：目前业界范式有第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四 范式(4NF)、第五范式(5NF)。
2、维度建模
维度模型主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业 务，特征是可能存在数据的冗余，但是能方便的得到数据。
关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低 执行效率。所以一般都会采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。
在维度建模的基础上又可分为三种模型：星型模型、雪花模型、星座模型。
维度建模是从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速的完成 需求分析，同事具有较好的大规模复杂查询的相应能力。其典型的代表是星型模型，以及在一些特殊场 景下使用的雪花模型。
维度建模设计分为以下步骤：
选择需要进行分析决策的业务过程定义粒度
识别维度确认事实
1）星型模型
星型模式是维度模型中最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式 由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度 表。
星型模型与雪花模型的区别主要在于维度的层级，标准的星型模型维度只有一层，而雪花模型可能会涉 及多层。
2）雪花模型
雪花模式是一种多维模型中表的逻辑布局，与星型模式相同，雪花模式也是由事实表和维度表所组成。 所谓的"雪花化"就是将星型模型中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了 以事实表为中心的雪花型结构，即雪花模式。
3）星座模型
数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享（例如两张事实表共用一些维 度表时，就叫做星型模型），这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模 式。
4）模型选择
在数据仓库建模时，会涉及到模式的选择，我们要根据不同模式的特点选择适合具体业务的模式。 星型还是雪花，取决于性能优先，还是灵活更优先。
在实际开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但 是整体看来，更倾向于维度更少的星型模型。
3、建模方法总结
ER模型以及维度模型是当前主流的建模方法。
ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统 的数据按相似性、一致性合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。
ER模型的特点如下：
需要全面梳理企业所有的业务和数据流； 实施周期长；
对建模人员要求高。
维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同 时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模 型。
不需要完整的梳理企业业务流程和数据；
实施周期根据主题边界而定，容易快速实现 demo。
7. 简述星型模型和雪花模型的区别？应用场景 ？
随着大数据时代的到来，数据仓库的技术和模型也越来越受到关注。在数据仓库中，星型模型和雪花模型是两种常用的数据建模方式。这两种模型在结构上存在一定的差异，同时也具有各自的优缺点。下面我们来详细了解一下这两种模型的区别以及优缺点。
一、星型模型
星型模型是一种基于事实表的模型，它的特点是将事实表与其他维度表相连，形成一个放射形结构。在星型模型中，所有的维度表都与事实表相连，因此它的查询效率比较高，易于理解和维护。
星型模型的优点主要有以下几个方面：
查询效率高。由于星型模型的结构比较简单，因此在查询时可以快速定位到需要的数据。
易于理解和维护。星型模型的结构比较清晰，易于理解和维护，能够大大降低维护成本。
可扩展性好。星型模型的结构比较松散，因此在扩展时比较灵活。
维度分析能力强。星型模型适合进行维度分析，能够快速地进行数据分析和数据挖掘。
二、雪花模型
雪花模型是一种基于事实表的模型，它的特点是将维度表之间的关系变得更加复杂。在雪花模型中，维度表之间存在多对多的关系，因此它的结构比较复杂，查询效率比较低。
雪花模型的优点主要有以下几个方面：
容纳更多维度。由于雪花模型的结构比较复杂，因此可以容纳更多的维度，使得数据分析更加全面。
避免冗余数据。雪花模型中的维度表之间存在多对多的关系，因此可以避免数据的冗余。
减少计算量。由于雪花模型的结构比较复杂，因此在查询时需要进行更多的计算，但是这样可以减少数据的冗余，从而减少计算量。
三、数据仓库的星型模型和雪花模型的区别以及优缺点对比
下面我们来对比一下数据仓库的星型模型和雪花模型的区别以及优缺点：
结构方面：星型模型的结构比较简单，呈放射形；雪花模型的结构比较复杂，呈雪花状。
查询效率方面：星型模型的查询效率比较高，而雪花模型的查询效率比较低。
数据冗余方面：星型模型的数据冗余比较少，而雪花模型的数据冗余比较多。
可扩展性方面：星型模型的可扩展性比较好，而雪花模型的可扩展性比较差。
综上所述，数据仓库的星型模型和雪花模型各有优缺点。在实际应用中，应根据具体的应用场景和需求来选择合适的建模方式，以达到最优的效果。
8. 简述数仓建模有哪些方式 ？
1、维度建模
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
1）星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
2）雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较 差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuule，性能差距会很 大。
星型模型可以理解为，一个事实表关联多个维度表，雪花模型可以理解为一个事实表关联多个维度表， 维度表再关联维度表。
3）星座模型
数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享（例如两张事实表共用一些维 度表时，就叫做星型模型），这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。
2、范式建模（ER建模）
从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符 合3NF。此建模方法，对建模人员的能力要求非常高。
特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解 耦，易维护，缺点是开发周期一般比较长，维护成本高。
3、Data Vault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan
Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数 据的整合，并非为数据决策分析直接使用。
4、Anchor模型
Anchor模型是对Data Vault模型做了进一步规范化处理，它是一个高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。企业很少使用
9. 简述数仓建模的流程 ？
数据仓库的发展大致经历了这样的三个过程：
简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一 些简单的能够帮助领导进行决策所需要的汇总数据。大部分表现形式为数据库和前端报表工具。
数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务 人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数 据。
数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够 按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务 具有指导性的数据，同时，为领导决策提供全面的数据支持。
通过数据仓库建设的发展阶段，可以看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模 型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：
1）进行全面的业务梳理，改进业务流程
在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。 通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将 业务按照特定的规律进行分门别类和程序化。
同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
2）建立全方位的数据视角，消灭信息孤岛和数据差异
通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的 数据。
而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题。 更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差 异将会得到有效解决。
3）解决业务的变动和数据仓库的灵活性
通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。
当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达 到整个数据仓库系统的灵活性。
4）帮助数据仓库系统本身的建设
通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期 目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
1、建模流程
就是业务模型->概念模型->逻辑模型->物理模型的这样一个流程，下面我们详细解释一下各个模型阶段 都要做什么。
1）业务建模：需求沟通
划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务 部门之间的关系。
深入了解各个业务部门的内具体业务流程并将其程序化。提出修改和改进业务部门工作流程的方法并程序化。
数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的 理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。
2）领域（概念）建模：画图想好怎么做
抽取关键业务概念，并将之抽象化。
将业务概念分组，按照业务主线聚合类似的分组概念。细化分组概念，理清分组概念内的业务流程并抽象化。理清分组概念之间的关联，形成完整的领域概念模型。
领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说 明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据 模型所能达到的一致性和关联性。
3）逻辑建模：表设计
业务概念实体化，并考虑其具体的属性。
事件实体化，也就是所谓的事实，并考虑其属性内容。说明实体化，也就是所谓的维度，并考虑其属性内容。逻辑模型具体要求如下：
总体来说就是建表，前面已经画出了关系图，这里只要将表里头有哪些字段考虑出来就可以，如果是事 实表就考虑事实字段和业务主键，如果是维度表就考虑维度属性，SCD策略等等。在这里需要确定数据 粒度，如果多个指标都用到一个字段，则取粒度最小的指标。如果不确定指标的量度，则取毫秒级作为 粒度。
4）物理建模：建表
针对特定物理化平台，做出相应的技术调整。
针对模型的性能考虑，对特定平台作出相应的调整。针对管理的需要，结合特定的平台，做出相应的调整。生成最后的执行脚本，并完善。
物理模型具体要求如下：
综合现实的大数据平台、采集工具、etl工具、数仓组件、性能要求、管理要求等多方面因素，设计出具 体的项目代码，完成数仓的搭建。
总结来说，上面的模型设计流程大部分应用于DWD层，也就是事实维度层。通过建模，捋清逻辑，把业 务落实到一张张表，并梳理表于表之间的关系。
2、建模过程
假设现在在构建一张订单表
从多个维度进行统计组合，形成多维度数据集，来从多个角度观察业务过程的好坏
1）选择业务过程
确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。因此，建模的第一个步骤是描 述需要建模的业务流程。例如，需要了解和分析一个零售店的销售情况，那么与该零售店销售相关 的所有业务流程都是需要关注的。为了描述业务流程，可以简单地使用纯文本将相关内容记录下 来，或者使用"业务流程建模标注"（BPMN）方法，也可以使用统一建模语言（UML）或其他类似 的方法。
业务过程就是需要那种业务场景下产生的订单表(划分到那个业务线和数据域) 业务过程就是用户下单的订单记录表
2）选择数据域
（1）申明粒度
粒度就是确认一条记录代表的含义或者是细化到何种程度(一条记录代表一个订单还是多个订单， 如拼团的时候团长的单)
在选择维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在一个 事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。
从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为 原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要，但这样的粒度 往往不能满足对细节数据的查询需求。
不同的事实可以有不同的粒度，但同一事实中不要混用多种不同的粒度。维度模型建立完成之后， 还有可能因为获取了新的信息，而回到这步修改粒度级别。
（2）确认维度
维度的粒度必须和第二步所声明的粒度一致。
维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。
典型的维度都是名词，如日期、商店、库存等。维度表存储了某一维度的所有相关数据，例如，日 期维度应该包括年、季度、月、周、日等数据。
（3）确认事实
这一步识别数字化的度量，构成事实表的记录。它是和系统的业务用户密切相关的，因为用户正是 通过对事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的，可累加，可 计算，如成本、数量、金额等。
3、模型设计的思路
业务需求驱动，数据驱动，构造数据仓库有两种方式：一是自上而下，一是自下而上。
1）自上而下
Bill Inmon先生推崇"自上而下"的方式，即一个企业建立唯一的数据中心，就像一个数据的仓库，其中数据是经过整合、经过清洗、去掉脏数据的、标准的，能够提供统一的视图。要建立这样的数据仓库，并 不从它需要支持哪些应用入手，而是要从整个企业的环境入手，分析其中的概念，应该有什么样的数 据，达成整体概念。
2）自下而上
Ralph Kimball先生推崇"自下而上"的方式，他认为建设数据仓库应该按照实际的应用需求，加载需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期较短，客户能够很快看到结果。（针对 客户的需求，需求要什么就做什么）
4、模型落地实现
按照命名规范创建表
开发生成维表和事实表的代码
进行代码逻辑测试，验证数据加工逻辑的正确性
代码发布，加入调度并配置相应的质量监控和报警机制
10. 简述维度建模的步骤，如何确定这些维度的 ？
维度建模主要有4个步骤：选取业务过程、定义粒度、确定维度和确定事实。这4个步骤贯穿了维度建模 的整个过程和环节。
1、选取业务
过程业务过程即企业和组织的业务活动，它们一般都有相应的源头业务系统支持。对于一个超市来说， 其最基本的业务活动就是用户收银台付款；对于一个保险公司来说，最基本的业务活动是理赔和保单 等。当然在实际操作中，业务活动有可能并不是那么简单直接，此时听取用户的意见通常是这一环节最 为高效的方式。
需要注意的是，这里谈到的业务过程并不是指业务部门或者职能。模型设计中，应将注意力集中放在业 务过程而不是业务部门，如果建立的维度模型是同部门捆绑在一起的，就无法避免出现数据不一致的情 况（如业务编码、含义等）。因此，确保数据一致性的最佳办法是从企业和公司全局与整体角度，对于 某一个业务过程建立单一的、一致的维度模型。
2、定义粒度
定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明。粒度传递了事实表度量值相联系的 细节所达到的程度的信息。其实质就是如何描述事实表的单个行。
典型的粒度定义包括：
超市顾客小票的每一个子项； 医院收费单的明细子项；
个人银行账户的每一次存款或者取款行为； 个人银行账户每个月的余额快照。
对于维度设计来说，在事实表粒度上达成一致非常重要，如果没有明确的粒度定义，则不能进入后面的 环节。如果在后面的环节中发现粒度的定义不够或者是错误的，那么也必须返回这一环节重新定义粒 度。
在定义粒度过程中，应该最大限度地选择业务过程中最为原子性的粒度，这样可以带来后续的最大灵活 度，也可以满足业务用户的任何粒度的分析需求。
3、确认维度
定义了粒度之后，相关业务过程的细节也就确定了，对应的维度就很容易确定。正如前文所述，维度是 对度量的上下文和环境的描述。通过维度，业务过程度量与事实就会变得丰富和丰满起来。对于订单来 说，常见的维度会包含商品、日期、买家、卖家、门店等而每一个维度还可以包含大量的描述信息，比 如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。
4、确认事实
确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后，事实和度量一般也很容易确定，比 如超市的订单活动，相关的度量显然是销售数量和销售金额。
在实际维度事实设计中，可能还会碰到度量拆分的问题，比如超市开展单个小票满10减10元的活动，如 果小票金额超过10元，这10元的优惠额如何分配到每一个小票子项实际设计中，可以和业务方具体讨论 并制订具体的拆分分配算法。
11. 简述维度建模和范式建模区别 ？
1、范式建模
Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。操作型或事务型系统的数据源，通过ETL 抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据建设原子数据的数据仓库EDW，EDW不是多 维格式的，不方便上层应用做数据分析，所以需要通过汇总建设成多维格式的数据集市层。
优势：易于维护，高度集成；
劣势：结构死板，部署周期较长。范式建模应用在EDW层
一个符合第三范式的关系必须具有以下三个条件：
每个属性的值唯一，不具有多义性；
每个非主属性必须完全依赖于整个主键，而非主键的一部分；
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
但是由于EDW的数据是原子粒度的，数据量比较大，完全规范的3范式在数据的交互的时候效率比较低 下，所以通常会根据实际情况在事实表上做一些冗余，减少过多的数据交互。
2、维度建模
Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构。同样的，操作型或事务型系统的数据 源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据，利用维度建模方法建设一致 维度的数据集市。通过一致性维度可以将数据集市联系在一起，由所有的数据集市组成数据仓库。
优势：构建迅速，最快的看到投资回报率，敏捷灵活；
劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
具体选择哪种建模模型，目前实际企业实际开发中，不会选择绝对一种，根据情况灵活组合，甚至并存
（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体 系，减少Join就是减少Shuule，性能差距很大。
12. 简述维度表和事实表的区别 ？
简单的说维度表就是我们观察该事物的角度（维度)；事实表就是我们要关注的内容。
事实表：表格里存储了能体现实际数据或详细数值，一般由维度编码和事实数据组成。
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买 为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。
维度表：表格里存放了具有独立属性和层次结构的数据，一般由维度编码和对应的维度说明(标签)组 成。
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联 的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模 迅速增长。
比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按...分析就构成一个维度。前面的示例就可以有两个维度：类型和区域。下面是两个常见的维度表结构：
产品维度表：Prod_id, Product_Name, Category, Color, Size, Price
时间维度表：TimeKey, Season, Year, Month, Date
而事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下：
销售事实表：Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量，以货币计),
Unit(销售量)
事实数据和维度数据的识别必须依据具体的主题问题而定。事实表用来存储事实的度量（measure）及 指向各个维的外键值。维表用来保存该维的元数据，即维的描述信息，包括维的层次及成员类别等
13. 简述什么是ER模型 ？
在信息系统中，将事务抽象为"实体"（Entity）、"属性"（Property）、"关系"（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。
实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库表的 实体表。
属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有"库存"的属 性产生；用户购买商品，依附实体用户、商品，就会有"购买数量"、"金额"的属性产品。
实体之间建立关系时，存在对照关系：
1:1：即1对1的关系
1:n：即1对多的关系n:m：即多对多的关系
在日常建模中，"实体"用矩形表示，"关系"用菱形，"属性"用椭圆形。ER实体关系模型也称为E-R关系 图。
14. 简述OLAP、OLTP解释 ？
操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing）
也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查 询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的 数据库系统作为数据管理的主要手段，主要用于操作型处理。
分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing） 一般针对某些主题的历史数据进行分析，支持管理决策。
OLTP与OLAP的异同如下表所示：
操作型处理 分析型处理
细节的 综合的或提炼的
实体-关系（ER）模型 星型或雪花模型
存取瞬间数据 存储历史数据，不包含最近的数据
可更新的 只读，只追加
一次操作一个单元 一次操作一个集合
性能要求高，响应时间短 性能要求宽松
面向事务 面向分析
一次操作数据量小 一次操作数据量大
支持日常操作 支持决策需求
数据量小 数据量大
客户订单、库存水平和银行账户等 客户收益分析、市场细分等
15. 简述维度设计中有整合和拆分，有哪些方法，并详细说明 ？
1、垂直整合
在不同来源表中可能会包含这相同的数据集。只是存储的信息不同。如电商的会员相关的表包含了会员 基础信息表、会员扩展表、会员等级信息表等，依照维度设计方法，尽量整合到会员维度模型中，丰富 其维度属性。
2、水平整合
不同来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。如上会员体系中还可能存 在各种类型会员表，如淘宝生态中 淘宝会员、国际站会员、支付宝会员等水平类型的表。这种情况的整合过程中，首先需要考虑各个会员体系是否有交叉，如果存在交叉，则需要去重；如果不存在交叉，则 需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后的表
的自然键；另一种方式是设置超自然键，将来源表各子集的自然键加工成个字段作为超自然键。
3、水平拆分
维度通常可以按照类别和类型细分。如某宝系商品表，根据业务线或行业等可以对商品进行细分，如淘 宝的商品、天猫的商品、 飞猪旅行的商品、淘宝海外的商品、天猫国际的商品等。不同分类的商品，其维度属性可能相同，也可能不同。航旅商品想比较于普通商品都有都有商品价格、标题、类型、上架时 间、类目等维度属性。但是航旅的商品除了有这些公共属性外，还有酒店、点、门票、旅行等自己独特 的维度属性。
针对此问题一般有两种解决方案：
将维度的不同分类实例化为不同的维度，同时在主维度表中保存公共属性； 维护单一维度，包含所有的可能的属性。
具体选择哪种方案，在数据模型设计过程中需要考虑的因素有很多，基本不可能满足各个特性指标的最 优化。在设计过程中需要重点考虑以下几个原则。
扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定 性。软件工程中的高内聚、低稠合的思想是重要的指导方针。
效能：在性能和成本方面取得平衡。通过牺牲一定的存储成本，达到性能和逻辑的优化。
易用性：模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表，并能够方 便地查询和分析。
根据数据模型的设计思想我们可以如下考虑和选择：
第一个是维度不同分类的属性差异情况。当维度属性随类型变化较大时，将所有可能的属性建立在 一个表中时不切合实际的，也没有必要这样做。此时建议采用方案一，定义一个主维度用于存放公 共属性；同时定义多个子维度，其中除了包含公共属性外，还包含各自的特殊属性。比如在阿里巴 巴数据仓库维度体系中，依据此方法，构建了商品维度、航旅商品维度等。公共属性 般比较稳
定，通过核心的商品维度，保证了核心维度的稳定性；通过扩展子维度的方式，保证了模型的扩展 性。
第二个是业务的关联程度。两个相关性较低的业务，稠合在起弊大于利，对模型的稳定性和易用性 影响较大。比如在数据仓库维度体系中，对某宝商品和 *** 商品构建两个维度。业务各自发展在数据仓库层面，属于不同数据集市，一 般不会相互调用，业务分析人员 般只针对本数据集市进行统计分析。如果设计成一个维度，由于不同业务各自发展， 此维度需要变更，淘宝业务变更亦然， 稳定性很差；在易用性方面，会给数据使用方造成困扰。
4、垂直拆分
维度是维度建模的基础和灵魂，维度属性的丰富程度直接决定了数据仓库的能力。在进行维度设计时， 依据维度设计的原则，尽可能丰富维度属性，同时进行反规范化处理。对于具体实现时可能存在的问题 如下：
一是在"水平拆分"中提到的，由于维度分类的不同而存在特殊的维度属性，可以通过水平拆分的方 式解决此问题。
二是某些维度属性的来源表产生时间较早，而某些维度属性的来表产出时间较晚；或者某些维度属 性的热度高、使用频繁，而某些维度属性的热度低、较少使用 或或者某些维度属性经常变化，而某些维度属性比较稳定。在"水平拆分"中提到的模型设计的三个原则同样适合解决此问题。
出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维度表存放稳定、产出时间早、认读 高的属性；从表存放变化较快、产出时间较晚、热度低的属性。例如在商品维表的设计中，可以设计商 品主维度和商品的扩展维度。主商品表时间可以每天1点产生，而扩展维度每天3点才能产生。由于商品 扩展维度有冗余的库存等变化较快的数据，对于主维度进行缓慢变化的处理较为重要。通过存储的冗余 和计算成本的增加，实现了商品主模型的稳定和产出时间的提前，对于整个数据仓库的稳定和下游应用 的产出都有较大意义。
16. 简述事实表设计分几种，每一种都是如何在业务中使用 ？
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表 达业务过程，包含了引用的维度 和与业务过程有关的度量。
1、事实表概述
事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。
1）事务事实表
也称原子事实表，描述业务过程，跟踪控件或时间上某点的度量事件，保存的是最原子的数据。 类似于mysql binlog日志，每一次相关的 change 都记录下来，生成一行新的数据。 2）周期快照事实表
以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等。
只看某个业务过程，比如订单收货，数据按订单收货时间来切分，周期可以为每天、每月等。
3）累积快照事实表
用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记 录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。
要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算 不同业务过程的时间间隔。
2、事实表设计原则
原则 1：尽可能包含所有与业务过程相关的事实
分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；
在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储 开销不会太大；
原则 2：只选择与业务过程相关的事实
如订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
原则 3：分解不可加性事实为可加的组件
如订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；
原则 4：在选择维度和事实之前必须先声明粒度
粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性； 每个维度和事实必须与所定义的粒度保持一致；
设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；
原则 5：在同一个事实表中不能有多种不同粒度的事实
疑问：怎么判断不同事实的粒度是否相同？
粒度为票一级；（实际业务中，一个订单可以同时支付多张票）
票支付金额和票折扣金额，两个事实的粒度为 "票级"，与定义的粒度一致；
订单支付金额和订单票数，两个事实的粒度为 "订单级"，属于上一层订单级数据，与 "票级"
事实表的粒度不一致，且不能进行汇总；
如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；
原则 6：事实的单位要保持一致
如订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分， 以方便使用；
原则 7：对事实的 null 值要处理
原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；
处理：用 0 代替 null ；
原则 8：使用退化维度提高事实表的易用性
事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；
通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等； 易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；
在 Kimball 的维度建模中，通常按照星形模型的方式设计，通过事实表的外键关联专门的维表，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样。
思路：通过增加冗余存储，减少计算开销，提高使用效率
3、事实表设计方法
上上一题也有说过，这里大同小异，也可以看上上一题的
Kimball 的维度模型设计 4 步法：选择业务过程、声明粒度、确定维度、确定事实。
当前的互联网大数据环境，维度模型的设计，是基于 Kimball 的四步维度建模方法进行了更进一步的改进。
第一步：选择业务过程及确定事实表类型
思路：详细分析需求，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的 业务过程。
以实例说明：如何选择业务过程？如何确定事实表类型？ 例：淘宝的一个交易订单
1）分析业务的生命周期：如上图，业务过程通常使用行为动词表示业务执行的活动；
2）明确关键的业务步骤：该订单流转的业务过程有 4 个：创建订单 → 买家付款 → 卖家发货 → 买家确认收货；
3）根据业务需求，选择与维度建模有关的业务过程；
如是选择 "买家付款" 这个业务过程，还是选择 "创建订单" 和 "买家付款" 这两个业务过程，具体根据业务情况来定。
4）根据所选的业务过程确定事实表类型；
如选择 "买家付款" 这个业务过程，则事实表类型应为只包含买家付款这一个业务过程的 "单事务事实表"；
如选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有
4 个业务过程的 "累积快照事实表"。
第二步：声明粒度
粒度的作用：
粒度的声明，意味着精确定义事实表的每一行所表示的业务含义；
明确的粒度能够确保对实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次 记录。
粒度的选择：尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。
灵活性：支持无法预期的各种细节层次的用户需求；
对于订单级别，粒度可以定义为最细的订单级别。（如，父子订单，事实表的粒度可以定 "子订单级别" ；）
第三步：确定维度
完成了粒度声明，就意味着确定了主键，对应的维度组合以及相关的维度字段也可以确定了。 选择维度的原则：应该选择能够描述清楚业务过程所处的环境的维度信息；
如淘宝订单 "付款事务事实表" 中，粒度为 "子订单"，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等。
第四步：确定事实
确定原则：选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致； 思路：可以通过回答 "过程的度量是什么" 来确定；
注意：将不可加性事实分解为可加的组件；（分解的原则：可以通过分解后的可加的属性值，计算得到 不可加性事实）
17. 简述单事务事实表、多事务事实表区别与作用 ？
事务事实表用于跟踪定义业务过程的个体行为设计案例场景如下：为交易事务设计事实表
1）业务分析：交易事务包括下单、支付、发货、完结四个业务过程。
2）确定粒度：同一个订单中可以包含多个在商品，每个商品对应一个子订单。在上述四个业务过程中 下单、支付、完结选择子订单作为粒度，而发货业务过程包含物流信息，以父订单为粒度。
3）确定维度：卖家、买家、商品、商品类目、发货地区、收货地区、父订单一级杂项维度。
4）确定事实：每个业务过程有自己的事实，如下单过程的下单金额、下单数量；支付过程的支付金 额、积分金额等。
5）冗余维度：为了提升效率，把常用的维度荣誉到事实表
1、单事务事实表
一个业务过程一张事实表，方便对每个业务做独立分析
2、多事务事实表
将不同业务过程放在同一个事实表中，又可以分为不同业务过程使用不同事实字段和不同业务过程使用 相同事实字段两种。
1）不同业务过程使用不同事实字段，一般用于业务相似，粒度相同但是业务过程的度量差异大的场 景。有两个典型的问题：
在数据中遇到不是当前业务过程的度量，采用零值处理
表中存在多个业务，如何标记？给每一个数据加一个属性标识是否当日业务
2）不同业务过程使用相同事实字段，用一个标签字段标识是那种业务（如商品的收藏/删除）。一般用 于业务相似，粒度相同同时业务过程的度量差异不大的场景。但是有一个问题要注意，因为用同一个字 段标识不同业务的度量，所以数据一个周期内会有多条记录。
3、单事务事实表与多事务事实表对比
单事务事实表 多事务事实表
粒度 相互不相关 相同粒度
维度 相互不相关 一致
事实 只取当前业务事实 同时保留多个过程事实，非当前业务的事实用零值处理
冗余维度 多个业务过程需要冗余多次 多个业务过程只冗余一次
计算成本 较多，每个业务单独计算一次 多个业务融合在一张表，只需计算一次
另外，如果一个业务过程的事实量巨大，不宜使用多事务事实表，会造成大量零值
18. 简述说下一致性维度、一致性事实、总线矩阵 ？
在Kimball的维度建模的数据仓库中，关于多维体系结构（MD）有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。
1、总线架构
在多维体系结构（MD）（也就是总线架构）的数据仓库架构中，主导思想是分步建立数据仓库，由数 据集市组合成企业的数据仓库。但是，在建立第一个数据集市前，架构师首先要做的就是设计出在整个 企业内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实。而开发团队必须严格的按照 这个体系结构来进行数据集市的迭代开发。
一致性维度就好比企业范围内的一组总线，不同数据集市的事实的就好比插在这组总线上的元件。这也 是称之为总线架构的原因。
实际设计过程中，我们通常把总线架构列表成矩阵的形式，其中列为一致性维度，行为不同的业务处理 过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵
（Bus Matrix）。
总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础，也建立了一套可以逐步 建立数据仓库的方法论。由于总线架构是多维体系结构的核心，所以我们有时就把多维体系结构直接称 为总线架构。
2、价值链的意义
每家机构都有一个关键业务过程组成的潜在价值链，这个价值链确定机构主体活动的自然逻辑流程。数 据仓库建设就是围绕着价值链建立一致化的维度和事实。
3、数据总矩阵
矩阵的每一行对应都对应机构中的一个业务过程，每一列都和一个业务维度相对应，用叉号填充显示的 是和每一行相关的列。业务过程应该先从单个数据源系统开始，然后再进行多数据源的合并。
企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构，提供了一种可用于分解企业数据仓库规划任 务的合理方法，开发团队可以独立的，异步的完成矩阵的各个业务过程，迭代地去建立一个集成的企业 数据仓库。
4、一致性维度
在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据 集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出 现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这 个问题。
一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需 要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结 果。一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。
在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一 致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同 的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维 度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。
在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度 在数学意义上是另一个维度的子集。
例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期 维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一 致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度 保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使 所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。
5、一致性事实
在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工 作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back
Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询 多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。
为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点：第一个是KPI的定义及计算方 法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位 的事实分开建立字段保存。
这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探 查，一个分布式的数据仓库就建成了。
6、小结
总线矩阵：业务过程和维度的交点。
一致性维度：同一集市的维度表，内容相同或包含。一致性维度要么是统一的，要么是维度表的一个子 集。
一致性事实：不同集市的同一事实，需保证口径一致，单位统一。指每个度量在整个数据仓库中都是唯 一的统计口径，为了避免歧义，一个度量只有唯一的业务术语
19. 简述从ODS层到DW层的ETL，做了哪些工作 ？
这里，我们将数据模型分为三层：数据运营层(原始数据层)（ ODS ）、数据仓库层（DW）和数据应用层（APP）。
ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务 定制的应用数据。
1、数据运营层：ODS（Operational Data Store）
"面向主题的"数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、 洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原 封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。
2、数据仓库层：DW（Data Warehouse）
数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层。
1）数据明细层：DWD（Data Warehouse Detail）
该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的 易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。
2）数据中间层：DWM（Data WareHouse Middle）
该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用 性，减少重复加工。
直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
3）数据服务层：DWS（Data WareHouse Servce）
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续 的业务查询，OLAP分析，数据分发等。
一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般 也会称该层的表为宽表。
在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问 题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。
3、数据应用层：APP（Application）
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。
20. 简述数据仓库与（传统）数据库的区别 ？
数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
数据仓库：数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
业务数据库中的数据结构是为了完成交易而设计的，不是为了而查询和分析的便利设计的。
业务数据库大多是读写优化的，即又要读（查看商品信息），也要写（产生订单，完成支付）。因 此对于大量数据的读（查询指标，一般是复杂的只读类型查询）是支持不足的。
而怎么解决这个问题，此时我们就需要建立一个数据仓库了，公司也算开始进入信息化阶段了。数据仓 库的作用在于：
数据结构为了分析和查询的便利；
只读优化的数据库，即不需要它写入速度多么快，只要做大量数据的复杂查询的速度足够快就行 了。
那么在这里前一种业务数据库（读写都优化）的是业务性数据库，后一种是分析性数据库，即数据仓 库。
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别：
操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关 心操作的响应时间、数据的安全性、完整性和并发的支持用户数等问题。传统的数据库系统作为数 据管理的主要手段，主要用于操作型处理。
分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题历史数据进行分析，支持管理决策。
OLTP与OLAP的异同如下表所示：
操作型处理 分析型处理
细节的 综合的或提炼的
实体-关系（ER）模型 星型或雪花模型
存取瞬间数据 存储历史数据，不包含最近的数据
可更新的 只读，只追加
一次操作一个单元 一次操作一个集合
性能要求高，响应时间短 性能要求宽松
面向事务 面向分析
一次操作数据量小 一次操作数据量大
支持日常操作 支持决策需求
数据量小 数据量大
客户订单、库存水平和银行账户等 客户收益分析、市场细分等
21. 简述数据质量是怎么保证的，有哪些方法保证 ？
1）从技术层面来说，需要构建一套高效、健壮的ETL程序，以此保证数据清洗、转换后数据的正确性和 一致性。
2）从流程上来说，整个ETL是多个任务，按步骤顺序执行的一个过程，后置任务依赖前置任务，定期执 行，整个流程需要自动化，并且哪个环节出现了问题，给予预警，通知相关维护人员及时处理。
3）从管理层面上来说，数据仓库是构建在公司各个业务系统之上，它是一面镜子，很多时候它能反映 出业务系统的问题，所以需要管理层的支持和约束，比如通过第一条说的事后自动检验机制反映出业务 系统的维护错误，需要相应的业务系统维护人员及时处理。
数据治理流程如下：
基本流程如下：发现数据质量问题 > 定义数据质量规则 > 质量控制 > 质量评估 > 质量优化。
扩展内容：
这里主要是阿里对数仓的一些数据质量保证原则
1、数据质量保障原则
阿里对数据仓库主要从四个方面评估数据质量
1）完整性
确保数据不存在缺失
2）准确性
确保数据不存在异常或错误
3）一致性
体现在从业务仓库加工到数据仓库，再到各个消费节点，必须是同一种类型，长度也需要保持一致。
4）及时性
确保数据能及时产出，越来越多的应用希望数据更快产出。
2、数据质量方法概述
阿里的业务复杂，种类繁多的产品每天产生数以亿计的数据，每天的数据量在PB级以上，而数据消费端 的应用又层出不穷，各类数据产品如雨后春笋般出现。为了满足这些数据应用，数据仓库的规模也不断 膨胀，同时数据质量的保障也越来越复杂。
基于上述背景，提出一套数据质量建设方法
1）消费场景知晓
主要是通过数据资产和基于元数据的应用链路分析解决消费场景知晓的问题。
2）数据生成加工各个环节卡点效验
在各个数据生成环节，格局不同资产等级做出相应的处理。
3）风险点监控在线数据
主要是针对在线系统日常运行产出的数据进行业务规则的效验，以保证数据质量，其主要使用实时 业务检测平台BCP（Biz-Check-Platform）。
离线数据主要是针对离线系统日常运行产出的数据进行数据质量监控和实效性监控，其中数据质量监控主要 是使用DQC，实效性监控主要是使用摩萨德。
4）质量衡量
对质量的衡量既有事前的衡量，如DQC覆盖率；又有事后的衡量，主要用于跟进质量问题，确定质量问 题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生。根据质量问题对不同 等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障。质量分则是综合事前和事 后的衡量数据进行打分。
5）质量配套工具
针对数据质量的各个方面，都需要相关的工具进行保证，提高效率。
3、消费场景知晓
在数据快速增长，数据类产品和日常决策支持等系统层出不穷，数据仓库应接不暇，数据工程师很难确 定几百PB的数据到底是否都是重要的，是否都要进行保障，是否有一些数据已经过期了，是否所有需要 精确的进行保障。
基于上述疑问，阿里内部提出数据资产等级，解决消费场景知晓问题。
1）数据等级定义毁灭性质
即数据一旦出错，将会引起重大资产损失，导致收益大损。记为A1（Asset）
全局性质
即数据直接或者间接用于集团级业务和效果的评估、重要平台的运维、对外数据产品的透露、影响 用户在阿里系网站的行为。记为A2
局部性质
即数据直接或间接用于内部一般数据产品或者运营/产品报告，如果出现问题会给事业部或业务线 造成影响或者工作效率降低。记为A3
一般性质
即数据主要用于小二的日常数据分析，出现问题不会带来太大的影响。记为A4 未知性质
不能明确说出数据的应用场景，则标注为未知。记为A5
2）数据资产等级落地
先给不同数据产品或应用划分数据资产等级，再依托元数据的上下游血缘，可以将整个加工消费链打上 该数据资产等级。
总结：解决了消费场景知晓的问题，就知道了数据的重要等级，针对不同的等级，也将采取不同的保障 措施。
4、数据加工过程卡点校验
1）在线系统卡点效验
主要是指在线系统 的数据生成过程中进行的卡点效验。要向数据保障数据准确性，主要使用工具。
发布平台
在业务进行重大变更时，订阅这个发布过程，然后给到离线开发人员。当然不会频繁通知离 线开发人员，会根据数据资产等级通知相应人员
数据库表的变化感知
数据库扩容对表的DDL变化，都需要主动通知离线开发人员。有了开发工具，开发人员更重要
须知哪些是重要的核心数据资产须知哪些只是内部分析数据使用
2）离线系统卡点效验
首先，代码提交时的卡点效验
由于开发人员素质不同，代码能力也有差异，所以需要工具代码扫描SQL SCAN，对每次提交代码进行扫描，将风险点提出来。
其次，是任务发布上线时卡点效验
发布上线前测试，代码评审和回归测试
回归测试：指修改了旧代码后，重新进行测试以确认修改没引入新的错误。冒烟测试：指开发人员修复一个bug，测试人员专门针对这个问题测试。
发布上线后测试：Dry-Run测试或真实环境运行测试。
Dry-Run：不执行代码，仅运行执行计划，避免由于上线下环境不一致导致语法错误。 最后是节点变更或数据重刷前的变更通知
一般指使用通知中心将变更原因、变更逻辑、变更测试报告和变更时间等自动通知下游，下游对此 次变更没有异议后，再按约定时间执行发布变更，将变更对下游影响降至最低。
5、风险点监控
主要是针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制
1）在线数据风险点监控
采用实时业务检测平台BCP保障重要数据资产的质量。BCP：制定效验规则用于验证数据的准确性
2）离线数据风险监控
数据准确性
使用DQC来监控数据数据及时性
需要进行一系列的报警和优先级设置，使得重要的任务优先且正确产出。使用的工具有摩萨德。
6、质量衡量
评估各种数据仓库质量保障方案，有以下指标：
1）数据质量起夜率，及夜晚处理数据问题
2）数据质量事件
3）数据质量故障体系：指的是严重的数据质量事件处理方案：
故障定义
故障等级故障处理故障REview
22. 简述怎么衡量数仓的数据质量，有哪些指标 ？
1）数据的准确性
数据准确性（Accuracy）是指数据采集值或者观测值和真实值之间的接近程度，也叫做误差值，误差越 大，准确度越低。
指数据中记录的信息和数据是否准确，数据记录的信息是否存在异常或错误。准确性关注的是数据记录 中存在的错误，如字符型数据的乱码现象就存在着准确性的问题，还有就是异常的数值：异常大或者异 常小的数值、不符合有效性要求的数值等。
2）数据的精确性
数据的精确性（Precision）是指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。精 确性，也可以叫精准性。精确性与我们数据采集的精度有关系。精度高，要求数据采集的粒度越细，误 差的容忍程度越低。
比如测量人的身高，我们可以精确到厘米，多次测量差异只会在厘米级别；测量北京到上海的距离，我 们精确到公里，多次测量结果间的差异会
在公里级别:采用游标卡尺测量一个零件的厚度，可以精确到1/50毫米，多次测量的结果间的误差也只会 在1/50毫米间。采用的测量方法和手段直接影响着数据的精确性。
3）数据的真实性
数据的真实性，也叫数据的正确性(Rightness)。数据的正确性取决于数据采集过程的可控程度，可控程 度高，可追溯情况好，数据的真实性容易得到保障，而可控程度低或者无法追溯，数据造假后无法追 溯，则真实性难以保证。为了提高数据的真实性，采用无人进行过程干涉的智能终端直接采集数据，能 够更好地保证所采集数据的真实性，减少人为干预，减少数据造假，从而让数据更加正确地反应客观事物。
4）数据的及时性
数据的及时性（In-time）就是指数据能否在需要的时候得到保证。
比如月初会对上个月的经营和管理数据进行统计汇总，这些数据能否及时处理完成，财务能否在月度关 账后及时核算。数据的及时性是我们数据分析和挖掘及时性的保障。如果公司的财务核算复杂，核算速 度缓慢，上个月的数据在月中才能统计汇总完成，等需要调整财务策略的时候，已经到了月底了，一个 月已经快过完了。特别是公司做大了之后，业务覆盖多个市场，多个国家，数据不能及时汇总，会影响 到高层决策的及时程度，数据的及时性与企业数据处理的速度和效率有直接的关系，为了提高数据的及 时性，越来越多的公司采用管理信息系统，并在管理信息系统中附加各种自动数据外理功能，能够在数 据上传系统之后自动完成绝大部分报表，从而保证数据外理的效率。计算机自动外理中间层数据是提高 企业数据处理效率的有效手段。
除了保证数据采集的及时性和数据外理的效率问题外，还需要从制度和流程上保证数据传输的及时性， 数据报表完成了，要及时或者在要求的时间范围内发送到指定的部门，或者上传到指定的存储空间。
5）数据的即时性
指数据采集时间节点和数据传输的时间节点，一个数据在数据源头采集后立即存储，并立即加工呈现， 就是即时数据，而经过一段时间之后再传输到信息系统中，则数据即时性就稍差。
比如微博的数据采集，当用户发布了微博，数据立即能够被抓取和加工，会生成即时微博数据报告，并 随着时间推移，数据不断变化，我们可以称作是即时采集和处理的。一个生产设备的仪表即时反应着设 备的温度、电压、电流、气压等数据，这些数据生成数据流，随时监控设备的运行状况，这个数据可以 看作是即时数据。而当设备的即时运行数据存储下来，用来分析设备运行状况与设备寿命的关系，这些 数据就成为历史数据。
6）数据的完整性
数据的完整性是从数据采集到的程度来衡量的，是应采集和实际采集到数据之间的比例。
比如一条信息采集12个数据点，如我们采集员工信息数据的时候，要求填写姓名，出生日期，性别，民 族、籍贯，身高、血型、婚姻状况，最高学历，最高学历专业、最高学历毕业院校、最高学历毕业时间 等12项信息，而某一员工仅仅填写了部分信息，如只填写了其中的5项，则该员工所填写数据的完整性 只有一半。
一个公司数据的完整性体现着这个公司对数据的重视程度。要求采集数据而实际上并未完整采集，只采 集了一部分，这就是不完整的，往往是公司对数据采集质量要求不到位导致的。公司要求每个人都填写 完整的个人信息表，而有部分员工拒绝填写，公司2000员工，只有1200人填写了完整的个人信息表，则 这个数据集就是不完整的。
另外，对干动态数据，还要从时间轴上去衡量数据采集的完整性。比如，我们要求每小时采集一次数 据，每天会形成24个数据点，记录为24条数据，但是员工渎职，只记录了20次，那么这个数据集也是不完整的。
7）数据的全面性
数据的全面性和完整性不同，完整性衡量的是应采集和实际采集的差异。而全面性指的是数据采集点的 遗漏情况。
比如说，我们要采集员工行为数据，我们只采集了员工上班打卡和下班打卡的数据，上班时间的员工行 为数据并未采集，或者没有找到合适的方法来采集。那么，这个数据集就是不全面的。
比如描述一个产品的包装，仅仅描述了产品包装的正面和背面，没有记录产品包装的侧面，则就是不全 面的。我们记录一个客户的交易数据，我们只采集了客户订单中的产品、订单中产品的价格和数量，而 没有采集客户送货地址，采购时间，这个数据采集就是不全面的。
比如腾讯OO和微信的用户数据记录了客户交流沟通的数据；阿里和京东的用户数据记录了用户的购买 交易数据；百度地图记录了用户出行的数据；大众点评和美团记录了客户餐饮娱乐的数据。对于全面描 述一个人的生活的衣食住行各方面，这些公司的数据都是不全面的，而如果把他们的数据整合起来，则 会形成更加全面的数据。所以说，数据的全面性是一个相对的概念。过度追求数据的全面性是不现实的。
8）数据的关联性
数据的关联性是指各个数据集之间的关联关系。
比如员工工资数据和工绩效考核数据是通过员工这个资源关联在一起来的，而且绩效数据直接关系到工 资的多少。采购订单数据与生产订单数据之间通过物料的追溯机制进行关联，而生产订单又是由员工完 成的，即通过员工作业数据与员工信息数据关联起来
23. 简述什么是增量表、全量表和拉链表 ？
在数据仓库中，全量表、增量表和拉链表是常见的数据存储方式。它们各自具有不同的特点和应用场景，下面将详细介绍这些数据存储方式的概念和优缺点。
一、全量表
全量表是指将数据源中的数据完全加载到数据仓库中，以便进行分析和查询。全量表的特点是数据完整、详细，任何查询都可以在全量表上进行。但是，全量表需要占用较大的存储空间，数据加载和更新也需要较长的时间。
全量表的应用场景主要是数据仓库的初始建设阶段，或者是对数据源数据变化不频繁的情况。全量表适用于一次性查询和批量处理，例如数据分析、报表生成等。
二、增量表
增量表是指只将数据源中发生变化的数据加载到数据仓库中，以减少数据仓库的存储空间和数据加载时间。增量表的特点是数据更新快速、存储空间较小，适用于数据源数据变化频繁的情况。但是，增量表无法支持一些复杂的查询和数据分析操作。
增量表的应用场景主要是数据源数据变化频繁的情况，例如电商、金融等行业的交易数据。增量表适用于实时查询和实时数据分析，可以为业务决策提供快速支持。
三、拉链表
拉链表是指将数据源中的历史数据和当前数据分别存储在不同的表中，并通过链接字段将它们关联起来。拉链表的特点是可以在不删除历史数据的情况下，对当前数据进行更新和插入操作。拉链表适用于需要保留历史数据的情况，例如订单管理、商品管理等。
拉链表的应用场景主要是需要保留历史数据的情况，例如订单管理、商品管理等。拉链表适用于需要分析历史数据和当前数据的场景，例如销售分析、产品分析等。
在实际应用中，根据不同的业务需求和数据特点，可以选择不同的数据存储方式。全量表、增量表和拉链表各有其优点和缺点，可以根据实际需求进行选择和组合使用。
需要注意的是，数据仓库的建设是一个长期的过程，需要不断地完善和优化。在建设数据仓库时，需要考虑数据的质量、安全性和可操作性等方面的问题，以确保数据的准确性和可靠性。同时，也需要定期对数据仓库进行清理和优化，以提高数据的处理效率和查询性能。
总之，数据仓库的全量表、增量表和拉链表是数据存储的常见方式，各有其优点和缺点。在建设数据仓库时，需要根据实际需求和数据特点选择合适的数据存储方式，并注意数据的质量和安全性。同时，也需要不断地优化和改进数据仓库的建设，以提高数据的处理效率和查询性能。