【2022持续更新】大数据面试题整理-数据仓库篇

大数据面试题整理-数据仓库篇

导语

本专栏博文会整理日常工作与面试中最常用到的大数据相关组件与Java语言的架构、概念、知识点，方便大家进行查阅。
涉及到的面试题以及答案均为博主搜罗整理，并加上自己的理解编写而成。同时博主会在部分题目的下方添加管遇此题深入理解的博文连接，方便读者的深入理解。
希望大家可以通过此篇博文对于大数据相关概念有一个更深入的理解
还有哪些想看的面试题，读者可以在评论区补充，博主会在一天内进行更新！！！
最后预祝大家新的一年升职加薪，工资涨涨涨！

1、什么是数据仓库（数仓的定义）

数据仓库 Data Warehouse，是为企业所决策制定过程，提供所有支持类型的数据集合。用于分析性报告和决策支持。数仓是一个面向主题、集成的、相对稳定、反应历史变化的数据集合，随着大数据技术的发展，其作用不再局限于决策分析、还可以为业务应用、审计、追踪溯源等多方面提供数据支撑，帮助企业完成数字化转型。

2、数据仓库特点

面向主题

普通的操作型数据库主要面向事务性处理，而数据仓库中的所有数据一般按照主题进行划分。主题是对业务数据的抽象，是从较高层次上对信息系统中的数据进行归纳和整理。

面向主题的数据可以划分成两部分

1. 根据原系统业务数据的特点进行主题的抽取。
2. 确定每个主题所包含的数据内容。例如客户主题、产品主题、财务主题等；而客户主题包括客户基本信息、客户信用信息、客户资源信息等内容。

分析数据仓库主题的时候，一般方法是先确定几个基本的主题，然后再将范围扩大，最后再逐步求精

集成性

面向操作型的数据库通常是异构的、并且相互独立，所以无法对信息进行概括和反映信息的本质。
而数据仓库中的数据是经过数据的抽取、清洗、切换、加载得到的，所以为了保证数据不存在二义性，必须对数据进行编码统一和汇总，以保证数仓内的数据一致性，消除冗余数据。

稳定性

数据仓库中的数据反映的都是一段历史时期的数据内容，它的主要操作是查询、分析而不进行一般意义上的更新（操作型数据库主要完成数据的增加、修改、删除、查询），一旦某个数据进入到数据仓库后，一般情况下数据会被长期保留，当超过规定的期限才会被删除。通常数据仓库需要做的工作就是加载、查询和分析，一般不进行修改操作。

反映历史变化

数据仓库不断从操作型数据库或其他数据源获取变化的数据，从而分析和预测需要的历史数据，所以一般数据仓库中数据表的维度与事实表中都含有时间键，以表明数据的历史时期信息，然后不断增加新的数据内容。通过这些历史信息可以对企业的发展历程和趋势做出分析和预测。数据仓库的建设需要大量的业务数据作为积累，并将这些宝贵的历史信息经过加工、整理，最后提供给决策分析人员，这是数据仓库建设的根本目的。

3、数据库和数据仓库的区别

数据库
用于OLTP，主要用于操作型处理
数据库是面向事物处理的，数据是由日常的业务产生的，常更新；
数据库一般用来存储当前事务性数据，如交易数据、业务数据；
数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；

数据仓库
用于OLAP，支持管理决策。
数据仓库是面向主题的，数据来源多样，经过一定的规则转换得到，用来分析。
数据仓库一般存储的历史数据。
数据仓库的设计一般不符合三范式，并且反规划范，有利于查询。

4、数仓构建流程

1、数据调研、划分主题域

通过与业务部门的交流，了解建立数仓要解决的问题，确定数据分析或前端展现的主题和各个主题下的查询分析要求。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系。

2、明确统计指标

确定主题后，需要考虑分析的各种指标。它们一般为数据值型数据，量度是要统计的指标，必须事先选择恰当，基于不同的度量可以进行复杂关键性指标(KPI)的设计和计算。

3、构建总线矩阵

明确业务过程和维度所属主题域、明确维度与业务过程的关系，最后形成一个总线矩阵图表。

4、构建明细模型

