中通快递数据治理实践

物流的数据场景非常特殊，对数据质量的要求非常高，不仅要精准，更要及时、精确。所以物流领域是最早开启数据溯源的业务场景，也是最早开启公共查询信息的场景。

中通作为四通一达的一员，数据治理的经验非常值得参考。今天咱请中通快递的薛大侠为大家详细分享他们的数据治理经验。

01、中通业务分析

中通快递成立已经有将近 20  年时间，是一家以快递为主的大型综合物流服务企业。除了快递之外，还有国际、快运、云仓等等的一系列业务。根据今年二季度的数据来看，目前日均单量近 7000 万，市场份额已经达到了 23%，位居行业第一。

快递行业的主要业务流程包括收、发、到、派、签五个环节。用户下单后，快递小哥会上门收快件，再由网点统一把件交到转运中心。转运中心做分拣之后，再通过合理的路由把件转运到末端末中心，末中心再将件分配到网点，然后由快递小哥进行派件，最后由客户进行签收，这样一个流程基本就结束了。

02、数据治理驱动力&目标

随着物流行业也由传统行业向数字化、智能化新模式的转变，中通为了在激烈竞争的市场环境中保持领先的地位，也在积极地进行数字化转型，在这个过程中对数据的依赖程度会越来越高。

业务人员在日常使用数据过程中还是有一些痛点的，主要的表现：

第一，数据资产缺乏盘点。当前核心系统的主要数据已经采集到数据仓库，但是在日常的业务分析中经常需要向业务系统了解需要用到的数据在哪里。总得来看对数据资产还是缺乏整体盘点，公司主要有哪些数据，都分布在哪些系统中，哪些数据已经采集到数仓，哪些还没有入库，还有待进一步梳理。

第二，数据标准化建设不足。数据标准会贯穿数据管理的全流程，虽然我们制定了一系列规范文档、制度文档、流程文档等，但有了标准并不代表数据标准化已经落实了，像指标数据的标准化、主数据的标准化等方面还需要进一步的提升。

第三，数据质量问题。数据质量是数据的生命线，差的数据质量严重影响数据分析的结论，有的可能对决策产生误导，如脏数据、维度数据缺失或变更等一系列问题，都需要进行治理，比如扫描信息缺失，导致运单路由轨迹不准确；数据维度值变化，统计某个渠道业务量陡增或骤降。

第四，数据模型待完善。目前已经建设了一批公共宽表，但是随着业务发展，有些时候业务方需求比较急，开发直接从基础明细表取数，导致宽表复用度降低；为了追求开发效率，团队内部也存在烟囱式开发现象，导致一些 ST 层共有逻辑没有下沉。

除了上述问题，快递公司还会积累大量收件人、发件人的地址、姓名、电话等信息，这些信息都需要进行有效的管理。此外，国家也出台了《数据安全法》、《个人信息保护法》等法律法规，需要我们做好数据分级分类和对数据合规安全的访问，同时保障数据保密性、完整性和可用性。

数据治理的核心是希望把数据变为数据资产，让数据资产在数据驱动业务过程中发挥价值。最主要期望能够实现的目的是：

1. 提升数据质量

2. 解决数据孤岛问题，实现数据汇聚联接

3. 掌握数据资产现状

4. 保障数据安全合规

5. 逐渐释放业务价值，如在降本增效、提升客户满意度等方面发挥作用

根据物流行业的发展趋势以及公司数据化转型的要求，基于打造数字综合物流服务的战略规划，我们也建立了一套比较成熟的数据治理体系，主要包括战略、机制、专题和平台等等方面。

（1）机制层面

公司近年陆续组建了顺应数字化团队协作模式的组织架构，基于一把手工程思路，专门成立了数字化支撑团队，并在各业务部门设置专门的岗位，清晰明确了的各部门的数据管理责任; 同时为规范推行数字化工作开展，有章可循，我们IT部门组织各业务部门共同编写数据管理政策、制度、细则、手册共4个梯度的数据管理办法文档，目前正在推广执行中。

（2）专题方面

聚焦数据标准、质量、元数据管理、安全及生命周期等一共8个专项服务，全面提供数据支撑业务；在具体实施层面，我们会围绕“盘”、“规”、“治”、“用”四个方面展开。

