数据仓库总结

数据仓库的基本架构 | 人人都是产品经理

https://zhuanlan.zhihu.com/p/68666354https://zhuanlan.zhihu.com/p/68666354

数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision-Support）。

数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。

数据仓库的趋势：

• 实时数据仓库以满足实时化&自动化决策需求；
• 大数据&数据湖以支持大量&复杂数据类型（文本、图像、视频、音频）；

ERP、SCM、CRM等系统的区别和联系 - 知乎

ERP(Enterprise Resource Planning)，中文是企业资源计划（系统），是基于计算机技术和管理科学的最新发展，从理论和实际两个方面，提供企业（以服装行业为代表）整体经营管理解决方案。

SCM(Supply Chain Management)，中文是供应链管理（系统），是对供应链上从供应商、生产厂家、分销商到零售商等的物流进行计划和控制，让生产资料以最快的速度，通过生产、分销环节变成增值的产品，最后到达有消费需求的消费者手中。

CRM(Customer Relationship Management )，中文名是客户关系管理（系统），是通过不断加强与顾客交流、不断了解顾客需求、不断对产品及服务进行改进和提高，以满足顾客的需求的连续的过程。

数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用

数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extract, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

ETL的是 Extract-Transform-Load 的缩写，用来描述将数据从来源迁移到目标的几个过程：

• Extract，数据抽取，也就是把数据从数据源读出来。
• Transform，数据转换，把原始数据转换成期望的格式和维度。如果用在数据仓库的场景下，Transform也包含数据清洗，清洗掉噪音数据。
• Load 数据加载，把处理后的数据加载到目标处，比如数据仓库。

为什么要面向主题？面向主题是数据仓库的第一特性，主要是指合理地组织数据以实现分析。对于源数据而言，其数据组织形式是多样的，像点击流的数据格式是未经优化的，前台数据库的数据是基于OLTP操作组织优化的，这些可能都不适合分析，而整理成面向主题的组织形式才是真正地利于分析的，比如将点击流日志整理成页面（Page）、访问（Visit或Session）、用户（Visitor）三个主题，这样可以明显提升分析的效率。

数据仓库中的数据是按照一定的主题域进行组织的，每一个主题对应一个宏观的分析领域，数据仓库排除对决策无用的数据，提供特定主题的简明视图。

如何构建数据仓库？

1). 前期业务调研 需求调研 数据调研 技术选型

2). 提炼业务模型，总线矩阵，划分主题域；

3). 定制规范 命名规范、开发规范、流程规范

4). 数仓架构分层

5）选择合适的数据模型，不同的行业涉选取的模型近不相同，合适的模型，更利于在数据存储，计算，开发，安全，以及数据查询的效率，更能体现数仓的价值。

数仓最重要的是什么？

答：数据的准确性，鄙人记得在一个统计网站上看过，好多数仓因为数据不准确被终止。

    数据的真正价值在于数据驱动决策，通过数据指导运营,在一个不准确的数据驱动下，结果可想而知。

如何保证数据的准确性？

    元数据的建设与管理是其中重要的一个环节

    元数据建设的目标是打通数据接入到加工 ，再到数据消费整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量。

    首先梳理清楚元仓底层数据，对元数据做分类，如计算元数据、存储元数据、质量元数据等，减少数据重复建设，保障数据的唯一性。

另外， 要丰富表和字段使用说明，方便使用和理解。根据元仓底层数据构建元仓中间层，建设元数据基础宽表，也就是元数据中间层，打通从数据产生到消费整个链路。

也可在粒度、规范等方面展开，见仁见智。

传统数仓的程度（建模工具、ETL工具、BI报表工具、调度系统）

建模工具：powerDesiger、Erwin、Visio

ETL工具: kettle/informatic（主流的两款） 等等

BI报表工具:superset、cboard、redash、帆软BI/QuickBI/PowerBI 等等

调度系统：airflow、azkaban、ooize、xxl-job、dolphinscheduler、Zeus、hera、TASKCTL/自研平台 等等

传统数仓和大数据数仓的异同？有哪些大的变化？

其区别主要数数仓数据存储的地方不同，传统数仓数据存储在mysql/oracle等关系型数据库上，大数据数仓存储在hadoop平台的hive中（实际上是HDFS中），当然也有其他的数仓产品比如TD、greenplum等。

数据仓库基于维护细节数据的基础上在对数据进行处理，使其真正地能够应用于分析。主要包括三个方面：

数据的聚合：这里的聚合数据指的是基于特定需求的简单聚合（基于多维数据的聚合体现在多维数据模型中），简单聚合可以是网站的总Pageviews、Visits、Unique Visitors等汇总数据，也可以是Avg. time on page、Avg. time on site等平均数据，这些数据可以直接地展示于报表上。