DIM公共维度层
（DIM）公共维度层由维度表构成，基于维度建模理念，建立整个企业的一致性维度。
维度是逻辑概念，是衡量和观察业务的角度。在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。

构建明细事实表DWD，将原始数据表和各个维度表进行关联,生成事实表。

5、构建汇总模型

根据衍生指标和派生指标构建DWS

6、ETL以及代码实现

数据清洗转换和传输。业务系统中的数据加载到数据仓库之前，必须进行数据的清洗和转换，保证数据仓库中数据的一致性。

7、数仓应用、结果验证

开发数据仓库的分析应用。满足业务部门对数据进行分析的需求。

8、数仓管理

元数据治理、数据质量监控、数据血缘管理

5、数仓分层概述

ods：operation data store原始数据层，
数据保持原貌不做处理，ODS层是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响

dmi：公共维度层
公共维度层由维度表构成，基于维度建模理念，建立整个企业的一致性维度。

dwd：data warehouse detail明细数据层
结构和粒度与原始表保持一致，通过维表与ods层数据进行清洗关联得到（去除空值，脏数据）
是业务层与数据仓库的隔离层

dws：data warehouse service数据服务层
数据轻度汇总。基于dwd上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表

ads：application data store 数据应用层
为各种统计报表提供数据
该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。例如：我们经常说的报表数据，或者说那种大宽表，一般就放在这里。

6、数仓为什么要分层

把复杂问题简单化

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。

清晰数据结构：

每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。

空间换时间、减少重复开发。

通过建设多层次的数据模型供用户使用，避免用户直接使用操作型数据，可以更高效的访问数据。
通过开发一些通用的中间层数据，能够减少极大的重复计算。

数据之间解耦合：

分层后不必改一次业务就重新接入数据。

而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

7、维度建模选择：星型、雪花、星座

星型模型

一张事实表，根据主键关联多张一级维度表

星型架构是一种非规范化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。很多统计查询不需要做外部的连接，通过冗余换取运行效率。

雪花模型

雪花模式是星型模式的扩展，其中某些维表被规范化，进一步分解到附加维度表中。

优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。

星座模型

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。常用于数据关系更复杂的场景。也称事实星座模型。

比较

1、雪花模型在维度表、事实表之间的连接很多，因此性能方面会比星型模型低。

2、雪花模型使用的是规范化数据，数据冗余来减少数据量。其维度层级和维度信息都存储在数据模型之中。
星形模型是反规范化数据，数据存在冗余，维度直接关联事实表，维度层级清晰明了。

3、雪花模型在设计上更加复杂，由于附属维度的限制，ETL复杂且不能并行化。
星形模型加载维度表，不需要添加附属维度层级，ETL相对简单，可以实现高度的并行化。

4、雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”。
星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”

8、缓慢变化维处理

常见的缓慢变化维处理方式有三种：
1）直接覆盖：不记录历史数据，薪数据覆盖旧数据

2）新加一行数据（纵向扩展）：使用代理主键+生效失效时间或者是代理主键+生效失效标识（保存多条记录，直接新添一条记录，同时保留原有记录，并用单独的专用字段保存）

3）新加两个字段（横向扩展）：一个是previous，一个是current，每次更新只更新这两个值，但是这样职能保留最近两次的变化（添加历史列，用不同的字段保存变化痕迹，因为只保存两次变化记录，使用与变化不超过两次的维度）

1. 通过拉链表

9、拉链表的应用

10、事实表的类型

事务型事实表

概述

事务事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。

事务型事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求。

设计流程

设计事务事实表时一般可遵循以下四个步骤：

选择业务过程→声明粒度→确认维度→确认事实

选择业务过程

在业务系统中，挑选我们感兴趣的业务过程，业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。通常情况下，一个业务过程对应一张事务型事实表。

声明粒度

业务过程确定后，需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么，应该尽可能选择最细粒度，以此来应各种细节程度的需求。
典型的粒度声明如下：
订单事实表中一行数据表示的是一个订单中的一个商品项。

确定维度

确定维度具体是指，确定与每张事务型事实表相关的维度有哪些。

确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。

确定事实

此处的“事实”一词，指的是每个业务过程的度量值（通常是可累加的数字类型的值，例如：次数、个数、件数、金额等）。

