营销自动化场景下OLAP架构演进：从Hive数仓到实时分析

营销自动化跑一段时间后，你一定会遇到这个场景：用户标签、订单记录、广告投放数据、客服工单、微信社群行为……散落在五六个系统里，运营想要一张“最近30天在公众号看过文章、又在淘宝下过单但没领优惠券的高价值用户”名单，你对着数据仓库里几百张表，靠写SQL拼了三天，结果跑出来一张几千万行的中间表，下游BI直接超时。这时候你会发现，过去那套“数仓+宽表+报表”的玩法，已经撑不起“数据驱动营销”这四个字了。

这篇文章我主要想聊的，就是营销自动化系统里，多源数据场景下OLAP架构一步步演进的过程。不会只停留在“ClickHouse好快”这种结论上，而是把它拆开：数据从哪来、模型怎么建、查询怎么做、实时链路怎么接、踩过哪些坑、最后为什么还要停下来反思“数据驱动”本身的边界。如果你正在搭营销数据中台、或者被运营的各种分析需求反复折腾，这篇文章应该能给你一些可落地的参考。

1. 先想清楚：营销自动化为什么需要OLAP架构

很多团队做营销自动化，第一反应是上CRM、上MA系统，把用户分群和触达流程管理起来。但真正的难点往往不是“触达”本身，而是“凭什么给这个用户发这张券”，也就是决策依据。决策依据来自数据，而数据在营销场景里有一个非常典型的特征：多源且杂。

1.1 营销数据源的真实画像

我梳理一下自己实际接过的数据源，你会发现远不止“订单和用户表”这么简单：

• 第一方行为数据：前端埋点（页面浏览、按钮点击）、小程序路径、App启动、H5表单提交。这类数据量巨大，一天几千万条很正常，而且字段极其稀疏，每个事件带的参数都不一样。
• 交易与业务数据：订单、售后、优惠券核销、会员积分变动。这类数据在业务库（MySQL、PostgreSQL）里，规范程度高，但需要实时同步才能用。
• 客户主数据：CRM里的联系人、企业微信好友关系、销售跟进记录、客户星级。这类数据更新慢，但维度极其重要，决定了“这个人是谁”。
• 第三方投放数据：巨量引擎、腾讯广告、Google Ads的消耗、展示、点击数据。一般通过API拉取，字段命名和口径跟内部完全不一致。
• 客服互动数据：客服工单、会话记录、满意度评价。这些数据最大的问题是文本占大头，结构化程度低。

这些数据源有一个共性：没有一个系统能独立回答“用户完整旅程”的问题。所以第一步不是选OLAP引擎，而是先把数据汇聚的问题想清楚，也就是多源数据的接入层怎么设计。

1.2 营销分析的典型OLAP需求

数据汇聚之后，运营和分析师会提出什么样的查询需求？我归类下来大概是这几类：

• 多维筛选：按渠道、城市、用户等级、设备类型任意组合，筛出目标人群包，比如“北京、iOS端、近7天活跃、领过券未下单”。
• 漏斗转化分析：从曝光到访问、加购、下单、支付，每个环节的人数与转化率，还要能按照渠道/活动维度下钻。
• 留存与生命周期分析：某一天进入的新用户在后续N天的活跃/下单留存，这个对数据量要求非常高。
• 指标计算：GMV、客单价、转化率的看板统计，通常是固定粒度的汇总查询。

这些需求混合在一起，对查询引擎的要求就非常明确：支持高基数维度快速过滤、做多表关联或者大宽表扫描、能够在秒级甚至毫秒级返回聚合结果。传统用MySQL做报表肯定不行，用Hive跑离线更是隔天才能看到结果，而营销活动的响应周期往往只有几分钟到几小时。这就是OLAP引擎入场的前提。

2. 多源数据接入：模型设计的第一个分水岭

很多人一开始关心的是用ClickHouse还是Doris，但我在实际演进里发现，真正决定OLAP好不好用的，反而是接入层和数据建模。数据接得烂，再快的引擎也救不回来。

2.1 实时与离线的链路取舍

多源数据接入，最先要决策的就是每条链路走实时还是走离线。我自己的经验是两个维度来判断：数据源下游业务的时效要求，以及数据源本身的产生方式。

• 订单、支付、优惠券核销：强烈建议走实时链路，因为营销自动化里经常有“下单未支付后N分钟自动发券”这类实时场景，延迟超过1分钟，活动体验就很差了。
• 埋点行为数据：最好走实时管道同时落地两份，一份进OLAP做实时分析，一份进数据湖做离线全量归档。因为埋点数据量太大，实时链路一旦出问题，离线归档可以作为数据恢复的兜底。
• CRM主数据、投放数据：离线T+1基本够用，除非你在做实时广告位出价调整，那需要的已经是另一套技术栈了。

在实际架构里，我通常用Debezium订阅业务库的binlog到Kafka，再通过Flink做清洗和轻量聚合，最后写入OLAP引擎；离线链路用Airflow编排Spark任务做批量同步。这么做的好处是逻辑清晰：实时链路管“新鲜”，离线链路管“全量”，质量出问题时能够互相校验。

2.2 宽表优先还是星型模型优先

这个问题在OLAP场景下争论特别多。先说结论：营销分析场景，宽表优先，但不是无脑一张表装天下。

为什么说宽表优先？OLAP引擎在底层大多数是列式存储，如果查询需要关联大量维度表，每次都要走分布式join，性能损耗很大。特别是ClickHouse这种引擎，join本来就不是强项，用得不好直接拖垮查询性能。相比起来，把常用维度冗余进事实表里，虽然占存储，但换来的是查询时不用join，性能提升非常可观。

但一张表装天下也有问题。营销数据的维度实在太容易变化了。举一个实际案例：我们最早把所有用户事件压成一张“用户行为大宽表”，包含用户基础属性、设备、页面、商品、渠道等60多个字段。刚开始查询很爽，但某次投放渠道接了个新平台，对方传了一个新的广告位ID字段，我们只能给表加列，结果一个加了两年的大