历史发展

援引网络博文中的简单总结

OLAP这个名词是数据库之父Edgar F. Codd于1993年在文章《Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate》提出，他总结了OLAP产品的12个原则，随后OLAP产品相继问世并逐渐形成今天的格局。
但第一款OLAP产品Express却于1975年问世，随着被Oracle收购后繁荣发展了30余年，最后由继任者Oracle 9i替代。这么多年过去，基本的OLAP理念和数据模型仍然未变。

基于电子表格的数据分析

例如在基于数据库的数据分析兴起以前，于1985年，Excel 1.0诞生。它是微软在Excel中集成了数据透视表功能可能是Excel产品最重要的增强功能之一，因为数据透视表已成为多维分析中最流行和使用最广泛的工具。
即使数据库和大数据普及的当下，很多简而小的账务场景下，用户依然使用Execel本身来分析数据。

基于传统数据库的数据分析

1989年，SQL语言标准诞生，它可以从关系数据库中提取和处理业务数据。这可能是个转折点。在1980‘s年代，电子表格在OLAP应用中占绝对主导地位；而1990’s年代以后，越来越多的基于数据库的OLAP应用开始出现：
例如，Microsoft于1999年发布的OLAP服务，其于2000年成为Microsoft Analysis Services。

基于大数据的数据分析

随着大数据技术的兴起，传统数据库不再能够胜任海量数据场景下的分析工作，随着Google三驾马车，分布式文件系统（Google File System）、分布式表格（BigTable）和分布式计算模型 （MapReduce），三篇论文的发表，Hadoop技术蓬勃发展，OLAP技术也随之进化，陆续出现了许多优秀的数据处理和分析工具，如Hive、Spark、Impala等等。

当下的现状

OLAP技术的分类

MOLAP

即Multi-Dimensional OLAP，是一种将数据进行多维预处理的OLAP技术，它通过将数据进行预结算，并将聚合结果存储到CUBE模型中，以多维数组的形式物化到存储系统中，从而加快后续查询。
产品有 Cognos Powerplay, Essbase, TM1, Jedox 和 icCube、Druid、Kylin等等。

ROLAP

即Relational OLAP，是一种基于关系型数据库的OLAP系统，在ROLAP系统中，数据存储在关系型数据库中，分析时直接从数据库中读取数据进行计算和分析。
产品有Vertica、Amazon Redshift、Google Dremel、Hulu Nesto、Presto、Druid、Impala、Greenplum、HAWQ和Doris等。

HOLAP

即Hybrid OLAP，融合MOLAP和MOLAP的特性，兼具两种场景下的数据分析能力。
产品有Holos、Microsoft Analysis Services,、Oracle Database OLAP Option、MicroStrategy and SAP AG BI Accelerator等。

主流的OLAP引擎

MOLAP：Druid、Kylin
ROLAP: Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL
HOLAP: Holos、Microsoft Analysis Services,、Oracle Database OLAP Option

新技术的普及

在讲计算时，不可不谈及存储，反之亦然，这两个概念本就是相互依存，相互促进，因此后面讲的概念不会区分适用于哪个层面。

内存向量计算

硬件的更新换代，影响着计算能力的提升，内存向量化计算是当下已经探索的、可行且高效的提升系统计算能力的手段。
例如基于Spark引擎的gluten、Photon项目，基于Presto/Trino的Velox项目，逐渐被应用到生产环境，计算性能确实能够有成倍的提升。

列式数据存储及交换

基本上已经是OLAP引擎的标配能力，不仅仅能够减少网络资源的开销，同时能够更快速地交换大量数据。
Apache Arrow列式数据格式，为不同第一间的数据交互和传输提供了统一的数据组织方式，许多的OLAP系统都已经支持了Arrow格式的数据格式，例如Spark、Presto/Trino。

增量查询

随着数据湖技术的发展，例如Apache Hudi、Apache Iceberg等，为OLAP引擎增添了新的动力，这些湖系统利用CDC(Changed Data Capture)弥补了HADOOP文件无法更新的问题，同时又提供了数据快照功能，因此当下的OLAP引擎也都随之进化，扩展自己的SQL语法以支持Time Travel，同时也支持在增量数据上的检索。

