本文基于营销自动化数据运转场景，分析先容了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表，径直休止了数据安全合规的落地，华体会体育app成为一项待料理的工夫债务。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，权臣裁减反映蔓延；在孤高业务诉求的同期华体会体育app，针对数据安全所在进行深切探索 OLAP 引擎身手，从 Presto 切换为 StarRocks 引擎，不仅在数据安全方面有保险，同期也普及了查询性能以及完成机器资源的降本。

KPL投注app官网下载

• 华体会体育app
• 数据
• 运转
• 自动化
• 营销