StarRocks x Paimon 构建极速实时湖仓分析架构实践

2024-04-27 09:36

本文主要是介绍StarRocks x Paimon 构建极速实时湖仓分析架构实践,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Paimon 介绍

Apache Paimon 是新一代的湖格式,可以使用 Flink 和 Spark 构建实时 Lakehouse 架构,以进行流式处理和批处理操作。Paimon 创新性地使用 LSM(日志结构合并树)结构,将实时流式更新引入 Lakehouse 架构中。

Paimon 提供以下核心功能:

  • 高效实时更新:高吞吐和低延迟的数据摄入和更新

  • 统一的批处理和流处理:同时支持批量读写和流式读写

  • 丰富的数据湖功能:ACID, Time Travel 和 Schema Evolution 等

StarRocks 介绍

Linux 基金会项目 StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing) 数据库,遵循 Apache 2.0 开源协议。StarRocks 架构简洁,采用了全面向量化引擎,并配备全新设计的 CBO (Cost Based Optimizer) 优化器,查询速度(尤其是多表关联查询)远超同类产品。

StarRocks 不仅能高效的分析本地存储的数据,也可以作为计算引擎直接分析数据湖中的数据。用户可以通过 StarRocks 提供的 External Catalog,轻松查询存储在 Apache Paimon 数据湖上的数据,无需进行数据迁移。支持的存储系统包括 HDFS、阿里云 OSS、阿里云 OSS-HDFS 等

本文将介绍如何使用 StarRocks 和 Paimon 构建高效的数据湖分析架构,利用 StarRocks 达到极致的 Paimon 查询效率,并给出详细的操作步骤和性能测试数据。

本文主要内容:

  1. 快 - 使用 StarRocks 直接查询 Paimon 湖格式

  2. 更快 - 开启 Data cache 查询 Paimon 湖格式

  3. 超级快 - 构建异步物化视图查询 Paimon 湖格式

PART/ 01 快-使用 StarRocks 直接查询 Paimon 湖格式

StarRocks 支持 Catalog(数据目录)功能,实现在一套系统内同时维护内、外部数据,不需要手动建外表,指定数据源路径,即可轻松访问并查询各类数据湖格式,例如 Hive,Paimon,Iceberg 等。开箱即用,不需要任何数据导入和迁移。

例如:在 StarRocks 里创建一个 filesystem 类型的 Paimon Catalog:

CREATE EXTERNAL CATALOG paimon_fs_catalog
properties
( "type" = "paimon","paimon.catalog.type" = "filesystem","paimon.catalog.warehouse" = "oss://<bucket>/paimon/warehouse"
);

执行 SQL 查询 Paimon 数据湖(以 TPC-H Q1 为例):

selectl_returnflag,l_linestatus,sum(l_quantity) as sum_qty,sum(l_extendedprice) as sum_base_price,sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,avg(l_quantity) as avg_qty,avg(l_extendedprice) as avg_price,avg(l_discount) as avg_disc,count(*) as count_order
frompaimon_fs_catalog.paimon_tpch_flat_orc_100lineitem
wherel_shipdate <= date '1998-12-01' - interval '90' day
group byl_returnflag,l_linestatus
order byl_returnflag,l_linestatus

我们使用相同的硬件资源(配置详情见附录),对比了 StarRocks 和 Trino 分别查询Paimon Append Only 表格式的 TPC-H 100G 数据集,Trino 使用了最新的 Paimon-Trino 版本,已包含了对 ORC 文件读取的优化,测试结果如下:

在这里插入图片描述

StarRocks 的总耗时为 148.92s,Trino 的总耗时为 640.8s

可以得到,在本测试场景下,StarRocks 的查询效率是 Trino 的 4.3倍。

使用 StarRocks 直接查询 Paimon 数据是实际生产环境中最常见的场景,操作简单,可以满足大部分 Paimon 数据湖分析的需求。

PART/ 02 更快-开启 Data Cache查询 Paimon 湖格式

在数据湖分析场景中,StarRocks 作为 OLAP 查询引擎需要扫描 HDFS 或对象存储上的数据文件。查询实际读取的文件数量越多,I/O 开销也就越大。此外,在即席查询 (ad-hoc) 场景中,如果频繁访问相同数据,还会带来重复的 I/O 开销。

为了进一步提升该场景下的查询性能,StarRocks 2.5 版本开始提供 Data Cache 功能。通过将外部存储系统的原始数据按照一定策略切分成多个 Block 后,缓存至 StarRocks 的本地节点,从而避免重复的远端数据拉取开销,实现热点数据查询分析性能的进一步提升。

