先来谈谈架构。

其实，我很反感本质这个词。因为本质这个词，抽象，模糊，不好定性。回答者好心倾囊相授，看的人却以一句“ 你没有明白我的意思，你说的本质和我说的，不一样！我的意思是……”。

要说本质，就要有分门别类的标准，要把抽象细化下来，这非常考验人的形象与归纳思维。人与人之间，理解有偏差，谈话中对方跟不上，就容易造成误解。这种事情太多了。

那么我把这个题目改一改，问，数据库与数据仓库的应用区别是什么？这样就好多了。至少，我们明确了在应用这个方向上，讨论“本质区别”。但事实上，这样问也不够好，还是模糊。这相当于问，“咖啡店与星巴克的区别是什么”。是不是很奇怪，有谁会问这么二的问题呢？

所以我说，问题本身就不够明确。为什么，你往下看就知道了。

既然谈到了应用，那主体肯定是人，只有人，才是应用的驱动体。站在人的角度来看，两者的区别就会清晰很多。

首先，我们来看下，数据的应用有哪些。

第一种应用，我买了电影票：

这类应用，特点都是实时交互，我付了款，立马得到服务。比如购物，餐饮，交通等等。我们称之为 OLTP，也就是传统上所说的“关系型事务数据库”应用。

第二种应用，我用记账本：

这类应用，通常会涉及很长一段时间的数据读取，最终的数据呈现会以多种维度组织，实时性不高，但维度一定不止一位。这类应用属于数据仓库的数据分析细分领域，也称之为 OLAP。

理解了这两类应用后，我们进一步归类。无论是 OLTP 还是 OLAP，其实都是数据库应用，都要以数据库作为存储和处理基础。

OLAP 数据仓库技术，不过是数据库应用中的一种。但数据库和数据仓库是否一定要以关系型事务数据库作为基础呢，不是的。我们接着往下分析。

数据库

刚才我们谈到应用，继而谈到应用的主体，人。那么谈人的时候，有有必要从人经历的历史，来看人的发展。以下是半个世纪来，人们在使用数据库上的历史节点。

刚开始，人们在应用数据需求上，使用各类不同的数据模型，有 Network Model, Hierarchical Model,还有 Relational Model.

比较好理解的是，Hierarchical Model ：

有一对多的层级关系，最适合用来记录上下级关系的数据。比如部门组织架构，会计分录，工业制造常用的BOM(物料清单)等。

接下来，特殊应用就是网络模型(Network Model):

20世纪50年代的计算机应用水平，还没有互联网概念。以现在发达的社交网络来理解网络模型，最合适不过。对，就是平常我们所说的社交网络。

人与人之间的联系，就像一张网。两两认识的朋友，早晚也会成为朋友，用6度人脉来解释，就是你要认识王XX，也只要找到关键的6个人带你。

领衔数据库发展潮流，霸榜半个世纪的理论，是关系型数据库

1970 年开始，关系型数据库论文《大型共享数据库数据的关系模型》在ACM发表了。由此打开了关系型数据库霸榜的序幕。

从1973年开始，数据库厂商都开始以 IBM System R 为蓝本，开发自己的商用版本。比如 Oracle, IBM DB2, SQL Server , PostgreSQL 等等。

以 NoSQL,NewSQL 展开数据库新时代序幕

随着手机，尤其是智能手机，智能平板，互联网应用的发展，关系型数据库在处理这些应用上逐渐吃力，因此 Redis, MongoDB, ElasticSearch 逐渐有了市场。

他们的操作语法，看似和关系型数据库没有相似之处，但在组成架构上却还有些异曲同工，目的是把原来在关系型数据库中不好处理的部分，经过结构规范化，存储优化，索引优化等技术，使得这些非关系型结构化的数据处理，变得更加高效。

并不是说，传统的应用中就没有今天互联网时代的应用，也有的。比如网站的打日志，全网搜索等。

