OLAP技术以及Doris应用

一、引言

在当今数据驱动的时代，企业对数据分析的需求日益增长。随着大数据技术的不断进步，传统的数据处理方式已难以满足实时性、高效性和复杂查询的要求。在线分析处理（Online Analytical Processing, OLAP）作为数据仓库技术的一个重要组成部分，因其能够支持复杂的分析操作、提供快速的数据访问能力而备受关注。OLAP系统通过多维数据模型，使用户能够从多个角度对数据进行深入分析，从而帮助决策者快速获取洞察，支持业务发展。

Apache Doris是一个高性能、实时的分析型数据库系统，它结合了MPP（Massively Parallel Processing）架构和列式存储的优势，能够在大规模数据集上提供亚秒级的查询响应时间。Doris的设计初衷是为了克服传统OLAP工具中存在的性能瓶颈和使用复杂度问题，它不仅提供了强大的SQL支持，还具备易用的管理和维护特性，使得非技术背景的用户也能够轻松上手。随着其功能的不断完善和社区的持续壮大，Doris正逐渐成为现代企业构建数据平台的首选方案之一。

本文将主要介绍OLAP技术的核心概念及其不同类型的对比，并重点分析Doris如何利用先进的技术手段解决实际问题

二、OLAP介绍

2.1 OLAP的定义

OLAP的全称是Online Analytical Processing（在线分析处理），是一种针对复杂数据分析需求设计的技术，特别适合于数据仓库环境中的多维数据分析。

2.2 OLAP和OLTP的对比

	OLAP在线分析处理	OLTP在线事务处理
设计目标	目标是支持数据分析和决策支持，提供多维度、多层次的数据分析能力。关注于复杂查询的快速响应，支持数据的深度挖掘和多角度分析	目标是支持日常的业务操作，确保事务的准确性和及时性。着重于提供高频率、低延迟的事务处理能力，以支持大量并发的读写操作
数据处理方式	主要处理静态的历史数据，处理的数据量巨大，一次查询可能涉及大量数据的聚合和筛选，数据通常不经常更新，而是定期批量加载	主要处理实时变化的动态数据，处理的数据量通常较小，一次操作涉及的记录数量有限，主要进行增、删、改、查操作
应用场景	应用于需要对大量数据进行分析和报告的场景，如市场分析、财务报表、客户行为分析、预测建模等	应用于需要实时处理大量简单事务的场景，如银行交易、订单处理、库存管理、客户服务等
性能	1. QPS一般为几百到几千2. 查询时延一般为秒级甚至分钟级3. 处理数据量一般可达TB、PB级别	1. QPS一般为几千到几万2. 查询时延一般为亚、毫秒级3. 处理数据量一般为GB级别

2.3 主流OLAP数据库介绍****

	Hive	ClickHouse	Doris
特点	基于Hadoop，可以将结构化的数据文件映射为数据库表并提供简单SQL查询	用于在线分析的列式数据库管理系统，支持实时插入和查询	一个分布式列式存储的开源数据库系统，专注于提供高性能的在线分析处理能力
适用场景	适合于批处理的离线分析任务，不适合实时查询	适用于实时查询和数据流处理	适用于大规模数据集的高效查询

2.4 OLAP类型介绍

	ROLAP (Relational OLAP)	MOLAP (Multidimensional OLAP)	HOLAP (Hybrid OLAP)
定义	基于传统关系数据库的OLAP实现	采用多维数据立方体存储数据，预计算所有可能的汇总数据	结合了ROLAP和MOLAP的优点，部分数据预计算存储为多维数据立方体，其余数据保持关系型存储
优点	灵活性高，易于集成现有关系数据库	对预定义查询响应迅速，特别适合固定维度的复杂查询	既提供了MOLAP的快速查询能力，又避免了其高昂的存储成本
缺点	查询速度可能较慢，尤其在大规模数据集上	存储空间占用大，维护成本高	实现复杂度较高，需要精细的设计和管理

三、OLAP应用-Doris

3.1 Doris介绍

