#数据#分析引擎2.0已来,神策数据再刷行业标准!( 三 )


在这个优化点完成之后 , 部分复杂查询场景的效率提升了10倍 , 而内存使用则降低到原本的1/5 。
查询引擎的其它优化
除了专门针对用户行为序列查询的优化之外 , 我们还对Impala的代码生成(Codegen)技术做了进一步的扩展 , 让它在更多的场景下可以使用 。
另外还实现了Join表达式下推的优化、针对复杂条件表达式的表达式预求值优化等 , 这些优化都在不同的使用场景下提升了数倍的查询效率 。
值得一提的是 , 由于这些优化点中很多并非神策独有的场景 , 我们也会把这类通用的优化点都提交给Impala社区 , 其中部分已经合并到最新的官方Release版本中 。
三、查询调度的优化
查询性能上的指标提升固然重要 , 但是对于神策系统的直接使用者来说 , 在查询性能提升同时 , 也更期望有稳定优异的综合使用体验 。 尤其在数据量巨大、硬件资源有限的客观场景之下 , 不同查询的响应时间也会存在比较大的差异 , 但是我们依然期望可以通过在查询调度、产品体验上的一系列优化 , 让每位用户都能在一个可预期的时间内 , 及时得到正确的数据分析结果 。
查询资源预估
Impala并不是一个为高并发或者大量用户共同使用而设计的系统 , 尤其是在遇到大量高内存消耗查询的场景下 , 很容易出现集体失败的情况 。 而这种情况之所以出现 , 最主要的问题就在于查询引擎往往很难准确预估出一个查询所需要的资源 , 尤其是内存资源的大小 。
只有有了准确的资源预估 , 查询的分级调度、排队、并发控制等策略才有了执行的前提 。 不过很遗憾的是 , 虽然Impala最近发布的几个新版本也在查询的资源预估、资源的控制方面做了不少的改进 , 但是依然不能满足神策分析这种复杂应用场景的需要 。
不过 , 我们也发现并非一定需要依赖Impala才能获取到查询预估的信息 。 神策分析虽然是一个非常灵活的数据分析系统 , 但是在实际的应用场景下 , 用户的查询模式上依然还是会形成某种规律 。
因此 , 我们完全通过对已经完成的历史查询记录的分析 , 结合Impala的已有功能 , 构建出了一个查询资源预估的模型 。 这样 , 我们可以在任何一个查询执行之前 , 对它的资源消耗做出相对准确的预估 。
有了准确的查询资源预估 , 神策数据分析系统不但可以告知用户每个查询的大致执行时长 , 还可以在查询资源不足的情况下实现对查询资源的有效调度 , 从而避免资源挤兑导致查询连环失败的现象 。
在此基础上 , 我们还支持对用户、角色、项目等不同维度的查询资源进行精细化控制 , 以满足集团型客户在资源控制方面的复杂需求 。
异步查询
大部分场景下 , 神策分析都可以将分析结果实时返回给用户 , 例如在数秒或者不超过30秒的时间内返回并展现出结果 。
但在以下个别场景中 , 可能需要用户等待数分钟或者更久:
1)查询的数据量特别大 , 同时查询复杂度很高 , 且无法命中缓存;
2)查询的并发人数较多 , 且无法命中缓存;
3)查询返回的结果集特别大 , 例如查询一个用户群的列表 , 返回的结果集可能有几百兆或者更大 。
考虑到尽可能不阻塞用户的查询工作 , 且避免因误操作关闭页面导致无法找回之前的查询结果 , 我们在产品中增加了异步查询功能 。
针对上述三个场景 , 允许用户将此查询保留至后台持续计算 。 当查询完成 , 通过消息通知及时告知用户查看或下载分析结果 。
#数据#分析引擎2.0已来,神策数据再刷行业标准!
图片

整体性能提升对比
附上做完上面的所有优化之后 , 我们自己模拟的标准数据集下在一些典型场景下的性能提升对比:
#数据#分析引擎2.0已来,神策数据再刷行业标准!
图片

神策分析引擎2.0是神策数据各产品线和分析模型演进与迭代的基础 , 本文提到的部分功能及优化点已经随着神策分析新版本的上线覆盖了数百家客户 , 部分底层架构改动较大的优化点则正在小范围试运行阶段 , 会在未来的两个月内逐步覆盖到神策数据的所有客户 。


推荐阅读