18
2023-07
简单理解OLAP引擎
尝试用最简单的方式解释一下OLAP和OLTP的区别。毕竟对于一个走业务线的数据分析师而言，一些技术问题也没有必要过分深究。
LEARN MORE
图片由海艺AI绘制
先聊点概念
学习一个陌生概念的最好办法就是去仔细读官方的定义或者概念。如果你觉得官方的定义看起来枯燥无味不明所以，那一定是你解读的方式不对。
对于这种英文的名词，一定不要慌，先去查查这几字母究竟是哪些单词的缩写，而不是去看中文翻译是啥——中文翻译十有八九是深坑。
联机事务处理OLTP
Online Transaction Processing
联系分析处理OLAP
Online Analytical Processing
忽略中文翻译，直接去看英文的定义，是不是很容易就能理解到，OLAP就是为了数据分析而生的，分析这个大字已经明晃晃的写出来了。所以说，对分析师而言，为什么OLAP更快更好用的原因已经呼之欲出了。
万物道理相通，数据库和人生也有共同之处。打工人做副业都明白应该这个道理：不要拿你的业余(爱好)去挑战别人的专业(饭碗)。对OLTP而言，支持业务是主业，而分析就是副业；而对OLAP而言，分析才是专业，所以在分析领域，OLTP完全不是OLAP的对手。
分析是什么，分析处理要处理什么，大家应该读懂，我就不细说了，但可能有人对什么叫事务处理没啥概念。说得细一点就是，事务处理是为了实现一个具体的功能或者需求：比如在网页上编辑自己的个人资料并提交保存。对这个需求来说，数据库执行的操作其实就是增删改查：查到你的信息，给你呈现页面，根据你的编辑结果进行增删改和保存。分析处理和事物处理就不一样了，更多的操纵并不是对数据做增删改，而是查，并且大概是不带ID和索引的查，一般是group by，count，sum这种查法。
不难理解，分析处理和事务处理对于数据库的操作是完全不一样的——事务处理绝大多数情况下是对一行数据处理，分析处理绝大多数情况下是对一列数据进行处理。这不意味着分析处理就能对一行数据进行处理，也不意味着事务处理对一列数据进行处理，实际上OLAP和OLTP都是可以的，只不过在处理效率上有较大的差别罢了。
再说说实操
很多数据分析师容易把OLAP和某一种数据库画上等号，得出类似于clickhouse比pgsql强这种结论。这很正常，毕竟数据分析师不是DBA，这种东西不需要知道太多。由于这几年的工作经验导致我在技术的路上上越走越深了，就稍微了解得多了一点。
其实事情可能并不是这样的，在这里我要额外介绍一个概念——HTAP（Hybrid transaction/analytical processing）。
前面已经说过了，OLAP和OLTP是在不同的场景上的应用。实际对企业而言，OLAP和OLTP两种常见都需要的，那么我们在采购数据库产品的时候岂不是要选择两种？不，这代价太大了，我们希望的选择的是，既擅长OLAP又擅长OLTP的数据库。虽然听起来这不是既要又要的典型离谱发言么，但实际上还真的是有需求的地方就有市场，有市场的地方就有勇士愿意尝试一下。市面上有一些宣称自己是HTAP的数据库工具，因为不是专业的DBA人员，怎么样这个话题我就不去评论了。
除了市场需求以外，还有一个数据分析师都需要关注的地方，那就是如果用来OLTP和OLAP两套东西，就一定会面临一个问题，那就是数据从OLTP到OLAP的同步问题。或者说得更加直白一些，数据从业务系统到数仓的同步问题。传统的解决思路，就是单独做一个体系，按照一定的流程把数据从OLTP搬运到OLAP中。这个过程搬运的过程也就是很多偏业务的数据分析师小伙伴似懂非懂的ETL了。说白了，ETL的本质其实和大家做周报日报定时邮件的思路是完全一样的，就是是一个定时的任务。
可能是冷知识，也可能不是
- Excel在结构化引用（超级表）的情况下是类似于OLAP的，而常规默认的情况下是OLTP，这就是超级表优于一般格式的原因。
- 其实mysql也有olap的版本（MySQL Analytics Engine）但是似乎大家都说不好用，真的假的咱也不知道，毕竟这个是Oracle Cloud限定。
- postgresql，是一专多长的全栈数据库，天生就是HTAP，完美符合了既要OLAP又要OLTP的需求。