Apache Doris 是一款基于 MPP 架构的高性能、实时的分析型数据库，以高效、简单、统一的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。

3.2 高性能方案

这一章节中我将从Doris的架构设计、针对查询的优化措施等方面介绍Doris是如何实现高性能的。

3.2.1 Doris整体架构

正如前面提到的Doris是基于MPP架构设计的，MPP（Massively Parallel Processing，大规模并行处理）架构是一种用于处理大规模数据集的计算机架构，其核心理念是在多个处理器或节点之间分配数据和计算任务，以便并行执行，从而大幅度减少处理时间和提高系统吞吐量。

Doris的MPP架构由Frontend（FE）和Backend（BE）两个组件组成：

• FE主要负责用户请求的接入、查询解析规划、元数据管理、节点管理相关工作。
• BE主要负责数据存储、查询计划的执行。每个BE都可以独立存储和处理数据。

这两类组件都是可以横向扩展的，并且通过一致性协议来保证服务的高可用和数据的高可靠，所以这种架构兼顾了高可用和可扩展性。

3.2.2 向量化查询引擎

向量化技术是指数据库在执行查询时，将一行一行的数据处理转变为向量化处理，即一次性处理多行数据。这种处理方式可以充分利用CPU的SIMD指令集，相比于非向量化处理可以带来几倍到几十倍的性能提升。

（注意，这里的向量不是数学意义上的向量，而是指包含相同类型数据元素的数组或集合）

目前一些OLTP数据库例如PostgreSQL、Oracle Database等已经支持向量化执行，在MySQL9.0版本中，也引入了VECTOR数据类型用于存储向量和加速数据处理。

传统方式：每次读取一行数据，然后传递给下一个算子

向量化方式：每次读取一批数据，以向量形式传递给下一个算子

3.2.2.1 列式存储

Doris 使用列式存储格式，相比于MySQL等OLTP数据的行式存储，列式存储的数据在内存中是按列组织的，相同字段的数据存储在一起，形成连续的物理存储空间。

这种布局非常适合向量化执行，因为它允许查询引擎在处理数据时直接访问和操作整个列，而无需遍历整行数据，从而减少了数据访问的随机性和提高了缓存命中率。

3.2.2.2 减少虚函数调用

虚函数指的是运行时动态分派的函数调用，在数据库中通常与数据类型的多态处理有关，在每次执行时需要确定正确的函数版本，还可能涉及类型检查和间接跳转，增加了运行时的额外开销。

在向量化执行时，因为数据是按照列式存储的，所以在编译时可以针对整个数据列的类型提前绑定非虚函数，提高执行效率。

3.2.3 Join优化

大规模数据集的查询中，往往会涉及比较耗时的多表Join，所以Doris对Join操作的优化也是提升查询性能的关键部分。

后续章节中我将以最常用的Hash Join中对于Shuffle阶段的优化为例介绍一下Doris是如何提升Join性能的。

3.2.3.1 Shuffle优化

相比于集中式的OLTP数据库，Doris作为分布式的MPP架构数据库，在Join的过程中数据需要进行拆分调度（Shuffle），才能保证最终的Join结果是正确的。

有分布特征的表其数据本身就是通过Hash计算进行分桶存储的，Doris对这些表进行Join时，可以通过数据分布信息，减少参与Shuffle的表数量，甚至可以无需Shuffle直接在节点本地Join，大大减少了网络开销

3.2.4 自适应查询执行

Adaptive Query Execution（AQE，自适应查询执行）技术是Apache Doris中的一个重要特性，它能够根据查询的Runtime Statistics（运行时的统计信息，例如表的行数、数据分布等）动态调整查询执行计划，以优化查询性能。

下面以Runtime Filter为例介绍一下AQE是如何应用的。

3.2.4.1 Runtime Filter

Runtime Filter是一种在查询执行期间动态生成并应用的过滤机制，它能够在运行时根据已处理的数据生成过滤条件，并将其推送到执行计划的早期阶段，通常是扫描节点（Scan Node）。这样做的目的是尽早剔除不必要的数据，减少后续Join操作的数据量，从而加速查询处理。

