导读：本文由京东零售大数据架构师李海波老师贡献。李海波老师从2016年开始在小米和京东负责商业智能和多维分析，推动了多个OLAP组件在公司落地，积极参与内核研发是Apache Doris和ClickHouse的贡献者，曾在百度等公司长期负责广告和搜索相关架构，毕业于华中科技大学计算机专业。

下面就为您带来李海波老师关于OLAP关键技术演进的思考：

01

数据管理领域的分化

Data Management

1. OLAP 背景由来

联机分析处理的概念最早由关系数据库之父E.F. Codd于1993年提出。Codd认为，联机事务处理已不能满足终端用户对数据库查询分析的要求，SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果，而查询的结果并不能满足决策者提出的需求。

因此，Codd提出了多维数据库和多维分析的概念，即OLAP（Online analytical processing）。OLAP委员会对联机分析处理的定义为：使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取，从而获得对数据更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是“维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。

2. 海量、实时、支持演进的新需求

随着互联网、电商和移动互联网等行业的兴起，数据规模越来越来大，分析洞察需求越来越精细化，激烈市场环境下的决策要求数据具有更高的时效性，不同于早期的技术，新时期的OLAP技术也呈现快速的迭代进化。

早期的报表系统，通过MapReduce计算出统计结果并存储在MySQL中，这个架构有两个局限，其一是MySQL单表存储能力有限只能保存有限的维度组合，数据量大时需要分库分表，其二是只能处理离线或微批准实时的数据，无法实时统计数据。

为了解决维度组合存储的问题，一种新的解决方案是把维度的组合作为Key、指标作为Value存储在KV引擎如HBase中，这样就让维度的数量大大增加，但是也无法支持更多的维度，因为维度的增加会导致维度组合量的成倍的增长，出现维度爆炸的问题。

为了解决海量数据实时查询的问题，Druid和ElasticSearch出现了，通过增量追加、实时聚合、索引、位图等技术，把数据的新鲜度从几十分钟提升到秒级。

另一个问题是维度和指标需要支持演进，比如为了适应业务新的变化，需要在原来的维度基础之上，增加新的采集维度，或者调整计算口径；另一种情况是维度字典表发生变化，比如组织架构调整后，需要把历史数据按照新的维度来计算。

为了解决维度爆炸、实时查询以及模型演进的问题，一种新架构的OLAP出现了，整合了列存、MVCC、物化视图的向量化执行引擎的MPP架构，解决海量数据、实时分析的需求，同时支持表结构的演进，其中以ClickHouse和Doris为代表。

如下图涵盖了大部分的数据查询和分析的场景，OLAP范围涵盖了报表、多维分析和搜索等方向，而ClickHouse/Doris成为主流的OLAP引擎。

02

Hadoop&数据库蓬勃发展

谈到新时期的OLAP的演化，就不得不提Hadoop的生态，以Google三驾马车的论文发表为代表， Hadoop开源生态得到蓬勃发展。数据存储在HDFS中，Hive进行数据结构的管理并支持SQL，处理引擎由MapReduce升级为Spark，实时流从Storm升级为Spark Streaming和Flink，非结构化的音视频和网页存储在HBase中，同时搭配分布式一致性组件ZooKeeper，数据管道Kafka，调度Yarn等，各类组件百花齐放，组件的升级迭代非常迅速。数据计算链路以Lambda和Kappa架构最为典型，离线以HDFS为存储Spark为处理引擎，输出结果存在OLAP中；实时以Kafka为管道，Flink为处理引擎，输出结果存储在OLAP中。而OLAP承接了大数据处理引擎的写入，并支持上层数据应用的查询，处在一个较为核心的位置。

而在数据库领域，为了简化数据摄入和ETL的过程，同时发挥行存和列存的优势，也提出了HTAP的概念。HTAP就是把OLTP和OLAP的优势结合起来，弥补了OLAP的一些不足，如行存引擎能支持高频写入，同时支持高并发的查询单条明细数据。在减少ETL复杂度方面，内置的数据同步能力，在小规模数据量和中低复杂度的业务场景中完全足够。国内数据库也在快速发展中，如阿里的OceanBase和PingCAP的TiDB。