盘：发现业务痛点，调研业务部门，梳理业务流程，分析数据问题，数据盘点，收集数据字典与数据规范；

规：定义数据标准，确认核心系统，定义数据模型，确定数据流向，制定数据质量规则

治：跨数据域的数据整合拉通，形成单一数据视图，进行数据质量检核，并对数据质量实时监控和预警；

用：为业务部门提供生产经营指标分析服务，提供数据快速检索与数据资产全景可视服务；

专题主要包括我们经常会提到的数据标准、数据质量、模型、主数据等八大块内容。

（3）平台层面

数据治理离不开平台的支撑， 公司也通过自研包括元数据、数据质量、大数据等平台等来支撑治理工作的展开。

数据治理工作需要组织架构来保证。在管理层面有数据治理委员会，数据管理办公室负责实际开展工作，主要负责标准规范的制定、协调某些需要升级的数据质量问题。接下来的执行层面有数据架构组、数据质量组等等，他们负责具体的治理工作。

03、数据治理实践

上边提到数据治理主要包括八大块内容，实际工作中每一块我们都有涉及。由于时间关系，重点挑其中三块：数据质量、模型、元数据做介绍。

1. 数据质量治理

数据质量是数据治理的核心，也是基础工作。数据质量通常会从及时性、真实性、唯一性、完整性、有效性、一致性等六个维度来衡量。

日常工作中涉及到数据质量的问题通常会有数据重复、波动值过大、异常值、操作不规范、数据未采集等。

举一个实际工作中遇到的运单扫描的例子。在收、发、到、派、签的整个环节，一般是要求都要业务人员都要扫描，但实际操作可能不规范导致某些扫描环节缺失，那就会导致运单的路由轨迹不准确，进而影响到数据分析。

种种数据质量问题会引起业务方对数据不信任、无法做出正确决策、不能精细化运营等问题，这就需要有一套数据质量解决方案。我们的方案包括四方面：

第一，数据质量问题发现。借助数据质量管理平台，对数据从入库到后续加工的整个链路进行监控，来发现业务系统、开发加工过程中的一系列问题。另外还需要通过下游使用数据的环节来发现一些深层次的数据质量问题，如通过业务专题分析来发现数据质量问题。之后再以业务驱动的方式推动数据质量问题的解决。

第二，评估分析。主要是分析问题产生的原因。在解决问题的时候不能仅停留在表象，需要分析问题产生的根本原因，从源头解决数据质量问题。当评估数据质量问题需不需要去解决时，还需要考虑治理成本和收益。

第三，数据质量问题的解决。数据质量问题通常来说会考虑从业务、技术、流程等方面去考虑推动解决。

第四，数据质量验收。即验证相关问题是否得到解决。

对于数据质量的监控，主要包括三个环节：

第一，结合数据质量衡量的六个维度及日常工作中发现的数据质量问题，配置相关规则。

第二，在数据加工的各个环节设置检查点，比如从 ODS 到 DW，从 DW 到 DM 等环节。如在 ODS 的检查点设置中，可能会包括数据源抽取记录的检查；在基础层会有空值、编码值、一致性、重复性等问题的检查 。

第三，输出异常结果，进行告警处理。

看一个具体的监控案例。当用数据质量监控平台对一张表进行监控时，我们可以选择配置相关规则，可以直接采用预置的规则模版，也可以自定义规则。也可以设置检查规则的属性，比如是强规则还是弱规则，此外对告警的属性也可以进行设置。规则配置完成以后在实际检测过程中，如果某个检测规则违反了强规则，则其会阻断下游任务的执行。

告警升级机制方面，强规则一般会提供电话告警。如果说由于疏忽或其他情况导致任务负责人未及时处理，那么会升级到leader来推进问题的解决。

告警信息是点对点，我们对告警信息会进行聚合，形成质量全貌信息。比如每天早上来上班，我就可以打开质量全貌信息，看一下当天执行了多少检查规则，有多少是有问题的。如果有问题可以继续分辨哪些是真有问题，哪些是没问题，有问题的是否已经解决。如果检查规则设置不合理，我们会进行优化，逐渐使得告警规则更准确，形成质量监控全面、准确的闭环。

