菜鸟寄件业务当前为菜鸟的基础设施建设业务，是用户与【菜鸟】品牌最直接最基本的认知联系。通过与三通一达等巨头快递公司合作，降本增效，数字化、智能化的推动了中国快递行业腾飞。在新的一年里，菜鸟裹裹更是【做物流行业数字化转型的引擎】这一菜鸟大愿景的践行者。目前裹裹寄件日常寄件订单量百万级别，且双十一等大促期间订单量更是成倍增长。
智能化履约过程及不断精益化的业务系统，菜鸟裹裹团队急需一套一体化的数据产品，能够智能化、专业化、高效化的解决日常遇到的数据问题与需求，并在日常的数据监控与效果分析的过程中，用数据影响业务决策。基于业务越来越频繁的数据需求及数据应用，我们使用Hologres构建万能查产品，一劳永逸的解决业务汹涌的需求与各种口径、降本增效等问题。

通过本文我们将会介绍菜鸟裹裹基于Hologres构建万能查产品的最佳实践。

1. 菜鸟裹裹数据旧时代的迷雾

1.1 冗余建设，数据口径等差异导致的数据不准

菜鸟1.png

菜鸟裹裹寄件业务发展至今，已经历过多轮的业务方向调整以及组织架构的变动，必然会存在极重的数据历史包袱。各类数据指标根据业务类型、运营模式的不同分散于不同的看板模块，效果分析关联度低；或同时多数据看板重复建设，类型过度细分，找数难，直接影响业务分析效率及体验感。此外，业务和BI所面对的分析场景、汇报对象、实际目标的不同，对于同一个指标可能存在多版本多角度的统计口径，易出现数据口径等细微差异导致的数据不准的情况，导致了数据同学日益繁重的“找茬”工作。若再不协同各方梳理指标口径，确定口径定义模式，统一底层数据，删减冗余看板，最后压死数据同学的将是任意一个不知名的“包裹”。

1.2 数据开发周期长，阻碍发展进度

菜鸟2.png
早期的数据产出常常以需求为导向，以快速满足业务分析为目的。因此之前协作模式，主要为业务提出取数需求，分析现有数据看板是否支持，若无法支撑则重新搭建，并未将数据产品化。快速发展的业务必然会衍生出新的分析维度，目前固化的数据看板无法快速应对，同时也没有业务可自助查询数据的统一入口，数据分析进度与数据开发周期强绑定，从而导致业务常常不得不停下来等数据，对业务进度上造成了一定的阻碍。

1.3 查询速度慢，业务体验差

菜鸟3.png
离线数据分析和业务看板目前存在两种常规设计方案，如下图所示：

用FBI等工具直接访问MaxCompute（原ODPS）离线表，但是由于ODPS开发资源短缺和MR的处理架构导致数据访问速度相对较慢，用户等待任务执行时间往往超于数据分析本身；
形成一个adm层的聚合指标结果宽表，通过外表或DataX工具将聚合结果写入OLAP引擎加速查询（利用ADB提供的稳定查询加速能力），但该方案数据需维护大量同步任务，且任务同步耗时较长。同时，该方案仅适用于较少且相对稳定的维度和指标查询组合，只需对汇总层结果进行简单聚合计算。

菜鸟4.png

2. 新时代面临的挑战

2.1 业务日益增长的数据需要和不平衡不充分的数据服务发展之间的矛盾

业务发展处于高速发展阶段，裹裹寄件运营模式在快速试验快速试错的过程中急需数据中台提供强有力的支持。个性化推荐、敏捷分析，大数据的应用在这个时代创造了很多千亿级别的现象级公司，可见于此业务发展迅速膨胀，若数据中台依旧保留一对一的数据服务模式，服务速度将远远跟不上时代的前进脚步。目前迫切于找到应对指数级增长的数据需求的出路，打造一套一体化的数据产品，智能化、专业化、高效化的解决日常遇到的数据问题与需求，真正做到数据赋能，驱动寄件模式升级。

2.2 在降本增效大背景下的人效匹配问题

业务核心诉求是通过数据化产品快速监控分析，看清局部业务现状并作出决策，并不在乎如何取数。数据计算过程，易造成数据过于定制化、灵活性差、分析维度不全面等问题。若后续出现同类取数分析需求，需增加新维度或指标时，数据同学需重新开发代替迭代，重启新看板模块，成本高、效率低、排期长，业务抱怨不断，与开始快速响应业务快速看数需求目的相悖。兼顾成本和体验，释放人力的同时保证业务同学可快速自助获取数据，是一个迫在眉睫的问题。

菜鸟5.png

3. 迎难而上：Hologres的选择，万能查的诞生

3.1 裹裹稳定的业务形态

