亿级数据如何实现秒级响应?

本文涉及的产品
智能商业分析 Quick BI,专业版 50license 1个月
简介: 本文详细介绍了瓴羊Quick BI的性能架构、性能工具和性能保障,旨在帮助企业更好地理解和使用这一商业智能工具。文章首先概述了BI产品在企业中的重要性,随后深入探讨了Quick BI的性能架构,包括应用架构、分析引擎和渲染引擎,以及其优势和测试效果。接着,文章介绍了性能工具,包括性能分析和性能诊断,帮助用户精准诊断和优化性能瓶颈。最后,文章阐述了性能保障措施,如线上监控、版本巡检和定期报告,确保系统的稳定性和高效运行。通过这些设计,Quick BI能够满足企业在不同场景下的性能需求,提升数据分析效率和决策能力。

前言

商业智能(BI)作为现代企业数字化增长的助推器,越来越多应用于企业日常的决策制定运营效率、财务管理等活动中。近期我们从市场部门了解到,现阶段客户在选择一款BI产品时不仅关心它的功能和价格,同时也越来越关注产品的性能和服务,因此本文会围绕Quick BI性能专题做一次详细的介绍

提到性能,不同客户的关注点会有一些差异,例如有些客户访问量比较大,关注的是产品的并发性能,有些客户数据量比较大,更关心数据的查询性能,另外有些客户用Quick BI搭建了大型数据应用,对报表的打开性能有很高的要求。为了让客户更加流畅高效地使用Quick BI,瓴羊的产研团队从性能架构、性能工具以及性能保障全链路都做了精心的设计。


性能架构

什么是性能

性能(Performance)是计算机科学和制造工程中一个关键的概念,通常涉及到效率、速度、效果或质量等方面的度量,性能的好坏直接体现了一款产品的技术竞争力。


在车辆工程领域,衡量一个汽车的关键性能指标包含动力性能(百米加速度),能源性能(百公里油耗),操控性能(刹车系统)以及安全性能(碰撞检测)等;而在计算机领域,服务器的性能指标则包括了CPU、GPU、内存和存储等关键硬件配置,类比到软件上则主要是指响应时间,吞吐量,资源利用率,安全性,扩展性。

 image.png 

如何衡量BI产品的性能

Quick BI的产品定位是一款提供智能化数据分析及可视化能力,满足用户数据准备、数据分析、数据可视化等需求的云上SAAS产品。从定位上看Quick BI主要包含了三大特征,即云上SAAS产品、数据分析、数据可视化。


首先,作为一款标准的云上SAAS(Software as a service)产品,Quick BI除了包含软件产品通用的基础服务指标(响应时间、吞吐量,并发数)外,还包含了诸如Open API,订阅推送,监控告警等一些BI场景的特有服务指标,只有构建高稳定、高扩展性的应用架构,才能保障产品在这些指标上的性能优势。


其次,数据分析作为BI产品的最核心链路,其本质就是对表进行建模并连接用户的数据源执行取数查询,取数耗时是这个阶段的关键指标。直连数据库模式下这个指标会强依赖用户的数据量和数据库性能,而Quick BI在用户的数据库和可视化分析之间建立了一层分析引擎用于执行内存计算以及查询加速,因此内存计算耗时、加速成功率以及缓存命中率也成为衡量数据分析的扩展指标。


最后,数据可视化作为数据分析的后链路,对于用户的看数效率也是至关重要的。国内很多用户都是从传统BI过渡过来,习惯于用BI工具搭建上百个图表以上的复杂报表应用,在报表中使用50个字段列10000行以上的大宽表也很常见,为了让报表在上述场景上也能快速展现,Quick BI引入了渲染引擎对报表的加载渲染速度做了很多优化。

 image.png



架构介绍

应用架构

架构介绍

我们的服务器物理上采用最经典的分布式集群架构部署,这种架构对于服务的扩展性和安全性有很大优势。从逻辑上看可以分为两层,第一层是调度和基础服务层,其中的driver节点负责下发取数任务和管理业务数据库和缓存,附加依赖资源主要是用于产品的性能、运维、用户文件存储等服务;第二层是执行和扩展服务层,其中executor节点负责执行取数任务和汇总数据,而其余节点都是产品的扩展服务集群,包含数据加速引擎、数据准备引擎、订阅服务集群以及智能问数所依赖的BI大模型集群。


其中除了实线部分,其余的模块在独立部署环境用户都可以根据自己的业务需要选择是否部署,在公共云环境用户也可以选择是否开通/订阅相应的服务。

 image.png

服务器拓扑图


架构优势

● 高扩展性:

水平扩展:对任意集群增加服务器节点都能带来整体性能的提升

○ 垂直扩展:对任意集群升级服务器配置也能带来整体性能的提升

弹性部署:

