数据仓库与数据湖之间有何区别？

2019独角兽企业重金招聘Python工程师标准>>>

对 OLTP 和OLAP 的区别还可以有一个维度，就是及时性需求。OLTP对事务的及时性需求较高，而OLAP 则不然。 ——曹洪伟

数据仓库一般基于数据库实现，但是为部署和维护上是分离的。数据仓库可以是基于关系数据库实现的，这样的数据仓库被称为ROLAP。数据仓库也可以是基于多维数据结构实现的，这样的数据仓库被称为MOLAP。

03

数据仓库架构

数据仓库是一种体系结构，而不是一种技术。数据仓库最为核心的内容分类两部分：

1. 基于关系数据库的多维建模（RDBMS-based dimensional modeling）
2. 基于数据立方体的OLAP查询（cube-based OLAP）

数据仓库体系结构中还包括前端的查询工具， 表工具和数据挖掘工具，被称为front-end。

最后也是最重要的是，数据仓库体系结构中都会包含一个构建数据仓库的元数据仓库。

元数据仓库包括数据库schema，view，用于ETL的metadata，用于数据聚合的metadata，用于 表呈现的metadata和SQL模板等。数据仓库往往采用meta data driven的架构设计，这个元数据仓库就至关重要。

上文中提到的维度的概念。维度(dimension)是观察事物的角度，也是数据库事实表中用来描述数据分类的层次结构。维度在数据中就是表示为列，在SQL中用作过滤和分组。

像上图这样对数据进行多个维度的抽象并借助于数据库的select，group by等基本操作形成的OLAP多维数据操作（roll up，drill down，slice and dice，pivot）被称为多维数据模型。

为了方便复杂分析和可视化呈现，数据仓库中数据往往以多维模型建模。每一个维度被称为一个层级，三个维度构成一个数据立方体。维度也通常用来过滤和分组，所以数据立方体称之为group by的并。

OLAP也被称为在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。

04

数据立方体

数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度。

但一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了与传统关系型数据库的二维表区别开来，于是就有了数据立方体的称呼(见下图)。

另外一个常见的数据库设计方法是“雪花模型”。雪花模型通过定义单独的维度表，改进了星型模型中没有明确提供维度层级的问题。是谓维度表的正则化，如下图。但星型模型更适合浏览维度层级。

因此，数据仓库被认为是对数据库查询性能问题的一个解决方案。在90年代，人们已经都面临一个数据爆炸的挑战，为了解决那个时代的“大数据”问题，数据仓库应运而生。

在1980s早期，大数据是指数据集超出了磁带机的处理能力。 在1990s，大数据是指数据集超出了Microsoft Excel或者桌面PC的处理能力。 今天，大数据是指数据集超出了关系数据库的处理能力。

站在大数据时代回望数据架构的发展历史，然后从技术的角度思考大数据的定义：

当前流行的技术处理不了的数据，都是大数据。

数据仓库的本质是把数据变小，一般有两个方法：

第一是通过抽取，转换，加载，清洗。

第二是通过pre-aggregation获得数据的一份单独拷贝。因此数据仓库被定义为：

为了方便查询分析，把数据从关系数据库中单独拷贝一份出来，然后通过ETL或者ELT转换。

对于大数据，仅仅简单构建一个数据仓库是不够的。数据应该如何结构化才能更便于分析据库和分析工具应该如何设计才能更高效的处理大数据/p>

意识到大数据固有的时间属性和空间属性，是我们理解关系数据库处理大数据时存在性能问题的重要前提。

如果说数据是我对世界的观察记录的话，大数据是我们对世界在时间和/或空间维度的重复观察。这就是大数据的时空特点，也是数据仓库多维模型的构建原理。

当今的主流数据库模型是关系数据库，并且该模型显式地忽略表中的行的顺序。这将不可避免导致应用以非顺序的方式查询数据。