经过上述四个步骤，事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么，第三步可以确定每张事务型事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。

周期快照事实表

概述

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。

对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。

对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。

设计流程

确定粒度

周期型快照事实表的粒度可由采样周期和维度描述，故确定采样周期和维度后即可确定粒度。

采样周期通常选择每日。

维度可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则可确定维度为仓库和商品。

确定完采样周期和维度后，即可确定该表粒度为每日-仓库-商品。

确认事实

事实也可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则事实为商品库存。

适用场景

适用于分析存量型、状态型指标

事实类型

此处的事实类型是指度量值的类型，而非事实表的类型。事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。

可加事实

可加事实是指可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。

半可加事实

半可加事实是指只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。

不可加事实

不可加事实是指完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。

累计快照事实表

概述

累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。

累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

设计流程

累积型快照事实表的设计流程同事务型事实表类似，也可采用以下四个步骤，下面重点描述与事务型事实表的不同之处。

选择业务过程→声明粒度→确认维度→确认事实

选择业务过程

选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表。

声明粒度

精确定义每行数据表示的是什么，尽量选择最小粒度。

确认维度

选择与各业务过程相关的维度，需要注意的是，每各业务过程均需要一个日期维度。

确认事实

选择各业务过程的度量值。

适用场景

适用于处理多事务关联

11、全量表,增量表,追加表，拉链表的区别及使用场景（同步策略）

全量表
每天的所有的最新状态的数据。 1、全量表，有无变化，都要报 2、每次上报的数据都是所有的数据（变化的 + 没有变化的）

增量表
新增数据，增量数据是上次导出之后的新数据。 1、记录每次增加的量，而不是总量； 2、增量表，只报变化量，无变化不用报 3、业务库表中需有主键及创建时间，修改时间

拉链表
维护历史状态，以及最新状态数据
适用情况：

1. 数据量比较大
2. 表中的部分字段会被更新
3. 需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数
4. 更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费

优点 1、满足反应数据的历史状态 2、最大程度节省存储

12、你们的数仓上层应用有哪些

用户画像，运营平台，精准营销，推荐系统等

13、数据质量保障

14、怎么理解元数据？

1. 业务元数据 描述 "数据"背后的业务含义。 主题定义：每段 ETL、表背后的归属业务主题。 业务描述：每段代码实现的具体业务逻辑。 标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。 标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。 不断的进行维护且与业务方进行沟通确认。
2. 技术元数据 数据源元数据：例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。
3. ETL 元数据： 根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。 数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。 数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
4. 数据仓库元数据： 数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式等。
5. BI 元数据： 汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。
6. 管理元数据 管理领域相关，包括管理流程、人员组织、角色职责等。

15、数据漂移如何解决

源系统同步进入数据仓库的第一层数据称为ODS层，数据漂移是ODS数据的一个顽疾。通常是指ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

由于ODS需要承接面向历史的细节数据查询需求,这就需要物理落地到数据仓库的ODS表按时间段来切分进行分区存储,通常的做法是按某些时间戳字段来切分,而实际上往往由于时间戳字段的准确性问题导致发生数据漂移。

通常,时间戳字段分为四类:
1、 数据库中数据更新时间(假设这类字段叫modified_time)
2、 数据库日志中的数据记录更新时间(假设这类字段叫log_time)
3、 业务过程发生时间(假设这类字段叫proc_time)
4、 数据被抽取的时间(假设这类字段叫extract_time)

理论上,这几个时间应该是一致的,但是在实际生产中,这几个时间往往会出现差异,可能的原因有以下几点:
1、 由于数据抽取需要时间, extract_time往往会晚于前三个时间。
2、 前台业务系统手工订正数据时未更新modified_time.
3、 由于网络或者系统压力问题, log_time或者modified_time会晚于proc_time.

