作者：张乃刚（花名：隽驰)，CCO数据开发

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类去重指标无奈准确计算。实质上指标值仍然是预计算，所以维度上再聚合时依然会呈现收缩，不能准确计算去重值。
  • 局部特色维度无奈反对。业务的洞察诉求越来越精密全面，交易特色、物流特色等一些属性以及快照类数据，在这个计划中难以反对，如订单的预售的类型、是否直播订单等。
  • 实时离线比照窗口难实现。实时指标有较强的多时段不同点位的窗口比照诉求，当遇到当天XX小时同环比历史同时段这类需要时，以后计划难以实现，预计算各种时长打点的历史数据也不事实。

阶段三：基于Hologres明细宽表的即席查问

为了能反对到更加丰盛的场景以及反对到实时离线联邦查问下灵便的窗口利用，咱们计划的思考方向转向为不再做指标的预计算，间接将明细数据写入到OLAP引擎，在数据集/数据服务等服务层间接关联DIM表即席查问。同样这对OLAP引擎的性能要求极高，CCO在去年实时架构降级之后，参见CCO x Hologres：实时数仓高可用架构再次降级，双11大规模落地，借助Hologres列存弱小的OLAP能力及实时离线联邦查问能力使该计划落地变为可能。

没有最好的计划，只有在对应场景下做出取舍后绝对实用的计划。在这个阶段，咱们就义了肯定的查问性能，抉择了对场景反对更丰盛、实时离线联邦查问以及扩大灵便度更反对更佳的计划。当然在淘系这类较大数据量的业务场景中，咱们也做了肯定的优化和取舍。如在理论解决中，对于绝对稳固的维度咱们在MaxCompute/Flink解决写入了明细，只对于行业类目等这类易调整且绝对敏感的维度间接在数据集/数据服务关联查问。

三种计划比照：

场景计划一：预聚合计划二：轻度汇总计划三：明细即席查问
查问性能（较大数据量）较好个别个别
维度反对反对丰盛但数据量易爆炸反对范畴固定维度反对丰盛
扩展性较差好较好
去重计算存在收缩存在收缩可准确计算
实时离线联邦查问窗口比照不反对不反对灵便反对
行业回刷须要回刷无需回刷无需回刷

Hologres+FBI一体化体验洞察数据实际

联合CCO体验业务在数据洞察利用场景中数据量大、周期长、链路范围广、维度特色多、实时离线比照窗口及快照特色诉求多等需要特点，咱们利用Hologres+FBI的各种个性一直在实践中设计优化整体的解决方案。从数据利用诉求来说，用户能够承受肯定工夫的返回提早，波及较大数据量读写但同时查问QPS较低，因此咱们抉择就义肯定的查问RT，抉择应用基于Hologres明细的即席查问的计划，整体流批两条链路构造如下：

如上所示，整体的计划是绝对典型的Lambda构造：

  • 在实时的链路中，咱们读取各主题的实时公共层Holo Binlog或者TT/MQ音讯，利用Flink的流解决能力，通过查问长久化存储的Hologres维表补齐模型所需的字段，同时通过事件触发的音讯，查问维表/HSF接口实现状态快照的采集，构建成ADS/MDS明细宽表，写入到Hologres分区表的当日实时分区。
  • 在离线的链路中，咱们读取各主题的公共层及维表，以及T日实时采集的快照信息，在T+1日构建离线的ADS/MDS明细宽表，通过MaxCompute表面形式Batch写入到Hologres表的各历史分区。为了保障T日分区在T+1日的无感切换，咱们会通过两头表rename的形式保障霎时切换。
  • 在上游利用时通过搭建FBI数据集或数据服务，提供查问Hologres明细表的即席查问能力，反对多维穿插剖析、大数据量下的去重计算、实时离线联邦查问等OLAP场景。

以下为咱们针对下面提到的前阶段数据应用存在的各种问题，在实际利用中的一些具体的技术计划。

表设计、 Table Group 及索引抉择

  • 表设计

次要查问场景是基于明细按工夫范畴的OLAP查问，数据规模单日分区超数十亿，同时也须要按天更新回刷数据，所以Hologres表的属性抉择上，是列存+业务主键PK+日期分区表。

  • Table Group设置

