有口碑的做网站,中国作风建设门户网站,做网站用什么电脑好,快3网站制作 优帮云CCO是Chief Customer Officer的缩写#xff0c;也是阿里巴巴集团客户体验事业部的简称。随着业务的多元化发展以及行业竞争的深入#xff0c;用户体验问题越来越受到关注。CCO体验业务运营小二日常会大量投入在体验洞察分析中#xff0c;旨在通过用户的声音数据结合交易、物…CCO是Chief Customer Officer的缩写也是阿里巴巴集团客户体验事业部的简称。随着业务的多元化发展以及行业竞争的深入用户体验问题越来越受到关注。CCO体验业务运营小二日常会大量投入在体验洞察分析中旨在通过用户的声音数据结合交易、物流、退款等业务数据洞察发现消费者/商家体验链路上的卡点问题并推进优化带给消费者和商家更好服务体验。
以今年3月为例通过统计日志数据发现共有80业务同学提交了22000个Query都是围绕着用户心声和业务数据的多维度交叉分析如果按照每个Query小二平均投入10分钟进行编写、执行、检查等操作来计算的话共计投入458工作日也就意味着这80业务同学人均每个月至少有1周的时间全部投入在数据处理、运行上。业务侧大量的洞察分析诉求也使得体验洞察的数字化和智能化能力建设势在必行我们需要有能支持到业务复杂场景Ad-hoc查询的数据能力和产品能力。
通过对数据产品的不断迭代我们采用HologresFBI支撑CCO体验小二所有数据探索需求月均50亿明细数据聚合查询秒级返回支持100业务小二大促、日常的体验运营洞察分析助力业务小二单次洞察分析提效10倍以上解放业务同学的生产力。在文本中我们也将会介绍CCO数据洞察产品基于Hologres在BI查询场景的最佳实践。
体验洞察各阶段方案演变
结合业务我们梳理了当前CCO体验洞察数据应用的几个特点
数据覆盖场景广。覆盖了从用户浏览、下单、支付、发货物流到售后退款等全链路的业务场景数据涉及范围广。数据量较大。如交易类数据亿级/日、退款类数据千万级/日。实时时效以及多时间窗口对比诉求。如大促活动期间实时对用户Top求助场景是否异常的判断涉及多种窗口环比、同比、历史同时段、活动期同时段等对比来进行影响面评估和预警布防。数据监控周期长。如大促期间的售后情况洞察因为售后期较长往往会锁定大促周期的订单观察后续N天的退款、纠纷数据变化。数据需刷新的周期长。大量的快照类特征诉求。如分析用户咨询时刻的交易状态、物流状态等特征分布用以分析用户求助的真实诉求。
因此在整体数据方案落地的过程中如何快速响应业务不断变化的需求同时考虑业务上的数据特点选择相对稳定且高可用的方案是我们需要面对的问题。这里主要经历了三个阶段。
阶段一预计算聚合CubeMOLAPADB加速查询
这个阶段还未支持实时的洞察能力采用的方式是比较常规的预计算聚合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处理写入了明细只对于行业类目等这类易调整且相对敏感的维度直接在数据集/数据服务关联查询。
三种方案对比
场景方案一预聚合方案二轻度汇总方案三明细即席查询查询性能较大数据量较好一般一般维度支持支持丰富但数据量易爆炸支持范围固定维度支持丰富扩展性较差好较好去重计算存在膨胀存在膨胀可精确计算实时离线联邦查询窗口对比不支持不支持灵活支持行业回刷需要回刷无需回刷无需回刷
HologresFBI一体化体验洞察数据实践
结合CCO体验业务在数据洞察应用场景中数据量大、周期长、链路范围广、维度特征多、实时离线对比窗口及快照特征诉求多等需求特点我们利用HologresFBI的各种特性不断在实践中设计优化整体的解决方案。从数据应用诉求来说用户可以接受一定时间的返回延迟涉及较大数据量读写但同时查询QPS较低因而我们选择牺牲一定的查询RT选择使用基于Hologres明细的即席查询的方案整体流批两条链路结构如下 如上所示整体的方案是相对典型的Lambda结构
在实时的链路中我们读取各主题的实时公共层Holo Binlog或者TT/MQ消息利用Flink的流处理能力通过查询持久化存储的Hologres维表补齐模型所需的字段同时通过事件触发的消息查询维表/HSF接口完成状态快照的采集构建成ADS/MDS明细宽表写入到Hologres分区表的当日实时分区。在离线的链路中我们读取各主题的公共层及维表以及T日实时采集的快照信息在T1日构建离线的ADS/MDS明细宽表通过MaxCompute外表方式Batch写入到Hologres表的各历史分区。为了保证T日分区在T1日的无感切换我们会通过中间表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;
T1分区覆盖方案
在Flink作业定义Hologres Sink表时需要配置partitionRouter和createPartTable参数来保证流作业数据Sink到实时的分区以及在路由不到分区时自动创建分区。
partitionRouter true
createPartTable true
Holo的分区表是子母表结构子表的当日分区作为流作业的Sink表T1及之前的分区为离线任务Batch写入在每天上午离线任务调度结束数据生成后覆盖实时作业写入的数据。而在T1的离线数据写入的时候如何避免写入时出现空分区或者查询抖动目前的方案是批写入临时子表然后rename并挂载到母表可以瞬间完成T1分区的数据切换避免影响应用端使用体验。以下以某个表示例。
BEGIN;
--线上表分区子表如果不存在分区就创建该分区
create table if not exists ads_tb_di_${bizdate} partition of ads_tb_difor values in (${bizdate});
--批数据写入的中间表子表
create table if not exists ads_tb_di_batch_${bizdate} partition of ads_tb_di_batchfor 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_amtfrom ads_tb_diwhere 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写入进去
WITHserv_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聚合结果表
WITHaggregation_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接口返回的数据写入当天的实时分区在T1日我们通过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库而非托管在数据服务平台。因而数据集的监控、压测、慢查询的预警优化等没法依托数据服务平台的能力纳入统一管理为了保障数据的稳定性、高可用性后续需要将体验洞察的所有数据集依托服务平台集中管控。
作者张乃刚花名隽驰)CCO数据开发
原文链接
本文为阿里云原创内容未经允许不得转载。