通常的做法是根据其中的某一个字段来切分ODS表,这就导致产生数据漂移。下面我们来具体看下数据漂移的几种场景。
1、 根据extract_time来获取数据。这种情况数据漂移的问题最明显。
2、 根据modified_time限制。在实际生产中这种情况最常见,但是往往会发生不更新modified time而导致的数据遗漏,或者凌晨时间产生的数据记录漂移到后一天。
3、 根据log_time限制。由于网络或者系统压力问题, log_time会晚于 proc_time,从而导致凌晨时间产生的数据记录漂移到后一天。例如,在淘宝“双11”大促期间凌晨时间产生的数据量非常大,用户支付需要调用多个接口,从而导致log_time晚于实际的支付时间。
4、 根据proc_time限制。仅仅根据proc_time限制,我们所获取的ODS表只是包含一个业务过程所产生的记录,会遗漏很多其他过程的变化记录,这违背了ODS和业务系统保持一致的设计原则。
处理方法主要有以下两种

1、 多获取后一天的数据
在ODS每个时间分区中向前、向后多冗余一些数据,保障数据只会多不会少,而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间proc_time来限制。
但是这种方式会有一些数据误差。
2、 通过多个时间截字段限制时间来获取相对准确的数据
(1) 首先根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据,并用modified_time过滤非当天数据,确保数据不会因为系统问题而遗漏。
(2) 然后根据log_time获取后一天15分钟的数据;针对此数据,按照主键根据log_time做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据(数据库日志将保留所有变化的数据,但是落地到ODS表的是根据主键去重获取最后状态变化的数据)。
(3) 最后将前两步的结果数据做全外连接,通过限制业务时间proc_time来获取我们所需要的数据。

下面来看处理淘宝交易订单的数据漂移的实际案例。我们在处理“双11”交易订单时发现,有一大批在11月11日 23:59:59左右支付的交易订单漂移到了12日。主要原因是用户下单支付后系统需要调用支付宝的接口而有所延迟,从而导致这些订单最终生成的时间跨天了。即modified_time和log_time都晚于proc_time.
如果订单只有一个支付业务过程,则可以用支付时间来限制就能获取到正确的数据。但是往往实际订单有多个业务过程:下单、支付、成功,每个业务过程都有相应的时间戳字段,并不只有支付数据会漂移。
如果直接通过多获取后一天的数据,然后限制这些时间,则可以获取到相关数据,但是后一天的数据可能已经更新多次,我们直接获取到的那条记录已经是更新多次后的状态,数据的准确性存在一定的问题。
因此,我们可以根据实际情况获取后一天15分钟的数据,并限制多个业务过程的时间戳字段(下单、支付、成功)都是“双11"当天的,然后对这些数据按照订单的modified time做升序排列,获取每个订单首次数据变更的那条记录。
此外,我们可以根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据,并用modifie_time过滤非当天数据,针对每个订单按照log_time进行降序排列,取每个订单当天最后一次数据变更的那条记录。最后将两份数据根据订单做全外连接,将漂移数据回补到当天数据中。

16、数据治理内容

技术层面-李奇峰总结

1. 数据分类：首先是针对各数据进行归类，根据业务需求划分成不同的类别，然后将数据表依次归类。
2. 时间字段治理：在所有数据中添加统一名称的时间字段，依次记录数据发生时间、最后更新时间、插入时间等。
3. 数据过滤：在入库时如果碰到无法解析的错误数据，或者关键字段缺失的数据，则直接丢弃。
4. 数据去重：如果在入库时发现库中存在相同的数据，则会将新数据直接覆盖旧数据。
5. 数据抽取与合并：将各个类别的数据的指定字段抽取到一个正式库中，统一格式，去除多样字段，标注来源信息。同时在抽取过程中，将属于同一事件的多个日志进行合并，保存至合并库中。
6. 数据关联：数据入库后，各个数据之间关联性较弱，在开发过程中需要重复调用数据接口进行数据获取。于是在数据入库时或入库后，根据主外键ID、相同含义字段进行关联，将关联字段更新至源数据中。

业务层面-苏奕嘉总结

我觉得从框架而言，我个人认为需要几部分：

