Design Data-Intensive Applications 读书笔记九 事务处理或者分析

事务处理或者分析？

早期商业数据处理过程，即应对商业事务的写入过程：完成交易，下订单，付薪水。随着数据库扩展到不包含金钱交换的领域，都会在事务这里卡住，即要求读取和写入形成一个逻辑单元。

事务不需要满足ACID特性（原子性，一致性，隔离性，持久化）。事务过程只是意味着允许客户端执行低延迟的读取和写入，相对应的是定期运行的批量加工。

即便数据库用于处理各种数据：博客评论，游戏等，基本的访问模式仍然和处理商业数据类似。一个应用通过一部分键和索引来查询对应的值。用户输入记录来插入或者更新记录。因为这些应用都是交互式的，这类访问模式被称为在线事务处理（online transaction processing,OLTP）。

但是数据库开始用于数据分析，这有着不同的访问模式。一般来说，分析查询需要扫描大量的记录，在每条记录中只读取小部分列，然后计算统计值，而不是返回记录给用户。比如：如果你的数据是销售记录表，分析查询可能是：

1、一月份商店的总收入。2、最近的一次促销中我们比平时卖出了多少香蕉。3、哪个品牌的婴儿食品和X牌纸尿布搭配销售最多。

这些查询都用作商业分析，帮助管理层做出更好的决策。为了区别于事务模式，这种模式被称为在线分析进程（online analytic processing，OLAP）。OLTP和OLAP的界限不明确，但是下面是它们的一些典型特征

表3-1

首先，一个数据库既可以用作事务处理也可以用作分析查询。SQL证明了它的灵活性很高：两种查询都可以用。虽然如此，在20世纪80年代和90年代早期，公司倾向于停止使用OLTP系统用于分析，而是用一个独立的数据库用于分析工作，这个独立的数据库被称为数据仓库（data warehouse）

数据仓库

一个企业可能有多个事务处理系统。每个系统都很复杂，需要一组人去维护，所以这些系统的操作都是互相独立的。因为对商业操作很关键，OLTP系统期望有着高可用性，以及低延迟处理事务。因此数据库管理员近距离监视OLTP数据库。它们通常不情愿在数据库上运行分析查询，因为分析查询消耗很大，会损害并发执行事务的性能。

数据仓库是个独立的数据库，用作分析查询，而不会影响其他的OLTP 操作。数据仓库包含了从公司多个OLTP 系统的数据的只读备份。数据从OLTP系统数据库中提取出来，转化至用于分析的模式，清洗，然后加载值数据仓库。这个获取数据的过程称为ETL（Extract-Transform-Load），如图3-8所示

数据仓库几乎存在于所有大型企业，但是小公司几乎没听说过。可能是大多数小公司没有如此多的不同OLTP系统，并且小公司的数据量没有那么大——小到可以在传统的SQL数据库上做查询或者分析。在大公司里，很多必须的重量级操作在小公司里是很简单的事。

使用单独的数据仓库而不是在OLTP系统上直接查询的好处是数据仓库里的数据可以应用分析路径的优化。这就关系到之前讨论的索引算法，它们适用于OLTP，但是不怎么适用于分析查询。接下来的部分就讨论存储引擎对分析查询的优化。

OLTP数据库和数据仓库的分歧

数据仓库的数据模型目前绝大多数都是关系型的，因为SQL能很好的适用于分析查询。目前也有很多可视化工具用于生成SQL查询，可视化结果，分析数据。

表面上，数据仓库和关系型OLTP数据库很相似，都有着SQL查询接口。但是系统的内在相异，因为它们为不同的查询模式做优化。很多数据库供应商现在关注的是支持事务处理或者是分析工作，而不是全部。

一些数据库（如 Microsoft SQL Server和SAP HANA）同时支持事务处理和数据仓库。但是它们演化成一个通用的SQL接口连接两个独立的存储引擎。

星型和雪花型：分析的模式

之前在第二章，讨论了在事务处理领域，有很多数据模型。另一方面在分析过程中，也有差不多的数据模型。很多数据仓库都是标准化的风格，称为“星型模式”（star schema，也叫作维度模型，dimensional modeling）。

图3-9展示了在一个杂货店可能有的数据仓库的模式。在中间的模板被称为事件表格fact table。事件表格的每一行代表了发生在一个特定时间的事件（这里每行代表一个消费者的交易记录）。如果我们是分析网站流量而不是销售数据，每一行可能代表了用户的点击或者浏览。

一般来说，事件表格存储的都是独立事件，这能保证后续分析的最大灵活度。但是这也意味着事件表格会变得非常大。类似苹果那样的大企业，数据仓库里可能会有几十PB的历史交易数据。

事实表格的一些列都是属性，例如商品售价和进货价格。其他列都是外键，指向其他表格，称为维度表格。事件表格代表事件，维度表格代表了事件的5W1H（who,what,where,when,why,how）。

图3-9中，一个维度表示产品卖出去了。dim_product表格代表了销售中的一类商品，包含了库存单位（SKU），描述，品牌，类别，热量，包装大小等。

甚至日期和时间也能用维度表格表示，因为这能额外添加关于日期的信息（比如公共假日），能够统计节假日和非节假日的销售量。

“星型模式”这个词就来自于这些表格的关联。事件表格居中，周围围绕着维度表格，这些表格的连接类似星星的放射线。

一个不同的模板称为“雪花模式”（snowflake schema），维度被分成不同的子维度集合。比如，品牌和商品类别分在特定的表格中，dim_product表格可能存储品牌和类别作为外键，而不是存储为字符串。雪花模式比星型模式更加正规，但是用作简单分析的时候，星型模式更好用。

在数据仓库中，表通常很宽：事件表通常超过100列，甚至数百列。维度表格也很宽，因为它们包含了所有可能用于分析的元数据。