阿里CCO：基于 Hologres 的亿级明细 BI 探索分析实践

CCO是Chief Customer Officer的缩写，也是阿里巴巴集团客户体验事业部的简称。随着业务的多元化发展以及行业竞争的深入，用户体验问题越来越受到关注。CCO体验业务运营小二日常会大量投入在体验洞察分析中，旨在通过用户的声音数据结合交易、物流、退款等业务数据，洞察发现消费者/商家体验链路上的卡点问题并推进优化，带给消费者和商家更好服务体验。

以今年3月为例，通过统计日志数据发现，共有80+业务同学提交了22000+个Query，都是围绕着用户心声和业务数据的多维度交叉分析，如果按照每个Query小二平均投入10分钟进行编写、执行、检查等操作来计算的话，共计投入458工作日，也就意味着这80+业务同学人均每个月至少有1周的时间全部投入在数据处理、运行上。业务侧大量的洞察分析诉求也使得体验洞察的数字化和智能化能力建设势在必行，我们需要有能支持到业务复杂场景Ad-hoc查询的数据能力和产品能力。

通过对数据产品的不断迭代，我们采用Hologres+FBI支撑CCO体验小二所有数据探索需求，月均50亿+明细数据聚合查询秒级返回，支持100+业务小二大促、日常的体验运营洞察分析，助力业务小二单次洞察分析提效10倍以上，解放业务同学的生产力。在文本中，我们也将会介绍CCO数据洞察产品基于Hologres在BI查询场景的最佳实践。

体验洞察各阶段方案演变

结合业务，我们梳理了当前CCO体验洞察数据应用的几个特点：

• 数据覆盖场景广。覆盖了从用户浏览、下单、支付、发货物流到售后退款等全链路的业务场景，数据涉及范围广。
• 数据量较大。如交易类数据（亿级/日）、退款类数据（千万级/日）。
• 实时时效以及多时间窗口对比诉求。如大促活动期间实时对用户Top求助场景是否异常的判断，涉及多种窗口（环比、同比、历史同时段、活动期同时段等）对比，来进行影响面评估和预警布防。
• 数据监控周期长。如大促期间的售后情况洞察，因为售后期较长，往往会锁定大促周期的订单，观察后续N天的退款、纠纷数据变化。数据需刷新的周期长。
• 大量的快照类特征诉求。如分析用户咨询时刻的交易状态、物流状态等特征分布，用以分析用户求助的真实诉求。

因此在整体数据方案落地的过程中，如何快速响应业务不断变化的需求，同时考虑业务上的数据特点，选择相对稳定且高可用的方案是我们需要面对的问题。这里主要经历了三个阶段。

阶段一：预计算聚合Cube（MOLAP）+ADB加速查询

这个阶段还未支持实时的洞察能力，采用的方式是比较常规的预计算聚合Cube结果集，即在MaxCompute侧将所需要的交叉维度指标预计算好，形成一个ADS层的聚合指标结果宽表，通过外表或者DataX工具将聚合结果写入到OLAP引擎加速查询。此阶段CCO较为主流的OLAP引擎选型主要是ADB、MySQL等。这种方案在应对较少且相对稳定的维度和指标组合时较为适用，因为结果已经预计算好，只需要针对结果表进行简单聚合计算，ADB也提供了稳定的查询加速能力。以下为整体数据链路结构的简单示意图：

但是随着业务场景的更加复杂化，存在的问题也极为明显：

• 灵活度差，扩展成本高。当业务上要增加新维度或指标时，需要在MaxCompute应用层多层添加逻辑、修改表结构并且需要回刷数据，数据的扩展成本十分高。
• 数据量易爆炸。因为预计算的结果集最细粒度是所有维度的枚举值交叉，只要某几个维度枚举值比较多的话，交叉后的数据量就会存在大幅膨胀的可能，甚至膨胀到交叉后远大于明细数据量级的情况。
• 行业回刷成本高。因为维度特征预计算好的原因，类似淘系行业调整等较为常见的因素带来的回刷无法避免。每一次行业调整，为了保证行业的准确性，都会需要一次全量的回刷。
• UV类去重指标无法精确计算。遇到UV等需要去重计算的指标，因为预计算按照维度最细组合计算，再次聚合的时候不可避免会出现结果膨胀，无法精确的实现去重计算。
• 数据回流时间长。离线数据通过Shell脚本操作外表或者DataX同步任务方式回流ADB，在数据量较大的时候同步时间长，并且在回流高峰的时候，因为槽位资源打满，容易频繁出现任务超时、出错，甚至库抖动等问题，维护成本较高。

阶段二：实体ID轻度汇总事实表+维度表关联查询

这个阶段实时化洞察已经在很多场景有较强的诉求，故需要同时结合实时链路来考虑方案。方案一不适合实时链路的建设，主要在于预计算的多维汇总宽表难以确定PK，一旦维度组合发生变化，PK需要重新定义，无法稳定的支持upsert/update操作。

所以在这个阶段主要针对扩展性灵活性等问题重新设计了方案。主要的思路是不做维度的预计算，而是抽取洞察场景内事实表的实体对象ID，构建基于这些实体对象ID的轻度汇总DWS指标层，然后将DWS指标事实表和实体对象的DIM表直接写入到OLAP引擎，在数据服务或者FBI数据集这一层直接join查询。

以共享零售为例，业务的本质是买家下单，货从卖家流转到买方。这里的参与的对象有商品、商家、买家、骑手等，我们构建以商品ID+商家ID+买家ID+骑手ID的联合主键，计算在这个主键下的各业务模块的指标汇总事实表，然后利用OLAP引擎的强大的交互分析能力直接关联事实表和维表做多维分析查询。数据链路结构的简单示意图如下：

这种方案对比方案一解决了扩展性问题，提升了灵活度，维度的扩展只需要简单调整维表即可，遇上行业的调整甚至无需做任何处理；同时PK稳定，也能支持到实时upsert。但也因为数据展现端关联查询逻辑复杂，性能上对OLAP引擎要求较高。存在的问题可以总结为以下几点：

• 大数据量下性能较差。数据应用端大量的join操作，尤其PK不相同无法走Local Join，在数据量较大的场景如淘系业务里，性能难以支持。
• UV类去重指标无法精确计算。本质上指标值