左手数据库，右手大数据，处于中间的OLAP博采众长，查询引擎、事务、多版本机制来自数据库，又吸收了大数据分布式技术、多副本、列存等特性，走出了一条特色鲜明的技术路线。

03

OLAP组件群雄崛起

因为大部分读者是OLAP的使用用户，所以我们先聊各个OLAP引擎的特点和适用的场景，因为篇幅有限所以只能简单介绍。下面挑选5款典型的开源OLAP引擎给大家介绍，Druid是最早的实时OLAP引擎，ES是基于全文检索的技术，Kylin是基于Hadoop生态的整合技术，CK和Doris是偏分析型数据库OLAP方案，他们都适合不同的场景。

在众多的OLAP引擎中如何选型，我这里挑选几个典型问题，大家可以带着问题去阅读：

① 查询的数据规模有多大，百万级、亿级还是百亿级

② 是T+1的数据，还是分钟级实时写入需求

③ 数据表的维度和指标是否存在频繁变更的需求

④ 是否存在某条数据需要被更新需求

⑤ 是否有对历史数据重新计算的需求

⑥ 公司在OLAP上的投入有多大如人力或服务器资源

1. 实时 Druid

Druid是第一个适合海量数据的OLAP引擎，在2015年一经开源，就在多个公司内广泛使用，一般用于实时数据查询。其分布式MPP架构和列存，日期分区、索引和近似去重等特性，成为后续OLAP引擎的标配，因Druid发展时间较长所以配套的工具较为齐备。Druid存在不支持SQL，不支持实时更新，关联查询功能较弱等问题。不支持SQL的问题主要是学习门槛比较高，另外就是缺乏SQL函数和语法，需要调整架构去支撑业务会增加额外的开发成本。

2. 搜索技术 Elasticsearch

Elasticsearch的技术基于开源的全文检索引擎Lucene，它周边工具建设很完善，可以快速部署和搭建，如Logstash或Beats用于收集、聚合数据写入到ES中，上层是Kibana可以灵活搭建看板，ES提供存储和查询、分析服务，统称为ELK套件。

目前两类场景使用ES比较多，一类全文检索如日志监控和文本搜索，另一类是实时报表类场景。ES在高频写入和高并发方面非常优秀，这种场景下很多用户选择使用ES。如果是实时报表类的场景，调整一下写入的批次和批量，以及增加一些查询缓存，在其他OLAP引擎中也同样能够满足。ES也存在不支持SQL或SQL不够丰富的问题，比其他C++的开发的引擎，资源消耗和稳定性层面有所欠缺。

3. 预聚合 Kylin

Apache Kylin™是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区，它能在亚秒内查询巨大的表。简单理解，Kylin是基于Hadoop的生态，能自动聚合计算，整合了存储引擎能提供SQL查询的OLAP加工和查询组件集合，大幅度提升了数据开发的效率，Kylin也存在时效性和明细查询的不足。

4. 简单易用 Doris/StarRocks

Apache Doris是百度内部孵化并贡献给Apache的顶级项目，MPP架构、列式存储、MVCC多版本技术，幂等性和强一致性写入，支持多种Join方式和复杂SQL，新版本支持向量化计算方式性能提升较大，也提供了多种数据导入方式。StarRocks是和Doris类似的一款开源的引擎，在查询方面做了很多优化，最近在湖仓一体方面支持力度较大。

Doris有较低的使用门槛，完善的功能，较好的性能和简单的运维，因此特别适合中小规模业务，就像使用MySQL一样简单，就能完成百亿级数据量的秒级查询和分析，在百度、京东、美团和小米都有广泛使用，在国内拥有较高的人气。近期Doris和StarRocks的迭代速度很快，比如增加了支持向量化性能提升和稳定性提升等特性。

5. 功能强悍 ClickHouse

ClickHouse是俄罗斯的搜索引擎公司Yandex 于 2016 年开源的用于MPP架构的列式存储分析型数据库，ClickHouse的全称是Click Stream，Data WareHouse。ClickHouse的特点是极致的向量化查询性能，功能强大的表引擎、数据类型、索引类型和高效计算函数，灵活的的可配置项和自定义参数。另外CK的具有良好的架构和可扩展性，很方便基于CK进行定制化部署和二次开发，头条、腾讯、京东等公司都有大规模的应用，而且做了较多的改善和改进。

