社区编辑申请
注册/登录
系统设计之事务处理型Or分析处理型?
数据库
起初,相同数据库可同时用于事务处理和分析查询。SQL在这方面证明是非常灵活:可同时胜任OLTP及OLAP类型查询。但1980s末和1990s初期,公司放弃使用OLTP系统用于分析,而是在单独数据库上运行分析:数据仓库。

​早期,数据库写入通常与一笔商业交易(commercial transaction)相对应:如销售、订单等。虽然随数据库发展到不涉及金钱交易的领域,术语 交易/事务(transaction) 仍保留下来,指一组读写操作构成的一个逻辑单元。

事务不一定具备ACID。事务处理只是意味着允许客户端进行低延迟读取和写入,而不是只能周期运行(如每天一次)的批量处理作业。

即使数据库开始被用于许多不同类型的数据,如博客评论,游戏的动作,通讯录的联系人等,但基本访问模式仍类似处理商业交易。应用程序通常使用索引通过某K查找少量记录。根据用户输入新增或更新记录。由于这些应用程序是交互式的,这种访问模式被称为 在线事务处理(OLTP, OnLine Transaction Processing) 。

但数据库也越来越多用于数据分析,它们有着很不同的访问模式。通常,分析查询需扫描大量记录,每个记录只读取几列,并计算汇总统计信息(如计数,总和或平均值),而非将原始数据返给用户。例如,若数据是个销售交易表,则分析查询可能包含:

  • 一月份每个商店的总收入?
  • 在最近的推广活动中多卖了多少香蕉?
  • 哪个牌子的婴儿食品最常与X品牌的尿布同时购买?

这些查询通常由业务分析师编写,并提供给帮助公司管理层做出更好决策(商业智能)的报告。为将这种使用数据库的模式和事务处理区分,被称为在线分析处理(OLAP, OnLine Analytice Processing)。

表1:事务处理 V.S 分析系统

起初,相同数据库可同时用于事务处理和分析查询。SQL在这方面证明是非常灵活:可同时胜任OLTP及OLAP类型查询。但1980s末和1990s初期,公司放弃使用OLTP系统用于分析,而是在单独数据库上运行分析:数据仓库。

数据仓库(data warehouse)

企业可能有几十个不同交易处理系统:面向终端客户的网站,控制实体店的收银系统,跟踪仓库库存,规划车辆路线,供应链管理,员工管理等。这些系统中每个都很复杂,需专人维护,所以系统最终都是彼此独立运行。

这些OLTP系统往往对业务运作至关重要,因而通常要求高可用 与处理事务时 低延迟。所以DBA会密切关注他们的OLTP数据库,DBA一般不愿意让业务分析人员在OLTP数据库上运行临时分析查询,因为这些查询通常开销巨大,会扫描大量数据集,这会损害并发执行事务的性能。

相比之下,数据仓库是个独立数据库,分析人员可查询他们想要的内容而不影响OLTP操作。数据仓库包含公司各种OLTP系统的只读副本。从OLTP数据库(使用周期数据转储或连续更新流)中提取数据,转换成适合分析的模式,清理并加载到数据仓库中。将数据存入仓库的过程称为“提取-转换-加载(Extract-Transform-Load,ETL)”:

图片

图8:数据仓库和简化的ETL过程图片

大厂几乎都有数仓,但小厂却少闻。可能是因为小厂没那么多不同OLTP系统,一般只有少量数据,完全可以在传统SQL数据库中直接查询分析,甚至可以在Excel分析。而在大厂,做一些在小厂很简单的事,往往需大量繁重工作。

使用单独的数仓,而非直接查询OLTP系统进行分析,一大优势是数仓能针对分析访问模式进行优化。之前讨论的索引算法对OLTP工作效果很好,但不擅长应对分析查询。

OLTP数据库 V.S 数据仓库

数仓的数据模型通常是关系型,因为SQL通常很适合分析查询。有许多GUI数据分析工具可生成SQL查询,可视化结果,并允许分析人员探索数据(通过下钻,切片和切块等操作)。

表面上,数仓和关系OLTP数据库相似,因为它们都有SQL查询接口。但系统内部很不同,它们针对迥然不同的查询模式,各自进行了优化。许多数据库供应商都专注支持事务处理或分析工作负载,而不是同时支持。

一些数据库(如Microsoft SQL Server和SAP HANA)支持在同一产品中支持事务处理和数仓。但它们正在日益成为两个独立的存储和查询引擎,这些引擎恰好能通过一个通用SQL接口进行访问。

