Hive数据仓库基本知识

数据仓库的定义
主要用于支持决策，面向分析型数据处理；其次对多个异构成的数据源有效集成，集成后按照主题进行重组，并包含历史数据，而且存放在数据仓库的数据一般不再修改。

面向主题、集成的、相对稳定的、反应历史变化的数据集合，用于支持管理决策

1）数据仓库是用于支持决策、面向分析型数据处理
2）对多个异构的数据源有效集成，集成后按照主题进行分组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。
面对大数据的多样性，在存储和处理这些大数据时，我们就必须要知道两个重要的技术
Hive和Hadoop。当数据为结构化数据，来自传统的数据源，则采用数据仓库技术来存储和处理这些数据

数据仓库和数据库的区别

从目标、用途、设计上来说

1、数据库是面向事务处理的，数据是有日常的业务产生的，常更新；数据仓库是面向主题的，数据来源多样，经过一定的规则转换得到，用来分析
2、数据库一般用来存储当前事务性数据，如交易数据，数据仓库一般存储的历史数据
3、数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；数据仓库的设计一般不符合三范式，有利于查询

如何构建数据仓库
数据模型灵活多变，以实际需求为导向，设计要兼顾灵活性、可扩展性、要考虑技术可靠性和实施成本。
1、系统分析，确定主题
2、选择满足数据仓库的要求的软件平台
3、建立数据仓库的逻辑模型
4、逻辑数据模型转换为数据仓库模型
5、数据仓库数据模型优化。
6、数据清洗转换和传输。
7、开发数据仓库的分析应用。
8、数据仓库的管理

什么是数据中台
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务

这些服务和企业的业务有较强的关联性，是企业独有能复用的，它是企业业务和数据的积淀，不仅能降低重复建设，减少烟囱式协作的成本，也是差异化竞争的优势所在

数据中台通过整合公司开发工具、打通全域数据、让数据持续为业务赋能，实现数据平台化、数据服务化和数据价值化。
数据中台更加侧重于“复用”与“业务”

数据中台、数据仓库、大数据平台、数据胡的关键区别是什么？
1）基础能力上的区别
数据平台：提供的是计算和存储能力
数据仓库：利用数据平台提供的计算和存储能力，在一套方法论的指导下建设的一整套的数据表
数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值
数据湖：一个存储企业级各种原始数据的大型仓库，包括结构化和非结构化数据，其中湖里的数据可供存取、处理、分析和传输
2）业务能力上的区别
数据平台：为业务提供数据只要方式是提供数据集
数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表
数据中台：企业级的逻辑概念，体现企业数据产生价值能力，为业务提供服务的主要方式是数据API
数据湖：数据仓库的来源

总结
数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务，数据中台在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层

大数据有哪些相关的系统
数仓设计中心：按照主题域、业务过程，分层的设计方式，以维度建模作为基本理论依据，按照维度、度量设计模型，确保模型、字段有统一的命名规范

数据资产中心：梳理数据资产，基于数据血缘，数据的访问热度，做成本的治理
数据质量中心：通过丰富的稽查监控系统，对数据进行事后检验，确保问题数据第一时间被发现，避免下游的无效计算，分析数据的影响范围
指标系统：管理指标的业务口径、计算逻辑和数据来源，通过流程化的方式，建立从指标需求、指标开发、指标发布的全套协作流程
数据地图：提供元数据的快速索引，数据字典、数据血缘、数据特征信息的查询，相当于元数据中心的门户

如何建设数据中台

数据中台在企业落地实践时，结合技术、产品、数据、服务、运营等方面，逐步开展相关工作

1）理现状：了解业务现状、数据现状、IT现状、现有的组织架构
2）定架构：确认业务架构、技术架构、应用架构、组织架构
3）建资产：建立贴近数据层、统一数仓层、标签数据层、应用数据层
4）用数据：对数据进行输出、应用
5）数据运营：持续运营、持续迭代

中台建设需要有全员共识，由管理层从上往下推进，由技术和业务人员去执行和落地是一个漫长的过程，在实施数据中台时，最困难的地方就是需要有人推动

数据仓库最重要的是什么
数据集成、数据质量

企业的数据通常存储在多个异构数据库中，要进行分析，必须对数据进行一致性整合，整合后才能对数据进行分析挖掘出潜在的价值

数据质量必须有保障，数据质量不过关，别人怎么使用你的数据