1. 字段规则治理：主要是和业务方对齐原子指标的含义，如有多条线，需要一起对齐口径，只有业务方都承认和了解接受了原子指标口径，数仓才好进一步处理，举例：净收益到底是【营销额-成本（包含各种费用）】还是【营销额-成本（只包含成品本身的成本）】，不同的业务线可能有不同的定义，如供应链和营销链注重的就不一样
2. 数据源治理：数据源即上游数据，上游数据多而繁杂，可细分为不同数据类型进行划域治理，类似主题建模和数据域的概念，比如订单、客户、供应链、财务等等，不同的域有不同的强规则体系，这个体系可形成一套完备的探查系统，比如数据源探查体系：订单{null值:是否有null值,长度:订单号是否满足规则,金额:是否有营销额无净销额……}，客户{OneID:是否标识,手机号:是否为空,收货地址:是否满足规则……}。不同的数据域有着不同的字段定义标准和探查规则标准，如果没有探查阶段，那么数据治理就是睁眼瞎
3. 数据质量反馈体系：很多时候，上游数据有了问题，下游沟通其实是一个很难的事情，比如上游为了满足自己业务需求，私自改了数值/字段名/表名等等，下游会发生依赖错误/数据值错误等情况，如果要求上游怎样做，其实很不靠谱，别人不太会听你的，那么就需要从更高一个维度解决，一是成立PMO组织，由更高级别的Leader组织，内部有数据部门，业务部门和测试部门，数据部门发现问题，交由测试部门进行总结反馈，定期给出质量报告，由测试部门监督业务部门完成整改，可用作计入绩效考核等方式进行管控，没有裁判的赛道是虚假的、不完整的。
4. 数据灾备规则和系统：没有人管控的了别人的做法和想法，那么就要做好数据部门本身的灾备规则和系统，比如从小处讲，ODS接入后在DW清洗时要注意NULL值处理，不管这个字段以前有没有NULL值，从大处讲，就是完善数据部门自己的代码书写规范，每次发版需要严格CodeReview，如果从系统角度出发，比如第三方，就做一个第三方统一接入系统，从源头规范化数据格式，比如业务线，就采取业务中台模式，数据所有数据统一处理统一管理，当然，这些扯开都是很大的话题，以后再讲

业务层面-幻枫总结：

1. 指标体系的建立，加上纬度属性的集成，构成数据字典，
2. 数据源有公约规则约束的情况下建立明细数据的的数据监控，数据远没有公约规则的，按照基础的数据标准和业务过程进行数据探查，然后按照数据展现情况进行数据监控，
3. 就是数据治理的组织架构，要由上层牵头下游处理，且要有管理体系，比如约束规范更改要有特定的流程，
4. 就是数仓内部根据下游的需求，制定清晰转换规则，要有相应的操作留档

业务层面-A94总结：

数据治理按类型分：

1. 主数据治理： 指企业内一致并共享的业务主体。 特点：准确性、一致性、集成性、共享性/可重用性和高价值。 主数据治理一般会作为单独的项目来做，MDM系统。一般是从源端进行管控治理主数据的主要问题： 关键信息孤岛，数据分布在多个孤岛，不能跨组织传播 组织内不能就一个主数据源达成一致 数据质量问题引发的业务流程和交易的失败 不正确或丢失数据造成合规性和绩效管理的问题 决策者做出基于错误数据的错误决定主数据解决方案： 一：数据转换映射 二：由应用系统承担主数据管理功能 三：集中管控
2. 交易数据治理 交易数据一般可以先在数据平台先行治理，之后再在源端进行管控治理
3. 参考数据治理 参考数据一般可以先在数据平台先行治理，之后再在源端进行管控治理
4. 分析数据治理 分析数据一般可以在数据平台进行治理
5. 数据模型、数据标准的治理 数据模型、数据标准一般可以先在数据平台先行治理，之后再在源端进行管控治理
6. 元数据治理：是企业数据资产管理的基础，是关于“数据的数据”，例如数据类型、数据定义、数据关系等，相当于数据表格中的表头信息，是一个相对客观的概念。 元数据一般可以先在数据中台先行治理，之后再在源端进行管控治理

思想层面-南知总结：

数据权限（安全），元数据管理（技术or业务，资产），数据质量（上下游延迟，故障快速感知和修复）

治理是很大的概念，从我经历过或做过的，可以下手的点就是质量、安全、资产

数仓是数仓，治理是治理。要明确的分开，凡涉及到口径、数据源、ETL processing的，应该算数仓方法论或数仓规范或落地平台化的方式方法

