开源大数据 OLAP 引擎最佳实践

01 开源 OLAP 综述

​

​如今的开源数据引擎多种多样，不同种类的引擎满足了我们不同的需求。现在 ROLAP 计算存储一体的数据仓库主要有三种，即 StarRocks(DorisDB)，ClickHouse 和 Apache Doris。应用最广的数据查询系统主要有 Druid，Kylin 和 HBase。MPP 引擎主要有 Trino，PrestoDB 和 Impala。这些引擎在行业内有着广泛的应用。

​

​02 开源数仓解决方案

接下来，我们讲讲开源大数据以及数仓的解决方案。上图是 EMR 的整体架构，在云资源层，主要有 ECS。在存储层的 JindoFS 提供了以 OSS 为基底的 Hadoop 接口，不但节约了成本，而且提升了整体的扩展性。数据湖格式有效解决了数据统一管理的难题。其次在计算引擎方面，它具有批处理，流式计算，机器学习和引擎加速等能力。

​

目前，大家应用最多的离线数仓体系是 Lambda 架构。该架构主要分为两个部分。

第一部分，在实时方面我们从 CDC,ORTP 的数据源开始，进行行为数据分析，然后通过 Kafka，Flink 进行加工。让数据在线系统，可以直接调用 API，提升点查效率。其次，当所有聚合的数都导入 Olap 系统时，运营人员可以快速用它，实现自己新的想法，提升工作效率。第二部分，在离线方面当需要长久保存数据时，大家都会使用 hive。如果没有增量数据库格式，大家一般通过 insert overwrite，在 detail 上做一些数据集市。除此之外，我们通过离线 t+1 的方式，实现离线数仓的实时数据订正。因为实时数据一般得出的是近似值，离线数据得到的是准确值。

第三部分，实时数据湖的解决方案，其数据量在 PB+级别。我们希望统一离线和实时数仓，用一套代码构建业务。数据湖的数据存储在 OSS/HDFS，由于我们的部分业务有 Upsert 变更需求，所以我们希望建设分钟级到小时级的数仓。能够将最热的数据导入 StarRocks/CK，OLAP 的查询时长保证在 500 毫秒到 2 秒之间。与此同时，我们利用 Presto 查询 Hudi/Iceberg/Delta 时，其速率能够保证在 5 秒至 30 秒之间。

​

上图是比较传统的实时数仓方案。当每天增量数据达到 10TB+，我们希望直接以单软件构建业务底座，让数据先存储在 CK/StarRocks，让冷数据转存到 OSS。不必再运维 Hadoop 的庞大体系，极大简化运维操作，可以媲美全托管。

​

第二种实时数仓的解决方案，我们通过 micro-batch 任务调度器去处理 DWS，DWD 和 ODS。其实时性非常强，极大简化了开发效率，数据的一致性最高。后续我们将推出存算分离方案，用 OSS 存储海量数据，用 Cache 加速热数据。

​

03 ClickHouse 介绍

ClickHouse 是面向联机分析处理（OLAP）的开源分析引擎。最初由俄罗斯第一搜索引擎 Yandex 开发，于 2016 年开源，开发语言为 C++。由于其优良的查询性能，PB 级的数据规模，简单的架构，在国内外公司被广泛采用。

它是列存数据库，具有完备的 DBMS 功能，备份列式存储和数据压缩。它的 MPP 架构易于扩展，易于维护。除此之外，它支持向量化的查询，完善的 SQL 以及实时的数据更新，查询速度可以达到亚秒级的响应。

​

那么 ClickHouse 的查询速度为什么会这么快呢？它类似于 LSM tree,所有数据都是经过有序排列，提前做好聚合计算，再存储。并且它的数据存储格式自带索引。其次，ClickHouse 可以基于多个 Key 创建索引。它的二级索引采用 Data skipping index。

ClickHouse 的应用场景主要有四个方面。

第一，用户行为分析。ClickHouse 将用户行为分析表制作成一张大的宽表，减少 join 的形式，实现路径分析、漏斗分析、路径转化等功能。除此之外，它还能支撑广告，营销和 AB 实验。

第二，实时 BI 报表。ClickHouse 可以根据业务需求，实时制作及时产出，查询灵活的 BI 报表，包括订单分析，营销效果分析，大促活动分析等等。

第三，监控。ClickHouse 可以将系统和应用监控指标通过流式计算引擎 Flink,Spark streaming 清洗处理以后，实时写入 ClickHouse。结合 Grafna 进行可视化展示。

第四，用户画像。ClickHouse 可以对各种用户特征进行数据加工，制作成包含全部用户的一张或多张用户特征表，提供灵活的用户画像分析，支撑广告，圈人等业务需求等等。

接下来，我们讲讲 EMR ClickHouse 架构。我们在 ClickHouse 的基础上做了一定的增强。首先，我们重构了 In Memory Part 写入模块，让它支持 Flink 单条写入，Flink Exactly Once 事务写入以及 Sharding Key 写入。成功解决了写 Distributed 表的痛点，提升了整体性能。其次，它还支持 DiskOSS。实现了冷热的分层存储，节约了成本。最后，我们实现了副本扩容和分片扩容，让扩容方式变得更灵活。

​

04 StarRocks 介绍

接下来，我们聊一聊 StarRocks。StarRocks 其向量化的执行引擎，实现了亚秒级查询延时。StarRocks 单节点 100M/秒的写入速度，让它每秒可处理 100 亿行数据。StarRocks 的综合查询速度比其他产品快 10 到 100 倍。数据秒级实时更新可见。其次，StarRocks 支持数千用户同时分析，部分场景每秒可支持 1 万以上的 QPS，TP99 控制在 1 秒以内。最后，StarRocks 基于多种数据模型，实现了极速分析，缩短业务交付时间。提升了数据工程师和分析师工作效率。

