江苏龙网

  1. 首页 > 资讯 > 科技 > >

#数据#分析引擎2.0已来，神策数据再刷行业标准！( 二 )


2.支持对于不同事件分桶的数据使用完全不同的存储策略(Storage Policy)这些不同的存储策略可以使用不同的存储系统、存储周期、压缩算法等 。
例如对于常规的事件 ， 我们默认使用基于本地HDFS+Parquet的存储方案;而对于低频使用的事件 ， 我们可以设置定期的归档策略 ， 把历史数据放入AWS S3等更廉价的存储;对于需要支持更新的事件 ， 则采用直接基于Kudu的存储 。
#数据#分析引擎2.0已来，神策数据再刷行业标准！
图片

可以看到 ， 新的存储方案不仅直接支撑了后续复杂查询效率的优化 ， 还使得客户在海量数据下的存储成本更加可控 ， 同时 ， 这个全新的设计也为未来更复杂的应用场景预留了足够的灵活性 。
存储相关的其它优化
支持数据的实时导入是神策数据平台的重要特性 ， 但是在实时导入的场景下 ， 存储系统里会不可避免的产生大量的碎片文件 ， 而这些碎片文件则会对查询的性能有很大负面影响 。
在我们之前的设计里 ， 这些碎片文件的合并是由一个定时调度的任务来执行 ， 这个任务会持续的使用固定的资源来进行碎片数据的合并 ， 这一方式会导致在系统的使用高峰期占用过多的资源 ， 而在低峰期则可能产生资源空闲 。
因此 ， 我们对它的调度策略进行了优化 ， 使用动态的调整与执行并行度的方式 ， 以保证在尽可能用满系统资源的同时 ， 不影响正常的查询负载 。
此外 ， 我们还优化了主要数据的压缩算法 。 在经过大量的真实数据测试之后 ， 我们发现使用LZ4/ZSTD的组合方案来替换之前SNAPPY/GZIP的方案 ， 可以在压缩比不变甚至略有提升的同时 ， 降低数倍的CPU资源使用 。
#数据#分析引擎2.0已来，神策数据再刷行业标准！
图片

ZSTD官方的测试结果
最后 ， 我们还对稀疏宽表的数据的写入效率进行了优化 ， 这个优化对于那些上千个属性的宽表的数据写入效率有数倍的提升 。
二、查询执行的优化
查询执行 ， 一直是检验系统是否健壮的试金石 。 后端存储的海量数据 ， 只有查询引擎足够强大 ， 才能保证前端风平浪静地实时查询 ， 整体平稳运行 。 正如我们之前的文章所介绍的 ， 神策分析引擎是以Impala的执行引擎为核心的系统(详情内容请参考链接：付力力:基于Impala构建实时用户行为分析引擎) ， 因此这部分主要也是对Impala的执行计划以及计算层做的修改 。
优化基于用户行为序列的查询
基于用户行为序列的查询是应用场景非常普遍的一类分析需求 ， 神策分析中的漏斗分析、归因分析、Session分析等功能都属于这一类 。 它们的共同点是需要得到每个用户的完整、有序的行为序列 ， 然后进行一系列复杂的规则计算 。
在我们之前的分析引擎的实现里 ， 受限于底层的数据存储结构 ， 这类查询每次都需要对几亿至上千亿条的数据进行重排序操作 ， 虽然我们对这个排序操作本身已经做了比较深度的优化 ， 但是依然是非常耗时的操作 。 尤其在内存资源不足的情况下 ， 还会启用基于磁盘外部排序 ， 这样整体的耗时会更长 。
在一般的数据分析系统里 ， 通常解决这类复杂分析问题的思路是进行预计算 ， 即在预先定义好维度、指标的前提之下 ， 把结果提前计算出来并缓存好 。 不过预计算的局限性是非常明显的 ， 即很难应对灵活多变的需求 。
因此 ， 为了更好的支撑这类灵活的分析需求 ， 我们依然确定了从查询执行本身来优化的整体思路 ， 基于上文所提到的存储结构优化 ， 在Impala执行层更加充分的利用了底层数据的有序性 ， 把全局的内存排序优化为了局部的归并排序 ， 最终使用更少的内存资源和更短的执行时间完成了查询的执行 。
#数据#分析引擎2.0已来，神策数据再刷行业标准！
图片

优化前后的执行计划对比


推荐阅读


上一篇：「产业」团油、满帮集团等领衔产业互联网演变

下一篇：「空气」Kaiterra正式推出Square墙内空气质量监测仪：低调简约，无痕融入商用空间