概念模型、逻辑模型、物理模型分别介绍一下
1）概念模型CDM：概念模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，以数据类的方式描述企业级的数据需求
概念模型的内容包括重要的实体与实体之间的关系，在概念模型中不包含实体的属性，也不包含定义实体的主键
概念模型的目的是统一业务概念，作为业务人员和技术人员之间的沟通桥梁，确定不同实体之间的最高层次的关系
2）逻辑模型LDM：逻辑模型反映的是系统分析人员对数据存储的观点，是对概念模型的进一步分解和细化，逻辑模型是根据业务规则确定的，关于业务对象，业务对象的数据项以及业务对象之间关系的基本蓝图
逻辑模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理
逻辑模型的目标是尽可能详细的描述数据，并不考虑物理上如何实现
3）物理模型PDM：物理模型是在逻辑模型的基础上，考虑各种具体的技术实现因素，进行数据体系结构设计，真正实现数据在数据仓库中的存放
物理模型的内容包括确定所有的表和列，定义外键用确认表之间的关系，基于用户的需求可能要进行反范式化等内容
10、SCD常用的处理方式有哪些？
slowly changing dimensions 缓慢变化维度
常见的缓慢变化维处理方式有三种：
1）直接覆盖：不记录历史数据，薪数据覆盖旧数据
2）新加一行数据（纵向扩展）：使用代理主键+生效失效时间或者是代理主键+生效失效标识（保存多条记录，直接新添一条记录，同时保留原有记录，并用单独的专用字段保存）
3）新加两个字段（横向扩展）：一个是previous，一个是current，每次更新只更新这两个值，但是这样职能保留最近两次的变化（添加历史列，用不同的字段保存变化痕迹，因为只保存两次变化记录，使用与变化不超过两次的维度）
11、怎么理解元数据？
1、业务元数据
描述 "数据"背后的业务含义。
主题定义：每段 ETL、表背后的归属业务主题。
业务描述：每段代码实现的具体业务逻辑。
标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。
标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。
不断的进行维护且与业务方进行沟通确认。
2、技术元数据
数据源元数据：例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。
ETL 元数据：
根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。
数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。
数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
数据仓库元数据：
数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式等。
BI 元数据：
汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。
3、管理元数据
管理领域相关，包括管理流程、人员组织、角色职责等。
12、数仓如何确定主题域？
主题是在较高层次上将数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域，在逻辑意义上，他是对企业中某一宏观分析领域所涉及的分析对象。
面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。
主题域通常是联系较为机密的数据主题的集合，可以根据业务的关注度，将这些数据主题划分到不同的主题域（也就是说对某个主题进行分析后确定的主题的边界）。
关于主题域的划分，可以考虑几方面：
1、按照业务或者业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
2、根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
3、按照功能或者应用划分：：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
4、按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；
总而言之，切入的出发点逻辑不一样，就可以存在不同的划分逻辑。在建设过程中可采用迭代方式，不纠结于一次完成所有主题的抽象，可先从明确定义的主题开始，后续逐步归纳总结成自身行业的标准模型。
13、如何控制数据质量？
1）校验机制，每天对比数据量，比如count()早发现，早修复
2）数据内容的比对，抽样对比
3）复盘、每月做一次全量
14、模型设计的思路？业务驱动？数据驱动？
构建数据仓库有两种方式：自上而下、自下而上
Bill Inmon推崇自上而下的方式（这里的上指的是数据源出发），一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图。要从整个企业的环境入手，建立数据仓库，要做很全面的设计。偏数据驱动
Ralph Kimball推崇自下而上的方式（这里的下指的是从业务需求出发），认为数据仓库应该按照实际的应用需求，架子啊需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期短，用户能很快看到结果。偏业务驱动
15、为什么需要数据仓库建模？
数仓建模需要按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门、完全一致的报表数据。
合适的数据模型，对于大数据处理来讲，可以获得得更好的性能、成本、效率和质量。良好的模型可以帮助我们快速查询数据，减少不必要的数据冗余，提高用户的使用效率。
数据建模进行全方面的业务梳理，改进业务流程，消灭信息孤岛，更好的推进数仓系统的建设。
16、数据仓库建模方法有哪些？
维度模型
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
Kimball老爷爷维度建模四个步骤：
选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实
星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
星型模型可以理解为，一个事实表关联多个维度表，雪花模型可以理解为一个事实表关联多个维度表，维度表再关联维度表。
星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。
星座模型是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表，他们之间是否共享一些维度表。
范式模型
即实体关系（ER）模型，数据仓库之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。
特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较长，维护成本高。
Data Vault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
Anchor模型
高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。企业很少使用。
17、数仓架构为什么要分层？
分层可以清晰数据结构，使用时更好的定位和理解
方便追踪数据的血缘关系
规范数据分层，可以开发一些通用的中间层数据，能够减少极大的重复计算
把复杂的问题简单化
屏蔽原始数据的异常，下游任务没有感知异常

数仓分层
分层的作用：逐层解耦，减少重复计算，降低烟囱式开发。越到底层越接近业务发生的记录，越到上层越接近业务目标
1、清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解，实现业务数据解耦
2、减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
3、统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
4、复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定问题
ODS
存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的准备区
作用
1、保持数据原貌不做任何修改，起到备份数据的作用
2、数据采用压缩，减少磁盘存储空间（如：原始数据100G，可以压缩到10G）
3、创建分区表，防止后续的全表扫描
DWD
以业务过程为驱动，基于每个具体的业务特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。同时，为了提高数据明细层的易用性，该层会采用一些维度退手法，将维度退化至事实表中，减少事实表和维表的关联，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性

DIM
根据维度建模中的星型模型思想，将维度进行退化

DWS
对数据做横向的连接，纵向轻度的聚合操作
DM
数据集市，按照主题进行汇总

APP/ADS
数据应用层：针对大主题指标分别进行分析，根据业务具体需求，做对应的统计分析指标

2、步骤
DWD层需要构建维度模型一般采用星型模型，呈现的状态一般为星座模型。维度建模一般按照
选择业务过程 -> 声明粒度 -> 确认维度 -> 确认事实