例如:开启 Data Cache 的步骤

  1. BE 增加如下配置并重启:
# 开启data cachedatacache_enable=true# 单个磁盘缓存数据量的上限,本示例20Gdatacache_disk_size=21474836480# 内存缓存数据量的上限,本示例4Gdatacache_mem_size=4294967296# 缓存使用的磁盘路径datacache_disk_path=/mnt/disk1/starrocks/storage/datacache;/mnt/disk2/starrocks/storage/datacache;/mnt/disk3/starrocks/storage/datacache;/mnt/disk4/starrocks/storage/datacache
  1. MySQL 客户端执行:
SET enable_scan_datacache = true;

我们可以在 Query Profile 里观测当前 Query 的 Cache 命中情况,观测下述指标查看 Data Cache 的命中情况:

  • DataCacheReadBytes:从内存和磁盘中读取的数据量。

  • DataCacheWriteBytes:从外部存储系统加载到内存和磁盘的数据量。

如以下的示例,显示该 Query 在 Data Cache里读取了 10.107 GB 的数据

- DataCache:- DataCacheReadBlockBufferBytes: 920.146 MB- __MAX_OF_DataCacheReadBlockBufferBytes: 14.610 MB- __MIN_OF_DataCacheReadBlockBufferBytes: 1.762 MB- DataCacheReadBlockBufferCounter: 27.923K (27923)- __MAX_OF_DataCacheReadBlockBufferCounter: 440- __MIN_OF_DataCacheReadBlockBufferCounter: 55- DataCacheReadBytes: 10.107 GB- __MAX_OF_DataCacheReadBytes: 163.518 MB- __MIN_OF_DataCacheReadBytes: 20.225 MB- DataCacheReadDiskBytes: 563.468 MB- __MAX_OF_DataCacheReadDiskBytes: 30.965 MB- __MIN_OF_DataCacheReadDiskBytes: 0.000 B- DataCacheReadMemBytes: 9.556 GB- __MAX_OF_DataCacheReadMemBytes: 142.791 MB- __MIN_OF_DataCacheReadMemBytes: 20.225 MB- DataCacheReadCounter: 41.456K (41456)- __MAX_OF_DataCacheReadCounter: 655- __MIN_OF_DataCacheReadCounter: 81- DataCacheReadTimer: 9.157ms- __MAX_OF_DataCacheReadTimer: 48.792ms- __MIN_OF_DataCacheReadTimer: 478.759us- DataCacheSkipReadBytes: 0.000 B- DataCacheSkipReadCounter: 0- DataCacheWriteBytes: 0.000 B- DataCacheWriteCounter: 0- DataCacheWriteFailBytes: 0.000 B- DataCacheWriteFailCounter: 0- DataCacheWriteTimer: 0ns

我们开启 Data Cache 后,再次执行 TPC-H 100G 基准测试,第一次执行总耗时为134.59s,第二次执行总耗时为 110.2s,第三次执行总耗时 113.12s,第一次相对后两次较慢是因为 StarRocks 要从对象存储 OSS 里拉数据,并做本地 Cache,后两次从 Profile 可以看到基本全命中本地 Cache 做运算,执行时间稳定在 110s 左右。

可以得到,在本测试场景下,开启 Cache 之后,查****询性能提升了35.4%左右

在生产环境中,Data Cache 的性能在不同的 Query Pattern 以及不同的数据量下,查询性能有从百****分之几十到几倍的提升。

PART/ 03 超级快-构建异步物化视图查询 Paimon 湖格式

生产环境环境中的应用程序经常基于多个大表执行复杂查询,通常涉及大量的数据的关联和聚合。处理此类查询通常会大量消耗系统资源和时间,造成极高的查询成本,StarRocks 可以使用异步物化视图解决以上问题。异步物化视图是一种特殊的物理表,其中存储了基于基表特定查询语句的预计算结果。当您对基表执行复杂查询时,StarRocks 可以直接复用预计算结果,避免重复计算,进而提高查询性能。

我们以 TPC-H Q1 的查询 SQL 为例,演示如何创建 Paimon 湖格式的异步物化视图:

CREATE MATERIALIZED VIEW lineitem
DISTRIBUTED BY HASH(l_shipdate)
REFRESH IMMEDIATE  MANUAL
AS
selectl_returnflag,l_linestatus,l_shipdate,sum(l_quantity) as sum_qty,sum(l_extendedprice) as sum_base_price,sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,avg(l_quantity) as avg_qty,avg(l_extendedprice) as avg_price,avg(l_discount) as avg_disc,count(*) as count_order
frompaimon_fs_catalog.paimon_tpch_flat_orc_100.lineitem
group byl_returnflag,l_linestatus,l_shipdate