在这种情况下，传统的数据架构可以通过引入缓存的方式缓解性能问题，而大数据则会大大放大了次优访问模式对性能的影响。

如下图所示随机访问和顺序访问的差别。

我有一个看法，NoSQL的键值存储即是用极简的非结构化来实现结构化存储的逆规范化。

键值存储是极简的结构化，也是极简的非结构化。

关于顺序存储，不可更改数据集，可以参考Pat Helland《Immutability Changes Everything》，和我上面的介绍是一致的。

关于传统关系数据库的讨论还有数据库知名专家，2015年图灵奖得主Michael Stonebraker撰写的《One Size Fits All》，分别从数据仓库和流处理两个方面探讨了数据库25年来一招不变的灵丹妙药已经不再适合现在的业务发展。

文章的中心思想和Pat Helland提出lambda架构也有异曲同工之妙。

上面的讨论是架构的微观考虑，让我们回到大数据架构的宏观指导上来。

目前业界对大数据的一个共识的定义是5个V。如下图所示。

传统的OLAP 而言，实时性需求不明显，实时分析的强需求是导致大数据技术的一个原因。 ——曹洪伟

基于此，我个人推荐的大数据架构是BDAS, the Berkeley Data Analytics Stack。这个架构中不仅包含上面提到的三个思考维度，还提供了整个大数据架构blueprint。内容很多，使用时各个击破，在此不赘述。

和数据仓库对比来看，数据仓库是高度结构化的架构，数据在转换之前是无法加载到数据仓库的，用户可以直接获得分析数据。而在数据湖中，数据直接加载到数据湖中，然后根据分析的需要再转换数据。

总结起来，数据湖架构有一下几个显著的特点：

1. 数据存储：大容量低成本
2. 数据保真度：数据湖以原始的格式保存数据
3. 数据使用：数据湖中的数据可以方便的被使用
4. 延迟绑定：数据湖提供灵活的，面向任务的数据绑定，不需要提前定义数据模型

电信运营数据的特点是数据多样化要求不高，大多数数据是结构化数据，数据容量要求不是特别高，数据的实时处理要求最高。

09

演进路径实践

现在的架构是一个典型的数据仓库架构。如下图所示。现在的架构设计有以下几个要点：

• ROLAP：基于Oracle数据库，但并没有用Oracle的数据仓库，单独构建数据仓库。
• Schema设计：主要有两类表：原始数据表和聚合表； 每类表都有三层结构：表，用作聚合的视图，用作 表的视图。不同的应用使用不同的视图来操作数据。当原始的数据表结构变化时，可以根据需要更改不同层次的视图。
• Schema的演化。这是一个比较大的主题，关系数据是schema on write的，任何列的增加都需要alter表结构，这会带来客户系统很长时间的downtime。因此原始表采用1000列的设计（Oracle支持的最大列数），并且列只增加，不减少，避免了数据库schema的变化，降低不同release之间migration的成本。
• 数据存储：定期清除原始数据，只保留聚合数据。

传统 SQL 基于云平台重新定义为 NewSQL，那么 Data Warehouse 也可以重新定义 New Data Warehouse。 ——曹洪伟

这样的架构是不是New Data Warehouse，我不知道，可能是。在这样的架构下，最大的变化就是更换Oracle数据为HDFS，并使用SQL on Hadoop（比如Hive SQL，Spark SQL）等保持SQL接口，维持了前端分析引擎的不变。Meta Data部分依然保持了原来的数据建模，并没有改变数据集成方式。这样的架构继承了经典的仓库架构，提高系统扩展性，在满足业务需求的同时，最大化的保护已有投资。

在架构演进这个过程中，有一些lesson learned：

