开源 OLAP 及其在不同场景下的需求

本文主要是介绍开源 OLAP 及其在不同场景下的需求，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、开源 OLAP 综述

二、OLAP场景思考

2.1 面向客户的报表

2.2 面向经营的报表

2.3 末端运营分析

2.4 用户画像

2.5 订单分析

2.6 OLAP技术需求思考

三、开源数据湖/流式数仓解决方案

3.1 离线数仓体系——Lambda架构

3.2 实时数据湖解决方案

3.3 实时分析解决方案—Flink流式数仓

3.4 实时分析解决方案—SR物化视图

四、StarRocks介绍

4.1 极速统一的新一代数据架构

4.2 架构

4.3 核心能力

4.3.1 全面向量化引擎

4.3.2 CBO

4.3.3 分布式join

4.3.4 实时分析

4.3.5 数据湖分析

4.3.6 资源隔离

4.3.7 副本自动平衡

五、未来规划

原文大佬介绍的这篇开源OLAP数据架构有借鉴意义的，这些摘抄下来用作沉淀学习。如有侵权，请告知~

一、开源 OLAP 综述

近年来开源领域涌现出众多优秀产品，如StarRocks，Doris,湖数据，湖格式，Spark 以及早期的 HBase、Presto 等。种类繁多的开源产品工具为用户带来了便利，同时也带来了选择难题。

上图中对各种数据库做了简单的分类。例如，StarRocks,Doris 和 CK 等，它们在过去主要是存算一体的AP数据库。而Presto、Trino 和Impala等则是经典的基于Hadoop的MPP引擎。此外，Kylin、Hbase 和 Druid 等在预处理方面有较多应用。还有一类是近年来流行的湖格式（湖存储）工具，其中包括 Delta lake、Hudi、Iceberg，以及几个月前刚孵化的Apache Paimon 等。

二、OLAP场景思考

OLAP场景涉及的技术栈众多，应该如何选择呢？回答这个问题，首先从场景层面去思考，OLAP涉及的典型业务场景包括，面向用户的报表，面向经营的报表，用户画像，运营分析，订单分析及自助分析等。

2.1 面向客户的报表

面向广告主，门店经理以及ToB端的报表业务，这些场景有一个共同点，即需要根据用户的User ID等属性进行快速检索，对查询性能有较高要求，同时存在一定量的并发请求。当然，这里的并发与 ToC 的场景有所不同。

针对这些特点，一款优秀的OLAP引擎在技术上应满足以下要求：首先，具备前缀索引功能，这些在构架好索引之后，查询性能将得到显著提升；其次，向量化引擎也是一个重要趋势，最早由CK提出，如今许多引擎都在朝这个方向发展，向量化确实能够在很大程度上提高查询速度；此外，数据分布的均衡和自动反向处理也是关键，有助于避免数据倾斜等问题。

2.2 面向经营的报表

经营报表类场景汇总，例如实时大屏展示，实时风控，实时监控和审计等业务，它们的核心需求是数据的实时性，即在业务数据写入后，尽可能尽早的获取到这些数据。实时性的重要性在于，它会影响后续策略响应的速度。同时，在查询过程中，我们希望查询性能足够优秀。此外，这些业务还有一个重要特点，即需要对接商业化的BI工具。这意味着我们的SQL处理流程需要具备较高的多样性，以满足不断变化的分区需求。在此基础上，我们还需要对数据模型进行精细化设计，以满足多样化的需求。

2.3 末端运营分析

末端运营分析类场景，例如链家等企业的经纪人绩效计算以及买菜类应用的团长报表等。这些业务的一个共同特点是，经纪人不断变动，组织架构频繁调整，导致尾表变化愈发频繁。此外，这些业务对查询性能和数据可见性有一定要求。最重要的特点是计算逻辑复杂，即join条件繁多。因此OLAP引擎要能够支持灵活的数据模型，而不仅仅局限于大宽表。针对新型join支持方面，当前市面上的部分产品仍不够完善。为了提升性能，普遍希望在物化视图等方面具备一定能力。

2.4 用户画像

在用户画像这一业务场景中，面临的主要需求是大宽表的处理。CK引擎在用户画像领域得到了广泛应用。然而，某些场景下需要处理不同标签的组合查询。此外，用户画像业务对精确去重有较高要求。从引擎侧来看，需要支持大宽表以满足业务需求。然而，更新大宽表时，不能每次都能更新两三千列数据，因此更新能力显得尤为重要。此外，多流 join 支持以及 join 查询能力优化也是关键。在此基础上，还要求引擎支持 bitmap 精确查询，以满足用户画像业务的高效处理需求。

