数据库，数据仓库，数据湖-Toy模板网

这篇具有很好参考价值的文章主要介绍了数据库，数据仓库，数据湖。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

数据仓库四层分层

ODS——原始数据层：存放原始数据
- ODS层即操作数据存储，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入本层；一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。
- ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存；数据在装入本层前需要做以下工作：去噪、去重、提脏、业务提取、单位统一、砍字段、业务判别。
DWD——数据明细层：对ODS层数据进行清洗、维度退化、脱敏等。覆盖所有系统的、完整的、干净的、具有一致性的数据层。
- 该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证，在ODS的基础上对数据进行加工处理，提供更干净的数据。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，当一个维度没有数据仓库需要的任何数据时，就可以退化维度，将维度退化至事实表中，减少事实表和维表的关联。例如：订单id,这种量级很大的维度，没必要用一张维度表来进行存储，而我们一般在进行数据分析时订单id又非常重要，所以我们将订单id冗余在事实表中，这种维度就是退化维度。
DWS——数据服务层：对DWD层数据进行一个轻度的汇总。
- DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，会针对度量值进行汇总，目的是避免重复计算。该层数据表会相对比较少，大多都是宽表(一张表会涵盖比较多的业务内容，表中的字段较多)。按照主题划分，如订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
DM——数据集市层：为各种统计报表提供数据。
- 存放的是轻度聚合的数据，也可以称为数据应用层，基于DWD、DWS上的基础数据，整合汇总成分析某一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据，通常根据业务需求，划分成流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。从数据粒度来说，这层的数据是汇总级的数据，也包括部分明细数据。从数据的时间跨度来说，通常是DW层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几年的即可。从数据的广度来说，仍然覆盖了所有业务数据。
分层的核心思想就是解耦，再解耦，把复杂的问题简单化。也有分三层的，五层的。数据分层是一套让我们的数据体系更有序的行之有效的数据组织和管理方法。数据分层没有绝对标准，当然也不能包治百病，不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：数据仓库面试题——数据仓库分层_牛客网 (nowcoder.com)
- 隔离原始数据：不论是数据的异常还是数据敏感度，使真实数据与统计数据解耦开。
- 数据结构化更清晰：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。
- 数据血缘追踪：提供给外界使用的是一张业务表，但是这张业务表可能来源很多张表。如果有一张来源表出问题了，我们可以快速准确的定位到问题，并清楚每张表的作用范围。
- 增强数据复用能力：减少重复开发，通过数据分层规范化，开发一些通用的中间层数据，能够减少重复计算，提高单张业务表的使用率，提升系统的执行效率。
- 简化复杂的问题：把一个复杂的业务分成多个步骤实现，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
- 减少业务的影响：业务可能会经常变化，这样做就不必改一次业务就需要重新接入数据。
- 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
- 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径。
- 一个公司可能有多个业务系统，而数据仓库就是将所有的业务系统按照某种组织架构整合起来，形成一个仓储平台，也就是数仓。
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
架构是数据仓库建设的总体规划，从整体视角描述了解决方案的高层模型，描述了各个子系统的功能以及关系，描述了数据从源系统到决策系统的数据流程。业务需求回答了要做什么，架构就是回答怎么做的问题。
- 最大满足需求；便于团队沟通；便于进行规划；提高灵活性、生成率；便于维护；便于团队学习蓦_然 - 个人主页动态 - 牛客网 (nowcoder.com)
数据仓库的发展大致经历了这样的三个过程：
- 简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。大部分表现形式为数据库和前端报表工具。
- 数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
- 数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。
数据仓库（Data Warehouse），可简写为DW或DWH。它是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
数据仓库之父比尔·恩门于1990年提出数据仓库（Data Warehouse），数仓主要是为解决企业的数据集成与分析问题。数据仓库主要功能是将OLTP经年累月所累积的大量数据，通过数据仓库特有的数据储存架构进行OLAP，最终帮助决策者能快速有效地从大量数据中，分析出有价值的信息，提供决策支持。自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。
一句话总结：数据仓库存在的意义在于对企业的所有数据进行汇总，为企业各个部门提供统一的，规范的数据出口。数据仓库相比数据库，主要有以下两个特点：
- 数据仓库是面向主题集成的。数据仓库是为了支撑各种业务而建立的，数据来自于分散的操作型数据。因此需要将所需数据从多个异构的数据源中抽取出来，进行加工与集成，按照主题进行重组，最终进入数据仓库。
- 数据仓库主要用于支撑企业决策分析，所涉及的数据操作主要是数据查询。因此数据仓库通过表结构优化、存储方式优化等方式提高查询速度、降低开销。

数据仓库与数据库的对比

维度	数据仓库	数据库
应用场景	OLAP	OLTP
数据来源	多数据源	单数据源
数据标准化	非标准化Schema	高度标准化的静态Schema
数据读取优势	针对读操作进行优化	针对写操作进行优化