多维数据模型：多维数据模型提供了多角度多层次的分析应用，比如基于时间维、地域维等构建的销售星形模型、雪花模型，可以实现在各时间维度和地域维度的交叉查询，以及基于时间维和地域维的细分。所以多维数据模型的应用一般都是基于联机分析处理（Online Analytical Process, OLAP）的，而面向特定需求群体的数据集市也会基于多维数据模型进行构建。

        星型模型和雪花模型 在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。

星型模型：当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。每个维表中都会有一个维作为主键，所有这些维的主键结合成事实表的主键。事实表的非主键属性称为事实，它们一般都是数值或其他可以进行计算的数据。

雪花模型：当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的" 层次" 区域，这些被分解的表都连接到主维度表而不是事实表。例如，将地域维表又分解为国家，省份，城市等维表。它的优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

星座模型：星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式。 前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

星座模型主要有以下两大作用：共享维度和设置细节/聚集事实表。

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

维度建模的关键在于明确下面四个问题：

1. 哪些维度对主题分析有用？

        本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；

2. 如何使用现有数据生成维表？

                a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；

                b. 维度CUSTOMER和关系CUSTOMER相同；

                c. 维度STORE可由关系STROE和关系REGION连接得到；

                d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；

3. 用什么指标来"度量"主题？

        本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；

4. 如何使用现有数据生成事实表？

        销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；

业务模型：这里的业务模型指的是基于某些数据分析和决策支持而建立起来的数据模型，比如我之前介绍过的用户评价模型、关联推荐模型、RFM分析模型等，或者是决策支持的线性规划模型、库存模型等；同时，数据挖掘中前期数据的处理也可以在这里完成。

事实表和维度表：事实表是数据聚合后依据某个维度生成的结果表。

数据仓库的数据应用

报表展示：上数据报表几乎是每个数据仓库的必不可少的一类数据应用，将聚合数据和多维分析数据展示到报表，提供了最为简单和直观的数据。

即席查询：理论上数据仓库的所有数据（包括细节数据、聚合数据、多维数据和分析数据）都应该开放即席查询，即席查询提供了足够灵活的数据获取方式，用户可以根据自己的需要查询获取数据，并提供导出到Excel等外部文件的功能。

（即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。 即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。）

数据分析：数据分析大部分可以基于构建的业务模型展开，当然也可以使用聚合的数据进行趋势分析、比较分析、相关分析等，而多维数据模型提供了多维分析的数据基础；同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。

数据挖掘：数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开，但大多数时候数据挖掘会直接从细节数据上入手，而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口。

元数据管理

元数据（Meta Date），其实应该叫做解释性数据，即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。

最后做个Ending，数据仓库本身既不生产数据也不消费数据，只是作为一个中间平台集成化地存储数据；数据仓库实现的难度在于整体架构的构建及ETL的设计，这也是日常管理维护中的重头；而数据仓库的真正价值体现在于基于其的数据应用上，如果没有有效的数据应用也就失去了构建数据仓库的意义。

数据仓库架构

数据仓库标准上可以分为四层：ODS（临时存储层）、PDW（数据仓库层）、DM（数据集市层）、APP（应用层）。

1）ODS层：Operational Data Store 操作型数据存储

为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存；

特征：

• ODS直接存放从业务抽取过来的数据，这些数据从结构和数据上与业务系统保持一致，降低了数据抽取的复杂性。
• 转移一部分业务系统的细节查询功能，因为ODS存放的数据与业务系统相同，原来有业务系统产生的报表，现在可以从ODS中产生。
• 完成数据仓库中不能完成的功能，ODS存放的是明细数据，数据仓库DW或数据集市DM都存放的是汇聚数据，ODS提供查询明细的功能。
• ODS数据只能增加不能修改，而且数据都是业务系统原样拷贝，所以可能存在数据冲突的可能，解决办法是为每一条数据增加一个时间版本来区分相同的数据。

2）PDW层：

DW的数据也是只允许增加不允许删除和修改，数据仓库主要是提供查询服务

为数据仓库层，PDW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。这一层的数据一般是遵循数据库第三范式的，其数据粒度通常和ODS的粒度相同。在PDW层会保存BI系统中所有的历史数据，例如保存10年的数据。

三大范式: 1NF：字段是原子性的，不可分;
         2NF：有主键，非主键字段依赖主键。确保一个表只说明一个事物
         3NF：非主键字段不能相互依赖。 每列都与主键有直接关系，不存在传递的依赖

3）DM层：Data Mart 数据集市

为数据集市层，这层数据是面向主题来组织数据的，通常是星形或雪花结构的数据。从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了。从数据的时间跨度来说，通常是PDW层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几年（如近三年的数据）的即可。从数据的广度来说，仍然覆盖了所有业务数据。

数据集市，以某个业务应用为出发点而建设的局部DW, DW只关心自己需要的数据，不会全盘考虑企业整体的数据架构和应用，每个应用有自己的DM.