Table Group的设置个别依据应用场景、数据量大小、Join频次综合思考。须要关联的表放入同一个Table Group，通过Local Join缩小数据的Shuffle，可极大晋升查问效率。

Shard Count依据数据量抉择适合的大小。Shard数过小数据的读写会存在瓶颈，而Shard数过大会导致日常固定的开销以及查问启动的开销增大造成节约，大量的Shard数过大的表同时启动查问也容易给集群的负载造成压力，影响使用性能。目前体验洞察实际中，日增量亿级的交易类明细后果Shard Count设置为128，退款、征询求助等日增量千万左右的明细表Shard Count设置为32。

  • 索引设置

Hologres提供了Distribution Key、Clustering Key、Segment Key、Bitmap Columns等一系列的索引形式对表进行优化，正当的应用各类索引，能够大幅晋升使用性能。散布建Distribution Key只能是PK或PK的局部字段，抉择基于PK来设定；对于商家、类目、行业等常常用在Filter和Range场景的字段，咱们对应的设置了聚簇索引Clustering Key。而对于大量的二分类的维度特色以及枚举较少的字段，如是否直播订单、商家分层等，咱们对应设置了位图索引Bitmap Columns等。

BEGIN;CREATE TABLE "public"."ads_case_di" ( "date_id" TEXT NOT NULL, "case_id" INT8 NOT NULL, "industry_name"  TEXT NOT NULL,  "seller_id"    INT8 NOT NULL, "seller_nick"  INT8 NOT NULL, "is_presale_order" TEXT, "is_live_order"    TEXT,  XXX , PRIMARY KEY ("date_id","case_id"))PARTITION BY LIST (date_id);CALL SET_TABLE_PROPERTY('"public"."ads_case_di"', 'orientation', 'column');CALL SET_TABLE_PROPERTY('"public"."ads_case_di"', 'segment_key', '"date_id"');CALL SET_TABLE_PROPERTY('"public"."ads_case_di"', 'clustering_key', '"industry_name","seller_nick"');CALL SET_TABLE_PROPERTY('"public"."ads_case_di"', 'bitmap_columns','"is_presale_order","is_live_order"');CALL SET_TABLE_PROPERTY('"public"."ads_case_di"', 'dictionary_encoding_columns', '"industry_name","seller_nick","is_presale_order","is_live_order"');CALL SET_TABLE_PROPERTY('"public"."ads_case_di"', 'time_to_live_in_seconds', '17280000');COMMIT;

T+1分区笼罩计划

在Flink作业定义Hologres Sink表时，须要配置partitionRouter和createPartTable参数来保障流作业数据Sink到实时的分区以及在路由不到分区时主动创立分区。

partitionRouter = 'true' createPartTable = 'true'

Holo的分区表是子母表构造，子表的当日分区作为流作业的Sink表，T+1及之前的分区为离线工作Batch写入，在每天上午离线任务调度完结数据生成后笼罩实时作业写入的数据。而在T+1的离线数据写入的时候，如何防止写入时呈现空分区或者查问抖动，目前的计划是批写入长期子表而后rename并挂载到母表，能够霎时实现T+1分区的数据切换，防止影响利用端应用体验。以下以某个示意例。

BEGIN;--线上表分区子表，如果不存在分区，就创立该分区create table if not exists ads_tb_di_${bizdate} partition of ads_tb_di  for values in ('${bizdate}');--批数据写入的两头表子表create table if not exists ads_tb_di_batch_${bizdate} partition of ads_tb_di_batch  for values in ('${bizdate}');  --解除线上表依赖关系ALTER TABLE ads_tb_di DETACH PARTITION ads_tb_di_${bizdate};--解除两头表依赖关系ALTER TABLE ads_tb_di_batch DETACH PARTITION ads_tb_di_batch_${bizdate};--名称调换ALTER TABLE ads_tb_di_${bizdate} RENAME to ads_tb_di_temp_${bizdate};ALTER TABLE ads_tb_di_batch_${bizdate} RENAME to ads_tb_di_${bizdate};--挂依赖ALTER TABLE ads_tb_di ATTACH PARTITION ads_tb_di_${bizdate} FOR VALUES in ('${bizdate}');--删除长期批表drop TABLE ads_tb_di_temp_${bizdate};commit;

