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

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 本篇内容分享了开源大数据OLAP引擎最佳实践。分享人:范振 阿里云高级技术专家

视频链接:https://developer.aliyun.com/adc/series/yunqiinternet/lookback8?spm=a2c6h.25893875.J_2523936200.2.2ff43919WXR1ts

本篇内容将通过六个部分来介绍开源大数据OLAP引擎最佳实践。
一、开源OLAP综述
二、开源大数据/数仓解决方案
三、ClickHouse介绍
四、StarRocks介绍
五、Trino/PrestoDB介绍
六、客户案例

一、开源OLAP综述
image.png

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

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

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

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

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

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

三、ClickHouse介绍
ClickHouse是面向联机分析处理(OLAP)的开源分析引擎。最初由俄罗斯第一搜索引擎Yandex开发,于2016年开源,开发语言为C++。由于其优良的查询性能,PB级的数据规模,简单的架构,在国内外公司被广泛采用。
它是列存数据库,具有完备的DBMS功能,备份列式存储和数据压缩。它的MPP架构易于扩展,易于维护。除此之外,它支持向量化的查询,完善的SQL以及实时的数据更新,查询速度可以达到亚秒级的响应。
image.png

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

ClickHouse地应用场景主要有四个方面。第一,用户行为分析。ClickHouse将用户行为分析表制作成一张大的宽表,减少join的形式,实现路径分析、漏斗分析、路径转化等功能。除此之外,它还能支撑广告,营销和AB实验。第二,实时BI报表。ClickHouse可以根据业务需求,实时制作及时产出,查询灵活的BI报表,包括订单分析,营销效果分析,大促活动分析等等。
第三,监控。ClickHouse可以将系统和应用监控指标通过流式计算引擎Flink,Spark streaming清洗处理以后,实时写入ClickHouse。结合Grafna进行可视化展示。第四,用户画像。ClickHouse可以对各种用户特征进行数据加工,制作成包含全部用户的一张或多张用户特征表,提供灵活的用户画像分析,支撑广告,圈人等业务需求等等。
image.png

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

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

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

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

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

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

StarRocks为全场景提供了四种数据模型。第一,明细模型。用于保存和分析原始明细数据,数据写入后几乎无更新。主要用于日志,操作记录,设备状态采样等等。第二,聚合模型。用于保存,分析,汇总数据。不需要查询明细数据。数据导入后实时完成聚合,数据写入后几乎无更新。适用于按时间、地域、机构汇总的数据。
第三,主键模型。支持基于主键的更新,Delete and insert,大批量导入时保证高性能查询。用于保存和分析需要更新的数据。第四,更新模型。支持基于主键的更新,Merge On Read,更新频率比主键模型更高。用于保存和分析需要更新的数据。主键模型和更新模型都适用于状态会发生变动的订单,设备状态等。
image.png

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

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

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

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

接下来,我们看看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的缓存层加速数据湖查询。大幅提升了查询效率。
image.png

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

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

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

阿里云大数据是为业务敏捷而生的简单、易用、全托管的云原生大数据服务。激活数据生产力,分析产生业务价值。详情访问:https://www.aliyun.com/product/bigdata/apsarabigdata

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
相关文章
|
2月前
|
SQL 缓存 分布式计算
【跨国数仓迁移最佳实践5】MaxCompute近线查询解决方案助力物流电商等实时场景实现高效查询
本系列文章将围绕东南亚头部科技集团的真实迁移历程展开,逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第5篇,解析跨国数仓迁移背后的性能优化技术。 注:客户背景为东南亚头部科技集团,文中用 GoTerra 表示。
152 8
|
3月前
|
SQL 分布式计算 运维
【跨国数仓迁移最佳实践3】资源消耗减少50%!解析跨国数仓迁移至MaxCompute背后的性能优化技术
本系列文章将围绕东南亚头部科技集团的真实迁移历程展开,逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第3篇,解析跨国数仓迁移背后的性能优化技术。 注:客户背景为东南亚头部科技集团,文中用 GoTerra 表示。
200 0
|
2月前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
285 0
|
6月前
|
存储 缓存 分布式计算
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
本文将深入探讨基于 StarRocks 和 Iceberg 构建的云原生湖仓分析技术,详细解析两者结合如何实现高效的查询性能优化。内容涵盖 StarRocks Lakehouse 架构、与 Iceberg 的性能协同、最佳实践应用以及未来的发展规划,为您提供全面的技术解读。 作者:杨关锁,北京镜舟科技研发工程师
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
|
4月前
|
存储 SQL 人工智能
【跨国数仓迁移最佳实践1】Append Delta Table 统一存储格式创新
本系列文章将围绕东南亚头部科技集团的真实迁移历程展开,逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第一篇,跨国数仓迁移背后 MaxCompute 的统一存储格式创新。 注:客户背景为东南亚头部科技集团,文中用 GoTerra 表示。
111 0
|
7月前
|
存储 SQL 关系型数据库
拉卡拉 x Apache Doris:统一金融场景 OLAP 引擎,查询提速 15 倍,资源直降 52%
拉卡拉早期基于 Lambda 架构构建数据系统面临存储成本高、实时写入性能差、复杂查询耗时久、组件维护复杂等问题。为此,拉卡拉选择使用 Apache Doris 替换 Elasticsearch、Hive、Hbase、TiDB、Oracle / MySQL 等组件,实现了 OLAP 引擎的统一、查询性能提升 15 倍、资源减少 52% 的显著成效。
311 6
拉卡拉 x Apache Doris:统一金融场景 OLAP 引擎,查询提速 15 倍,资源直降 52%
|
10月前
|
SQL 监控 关系型数据库
用友畅捷通在Flink上构建实时数仓、挑战与最佳实践
本文整理自用友畅捷通数据架构师王龙强在FFA2024上的分享,介绍了公司在Flink上构建实时数仓的经验。内容涵盖业务背景、数仓建设、当前挑战、最佳实践和未来展望。随着数据量增长,公司面临数据库性能瓶颈及实时数据处理需求,通过引入Flink技术逐步解决了数据同步、链路稳定性和表结构差异等问题,并计划在未来进一步优化链路稳定性、探索湖仓一体架构以及结合AI技术推进数据资源高效利用。
725 25
用友畅捷通在Flink上构建实时数仓、挑战与最佳实践
|
12月前
|
人工智能 自然语言处理 关系型数据库
客户说|宝宝树选用AnalyticDB RAG引擎,共创智能母婴生活新范式
宝宝树与阿里云深度合作,利用大数据和AI技术,推出了一系列智能化产品,如AI解读B超单、AI起名等,覆盖备孕、孕期、产后等场景,提升了用户体验,推动了商业化进程。通过技术架构的优化,宝宝树在内容生产和搜索精度上取得了显著成效,未来将继续深化“AI+母婴”战略,为用户提供更全面、个性化的服务。

相关产品

  • 云原生大数据计算服务 MaxCompute