数据库 与 数据仓库的本质区别是什么？

我看了下目前的答案，大家从理论层面把数据库和数据仓库的本质区别解释的很全面了。

数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

数据仓库：数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

我尝试着再补充些具体的事例来说明，这样更可以帮助大家更好理解一些。

举个最常见的例子，拿电商行业来说好了。

基本每家电商公司都会经历，从只需要业务数据库到要数据仓库的阶段。

• 电商早期启动非常容易，入行门槛低。找个外包团队，做了一个可以下单的网页前端 + 几台服务器 + 一个MySQL，就能开门迎客了。这好比手工作坊时期。

• 第二阶段，流量来了，客户和订单都多起来了，普通查询已经有压力了，这个时候就需要升级架构变成多台服务器和多个业务数据库（量大+分库分表），这个阶段的业务数字和指标还可以勉强从业务数据库里查询。初步进入工业化。

• 第三个阶段，一般需要 3-5 年左右的时间，随着业务指数级的增长，数据量的会陡增，公司角色也开始多了起来，开始有了 CEO、CMO、CIO，大家需要面临的问题越来越复杂，越来越深入。高管们关心的问题，从最初非常粗放的：“昨天的收入是多少”、“上个月的 PV、UV 是多少”，逐渐演化到非常精细化和具体的用户的集群分析，特定用户在某种使用场景中，例如“20~30岁女性用户在过去五年的第一季度化妆品类商品的购买行为与公司进行的促销活动方案之间的关系”。

这类非常具体，且能够对公司决策起到关键性作用的问题，基本很难从业务数据库从调取出来。原因在于：

1. 业务数据库中的数据结构是为了完成交易而设计的，不是为了而查询和分析的便利设计的。


2. 业务数据库大多是读写优化的，即又要读（查看商品信息），也要写（产生订单，完成支付）。因此对于大量数据的读（查询指标，一般是复杂的只读类型查询）是支持不足的。

而怎么解决这个问题，此时我们就需要建立一个数据仓库了，公司也算开始进入信息化阶段了。数据仓库的作用在于：

1. 数据结构为了分析和查询的便利；


2. 只读优化的数据库，即不需要它写入速度多么快，只要做大量数据的复杂查询的速度足够快就行了。

那么在这里前一种业务数据库（读写都优化）的是业务性数据库，后一种是分析性数据库，即数据仓库。

最后总结一下：

数据库 比较流行的有：MySQL, Oracle, SqlServer等

数据仓库 比较流行的有：AWS Redshift, Greenplum, Hive等

这样把数据从业务性的数据库中提取、加工、导入分析性的数据库就是传统的 ETL 工作。现在也有一些新的方法，这展开说又是另一件事情了，有机会再详细说说。

数据库 Database (Oracle, Mysql, PostgreSQL)主要用于事务处理，数据仓库 Datawarehouse (Amazon Redshift, Hive)主要用于数据分析。

用途上的不同决定了这两种架构的特点不同。

数据库(Database)的特点是：

• 相对复杂的表格结构，存储结构相对紧致，少冗余数据。
• 读和写都有优化。
• 相对简单的read/write query，单次作用于相对的少量数据。

数据仓库(Datawarehouse)的特点是：

• 相对简单的(Denormalized)表格结构，存储结构相对松散，多冗余数据。
• 一般只是读优化。
• 相对复杂的read query，单次作用于相对大量的数据（历史数据）。

用图书表格系统举例子。如果是数据库储存的话，表单的设计如下：

这里有六张表，分别记录了作者，图书，图书种类，发行商以及他们之间的关系。

如果我们把以上数据用数据仓库来存储，表单设计需要对原始表单进行Denormalization。

Denormalization is a strategy used on a previously-normalized database to increase performance. In computing, denormalization is the process of trying to improve the read performance of a database, at the expense of losing some write performance, by adding redundant copies of data or by grouping data. - Denormalization - Wikipedia

现在我们把这个数据库的五张表以Books.Title作为主键，用如下图的脚本Denormalize之后存到数据库仓库中.

-- Denormalization Script -- 
select 
b.id,
b.title,
b.copyright,
b.isbn,
g.genre,
a.firstname as AuthorFirstName,
a.lastname as AuthorLastName,
a.dateofbirth,
a.gender,
p.name as PublisherName
from BOOKS b
left join GENRE g on b.genre = g.id
left join AUTHOR_BOOK_MAP abm on b.id = abm.bookid
left join AUTHORS a on a.id = abm.authorid
left join PUBLISHER_BOOK_MAP pbm on b.id = pbm.bookid
left join PUBLISHER p on p.id = pbm.publisherid;

那么数据仓库中就只剩下一张表，如下图所示。

存储空间对比

很明显，因为在denormalization的过程中，如果存在数据库主表和次表不是一对一的关系，那么最终数据仓库主表或者次表一定会出现重复的数据。所以从存储空间角度讲，相比于数据库紧密的存储结构，数据仓库则存在大量冗余重复的数据。

读写优化对比