○ 服务插件化:所有的辅助服务包括附加资源、数据加速引擎、数据准备引擎、订阅服务集群和BI大模型集群都是可插拔式部署,用户可根据业务需要选择是否部署以及集群规模

○ 混合部署:对于机器资源有限的客户或者是在POC场景,我们也能够支持将不同的服务(包括基础服务和扩展服务)部署到同一个服务器集群中,极限情况下我们也支持将所有的服务部署到一台服务器上(服务越多性能限制越大)

高可靠性

○ 冗余和故障转移:我们在公共云上采用了多区域部署,以确保即使一个区域发生故障,其他区域仍能提供服务,失败的任务也会迁移到正常节点上补数据

○ 自动恢复:对于系统内业务数据我们会定期备份,如果出现重大故障时,我们会启动应急恢复或回滚方案,保障产品线上服务的正常运行


分析引擎

分析引擎是连接上层业务应用和底层数据源之间的桥梁,当用户在数据集或者仪表板中下发取数任务时,是由分析引擎承载了包含了SQL拼装、数据源连接、内存计算以及结果汇完整取数过程。

引擎架构

分析引擎下发取数任务的方式主要包含两种模式:直连模式加速模式


直连模式是默认的查询路径,该模式下所有的取数任务是通过JDBC、SDK等方式直接连接用户的数据源进行实时查询,相关的访问和计算压力完全由用户的数据库/数据仓库来承载

加速模式只有在用户购买或部署了加速引擎服务后才能使用,开启加速模式后所有取数任务会走到Quick引擎链路中执行,在Quick引擎中支持三级缓存架构且每一级都可以由用户自己选择是否开启,命中1级缓存后会直接从redis中返回结果,命中2,3级缓存后取数会被下发到Quick BI的高性能分析引擎中加速执行,其中2级缓存是直接读取缓存的聚合结果,而3级缓存是基于抽取明细数据做的临时聚合。

 image.png



引擎优势

● 高性能 OLAP 引擎

○ 列式存储:用列式存储格式,进行聚合和分析查询只读区相关的列

○ 向量式计算:批量处理数据,从而提高 CPU 利用率和查询性能

○ 数据压缩:高效存储大量数据,同时减少 I/O 操作

○ 数据单表化:区别于fineBI的导入模式(按表导入),Quick BI 提供的是基于数据集的加速。 即使数据集配置了复杂的关联模型,数据抽取到加速引擎中都会以单表形式存在,最大程度提升查询性能。

多级缓存结合

○ 结果缓存:提供对于单次查询的缓存。在缓存有效期内, 同一个数据集完全相同的查询(即生成一致的查询 SQL),会直接返回有效期内第一次查询的结果,第一次查询依然会走数据库直连,适用于重复取数场景。

○ 预聚合: 开启后Quick引擎会存储并分析该组织近7天的查询日志,提取那些高频使用的字段和聚合方式组合,并在每次抽取任务中按照这些组合将聚合后的数据同步到引擎中,同步的数据量更小, 查询时直接返回聚合结果,适用于访问量大的固定报表场景。

全表加速:将用户数据集对应的明细数据抽取到Quick BI内置的高性能 OLAP 引擎中,依托引擎自身的高效分析能力,满足客户即席分析场景下(指标、维度、聚合方式以及筛选条件不固定)的查询加速需求。

● 失败告警与降级保障

○ 失败告警:支持通过可视化配置,在抽取任务失败时触发短信、钉钉、以及邮件告警通知。

○ 降级保障:因为一些原因,如数据抽取任务执行失败或正在进行中,查询加速会失效。该场景下 Quick BI 会自动降级回退到直连查询,保障数据顺利加载。

引擎加速效果

为了更好的体现Quick引擎的性能优势,我们采用了产品中使用量TOP1的MaxCompute数据源做查询耗时对比测试

● 测试方式

测试案例基于 MaxCompute 1000万和1亿的数据集,分别设置 10 和 100 万的维度分组

测试案例选取了 求和、计数、中位数、方差、标准差等简单聚合方式

每种场景图表分别查询 10 次,取10 次数据中的中位数进行记录并总结分布

● 测试结果

在MaxCompute数据源下,各种数据组合中加速后耗时(启用了抽取后查询)相较于加速前耗时(直连查询)都有近90%的查询耗时节省

○ 对于亿级数据分组数在百万级以下的场景中,Quick BI的查询速度基本可以做到秒级响应      

数据源

表列数

表行数

分组场景

加速前耗时

加速后耗时

MaxCompute

20

1000 万

分组数 = 10

4 - 6 秒

< 0.5 秒

1000 万

分组数 = 100 万

25 - 30秒

1 - 2 秒

1 亿

分组数 = 10

6 - 10 秒

1 - 2 秒

1 亿

分组数 = 100 万

45 - 60 秒