但那个时代并没有那么多流量，没有那么多人来访问应用，所以使用关系型数据库存储和处理这些数据还绰绰有余。但在流量爆发的今天，数据量早已不是当年可比。要存储和处理这些大数据，必须采用新新技术。

比如MongoDB的数据分片，可以把用户操作日志放入操作日志集群中，把搜索日志放入搜索集群中；而用户的搜索，可以单独放入 ElasticSearch 中，使得搜索这种高吞吐量的操作不再占用宝贵的 OLTP 服务器资源。

这些都是传统的关系型数据库在处理今天互联网应用上逐渐吃力的表现。

功能上的缺陷，使得关系型数据库丢失了一部分市场。可真正让厂商焦虑的，是处理 OLTP 事务上的瓶颈。这才是关系型数据库真正感到无力的地方。

比如淘宝每年的双十一，OceanBase 最高峰值达到每秒 6100 万。然而，传统的数据库，依据Oracle 的 TPC-C 打榜数据，只有 300万，完全支撑不住。当然这是 Oracle 2009年的数据，现今的 O 记云，能达到多少 QpmC，我们也不知道。

所以我说，真正让传统的RDBMS厂商感到恐慌的，应该是大吞吐量事务处理的无力。

至此，所有的应用，我们都可以称之为数据库应用。当然，也包括数据仓库。20世纪70年代以来，市场上占据主导地位的，还是关系型数据库。

使用关系型数据库搭建数据仓库，完全顺其自然，也合情合理。Kimball 与 Inmon 最初的数据仓库理论，都以关系型数据库作为底层存储架构。

但 Google 的大数据三驾马车出现后，情况开始变了。

FileSystem, BigTable, MapReduce 的出现，使得大吞吐量的数据仓库不再遥不可及，原先的RDBMS解决方案是利用时间差，来解决复杂查询的效率问题，但在数据量和吞吐量达到单台服务器容量极限后，再多的数据量也就难以负载了。

Google三驾马车的出现，使得多台，甚至千台数据库服务共同计算变成可能。一个人的力量是有限的，但一群人的力量就不可估量了。机器也是一样，关键在于调度。

先讨论早期的数据仓库技术及产品

刚才谈到，关系型数据库技术，早期用来服务银行，航空等行业。这些应用主要的功能是处理数据的输入与输出。能够把数据做到准确，安全，一致，就已经达标了。这系列应用，我们称之为 OLTP(在线联机事务处理)

但，随着输入的增多，输出就成为了瓶颈，最重要的就是数据分析变得吃力，响应需要等待很长时间，而且有时候结果甚至都出不来，还严重拖慢了数据输入的功能。

因此，全世界都意识到，大量数据的分析，应该和数据的输入系统，也就是业务系统分开来治理。这，就是数据仓库思维的启蒙。

进一步将数据模型优化成关系型数据模型与多维度数据模型概念的，是Kimball. 他的多维度数据模型虽然可以用关系型数据库实现，但数据结构的组织，已经完全不同于OLTP的使用规范，而是更接近于 OLAP，也就是在线联机分析处理。

正因为有了多维度数据模型，OLAP才有了新的产品。新的非关系型OLAP产品，与OLTP的关系型数据库，完全就不是一个架构了。比如 SQL Server Cube, Hyperion Essbase,DB2 OLAP Server 等等.他们采用了一种叫做稀疏性矩阵的技术。

以分布式数据库作为数据仓库技术的新起点

半个世纪以来，数据库世界一直都是关系型数据库的天下。那么多的业务系统都建立在RDBMS上，那么顺理成章，数据仓库也以RDBMS为基建了。这样一来，无论是硬件成本，还是人力成本，都可以减少到最少。

但摩尔定律一定是支配着信息产业的发展，每过18个个月翻番的，不仅仅是计算机硬件性能，对软件也提出更高的要求，数据库就更加严苛了。大家回忆下半年前，你们的数据库有多大，再想想现在你们的数据库有多大，就明白了。

