本文基于营销自动化数据启动场景，分析先容了Presto+大宽表决议、Bitmap决议、StarRocks决议的架构演进。

1分钟看图掌持中枢不雅点

一、业务配景从增量阛阓投入存量阛阓，轻视型的运营也曾无法为企业带来更多的阛阓份额和营收增长。这一近况也启动企业想考良好化运营，通过良好化运营挖掘出用户最大价值，从而栽种用户 LTV。良好化运营落地的紧迫举措便是数据启动。通过门店数字化运营，不错完了买通品牌与导购与滥用者的全程触点，千里淀、留存场景化交互数据，深度挖掘客户需求，为用户提供个性化功绩。举例：线下的门店开业梗概作念一些促销行为，通过短信、富媒体短信、企业微信、导购一又友圈等触点将行为信息传递给门店操纵有需要的用 #架构 #每天一个学问点户，吸援用户到店。

二、基础架构vivo 通过智高东说念主机以及智高东说念主机售卖渠说念的运营，累积了全渠说念，全场景的门店关联数据。 标签数据： 用户画像的关键点在于通过索要标签的形势将用户特征突显出来，现存存量用户数据量级 5亿+ 。事件数据：无为画像标签的产出需要数据团队清洗加工，算法介入，上架等一系列操作，分娩资本较大，且机动性和及时性齐有不及。事件数据基于其浩大的场景化推崇才调，加工简便，上架速率快的特质，成为标签除外的另一个紧迫数据来源。门店LBS数据： 线下营销重点无为是吸援用户到店，体验门店家具，从而促成往还。而门店有其独到的组织架构，因此门店关联的LBS亦然紧迫的数据源之一，数据团队基于存量用户数据瞻望算门店LBS相干数据蔓延至 90亿+ 。抽象了标签、事件、门店 LBS 数据的受众筛选，成为良好化营销的一浩劫点。

起首 MySQL 的性能不及以救助亿级数据多表且或非逻辑及时计算，通过调研以及公司海量计算组团队的地方，咱们遴荐了 OLAP（用于分析和查询大规模数据集的计算处理工夫）引擎 Presto，哄骗 Presto 的 SQL on Everything 脾气，完了了纷乱据源抽象的受众圈选。

图中为营销自动化平台数据启动合座架构，分为业务层、计算层、数仓层。 数仓层：主要为Hive数据仓库，数据由大数据团队整合标签、门店、事件，以及用户自界说上传的东说念主群包数据。计算层：由OLAP引擎-Presto组成，推广SQL、取得Hive数仓数据进行及时计算。业务层：提供东说念主群受众筛选、受世东说念主群固化、渠说念东说念主群下发逻辑业务处理才调；对外主要提供受众筛选-标签+事件+东说念主群的预估才调。基于这套架构的痛点： 标签数据来源DMP系统，大数据团队需先上架DMP系统，再上架自有CMS系统中，时效T+2起步。标签宽表跟着标署名段增长，一个宽表300+字段，保重资本高。标签+门店LBS大表，查询性能分钟级别反应，用户体验欠安。三、架构迭代为贬责以上问题点，通过与大数据、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 Plugin，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='#标签法例')

通过编造化 DMP 表，在 Presto 中领悟后查询 DMP 标签 Bitmap 用户数据复返下标数组与 id_mapping 表进行计算。

3.1.2 完了效能营销自动化中枢经过中移除了对大宽表依赖，新标签上架可由正本1.5东说念主天栽种到0.5东说念主天。

查询耗时由现时的分钟级别优化到秒级别（P90=38s），其中纯标签场景不错低至毫秒级别。

3.1.3 Presto + Bitmap的局限这次迭代贬责了查询性能和标签上架效能问题，但跟着业务复杂度加多，现存架构面对新的工夫挑战： 复杂查询性能瓶颈： 面对多表关联（Join）和复杂团员的查询场景，尽头是在门店LBS数据表的基础上进行多表Join时，性能与内存管束面对压力。工夫抑制业务安全： Presto无法写入加密Hive表，胜利拦阻了数据安全合规的落地，金年会成为一项待贬责的工夫债务。C 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 完了效能资源降本： 原有Presto集群53台，现时StarRocks搭建的集群为3台，用度资本裁减约 93% 。性能栽种： 查询P95耗时从 65s 裁减至 6s 。数据安全：底层无HDFS文献，现时可使用StarRocks函数对数据进行加解密，后期由海量计算组共事开采自动加解密功能。3.2.5 切换后的问题问题一：营销短信任务下发场景中，仅部分数据下发（如总量下发一千万条，本色仅允许下发一百万条）分析考据： 通过日记分析发现，当查询任务触及上千万数据时，本色仅复返一百万条落幕，超出数据丢失。关联查询SQL示举例下：select channel_id from table where crowd_id=100。由于该SQL在迁徙至StarRocks过程中未作念语法矫正，初步判断为StarRocks扫尾所致。查阅StarRocks官方文档，阐明存在系统变量 sql_select_limit，用于扫尾查询落幕的数据量。关联领悟详见： StarRocks系统变量文档 。为考据该判断，在测试集群平差异将该参数确立为100万、200万，并土产货环境进行考据，落幕适合预期：查询落幕数目受限于所设参数值。贬责决议：和洽集群运维共事，调治线上 StarRocks 集群的系统变量 sql_select_limit，撤消100万条落幕辘集束，并在重启集群后问题得以贬责。问题二：功绩频频 Full GC，且 GC 耗时1s 以上，导致功绩恳求超时刻析考据： 超时恳求在功绩端的给与时期至处理复返时期均在1s内，但客服端纪录的恳求时期早于功绩给与时期，且差值进步1s，经与运维换取阐明，摈斥汇注问题。在融合可不雅测平台中检察该功绩应用监控，发现超频频间点存在Full GC形态，且GC耗时进步1s，随后树立JVM参数生成GC日记便于进一步分析。使用Memory Analyzer Tool分析生成的堆转储文献，发现主如果大对象为RowDataStatic，该对象在取得数据库数据时是将系数落幕集加载至内存中。由于此前已撤消100万数据查询扫尾，当数据量达到老年代空间临界值时，触发Full GC。定为到查询明细数据的代码逻辑存在问题。Presto是流式查询，而StarRocks基于MySQL条约聚集，需树立相应参数才能启用流式查询机制。在土产货环境中，通过调治PreparedStatement的fetchSize参数进行对比测试，复现了线上功绩GC暂停形态：当未启用流式查询时，GC暂停时期长达10s。贬责决议：通过矫正代码中 MySQL JDBC 的树立参数，启用流式查询功能。 四、结语本文主要先容了营销自动化数据启动-OLAP 架构演进史，领先为贬责业务诉求，救助业务快速上线，基础架构遴荐 Presto+大宽表决议。

跟着数据量及标签维度的激增，为栽种标签上架效能，引入 Bitmap 决议完了预团员计算，通过标签上架融合至 DMP，显赫裁减反应延长；在温柔业务诉求的同期，针对数据安全地方进行深切探索 OLAP 引擎才调金年会官网首页入口，从 Presto 切换为 StarRocks 引擎，不仅在数据安全方面有保险，同期也栽种了查询性能以及完成机器资源的降本。

比赛投注(中国)官方网站

• 启动
• 数据
• 金年会官网首页入口
• 自动化
• 营销