• SQL on Hadoop是必须的。客户希望保持SQL接口的连续性。
• 混合数据仓库架构：针对不同的业务采用不同存储方案（Oracle 和 HDFS），数据量大的采用HDFS存储，数据量不够大的（不存在扩展性挑战的）可以依然使用关系型数据库。
• 逆规范化对性能的影响重大。通过对逆规范设计，可以达到关系数据库的查询性能。但是对于逆规范化是否存在其他影响，还需要研究。
• 相对于sequence files 和RC files，ORC文件格式的性能是最好的。
• 实时pipe使用storm和Kafka实现。

就像 NewSQL 那样，可以有 New Data Warehouse 的。就是 Data Warehouse与云计算的融合，即数据仓库的存储层在云平台，采用分布式系统。 对应用侧而言， 原有的方式依旧有效，这样就不会资产浪费，而是有效的继承， 也是通往数据湖的一个较稳妥的步骤。 ——曹洪伟

老曹这么一说，豁然开朗。我们在谈数据仓库架构向大数据架构演进的时候，其实我们在谈New Data Warehouse架构。

就像当初数据仓库的出现是对数据库系统存在的限制进行补充一样，目前的大数据平台是对数据仓库系统存在的问题进行补充。

他们的技术思路，技术架构，用户需求某种程度上是一致的，或者说核心的思想是一致的。不一致的地方仅仅是为了满足性能而做的技术方案的调整。

首先看数据集成架构。如下图，基于Hadoop的数据集成架构和基于关系数据库的传统数据集成架构是一致的。

不同地方在于由于数据量的增大，左边的架构采用具有逆正则化（逆规范化）和顺序存储，不可更改数据集等特点的Hadoop平台存储数据。

所以MapRdecue的核心思想就是在数据分片的基础上把数据仓库中的group-by-aggregation操作转换成分布式执行，MapRdecue和传统数据仓库的思想是一致的。

The Map-Reduce programming model provides a good abstraction of group-by-aggregation operations over a cluster of machines. The programmer provides a map function that performs grouping and a reduce function that performs aggregation. The underlying run-time system achieves parallelism by partitioning the data and processing different partitions concurrently using multiple machines.

所谓创新，继承和发展，大概如此吧。怪不得Michael Stonebraker撰文《MapReduce: A major step backwards》指出MapReduce是一个巨大倒退，并引发了他和DeWitt之间的大论战。

Google在2010年还为MapRdecue申请了专利，但我认为MapReduce不算是重大基础性创新，本质上还是云时代的数据仓库技术（New Data Warehouse）。但其作为Google三架马车的风头让人们大大忽略了传统数据仓库的技术思想，误导了很多年轻学子的技术崇拜。

A giant step backward in the programming paradigm for large-scale data intensive applications. Not novel at all — it represents a specific implementation of well known techniques developed nearly 25 years ago. To draw an analogy to SQL, map is like the group-by clause of an aggregate query. Reduce is analogous to the aggregate function (e.g., average) that is computed over all the rows with the same group-by attribute.

在New Data Warehouse架构的基础上，如何向Data Lake演进电信行业来说，NFV和SDN正在推动电信 络设备控制平面和数据平面的分离，电信设备数据会走向数据湖架构。

电信设备数据融合，运营数据融合，最终会走向一个大融合。总结起来，电信大数据对于数据湖架构的拥抱，来自于以下四个方面的驱动。我用四个推导公式，如下：

• 5G->BigData (Semi-Structured and Unstructured) -> Modern Data Architecture for Enterprise -> Data Lake Storage Architecture -> Data Lake
• Cloud -> Network Function Cloudification -> Network Function Virtualization -> stateless VNF -> Distributed Sharing Storage -> Data Lake
• Distributed analytics -> Data Lake
• Hierarchy architecture -> Flat operations architecture -> Data Lake

我们尝试过在数据加载过程中自学习的产生数据库schema，证明这个思路是可行的。基于结构化的数据，这个过程非常容易。但对于非结构化的数据，还是存在很大的挑战。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表31830 人正在系统学习中 相关资源：Veneer:文件屏蔽软件-开源-其它代码类资源-CSDN文库