​

如上图所示，StarRocks 的架构简洁明了，兼容 MySQL 协议，可使用各类 MySQL 客户端。并且支持 FE、BE 的水平扩展，从而实现自动均衡。让运维和使用都非常方便。

StarRocks 的极速引擎，实现了全面向量化执行。它可以按列存储，按列计算。用更少的虚函数调用，更少的分支判断，更好地利用 SIMD 指令并且对 CPU Cache 更友好。其次，StarRocks 向量化提升的效果明显。向量化 Filter，向量化聚合和向量化 Shuffle Join 的效果都有几何倍数的提升。

​

StarRocks 的极速引擎，具有全新的 CBO。基于 Orca 论文，将表达式重写、表达式复用。用公共谓词提取、谓词推导。将子查询改写，调整 Join 顺序、让 Join 算法自动选择。成功的将 SQL 语句转化为一个可执行 Plan。

StarRocks 的极速引擎，具有多种分布式的 Join。目前，这种分布式 Join 是 ClickHouse 比较缺乏的功能。右图是更加高效的 Join 方式，它通过提前完成 bucket 分类，让整体运行更加高效。

​

StarRocks 为全场景提供了四种数据模型。

第一，明细模型。用于保存和分析原始明细数据，数据写入后几乎无更新。主要用于日志，操作记录，设备状态采样等等。

第二，聚合模型。用于保存，分析，汇总数据。不需要查询明细数据。数据导入后实时完成聚合，数据写入后几乎无更新。适用于按时间、地域、机构汇总的数据。

第三，主键模型。支持基于主键的更新，Delete and insert，大批量导入时保证高性能查询。用于保存和分析需要更新的数据。

第四，更新模型。支持基于主键的更新，Merge On Read，更新频率比主键模型更高。用于保存和分析需要更新的数据。主键模型和更新模型都适用于状态会发生变动的订单，设备状态等。

​

StarRocks 在全场景中，还实现了高并发的查询。StarRocks 的分区机制可以高效过滤，提升查询性能。StarRocks 的分桶机制充分发挥了集群的性能，成功避免了热点问题。但 StarRocks 相对于其他的 OLAP 引擎和行存的 OLTP 引擎还有一定的差距。

​

在 LakeHouse 场景中，StarRocks 的联合查询，不但屏蔽了底层数据源的细节，而且可以对异构数据据源数据联合分析，与增量数据湖格式完美结合。为了提升查询速度，StarRocks 对每种数据源，进行针对性优化。增强了向量化解析 ORC、Parquet 格式，字典过滤，延迟物化等能力。

​

StarRocks 除了极致的引擎性能和全场景优化的能力，它还实现了弹性伸缩，支持在线扩容，让运维变得简单。面对流量增长，用户不但可以按需伸缩，节省成本。StarRocks 还支持小规模初始集群的逐步扩容，大大节省了运维成本。

​

05 Trino 介绍

如上图所示，EMR 的数据湖架构以 OSS 和 HDFS 作为数据湖的存储层。在存储层的基础上，精心安装了存储优化器，主要是 JindoFS 和 ALLUXIO 系列。在存储格式方面，EMR 的数据湖支持 Hudi,Iceberg 和 ORC 等格式。在计算层，它支持多种计算，比如 Flink,SPARK,Trino 和 Hive 等等。

接下来，我们看看 EMR Trino 的特性。首先在稳定向方面，EMR Trino 支持内置 Coordinator HA 赫尔 Worker Label 功能。由于 EMR Trino 集成了 EMR 弹性伸缩的能力，并且支持 Trino on K8s 产品形态，所以它大大节省了运维成本。在生态方面，EMR Trino 不但支持 Iceberg、Hudi、Delta Connector 等云上生态，而且支持优化的 ClickHouse、Hive 等 Connector。在性能方面，EMR Trino 针对 Parquet/Orc 等格式，进行优化。并且利用 JindoFS 的缓存层加速数据湖查询。大幅提升了查询效率。

​

06 客户案例

最后，我们一起聊几个客户案例。如上所示，这是一家在线教育客户。它每天的数据量高达几十亿条，同时还存在订单数据变更，特征人群圈选，机器学习训练等需求。原有的解决方案，存在数据处理不及时，无法应对 Upsert 场景，并且拉链表笨拙，耗费资源大。经过改造之后，完美支持 Upsert 场景，Presto 可以查询明细数据，CK 的宽表数也可供 Ad-hoc 查询，CK 的物化视图供 BI 系统查询。

上图是社交领域客户的架构图。它每天有 5TB 的数据规模，需要支持实时大屏，业务系统点查和业务人员随机查询。在改造之前，Hive 是分钟级数仓，它面临算不完，查不出，系统运维复杂的痛点。我们将宽表查询落入 CK 和 Ad-hoc 查询，将明细表落入 StarRocks，实现了复杂 Ad-hoc 查询，报表分析，物化视图点查能力。让数据仓库的运维变得简单高效。

上图是某电商领域的客户，它的大量业务依赖 OLTP 系统，在 GMV，订单，物流，客户分析，推荐系统等方面，都有升级的需求。原先的 Hadoop 数仓和离线 T+1 分析系统的方式，让整个系统运维复杂，成本居高不下。我们将 OLTP 系统逐步过渡到 OLAP 系统，替代了原有数仓结构的同时，让链路变得极其简化，让 Ad-hoc 查询灵活，方便运维人员分析细节数据，对接线上系统点查。简化系统的同时，提升了运维人员的工作效率，大幅降低了运维成本。