6. 总结和建议

上面几个引擎简单介绍完了，如果之前没有使用过OLAP引擎，推荐大家试试Doris/StarRocks，这两款引擎门槛低、场景适应性好，如动手能力强可以尝试ClickHouse，而ElasticSearch更适合全文检索的场景，Kylin适合离线预聚合场景，看看所选的引擎是否能覆盖上面几个问题的场景。

如果已经用了以上某款或其他引擎，也大可不必急于切换其他引擎，深入挖掘这款引擎的潜力，等有痛点需求满足不了，综合权衡之后再决定是否切换或迁移。另外选型时，也应当考虑社区活跃度和成熟度，避免遇到问题时找不到技术支持，最后，选型应该亲自安装部署并用实际的场景去测试。

最后我再提醒一下，多维分析技术在公司内全面成功实施，运维和运营非常重要，大部分问题来自错误使用或不当的运维方式，详细可以参考《京东OLAP高可用实践》等相关文章。

04

OLAP 的关键技术

通过上文的几款典型的OLAP引擎可以看出，OLAP技术呈现百花齐放的特点，因为篇幅有限，本节只能简单介绍OLAP中如下的技术，大家可以大体了解一下，如果要深入研究，请阅读其他专项文章：

① 架构：高可用、一致性、弹性

② 存储：列存、索引、物化视图

③ 计算：计算模型、优化器

1. 架构：分布式多副本技术的高可用架构

OLAP是一个分布式的多副本的并行处理架构，元数据是中心化存储，由一组节点对内管理数个数据或计算节点，对外提供一致性的服务。一般通过分布式一致性协议来保证元数据的安全和一致性，比如Raft或ZAB（ZooKeeper的协议）。一组Raft集群由单数节点数组成，新增或修改元数据时，如果半数节点写成功则提交到状态机，更改全局可见。而元数据管理服务的吞吐量，决定了整个集群的吞吐量，因为DDL（Data Definition Language，如建表、修改表等）操作、事务、甚至副本同步，都需要通过元数据管理服务。

多副本保证了数据的安全同时也提供了冗余的计算资源，副本的复制一般可以通过Quorum系数来控制，比如3副本节点写成功2副本之后返回成功，剩下的1副本后台异步同步，这样可以降低数据丢失风险，当然也可以写1副本成功返回，这样吞吐量是最高的。副本之间的Quorum机制，可以在该分片的副本节点中走一遍Raft的提交过程，也可以通过元数据管理服务集中分发副本。

高可用架构另一方面是部署视图，如下图是ClickHouse的一个跨机房部署方式，DNS是域名系统本身是多机房的，请求转发到CHProxy节点中，CHProxy转发到多分片多副本的节点中，RS（RaftKeeper）负责管控元数据，也是多机房部署的，数据写入到机房A中，通过RS同步到机房B中，整个系统不存在单点，即便是一个机房故障，另外一个机房也能提供服务。

2. 存储：版本和事务保证数据一致性

MVCC(Multi Version Concurrency Control) 中文全程叫多版本并发控制，是现代数据库引擎实现中常用的处理读写冲突的手段，目的在于提高数据库高并发场景下的吞吐性能。

MVCC可以保证导数的原子性，每次数据写入都是一个新的版本，当导数成功后版本生效，当写入失败版本不会生效。对于物化视图更新、DDL的操作，都可以保证原子性，在分布式的多个节点中，也可以保证节点间的数据的强一致性。

其原理不难理解，如下图有一个异步合并线程，61-90的每个小文件版本，可以合并成新的版本61-90，假如最大版本是92，经过多轮合并之后的版本是0-92。

版本的另一个用途是可以用于保证数据的原子性和一致性，在分布式系统中，如何保证多个分片间的数据一致性，或者保证底表和物化视图表的数据一致性，靠的是两段提交的方式，第一阶段，先把数据写入到各个分片中，这批写入的数据具有相同的版本号，当前版本是未提交状态，当每个分片数据就绪之后，第二阶段把版本号的状态设置为已提交，这样查询时就能同时看到已提交的版本。如果某些分片写失败，也可以回滚删除其他分片的数据。其他的操作如DDL也是类似。