Runtime Filter的工作原理：

1. Filter生成：在Build Side（通常是较小的表）的数据被处理时，Doris会根据数据特征生成一个Filter，这个Filter可能是一个简单的In/Min/Max值列表，也可能是一个Bloom Filter。
2. Filter推送：生成的Filter会被推送到Probe Side（通常是较大的表），并穿透到执行计划的最底层（Scan节点，扫描阶段）进行应用。这意味着在数据被读取之前就进行了过滤，减少了不必要的数据传输和处理。

支持的Filter类型：

•  In Filter：适用于基于固定值的过滤。
•  Min/Max Filter：基于数值范围的过滤。
•  Bloom Filter：适用于复杂查询条件下的高效过滤。

3.3 联邦查询

Doris 的联邦查询能力允许它直接从不同的数据源读取数据，而无需将数据物理地移动到 Doris 的存储层。这意味着 Doris 可以作为一个统一的查询引擎，访问和分析来自多个异构数据源的数据。

3.3.1 多源数据目录（Multi-Catalog）

Doris在原有的元数据层级上，新增一层 Catalog，构成 Catalog -> Database -> Table 的三层元数据层级。其中Catalog 可以直接对应到外部数据目录。例如Hive、HDFS、S3、Elasticsearch 和JDBC等。

这意味Doris支持联邦查询，可以在多个数据源之间无缝查询，而不需要将数据复制或移动到另一个系统中，这样可以在低成本的存储（如对象存储）上运行高性能查询。

举个例子：业务数据用rds存储，数仓中需要同步一份相同的数据用于分析，部署Doris连接rds的catalog后就无需持久化存储这些数据，同时计算效率还可以比之前使用Hive时更高，这样相比传统数据仓库，可以显著降低存储（减少重复拷贝的占用）和计算成本（更低配置实例实现相同性能）

3.3.1.1 Catalog操作

•  创建Catalog

1.  Doris配置Hive数据源示例：

2.  Doris配置MySQL数据源示例：

•  查看Catalog 

1. 如下图所示，这是大数据Doris目前已配置的外部数据源：

3.3.2 MySQL协议

数据仓库专门设计用于支持商业智能（BI）和决策支持系统（DSS），而Doris采用MySQL协议，高度兼容 MySQL 语法，支持标准 SQL，用户可以通过各类客户端工具来访问 Apache Doris，并支持与 BI 工具的无缝对接。

Apache Doris 当前支持多种主流的 BI 产品，包括不限于FineBI、Tableau、Power BI、Apache Superset 等，只要支持 MySQL 协议的 BI 工具，Apache Doris 就可以作为数据源提供查询支持。

3.3.3 权限管理

Doris 的权限管理系统参照了 Mysql 的权限管理机制，做到了行级别细粒度的权限控制，基于角色的权限访问控制，并且支持白名单机制。

除此之外，我们正在使用的SQL审核管理平台Archery在新版本中也支持了Doris实例，可以做到Doris SQL的查询和上线操作的审核，目前已经在测试环境部署了，线上正在准备升级部署中

四、Doris在云平台的应用

从前面的Doris的设计中可以看出，Doris具有以下优劣势：

优势	1. 支持MySQL协议并且高度兼容MySQL语法，使用Doris相比于ES、Mongo等数据库，能减少很多额外学习语法的成本。2. 执行复杂关联和聚合的查询时拥有很高的性能。3. 多数据源集成并且支持半结构化数据，能提供统一的数据处理入口。
劣势	1. 不适用于高并发的单点写入场景。

这一章节我将介绍一下目前Doris在云平台的实际应用场景。

4.1 BI看板

目前BA（需求分析师）会有自助查询的需求，其要求主要为：

1.  延时低的不固定模式查询；
2.  查询范围包含结果数据集和原始数据集，且会有跨源关联；

为了满足结果数据响应的及时性，需要将Hive数仓里的数据通过Sqoop或者Python脚本导入到MySQL中，然后通过连接MySQL表以提供看板数据，但这样会包含导入和建表两部分的额外开发