数据仓库架构包含三个部分：数据架构、应用程序架构、底层设施。
- 底层设施：底层设施为架构提供了基础，底层设施包括硬件、数据库平台、网络和桌面系统。
  - 硬件：硬件主要指服务器硬件，主要有数据库服务器、ETL服务器、调度服务器、报表服务器、BI门户服务器、接口服务器。
  - 数据库平台分为二大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing），主要有Oracel，MySQL。OLAP是为数据分析而设计的数据库管理系统。主要有Teradata, Greenplum，Hive，Kudu。
  - 桌面系统：数据仓库不同的应用对桌面系统也有不同的要求，开发工具主要有Window、Mac面系统，部署服务器主要有Unix桌面系统，系统BI应用程序主要有Window、Mac、移动设备桌面系统。
  - 网络：网络是底层设施的基础，特别是大数据时代对网络的要求越来越高。
- BI应用程序架构：数据仓库是数据处理的后台，业务用户并不关心后台怎么处理。BI应用是数据呈现的前台，是业务用户进行查询的入口。BI应用程序的体验也是衡量数据仓库是否成功的主要因素。
  - BI分析周期：业务分析从监视活动开始识别某个问题或时机，进而采取行动，最终回到监视该活动产生的结果上来，达到数据驱动业务增长的目的。分析周期把这个过程分为五个不同的阶段。监视活动；识别异常；确定原因的因素；模型供选方案；采取行动并跟踪结果。
  - BI应用分类：
    - 接口查询：数据以接口的形式提供给上下游系统，供上下业务系统进行查询。主要有推和拉二种模式。
    - 即席查询：业务用户根据自己的需求，自定义查询请求，后台自动组织SQL语句访问维度模型。
    - 标准报表：根据业务用户的需求，进行定制报表。
    - 仪表盘：它是向企业展示度量信息和关键业务指标现状的数据可视化工具。
    - 数据挖掘：为数据挖掘工具提供标准基础数据。
    - 运营查询：为了减少业务系统的大数据量查询压力，数据仓库为业务系统提供实时的查询。
  - 数据存储
    - 为了提高查询性能，BI工具需要把数据存储在本地服务器上；
    - OLAP多维模型需要把数据存储成Cube格式；
    - 把数据存储成文件格式，放在其他服务器上
- 数据结构：数据架构主要描述数据从源系统抽取数据，然后经过清洗、规范化、提交形成标准模型，最终提交给业务用户，以及对数据的管理。
  - 源系统：数据仓库一般会面临多个、异构数据源的问题，主要分为结构化，半结构化以及非结构化数据。为了便于管理需要对源系统建立元数据信息。
  - 抽取：因为源系统的多样性，源抽取阶段一般选择使用工具。
  - 数据转换：数据从源系统抽取过来之后，就要进入数据转换阶段。这一阶段是数据仓库开发核心阶段。
    - 数据清洗是制定转换规则，筛选数据并纠正数据的过程。清洗的目的是改进源系统的数据质量，但是不要在数据仓库做过多的清洗，源系统的数据质量应该在源头处理。清洗的主要内容包括：制定数据转换规则；提交错误事实表
    - 规范化就是整合各个源系统的数据，把数据统一命名，统一取值，建立企业标准版本数据。主要内容包括：数据标准化；删除重复数据；数据共存策略
  - 提交：提交就要根据维度模型生成维度表和事实表。提交主要内容包括：
    - - 选择合适的缓慢变化维类型
      - 为维表生成代理键
      - 管理不同粒度的层次维
      - 管理专项维
      - 生成维度桥接表
      - 生成代理键管道
      - 选择合适的事实表类型
      - 处理延迟到达的事实
      - 生成维度表
      - 生成事实表
  - 聚集：聚集是指根据事务事实表进行更高粒度的聚合以及生成相对应的维度表。主要内容包括：
    - 数据聚合
    - 缩小维度表
    - 生成OLAP多维数据集
  - 数据存储：数据存储是指在在数据的生命周期内对数据的管理，主要内容包括：
    - 数据备份；
    - 历史数据归档；
    - ETL过程中数据分层存储
