营销自动化数据驱动 - 多源数据 OLAP 架构演进

者为，vivo互联网服务器团队之中的Liu Xianchao。

此篇文章是依据营销自动化数据驱动的场景，对Presto与大宽表方案、Bitmap方案、StarRocks方案的架构演进进行了分析并予以介绍。

1分钟看图掌握核心观点

对应图一与图二而言，就辅助理解全文这方面，您究竟更倾向于选择哪一张图呢，欢迎于评论区留下您的看法，进行相关留言。

一、业务背景

当企业从增量市场步入存量市场，早前粗放型那种运营方式，已然没办法再给企业带去更多的市场份额，以及促使营收实现增长。而这样一种现状实际上也推动着企业去思索精细化运营，借助精细化运营把用户的最大价值给挖掘出来，进而提升用户LTV。精细化运营得以落地的一项关键举措便是依靠数据驱动。凭借门店数字化运营，能够达成将品牌与导购以及消费者之间的全程触点予以打通，沉淀、留存场景化交互数据，深入挖掘客户需求，为用户供给个性化服务。比如说，线下的店铺开张，或者开展一些促销活动，借助短信、富媒体短信、企业微信、导购朋友圈等接触点，把活动信息传送给门店周边有需求的用户，以此吸引用户到店。

二、基础架构

vivo经由智能手机开展运营，借助智能手机售卖方渠道，积攒了涵盖全渠道、全场景的门店关联数据。

对于受众筛选而言，它综合了标签数据，还综合了事件数据，也综合了门店LBS数据，这就使得成为精细化营销的一大难点状况出现了。

首先，MySQL的性能没办法支撑亿级数据，再者多表且或非逻辑实时计算也不行，经过调研，还有依据公司海量计算组团队的方向，我们采用了OLAP（一种用于分析和查询大规模数据集的计算处理技术）引擎Presto，借助Presto的SQL on Everything特性，达成了多数据源综合的受众圈选。

可以看到，图里面呈现的是营销自动化平台的数据驱动的整体架构，架构它被划分成了业务层，还有计算层，再就是数仓层。

基于这套架构的痛点：

三、架构迭代

针对上述问题点的解决之道，在于借由跟大数据团队以及 DMP 团队携手合作，以此来对底层标签数据结构予以优化，并且采用 Bitmap 数据结构用于设计标签，进而对底层数据源开展优化。

3.1 Bitmap方案3.1.1 设计与实现

数据结构设计如下：

按照用户这个维度，预先计算出自增ID ，把它用作Bitmap下标 ，再将标签列值转变为行值 ，每一行都存放着把所有用户压缩而成的Bitmap的数据。

由于引入DMP标签服务，需对现有OLAP引擎进行改造。

底层数据源，因Presto SQL On Everything的特性，能支持各类存储于不同数据库里的数据，借助开发Presto Connector Plugin来获取DMP平台标签服务，而大部分数据处于Hive数仓表中，比如像事件数据、门店数据等。

Presto计算层面，于Presto服务内，着重开发了和Presto Bitmap相关联的UDF插件，由Presto Connector去获取DMP平台的标签，借由Presto源码改造达成Select In Bitmap的能力，完成上述改造后，计算层能够凭借统一的SQL达成各类服务。

使用示例：

select count(user_id) from user_id_mapping where day='${day}'and user_rn in(select bitmap from dmp.virtual_table where rule='#标签规则')

于Presto里，借助虚拟化DMP表，于解析之后进而查询DMP标签Bitmap用户数据，使之返回下标数组，再与id_mapping表展开计算。

3.1.2 实现效果

移除了营销自动化核心流程里对大宽表的依赖，将原来需要1.5人天的新标签上架，提升到了只需0.5人天。

查询所耗时间，从当下的以分钟为单位，优化至以秒为单位（P90等于38秒），当中纯粹的标签场景，能够低到以毫秒为单位。

3.1.3 Presto + Bitmap的局限

针对此次迭代而言，其成功解决了查询性能的相关问题，以及标签上架效率这一问题，然而，随着业务复杂度呈现出增加趋势，现有的架构面临着崭新的技术挑战：

3.2 引入StarRocks方案

因考虑要解决上述提及的局限，还要为下一代有关实时数据分析的业务场景做好相应准备，所以我们对StarRocks展开评估，进而予以引入，它具有存算一体架构以及向量化执行引擎，对其寄望于能够在实时分析场景当中带来突破性的提升。

3.2.1 与Presto现有架构对比

要将切换StarRocks的升级价值予以体现，需从高性能这一维度展开比较，还要从高可用这一角度进行对照，并且要从高安全这个方面加以对比。

3.2.2 现状场景分析

历经3.2.1的调研与对比，显著明确了StarRocks具有的优势，进而针对现有业务系统展开场景分析，预先把StarRocks须兼容的方面改造完成句号。

3.2.3 落地规划

在把切换 StarRocks 需要改造的那些点都给准备妥当之后，我们会依照“由简到繁、由读到写、分阶段推进”这个原则，划分成四个阶段用以改造业务系统，从而控制切换风险以及实现平滑过渡。

经过以上迭代后架构如下：

变计算和数仓层为存算层，计算与数仓走向一体化，且整体受StarRocks管控。

3.2.4 实现效果

3.2.5 切换后的问题

问题一：

营销短信任务出现下行的那种场景里，只是有一部分的数据会施行下发动作，就好像总量要去下发达到一千万条之多，然而实际上仅仅是被允许去下发一百万条这么个情况。

分析验证：

解决办法是，和集群运维方面的同事进行协调工作，对线上的StarRocks集群的系统变量sql_select_limit作出调整，将100万条结果集的限制予以解除，在干完这些事情之后，重启集群，最终问题得到了解决。

问题二：

服务出现频繁的Full GC情况，而且GC所花费的时间在1s以上，进而致使服务请求的发送出现超时现象。

分析验证：

解决方案是，对代码里MySQL JDBC的配置参数予以改造，以此启用流式查询功能，实现该功能的启用。

四、结语

这本是重点讲述营销自动化数据驱动 - OLAP架构从起始到如今的发展历程，一开始是为了应对业务方面的需求，促使业务能够迅速上线，其基础架构选用的是Presto加上大宽表这种方案。

随着数据量急剧增多，标签维度大幅增加，为了提高标签上架的效率，引入Bitmap方案来实现预聚合计算，借助标签上架统一到DMP，明显减低了响应延迟；在满足业务需求的同时，针对数据安全方向深入探究OLAP引擎能力，从Presto转换为StarRocks引擎，不但在数据安全方面有保障，而且提升了查询性能，还完成了机器资源的成本降低。

相关标签： # 营销自动化 # 数据驱动 # OLAP架构 # Presto # StarRocks