关于大数据:大数据开发面试之数据仓库

数据仓库的定义？
首先，用于反对决策，面向剖析型数据处理；其次，对多个异构的数据源无效集成，集成后依照主题进行重组，并蕴含历史数据，而且大数据培训寄存在数据仓库中的数据个别不再批改。
数据仓库 (Data Warehouse) 是一个面向主题的 (subject oriented)、集成的(integrated)、绝对稳固的(non-volatile)、反馈历史变动(time variant) 的数据汇合，用于反对管理决策 (decision making support)。
数据仓库和数据库的区别？
从指标、用处、设计来说
• 数据库是面向事物解决的，数据是由日常的业务产生的，常更新；数据仓库是面向主题的，数据起源多样，通过肯定的规定转换失去，用来剖析。
• 数据库个别用来存储以后事务性数据，如交易数据；数据仓库个别存储的历史数据。
• 数据库的设计个别是合乎三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；数据仓库的设计个别不合乎三范式，有利于查问

如何构建数据仓库？
数仓模型的抉择是灵便的，不局限于某种模型办法。
数仓数据是灵便的，以理论需要场景为导向。
数仓设计要兼顾灵活性、可扩展性，要思考技术可靠性和实现老本。
• 系统分析，确定主题。通过与业务部门的交换，理解建设数仓要解决的问题，确认各个主题下的查问剖析要求
• 抉择满足数据仓库零碎要求的软件平台。抉择适合的软件平台，包含数据库、建模工具、剖析工具等
• 建设数据仓库的逻辑模型。确定建设数据仓库逻辑模型的根本办法，基于主题视图，把主题视图中的数据定义转到逻辑数据模型中
• 逻辑数据模型转换为数据仓库数据模型
• 数据仓库数据模型优化。随着需要和数据量的变动进行调整
• 数据荡涤转换和传输。业务零碎中的数据加载到数据仓库之前，必须进行数据的荡涤和转换，保障数据仓库中数据的一致性。
• 开发数据仓库的剖析利用。满足业务部门对数据进行剖析的需要。
• 数据仓库的治理。包含数据库治理和元数据管理。

什么是数据中台？
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台吧数据对立之后，会造成规范数据，再进行存储，造成大数据资产层，进而为客户提供高效服务。
这些服务和企业的业务有较强的关联性，是企业所独有且能复用的，它是企业业务和数据的积淀，其不仅能升高反复建设，缩小烟囱式合作的老本，也是差异化竞争的劣势所在。
数据中台通过整合公司开发工具、买通全域数据、让数据继续为业务赋能，实现数据平台化、数据服务化和数据价值化。数据中台更加侧重于“复用”与“业务”。
数据中台、数据仓库、大数据平台的要害区别是什么？
根底能力上的区别
数据平台：提供的是计算和存储能力
数据仓库：利用数据平台提供的计算和存储能力，在一套方法论领导下建设的一整套的数据表
数据中台：蕴含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的形式对外提供服务和价值。

业务能力上的区别
数据平台：为业务提供数据次要形式是提供数据集
数据仓库：绝对具体的性能概念是存储和治理一个或多个主题数据的汇合，为业务提供服务的形式次要是剖析报表
数据中台：企业级的逻辑概念，提现企业数据产生价值的能力，为业务提供服务的次要形式是数据 API
总的来说，数据中台间隔业务更近，数据复用能力更强，能为业务提供速度更快的服务。数据中台是在数据仓库和数据平台的根底上，将数据生产为一个个数据 API 服务，以更高效的形式提供给业务。数据中台能够建设在数据仓库和数据平台之上，是减速企业从数据到业务价值的过程的中间层。
大数据的一些相干零碎？
数仓设计核心：依照主题域、业务过程，分层的设计形式，以维度建模作为根本理论依据，依照维度、度量设计模型，确保模型、字段有对立的命名标准
数据资产核心：梳理数据资产，基于数据血统，数据的拜访热度，做老本的治理
数据品质核心：通过丰盛的稽查监控零碎，对数据进行预先校验，确保问题数据第一工夫被发现，防止上游的有效计算，剖析数据的影响范畴。
指标零碎：治理指标的业务口径、计算逻辑和数据起源，通过流程化的形式，建设从指标需要、指标开发、指标公布的全套合作流程。
数据地图：提供元数据的疾速索引，数据字典、数据血统、数据特色信息的查问，相当于元数据中心的门户。
如何建设数据中台？
数据中台在企业落地实际时，联合技术、产品、数据、服务、经营等方面，逐渐发展相干工作。
• 理现状。理解业务现状、数据现状、IT 现状、现有的组织架构
• 定架构。确认业务架构、技术架构、利用架构、组织架构
• 建资产。建设贴近数据层、对立数仓层、标签数据层、利用数据层
• 用数据。对数据进行输入、利用。
• 数据经营。继续经营、继续迭代。