留一个示例理解：阿里数据体系主要分为数据采集、数据计算、数据服务和数据应用四大层次。
- 数据采集层：阿里巴巴建立了一套标准的数据采集体系方案，致力全面、高性能、规范地完成海量数据的采集，并将其传输到大数据平台。数据来源主要有两部分：
  - 业务数据：主要存在数据库中；日志数据：主要来自于日志文件，日志采集技术：Aplus.JS：Web端日志采集技术方案，UserTrack：APP 端日志采集技术方案
  - 消息中间件（离线/实时）：TimeTunnel (TT ）：既包括数据库的增量数据传输，也包括日志数据的传输
  - 数据库同步工具（离线）：直连异构数据库（备库）来抽取各种时间窗口的数据。DataX/同步中心：同步中心是基于DataX易用性封装的
- 数据计算层：数据被整合和计算后，才能被挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。两大体系：
  - 数据存储及计算云平台（离线计算平台（MaxCompute）、实时计算平台（Strea Compute））；数据整合及管理体系：阿里内部称之为“OneData ”，数据整合及管理的方法体系和工具
  - 数据仓库：离线数仓：传统数仓。主要以天（包含小时、周和月）为单位，如T-1，则每天凌晨处理上一天的数据。实时数仓：流式数据。
  - 数仓的建设遵循业界的分层理念，传统的数据加工链路包括以下几层：数据层：Operational Data Store，ODS；明细数据层：Data Warehouse Detail，DWD；汇总数据层：Data Warehouse Summary，DWS；应用数据层：Application Data Store，ADS
  - 数仓不同层次之间的加工实现了数据资产向信息资产的转化，整个过程还进行了有效的元数据管理及数据质量处理。
  - 元数据模型整合及应用：主要包含数据源元数据、数据仓库元数据、数据链路元数据、工具类元数据、数据质量类元数据等。元数据应用主要面向数据发现、数据管理等，如用于存储、计算和成本管理等。
- 数据服务层：目的是数据被整合和计算好之后，可以提供给产品和应用进行消费。
  - 数据服务层以数据仓库整合计算好的数据作为数据源，可以架构在多种数据库之上，如MySQL和HBase等。数据服务层主要通过统一的数据服务平台对外提供数据服务，通过接口服务化方式对外提供数据服务。通过接口堆外提供的数据服务主要包括：简单数据查询服务；复杂数据查询服务；实时数据推送服务
  - 数据服务可以使应用对底层数据存储透明，将海量数据方便高效地开放给各应用使用。
- 数据应用层：数据准备好了，可以提供给其他部门使用，比如索、推荐、广告等应用。
在现在这个时代，数据对于企业而言，已经是一种重要资产。随着企业的不断发展，数据不断堆积，企业希望把生产经营中的所有相关数据都完整保存下来，进行有效管理与集中治理，挖掘和探索数据价值。而数据湖就应运而生。
数据湖是一个集中存储各类结构化和非结构化数据的大型数据仓库，它可以存储来自多个数据源、多种数据类型的原始数据，数据无需经过结构化处理，就可以进行存取、处理、分析和传输。数据湖能帮助企业快速完成异构数据源的联邦分析、挖掘和探索数据价值。
数据湖的本质，是由“数据存储架构+数据处理工具”组成的解决方案。
- 数据存储架构：要有足够的扩展性和可靠性，可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
- 数据处理工具，则分为两大类：
  - 第一类工具，聚焦如何把数据“搬到”湖里。包括定义数据源、制定数据同步策略、移动数据、编制数据目录等。
  - 第二类工具，关注如何对湖中的数据进行分析、挖掘、利用。数据湖需要具备完善的数据管理能力、多样化的数据分析能力、全面的数据生命周期管理能力、安全的数据获取和数据发布能力。如果没有这些数据治理工具，元数据缺失，湖里的数据质量就没法保障，最终会由数据湖变质为数据沼泽。

数据仓库和数据湖的不同类比于仓库和湖泊：仓库存储着来自特定来源的货物；而湖泊的水来自河流、溪流和其他来源，并且是原始数据。数据湖与数据仓库的对比

维度	数据湖	数据仓库
应用场景	可以探索性分析所有类型的数据，包括机器学习、数据发现、特征分析、预测等	通过历史的结构化数据进行数据分析
使用成本	起步成本低，后期成本较高	起步成本高，后期成本较低
数据质量	包含大量原始数据，使用前需要清洗和标准化处理	质量高，可作为事实依据
适用对象	数据科学家、数据开发人员为主	业务分析师为主

数据仓库特点
- 数据仓库是面向主题的：数据仓库中的数据是按照一定的主题域进行组织的，每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据，提供特定主题的简明视图。
- 数据仓库是集成的：数据仓库中的数据不是一开始就是在里面的，而是从各个分散的数据库中抽取出来的。但是有一个问题，就是这些来自不同数据库的数据会有重复和不一样的地方，如字段的同名异议、异名同义、单位不统一，字长不统一等。所以在集成的过程中，还要对数据进行清洗、规划、去敏等操作。一句话就是，数据仓库是对企业内不同业务部门数据完整集合，而且还是处理过的数据。
- 数据仓库的数据是稳定的：数据仓库中的数据主要是为了给企业做决策时分析使用，涉及的主要是对数据的查询，一般情况下不会对数据进行修改，如果数据仓库中的历史数据超过存储期限，则会直接删除。因为数据仓库涉及的操作主要是查询，所以它的系统要比数据库简单很多，但是数据仓库涉及到查询的数据量一般都很大，所以在数据查询就有更高的要求。一句话记忆，数仓里不存在数据的更新和删除（不是指数据到期的删除）操作。
- 数据仓库中的数据是随时间变化而变化的：数据仓库中的数据不可更新是针对应用来说的，也就是说，数据仓库的用户进行分析处理是不进行数据更新操作的。但并不是说，在从数据集成输入数据仓库开始到最后被删除的整个生存周期中，所有的数据仓库数据都是永远不变的。数据仓库的数据是随着时间变化而变化的主要表现如下：
  - 数据仓库随着时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库当中去，也就是要不断的生成OLTP数据库的快照，经统一集成增加到数据仓库中去；但对于确实不在变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，而不会对原有的数据库快照进行修改。
  - 数据库随着时间变化不断删去旧的数据内容。数据仓库内的数据也有存储期限，一旦过了这一期限，过期数据就要被删除。
  - 数据仓库中包含有大量的综合数据，这些综合数据中很多跟时间有关，如数据经常按照时间段进行综合，或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行从新综合。因此数据仓库的数据特征都包含时间项，以标明数据的历史时期。
  - 一句话理解，数仓里会完整的记录某个对象在一段时期内的变化情况。

数据库设计范式

关系数据库中关系是要满足一定要求的，满足不同程度要求成为不同的范式。范式共有1NF-5NF共6中（其中BC范式是3范式的补充）。各个范式之间的关系可以参考这张图。一个低级范式的关系模式通过模式分解可以转换为若干个高一级的范式的关系模式集合，这个过程叫做规范化。
- 第一范式 1NF：在一张二维表中每一个属性都必须是一个不可分的数据项。满足这个条件的关系模式就是第一范式（1NF）。简单说只要是一张二维的数据表，而且每个表中的字段语义上不可以在拆分了就满足第一范式了。目前大多数场景都是满足第一范式，当然有一些场景可能不满足，例如一个列表字段我们用逗号分隔存储。
- 第二范式 2NF：在第一范式的基础上，每个非主属性完全函数依赖与任何一个候选码，则称为第二范式。就是任何一个候选码，必须对应唯一一个非主属性。例如学生学号作为候选码，姓名作为非主属性这是满足第二范式的。但是学生学号作为候选码，学生成绩作为非主属性，这只满足第一范式（而且连函数依赖都不满足）。
- 第三范式 3NF：在第二范式的基础上，每个非主属性即不传递依赖于码，也不部分依赖于码，则称为第三范式。即每一个非主属性都完全依赖于码而不是，而不是存在传递依赖。例如学号作为码，学号->老师姓名(假定唯一),老师姓名->老师年龄。这种情况就是满足了第二范式但是不满足第三范式了。
- BC范式 BCNF：这是对3NF的扩充和修正。第三范式考虑的是，非主属性间存在传递依赖的关系，但是没有考虑到主属性和码存在传递依赖的关系。BC范式把他修正成了属性间不允许出现传递依赖。
  关系模式R中，若每一个决定个因素都包含码，则他属于BC范式。一个满足BCNF关系模式的有：
  - 所有非主属性对每一个码都是完全函数依赖。
  - 所有主属性对每一个不包含他的码也是完全函数依赖。
  - 没有任何属性完全函数依赖于非码的任何一组属性。
  - 其实BC范式存在的场景就是候选码和主属性存在传递依赖时，就代表候选码交叉后可能出现依赖的情况，这是对3NF的修正。
- 第四范式4NF：关系模式R属于第一范式，如果对于R的每个非平凡多值依赖X->->Y(Y不包含与X)，X都含有码，则该关系为第四范式4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖
- 第五范式5NF：这一块书上并没有很明确的将他的含义，在网上找到了一些相关资料。第五范式(5NF)也称为投影联合范式(PJ / NF) 。它旨在通过以多种格式分隔语义连接的关系来存储多值事实，以最大程度地减少关系数据库中的冗余。简单说就是尽可能拆分R的关系模式，通过连接依赖的方式拆分，最终拆出来的结果不可以是5NF的时候，他就满足5NF了。
  平凡多值依赖X->->Y(Y不包含与X)，X都含有码，则该关系为第四范式4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖
- 第五范式5NF：这一块书上并没有很明确的将他的含义，在网上找到了一些相关资料。第五范式(5NF)也称为投影联合范式(PJ / NF) 。它旨在通过以多种格式分隔语义连接的关系来存储多值事实，以最大程度地减少关系数据库中的冗余。简单说就是尽可能拆分R的关系模式，通过连接依赖的方式拆分，最终拆出来的结果不可以是5NF的时候，他就满足5NF了。文章来源地址https://www.toymoban.com/news/detail-569319.html