2.5 订单分析

订单分析场景中，数据实时性和复杂的查询逻辑是两个核心要点。实际上，回顾前面提到的各个场景，我们会发现订单分析场景与其他场景在业务特点和技术要求方面存在一定程序的共性。

订单分析业务对实时性有较高要求，以便快速响应业务变化。同时，由于订单数据的丰富性和多样性，查询逻辑往往较为复杂。这意味着我们需要为订单分析场景提供高性能、易用且支持复杂查询的解决方案。

2.6 OLAP技术需求思考

在打造一款OLAP引擎产品时，需要重点关注以下几个基础方面：

首先，强化多表关联（join）的能力支持，包括功能层面的语法支持和性能层面的优化。多表关联是OLAP查询的核心环节，对于处理复杂数据场景至关重要。
其次，现代化引擎解决方案的必备能力，如CBO（Cost-Based Optimization ）和向量化查询等。这些能力可以使产品在市场上具有竞争力，更好的解决各类业务场景问题。
此外，并发能力也是一项重要指标。在高并发场景下，OLAP 引擎需要具备稳定的性能表现和扩展性。在数据写入方面需要提高性能，高效的数据写入能力有助于 OLAP 产品更好地满足业务场景需求。
其他方面包括功能和架构的优化，如开发效率，UDF（用户自定义函数）支持等。以java udf为例，相比C++ UDF，java的易用性更高，有利于提高开发效率。

最后，还要考虑架构的运维便利性。良好的 OLAP 产品应具备简洁的运维方式，便于平台侧进行管理和维护。

三、开源数据湖/流式数仓解决方案

下面介绍阿里云 EMR（E-MapReduce）平台上常见的开源数据仓库和数据湖的架构。EMR 基础架构的最底层是云资源，主要包括ECS(弹性计算服务)和ACK（阿里云容器服务）。在此基础上，采用调度器来协调和控制数据处理流程。此外，我们还提供 JindoFS，这是一种与 Hadoop 兼容的分布式文件系统，便于用户存储和管理数据。

3.1 离线数仓体系——Lambda架构

接下来进一步讨论阿里云 EMR 平台上计算引擎的多样化应用，包括离线批处理、实时 Flink 以及 OLAP 相关引擎。目前，典型的数据仓库架构仍以离线批处理为主。这种架构中，实时数据通过 CDC 技术收集，并通过 Kafka 等消息队列传输至 Flink 等实时处理引擎。经过处理后的数据直接落地到 OLAP 引擎，以支持快速数据分析。

离线部分主要包括 ODS/ DWD 等分层，采用传统的 Hive 技术进行数据处理。然而，这种架构中实时与离线数据处理相对独立，因此数据一致性（数据对齐）成为一个常见问题。

为解决这一问题，近年来兴起了近实时数据湖架构，如 Delta、Iceberg、Hudi 等。这些新型数据存储格式旨在提高数据存储和处理的性能，同时简化数据对齐问题。新兴的 Apache Paimon 也为解决数据对齐问题提供了有效支持。

3.2 实时数据湖解决方案

实时数据湖架构也是 EMR 平台上常见的一种数据处理架构。在这种架构中，实时数据从 CDC 模式或直接从 Kafka 摄入，并在各个层次上进行增量处理。相较于 Lambda 架构，实时数据湖架构在数据链路上实现了统一，从而降低了数据校验等环节的工作量。

在这种架构中，常见的 OLAP查询引擎直接访问数据湖，或者作为末端的 ADS层为业务部门提供服务。通过实时数据湖架构，企业可以更高效地处理和分析数据，进而提升业务决策的敏捷性和准确性。

3.3 实时分析解决方案—Flink流式数仓

下面来描述一个典型的数据仓库架构。在该架构中，借助 Kafka 作为消息队列，使用 Flink 进行各层次的数据处理。同时，将处理后的数据同步到类似 StarRocks 的分析型数据库，以提高用户分析的性能。

3.4 实时分析解决方案—SR物化视图

基于StarRocks 进行实时数据分析，其优势包括当前应用以及未来可能的演进方向。在这种架构中，我们采用物化视图策略，首先将基础数据同步到 StarRocks 内部。然后，通过离线物化视图的批量调度能力，实现各层次数据的刷新。