还有一些深层次的数据质量问题可能通过我们常规的检查手段并不一定能发现，这时就需要借助下游数据使用来解决，一般我们会结合业务专题分析推动数据治理。在专题分析过程中，可能会发现种种数据质量问题，比如数据未线上化、数据采集不完整等，之后我们会针对具体问题制定有效措施，同业务方、业务系统的产品研发共同把问题解决。

以业务驱动方式推进数据质量建设取得了若干成果：

推动 100% 计费政策数据线上化，结算时效提升至 T-1

推动业务系统采集关键操作环节数据，支持更细粒度的业务分析

协调业务部门细化各类操作规范，操作数据质量进一步提升

完善业务系统功能

2. 数据模型治理

简要先介绍一些快递的业务特点。快递属于服务性行业，非常注重运营，最主要关注的是时效、服务、质量三方面。行业的情况会导致数据有如下特征：

数据生命周期比较长

核心运单流程生命周期短则 1 天，长则 3-5 天，异常单可能会更长。财务类周期结算长，涉及政策财经类数据计算回刷时间 1～3 个月；

业务流程复杂

运单核心流程从下单到签收涉及业务流程较为复杂及运单揽派签主流程外，还涉及结算、客服等额外流程；

对象多数据大

数据由不同业务对象如快递员、客服、分级员等多角色产生，非常依赖他们操作的规范性。另外，我们日均单量七千万，每一单都需要经过收发到派签的操作，数据量级可想而知；

数据精细化运营

当前快递行业竞争激烈，在此背景下更需要精细化运营，因此对数据依赖非常强。公司通过数据化运营进行成本管控，运单时效管控，服务质量管控，已成为公司日常运营常态，因此对数据准确性，时效性要求很高。

接下来介绍一下我们数仓的当前现状。首先，我们按照业务板块划分出运单、财经、客服等 27 个一级主题域。其次，核心数据集中在 DW 和 DM 层，为下游提供通用的公共服务。第三，当前我们是 PB 级数据规模，计算任务 1 万多，通过上千台集群的规模支撑了集团全领域业务线。

随着业务持续发展，项目也在快速迭代。数据建设不规范等方面的原因导致了复用性不高、时效不稳定等，自然而然也会引起资源危机等问题。

为此我们制定了一整套的方案，主要包括三方面：

第一，制定规范。制定诸如开发规范、分层使用规范，并严格要求各类数据开发和使用团队遵守；

第二，过程管控。以需求为驱动，将设计、开发、上线等数据建设各个阶段进行过程管控；

第三，模型分级。根据应用的重要程度来反推、梳理哪些是重要的模型和应用，将重要性高的模型和应用纳入重点治理范围，重点关注他们的复用性、实效性。

复用度治理方面，主要包括三块：

第一，流程规范的制定。我们会制定相关规范来要求数据参与者都遵守。通过制定规范，应用开发团队和数仓团队进行分工，且在业务需求评审环节要求数仓团队介入，可以更早地评估是否需要设计相关模型来支持应用团队的数据开发；

第二，过程线上管控。在数据使用、模型设计、任务上线等环节都进行线上管控，由leader审批把关；

第三，核心数据识别。最主要是识别出四类核心数据，最主要关注核心模型和核心应用，并对这类数据我们重点关注、重点保障，优先保障其核心链路上数据的准确性和及时性。

在数据复用度治理方面还需要关注时效、引用度、需求响应及时性之间的平衡问题。我们不能为了提高模型的复用度就任意的增加维度、指标，否则可能会导致下游应用产出障碍的问题。也不能说某个指标下游饮用不多就增加到宽表中来，一定要考虑平衡性的问题。

除此之外，我们还需要考虑响应的及时性。在流程上我们希望尽量做到规范，希望应用层都饮用模型、宽表的数据。在实际工作中，有时为了保证“业务需求第一”的原则，有可能允许应用层先从明细层取数进行开发，模型同步进行迭代优化，后续再让应用层把需求切换回来。

数据模型的治理也达成了一些成效，主要包括四个方面：