FBI的Velocity语法和Fax函数裁剪SQL优化查问

在BI的应用上，咱们抉择FBI（阿里团体外部的一款BI剖析产品）。目前FBI一个组件只反对一个数据集，为了反对多维穿插剖析利用，咱们比拟常见的计划是在数据集SQL中将所有可能用到的表拼接起来以备查问。但理论的即席查问场景中，用户抉择的指标和维度可能只应用到了数据集中的局部表，如果全量查问数据集，会造成节约同时也会影响查问性能。

联合FBI的 Velocity语法和Fax函数等个性配置动静查问能够实现依据用户的抉择动静路由裁剪，在数据集中如下应用Velocity语法增加判断语句，在扩大指标中配置动静查问的参数。这里的${tableindexorder} == 'order' 代表交易明细表，数据量较大。

在理论的即席查问场景中，如用户只抉择了“纠纷染指率”这类指标和维度，和交易数据没有关系，那么最终执行的query将不会命中${tableindexorder} == 'order' 这个分支下的SQL，借此实现对数据集SQL的裁剪，从而防止了每次查问都全量执行整体数据集，能够依据理论应用场景依照“不应用则不查问”的准则晋升查问效率。

实时离线联邦查问灵便窗口比照

大促场景下实时离线联邦查问的诉求非常常见，尤其以后工夫点位同环比历史同期时段点位这类比照需要，目前基于明细宽表的即席查问架构更加灵便高效。首先离线局部无需再进行预计算，尤其如果比照点位比拟细的话，如5分钟、10分钟这类窗口点位的比照，那离线须要预计算筹备的数据较为简单，数据量也非常大。另外对于流动当天退款量、退款金额的累计趋势这类很惯例的诉求的实现，也不再须要通过Flink计算每个点位的数值，再通过窗口函数进行聚合。间接对要害工夫字段减少打点字段，一个简略的窗口函数即可实现累计趋势图的绘制。比方以下为一个10分钟窗口累计趋势的示例：

select  date_id        ,create_time_10min ---10分钟向后打点        ,rfd_cnt --以后工夫窗口退款量        ,rfd_amt --以后工夫窗口退款金额        ,sum(rfd_cnt) over(partition by date_id order by create_time_10min asc) as total_rfd_cnt --累计退款量        ,sum(rfd_amt) over(partition by date_id order by create_time_10min asc) as total_rfd_amt---累计退款金额from    (            select  date_id                    ,create_time_10min                    ,count(*) rfd_cnt                    ,sum(refund_real_amt) as rfd_amt            from    ads_tb_di            where   date_id in ('20201111','20211111') --大促当天和历史同比            group by date_id                     ,create_time_10min        ) t;--create_time_10min 这里是对退款发动工夫的打点字段，等同于replace(substr(FROM_UNIXTIME(UNIX_TIMESTAMP(case_create_time) - (UNIX_TIMESTAMP(case_create_time)% (10 * 60)) + (10 * 60)),12,5),':','')

Hologres动静分区回刷

因为采纳了Hologres分区表的设计形式，当遇到须要同时回刷多个历史分区的状况时，因为Hologres分区是子母表构造且不反对向母表Insert数据，这里实现动静回刷多分区这类场景绝对麻烦一些，Hologres以后不反对程序块脚本，个别须要通过python/perl等脚本来进行对分区子表的循环操作。在这里咱们采纳DataWorks的管制节点配置用以绝对简略的实现对Hologres分区表的动静回刷。

UV类去重计算优化

在体验洞察的场景里，有着大量的去重计算的诉求，比方征询万笔订单求助量等这类指标，征询场景中会话量的计算大多是基于非主键列的计算，在目前这种基于明细的查问下，尽管防止了预计算后果集上聚合数据值收缩的状况，但大量的distinct操作极其影响性能。因此应答去重计算，在不同场景下咱们做了些不同的优化计划抉择。

  • 重要场景准确计算&长缓存周期