中台建设须要有全员共识，由管理层从上往下推动，由技术和业务人员去执行和落地是一个漫长的过程，在施行数据中台时，最艰难的中央就是须要有人推动。
数据湖的了解？
数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、解决、剖析及传输。
数仓最重要的是什么？
集体认为是数据集成。
企业的数据通常是存储在多个异构数据库中的，要进行剖析，必须先要对数据进行一致性整合。
集成整合后才能够对数据进行剖析、开掘数据潜在的价值。
概念数据模型、逻辑数据模型、物理数据模型
概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个次要步骤。
概念数据模型 CDM
概念数据模型是最终用户对数据存储的认识，反映了最终用户综合性的信息需要，以数据类的形式形容企业级的数据需要。
概念数据模型的内容包含重要的实体与实体之间的关系。在概念数据模型中不蕴含实体的属性，也不蕴含定义实体的主键
概念数据模型的指标是对立业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高档次的关系
逻辑数据模型 LDM
逻辑数据模型反馈的是系统分析设计人员对数据存储的观点，是对概念数据模型的进一步的合成和细化。逻辑数据模型是依据业务规定确定的，对于业务对象、业务对象的数据项以及业务对象之间关系的根本蓝图。
逻辑数据模型的内容包含所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，须要进行范式化解决。
逻辑数据模型的指标是尽可能具体的形容数据，但并不思考在物理上如何实现。
物理数据模型 PDM
物理数据模型是在逻辑数据模型的根底上，思考各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的寄存。
物理数据模型的内容包含确定所有的表和列，定义外键用于确认表之间的关系，基于用户的需要可能要进行反范式化等内容。
SCD 的罕用解决形式？
slowly changing dimensions 迟缓变动维度
• 不记录历史变动信息
• 增加列来记录历史变动
• 新插入数据行，并增加对应标识字段来记录历史数据。拉链表。

元数据的了解？
广义来讲就是用来形容数据的数据
狭义来看，除了业务逻辑间接读写解决的业务数据，所有其余用来保护整个零碎运行所须要的数据，都能够较为元数据。
定义：元数据 metadata 是对于数据的数据。在数仓零碎中，元数据能够帮忙数据仓库管理员和数据仓库开发人员不便的找到他们所关怀的数据；元数据是形容数据仓库外部数据的构造和建设办法的数据。依照用处可分为：技术元数据、业务元数据。
技术元数据
存储对于数据仓库技术细节的数据，用于开发和治理数据仓库应用的数据
• 数据仓库构造的形容，包含数据模式、视图、维、层次结构和导出数据的定义，以及数据集市的地位和内容
• 业务零碎、数据仓库和数据集市的体系结构和模式
• 由操作环境到数据仓库环境的映射，包含元数据和他们的内容、数据提取、转换规则和数据刷新规定、权限等。

业务元数据
从业务角度形容了数据仓库中的数据，他提供了介于使用者和理论零碎之间的语义层，使不懂计算机技术的业务人员也能读懂数仓中的数据。
• 企业概念模型：示意企业数据模型的高层信息。整个企业业务概念和互相关系。以这个企业模型为根底，不懂 sql 的人也能做到成竹在胸
• 多维数据模型。通知业务剖析人员在数据集市中有哪些维、维的类别、数据立方体以及数据集市中的聚合规定。
• 业务概念模型和物理数据之间的依赖。业务视图和理论数仓的表、字段、维的对应关系也应该在元数据知识库中有所体现。

元数据管理系统？
元数据管理往往容易被忽视，然而元数据管理是不可或缺的。一方面元数据为数据需求方提供了残缺的数仓应用文档，帮忙他们能自主疾速的获取数据；另一方面数仓团队能够从日常的数据解释中解脱进去，无论是对前期的迭代更新还是保护，都有很大的益处。元数据管理能够让数据仓库的利用和保护更加的高效。
元数据管理性能
• 数据地图：以拓扑图的模式对数据系统的各类数据实体、数据处理过程元数据进行分档次的图形化展现，并通过不同档次的图形展示。
• 元数据分析：血统剖析、影响剖析、实体关联剖析、实体差别剖析、指标一致性剖析。
• 辅助利用优化：联合元数据分析性能，能够对数据系统的利用进行优化。
• 辅助平安治理：采纳正当的平安管理机制来保障系统的数据安全；对数据系统的数据拜访和性能应用进行无效监控。
• 基于元数据的开发治理：通过元数据管理系统标准日常开发的工作流程

