开源 OLAP 综述
近年来，开源领域涌现出许多优秀的产品，如Starrocks、Doris、Lake Data、Lake Format、Spark，以及早期的HBase和Presto。 种类繁多的开源工具给用户带来了便利，但也提出了一个艰难的选择。
上图提供了各种数据库的简单分类。 例如，StarRocks、Doris 和 CK 曾经是集存储和计算于一体的 AP 数据库。 Presto、Trino 和 Impala 是基于 Hadoop 的经典 MPP 引擎。 此外，麒麟、HBase、Druid 在预处理中还有很多应用。 还有一类近年来开始流行的湖泊格式（湖泊存储）工具，包括几个月前刚刚孵化的Delta Lake、Hudi、Iceberg和Apache Paimon。
OLAP 场景思维
OLAP场景涉及很多技术栈，应该如何选择？ 要回答这个问题，我们首先在场景层面思考。 OLAP涉及的典型业务场景包括面向用户的报表、面向业务的报表、用户画像、运营分析、订单分析和自助分析。
对于广告主、店铺管理员和ToB报表服务来说，这些场景有一个共同的特点，那就是需要根据用户ID等属性快速检索用户，这些属性对查询性能要求很高，并发请求量也有一定的要求。当然，这里的并发性与TOC场景不同。
鉴于这些特点，一个优秀的OLAP引擎在技术上应该满足以下要求：首先，它应该具有前缀索引功能，这样在索引构建后，查询性能会明显提高; 其次，矢量化引擎也是一个重要的趋势，这是CK最早提出的，现在正朝着这个方向发展，矢量化确实可以在很大程度上提高查询速度; 此外，数据分布的均衡和自动逆向处理是帮助避免数据偏斜等问题的关键。
在业务报表场景下，如实时大屏展示、实时风控、实时监控、审计等，核心要求是数据的实时性，即业务数据写入后，能够尽早获取数据。 实时的重要性在于它会影响后续政策响应的速度。 同时，我们希望查询性能在查询过程中足够好。
此外，这些业务的一个重要特征是它们需要与商业BI工具进行交互。 这意味着我们的 SQL 处理流程需要高度多样化，以满足不断变化的分区需求。 最重要的是，我们还需要完善数据模型以满足不同的需求。
线下线分析场景，如联佳等企业的经纪人业绩计算、杂货店购物应用集团负责人的报告等。 这些业务的一个共同特点是经纪商在不断变化，组织架构频繁调整，导致尾盘变化更加频繁。
此外，这些服务对查询性能和数据可见性有一定的要求。 最重要的特征是计算逻辑的复杂性，即连接条件的多样性。 因此，OLAP 引擎需要能够支持灵活的数据模型，而不限于大型和宽型表。 在对新加入的支持方面，目前市场上的一些产品仍然不足。 为了提高性能，人们通常希望在物化视图中具有某些功能。
在用户画像的业务场景中，主要需求是处理大宽表。 CK引擎在用户画像领域得到了广泛的应用。 但是，在某些情况下，您需要处理不同标签的组合。 此外，用户画像业务对准确的重复数据删除有很高的要求。
从引擎侧来看，需要支持大而宽的表来满足业务需求。 但是，在更新大型和宽表时，您不能一次更新两三千列数据，因此更新能力尤为重要。 此外，多流联接支持和 JOIN 查询能力优化也是关键。 在此基础上，还需要引擎支持位图精准查询，满足用户画像业务的高效处理需求。
在阶次分析场景中，实时数据和复杂的查询逻辑是两个核心点。 事实上，回顾前面提到的场景，我们会发现，订单分析场景与其他场景在业务特征和技术需求方面存在一定程度的共性。
订单分析业务对实时性能有很高的要求，以便快速响应业务变化。 同时，由于订单数据的丰富性和多样性，查询逻辑往往很复杂。 这意味着我们需要一个高性能、易于使用的解决方案来支持订单分析场景的复杂查询。
在构建OLAP引擎产品时，需要关注以下几个基本方面：
首先，我们需要加强连接多个表的能力，包括功能层面的语法支持和性能层面的优化。 多表联接是 OLAP 查询的核心部分，对于处理复杂的数据场景至关重要。
其次，现代引擎解决方案具有必要的功能，例如基于成本的优化 （CBO） 和矢量化查询。 这些能力可以使产品在市场上具有竞争力，更好地解决各种业务场景中的问题。
此外，并发容量也是一个重要的指标。 在高并发场景下，OLAP引擎需要具备稳定的性能和可扩展性。 在数据写入方面，性能有待提升，高效的数据写入能力可以帮助OLAP产品更好地满足业务场景的需求。
其他方面包括功能和架构优化，例如开发效率、UDF（用户定义函数）支持等。 以 J**A UDF 为例，与 C++ UDF 相比，J**A 更易于使用，有利于提高开发效率。
最后，考虑架构的易操作性和维护性。 一个好的OLAP产品应该有一个简单的运维方法，在平台端易于管理和维护。
开源数据湖流式数据仓库解决方案
下面介绍阿里云e-MapReduce（e-MapReduce）平台上的开源数据仓库和数据湖架构。 首先，我们来谈谈EMR的整体架构。
EMR基础设施的最底层是云资源，主要包括ECS和阿里云容器服务（ACK）。 在此基础上，我们使用调度器来协调和控制数据处理过程。 此外，我们还提供Jindofs，这是一种与Hadoop兼容的分布式文件系统，使用户可以轻松存储和管理数据。
接下来，我们将进一步讨论计算引擎在阿里云EMR平台上的多样化应用，包括离线批处理、实时Flink和OLAP相关引擎。
目前，典型的数据仓库架构仍以离线批处理为主。 在这种架构中，实时数据通过 CDC 技术收集，并通过消息队列（如 Kafka）传输到 Flink 等实时处理引擎。 处理后的数据直接登陆OLAP引擎，支持快速数据分析。
离线部分主要包括ODS DWD等分层，采用传统的Hive技术进行数据处理。 然而，在这种架构中，实时和离线数据处理相对独立，因此数据对齐成为一个普遍的问题。
为了解决这个问题，近年来出现了近实时的数据湖架构，如delta、iceberg、hudi等。 这些新的数据存储格式旨在提高数据存储和处理的性能，同时简化数据对齐。 新兴的Apache Paimon也为解决数据对齐问题提供了有效的支持。
实时数据湖架构也是EMR平台上常见的数据处理架构。 在此体系结构中，实时数据从 CDC 架构或直接从 Kafka 引入，并在各个级别进行增量处理。 与lambda架构相比，实时数据湖架构在数据链路上统一，从而减少了数据校验等环节的工作量。
在此架构中，通用的OLAP查询引擎直接访问数据湖，或作为ADS层的末端为业务部门提供服务。 借助实时数据湖架构，组织可以更高效地处理和分析数据，从而提高业务决策的敏捷性和准确性。
让我们描述一个典型的数据仓库体系结构。 在这种架构中，Kafka 用作消息队列，Flink 用于各个级别的数据处理。 同时，将处理后的数据同步到像星石这样的分析数据库中，以提高用户分析的性能。
基于Starrocks的实时数据分析的好处包括当前的应用和未来可能的演化方向。 在这种架构中，我们采用物化视图策略，首先将底层数据同步到 StarRocks。 然后，通过离线物化视图的批量调度能力，刷新各层级数据。
这种架构的主要优点是整个数据分析过程都是在Starrocks引擎中完成的，减少了引入复杂引擎和组件的需要。 从维护的角度来看，这种架构使平台更加简洁，易于操作和管理。
Starrocks 推出
让我们仔细看看 Starrocks 的架构和核心功能。
Starrocks的核心优势在于能够有效处理上述各种场景。 它具有以下四个主要功能：
高查询性能：StarRocks 以其卓越的查询性能脱颖而出，可以快速返回查询结果，满足用户对实时数据的需求。 高效数据导入：StarRocks 在数据导入方面表现出色，高吞吐量、低延迟，确保数据快速导入和同步。 良好的并发支持：StarRocks 具有强大的并发处理能力，可以同时支持多个并发任务，提高系统性能和利用率。 丰富的数据模型：Starrocks提供了多种数据模型，方便多维度数据分析。 用户可以根据自己的实际需要选择合适的数据模型进行数据处理和分析。
在业务端的整体分层架构中，Starrocks 在分析层发挥着关键作用。 它实现了一个极其快速和统一的解决方案，涵盖了前面提到的各种业务场景。 借助 Starrocks 的高性能、高吞吐量和低时延，用户可以快速获取数据并实现高效的数据分析。 在此基础上，星石丰富的数据模型支持多种数据处理和分析方式，进一步满足用户在多维度数据分析方面的需求。
以 StarRocks 为核心，整个生态系统完整，包括数据导入、查询等。
Starrocks 有一个清晰、简单的架构。 总体而言，它分为两个角色：FE 和 BE。
FE主要负责查询解析和优化，以及生成物理执行计划。 FE 旨在实现高可用性，以确保在发生故障时自动容错。 通过内部实现的一致性协议元数据同步，即使在 FE 停机的情况下，系统也能保持稳定。
BE在储算分离之前起到计算执行引擎和存储引擎的作用。 BE 通常采用多副本策略来确保数据安全。 当 BE 宕机时，数据系统会自动迁移，不会影响查询性能。 同时，系统具有自我修复功能，可以自动补全其他机器上缺失的副本，保证数据的完整性和一致性。
从性能角度来看，全矢量化引擎是 Starrocks 的一个重要特性。 之所以强调“全面”，是因为只有在整个处理链中没有缺点的情况下，才能实现高效的矢量化引擎。 目前市面上很多产品都声称具备矢量化能力，但真正能实现全面矢量化的引擎并不多。
Starrocks综合矢量化引擎的优势主要体现在以下几个方面：
避免性能瓶颈：全面的矢量化引擎可以高效地处理随机和联接的数据，避免单个链接成为性能瓶颈。 更高的查询性能：通过引入矢量化技术，StarRocks 在核心计算过程中比传统引擎具有显著优势。 例如，可以有效地优化虚拟函数调用和 CPU 调度等操作。 优化系统资源利用率：全面的矢量化引擎可以更好地利用系统资源，进一步提升整体性能。
第二个主要的性能影响是 Starrocks 采用了成本驱动的优化策略 （CBO）。 CBO主要针对联接场景，通过计算每个联接操作的成本，动态调整联接顺序，优化查询计划。 此图是行业参考经典**，显示了 CBO 引擎的工作原理。 CMU的相关课程中也引入了CBO。
通过CBO，Starrocks可以调整和改写联接操作的顺序，从而支持多种联接类型，使其在复杂的业务场景中具有优越的性能。 这也是StarRocks能够应对多种多回合场景的核心技术之一。
Starrocks 在加入操作方面主要支持两种模式：随机加入和托管加入。 这两种模式的结合可以实现高效的数据处理和分析。
Shaffle Join：随机加入模式，包括 Broadcast Join，主要用于整体汇总场景。 在这种模式下，Starrocks 通过随机分配和重组数据来实现不同表之间的连接操作。
主机托管加入：对于一些特殊的业务场景，StarRocks 推荐使用 Colocation Join 方式。 在这种模式下，根据业务需求，两表的数据分布是完全一致的。 在查询过程中，避免了远程数据传输造成的延迟，提高了处理效率。
前面介绍了 Starrocks 在查询端的关键性能优化点，接下来介绍了导入端的特性。 从实时分析链接图中可以看出，Starrocks 支持组件模型的实时导入。
组件模型在设计上对传统的更新模型进行了优化，比如 Doris 早期的更新模型，实现了写查询之间的性能平衡。 在传统的更新模型中，导入速度较快，但查询时可能需要合并多个小文件，导致内存操作繁重。
组件模型的核心优势是：
主键索引简介：在导入数据时，Starrocks 首先会创建一个主键索引，以便知道密钥写入哪个历史文件。 根据此信息，可以更新删除信息以避免无效查询。 高效实现：尽管引入了主键索引，但 Starrocks 保证写入性能不会受到太大影响。 这是因为主键索引的实现效率更高，整体速度与传统的导入方式没有太大区别。 查询性能优化：得益于 Deliver Vector 信息，Starrocks 无需排序和合并。 同时，可以下推谓词，进一步提高查询性能。 物化视图：2 中的星岩从版本 5 开始，对实例化视图的支持相对完整。 具体化视图可以显著提高实时分析的性能，尤其是对于增量数据。
Starrocks 致力于为用户带来更好的分析体验，尤其是在查询性能方面。 为了实现这一目标，Starrocks 专注于用户分析，希望吸引 Presto 和 Impala 等产品的用户，让他们在不牺牲性能的情况下享受 Starrocks 的上层查询优化能力。
Starrocks在这方面取得了显著的成绩。 如下图所示，在大多数基准测试和实际客户案例中，Starrocks 的性能比 Trino 和 Presto 等竞争对手提高了 3-5 位。 这一成绩的取得，得益于Starrocks对查询引擎和底层架构的不断优化，为用户提供了更高效、更稳定的分析解决方案。
以上是另一份业绩报告。
从 2从版本 3 开始，Starrocks 引入了 Pipeline 引擎，旨在进一步提高 CPU 利用率。 在并发场景下，Starrocks 可以基于流水线引擎实现更好的资源隔离。 这种能力使得 Starrocks 在处理大大小小的查询和 ETL 任务时，在资源分配上尽可能灵活。 例如，当某些 ETL 任务较繁重时，如果没有资源隔离，其他查询任务可能会受到很大影响。 Starrocks的资源隔离能力可以有效降低这种影响，保证系统的稳定运行。
资源隔离是StarRocks的核心能力之一，对并发场景具有显著的优化效果。 通过提高CPU利用率和完善资源隔离机制，Starrocks可以为用户提供更高效、更稳定的分析解决方案，以满足各种复杂场景的需求。
最后一个核心竞争力是数据平衡。 分散数据之间的平衡依赖于存储和计算的分离，这使得Starrocks能够弹性扩展。
当有新节点加入时，StarRocks 能够自动将数据均匀分布在新节点上，保证每个节点的存储容量均衡。 当涉及到副本时，即使丢失，StarRocks 也可以自动恢复它们。 只要多个副本中至少有一个可用，Starrocks 就保证了数据的完整性和可靠性。
规划未来
starrocks 3.X 版本演变的关键点包括：
存储和计算分离：这就是 Starrocks 3X 版本的核心优化之一。 lake house：starrocks 3.X版本将支持硬字并集，在存储和计算分离的基础上，更容易实现多仓库、多操作能力。 此外，对于ETL场景，Starrocks也在不断优化和提升自身能力。 场景优化：去年，StarRocks专注于大房子场景，并实现了更成熟的能力。 目前，许多客户正在使用此方案。 建议关注此场景的用户尝试一下。 ETL能力优化：StarRocks针对计算、放置等场景进行了优化，支持增量物化视图。 在物化视图实时更新的同时，导入端也是统一的。 简化用户体验：Starrocks 致力于简化导入方式，降低用户学习成本。 针对不同的场景，StarRocks 提供了相应的导入方式。 例如，Snowflake在这方面做得很好，Starrocks将从其经验中学习，以优化用户体验。 半结构化数据类型支持：对于数据库场景，Starrocks 3版本 X 增加了对半结构化数据类型的支持，以满足用户在此类场景中的需求。 简而言之，Starrocks 3X 版本包括多个领域的优化和升级，包括存储和计算分离、Lakehouse、ETL 功能、用户体验和半结构化数据类型支持。 这些改进将帮助用户更高效地响应各种业务场景，提高大数据分析的处理性能。