在首屏外围指标块这类重要的出现场景，比方万单求助量、小蜜发动量等重要观测指标的大数概览统计，因为指标的精确性要求，咱们会应用distinct去重计算，这类指标数量不多，也因为不波及下钻剖析只是概览统计，对于离线场景能够在FBI等展现端设置较长的缓存周期，查问命中缓存的概率较高，能够肯定水平的缩小distinct带来的性能影响。

  • 高频维度场景应用RoaringBitmap高效去重

对于行业、类目等这一类重要并且高频被应用到的的维度场景，并且这些维度对计算的精度也有着较高的诉求，为了保障去重计数查问的性能，咱们利用Hologres的RoaringBitmap的数据压缩和去重个性在较大数据量下进行计算。因为RoaringBitmap实质上还是做了一层预聚合计算，如果维度太多粒度太细数据量也会收缩的比拟厉害，为了保障优化的成果，这里咱们选取局部重要维度，联合前文提到的FBI Velocity语法判断，当查问的维度命中在RoaringBitmap根底聚合的维度范畴时，通过RoaringBitmap疾速返回后果。RoaringBitmap去重示例如下：

CREATE EXTENSION IF NOT EXISTS roaringbitmap; --创立roaringbitmap extention-----创立映射表，用以映射去重字段serv_id到32位int类型    BEGIN; CREATE TABLE public.serv_id_mapping (     serv_id text NOT NULL,     serv_id_int32 serial,     PRIMARY KEY (serv_id)  );CALL set_table_property('public.serv_id_mapping', 'clustering_key', 'serv_id');CALL set_table_property('public.serv_id_mapping', 'distribution_key', 'serv_id');CALL set_table_property('public.serv_id_mapping', 'orientation', 'column');COMMIT;-----创立根底聚合后果表BEGIN;CREATE TABLE ads_tb_roaringbitmap_agg (    date_id text NOT NULL,  --日期字段    bu_type text,    industry_name text,    cate_level1_name text,    cate_level2_name text,     cate_level3_name text,     uid32_bitmap roaringbitmap, -- 去重计算结果计算  primary key(bu_type, industry_name,cate_level1_name,cate_level2_name, cate_level3_name, date_id)--查问维度和工夫作为主键，避免反复插入数据);CALL set_table_property('public.ads_tb_roaringbitmap_agg', 'orientation', 'column');CALL set_table_property('public.ads_tb_roaringbitmap_agg', 'clustering_key', 'date_id');CALL set_table_property('public.ads_tb_roaringbitmap_agg', 'event_time_column', 'date_id');CALL set_table_property('public.ads_tb_roaringbitmap_agg', 'distribution_key', 'bu_type,industry_name,cate_level1_name,cate_level2_name,cate_level3_name');end;--------将映射表里没有的serv_id写入进去WITH     serv_ids AS ( SELECT serv_id  FROM ads_xxx_crm_serv_total_chl_di WHERE date_id = '${bizdate}' GROUP BY serv_id )    ,new_serv_ids AS ( SELECT a.serv_id  FROM serv_ids a LEFT JOIN serv_id_mapping b ON (a.serv_id = b.serv_id) WHERE b.serv_id IS NULL )INSERT INTO serv_id_mapping SELECT  serv_idFROM    new_serv_ids;------依照聚合条件聚合后插入roaringbitmap聚合后果表WITH    aggregation_src AS( SELECT date_id,bu_type, industry_name,cate_level1_name,cate_level2_name, cate_level3_name, serv_id_int32 FROM ads_xxx_crm_serv_total_chl_di a INNER JOIN serv_id_mapping b ON a.serv_id = b.serv_id WHERE a.date_id = '${bizdate}' )INSERT INTO ads_tb_roaringbitmap_agg SELECT   date_id        ,bu_type        , industry_name        ,cate_level1_name        ,cate_level2_name        ,cate_level3_name        ,RB_BUILD_AGG(serv_id_int32)FROM    aggregation_srcwhere cate_level3_name is not null and   bu_type is not null GROUP BY date_id         ,bu_type        , industry_name        ,cate_level1_name        ,cate_level2_name        ,cate_level3_name;-------执行查问，RB_CARDINALITY 和 RB_OR_AGG 聚合计算SELECT  bu_type        , industry_name        ,cate_level1_name        ,cate_level2_name        ,cate_level3_name        ,RB_CARDINALITY(RB_OR_AGG(serv_id32_bitmap)) AS serv_cnt ---去重计算结果字段FROM    ads_tb_roaringbitmap_aggWHERE   date_id = '${bizdate}'GROUP BY bu_type        , industry_name        ,cate_level1_name        ,cate_level2_name        ,cate_level3_name;
  • 多维穿插剖析应用近似计算