• 基本读(Read)操作对比

下图所示的两种查询，一个是找一本书(PrimaryKey)的信息，另一个是找一位作者(Non-Key)所有的作品信息。由于数据库需要利用表之间的关联才能找到所有需要的数据，在效率上会相对低下。相比之下数据仓库把这些关联关系转化成重复数据记录到同一张表上了，查询效率相对就会较高。数据仓库相当于牺牲了空间换取了查询效率。

在数据库里面写这段query的时候，我们需要了解表单的结构与他们之间的关系——这对于做数据报告或者数据分析非常不友好，尤其是在表单结构很复杂的时候（比如表单使用了逻辑树的储存结构）。这时候数据仓库简单明了的Denormalized表单结构就对于生成数据报告就非常有优势了。

除此之外，由于数据报告和数据分析常常涉及到大规模的查询，这些查询很可能会占用很高的CPU资源，从而可能影响到数据库的常规读写操作——因为数据库常常是Single-Instance的（接下来会提到）；这一点上数据仓库的Multi-instances的结构就不会有太多这个问题。

• 大数据读(Read)操作对比

当数据量非常大的时候，特定条件下的数据仓库的读优化所带来的优势就开始碾压数据库了。大部分的数据库都是Single-instance的，而数据仓库则是Multi-instances的distributed system。数据仓库在分配储存的节点的时候是根据PrimaryKey/PartitionKey来分配的，查询的时候不仅根据查询键的值来搜索对应节点位置，同时进行大量的并行查询。这使得在对大数据进行查询的时候有极大的优势。

但是，并不是所有的读操作，数据仓库一直都有优势。比如在如下两种情况时，数据仓库的读表现并不如数据库：

1. 在对小量数据进行读取操作的时候，由于数据仓库要进行找Node的location之类的预运算，整体效率上反倒不如数据库。
2. 如果读取操作的目标不是主键(PrimaryKey)或者分配键(PartitionKey)，那么数据仓库的查询也需要进行全局扫描，效率上就不好说是否胜过数据库了。

这两点也是为什么现在即使有像Amazon Redshift这般强大的Datawarehouse应用，SQL Database仍然无法被取代的一部分主要原因。

• 写(Write)操作对比

大多数情况下，数据仓库不太会进行精确的写操作。因为冗余行数太多，有时候只是改一个很小的字段，也会修改大量的行数。而对于数据库来说，由于其紧凑的表格结构，写操作就可以非常精细有效了。比如，我需要修改《Java Complete》这本书的版权，从1999改到2002，数据库里面只需要该一行，而数据仓库里面需要改5行。

数据仓库的写操作都是整段(表)刷新或者整段数据插入, 这也和它的用途——做数据分析有关系。由于数据仓库的整表刷新和分布式储存的特质，我们可以通过把PartitionKey设置成数据创建/更新的时间，然后记录一段时间内的历史数据。这对于数据分析以及利用数据进行决策都有重要意义。

虽然这里进行了数据库和数据仓库的对比，但是并不是想得出两者孰优孰劣的结论。实际情况是，很多的架构的存储方案都是数据库和数据仓库一起使用的。下面会介绍一种这类架构的简单例子。

常见相关架构以及数据目录(Data Catalog)

通常的软件架构简化一下就是，用户通过API和数据库交互。

这里如果要直接在数据库上做数据分析，数据监控等等任务的话，会有以下几个问题：

• 数据分析通常涉及大量数据查询，可能会占用太多CPU从而影响软件的基本功能。
• 数据库的表单结构通常比较复杂，需要数据分析人员对DB结构有深入的了解。
• 数据库在进行大量数据查询的时候效率较低。
• 开放数据库访问权限（即便只是读权限），尤其是给外组人员，会有安全隐患。

为了解决以上四个问题，我们可以通过利用脚本，每隔一段时间把数据库里面的所有数据Denormalize到数据仓库里面，在数据仓库里面进行数据分析。根据之前提到的数据仓库的所有的特性（独立不影响业务，表结构简单，读数据速度快，相对安全），这四个问题都可以得到很好的解决。

但是这里还是有一个小问题。如果有很多不同的组需要共享这个Datawarehouse，那么同样他们的脚本可能会相互影响。这里引入一下数据目录(Data Catalog)的概念来解决这个问题。

A data catalog is a metadata management tool designed to help organizations find and manage large amounts of data – including tables, files and databases – stored in their ERP, human resources, finance and e-commerce systems as well as other sources like social media feeds. - https://searchdatamanagement.techtarget.com/definition/data-catalog

通过数据目录储存元数据，然后发布出去让不同组的数据仓库都可以同步这个数据。这样，每个不同组的数据仓库都拿到了同样的Denormalized数据，但是却相互独立开了。

这样一个架构基本上是把做事务处理的数据库和做数据分析的数据仓库解耦了。同时增加了整个系统的可扩展性。

这里只是很浅地探讨了一下两者之间的区别，其实还有很多细节可以深入展开。先暂时写到这里，有想到其他的再更新。Peace!