版本合并策略，也同样应对数据更新的场景，OLAP中可以处理低频更新而不能高频更新，主要原因是OLAP中的更新并不是直接修改原始记录，而是写入更新的数据文件，而文件合并是后台异步进行的。如果更新的数据没有合并则在查询时合并，这样会影响查询性能，如果文件要被合并，则需要通过多次合并最终消除重复记录。

3. 存储：列存和索引的性能加速

事务性数据库都是按行存储方便更新和按行查询，OLAP中数据量大、列多、写少读多、单个查询只查询少量列的特点，列存比较合适这类场景。

列存的优势：

• 查询少量列，读取的数据量小；
• 列存利于索引，针对列可以有设置多种索引类型；
• 列存方便做物化视图，根据视图所需的列去更新物化视图；
• 列存的压缩效率高，相同数据类型和相似值的列可以定制高效的压缩算法；
• 方便向量化计算。

列存的劣势：

• 存在写放大的问题，不方便更新，不适合高频导数；
• 对点查询不友好，比如需要查询全列，IO效率低。

索引技术也是OLAP中查询加速有效的手段，OLAP中的索引一般分为主键索引、Skipping索引、Bitmap索引、Bloom Filter索引等。

OLAP的主键索引是一种稀疏索引，不是索引每一行数据，而是索引每个数据块，数据按主键索引进行排列，稀疏索引的好处，就是少量的索引标记，就能记录大量的数据区间位置信息，如果按照8K行数据设置一条索引，上亿条的数据，索引只需要1万多条，可以放在内存中。如下图如果查找Downtown，需要先找到Brightoo然后再向下查找，这种索引结构适合大批量数据范围查找。

另外，OLAP也支持二级索引，比如Skipping索引、Bitmap或Bloom Filter索引，具体每种索引的细节我就不再赘述，通过创建二级索引，可以快速在非主键列查找数据提升查询性能。

4. 存储：物化视图预聚合查询加速

在OLAP中最有效的性能优化手段是降低数据规模，如下图的数据金字塔，从下到上数据量越来越小，计算量越来越小，查询延时会越来越快，物化视图是一个非常重要的性能加速特性。数据直接写入到明细数据表中，物化视图根据建表的SQL，自动聚合成物化视图的数据。明细数据表和物化视图表通过事务保证两者数据的强一致性。

如下图的示意图，table b是明细表（base表），table c是物化视图（rollup表），当table b数据发生更新时，会实时的反应在table c中。当查询AdvertiserId和Country的Clicks和Cost时，直接查询table c就能查询到结果，如果查询Date和Country的Clicks和Cost时，需要重table b中查询。用户写SQL时，无需知道从哪张表查询，查询引擎会自动路由到物化视图或明细表中。

物化视图就是预聚合的模式，这种聚合和计算由OLAP引擎完成了，且能保证聚合后的数据一致性，计算逻辑由建物化视图的SQL来表示。

5. 查询：查询引擎和优化器

传入一条SQL到返回结果，中间有很多步骤，一般来说分为SQL解析、生成执行计划、节点协调和计算执行等阶段。

用户一般是基于自己对业务的理解去编写SQL，SQL业务友好且非常复杂，但是对于查询引擎来说，按照用户的SQL去执行性能不佳，所以查询引擎可以基于规则进行优化（RBO），比如把过滤条件下推、Limit下推等，也可以基于代价优化（CBO），比如获取历史查询中表的数据量或查询数据量，对大小表进行Join算子优化。另外，在OLAP中因为数据量都比较大，多表关联Join操作也有很多方式，比如全局Join、本地Join、哈希Join、Shuffle Join等。

从大的方面来看，协调阶段是下发子查询和收集远程节点的数据，最终汇总到一个节点计算后返回给客户端，如下图的3-5这几个步骤。如果是多副本的，相同分片中也有一个副本选择策略，比如随机、顺序或按优先级选择。

在计算模型方面，一般都实现了火山模型、向量化执行和编译执行等计算模型。

05

