【记录】OLAP和OLTP

下面为提炼的重点内容，全部内容参考：OLAP和OLTP

OLAP和OLTP的不同设计要求

对于OLTP系统和OLAP系统有哪些不同的要求？要说清楚这个，首先需要分析一下这两个系统的关键特征。

对于OLTP系统来说，最重要的事情是：

使得大量的人能够同时执行数据库事务操作，QPS至关重要。
上面涉及到的事务操作应该非常简单，且一次请求只运行涉及一条或几条记录操作。
OLTP系统必须确保整个交易链（涉及多个交易）被正确记录。 在OLTP系统中，我们将花费大量的时间来确保数据在我们的系统中是一致的。例如，我们不能接受这样的事实：客户已经把钱付给了银行，但订单却没有创建。付款要么与订单创建一起失败，要么与订单创建一起成功。
要求日常业务能得到闪电般的响应速度。

对于OLAP系统，有五个关键特征：

以商业分析为重点的多维数据模型。 这个模型应该足够大，以包含所有的历史数据，并且应该足够宽，以包含所有经常使用的字段。
以商业分析为重点的指标字段。 OLAP提供大多数指标应该来自于业务团队或Bl团队本身，而不是来自于交易记录的需要。例如，在OLTP系统中，我们可能不需要记录每个客户的第一次交易时间，但在OLAP系统中，这将是非常有用和重要的。
在所有情况下为所有用户提供一致的数据和计算。 OLAP系统从许多数据源获取数据，并专注于使同一查询的结果在所有情况下对所有用户一致。然而，OLTP不太关心不同条件下的查询一致性，而是更关心结果的准确性。例如，不同的人可以在不同的OLTP系统中查询"共有多少个菜品"，而很可能他们每个人都会得到不同的结果。但是OLAP系统应该能够告诉他们每个人完全相同的答案，这个答案可能是复杂点的，类似于"在点菜系统中有20个，在财务系统中有13个"，或者简单点，类似于"13个"。但是无论怎么查，他们都应该得到一样的答案。
更细化的权限管理。 OLAP系统比OLTP系统更关注权限管理。OLTP系统更倾向于使用功能级别的权限控制，也就是说，用户要么能使用这个功能，要么不能使用。然而在OLAP系统中，我们常常需要在数据表的行级和列级的基础上控制访问。
大数据量下的高速分析。 用户一般会在OLAP系统做复杂的查询，但这并不意味着用户会更有耐心。也许他们可以比那些OLTP系统的客户等得更久一点，但查询的复杂性和数据量也明显更高。不管是通过预聚合还是通过大规模的并行处理，OLAP系统应该始终保证用户能够尽快获得结果。

因此，在产品设计方面，OLTP支持的产品最终是交易处理系统，并且需要更多的考虑如何确保流畅的用户体验，以及如何吸引用户尽可能长时间的留在产品上。产品经理主要从功能层面考虑一致性问题，希望确保所有功能总能提供一致的服务。

然而，OLAP支持的产品需要更多地考虑如何控制访问，如何设计与其他实时系统的数据交互，如何在有一些突发事情需要处理时引导和提醒用户。这是因为OLAP支持的产品是分析处理系统，是被用来支持及时的，复杂的决策。

但这并不意味着OLTP系统设计完全不用花时间在访问控制或数据模型设计上。OLAP系统设计完全不花时间在用户体验和功能上，只是时间的分配比重不同。实际上，对于OLAP产品，如仪表盘和实时监控器，数据产品经理们也花了大量的时间来考虑如何使数据被用户更好地理解——因为OLTP产品更具有不可替代性，用户放弃一个设计不好的OLAP产品甚至比放弃一个OLTP产品来的更快。

OLAP的可视化

我知道这一切听起来很合理，但是仍然很难想象。

试试看将OLAP的数据表进行可视化，这样我们就可以更直观的理解OLAP数据模型中发生的事情。

请添加图片描述
OLAP立方体从各种上游中获取数据，而且很可能是实时系统。我们把它们整合起来，重新组织成一种完全不同的数据格式，我们把这种格式称为"OLAP"格式。

你可以看到，在关系数据库中，基本上是OLTP系统中的数据库，所有的东西都被隔离并且存储在不同的表中，这样，当你在事务性的基础上写进或者读出单行记录时，你可以达到最高的效率。

在游标，我们可以看到OLAP数据模型。当然，现实生活中的OLAP立方体要比这个复杂得多，但原理都是相同的。立方体的长度、高度和宽度是三个业务维度。这三个业务维度也可以根据不同的值进行分析下钻，或者根据其自身的层次结构进行汇总。

例如，如果你想检查第一季度通过航空运输从非洲发出的包裹数量。OLAP数据模型中你可以简单地检查左上角的那个小立方体。但在关系型数据库中，这将是异常噩梦。你至少需要连接三个表。当我们的分析越复杂，OLAP立方体就越有优势。就像如果问题是"与第二季度相比，从澳大利亚通过航空路线发出的包裹的增长情况如何？"，基于OLTP表的设计将非常麻烦，但在立方体中就容易多了，这就是OLAP数据模型的魔力。