这种架构的主要优势在于，整个数据分析过程都在StarRocks引擎内完成，降低了引入复杂引擎和组件的需求，从维护角度来看，这种架构使得平台更加简洁，方便运维和管理。

四、StarRocks介绍

StarRocks 的核心优势在于，它能够有效应对前面所提及的各种场景。它具有如下四个关键特点：

高查询性能：StarRocks 以其卓越的查询性能脱颖而出，能够迅速返回查询结果，满足用户对实时数据的需求。
高效数据导入：StarRocks 在数据导入方面表现出色，具有较高的吞吐量和较小的延迟，能够保证数据的快速导入和同步。
良好的并发支持：StarRocks 具备强大的并发处理能力，可支持多个并发任务同时进行，提高系统性能和利用率。
丰富的数据模型：StarRocks 提供了多样化的数据模型，便于进行多维数据分析。用户可以根据实际需求，选择合适的数据模型进行数据处理和分析。

4.1 极速统一的新一代数据架构

在业务侧的整体分层架构中，StarRocks 在分析层发挥着关键作用。它实现了极速统一的解决方案，能够覆盖前面提到的各种业务场景。通过 StarRocks 的高性能、高吞吐量、低延迟等特点，用户可以快速地获取数据，实现高效的数据分析。在此基础上，StarRocks 丰富的数据模型支持多种数据处理和分析方式，进一步满足用户在多维数据分析方面的需求。

以 StarRocks 为核心，包括数据导入、查询等等在内，整个生态链路完备。

4.2 架构

StarRocks 具有架构清晰、简单的特点。整体上，分为两个角色：FE和BE。FE主要负责查询解析和优化，生成物理执行计划。FE采用了高可用设计，确保在出现故障时能够进行容错处理。通过内部实现的一致性协议元数据同步，即使在FE宕机的情况下，系统也能保持稳定运行。BE在存算分离之前，扮演计算执行引擎和存储引擎的角色。BE通常采用多副本策略，以确保数据安全。当某台BE宕机时，数据系统会自动进行迁移，不会影响查询性能。同时，系统具备自愈功能，能够在其他机器上自动补全缺失的副本，保证数据的完整性和一致性。

4.3 核心能力

4.3.1 全面向量化引擎

从性能层面来看，全面向量化引擎是 StarRocks 的一个重要特点。之所以强调“全面”，是因为只有在整个处理链路上都没有短板，才能实现高效的向量化引擎。目前市场上许多产品都声称具备向量化能力，但真正能实全面向量化的引擎并不多。

StarRocks 全面向量化引擎的优势表现在以下几个方面：

避免性能瓶颈：全面向量化引擎在Shuffle 和 Join等环节都能高效处理数据，避免了单一环节成为性能瓶颈。
更高的查询性能：通过引入向量化技术，StarRocks 在核心计算环节相对于传统引擎有显著优势。例如，虚函数调用和 CPU 调度等操作都能实现高效优化。
优化系统资源利用：全面向量化引擎能够更充分地利用系统资源，进一步提高整体性能。

4.3.2 CBO

第二个对性能有重大影响的是StarRocks采用了代价驱动的优化策略（CBO）。CBO主要针对Join场景，通过计算每个Join操作的代价，动态调整Join顺序和优化查询计划。通过 CBO，StarRocks 能够实现 Join 操作的顺序调整和改写，从而支持多种 Join 类型，使其在复杂业务场景下具有优越的性能。

4.3.3 分布式join

StarRocks 在 Join 操作方面主要支持两种模式：Shuffle Join和Colocation Join。这两种模式组合集合可以实现高效的数据处理和分析。

Shuffle Join：包括 Broadcast Join 在内的 Shuffle Join 模式，主要用于总体汇总场景。在这种模式下，StarRocks 通过对数据进行随机分发和重组，实现不同表之间的 Join 操作。
Colocation Join：针对某些特殊业务场景，StarRocks 建议使用 Colocation Join 方式。这种模式可以根据业务需求，保证两张表的数据分布完全一致，在查询过程中，避免了远端数据传输带来的延迟，提高了处理效率。

4.3.4 实时分析

前面介绍了 StarRocks 在查询侧的关键性能优化点，接下来介绍导入侧的特点。在实时分析链路图中可以看到，StarRocks 支持实时导入组件模型。