而对于大多数维度场景，对去重并不是要求100%准确，应用Hologres本身的APPROX_COUNT_DISTINCT近似计算，去重精度误差可达1%以内，在可承受范畴内且不会大幅影响查问性能。同时可如下通过调整精度参数来管制计算的精确度，但也会相应的减少计算开销，实测默认参数值17就能够达到较好的去重精度。

set hg_experimental_approx_count_distinct_precision = 20;

同时Hologres 1.3版本也反对了UNIQ函数，跟count distinct是一样的语义，然而计算效率更高，更节俭内存，后续咱们将会应用。

快照采集及长久化离线存储

前文提到了CCO侧体验洞察剖析存在大量的快照类特色诉求，比方用户征询时刻的货物状态、物流节点等，这类快照对剖析用户求助、退款时候的实在的境况和诉求及其重要。而这类快照在各类零碎中不太可能都有业务埋点，因而须要数据侧去加工失去对应的数据。这类快照数据如果通过批工作解决存在的次要问题是无奈精准的获取快照状态，比方征询时的物流节点，通过离线ETL解决须要比对征询工夫和物流各节点的工夫卡先后顺序得出过后的节点状态，对节点的枚举是否全面要求极高，并且解决复杂程度也较高。

因而，通过实时的音讯联合实时更新的长久化存储的维表或线上接口来生成快照类数据是较为适合的计划，以征询时订单状态的实现为例，咱们接入征询创立的TT/MQ，产生征询之后去查问对应订单维表或者TC接口，返回的数据写入当天的实时分区，在T+1日咱们通过Hologres的表面导出的性能，将T日实时写入的这类快照状态字段从Hologres导出到MaxCompute做长久化离线存储，在批工作的链路里离线分区的快照类字段可JOIN这份数据产出，同时也能够用以后续的数据回刷、业务洞察剖析。

--回写至MaxComputeINSERT INTO ads_holo_imp_di_foreign --表面，映射ODPS表ads_xxx_holo_imp_di        (            date_id                         ,serv_id           ,xxx        )SELECT   date_id                        ,serv_id            ,xxxFROM ads_total_chl_diWHERE date_id= '${bizdate}';

业务成果

一体化体验洞察于本年初上线，目前次要反对在淘系退款、征询万求等场景的实时多维穿插剖析、智能异样检测，月均50亿+数据量级下的聚合查问根本均能在秒级返回，反对到100+业务小二大促、日常的体验经营洞察剖析，助力业务小二单次洞察剖析提效10倍以上。

双11大促期间（11.1-11.20），一体化洞察提交执行的Query数为66w+，假如50%的Query为无效查问，同样依照每个Query小二过来均匀须要投入10分钟进行编写、执行、查看等操作来计算，共计节俭了6875人日，当然如果没有对应的数据/产品能力，小二受限于SQL技能以及开发成本也不会产生这么多查问，但也侧面反映了一体化洞察对小二们工作效率的无力晋升。

将来方向和思考

流批一体化

因为目前上游依赖的中间层离线和实时模型还不能齐全对立，整体的数据架构还是比拟传统的Lambda架构，须要保护离线、实时两套工作，开发、工作运维的老本较高，并且实时、离线数据存在肯定的差别。当然从一套代码实现原先流批两条链路的的角度来说，目前基于Hologres的架构下存储对立、计算对立的前提都是具备的，后续咱们次要推动DWD中间层的模型对立，实现一体化体验洞察整体数据架构流批一体。

数据集服务治理

为了整体疾速上线，目前仍有大量的FBI数据集直连Hologres库而非托管在数据服务平台。因此数据集的监控、压测、慢查问的预警优化等没法依靠数据服务平台的能力纳入对立治理，为了保障数据的稳定性、高可用性，后续须要将体验洞察的所有数据集依靠服务平台集中管控。