元数据管理规范
对于绝对简略的环境，依照通用的元数据管理规范建设一个集中式的元数据知识库
对于比较复杂的环境，别离建设各局部的元数据管理系统，造成分布式元数据知识库，而后通过建设规范的元数据交换格局，实现元数据的集成治理。
数仓如何确定主题域？
主题
主题是在较高层次上将数据进行综合、归类和剖析利用的一个抽象概念，每一个主题根本对应一个宏观的剖析畛域。在逻辑意义上，它是对企业中某一宏观剖析畛域所波及的剖析对象。
面向主题的数据组织形式，就是在较高层次上对剖析对象数据的一个残缺并且统一的形容，能刻画各个剖析对象所波及的企业各项数据，以及数据之间的分割。
主题是依据剖析的要求来确定的。
主题域
从数据角度看（集合论）
主题语通常是分割较为严密的数据主题的汇合。能够依据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定由最终用户和数仓设计人员共同完成。
从须要建设的数仓主题看（边界论）
主题域是对某个主题进行剖析后确定的主题的边界。
数仓建设过程中，须要对主题进行剖析，确定主题所波及到的表、字段、维度等界线。
确定主题内容
数仓主题定义好当前，数仓中的逻辑模型也就根本成形了，须要在主题的逻辑关系中列出属性和零碎相干行为。此阶段须要定义好数据仓库的存储构造，向主题模型中增加所须要的信息和能充沛代表主题的属性组。
如何控制数据品质？
校验机制，每天进行数据量的比对 select count()，早发现，早修复
数据内容的比对，抽样比对
复盘、每月做一次全量
如何做数据治理？
数据治理不仅须要欠缺的保障机制，还须要了解具体的治理内容，比方数据应该怎么进行标准，元数据该怎么来治理，每个过程须要那些零碎或者工具来配合？
数据治理畛域包含但不限于以下内容：数据规范、元数据、数据模型、数据分布、数据存储、数据交换、数据申明周期治理、数据品质、数据安全以及数据共享服务。
模型设计的思路？业务驱动？数据驱动？
构建数据仓库有两种形式：自上而下、自下而上
Bill Inmon 推崇自上而下的形式，一个企业建设惟一的数据中心，数据是通过整合、荡涤、去掉脏数据、规范的、可能提供对立的视图。要从整个企业的环境动手，建设数据仓库，要做很全面的设计。偏数据驱动
Ralph Kimball 推崇自下而上的形式，认为数据仓库应该依照理论的利用需要，架子啊须要的数据，不须要的数据不要加载到数据仓库中。这种形式建设周期短，用户能很快看到后果。偏业务驱动
数据品质治理
数据品质治理是对数据从打算、获取、存储、共享、保护、利用、沦亡生命周期的每个阶段里可能引发的数据品质问题，进行辨认、度量、监控、预警等，通过改善了进步组织的管理水平使数据品质进一步提高。
数据品质治理是一个集方法论、技术、业务和治理为一体的解决方案。放过无效的数据品质管制伎俩，进行数据的治理和管制，打消数据品质问题，从而进步企业数据变现的能力。
会遇到的数据品质问题：数据真实性、数据准确性、数据一致性、数据完整性、数据唯一性、数据关联性、数据及时性
什么是数据模型？
数据模型就是数据组织和存储的办法，通过形象的实体以及实体间分割的模式来表白事实世界中事务的互相关系的一种映射，他强调从业务、数据存取和应用角度正当的存储数据。
为什么须要数据仓库建模？
数仓建模须要依照肯定的数据模型，对整个企业的数据进行采集，整顿，提供跨部门、完全一致的报表数据。
适合的数据模型，对于大数据处理来讲，能够取得得更好的性能、老本、效率和品质。良好的模型能够帮忙咱们疾速查问数据，缩小不必要的数据冗余，进步用户的应用效率。
数据建模进行全方面的业务梳理，改良业务流程，毁灭信息孤岛，更好的推动数仓零碎的建设。
OLAP 和 OLTP 的模型办法的抉择？
OLTP 零碎是操作事物型零碎，次要数据操作是随机读写，次要采纳满足 3NF 的实体关系模型存储数据，在事物解决中解决数据的冗余和一致性问题。
OLAP 零碎是剖析型零碎，次要数据操作是批量读写，不须要关注事务处理的一致性，次要关注数据的整合，以及简单大数据量的查问和解决的性能。