多源融合

即OLAP系统可以支持同时处理多个数据源，并将不同的数据源抽象为Connector，就像JDBC CONNECTOR那样的，可以把这些不同源的数据转换为自己内部的统一数据格式，以实现跨数据源的计算。

计算下推

随着多数据源的融合，也对OLAP系统的查询计划能力提出了更高的要求，由于不同的数据源所支持的数据类型、聚合方法、统计信息、过滤谓词不尽相同，因此需要OLAP系统有能力因地制宜地将合适的逻辑下推到Connector层，由Connector决定如何处理这些细节，如此才能更高效地完成查询任务。

例如，过滤条件下推到Connector/Scan已经是必不可少的能力；聚合计算下推，例如MIN/MAX聚合函数，有些Connector存储了表级/分区级的统计信息同，因此可以不必读取真实数据，就能返回聚合结果。

物化视图

物化视图实际上就是基于源表之上的预聚合的结果表，它独立于源表存储，因此会导致占用的存储空间膨胀。不过好处是利用空间换时间，SQL引擎可以改写特定模式的SQL，利用物化视图表影响查询，以加速计算。

可以参照Clickhouse中的各类MergeTree表引擎来理解物化视图，不过物化视图相对简化。

物化视图真正可靠，存在很明显的问题，就是如何解决数据同步的问题，即物化视图初始化之后，如果源表发生了更新，如何将这些更新应用到物化视图表，就需要考虑各种情况下的更新事件，以选择的方式来MERGE新数据，不过由于聚合算子通常比较复杂，难以在增量更新场景下实现物化视图表的更新，因此即使主流的OLAP引擎，如Starrocks，也仅仅支持简单的聚合函数，如MIN/MAX/SUM/COUNT等。

发展趋势

智能化分析

对于数据分析人员，使用OLAP系统不过是计算出预想的数据结构和关系，然后再在自己的场景下利用数据分析手段，找到数据与业务的关系，但随着大模型或AI技术的普及，数据从清洗、到转换、到计算、到分析、再到解释，大胆预测必将成为一个固定的套路，因此如果OLAP系统能够很容易的与嵌入到整条链路或是成为整条链路，这必将增强OLAP的价值。

多源融合和自动化处理

基于计算与存储分离的设计，一个引擎可以很容易地读取不同的数据源，从而实现跨源的数据聚集能力，同时也可以自动地对来源数据进行清理、转换。

动态/虚拟列

需要底层支持表达式列（区别于Plain列），类似于MySQL中存储JSON表达式列（虚拟列）的功能，Iceberg中利用Transformer实现隐藏分区的功能，Clickhouse中的聚合视图表的功能等，该功能可以动态扩充源表的列，同时可以由使用者决定写时计算或读时计算，以应对不同的场景。

通常底层存储的列数据都只能是基础列的数据，如name列，对应的存储值有’张三’，如果查询SQL中的过滤表达式包含了name列，且为复杂表达式，如substr(name, 10)，那么在查询时肯定是不能预先知道每一个值的经过substr函数后的结果，因此必须将数据读取内存并且应用函数方法才能决定如何过滤数据或是优化查询。
当有了虚拟列的能力，可以选择在插入数据时，新增一个内部列，列名为_XX_internal，存储substr(name, 10)计算后的结果，如此当SQL中有表达式匹配就可以直接将substr(name, 10)替换成_XX_internal，避免现场计算，以加速SQL影响。
当然也可以选择_XX_internal存储的仅仅是表达式或是不存储，这样就对齐了最原始的SQL检索能力。

HTAP

即Hybrid Transaction / Analytical Processing，混合事务分析处理。当下许多OLAP引擎兼具事务的特性，同时支持OLTP和OLAP的场景，例如Starrocks、Hologres、Trino等，除了本身支持查询计算功能外，也在不断完善支持数据的写入。
对于一个多源融合系统来说，能够支持数据的写入，也将省去不少的其它系统上的维护工作。

文章仅仅是列举了一些比较常见且有效的改进OLAP系统的功能，也提及了一些可预见的发展方向，相信还有很多我所没了解到的新的技术、新功能，欢迎大家在评论区丰富本文的内容。