目前裹裹寄件日常寄件订单量百万级别，且双十一等大促期间订单量更是成倍增长，其主要业务模式为收到各端寄件的需求（信息流），然后将寄件需求单分发给合作的快递公司网点及小件员（三通一达），小件员在包裹侠上接单/消费者到站寄件；包裹揽收后消费者完成运费支付，快递交付于第三方物流完成运输配送。

菜鸟6.png

3.2 Hologres的强大之处

Hologres是一站式实时数据仓库引擎，支持海量数据实时写入、实时更新、实时分析，与MaxCompute、Flink、DataWorks深度融合，提供离在线一体化全栈数仓解决方案，广泛应用在实时数据中台建设、精细化分析、自助式分析、营销画像、人群圈选、实时风控等场景。HOLO的主要特性有：

支持高并发数据实时写入和实时查询，存储计算分离可独立扩展；
底层数据架构统一，行存表支持高QPS KV点查询，列存表适应于OLAP分析或Adhoc查询；同时支持负载隔离，统一数据访问接口与安全策略；
联邦查询，支持盘古2.0文件直接读取；外表加速Hologres无缝对接MaxCompute，支持外部表透明加速查询，支持OSS外部表读写；

3.3 万能查产品构想

通过目前现有的数据支撑能力，依赖Hologres引擎，将裹裹寄件常用且稳定的维度和指标封装于万能查中。用户可根据自己的需求筛选字段，定制化自己的报表，快速自助完成运营数据分析。基于一体化数据分析产品「万能查」，突破目前数据产品的壁垒，达到降低成本、提高效率、保证数据准确性、完成体验升级的目的。

统一口径：协同BI、多方业务梳理业务过程、整理刻画业务形态的关键性指标、统一数据指标计算口径、及对外输出查询口径；
产品刻画：万能查为一套一体化多维度多场景的数据分析体系，快速为运营决策、产品策略提供快速有效的数据支撑。汰换之前的「报表」+「临时取数」的数据输出模式下，业务方可通过万能查有效地监控运力任务单据的生命周期，管理小件员运力流程，自主完成分析结论、临时取数需求，减少开发成本，提高运营效率。

菜鸟7.png

4. 万能查产品架构体系

4.1 模块设计

产品需求设计过程中，会接受到不同的用户各种的个性化诉求。业务团队主要将运营过程划分为订单运营和用户运营，而不同的需求会有不同视角和粒度的看数诉求。另外，由于淘退订单的业务特殊性，需基于全局淘退订单进行分析，订单视角存在较大的区别。因此针对用户的个性化需求，以及实际业务场景，我们将万能查划分为三大模块：订单，用户，淘退，设计多款万能查产品。

菜鸟9.png

4.2 数据架构设计

数据能力矩阵，根据前期的需求调研，积极协调业务、BI同学对裹裹寄件的分析场景、产出逻辑、最终目标进行统一；收集整理刻画裹裹寄件业务过程的关键指标，构建数据指标矩阵

菜鸟10.png

数据建模，完成核心指标需求收集和分析后，划分数据域，联系多部门团队同学，确定数据中间层，并进行数仓模型评审

菜鸟11.png

4.3 数据模型设计

基于数据量大、周期长、链路范围广、维度特征多等业务需求特点，且结合Hologres存储费用高等问题。我们整体万能查设计结构如下：

在ODPS中读取各主题的公共层及维表，构建可扩展性较高的轻度汇总层。将查询频率较高的近一年数据通过内表的形式导入Hologres表的各历史分区，提高高速查询；
考虑到业务分析时使用跨年的数据进行同期比较分析，但分析频率并不高，因此选择牺牲速度提供外表的形式查询（外表最多支持512分区查询）。目前FBI一个组件只支持一个数据集，为保证用户的使用体验，我们利用试图的方式在Hologres中将内表以及外表进行合并，对外只透传视图。
基于轻度统计层的按时间范围的OLAP查询是主要的数据场景，存在大量聚合Group by等操作，因而Holo表的属性选择上，毫无疑问是列存+日期分区表。一方面对于日期（ds）设置为分区字段，可以有效缩小每次查询的扫描范围；另一方面也可以较安全的进行运维和排查问题。
具体结构如下：

菜鸟12.png

4.3.1 索引设计

Hologres提供了Distribution Key、Segment Key、Clustering Key、Bitmap Columns等一系列的索引方式对表进行优化，合理的使用各类索引，可以大幅提升使用性能。

基于裹裹寄件业务导入数据为轻度汇总无唯一主键且无自增/类自增字段的特性，不设置Distribution Key以及Segment_key，采用随机分发到shard的模式，其中，设计Segment_key索引中会存在一个误区，是指定具备递增逻辑列，区别于ds分区字段，同时设置分段列需排序后写入，才会生效。

