关于大数据:菜鸟裹裹万能查小包裹数据的大革新

作者：哈九，菜鸟裹裹数据研发

无刃，菜鸟裹裹数据研发

夏招，菜鸟裹裹数据产品

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

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

一、菜鸟裹裹数据旧时代的迷雾

1. 冗余建设，数据口径等差别导致的数据不准

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

2. 数据开发周期长，妨碍倒退进度

\
晚期的数据产出经常以需要为导向，以疾速满足业务剖析为目标。因而之前合作模式，次要为业务提出取数需要，剖析现有数据看板是否反对，若无奈撑持则从新搭建，并未将数据产品化。疾速倒退的业务必然会衍生出新的剖析维度，目前固化的数据看板无奈疾速应答，同时也没有业务可自助查问数据的对立入口，数据分析进度与数据开发周期强绑定，从而导致业务经常不得不停下来等数据，对业务进度上造成了肯定的妨碍。

3. 查问速度慢，业务体验差

\
离线数据分析和业务看板目前存在两种惯例设计方案，如下图所示：

1. 用 FBI 等工具间接拜访 MaxCompute（原 ODPS）离线表，然而因为 ODPS 开发资源短缺和 MR 的解决架构导致数据访问速度绝对较慢，用户期待工作执行工夫往往超于数据分析自身；
2. 造成一个 adm 层的聚合指标后果宽表，通过表面或 DataX 工具将聚合后果写入 OLAP 引擎减速查问（利用 ADB 提供的稳固查问减速能力），但该计划数据需保护大量同步工作，且工作同步耗时较长。同时，该计划仅实用于较少且绝对稳固的维度和指标查问组合，只需对汇总层后果进行简略聚合计算。

二、新时代面临的挑战

1. 业务日益增长的数据须要和不均衡不充沛的数据服务倒退之间的矛盾

业务倒退处于高速倒退阶段，裹裹寄件经营模式在疾速试验疾速试错的过程中急需数据中台提供强有力的反对。个性化举荐、麻利剖析，大数据的利用在这个时代发明了很多千亿级别的景象级公司，可见于此业务倒退迅速收缩，若数据中台仍旧保留一对一的数据服务模式，服务速度将远远跟不上时代的后退脚步。目前迫切于找到应答指数级增长的数据需要的前途，打造一套一体化的数据产品，智能化、专业化、高效化的解决日常遇到的数据问题与需要，真正做到数据赋能，驱动寄件模式降级。

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

业务外围诉求是通过数据化产品疾速监控剖析，看清部分业务现状并作出决策，并不在乎如何取数。数据计算过程，易造成数据过于定制化、灵活性差、剖析维度不全面等问题。若后续呈现同类取数剖析需要，需减少新维度或指标时，数据同学需从新开发代替迭代，重启新看板模块，老本高、效率低、排期长，业务埋怨一直，与开始疾速响应业务疾速看数需要目标相悖。兼顾老本和体验，开释人力的同时保障业务同学可疾速自助获取数据，是一个火烧眉毛的问题。

三、迎难而上：Hologres 的抉择，万能查的诞生

1. 裹裹稳固的业务状态

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

2.Hologres 的弱小之处

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

• 反对高并发数据实时写入和实时查问，存储计算拆散可独立扩大；
• 底层数据架构对立，行存表反对高 QPS KV 点查问，列存表适应于 OLAP 剖析或 Adhoc 查问；同时反对负载隔离，对立数据拜访接口与安全策略；
• 联邦查问，反对盘古 2.0 文件间接读取；表面减速 Hologres 无缝对接 MaxCompute，反对内部表通明减速查问，反对 OSS 内部表读写；

3. 万能查产品构想

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

• 统一口径：协同 BI、多方业务梳理业务过程、整顿刻画业务状态的关键性指标、对立数据指标计算口径、及对外输入查问口径；
• 产品刻画：万能查为一套一体化多维度多场景的数据分析体系，疾速为经营决策、产品策略提供疾速无效的数据撑持。汰换之前的「报表」+「长期取数」的数据输入模式下，业务方可通过万能查无效地监控运力工作单据的生命周期，治理小件员运力流程，自主实现剖析论断、长期取数需要，缩小开发成本，进步经营效率。

四、万能查产品架构体系

1. 模块设计

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

2. 数据架构设计

• 数据能力矩阵，依据后期的需要调研，踊跃协调业务、BI 同学对裹裹寄件的剖析场景、产出逻辑、最终目标进行对立；收集整理刻画裹裹寄件业务过程的要害指标，构建数据指标矩阵