3 范式
每个属性值惟一，不具备多义性
每个非主属性必须齐全依赖于整个主键，而非主键的一部分
每个非主属性不能依赖于其余关系中的属性
数据仓库建模办法？
有四种模型：ER 模型、维度模型、Data Vault 模型、Anchor 模型。用的较多的是维度模型和 ER 模型。
ER 模型
ER 模型用实体关系模型形容企业业务，在范式实践上满足 3NF。数仓中的 3NF 是站在企业角度面向主题的形象，而不是针对某个具体业务流程的实体对象关系的形象。
采纳 ER 模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据依照主题进行相似性整合，并进行一致性解决。
ER 模型特点：
须要全方位理解企业业务数据
施行周期较长
对建模人员要求教高
维度建模
维度建模依照事实表和维度表来构建数仓。
维度建模从剖析决策的需要登程构建模型，为剖析需要服务。重点关注用户如何疾速的实现数据分析，能够直观的反馈业务模型中的业务问题，须要大量的数据预处理、数据冗余，有较好的大规模简单查问的响应性能。
事实表
产生在事实世界中的操作性事件，其产生的可度量数值，存储在事实表中。从最细粒度级别来看，事实表的一行对应一个度量事件。事实表示意对剖析主题的度量。
事实表中蕴含了与各个维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数一直减少，表数据量迅速增长。
维度表
维度示意剖析数据时所用的环境。
每个维度表都蕴含独自的主键列。维度表行的形容环境应该与事实表行齐全对应。维度表通常比拟宽，是扁平型的非标准表，蕴含大量的低粒度的文本属性。
留神：
事实表的设计是以可能正确记录历史信息为准则
维度表的设计是以可能以适合的角度来聚合主题内容为准则
维度建模的三种模式
星形模型：以事实表为核心，所有的维度间接连贯在事实表上。由一个事实表和一组维度表组成。
雪花模型：是对星形模型的扩大。雪花模型的维度表能够领有更细的维度，比星形更标准一点。保护老本较高，且查问是要关联多层维表，性能较低
星座模型：基于多张事实表，多张事实表共享维度信息 *

维度建模步骤：
抉择业务过程
抉择粒度
选定事实表
抉择维度
事实表的类型？
事实表有：事务事实表、周期快照事实表、累积快照事实表、非事实事实表
事务事实表
事务事实表记录的是事务层面的事实，保留的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件产生后产生，数据的粒度通常是每个事务记录一条记录。
周期快照事实表
以具备规律性的、可预感的工夫距离来记录事实。它统计的是距离周期内的度量统计，每个时间段一条记录，是在事务事实表之上建设的汇集表。
累积快照事实表
累积快照表记录的不确定的周期的数据。代表的是齐全笼罩一个事务或产品的生命周期的时间跨度，通常具备多个日期字段，用来记录整个生命周期中的要害工夫点。

非事实型事实表
在维度建模的数据仓库中，有一种事实表叫 Factless Fact Table，中文个别翻译为“非事实型事实表”。在事实表中，通常会保留十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者阐明某些流动的范畴。上面举例来进行阐明。
第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校须要对学生按学期进行跟踪。维度表包含学期维度、课程维度、系维度、学生维度、注册业余维度和获得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为 1。这样的事实表能够答复大量对于大学开课注册方面的问题，次要是答复各种状况下的注册数。
第二类非事实型事实表是用来阐明某些流动范畴的事实表。例如：促销范畴事实表。通常销售事实表能够答复如促销商品的销售状况，然而对于那些没有销售进来的促销商品没法答复。这时，通过建设促销范畴事实表，将商场须要促销的商品独自建设事实表保留。而后，通过这个促销范畴事实表和销售事实表即可得出哪些促销商品没有销售进来。这样的促销范畴事实表只是用来阐明促销流动的范畴，其中没有任何事实度量。
事实表中通常要保留度量事实和多个维度外键，度量事实是事实表的关键所在。
非事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或阐明某些流动的范畴。
第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件。
第二类非事实型事实表是用来阐明某些流动范畴的事实表。例如：促销范畴事实表。
数仓架构为什么要分层?
• 分层能够清晰数据结构，应用时更好的定位和了解
• 不便追踪数据的血缘关系
• 标准数据分层，能够开发一些通用的中间层数据，可能缩小极大的反复计算
• 把简单问题简单化
• 屏蔽原始数据的异样。不用改一次业务就从新接入数据