特征：

• DM结构清晰，针对性强，扩展性好，因为DM仅仅是单对一个领域而建立，容易维护修改
• DM建设任务繁重，公司有众多业务，每个业务单独建立表。
• DM的建立更多的消耗存储空间，单独一个DM可能数据量不大，但是企业所有领域都建立DM这个数据量就会增加多倍。

4）APP层：

为应用层，这层数据是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。从数据的广度来说，则并不一定会覆盖所有业务数据，而是DM层数据的一个真子集，从某种意义上来说是DM层数据的一个重复。从极端情况来说，可以为每一张报表在APP层构建一个模型来支持，达到以空间换时间的目的数据仓库的标准分层只是一个建议性质的标准，实际实施时需要根据实际情况确定数据仓库的分层，不同类型的数据也可能采取不同的分层方法。

数据仓库DW、ODS、DM概念及其区别_helloxiaozhe的博客-CSDN博客_dw层的概念https://blog.csdn.net/helloxiaozhe/article/details/88599056

数据仓库架构的演变

1. 离线大数据架构

2.  Lambda架构: 离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是Lambda架构。

随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

Lambda架构问题：

• 1.同样的需求需要开发两套一样的代码
  这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
• 2.资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）

3. Kappa架构：实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。

Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构

Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。

在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。

Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

Kappa架构的重新处理过程

重新处理是人们对Kappa架构最担心的点，但实际上并不复杂：

• 1.选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如Kafka，可以保存全部历史数据。
• 2.当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。
• 3.当新作业赶上进度后，应用切换数据源，读取2中产生的新结果表。
• 4.停止老的作业，删除老的结果表。

在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。

Kappa架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。

另外，随着数据多样性的发展，数据仓库这种提前规定schema的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是schema on write，数据湖模式是schema on read。

典型的数仓存储是HDFS/Hive，ETL可以是MapReduce脚本或HiveSQL。

为什么要对数据仓库分层？
1）用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。

2）如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。

3）通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。

数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。

数据湖的本质包含如下四部分：

1、统一的存储系统

2、存储原始数据

3、丰富的计算模型/范式

4、数据湖与上云无关 

​​​​​​数据湖 VS 数据仓库之争？阿里提出大数据架构新概念：湖仓一体-阿里云开发者社区

引擎技术进入收敛期 - 随着Spark（通用计算）、Flink（流计算）、Hbase（KV）、Presto（交互分析）、ElasticSearch（搜索）、Kafka（数据总线）自从2010-2015年逐步占领开源生态，最近5年新引擎开源越来越少，但各引擎技术开始向纵深发展（更好的性能、生产级别的稳定性等）。 

数据建模考虑的点是什么，针对一个业务场景，数据模型大致怎么设计？
单个数据模型表的设计考虑点比较多，首先要明确要做的是哪一层的数据模型表，不同层级的模型在设计时考虑的点是不一样的；

     1.1 如果是底层明细模型，首先它是下游所有数据表的支撑表，在设计时首先要参考和遵守数仓的设计规范，包括数据字段结构，命名等问题，然后需要明确它的数据域、业务过程的划分；然后是它的属性字段需要覆盖全面；其次就是需要关注它的数据质量约束等；

     1.2 如果是汇总层模型，首先要考虑通用性，要明确它是什么分析主题，在该主题下是否有冗余的数据表，它要覆盖下游的的那些应用场景，哪些公共处理逻辑可以下沉；同时还要考虑扩展性和维护成本的平衡等；

     1.3 如果是应用层模型，需要考虑的是它的用户是谁，需求背景是什么，使用方式是什么（eg. adhoc查询，还是面向报表系统，多维分析等）不同的使用方式可能对应的数据表结构是不一样的；其次要明确它的统计粒度，周期，维度，更新频率是怎样的，它的生命周期是怎样的；最后根据需求的复杂程度，还需要评估是构建一张表还是进行纵向拆分为多个模块等等。

对于数据中台的理解，和数据仓库和数据湖的区别
首先，数据中台、数据仓库和数据湖没有直接的关系； 

数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套不断把数据变为资产并服务于业务的机制。数据中台具备4个核心能力：数据汇聚整合、数据转化加工、数据服务可视化、数据价值变现。

数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供分析、决策等功能，可以理解数据仓库是数据中台中的内容资产；

数据湖（DataLake）是一种存储企业的各种原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖是以自然格式存储的数据的系统或存储库，通常是对象Blob或文件，可以存储时不需要对其进行结构化的定义。它与数据仓库的差异是：数据仓库大多存储的是结构化数据，面向数据分析；而数据湖存储的包含结构化数据（关系型系统数据库中的数据），半结构化数据（CSV，日志，XML，JSON）和二进制数据（图像、音频、视频），主要面向深度学习。