未来趋势：简化与融合

Future

OLAP以支持实时、支持Schema演进，具有高吞吐写入和低延时查询能力，近几年获得了爆发式的发展，证明了OLAP面对复杂多变、快速演化的数据分析需求有强大的适应性。

但应该看到，目前尚没有一个开源的OLAP组件能够适应各种场景，能够兼顾实时性、性能、灵活性、高可用性、可扩展性、弹性、和可维护性等方方面面，这样就使得一家公司会存在多个OLAP组件，同时列存设计也导致部分OLAP引擎存在高频更新和点查能力中存在短板。

同时，经过10多年的发展，现在的大数据生态日趋成熟，各类组件层出不穷，某个组件能解决特定领域的问题，在OLAP领域，上游需要对接各种数据源、数据管道和计算引擎，下游需要对接各种查询器、报表和分析产品，处在一个数据流的中心关键环节。但是形成一个完整的数据分析解决方案时，需要各种组件的搭配，存在组件多复杂、使用门槛高、稳定性不足等问题。

如果从用户的角度去思考，他们对数据分析的诉求可能是，把数据写进去并能查询出来，同时支持各种优化和演进，最好数据也能被其他服务如算法引擎也能使用。用户迫切需要一个简单、高性能和稳定的数据解决方案，但实际上现有的技术做不到，现有技术能力约束了现有的架构门槛高、架构复杂、TCO成本高。

如果乐观的看待以上的问题，技术的发展总是要和用户的需求相匹配，我认为大致上有三类趋势：

① 联邦查询，指利用一款OLAP引擎的查询引擎能力，去查询和关联异构组件的数据源，比如在中ClickHouse或Doris中，可以查询MySQL、Hive以及ElasticSearch中的数据，这种方式可以把OLAP的高性能和各个组件存储优势结合，对外提供统一的查询服务。

② 混合存储，联邦查询发展的另一种形式是，在OLAP中内嵌其他存储引擎，做到无缝集成，比如在一款OLAP引擎中内嵌ElasticSearch的搜索引擎能力，或者内置KV存储或事务数据库行存。同时，利用多副本保证数据安全性，上层统一的SQL引擎，协调器把查询调度各种数据节点。

③ 湖仓一体，数据湖阶段是解决Hadoop僵化的缺陷，湖仓一体阶段就应当解决各种写入吞吐、各种计算负载的更大范围场景的问题，把数据湖的开放性、兼容性和数仓（指数仓引擎如OLAP）的高性能和灵活性相结合，湖仓一体化存储可以同时支持BI和AI两大类场景，支持即席分析、低延时查询和点查询等各种场景。

OLAP提供了软硬件一体化的极致性能，但云原生极致弹性能力是云数仓必备的能力，在电商大促或红包活动中也需要快速扩缩容，这是未来的一个趋势是通用型能力。

我们可以看到，OLAP走过了内聚性发展的阶段，比拼性能和功能的上半场已经结束，下半场开始逐步外延到其他领域。用户需求正推动着数据分析系统不断走向简化，数据库和大数据两大技术在OLAP领域互相借鉴中走向融合，开发者也在致力于提供一个简单灵活、高效可靠的分析系统而努力，我相信OLAP领域的未来会越来越美好。

06

参考资料

Reference

Hadoop：https://www.edureka.co/blog/hadoop-ecosystem

Druid：https://anskarl.github.io/post/2019/druid-part-1/

Kyligens：https://kylin.apache.org/cn/

ES：https://www.elastic.co/cn/pdf/architecture-best-practices.pdf

Doris：https://doris.apache.org/

Impala：https://impala.apache.org/

AWS：https://aws.amazon.com/cn/blogs/china/build-intelligent-lake-warehouse-on-amazon-cloud-technology/

大数据技术架构：https://baijiahao.baidu.com/s?id=1725750501708712603&wfr=spider&for=pc

列存：https://draveness.me/whys-the-design-olap-column-oriented/

Google Mesa：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/42851.pdf

向量和编译执行：https://www.vldb.org/pvldb/vol11/p2209-kersten.pdf

浅谈OLAP系统核心技术点 : https://zhuanlan.zhihu.com/p/163236128