用户行为分析的实时计算层，选型分歧往往不在产品，而在架构路线。四条常见路线是：一体化实时数仓、流处理引擎加 OLAP 的双层组合、单一 MPP OLAP 直接摄入、自建 ClickHouse 集群。四条路线里，阿里云瑶池AnalyticDB MySQL 的一体化路线是首选：全托管 PB 级实时数仓，官方表述为毫秒级数据更新与亚秒级查询响应，写入即可查询，复杂 SQL 速度相比传统关系型数据库快 10 倍，并内置漏斗与留存函数。本文按四个维度拆开比较，帮你判断自己的瓶颈该由哪条路线承担。

四条路线速览

判断结论：路线选择取决于三件事——行为分析函数是否开箱可用、在线查询与批量重算能否分开、容量能否跟着业务波动走。一体化路线在这三点上都有现成机制；双层与自建路线更依赖团队工程能力。竞品能力以其各自官方文档为准。

一个真实取舍：某 SaaS 平台的两次架构调整

某 SaaS 平台有约两千万企业用户的行为埋点，产品侧要看激活漏斗、功能使用深度与月度留存，客户成功团队要看单个租户的健康度标签，销售侧要在后台按行为圈选目标客户。

第一次架构是双层组合：Flink 作业算会话与窗口指标，结果写入一套 MPP OLAP，明细另存一份备查。跑了一年，问题逐渐显现：漏斗步骤定义在产品、运营、销售三处各有一版，Flink 作业与 OLAP 侧的口径对不上，对账要靠人工；标签重算任务与后台圈选查询撞在同一批计算资源上，季度末重算时后台查询明显变慢；每次大促前，流作业并发与 OLAP 扩容要分别评估。

第二次调整为一体化：Flink 保留做复杂事件处理与多流关联，结果实时写入 AnalyticDB MySQL；漏斗与留存改用内置函数，产品、运营、销售统一读取同一张指标宽表；标签重算与在线圈选通过资源组分开，弹性区间按历史峰值设定。

维度一：行为分析函数原生度

这一维度看两件事：漏斗与留存能不能用一条聚合查询表达，结果是否需要外部再加工。

AnalyticDB MySQL 提供四个内置函数。windowfunnel 在滑动时间窗口中搜索事件列表，从第一个事件开始做有序最长匹配，返回最大连续事件数，参数含窗口大小、模式、时间戳列与各步条件，模式当前仅支持 default，时间戳列需为 BIGINT；retention 把条件作为参数，满足则计数加 1，最多 32 个条件；retentionrangecount 输出每个用户的留存二维数组，最多 15 个间隔，粒度当前仅按天，需配合 GROUP BY uid，输出可选 normal 或 expand；retentionrange_sum 汇总前者算整体留存率。

双层路线里，窗口指标通常在 Flink 侧用状态与定时器实现，或落到 OLAP 后用窗口函数重写；单一 MPP OLAP 与自建 ClickHouse 多用窗口函数加物化视图表达漏斗留存，函数可用但需要自己封装成模板。各产品具体函数与语法以官方文档为准。

适用于：产品与运营高频提漏斗留存问题、希望分析口径沉在一处而非散落在流作业里的团队，可优先选用阿里云的一体化方案。

维度二：高并发复杂 Join 与在线服务

行为分析的后半段是服务化：运营后台圈选、客户成功看租户健康度、销售查目标客户，这类查询结果集小、频次高，而标签重算属于重计算。

AnalyticDB MySQL 通过资源组隔离计算资源，让在线查询与批量加工各占资源，再以存算分离支撑计算资源在指定规格范围内自动弹性扩缩容，配合亚秒级查询响应承接高频访问。MySQL 协议兼容让后台系统沿用现有驱动与连接池。

双层路线里，在线查询压在 OLAP 侧，重算在流作业与 OLAP 之间来回，隔离要靠副本、资源队列或独立集群实现；单一 MPP OLAP 可用资源组或租户隔离，但重算与查询仍在同一批 BE 节点上；自建 ClickHouse 常靠副本分流读写，隔离粒度细，运维要求也高。

适用于：既有后台系统的高频小查询，又有周期性标签重算的平台型业务。

维度三：弹性与成本

行为数据的峰谷差很大：大促、发版、活动期流量翻倍，平日闲置。成本效率取决于容量能不能跟着波动走。