5 - 11 秒


引擎规格限制

当用户使用加速引擎做全表抽取加速时,因其底层是将用户的明细数据抽取到Quick BI内置的高性能分析型数据库中,所以其存储容量受限于云环境的当前集群规模,同时为了保证取数任务的执行效率和吞吐量,引擎对单个数据集的最大行数也做了限制;此外,不同数据库方言上也有一些差异,占位符和部分函数的使用会导致加速任务失效。相关的限制和注意项汇总如下

 image.png



渲染引擎

渲染引擎是低代码搭建模块的底层调度引擎,负责管理报表的资源加载、布局生成、取数拼装以及图表渲染等核心流程,在Quick BI中仪表板、大屏、数据表单甚至是电子表格底层都是复用了一套通用的渲染引擎模型。


引擎架构

在引擎中报表的渲染过程可以分解为四个阶段,每个阶段我们都针对不同的节点做了相应的加速:

 image.png

● 资源加载

○ 检测客户端:根据客户端版本、网络环境和设备类型制定不同的页面资源加载策略,例如在IE浏览器中需要加载兼容包,在移动微应用中需要加载SDK和布局适配,在开通公网的情况下会优先加载cdn资源。

○ 分析报表依赖:分析报表配置,最小化加载渲染需要使用的图表和组件

● 任务调度

○ 分析布局配置:分析页面的可视区范围和容器结构,优先加载和渲染可视区内的图表,提升首屏加载时间

○ 分析图表配置:解析图表中的相关配置,合成图表的字段信息,配置项信息和过滤器信息

● 取数查询

○ 拼接参数:解析URL上携带的外部参数和字段层级上的继承参数,拼装到查询结构中

○ 发起取数:将查询结构转换成接口参数下发到服务端取数,其中动态取数主要是针对查询控件或是tab控件上需要动态加载的下拉枚举选项进行预查询,主要是因为其他图表的取数结果依赖这些控件注入参数;而数据轮询主要是针对那些耗时较长(一般来说>5s)的取数接口,为了避免其占用服务端连接数会自动将其切换为轮询的方式去执行,如果轮询超过5分钟仍未获取到结果会自动终止取数任务,并将其状态设置为超时

图表渲染

○    在图表渲染的数据量较大时,渲染引擎会针对不同的图表类型采用不同的渲染优化策略,例如:针对表格类组件我们会采用虚拟滚动+数据分页的解决方案,其中虚拟滚动技术可以确保只有显示在表格可视区范围内的单元格才会被渲染到页面上;针对地图类组件我们会通过轮廓数据抽稀技术减少地理信息数据的传输(原理类似于图片压缩),而对于有底图的地图会根据用户的操作实时拉取对应层级的地理瓦片数据。


引擎优势

总结下来我们渲染引擎有如下几个优势

● 客户点加载优化

○ 类型/版本自适应

○ 布局/UI自适应

○ OA小程序继承

● 可视区加载优化

○ 资源懒加载

○ 图表动态加载

● 取数优化

○ 动态取数

○ 异步取数

○ 取数合并

● 图表渲染优化

○ 分页/动态加载

○ 标签/节点分组抽样

○ 虚拟滚动

引擎测试效果

● 测试方式

测试样本:包含仪表板全量图表类型(控件类、表格类、指标类、线柱类、饼图类、气泡/散点、漏斗图类、地理类等),图表数量在10-500之间生成300张报表

测试设备:低/高性能PC、低/高性能移动设备      高端:内存>=8G, CPU>=4核

数据采集:所有查询走缓存,分别测试一次无浏览器缓存数据与四次有浏览器缓存数据,取五次首屏渲染完成时间的平均值进行记录

● 测试结果

渲染时间

用例数量

用例占比

1秒内

18

6.00%

1-3秒

260

86.76%

3-6秒

22

7.24%

测试结论

高性能PC和移动设备上,100%的报表都能在3S内打开

低端移动设备上大数据量渲染图表展示(数据量10000 条)性能较差

性能工具

尽管Quick Bl性能架构能覆盖大部分常规场景,但在一些特殊情况下,如未加速的数据集延迟、大宽表或大量地图组件的报表加载、弱网环境或低配置设备等场景,仍有一定的优化空间。因此,在一个强大的性能架构外,企业还要关注性能工具,实现对潜在瓶颈的精准诊断与优化。 性能工具可分为性能分析与性能诊断两大类。

性能分析

性能分析工具主要帮助数据准备人员查看各工作空间中的查询耗时、加速开启情况、访问热度及性能优化建议。其统计逻辑为:系统会记录近30天的查询日志,包括查询时间、加速命中率等指标。通过这些数据,用户能够快速识别查询较慢且使用频繁的报表、图表和数据集,及时发现性能瓶颈并优化关键节点。

 image.png



性能诊断