第一，研发效能更密集，核心领域宽表使用占比较高，数据研发时效比原来提效不少。

第二，数据口径更一致。

第三，资源整体可控。

第四，时效更加稳定，计算任务在 6 点前可以完成总体的 80%，关键任务完成100%。日常任务时效能达到业务期望。

3. 元数据治理

我们的数仓中有上万张表，无论是对数据开发者还是业务使用方，都会面临无从下手的情况。他们在日常使用过程中的痛点最主要可以归纳为有什么、在哪里、怎么用三类。

比如一个运单，有收件人、发件人、运载轨迹、费用等各种信息，但具体有哪些表就不是很清楚了。在实际的工作中，分析师也经常会问有没有哪块的数据，在哪里之类等等。哪怕是找到表之后，也会疑惑数据是如何加工的，如果要用的话有哪些限制条件等等问题。

基于对现状的梳理及现阶段要达成的目标，我们希望能实现数据表、报表、数据指标的联动解锁，所以最主要的就是梳理这三方面的信息。

数据表我们最关心的可能是主题、子主题、概要信息等。我们根据业务现状及未来发展趋势，对主题进行调整优化，细化了二级主题，然后对这些表分门别类地进行梳理。概要信息主要包括表的处理逻辑、重要字段等信息。

我们可能不仅仅只是梳理我们大数据产品的一些报表，也包含在业务系统中的各种报表。因为在日常中，经常会遇到业务同学问业务系统中的某个报表对应的后台表是哪个的问题，他们更希望可以把表拿过来后再加工，或者说做一些统计分析等等。

通过对这些报表的梳理，整理出系统、统计规则、主要用途、负责产品经理、对应数据表等等信息。

在指标信息梳理方面，也做了相关的信息梳理。

基于上述的梳理，我们可以依赖元数据应用平台按主题了解数据全貌。

也可以按表、报表、指标等对象对数据进行检索，并实现表、报表、指标的联动。如通过对某个表名的查询，可以得到概要信息、处理逻辑、重要字段的说明，大致了解这张表有什么用。且不光可以呈现业务元信息，还可以呈现一些技术元信息，如消耗的计算资源、存储资源、血缘关系等等。

除了上述信息，元数据应用还可以提供包括数据冷热度分析、任务治理等内容。

04、未来规划

关于未来的规划，主要分为三个方向。

第一，结合业务发展重点，持续开展数据质量治理，继续提升数据质量；

第二，基于元数据，从资源消耗、价值等方面实现数据资产价值评估；

第三，联动业务系统，开展数据架构治理，后续达到企业整体数据架构的统一。

05、问答环节

Q1：高管、运营同学关注的报表需要固定在早上几点之前产出，他们依赖于此作相关决策。像这种关键任务的达成过程中是否有遇到过比较严重的问题，可否分享一些踩坑实践？

A1：原因有几方面。一，之前资源没有分队列的时候，确实出现过资源争抢等情况导致关键任务出现延迟等情况，现在已通过将资源划分队列来解决。二，数据引擎对实效性的影响。通过从原来的 Hive 慢慢将任务切换到 Spark 来逐步解决。三，模型的复用性治理，不能为了模型的复用性把所有东西都加到一个模型中，这时就需要做一些模型拆分、增加冗余度的工作。

Q2：中通在数据标准落地方面做了什么措施，怎样保证制定好的数据标准可以得到有效遵守和执行？

A2：在数据标准落地方面，主要做了模型标准化、指标标准化等，如果保证制定好的数据标准可以得到有效遵守和执行确实需要值得关注，首先需要流程来规范，同时也需要借助工具层面来保障。

Q3：在数据治理方面，构建类似数据地图一样的模型对数据业务的提升是否特别明显？这样的数据地图模型对下游用户来说，存在一定的学习成本，那么成本和对他的帮助是个怎样的关系？

A3：数据地图更多的是降低数据使用门槛，让使用方比较直观、一目了然的知道我们到底有哪些数据。使用成本相对来说是比较低的，比如每一个主题域包括哪一类的数据，有什么用途，我们相对都有比较明确的解释，比较直观的了解到这个主题是存放了哪些数据。