数据库|双引擎驱动Quick BI十亿数据0.3秒分析，首屏展示时间缩短30%( 二 ) 数据库

任务调度机制
支持在各段加载和执行流程中利用组件或函数控制CPU时间和网络占用优先级，从而将首屏内容的展示时间点缩短至少了30% 。
截流渲染机制
支持Redux类数据流体系，以配置化方式控制单位时间组件渲染次数，组件平均渲染次数减少90%以上。
按需计算机制
按需加载和执行JS逻辑组件及其资源，利用LazyObject思路（即：使用时初始化执行，而非定义时）进行按需调用， LazyCache思路（即：命中时计算和缓存，而非实时）进行数据流模型计算，节省约30%的CPU时间以及40%的网络占用。
预加载机制
通过将原本串行依赖的流程逻辑按不同时机并行（如：当页面拉取JS资源时同时拉取后端数据，在空闲时预加载下一屏内容），根据历史使用习惯预先加载后续可能访问的内容，达到瞬时查看的效果。
资源本地化缓存机制
将js等资源本地化的形式，加上根据不同设备（移动端等）的资源管理策略，有效解决系统内存释放导致的缓存失效，弱网环境导致的资源加载缓慢等问题。

经过一系列核心能力的升级和特定场景的针对性优化，操作平均FPS（每秒传输帧数）可达55左右，较复杂报表下，首屏加载时间也从最初18秒降至3秒以内（中等简单报表2秒内），结合Quick引擎，还可以支持10亿级数据量的报表3秒内展现。
典型场景下的性能体验全面提升 1、数据开发视角的场景方案
（1）报表展示的数据在一定时间内固定不变
有些客户对数据需要每天进行一次汇总，并通过 Quick BI 的可视化图表以日报形式展示出来。这些展示的数据在下一次汇总之前都不会发生变化，同时这些汇总数据比较固定，不需要阅览报表的人主动更改查询条件。
如是场景，推荐开启数据集上的缓存功能。用户可以自行设置缓存的有效期，在有效期内，相同的查询会命中缓存，直接将该周期内第一次查询的结果毫秒级返回。以上述场景为例，用户可以开启 12 小时的缓存，这样日报只会在第一次打开时进行数据查询，之后一整天的时间，一旦客户点击打开，报表就会立刻展现。

（2）报表数据存在较多变化，对非实时数据进行分析
以大促为例，商家在活动结束后，对大促期间的销量、营业额以及营销投放效果进行复盘。数据分析包含很多维度，比如类目、地区、部门等等。商家的分析师或者决策者在查看报表时，往往会对维度进行调整、变更、钻取，来获得更加深入的洞察。这个场景下用户数据查询的动作多变，上述的缓存策略往往很难命中。
此时，可以在数据集的 Quick 引擎中开启抽取加速。抽取加速默认全表加速，允许用户同步T-1 的数据到 Quick 引擎高性能存储及分析模块中，后续的查询和计算会直接在 Quick 引擎中进行，减少用户数据库的性能压力。抽取加速可以做到亿级数据，亚秒级响应。
与此同时还可以开启智能预计算模式，会对用户的查询历史进行分析，提前对可能的查询进行预聚合。用户的查询如果命中，则会直接返回聚合结果。

（3）用户数据源查询慢，但对数据实时性有要求
有的用户，数仓里的数据每天都在实时变化。以仓储管理为例，仓库里每天货物的进出是动态的，这些数据会实时落到数据库里，而客户希望能够通过 Quick BI 的报表，对这些动态数据进行分析。显然，上面提到的缓存方案以及抽取加速都无法达成这个目的。
对于这类用户来说，他们可以在数据集的 Quick 引擎里开启实时加速，通过引擎内置的 MPP 内存计算引擎，对数据进行实时的内存计算，从而达到加速的目的。