所以，大小型机，受制于单台资源，在日益增大的数据面前，毫无应招之力，只能让步于分布式数据库。以Hadoop的横空出世为起点，数据仓库终于不再以RDBMS马首是瞻，纷纷投奔分布式的非关系型数据库。

跟RDBMS如出一辙，Hadoop一战成名之后，后起之秀就越来越多，也越来越猛。原本 Hive 这样的非实时数据仓库，已经取得了很大的市场，但随着实时数据技术的渴求与引入，Spark, Flink 这样的分布式计算也日益得到人们的青睐。

真是“问世间，是否此山最高 或者另有高处比天高。”

计算机的世界就是这样，你追我赶，你方唱罢，我方登场。总有软件比你更快，更好，也总有人，比你更懂SQL

分布式数据库的技术派别

分布式数据库，在提高系统吞吐量，降低服务器高负载，提高作业系统性能等方面，均做出了很好的优化。数据在爆量的情况下，采用分布式数据库系统又变得自然不过了。

那么究竟有哪些分布式数据库呢？

其实分布式数据库自数据库发展以来，就没有停过。Oracle, SQL Server 在创立之初，就有各自实现分布式数据库的方法。不过那个时候，我们倾向于把这些叫做产品功能，比如高可用，复制，镜像技术，或者读写分离。

严格来说，这些分布式与我们今天所说的分布式，完全不一样。最重要的一点，商业数据库的分布式产品，都是高度自治的，那可真的是分布式，一台数据库服务器，与另外的分布式数据库服务器，不共享硬盘，也不共享内存与CPU.看上去完全无关，但逻辑上还是有联系，围绕着同一个应用，一台服务器供写入数据，另一台或者几台则供查询读取。数据同步使用 CDC, BAT 脚本等方式完成。

但若继续采用上面的架构，流量再翻10倍，100倍，肯定就顶不住了，因为单机作战能力并不能无限升级，也就不能线性增长。这时，必须采用严格的分布式架构，使每一种数据，都落地在不同的数据库服务器上。

这个时候， MPP 和 Hadoop 为代表的两类分布式计算架构出现在市场，也算是应运而生了。当然这是另外的话题。

先来谈谈架构。

企业数据仓库架构

关于数据仓库，有一种简单粗暴的说法，就是“任何数据仓库都是通过数据集成工具连接一端的原始数据和另一端的分析界面的数据库”。

数据仓库用来管理企业庞大的数据集，提供转换数据、移动数据并将其呈现给终端用户的存储机制。许多架构方法以这样或那样的方式扩展数据仓库的能力，我们讲集中讨论最本质的问题，在不考虑过多技术细节的情况下，整个层次架构可以被划分为4层：

• 原始数据层（数据源）
• 数据仓库架构形态
• 数据的采集、收集、清洗和转换
• 应用分析层

单层架构（直连）

大多数情况下，数据仓库是一个关系型数据库，包含了允许多维数据的模块，或者分为多个易于访问的多主题信息域，最简单的数据仓库只有一层架构。

单层架构就以为着数据仓库与分析接口直接连接（直连），终端用户可以直接查询。但简单有其弊端和适用性：

传统上数据仓库的存储从 100GB 起，直连可能会导致数据查询处理速度慢，因为要直接从数据仓库查询准确的数据，或者是准确的输入，过程中要过滤掉很多非必要数据，这对数据库以及前端BI工具的性能要求相当高，基本性能不会太高。

另外，在处理复杂维度分析时性能也受限，由于其缓慢性和不可预测性，很少应用在大型数据平台。要执行高级数据查询，数据仓库应该在低级实例下被扩展从而简化数据查询。

两层数据架构（数据集市层）

两层架构就是在前端应用层和 EDW 层增加了数据集市层。数据集市是包含特定主题域信息的低级别存储库。简而言之，它是一个在特定主题（例如销售、运营、市场等）下延伸了 EDW 的较小数据库。

