系统设计之事务处理型Or分析处理型？

大厂几乎都有数仓，但小厂却少闻。可能是因为小厂没那么多不同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）。事实表的每行表示在特定时间发生的事件（这里的每行代表客户购买的产品）。若分析网站流量而非零售量，则每行可能代表一个用户的页面浏览量或点击量：

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

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

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

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

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

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

典型数仓中，表格通常很宽：

• • 事实表格通常超过100列，有时甚至数百列

• • 维度表也可能很宽，因为它们包括可能与分析相关的所有元数据。如dim_store 表可能包括在每个商店提供哪些服务的细节，是否具有店内面包房，店面面积，商店开张日期，最后一次装修时间，距离最近的高速公路有多远等。

欢迎加入后端交流群，关注本公众号添加我本人微信，邀请进群。

最近在准备面试BAT，特地整理了一份面试资料，覆盖Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。在这里，我为大家准备了一份2021年最新最全的互联网大厂Java面试经验总结。
想获取史上最简单的Java大厂面试题学习资料
关注如下公众号，后台回复「面试」即可白嫖！

往期推荐


精心整理Java大厂面试必读书籍(强烈推荐)
我是如何一步步让公司的MySQL支撑亿级流量的？
你真的思考过自己写的代码为啥这么垃圾吗？

嘿，你在看吗？