• 数据建模，实现外围指标需要收集和剖析后，划分数据域，分割多部门团队同学，确定数据中间层，并进行数仓模型评审

3. 数据模型设计

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

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

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');

2）动静分区回刷设计

因为采纳了 Hologres 分区表的设计形式，但在 ODPS 数据回流至 Hologres 时，Hologres 分区表无奈间接向父表插入数据，需顺次删除并重建分区子表，将数据插入分区子表中，实现分区父表动静更新数据，且以后不反对 python/shell 等脚本循环调度 Hologres SQL 实现数据回刷。实现 Hologres 的分区表动静分区式更新回流数据，即循环执行 Hologres 分区表脚本将数据回流至每一个分区子表。（理解到前期 holo1.3 版本上线，将反对动静分区治理，离线将反对动静写入，且可反对并行补数据。）

3）其它设计

Table Group 的设置个别依据数据规模、拜访个性、资源规格和应用重心（Join 频次）等综合思考。须要关联的表放入同一个 Table Group，通过 Local Join 缩小数据的 Shuffle，可极大晋升查问效率。肯定范畴内，Shard Count 能够进步数据写入和查问剖析解决的并行度。但大量的 Shard 数须要更多的节点间通信资源、计算资源以及内存资源撑持，从而导致资源节约。

目前，裹裹寄件轻度统计层数据，数据起源对立，表单分区个别在数千万行量级，个别做灵便多维度汇总，并发不高，且无需做多流 join。因而抉择默认 Shard Count 为 12，不做非凡批改。

4. 产品展现

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

五、高效的业务效力

1. 统一口径：万能查对立了数据指标计算口径、及对外输入查问口径，大幅度缩小不同报表数据对不齐、对不准等问题，预计下线 30+FBI 看板，且间接性达到对外传递数据撑持能力，反向积淀数据资产的成果。
2. 提高效率：万能查涵盖规模、客诉、服务质量、衰弱度考核、淘系逆向、用户等多维度多业务的数据，已可撑持业务日常的监控考核需要；同时，业务方可通过万能查多维度自由组合自行实现剖析论断需要、及 95%+ 长期取数需要，数据指标开发需要从原来的一周提 6 次升高位两周提 2 次，大幅缩小开发成本，进步经营效率，业务同学满意度 95%+。

• 爽约率案例：疾速监控网点爽约率稳定，精准剖析稳定起因，并疾速触达至城市经理；
• 疫情订单拦挡案例：针对突发疫情，业务方可疾速通过万能查明细查问异样包裹，将响应过程缩短至小时级别。

3. 降低成本：万能查数据产品上线以来，从新规整鸟查 FBI 数据看板，删减冗余看板近 30+；
4. 产品影响力：万能查已笼罩了裹裹整条业务线的外部用户，涵盖商家、运力、线上寄件、IOT、大 B 销售、客服、体验、业务产品技术等将近 15 个团队，周均 DAU200+，季度均 DAU1000+，已收到几十位业务同学的称心反馈。目前该产品模式已宽泛复用于其余菜鸟业务线。

六、将来方向和思考

1. 产品升级

目前经营决策、产品策略的成果剖析关联度剖析能力还比拟弱，能较大水平的满足业务方全局监控剖析的需要，但却无奈精细化感知指标数据的稳定以及产品变更与数据稳定的因果关系。对于数据变动的业务能力降级，将是产品接下来迭代的重点方向；

2. 时效降级

目前产品次要是基于离线数据设计，然而存在较多的实时数据查问需要，如疫情预警时，需依赖实时 / 小时数据取出截止以后时段的包裹明细。咱们后续能够读取 Hologres Binlog 或者 TT/MQ 音讯，利用 Flink 的流解决能力，通过查问长久化存储的 Hologres 维表补全模型字段，形成明细表，写入到 Hologres 分区的当日实时分区；并在 T + 1 日咱们通过 Hologres 的表面导出的性能，将 T 日实时写入的这类快照状态字段从 Hologres 导出到 ODPS 做长久化离线存储，充分利用 Hologres 资源。\

最初：\
菜鸟裹裹数据产品设计任重道远，Hologres 在数据产品上的利用范畴十分宽泛，万能查只是该数据引擎的探路者，两头碰到了各种各样的问题，包含模型设计、性能调优等，感激数据团队同学在数据技术和 Hologres 架构等方面的反对和帮忙，将来咱们也将会继续应用共建。