网易有数 BI 性能保障体系建设与实践
导读 本文将分享有数 BI 性能保障体系的建设与实践。
主要分为以下 4 个部分：
-
有数 BI 产品的介绍
-
企业高并发报表访问性能挑战
-
有数 BI 性能体系建设与实践
-
未来计划
分享嘉宾｜胡雪亮 网易 有数 BI 技术部负责人
编辑整理｜张建闯 BOSS 直聘
出品社区｜DataFun
01/有数 BI 产品的介绍
网易数帆是网易旗下 ToB 企业服务品牌，愿景是提供数字化转型技术与服务的提供商，依托网易 20 多年互联网技术积累，推出了软件生产力、数据生产力、智慧生产力的三大数字生产力模型，助力企业数字化转型，提质增效。现在网易数帆已经为 300 余家行业头部企业服务。
有数 BI 是网易数帆推出的一个企业级的智能大数据敏捷分析平台，助力企业实现数据驱动决策，平台从 2014 年底开始建设，提供了私有部署版本和 SAAS 版本，目前已有几百家企业客户在使用。
有数 BI 是一个一站式的数据分析与应用工作台，主要通过零代码的方式，简单的拖拽就能完成从数据连接、数据建模，再到报告、大屏、数据门户完整制作。
整个平台有十多个子产品，包括可视化分析、数据大屏、数据填报、数据准备、数据门户、复杂报表等，帮助企业打造自己的数据产品和应用。
有数 BI 可视化分析具有如下特色：
（1）拖拽式报表制作
PPT 式布局：自由布局排版，多图层仪表板设计。
零代码一体化制作：简单拖拽，无需切换，所见即所得。
（2）敏捷可视化探索与展示
强大的可视能力：丰富的可视化图表，支持多样数据应用场景。
多维度透视多度量轴图表：行业领先的可视化探索能力。
（3）灵活交互与强大计算能力
支持函数计算，动态参数，动态分析，自定义表计算。
跨视图粒度分析（LOD）：可视化环节可以实现跨当前图表视图粒度的数据处理以及高级计算。
交互式分析：支持上卷下钻，图表联动，报表跳转等。
有数 BI 产品的技术架构主要分为四层：
（1）前端绘图层：平台的前端业务逻辑和图表的绘制引擎，其中 NEV 是网易数帆自研的图表可视化引擎。
（2）后端业务层：基于 Node.js 开发的中间层，包括用户权限管理、图表配置管理、资源管理、定时调度、智能缓存等业务逻辑。
（3）数据引擎层：基于 Java 类语言开发，包括 Scala，Clojure，Java，主要负责图形智能推导，数据的查询、计算、写入和导出。
（4）数据源层：包含客户的外部数据源以及有数的 MPP（CK 和 GP）。
02/企业高并发报表访问性能挑战
性能是 BI 用户体验的关键，有数 BI 主要定位企业级大客户，企业级客户主要有数据量大、图表数量多和用户访问并发大的特点，有些客户的图表数量有几万甚至十几万，每天图表访问量有几十万，这个会给 BI 带来哪些挑战呢？
（1）上班看数高峰期的并发如何应对？
（2）灵活分析类的查询性能如何解决？
（3）领导看数性能和稳定性如何保障？
为什么企业级 BI 性能保障难度大，一方面企业级 BI 要求支持更高的图表查询并发，另一方面 BI 图表查询的 SQL 复杂度高，引擎能支持的并发度低，像一般引擎也就几十的并发。而 OLAP 类的查询随着查询并发增加，无法像 OLTP 那样容易水平扩展，不同查询的资源消耗差异很大，经常会发生一两个查询占据集群大量资源把集群都卡住的情况。
对于这些问题可能首先会想到的就是加资源，但加资源不一定就能解决，而且也不是一个最经济的方式。虽然在某些场景下，加资源可能能够扛住高峰期查询，但是很多 BI 系统在低峰期查询较少，整体利用率不高。
要解决企业级 BI 图表查询并发远高于引擎支持的并发的问题，要求我们一方面尽可能减少图表落库查询，另一方面要提升落库查询性能以提升并发。
我们开发了基于用户行为分析的多级缓存加速的方案，这样又快又可以节省系统资源。缓存加速本质上是分析已有的用户行为去预测未来的访问行为，给出最优的方案。
要提升 BI 访问性能要充分利用用户在 BI 上的访问行为，用户在 BI 的访问行为编辑态主要是制作报告，阅览态包括打开报告和在报告上做一些分析，比如灵活筛选、上卷下钻、图表联动。接下来我们看看这些场景的性能我们是如何解决的？
03/有数 BI 性能体系建设与实践
下面具体介绍有数 BI 性能体系。
1. 整体架构
有数 BI 的性能保障体系，主要分三层：
**（1）图表层（可视化查询）：**负责图表配置翻译成可视化查询，图表层提供了基于数据产出的智能缓存，用来缓存可视化查询结果，提供毫秒级的响应。
**（2）数据模型层（多维分析查询）：**负责可视化查询翻译成基于模型的多维分析查询，模型层提供跨引擎物化视图，用来缓存模型预计算结果，包括模型明细或模型预聚合的结果。
（3）数据连接层（SQL 查询）： 基于模型的查询最终会翻译成具体数据源的 SQL 查询，数据连接层提供 MPP加速，可以把数据源里面的表/自定义 SQL抽取到 MPP 里面加速。
另外，有数 BI 数据医生提供了报告性能运维能力，用户可以自助运维报告的稳定性和性能。数据医生模块提供图表性能自动诊断优化功能。对于管理员来说，可以查询项目下图表的性能指标和发现性能问题，以及使用推荐方案优化。数据医生还有报告的分级治理功能，可以标记重点报告，支持重点报告走单独的数据连接，也可以为重点报告设置预缓存优先级等。
2. 智能缓存
我们先看智能缓存，BI 系统一天最大的查询并发一般来自上班看数高峰，特别是周一，之前早上看数高峰时段经常遇到图表加载不出来，当时还专门对这种情况提供了一个提示："当前数据查询高峰，请稍后再试"，希望用户能够错峰使用。
后来经过分析，发现用户在上班的时候打开报告的场景，数据查询是能够预测的：
（1）用户打开报告的时候，查询条件是比较固定的，能够提前把这个数据计算出来。
（2）有些用户在打开报告做灵活筛选的时候，筛选的条件也是比较有规律的，比如今天我筛选的是浙江省，明天可能还是浙江省。
针对这种场景我们开发了基于数据产出的智能缓存来提前缓存预加载。智能缓存提供了丰富的触发方式，包括猛犸中台产出消息、openAPI、MPP 抽取完成、定时刷新等。有数 BI 收到消息后会通过表/模型/图表血缘结合用户权限计算待缓存的图表，同时根据图表最近 30 天的 PV 和 UV 以及是否为重点报告等规则做缓存优先级的计算，形成缓存优先级的队列，最后使用缓存并发控制调用图表缓存接口进行缓存。
因为 BI 依赖的很多数据凌晨就产出了，因此智能缓存不仅降低了高峰期落库查询压力，也利用错峰提升了资源利用率。
智能缓存在内部云音乐、严选，外部温氏等客户都有广泛应用，落地效果较好，因为报告首开查询在总查询中占了很大比例。衡量智能缓存落地最重要的以下三个指标，以云音乐的使用来举例，通过智能缓存治理（包括重点报告标记、表产出消息和时间治理、缓存并发数调整）达到如下效果：
（1）缓存图表比例，这个目前基本做到了 100%，也就是上班前基本预缓存了最近 30 天有访问的所有图表。
（2）首访缓存命中率，这个目前在 90% 以上，也就是 90% 以上的用户首访都能命中缓存秒开。
（3）分析缓存命中率，这个目前 65% 左右，也就是 65% 的用户分析查询也命中了缓存。
3. 高性能查询引擎 MPP
智能缓存解决了首访报告和有规律的分析场景，那么灵活分析类场景的查询性能如何解决呢？BI 上有很多类型的数据源不适合 OLAP 查询，比如 Excel，MySQL，Oracle 等等，针对这种场景有数 BI 提供了把数据源表抽取到 MPP 引擎加速的方案，目前 MPP 主要支持 gp 和 ck，以后可能也会支持 Doris。
有数 BI 支持全量覆盖、全量追加、增量和滚动覆盖等四种抽取类型，抽取触发支持定时触发，也可以依赖表数据产出消息触发。同时抽取方式也支持 Spark 分片抽取。另外有数 BI 产品上还提供了 MPP 的容量管理、任务监控告警以及抽取历史记录管理的功能。
MPP 目前有几十家私有部署客户使用，有很多深度使用的客户，包括温氏集团、马上金融、长鑫存储、平安产险等，重点客户单日抽取任务最高超1w+，温氏集团、平安产险月活5000+，性能方面平安产险、温氏集团查询5s内图表比例有96%以上。
4. 物化视图
有数BI在模型层引入物化视图能力，灵活分析类场景可以通过创建物化视图进行模型预计算来加速查询，有这么几个思路：
（1）对模型进行全量物化，就是把多表关联模型变成宽表明细。
（2）可以基于用户在图表上配置的字段来垂直切分，只物化整个表的部分字段，很多模型用到的字段只有整体的一小部分。
（3）可以对数据进行筛选范围的水平切分，比如某个图表只查询今年的数据。
（4）如果明细数据过大也可以对图表中固定的聚合粒度做聚合视图的加速。
我们研发了基于模型的跨引擎物化视图功能，因为 BI 数据模型天生就是跨引擎的，所以可以直接基于数据模型来物化，有数 BI 物化视图可以物化任何支持的数据源，物化结果可以存储到我们支持的 MPP 引擎中。
用户在模型上可以配置全量明细、带筛选条件的明细、聚合视图，基于模型的物化视图会被翻译成 ETL 信息，也就是有数 BI 的数据准备，BI 后台会去调度物化 ETL 更新物化视图。调度方式可以是定时，也可以是表产出消息驱动。物化视图的历史记录和容量可以在项目中心管理。图表查询时，可以根据物化视图配置和ETL信息改写，BI 基于模型的查询改写比 SQL 改写更直接。
另外在产品上物化字段选取支持根据报表配置信息一键生成物化字段，物化筛选条件选取支持根据报表上的默认筛选条件推荐。
我们在网易内部为严选业务重点报告做了优化，在没有增加资源的情况下，达到了较好的效果：
（1）创建物化视图 70+。
（2）开启了物化功能的模型，物化查询命中率 90%+。
（3）落库查询 5s 内图表比例提升了 50%（从 55% 提升到 83%）。
5. 数据医生
前面讲的智能缓存、MPP、物化视图只是优化手段，还不是我们的目标。企业级 BI 图表数量和查询量都比较大，对这些大量的图表进行管理和运维，也是非常大的工作量，常见问题有：
（1）如何保障图表，特别是重点图表的可用性和性能。
（2）管理员如何发现和治理有性能问题的图表。
（3）用户遇到图表性能问题时如何解决。
下面是不同角色对报告的运维方式：
（1）阅览者：在阅览报告时，能够方便的反馈报告的性能问题，能找到问题谁来解决。
（2）编辑者和管理员：管理员要及时发现性能问题、解决问题，编辑者要能协助管理员解决问题。
要运维报告，首先要定义保障的核心指标，也就是运维的目标，主要包括图表首访缓存命中率、图表查询错误率、高性能图表比例。其次要诊断性能问题，有数 BI 和底层引擎团队一起，研发了算子级别的性能诊断模型，提供从问题到诊断再到优化方案的闭环。比如定位到扫描表慢，诊断发现没有设置分区字段筛选，就会提供分区筛选的方案。
有了诊断模型之后，在图表、报告、模型下面都可以看到诊断出的问题和优化手段，在报告这里还可以看到实时的 timeline，图表在每个阶段查询的耗时，同时也能看到历史性能的分析。在项目中心，可以看到看到报告运维相关的系统报告，管理员可以跟踪这些指标不断的进行优化。
同时有数 BI 还提供了重点报告分级治理的方案，包括重点报告管理，资源隔离，缓存优先级，耗资源查询的治理等。
网易内部云音乐、严选、外部温氏都做了这块的治理，通过智能缓存、系统报告和重点报告分级治理，重点报告可用性和性能指标是非常稳定的：
（1）重点报告图表查询错误率在 0.1% 以下，没有了查询高峰错误，有少量是图表上的业务错误。
（2）5s 内图表比例基本上在 96% 以上，大部分图表都是非常快的。
04/未来计划
未来规划主要包括以下几方面：
（1）MPP 引擎：提升 MPP 任务运维能力和支持多集群。
（2）物化视图：物化创建推荐和增量物化。
（3）数据医生：提升算子诊断和性能优化推荐的准确性，同时完善项目级的诊断优化。
05/问答环节
Q1：BI 缓存体系的命中率是多少，预缓存提升了多少比率，什么场景预缓存不能解决？
A1：做的比较好的客户都在 90% 以上，预缓存提升至少 10%，不能解决的场景主要是分析类的场景，分析类场景要用物化视图来解决的。
Q2：数据新鲜度怎么保证？
A2：预缓存是基于数据产出的，除了实时场景外，大部分的用户查询的数据都是 T+1 的，所以在凌晨把这些数据计算出来就可以了。
Q3：数据医生使用怎么样？
A3：数据医生的诊断模型在升级迭代，目前重点报告分级治理使用效果还是非常好的，报告的量大了之后，保障所有的报告难度是非常大的，如果能够挑选出非常核心的报告，来做资源的隔离和治理，就能够保障核心的用户访问报告的需求，解决了主要矛盾。
Q4：缓存时间是多久，对有实时性有要求的怎么提升性能？
A4：如果是小时级的，也可以做预缓存，但是如果是完全实时的，则不会进行缓存。
Q5：实时数据缓存策略会不一样么？
A5：在模型配置中会设置缓存的过期时间。
Q6：一个报告端到端打开性能是什么样的？
A6：我们会定义一个高性能图表打开时间的阈值，比如 3s 或 5s，在这个时间内打开就是一个高性能图表，我们治理的客户，5s内图表比例都在96%以上。
Q7：业务方实时数据进 MPP 可以么？
A7：可以把调度设置为分钟级，增量写入。
Q8：怎么设置数据推的动作？
A8：一个是和中台打通，中台数据产出之后，把消息推送给我们，也提供了 API 的模式，数据产出之后可以调 API 把数据推过来。
Q9：不同数据源更新时间不一样，缓存更新时间怎么设置？
A10：这个在数据源层设置的本来就是不一样的，如果是一个实时的数据，那么可能秒级就会过期。
今天的分享就到这里，谢谢大家。
今日推荐
生成式 AI 模型构建实战
⏰ 活动时间：6/27-28 9:00-17:00
☕️ 活动地点：上海·世博中心
点击链接报名参会：2023年亚马逊云科技中国峰会 - 因构建_而可见