此外，由于用户存在多种等值过滤查询场景，经过统计分析经常用在Filter和Range场景的字段，我们将使用次数相对较多的字段“业务子类”设置为聚簇索引Clustering Key，其余分析维度设置Bitmap，如揽件网点，运力类型，发货城市等信息。

CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d','orientation','column');CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d','clustering_key','send_sub_type');CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d','bitmap_columns','fac_id,fac_name',...);CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d','time_to_live_in_seconds','34560000');

4.3.2 动态分区回刷设计

由于采用了Hologres分区表的设计方式，但在ODPS数据回流至Hologres时，Hologres分区表无法直接向父表插入数据，需依次删除并重建分区子表，将数据插入分区子表中，实现分区父表动态更新数据，且当前不支持python/shell等脚本循环调度Hologres SQL实现数据回刷。实现Hologres的分区表动态分区式更新回流数据，即循环执行Hologres分区表脚本将数据回流至每一个分区子表。（了解到后期holo1.3版本上线，将支持动态分区管理，离线将支持动态写入，且可支持并行补数据。）

4.3.3 其它设计

Table Group的设置一般根据数据规模、访问特性、资源规格和使用重心（Join频次）等综合考虑。需要关联的表放入同一个Table Group，通过Local Join减少数据的Shuffle，可极大提升查询效率。一定范围内，Shard Count可以提高数据写入和查询分析处理的并行度。但大量的Shard数需要更多的节点间通信资源、计算资源以及内存资源支撑，从而导致资源浪费。

目前，裹裹寄件轻度统计层数据，数据来源统一，表单分区一般在数千万行量级，一般做灵活多维度汇总，并发不高，且无需做多流join。因此选择默认Shard Count为12，不做特殊修改。

4.3.4 产品展示

筛选所需指标维度，也可以在搜索框中输入你想要查找的字段。比如【及时回单率】【网点ID】点击确定，指标数据将会自动聚合，秒级返回；可在同一数据入口，查询分析包裹全链路的指标数据；
自主上传运单号或用户ID，快速分析用户复购率、订单流程进度等分析型数据需求；
定制化，选择指标结果及筛选项结果将会记录下来，在下次进入时仍然会记住这些选项，无需重复操作；

菜鸟13.png

5. 高效的业务效能

5.1 统一口径

万能查统一了数据指标计算口径、及对外输出查询口径，大幅度减少不同报表数据对不齐、对不准等问题，预计下线30+FBI看板，且间接性达到对外传递数据支撑能力，反向沉淀数据资产的效果。

5.2 提高效率

万能查涵盖规模、客诉、服务质量、健康度考核、淘系逆向、用户等多维度多业务的数据，已可支撑业务日常的监控考核需求；同时，业务方可通过万能查多维度自由组合自行完成分析结论需求、及95%+临时取数需求，数据指标开发需求从原来的一周提6次降低位两周提2次，大幅减少开发成本，提高运营效率，业务同学满意度95%+。

爽约率案例：快速监控网点爽约率波动，精准分析波动原因，并快速触达至城市经理；
疫情订单拦截案例：针对突发疫情，业务方可快速通过万能查明细查询异常包裹，将响应过程缩短至小时级别。

5.3 降低成本

万能查数据产品上线以来，重新规整鸟查FBI数据看板，删减冗余看板近30+；

5.4 产品影响力

万能查已覆盖了裹裹整条业务线的内部用户，涵盖商家、运力、线上寄件、IOT、大B销售、客服、体验、业务产品技术等将近15个团队，周均DAU200+，季度均DAU1000+，已收到几十位业务同学的满意反馈。目前该产品模式已广泛复用于其他菜鸟业务线。

6. 未来方向和思考

6.1 产品升级

目前运营决策、产品策略的效果分析关联度分析能力还比较弱，能较大程度的满足业务方全局监控分析的需求，但却无法精细化感知指标数据的波动以及产品变更与数据波动的因果关系。对于数据变化的业务能力升级，将是产品接下来迭代的重点方向；

6.2 时效升级

目前产品主要是基于离线数据设计，但是存在较多的实时数据查询需求，如疫情预警时，需依赖实时/小时数据取出截止当前时段的包裹明细。我们后续可以读取Hologres Binlog或者TT/MQ消息，利用Flink的流处理能力，通过查询持久化存储的Hologres维表补全模型字段，构成明细表，写入到Hologres分区的当日实时分区；并在T+1日我们通过Hologres的外表导出的功能，将T日实时写入的这类快照状态字段从Hologres导出到ODPS做持久化离线存储，充分利用Hologres资源。

最后：
菜鸟裹裹数据产品设计任重道远，Hologres在数据产品上的应用范围非常广泛，万能查只是该数据引擎的探路者，中间碰到了各种各样的问题，包括模型设计、性能调优等，感谢数据团队同学在数据技术和Hologres架构等方面的支持和帮助，未来我们也将会持续使用共建。

了解Hologres

合集.png