17、数据集市、数据中台、数据仓库

18、原子指标、衍生指标、派生指标的区别

1. 原子指标 基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如呼单量、交易金额
2. 派生指标 是1个原子指标+多个修饰词（可选）+时间周期，是原子指标业务统计范围的圈定。派生指标又分可以下二种类型： a. 事务型指标：是指对业务过程进行衡量的指标。例如，呼单量、订单支付金额，这类指标需 要维护原子指标以及修饰词，在此基础上创建派生指标。 b.存量型指标：是指对实体对象（如司机、乘客）某些状态的统计，例如注册司机总数、注册 乘客总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间 周期一般为“历史截止当前某个时间”。
3. 衍生指标 是在事务性指标和存量型指标的基础上复合成的。主要有比率型、比例型、统计型均值

19、范式建模

范式建模法主要用于关系型数据库的数据存储，主要用于业务系统，分为实体表与关系表，可以解决数据冗余，插入，修改，删除异常的问题。
目前OLTP业务系统中大多采用的是三范式建模法。

• 第一范式 1NF是所有关系型数据库的最基本要求。属性值不可再分，说直白点就是一列里面不能包含多个小列，就像下面这样
• 第二范式 保证一张表只描述一件事情
• 第三范式 所有字段只能直接依赖主键，不得依赖于其它字段(非主属性) 消除依赖传递。决定某字段值的必须是主键，而不是其他字段

20、数仓一致性如何保证

数仓数据不一致会导致数据重复计算，数据孤岛，并对使用人员产生误解。

数据一致性可以避免重复建设和指标冗余建设，从而保障数据口径的规范和统一，最终实现数据资产全链路关联，提供标准数据输出以及建立统一的数据公共层。

主要通过构建一致性维度和一致性事实。
通过制定数仓规范可以保障。

21、主题域如何划分

主题域通常是联系较为机密的数据主题的集合，可以根据业务关注度，将这些数据主题划分到不同的主题域（也就是说对某个主题进行分析后确定的主题的边界）。
关于主题域的划分，可以考虑几方面：

1. 按照业务或者业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
2. 根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
3. 按照功能或者应用划分：：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
4. 按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；

总而言之，切入的出发点逻辑不一样，就可以存在不同的划分逻辑。在建设过程中可采用迭代方式，不纠结于一次完成所有主题的抽象，可先从明确定义的主题开始，后续逐步总结成自身的标准模型。

22、制定了哪些数仓规范

1. 分层规范
2. 表规范：命名、注释、分区、存储格式规范、字符集、空值
3. 字段规范：命名、注释、类型
4. 视图、存储过程、函数命名规范

23、如何避免业务数据库表结构变更导致数仓任务大面积报错。

1、表结构变动应提前沟通，确定上下游影响范围后进行统一调整变更。
2、抽取时避免采用select * 全表抽取，抽取粒度应该精确到字段层面。
3、对业务数据库表进行变更监控，根据表信息模板与现表结构进行校验，监控到结构变动后立即通知或告警。

24、模型设计的思路？业务驱动？数据驱动？

构建数据仓库有两种方式：自上而下、自下而上

自上而下指的是数据源出发，一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图。要从整个企业的环境入手，建立数据仓库，要做很全面的设计。偏数据驱动

自下而上指的是从业务需求出发，认为数据仓库应该按照实际的应用需求，加载需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期短，用户能很快看到结果。偏业务驱动

25、为什么需要数据仓库建模？

数仓建模需要按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门、完全一致的报表数据。

合适的数据模型，对于大数据处理来讲，可以获得得更好的性能、成本、效率和质量。良好的模型可以帮助我们快速查询数据，减少不必要的数据冗余，提高用户的使用效率。

数据建模进行全方面的业务梳理，改进业务流程，消灭信息孤岛，更好的推进数仓系统的建设。

26、总线架构

维度建模的数据仓库中，有一个概念叫Bus Architecture，中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。

在多维体系结构（MD） 的数据仓库架构中，主导思想是分步建立数据仓库，由数据集市组合成企业的数据仓库。但是，在建立第一个数据集市前，架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实。而开发团队必须严格的按照这个体系结构来进行数据集市的迭代开发。