组件模型相对于传统更新模型（如 Doris 早期的更新模型）在设计上进行了优化，实现了写入和查询之间的性能平衡。在传统更新模型中，导入速度较快，但查询时可能需要合并多个小文件，导致内存操作较重。

组件模型的核心优势在于：

引入主键索引：在导入数据时，StarRocks 首先创建主键索引，以便知道写入的 key 在哪个历史文件中。基于这个信息，可以更新 DELETE 信息以避免无效查询。
高效的实现：尽管引入了主键索引，但 StarRocks 保证了写入性能不会受到太大影响。这是因为主键索引的实现较为高效，整体上与传统导入方式的速度差距不大。
查询性能优化：由于有了 deliver vector 信息，StarRocks 无需进行排序合并。同时，谓词可以进行下推，进一步提高查询性能。
物化视图：StarRocks 从 2.5 版本开始，对物化视图的支持较为完备。物化视图可以大幅提高实时分析的性能，尤其是针对增量数据。

4.3.5 数据湖分析

StarRocks 致力于为用户带来更好的分析体验，特别是在查询性能方面。为了实现这一目标，StarRocks 重点关注了用户分析相关的工作，希望能够吸引 Presto 和 Impala 等产品的用户，让他们能够在 StarRocks 上享受到上层查询优化能力，同时不影响性能。

StarRocks 在这方面取得了显著的成果。如下图所示，相对于 Trino、Presto 等竞争对手，StarRocks 在大多数基准测试和实际客户案例中，性能提升了 3-5 位。这一成果得益于 StarRocks 不断优化查询引擎和底层架构，为用户提供了更高效、稳定的分析解决方案。

4.3.6 资源隔离

从 2.3 版本开始，StarRocks 推出了 pipeline引擎，旨在进一步提高 CPU 利用率。在并发场景下，基于pipeline引擎，StarRocks能够实现较为良好的资源隔离能力。这种能力使得StarRocks在处理大小查询以及ETL任务时，能够尽量弹性地进行资源分配。例如，当某些ETL任务较为繁重时，如果没有资源隔离，其他在线查询任务可能会受到较大影响。而 StarRocks 的资源隔离能力则可以有效降低这种影响，确保系统稳定运行。

资源隔离是 StarRocks 核心能力之一，对于并发场景具有显著的优化效果。通过提高 CPU 利用率和完善资源隔离机制，StarRocks 能够为用户提供更高效、稳定的分析解决方案，满足各种复杂场景下的需求。

4.3.7 副本自动平衡

最后一项核心能力是数据间的均衡。散落的数据之间的均衡依赖于存储和计算的分离，这种分离使得StarRocks 能够实现弹性的扩容。当添加新节点时，StarRocks 能够自动将数据均衡分布到新节点上，确保每个节点的存储量均衡。在副本方面，即使出现丢失的情况，StarRocks 也能自动进行恢复。只要确保多副本中至少有一个副本可用，StarRocks 就能保证数据的完整性和可靠性。

五、未来规划

StarRocks 3.x 版本演进的关键点包括：

存储和计算分离：这是 StarRocks 3.x 版本的核心优化之一。
Lake House：StarRocks 3.x 版本将支持硬字联合力，使得在存储和计算分离的基础上，实现多仓库、多作业的能力变得更加便捷。此外，针对 ETL 场景，StarRocks 也在不断优化和完善产品自身能力。
场景优化：去年，StarRocks 重点关注了 Big House 场景，并已实现较为成熟的能力。目前，许多客户正在使用这一场景。建议关注这一场景的用户进行尝试。
ETL能力优化：StarRocks针对算落盘等场景进行了重点优化，并支持增量物化视图。实时更新物化视图的同时，导入端也实现了统一
简化用户体验：StarRocks 致力于简化导入方式，降低用户学习成本。针对不同场景，StarRocks 提供了相应的导入方式。例如，Snowflake 在这方面做得非常好，StarRocks 也将借鉴其经验，优化用户体验。
半结构化数据类型支持：针对数据库场景，StarRocks 3.x 版本增加了对半结构化数据类型的支持，以满足此类场景用户的需求。

总之，StarRocks 3.x 版本在多个方面进行了优化和升级，包括存储和计算分离、Lake House、ETL 能力、用户体验以及半结构化数据类型支持等。这些改进将帮助用户更高效地应对各种业务场景，提升大数据分析的处理性能。

参考文章：

开源大数据 OLAP 的思考及最佳实践

这篇关于开源 OLAP 及其在不同场景下的需求的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！