物化视图构建完成后,再次运行 TPC-H Q1 查询,StarRocks 可以自动改写查询SQL,从物化视图里直接读取数据。

在本测试场景下,TPC-H Q1 执行时间从直接查询 Paimon 数据湖的 3.5秒左右缩短到0.04s 左右。

实际生产环境中,物化视图应用在对查询延迟要求非常高的场景,而物化视图的构建方式会极大的影响最终查询耗时,需要用户根据业务需求和历史的查询 SQL 进行总结来选择合适的物化视图构建方式来满足具体的业务需求。

PART/ 04 当前总结

当前 StarRocks x Paimon 的能力主要包括:

  1. 支持各类存储系统,包括 HDFS 以及对象存储 S3/OSS/OSS-HDFS

  2. 支持 HMS 以及阿里云 DLF 元数据管理系统

  3. 支持 Paimon 的 Primary Key 和 Append Only 表类型查询

  4. 支持 Paimon 系统表的查询,常见例如 Read Optimized 表,snapshots 表等

  5. 支持 Paimon 表和其他类型数据湖格式的关联查询

  6. 支持 Paimon 表和 StarRocks 内表的关联查询

  7. 支持 Data Cache 加速查询

  8. 支持基于 Paimon 表构建物化视图实现透明加速,查询改写等

对于 Primary Key 表类型,我们对 Read Optimized 系统表做了完善的性能优化,可以与 Append Only 表一样充分利用 Native reader 的能力,得到直接查询 Paimon数据的最佳性能。直接查询 Primary Key 表的情况下,若 Primary Key 表里包含没有做 Compaction 的数据,StarRocks 里会通过 JNI 调用 Java 读取这部分内容,性能会有一定的损耗。即使是这种情况,在我们收到客户反馈里,平均还是会有相对Trino 达到3倍以上的性能提升。

PART/ 05 未来规划

接下来,我们会继续完善 StarRocks x Paimon 的支持能力,包括:

  • 使用 Native reader 支持 Primary Key 表的 Deletion vectors,进一步加速查询性能

  • 缓存 Paimon 元数据,减少重复 I/O 和降低 Analyze 阶段的延时

  • 接入 Paimon 表统计信息,优化复杂 SQL 的执行计划

  • 完善 Paimon 异步物化视图查询和改写功能


===

附录:本文性能测试环境说明


阿里云 EMR on ECS 数据湖集群:

  • EMR版本:EMR-5.16.0版本

  • 集群配置:1x master, 3x core

  • 机型:ecs.g6.4xlarge 16 vCPU 64 GiB

  • Trino版本:427

  • Paimon 版本:0.7

  • Paimon TPC-H 测试表类型:Append only,存储格式为ORC


EMR Serveless StarRocks 集群

StarRocks版本:3.2.4


测试软件配置

  • Trino

  • -Xmx50G

  • query.max-total-memory: 105GB

  • query.max-memory: 105GB

  • query.max-memory-per-node: 35GB

  • StarRocks

  • -Xmx50G


测试数据和步骤

  • 性能测试基准:TPCH 100G

  • 测试方法:每个 Query 跑3次取平均值,不做预热,不预先收集统计信息,测试数据放在 OSS

更多交流,联系我们:https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/8da64

这篇关于StarRocks x Paimon 构建极速实时湖仓分析架构实践的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/940140

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

C#实战|大乐透选号器[6]:实现实时显示已选择的红蓝球数量

哈喽,你好啊,我是雷工。 关于大乐透选号器在前面已经记录了5篇笔记,这是第6篇; 接下来实现实时显示当前选中红球数量,蓝球数量; 以下为练习笔记。 01 效果演示 当选择和取消选择红球或蓝球时,在对应的位置显示实时已选择的红球、蓝球的数量; 02 标签名称 分别设置Label标签名称为:lblRedCount、lblBlueCount

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

MOLE 2.5 分析分子通道和孔隙

软件介绍 生物大分子通道和孔隙在生物学中发挥着重要作用,例如在分子识别和酶底物特异性方面。 我们介绍了一种名为 MOLE 2.5 的高级软件工具,该工具旨在分析分子通道和孔隙。 与其他可用软件工具的基准测试表明,MOLE 2.5 相比更快、更强大、功能更丰富。作为一项新功能,MOLE 2.5 可以估算已识别通道的物理化学性质。 软件下载 https://pan.quark.cn/s/57