一致性维度就好比企业范围内的一组总线，不同数据集市的事实的就好比插在这组总线上的元件。这也是称之为总线架构的原因。

实际设计过程中，我们通常把总线架构列表成矩阵的形式，其中列为一致性维度，行为不同的业务处理过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵（Bus Matrix）。

总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础，也建立了一套可以逐步建立数据仓库的方法论。由于总线架构是多维体系结构的核心，所以我们有时就把多维体系结构直接称为总线架构。

27、一致性维度

一致性维度是Kimball的多维体系结构中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。

在多维体系结构中，没有物理上的数据仓库，数据仓库是由物理上的数据集市组合成，是一个逻辑概念。数据集市的建立是可以逐步完成的，多个数据集市组合在一起，成为一个数据仓库。那么如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合到整个数据仓库中，而一致性维度的提出正式为了解决这个问题。

一致性维度的范围是总线架构中的维度，即在多个数据集市中都存在的维度，这个范围的选取需要数据架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。

维度保持一致后，事实表就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉数据探索等操作，同时也就组成了数据仓库。

28、一致性事实

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。 一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。 为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点：第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。
这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。

29、Kimball架构和Inmon架构的区别

Inmon理论，自上而下，数据驱动
（1）自上而下按照主题建立数据仓库，如按照客户、供应商、产品等建立不同的主题。开发过程中每次增加一个主题；
（2）当建立的数据集市是跨多个主题的，需要以整合好的主题数据为基础。

Kimball理论，自下而上，业务驱动。
（1）自下而上，维度建模；
（2）先按照业务主线建立最小粒度的事实表，再建立维度表，形成数据集市，通过“一致维度”能够共同看到不同数据集市的信息；

30、概念模型、逻辑模型、物理模型分别介绍一下？

概念模型设计 , 逻辑模型设计 , 物理模型设计 是数据库及数据仓库模型设计的三个主要步骤

1. 概念模型 概念模型就是在了解了用户的需求 , 用户的业务领域工作情况以后 , 经过分析和总结 , 提炼出来的用以描述用户业务需求的一些概念的东西 ;

1. 该系统的商业目的是什么 , 要解决何种业务场景
2. 该业务场景中 , 有哪些人或组织参与 , 角色分别是什么
3. 该业务场景中 , 有哪些物件参与 ,4. 此外需要具备相关行业经验 , 如核心业务流程 , 组织架构 , 行业术语

1. 逻辑模型 逻辑模型是将概念模型转化为具体的数据模型的过程 , 即按照概念结构设计阶段建立的基本 E-R 图 , 按选定的管理系统软件支持的数据模型 (层次/网状/关系/面向对象) , 转换成相应的逻辑模型 , 这种转换要符合关系数据模型的原则 ;

1. 分多少个主题 , 每个主题包含的实体
2. 每个实体的属性都有什么
3. 各个实体之间的关系是什么
4. 各个实体间是否有关系约束

1. 物理模型 物理模型就是针对上述逻辑模型所说的内容 , 在具体的物理介质上实现出来 , 系统需要建立几个数据表 : 业务员信息表 , 客户信息表 , 商品信息表 , 定单表 ; 系统要包括几个功能 : 业务员信息维护 , 客户信息维护 , 商品信息维护 , 建立销售定单 ; 表 , 视图 , 字段 , 数据类型 , 长度 , 主键 , 外键 , 索引 , 约束 , 是否可为空 , 默认值 , 该阶段需完成 :

1. 类型与长度的定义
2. 字段的其他详细定义 , 非空 , 默认值
3. 却准详细的定义 , 枚举类型字段 , 各枚举值具体含义
4. 约束的定义 , 主键 , 外键

31、你认为数据仓库最重要的是什么

数据集成和数据质量
企业的数据通常存储在多个异构数据库中，要进行分析，必须对数据进行一致性整合，整合后才能对数据进行分析挖掘出潜在的价值；
数据质量必须有保障，数据质量不过关，业务方无法高效的使用数据。

32、指标体系建设流程

33、维度建模和范式建模的区别、应用场景