关于后端:阿里CCO基于Hologres的亿级明细BI探索分析实践

作者：张乃刚（花名：隽驰)，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_id
FROM    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_src
where 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_agg
WHERE   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 这份数据产出，同时也能够用以后续的数据回刷、业务洞察剖析。

-- 回写至 MaxCompute
INSERT INTO ads_holo_imp_di_foreign -- 表面，映射 ODPS 表 ads_xxx_holo_imp_di
        ( 
           date_id               
          ,serv_id 
          ,xxx
        )
SELECT   date_id               
         ,serv_id   
         ,xxx
FROM ads_total_chl_di
WHERE date_id= '${bizdate}';

业务成果

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

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

将来方向和思考

流批一体化

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

数据集服务治理

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