第三章存储和查询-part3,Designing Data-Intensive Applications 中文翻译摘要

事务型处理与统计分析的区别

早期的数据库是服务于商业社会的,每次数据库读写就意味着某种交易。随着数据库的应用逐渐从商业领域扩展到无所不在,过去一系列操作必须在一个逻辑单元完成的事务,目前也不那么在意了。过去数据库操作主要是事务型的,也就是我们根据一些key,用索引去数据库里面找到一小部分数据。数据基于用户的操作进行新增和更新。操作数据库的系统往往都是交互式的,也叫在线事务处理。(online transaction processing, OLTP)

但是时代变了,数据库广泛用于数据分析,特点和之前全然不同,经常分析师需要扫描整表的某一个或几个很小的列,计算各种统计结果。假设你的表是一个交易记录,那数据分析经常会这么查。

  • 我们一月每个商店的总收入是多少?

  • 最近这次促销活动让我们多卖了多少香蕉?

  • 哪一款婴儿食品和X牌的尿布在一块卖的最好

这些查询是和BI比较相关的,为了与刚才的OLTP做区分,管这种查询被称作在线分析处理.(online analytic processing, OLAP),可以用表格简单对比下他们的区别。

特点 OLTP OLAP
每次根据key查很少数据 查询大量数据,算统计数字
基于用户输入,随机写,低延迟 批量导入,或者基于时间流
用途 通过应用服务用户 给内部决策提供分析
数据呈现方式 数据的最终状态 数据的全历史状态
数据规模 GB 到TB TB 到PB

起初,关系数据库在两种场景下都挺好用的,但是后来很多公司就不在OLAP场景用关系数据库了,转而用了一个新的数据库, 数据仓库(data warehouse)

数据仓库

一个公司可能有多个OLTP的系统,服务于不同的应用和用户。往往这些系统和对应的存储服务于线上业务,所以他们对于可靠性和耗时有着非常严苛的要求。DBA也通常禁止分析员在数据库上跑些临时的分析任务,因为这些任务往往会扫描大量数据,影响线上的服务质量和数据一致性。
数据仓库则是一个独立的数据库,分析员可以在上面查询到核心数据但不影响线上的服务质量。数据仓库上面存储着一个OLTP系统数据的只读备份。数据从OLTP系统到数据仓库的过程称作ETL(Extract–Transform–Load),如图Figure 3-8

第三章存储和查询-part3,Designing Data-Intensive Applications 中文翻译摘要_第1张图片

之所以维护一个单独的数据仓库,而不是让分析员直接查询线上的OLTP数据库,有一个好处是数据仓库可以针对分析员做专门的优化。事实已经证明,第二章讨论的那些索引技术,对于分析员来说没什么用。现在就来看看专门为分析员优化的数据存储引擎长什么样。

OLTP 和数据仓库的分歧

大部分的数据仓库都是关系型的,因为SQL对于分析员来说用着很爽。另外还配以各种图形化的工具,帮助分析员生成SQL,可视化结果。让他们更容易的来探索数据。 内容都很虚,没什么值钱的,列些数据工具名字,商业化的工具有Teradata, Vertica, SAP HANA, ParAccel。开源的工具有Hive, Spark SQL, Impala, Presto, Apache Tajo, and Apache Drill

分析学的数据结构, 星形和雪花形

第二章讲了各种各样的数据模型以应对不同的线上业务的需求,但是离线分析用的数据模型就种类很少了,绝大部分数据仓库的数据模型都很规范,也就是星形结构。如Figure3-9的例子是一个零售商的数据仓库。仓库的核心是一张事实表(Fact Table),例子中对应fact_salesb表,每行记录了一个事件,这个例子中每行表示一个顾客在特定时间买了某一样商品。一般来说事实表是每一个事件一行记录,这样可以给分析员最大的灵活性。但这就意味着事实表无比巨大,像沃尔玛,苹果他们都有几十PB的数据仓库,绝大部分都是这类事件数据。

第三章存储和查询-part3,Designing Data-Intensive Applications 中文翻译摘要_第2张图片

事实表中的某些列对应某些属性,比如价格,而另外一些列相当于指向其他表的外键。一般来说对于一个事件,表示他的维度包括,5个W加一个H, who, when, what, why, where, how。举个例子,product表里面存储了所有商品的基础信息和id,fact_sales用外键的方式存储了在这次交易中,哪件商品被卖出去了。

很多时候连时间、日期这种字段也都是用外键的方式存储而不是直接写到事实表里面,因为日期也可能有很多属性,比如是否是节假日。这样就能让分析员方便的分析节假日和非节假日之间的区别了

星形结构顾名思义,就是在数据可视化的时候有一张事实表,事实表与若干个属性表相连,就好像星形一样。星形的一种变形是雪花形结构,当属性还有子属性的时候,比如一个商品又包含品牌,分类这些字段,这些又对应一张属性表。

一般来说数据仓库的列数都特别多,往往都有上百列,属性表也都很大,包含所有能帮助分析者的字段。例如店的大小,店内是否有面包店,上次装修是什么时候,距离最近的高速有多远。但凡可能用的上的都往里面放。

你可能感兴趣的:(第三章存储和查询-part3,Designing Data-Intensive Applications 中文翻译摘要)