为了满足原始数据的查询需求，需要使用Hive on Tez提供数仓中ODS层的数据查询，但这样查询速度较慢，且数据是离线批量刷新

现在针对这部分需求，大数据使用了Doris的多数据源支持和查询引擎加速，将Doris连接了Hive数仓、业务数据库等以实现从原始数据到结果数据的完整查询；再借助Doris的支持MySQL通用协议，使Hue、MetaBase、Fine BI等常用查询分析平台可以接入Doris数据源，满足内部的报表分析和即席查询需求。

4.2 统一业务数仓

基于Doris构建统一的业务数仓，逐步替代原Hadoop、Hive、Spark等组成的数仓架构。

研发效能等业务看板，通过Doris的多数据源支持，无需导入即可访问多个数字化系统的数据，并通过联邦查询将这些数据进行联合计算，进而构建了多层次分主题的研发数仓，全链路刷新数据只需要2分钟不到。

4.3 用户标签/画像

当前大数据使用的用户标签/画像主要基于用户的大批量历史数据计算生成，数据生成链路为Hive数仓→ 神策数仓→ 神策用户标签，链路较长且神策计算时长较长影响下游使用。

故已将部分用户标签的生成迁移到使用Doris实现并使用其计算引擎进行加速，减少了生成链路上的依赖复杂度和计算耗时。

4.4 日志分析加速

对于结构化数据，例如大数据采集了网关日志并存入的Hive表，之前分析需求基本采用Python脚本+Hive/Spark分批计算实现，执行时长过长容易影响交付，且占用计算和内存资源过多会影响其他任务。现采用Doris以外部表形式来读取日志表，得益于MPP架构和查询优化，对于大批量数据计算时长可从小时级减少到分钟级。

对于非结构化数据，例如S3上的原始日志文件，提供了半结构化数据类型VARIANT，可以将JSON中的字段自动拆分为子列存储，提高存储和检索效率。

以下是大数据之前进行性能测试的结果：

场景	Doris执行时长	Hive执行时长
45亿的数据根据某一字段过滤出11亿数据	耗时10分钟	纯SQL难以执行，只能通过脚本+SQL分批读取
Json解析测试：2.5亿数据解析单个Json字段后分组排序	耗时8分钟	纯SQL难以执行，只能通过脚本+SQL分批读取
报表查询：6000w的数据根据某一字段过滤，并关联d表800w数据	耗时12秒	耗时3分53秒
数据导出需求：读取5个月的a表3000w数据，关联b表460w数据、关联c表500w数据、关联d表800w数据	耗时20秒	耗时1分52秒

在实际业务中，以一些大批量历史数据的分析和导出需求为例，原需要脚本开发+SQL花费约1~2天的人日，现在通过Doris SQL只需要花费约2小时即可完成

五、总结与展望

5.1 总结

本文主要介绍了OLAP技术及其在现代数据处理中的重要性，特别是针对高性能分析型数据库Apache Doris的应用进行了详细探讨。

首先，我们从OLAP的基本概念出发，阐述了OLAP与OLTP的区别，以及主流OLAP数据库的特点和分类。

然后重点分析了Doris在OLAP领域的创新和优势，包括其MPP架构、向量化查询引擎、Join优化、自适应查询执行和联邦查询等功能。

最后，通过具体案例展示了Doris在云平台上的多种应用场景，如BI看板、统一业务数仓、用户标签/画像和日志分析加速等。

5.2 展望

结合前面章节总结的Doris优劣势，未来我们可以考虑在以下场景中使用Doris实现：

1.  数据读密集写稀疏，且写入更偏向于批量写入；
2.  用于查询日志（写入后基本不变）的数据库；
3.  需要跨库、跨数据源进行关联查询；

目前大数据Doris已经接入Archery系统，其他业务组同事可通过工单申请权限来查询和操作Doris的内部表和外部表，例如日志表、记录表等大批量数据，但暂不支持对外部数据源的数据库及表级别权限管理，这部分待后续调研解决中