这种方式解决了部门级数据查询和分析的问题，每个部门都更容易访问到所需数据，因为每个集市仅包含给定域信息，另外，数据集市限制了终端用户对数据的访问范围，设置了一道数据权限。但是创建数据集市层需要额外的硬件资源，并集成它与数据平台其他的数据库。

三层架构（OLAP）

在数据集市层之上，我们通常会使用联机分析（OLAP）处理多维数据集（cube）。OLAP 数据集是一类从多维度描述数据的特定数据库。关系型数据库只能表示二维数据，而 OLAP 允许在多维度下编译数据并且在维度之间移动。

OLAP专用于维度建模数据的分析，然后通过BI将OLAP的结果以图表的方式展现出来。

OLAP 的业务价值在于允许对数据进行切片、切片以多维度分析，以提供对所有企业数据或特定数据集市的访问，现在基本已成为主流的架构应用。

以下这张架构图使用最广泛的体系结构，它由顶层、中层和底层组成。

底层：数据仓库服务器的数据库作为底层，通常是一个关系数据库系统，使用后端工具将数据清理、转换并加载到该层。

中间层：数据仓库中的中间层是使用ROLAP或MOLAP模型实现的OLAP服务器。对于用户，此应用程序层显示数据库的抽象视图，这一层还充当最终用户和数据库之间的中介。

顶层：顶层是前端应用层，连接数据仓库并从数据仓库获取数据或者API，通常的应用包括数据查询、报表制作、BI数据分析、数据挖掘还有一些其他的应用开发。

从功能应用和技术架构来展开，以下是一张中大型企业的很详细的数据仓库架构图了。

数据仓库的4层核心组件：底层源数据库（数据存储方案）、ETL、前端应用、还有OLAP服务。

数据仓库数据库

底层的数据仓库服务器通常是一个关系数据库系统(各种表关联的sql统计会更方便一些，非关系型数据库目前在这方面还是有所区别)。常用的方案有Oracle、db2、sqlserve 还有essbase、greenplum、teredata等数据仓库专业解决方案。

1、采用传统关系型数据库，或经过功能扩展的MPP数据库

① 传统的关系型数据库有：oracle、mysql、DB2

② 大规模并行处理数据库：Vertica、Teradata(商业)、Greenplum (开源)

Teradata老江湖了，银行业使用较多，但成本也是真的贵，目前我们做项目较多的是用Greenplum，算是业界最快和最高性价比的高端数据仓库解决方案，Greenplum是基于PostgreSQL的，于2015年开源。我知道的国内四大行有3家在用，5大物流公司有4家在用，不少公司在从Teradata 迁移到 GP。

2、大数据平台架构：Hadoop+Hive

这套方案有多通用不用多说了，通常是这样的组合：TB级数据用PG，百TB级数据用GP，PB级i上数据用Hadoop。

下面整理了一张传统数据仓库架构、GP还有Hadoop大数据平台的对比图。

采集、收集、清洗和转换工具(ETL)

数据来源、转换和迁移工具用于执行将数据转换为数据仓库中的统一格式所需的所有转换、摘要和所有更改，它们也称为提取、转换和加载工具。其功能包括:

1、抽取

全量抽取：适用于数据量小且不容易判断其数据发生改变的诸如关系表，维度表，配置表等

增量抽取：适用于数据量大，为了节省抽取时间而采用的抽取策略

2、清洗

空值处理：将空值替换为特定值或直接过滤掉

验证数据正确性：把不符合业务含义的数据做统一处理

规范数据格式：比如把所有日期都规范成YYYY-MM-DD的格式

数据转码：把一个源数据中用编码表示的字段通过关联编码表转换成代表其真实意义的值

数据标准统一：比如在源数据中表示男女的方式有很多种，在抽取的时候直接根据模型中定义的值做转化。

3、转化和加载

转换：用ODS中的增量或者全量数据来刷新DW中的表

加载：每insert数据到一张表都可以称为数据加载

关于ETL工具的选型，这里罗列了一张对比表，基本囊括常用的ETL工具。

前端应用工具