性能诊断工具主要用于分析和优化性能,包含三个核心指标:首屏加载时长、优化建议和图表加载时长。企业可以通过报表级诊断工具发现并解决报表和数据分析操作中的性能问题,从而提升报表查询速度和响应性能。同时,通过组件级性能诊断工具,企业还可在数据传输、取数查询、渲染等待和图表渲染四个阶段统计组件加载时长,提升图表加载和响应效率。

 image.png

 image.png




性能保障

服务器需要日复一日地在线持续迭代,性能保障是确保其稳定运行和高效服务的关键,具体保障维度可分为线上监控、版本巡检和性能报告三个方面。

线上实时监控

无论是云上SaaS版本还是私有化部署版本,QBI研发和运维团队都会对服务器状态及接口性能进行线上监控,确保服务的高效运行。线上监控分为指标监控和运维监控两个平台,指标监控平台主要收集接口耗时、查询成功率等业务指标,运维平台则主要关注服务器健康情况,并关注磁盘与数据库监控,以及CPU、内存占用等通用指标。监控数据会上传至分析平台和告警平台,支持7×24小时监控,并通过电话、短信、钉钉等方式提供即时告警,确保问题能够快速响应与恢复,从而保障线上服务的稳定性与可靠性。

 image.png



日常版本巡检

版本巡检是性能保障的重要环节,在每次版本迭代中,QBI都会进行系统化性能测试,通过自动性能采集,实现报表对比分析与定向优化。巡检测试包含三大用例集:基准性能用例、新增功能用例,以及特殊场景性能问题用例。巡检对象覆盖分析引擎、渲染引擎及并发测试三大类,例如,分析引擎测试涉及千亿行数据和百万分组,渲染引擎覆盖仪表盘、电子表格等场景,并发测试重点监测TPS、QPS等指标。测试结果可以帮助快速发现性能异常并及时优化,确保系统即使在复杂环境下依旧可以顺畅运营。所有测试结果会形成性能报告,为版本发布提供有力保障。

 image.png



定期产出报告

性能报告是性能保障的重要组成部分,自5.2版本起,每个大版本发布后都会公开性能白皮书。白皮书评估分析性能、渲染性能和并发性能等核心指标。数据显示,开启抽取加速的前提下,Quick BI 的分析性能可以做到亿级数据秒级响应,渲染性能、并发性能表现也较为优异。

 image.png 

结语

随着数据规模的爆发式增长和应用场景的日益复杂,BI工具的精细化应用已成为企业应对复杂业务流程、实现科学数据决策的必由之路。凭借完善的性能架构、性能工具和性能保障全链路设计,瓴羊Quick BI充分满足了企业对BI工具性能的多样化需求,为企业提升数据分析效率、推动智能化决策提供了坚实保障。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps&nbsp;
相关文章
|
存储 SQL 关系型数据库
TiDB亿级数据亚秒响应查询整体架构
TiDB亿级数据亚秒响应查询整体架构
973 0
|
固态存储 关系型数据库 MySQL
TiDB亿级数据亚秒响应查询集群部署
TiDB亿级数据亚秒响应查询集群部署
336 0
|
关系型数据库 MySQL OLAP
TiDB亿级数据亚秒响应查询方案介绍
TiDB亿级数据亚秒响应查询方案介绍
614 0
|
1月前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
55 8
|
2月前
|
SQL 缓存 分布式计算
C#如何处理上亿级数据的查询效率
C#如何处理上亿级数据的查询效率
47 1
|
7月前
|
消息中间件 存储 Java
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的低延迟可用性机制方案实现
在充满挑战的2023年度,我们不可避免地面对了一系列棘手的问题,例如响应速度缓慢、系统陷入雪崩状态、用户遭受不佳的体验以及交易量的下滑。这些问题的出现,严重影响了我们的业务运行和用户满意度,为了应对这些问题,我们所在团队进行了大量的研究和实践,提出了低延迟高可用的解决方案,并在分布式存储领域广泛应用。
78 2
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的低延迟可用性机制方案实现
|
7月前
|
关系型数据库 MySQL 分布式数据库
ES如何做到亿级数据查询毫秒级返回
ES如何做到亿级数据查询毫秒级返回
123 0
|
5月前
|
消息中间件 负载均衡 算法
中间件在实时数据处理中低延迟
【7月更文挑战第4天】
66 3
|
7月前
|
存储 消息中间件 Java
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
在深入研究了 **“【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现”** 设计实现后,我们意识到,尽管API网关为服务商提供了高效的数据获取手段,但实时数据的获取仍然是一个亟待解决的问题。
108 1
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
|
存储 Prometheus Cloud Native
TiDB亿级数据亚秒响应查询扩缩容
TiDB亿级数据亚秒响应查询扩缩容
135 0

热门文章

最新文章