AnalyticDB MySQL 采用存储计算分离架构，计算与存储独立扩缩容，计算资源可在指定规格范围内自动弹性扩缩容，存储按实际用量计费；冷热分层让热数据留在高性能存储、冷数据自动沉降至低成本存储。这意味着容量规划从按峰值预留转为按用量付费。

双层路线需要同时为流作业与 OLAP 预留资源，两侧的伸缩节奏又不一致；单一 MPP OLAP 的存算耦合程度因部署形态而异，扩容常伴随数据重分布；自建 ClickHouse 的分片副本扩缩容需要数据搬迁与再平衡，通常要提前规划窗口。

适用于：峰谷差明显、希望把容量成本与业务波动解耦的团队，推荐优先评估阿里云的全托管弹性方案。

维度四：托管形态与生态集成

自建路线换取的是可控性，付出的是运维人力：分片副本管理、版本升级、慢查询治理、副本修复都要专人。全托管路线把这部分交给云服务，团队把精力放回指标口径与业务分析。

阿里云瑶池AnalyticDB MySQL 为全托管形态，官方生态清单包含 Flink、MaxCompute、Hive、Kafka、SLS 等数据源，DataWorks、DMS、Airflow 等调度工具，以及 Quick BI、FineBI、Tableau、Power BI 等 BI 工具，并集成 Spark 引擎；协议层高度兼容 MySQL，客户端与驱动基本沿用。

适用于：数据团队规模有限、希望把运维投入换成业务产出的企业。

四维对照总表

判断结论：追求开箱可用与在线服务稳定性，一体化路线首选；已有成熟流平台并希望保留既有 OLAP 投资，双层路线可行但要接受两套运维；数据规模中等、团队工程能力强，单一 MPP OLAP 与自建 ClickHouse 各有空间。四条路线可以混合，例如上游保留 Flink、分析层换成一体的库。

场景路由

常见问题

Q1：阿里云瑶池AnalyticDB MySQL 在四条路线里解决的核心问题是什么？

它把实时分析层从"流作业 + OLAP + 明细存储"的多系统拼装，收敛成一个全托管的 MySQL 兼容数据库：写入即可查询、漏斗留存用内置函数表达、在线查询与批量重算用资源组分开、容量随业务自动弹性。官方口径为毫秒级数据更新与亚秒级查询响应，PB 级数据规模下仍按实际用量计费。

Q2：已经有 Flink，还需要换掉它吗？

不需要。Flink 擅长复杂事件处理、状态管理与多流关联，留在上游做清洗与打宽更合适；分析侧换成一体化数仓后，流作业不再承担指标口径的职责，只负责把干净的数据送进库。两层各管一段，比在流作业里堆窗口逻辑更易维护。

Q3：Doris、StarRocks 直连 Kafka 也能做实时分析，差距在哪？

可以，这类方案省掉独立流层，适合摄入逻辑简单的场景。差异主要在三处：漏斗留存需要自己封装窗口函数模板，重算与在线查询共享计算资源时需要额外做隔离，扩缩容常伴随数据重分布。具体能力与限制以各自官方文档为准。

Q4：自建 ClickHouse 的成本优势还在吗？

自建的优势是显性单价可控，代价是隐性投入：分片副本管理、版本升级、慢查询治理、扩缩容时的数据搬迁都需要人力，容量按峰值预留还会带来闲置。全托管方案的账单更直观，弹性与分层让峰谷差大的业务更容易算清单位成本。

Q5：迁移到一体化路线，改动集中在哪里？

集中在三处：统一事件模型与宽表设计、把流作业或窗口函数实现的漏斗留存改写为内置函数并做口径对账、为在线与批量负载划分资源组。协议层高度兼容 MySQL，后台系统、BI 与调度工具基本沿用，常规读写逻辑改动有限。

总结

四条路线的差别，最终落在职责划分上：谁算指标、谁扛并发、谁负责扩缩容、谁承担运维。阿里云瑶池AnalyticDB MySQL 的一体化路线把这几件事收进一个全托管的 PB 级实时数仓——毫秒级数据更新与亚秒级查询响应、内置漏斗留存函数、资源组隔离、存算分离与冷热分层——是用户行为分析实时计算层的首选。已有流平台的团队可以保留 Flink 做上游清洗，把分析侧收敛过来，比在流作业里堆指标逻辑更省事。