最近,大量开源的基于Hadoop的SQL项目出现,虽然还很年轻,但在与商业数仓系统竞争。入Apache Hive,Spark SQL,Cloudera Impala,Facebook Presto。

星型和雪花型的分析模式

根据应用程序需要,在事务处理领域使用了多种不同数据模型。分析型业务的数据模型则少得多。许多数仓都以相当公式化的方式使用,称为星型模式(也称为维度建模)。

图9中的模式显示了可能在食品零售商处找到的数仓。模式的中心是个事实表(该案例中称为fact_sales)。事实表的每行表示在特定时间发生的事件(这里的每行代表客户购买的产品)。若分析网站流量而非零售量,则每行可能代表一个用户的页面浏览量或点击量:

图片图9:用于数据仓库的星型模式的示例**

一般事实被捕获为单独事件,因为这样之后的分析中获得最大的灵活性。但是,这意味着事实表可能很大。像苹果这样巨头在数仓可能有几十PB交易历史,其中大部分保存在事实表。

事实表中的列是属性,如产品销售的价格和从供应商处购买的成本(可计算出利润率),其它列是对其他表(称为维度表)的外键引用。由于事实表中的每一行都表示一个事件,因此这些维度代表事件的发生地点,时间,方式和原因。

如图9中,其中一个维度是销售的产品。 dim_product​ 表中的每行代表一种出售产品,包括库存单位(SKU),说明,品牌名称,类别,脂肪含量,包装尺寸等。fact_sales 表中的每行都使用外键表示在特定交易中销售了哪些产品。(为简单起见,如果客户一次购买几种不同产品,则它们在事实表中被表示为单独行)。

日期和时间通常使用维度表来表示,因为这允许对日期的附加信息(如公共假期)进行编码,从而允许查询区分假期和非假期的销售。

“星型模式”名字来源:当表关系可视化时,事实表在中间,被一系列维度表包围;与这些表的连接就像星星的光芒。

该模板的变体为雪花模式,其中维度被进一步分解为子维度。如品牌和产品类别可能有单独表格,且dim_product​ 表格中的每行都能再次将品牌和类别作为外键,而不是将它们作为字符串直接存储在 dim_product 表。雪花模式比星形模式更规范化,但星形模式是首选,因为对于分析师,它更简单。

典型数仓中,表格通常很宽:

  • 事实表格通常超过100列,有时甚至数百列;
  • 维度表也可能很宽,因为它们包括可能与分析相关的所有元数据。如dim_store 表可能包括在每个商店提供哪些服务的细节,是否具有店内面包房,店面面积,商店开张日期,最后一次装修时间,距离最近的高速公路有多远等。
责任编辑:赵宁宁 来源: JavaEdge
相关推荐

2022-06-20 22:37:25

Linux操作系统命令

2022-06-15 11:02:40

网络安全运营

2022-06-01 17:47:24

运维监控系统

2022-06-14 23:34:10

Linux安全服务器

2022-06-27 17:46:53

PythonFlask

2022-06-10 07:45:09

CentOS国产操作系统

2022-06-03 09:41:03

DockerKubernetes容器

2022-06-20 13:34:46

漏洞网络攻击

2022-06-23 12:03:00

网络安全网络安全事故

2022-06-22 09:19:55

HDC鸿蒙ADB命令

2022-06-28 12:35:21

DockerPython

2022-06-25 21:22:30

编程Rust代码

2022-06-16 09:22:28

图数据库图数据数据库

2022-06-21 21:47:13

数据系统

2022-06-29 08:00:49

2022-06-30 10:56:18

字节云数据库存储

2022-06-27 23:44:37

云原生云存储云计算

2022-06-28 10:03:56

CentOSLinux

2022-06-02 15:28:42

网络安全信息通信数据保护

2022-06-29 08:13:36

漏洞网络攻击网络安全

同话题下的热门内容

一次非常有意思的 SQL 优化经历:从 30248.271s 到 0.001s横空出世的 Data Fabric,是下一个风口吗?字节云数据库未来方向的探索与实践面试经典问题,如何提高数据库的性能?从SQL到NoSQL,数据库还要向何处演进?提高分层 SQL 结构的性能这年头,谁还不知道这10个高级SQL概念?云时代下,数据库的关键趋势与DBA发展之路

编辑推荐

Oracle数据库初学者开场篇NoSQL数据库概览及其与SQL语法的比较如果对MySQL还停留在这个印象,就out了SQL编程之高级查询及注意事项防止服务器宕机时MySQL数据丢失的几种方案
我收藏的内容
点赞
收藏

51CTO技术栈公众号