分析引擎2.0已来，神策数据再刷行业标准

2020年初，疫情让许多创业公司紧急刹车，这无疑是一次极限压力测试。它让所有企业都知道，“黑天鹅”随时都会来，反脆弱能力很重要。

神策数据的反脆弱能力源于夯实的基本功。在过去的5年里，神策数据服务了1000余家企业。依托底层数据采集、建模、分析、应用的标准化的用户分析体系，神策数据使得超过EB级别的海量数据能够高效处理，并以秒级的响应速度，服务并驱动千余家企业的发展。

期间，神策数据定义了公认的行业最高标准：30分钟完成私有化部署、单日入库千亿条数据、亿级日活实时在线分析……至今，同行业内无一企业能够企及。

在当下的窗口期，神策数据视之为修炼内功的最好时期。复工两个月后，神策数据又一次震动行业：重构分析引擎，进入2.0时代!

为什么要优化分析引擎?

神策分析引擎是神策数据产品矩阵的核心组件之一，它负责神策分析中的所有分析模型的计算执行，此外，它还支撑了神策用户画像平台的标签人群的计算、神策智能运营系统中的受众选择等功能。

一般来说，它也是神策系统中最大的硬件资源(CPU、内存)占用方。因此，对它的性能进行持续优化一直是我们的工作重点。

神策数据作为一家以私有化部署为主的大数据软件服务提供商，随着客户群体在不断增加，客户的数据量级也在快速上升，目前，神策数据平台所处理的日新增数据量已经高达1500亿条，而神策数据的分析引擎每天处理的数据条数则在数万亿级别。

性能的持续优化一方面可以显著的提升产品使用体验的提升，而从另外角度看，也意味着我们的客户可以以更低的硬件成本来承载系统的运行。

神策分析引擎2.0围绕存储、查询执行、查询调度进行了全面升级与优化，下面详细介绍。

一、存储的优化

虽然我们的最终目标是为了优化查询的性能，但是数据的存储是查询的基础，因此首先我们在存储方面做了一系列的优化，其中最主要的是我们重构了事件(Event)数据的存储方案，此外我们也在数据的合并策略等其它方面做了优化。

重构事件数据的存储方案

神策数据平台中对于事件数据的存储方案在我们之前的文章中有比较详细的介绍，简单的说，我们的方案里使用了HDFS+Parquet来存储历史数据、Kudu存储实时数据的方式，同时按照日期、事件来进行分区，如下图所示：

这种存储方案对于导入和大部分的查询场景都是比较友好的。但是随着越来越复杂的应用场景，我们也发现了一些需求在目前的方案下无法得到满足：

1.在很多复杂的分析场景下，分析引擎需要先对数据进行按照用户、时间进行排序的处理，而由于底层的事件数据的有序性很有限，这样会导致在执行查询的时候需要对数据进行临时的排序操作，消耗比较多的资源。

2.一个典型的应用场景里会存在多种不同类型的事件，这些事件有的需要永久保留、高频查询，而有的可能只需要保留比较短的时间周期，或者在一段时间之后就不再高频使用。

3.虽然大部分的事件都是对历史的记录，在入库之后就不会需要进行更新。但是依然有部分类型的事件需要支持比较频繁且实时的更新操作，比较典型的如电商的订单事件，订单的状态往往是需要可变的，如果能实现直接对状态的更新会让很多分析场景更简单。

为了解决上面几个问题，我们对事件数据的存储方案进行了一次重构，完成了以下两个主要改进点：

1.进一步强化了对每个分区内数据的预排序。尽可能的保证数据的有序性，这样可以极大的减少我们在实时分析时需要的重排序时间。

2.支持对于不同事件分桶的数据使用完全不同的存储策略(Storage Policy)这些不同的存储策略可以使用不同的存储系统、存储周期、压缩算法等。

例如对于常规的事件，我们默认使用基于本地HDFS+Parquet的存储方案;而对于低频使用的事件，我们可以设置定期的归档策略，把历史数据放入AWS S3等更廉价的存储;对于需要支持更新的事件，则采用直接基于Kudu的存储。

可以看到，新的存储方案不仅直接支撑了后续复杂查询效率的优化，还使得客户在海量数据下的存储成本更加可控，同时，这个全新的设计也为未来更复杂的应用场景预留了足够的灵活性。

存储相关的其它优化

支持数据的实时导入是神策数据平台的重要特性，但是在实时导入的场景下，存储系统里会不可避免的产生大量的碎片文件，而这些碎片文件则会对查询的性能有很大负面影响。

在我们之前的设计里，这些碎片文件的合并是由一个定时调度的任务来执行，这个任务会持续的使用固定的资源来进行碎片数据的合并，这一方式会导致在系统的使用高峰期占用过多的资源，而在低峰期则可能产生资源空闲。

因此，我们对它的调度策略进行了优化，使用动态的调整与执行并行度的方式，以保证在尽可能用满系统资源的同时，不影响正常的查询负载。

此外，我们还优化了主要数据的压缩算法。在经过大量的真实数据测试之后，我们发现使用LZ4/ZSTD的组合方案来替换之前SNAPPY/GZIP的方案，可以在压缩比不变甚至略有提升的同时，降低数倍的CPU资源使用。

ZSTD官方的测试结果(https://github.com/facebook/zstd)

最后，我们还对稀疏宽表的数据的写入效率进行了优化，这个优化对于那些上千个属性的宽表的数据写入效率有数倍的提升。

二、查询执行的优化

查询执行，一直是检验系统是否健壮的试金石。后端存储的海量数据，只有查询引擎足够强大，才能保证前端风平浪静地实时查询，整体平稳运行。正如我们之前的文章所介绍的，神策分析引擎是以Impala的执行引擎为核心的系统(详情内容请参考链接：付力力:基于Impala构建实时用户行为分析引擎)，因此这部分主要也是对Impala的执行计划以及计算层做的修改。

优化基于用户行为序列的查询

基于用户行为序列的查询是应用场景非常普遍的一类分析需求，神策分析中的漏斗分析、归因分析、Session分析等功能都属于这一类。它们的共同点是需要得到每个用户的完整、有序的行为序列，然后进行一系列复杂的规则计算。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!