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

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

2020年初 , 疫情让许多创业公司紧急刹车 , 这无疑是一次极限压力测试 。 它让所有企业都知道 , “黑天鹅”随时都会来 , 反脆弱能力很重要 。
神策数据的反脆弱能力源于夯实的基本功 。 在过去的5年里 , 神策数据服务了1000余家企业 。 依托底层数据采集、建模、分析、应用的标准化的用户分析体系 , 神策数据使得超过EB级别的海量数据(603138,股吧)能够高效处理 , 并以秒级的响应速度 , 服务并驱动千余家企业的发展 。
期间 , 神策数据定义了公认的行业最高标准:30分钟完成私有化部署、单日入库千亿条数据、亿级日活实时在线分析……至今 , 同行业内无一企业能够企及 。
在当下的窗口期 , 神策数据视之为修炼内功的最好时期 。 复工两个月后 , 神策数据又一次震动行业:重构分析引擎 , 进入2.0时代!
为什么要优化分析引擎?
神策分析引擎是神策数据产品矩阵的核心组件之一 , 它负责神策分析中的所有分析模型的计算执行 , 此外 , 它还支撑了神策用户画像平台的标签人群的计算、神策智能运营系统中的受众选择等功能 。
一般来说 , 它也是神策系统中最大的硬件资源(CPU、内存)占用方 。 因此 , 对它的性能进行持续优化一直是我们的工作重点 。
神策数据作为一家以私有化部署为主的大数据软件服务提供商 , 随着客户群体在不断增加 , 客户的数据量级也在快速上升 , 目前 , 神策数据平台所处理的日新增数据量已经高达1500亿条 , 而神策数据的分析引擎每天处理的数据条数则在数万亿级别 。
性能的持续优化一方面可以显著的提升产品使用体验的提升 , 而从另外角度看 , 也意味着我们的客户可以以更低的硬件成本来承载系统的运行 。
神策分析引擎2.0围绕存储、查询执行、查询调度进行了全面升级与优化 , 下面详细介绍 。
一、存储的优化
虽然我们的最终目标是为了优化查询的性能 , 但是数据的存储是查询的基础 , 因此首先我们在存储方面做了一系列的优化 , 其中最主要的是我们重构了事件(Event)数据的存储方案 , 此外我们也在数据的合并策略等其它方面做了优化 。
重构事件数据的存储方案
神策数据平台中对于事件数据的存储方案在我们之前的文章中有比较详细的介绍 , 简单的说 , 我们的方案里使用了HDFS+Parquet来存储历史数据、Kudu存储实时数据的方式 , 同时按照日期、事件来进行分区 , 如下图所示:
#数据#分析引擎2.0已来,神策数据再刷行业标准!
图片

这种存储方案对于导入和大部分的查询场景都是比较友好的 。 但是随着越来越复杂的应用场景 , 我们也发现了一些需求在目前的方案下无法得到满足:
1.在很多复杂的分析场景下 , 分析引擎需要先对数据进行按照用户、时间进行排序的处理 , 而由于底层的事件数据的有序性很有限 , 这样会导致在执行查询的时候需要对数据进行临时的排序操作 , 消耗比较多的资源 。
2.一个典型的应用场景里会存在多种不同类型的事件 , 这些事件有的需要永久保留、高频查询 , 而有的可能只需要保留比较短的时间周期 , 或者在一段时间之后就不再高频使用 。
3.虽然大部分的事件都是对历史的记录 , 在入库之后就不会需要进行更新 。 但是依然有部分类型的事件需要支持比较频繁且实时的更新操作 , 比较典型的如电商的订单事件 , 订单的状态往往是需要可变的 , 如果能实现直接对状态的更新会让很多分析场景更简单 。
为了解决上面几个问题 , 我们对事件数据的存储方案进行了一次重构 , 完成了以下两个主要改进点:
1.进一步强化了对每个分区内数据的预排序 。 尽可能的保证数据的有序性 , 这样可以极大的减少我们在实时分析时需要的重排序时间 。


推荐阅读