数据库、数据仓库之间的区别与联系
一、OLTP与OLAP在理解"数据仓库"与“数据库”的区别之前，我们需要先说明两个术语，即：OLTP与OLAP。
OLTP（on-line transaction processing）联机事务处理：通常指的是面向传统应用服务的关系型数据库，用户通过web界面操作实时“增删改查”数据库里面的数据。包含核心的基本的事务处理逻辑，用户对于性能的要求很高，用户点击界面之后，响应时间最低要求在5秒之内（通常3秒以内），同时需要支持比较高的用户并发度。OLTP的数据操作通常面向的是1条或几条少量数据，比如：用户下单操作该用户的购物车、支付记录、积分记录等少量数据。
OLAP（On-Line Analytical Processing）联机分析处理：面向的应用主要是执行复杂的数据分析操作，侧重于决策支撑，通过图形报表展现直观易动的数据分析结果。对于响应时间的要求相对宽松，数据分析过程通常不支持用户高并发，但数据分析的结果支持用户的高并发访问。OLAP面向的通常是批量数据操作，数据按批次进行导入、分析等操作，OLAP系统通常结合ETL(抽取（extract）、转换（transform）、加载（load）)系统进行使用。
理解上面的两个数据，剩下的就简单多了，数据库通常面向OLTP操作，数据仓库通常面向OLAP操作。OLTP侧重于保存及变更数据的当前状态，而数据仓库侧重于保存数据的历史存档。比如：用户银行转账，OLTP数据库侧重于管理用户当前账户里的剩余金额，和转账过程对方账户金额入账的数据一致性；而OLAP数据仓库侧重于记录谁进行了转账、转了多少钱、钱转到了哪里。历史上该用户习惯在什么时间转账，月初还是月末？一个月转账几次？
二、数据仓库的特点
下面的是数据仓库的几个典型特点：
关注于记录数据变化的过程，而不是数据当前的状态。
读多写少
大宽表
数据批量操作，不更新或很少更新
不支持事务
有的工作经验相对少的朋友看了这几条会说：“这哪是什么特点，这都是缺点啊！” 。不更新或很少更新，读多写少都是场景限制，大宽表破坏数据库设计范式，不支持事务那还叫什么数据库？其实不然，在OLAP的场景下，这些恰恰是它为了保障数据分析的性能所进行特殊设计的特点。我给大家举几个例子：
比如：某云厂商按周期采集服务器的运行指标，比如：内存使用率、CPU使用率等等。这些指标都是批量采集、批量入库的，一旦入库就不会再去修改。通常也不会将内存指标建立一张表、CPU使用率建一张表，而是对于同一机房的服务器建一张表，这张表以时间维度包含各种指标。比如：查询内存使用率>80,CPU使用率>70的服务器的时候，就不会两表关联查询了，查询一张宽表就可以了，数据分析的性能飞跃式提升。不支持事务，通常OLAP系统不支持事务，因为事务会在一定程度上影响数据操作的性能。数据入库之后，需要针对这些指标不断地进行分析、挖掘，即：读多写少，基本上就批量写一次后续都是读数据操作。
又比如：股票实时交易数据，关注于记录数据变化的过程，而不是数据当前的状态。所有股票的所有历史数据一旦进入数据仓库之后，就不会发生修改。可以进行股票量化交易分析。
又比如：用户商品点击量数据、用户操作行为数据、用户网页浏览时长数据等等，这些数据都是对用户进行分析所需要的数据，一旦入库不会修改。可以进行用户买卖意愿行为分析。
其实还有很多这种类型的数据，这种数据的特点就是：数据量大、产生之后不会发生变化（那一个时间刻度的数据就不会发生变化）。因此，数据仓库通常面向的是吞吐量大的历史数据进行存档、不会在做更新删除操作的这种数据场景，数据存档之后通常只面向数据查询分析。
三、数据库与数据仓库结合使用
通常一个较大型的应用服务系统，既有数据库，也有数据仓库。数据库面向用户进行联机事务处理，处理用户界面的实时操作。数据仓库的数据面向决策管理层，提供数据及图形报表，提供变化多样的数据分析决策。
上图是一个典型的数据库与数据仓库同时存在的应用服务场景
互联网用户通过应用服务产生用户行为，对数据库进行OLTP操作
应用服务把用户的操作的行为发送给消息队列，消息队列将数据导入数据仓库
数据库的数据可以通过ETL抽取、处理、转换、整合到数据仓库
决策分析系统主要面向数据仓库进行数据分析，数据分析结果可以回馈到数据库，通过应用服务面向互联网用户提供数据分析结果查看能力
决策分析系统同时对应用服务的决策管理者，提供数据分析决策支撑能力
页:
[1]