数据仓库平台的搭建，最终是为了梳理出有用数据、提供有价值信息，帮助业务做出正确决策。

前端应用工具主要就是和数据仓库不同环节的数据交互，这些应用一般可以分为4类：

• 数据查询和报表工具
• BI即席分析工具
• 数据挖掘工具
• 各种基于数据仓库或数据集市的应用开发工具

其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。

1、数据查询和报表工具

通常用来生成一些固定类报表，自动化报表，支持打印和计算等大批量批处理作业。

流行的报表工具，在旧数据仓库时代主要是IBM的BO、Oracle的BIEE、还有微软和cognos，整体打包在数据仓库解决方案里，报表作为一个组件存在。但是随着传统型数仓，架构重成本贵，很多公司在项目上会自己考虑设计架构，而不是直接强套昂贵的解决方案，包括很多开源组件/平台的使用。

有关报表工具，现在项目上用的比较多的是帆软FineReport，针对不同企业数仓架构以及报表需求的适用性较广。比如对接各种数据库直接生成报表；对采集整理后的数据进行多维报表展现，支撑业务分析报表；对接集团性数据仓库，构建数据中心平台，形成决策分析平台。

2、BI即席分析工具

BI一般都集成了OLAP服务器和报表展示功能。分析型BI基于多维数据库的概念，能多维视角分析数据，通常是从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端BI分析工具读取。

BI在前端通过拖拽数据字段，多维度实施展现数据，最终生成各种分析报告。常用的BI工具有PowerBI、Tableau、FineBI，还有开源的superset。个人使用多用前两者，企业项目上选型多用FineBI，因为要考虑性能、服务方案等。剩余就是自研或者开源，superset算是比较公认的开源BI。

BI工具做什么的不多说了，在项目选型的时候主要考虑上手难度（考虑没技术基础的业务用），数据处理性能，其他就是技术选型的事，还有成本。

3、数据挖掘工具

OLAP是将数据多维视角呈现分析，数据挖掘则是应用的算法来揭示数据的规律性，比如相关性、模式和趋势等。数据挖掘工具就是做这个的，它能让一些算法和过程自动化。

举个例子，比如银行里数据仓库以面向“客户”为主题进行数据的存储，OLAP可以实现数据按照客户的基本信息、储蓄账户信息、历史余额信息、银行交易日志等，以报表或者可视化的方式呈现分析，多方面掌握客户动态，发现数据的问题，更好的针对不同类型用户进行特定性营销。而数据挖掘则是通过历史数据建立模型，在拟合历史的基础上，分析未来趋势，判断哪些因素的改变将很可能意味着客户的最终流失，进而避免其发生。

常用的数据挖掘工具，R、Python还有SPSS，基本都是开源个人可用的。和BI和报表不同，市面上少有为客户提供定制化数据分析和挖掘的商业工具或者项目服务，因为行业性太强，需要非常熟悉业务、数据、平台，所以我见过基本都是自己养数据分析团队或者挖这类的人才。

4、应用开发

以上报表型、分析型的数据产品，但也会有延申出来的各种特定业务的数据决策系统，比如银行业基于管理层监控的的行长驾驶舱、零售业基于门店数据经营的决策系统，以及电商平台的营销参谋（输入营销目标及参数，比如要开展双十一母婴市场的促销活动，系统可以基于以往海量数据计算出应该选择什么品类的商品，在什么用户群中，以什么形式开展活动效果会更佳），都是基于这样的逻辑——基于业务深度应用。此时数仓就是提供一个服务平台的角色，比如现在很火的数据中台也大体是这个逻辑，将数据服务化，具体不懂就不班门弄斧了。

这样的服务，当然需要自己开发。

在这三层之间其实还有中间层OLAP服务器，典型实现为ROLAP模型或MOLAP模型。现在很多成熟的BI工具都是集成了OLAP服务器的，所以通常我们只需要选择ETL工具以及存储方案和可视化BI方案即可，所以OLAP本文也就不多讲了。