数据分层思维？
实践上数据分为：操作数据层、数据仓库层、数据服务层。可依据须要增加新的档次，满足不同的业务需要。
操作数据层 ODS
Operate Data Store 操作数据存储。数据源中的数据通过 ETL 后装入 ODS 层。
ODS 层数据的起源个别有：业务数据库、日志、抓取等。
数据仓库层 DW
依据 ODS 层中的数据依照主题建设各种数据模型。
DW 通常有：DWD、DWB、DWS
DWD: data warehouse detail 细节数据层，是业务层和数据仓库的隔离层。
DWB: data warehouse base 根底数据层，存储的是主观数据，个别用作于中间层。
DWS: data warehouse service 服务数据层，整合汇总剖析某个主题域的服务数据。个别是大宽表。
数据服务层 / 应用层 ADS
该层次要提供数据产品和数据分析应用的数据，个别会放在 ES、Mysql 零碎中供线上零碎应用
数仓架构进化
经典数仓架构：应用传统工具来建设数仓
离线大数据架构：开始应用大数据工具来代替经典数仓中的传统工具
Lambda 架构：在离线大数据架构的根底上，应用流解决技术间接实现实时性较高的指标计算
Kappa：实时处理变成了次要的局部，呈现了以实时处理为外围的 kappa 架构
离线大数据架构
数据源通过离线的形式导入离线数仓中。上游利用依据业务需要抉择获取数据的形式
Lambda 架构
在离线数仓的根底上减少了实时计算的链路，并对数据源进行流式革新，实时计算去订阅音讯队列，并推送到上游的数据服务中去。
Lambda 架构问题：同样的需要须要开发两套一样的代码；资源占用增多
Kappa 架构
kappa 架构能够认为是 lambda 架构的简化版，移除了 lambda 架构中的批处理局部。
在 kappa 架构中，需要批改或者历史数据重新处理都通过上游重放实现
kappa 架构最大的问题是流式重新处理历史数据的吞吐能力会低于批处理，但能够通过减少计算资源来补救
总结
实在场景中，是 lambda 架构和 kappa 架构的混合。大部分实时指标通过 kappa 架构计算，大量要害指标用 lambda 架构批量计算
随着数据多样性的倒退，数据库这种提前规定 schema 的模式显得力不从心。这时呈现了数据湖技术，把原始数据全副缓存到某个大数据存储上，后续剖析时依据需要去解析原始数据。简略来说，数据仓库模式是 schema on write，数据湖模式是 schema on read
OLAP 简介
OLAP（On-line Analytical Processing），联机剖析解决，其次要的性能在于不便大规模数据分析及统计计算，对决策提供参考和反对。
特点：数据量大、高速响应、灵便交互、多维分析
OLAP 分类
存储类型分类
ROLAP（RelationalOLAP）
MOLAP（MultimensionalOLAP）
HOLAP（HybridOLAP）
解决类型分类
MPP 架构
搜索引擎架构
预处理架构
开源 OLAP 解决方案
• Persto、SparkSQL、Impala 等 MPP 架构和 ROLAP 的引擎
• Druid 和 Kylin 等预处理架构和 MOLAP 的引擎
• ES 这种搜索引擎架构
• ClickHouse 及 IndexR 这种列式数据库

OLAP 引擎
Presto
Facebook 开发的分布式大数据 SQL 查问引擎，专门进行疾速数据分析
特点
• 能够将多个数据源的数据进行合并，能够逾越整个组织进行剖析
• 间接从 HDFS 读取数据，在应用前不须要大量的 ETL 操作

查问原理
齐全基于内存的并行计算
流水线
本地化计算
动静编译执行打算
小心应用内存和数据结构
类 BlinkDB 的近似查问
GC 管制
Druid
Druid 是一个用于实时查问和剖析的分布式实时处理零碎，次要用于广告剖析，互联网广告监控、度量和网络监控
特点
• 疾速的交互式查问——Druid 的低提早数据摄取架构容许事件在它们创立后毫秒内可被查问到。
• 高可用性——Druid 的数据在零碎更新时仍然可用，规模的扩充和放大都不会造成数据失落；
• 可扩大——Druid 已实现每天可能解决数十亿事件和 TB 级数据。
• 为剖析而设计——Druid 是为 OLAP 工作流的探索性剖析而构建，它反对各种过滤、聚合和查问

利用场景
• 须要实时查问剖析
• 具备大量数据时，如每天数亿事件的新增、每天数 10T 数据的减少；
• 须要一个高可用、高容错、高性能数据库时。
• 须要交互式聚合和疾速探索大量数据时

Kylin
Kylin 是提供与 Hadoop 之上的 SQL 查问接口及多维分析能力以反对超大规模数据