物流行业数据中台实战——兼谈数据中台实施方法论

1.1 行业背景

物流行业已走过规模增长时期，正在进入传统企业不断进化，新物种全面崛起，互联网巨头争相入局的竞争新时代——政策利好与黑科技促进完善能力基底，商流变革倒逼物流升级，也由此迎来最好也是最艰难的时代。

随着新兴企业的积极入局，“互联网+物流”模式得以快速兴起，作为行业的新鲜血液，这些新进入者在资本的助力下，依托其创新的商业模式、积极灵活的市场拓展过程确实对传统物流企业带来一定冲击，也进一步推动了整个物流产业生态的丰富和发展。

阿里巴巴推出的数据中台强调两个概念：业务数据化和数据业务化。正是新兴互联网企业以技术和业务为抓手赋能行业的切入点。

1.2 传统物流公司信息化的困境和传统解决方案

从粗放式经营到精细化管理，物流公司信息化建设是企业变革关键核心。在互联网时代物流企业信息化建设面临的主要问题有：

图1.1企业信息化面临的问题

针对企业信息化的挑战，传统解决方案是企业级数据治理。数据治理是一套持续改善管理机制，涵盖了人员，流程和技术，是一系列改变数据使用行为的过程。
但是传统数据治理是一个冗长的，复杂的过程，而且需要大量人力和资源投入。有很大的缺陷如：

1.实施周期长
2.达至预期目标的不确定性
3.对相关人员素质（技术，对数据资产认知等）依赖过高
4.过长的实施周期，无法适应短平快的互联网竞争等。
5.每一次数据治理都是对企业所有信息系统的一次重构和整合
6.脱离业务场景从标准层面的数据治理，无法直接产生业务价值。

而数据中台技术是通过一序列信息技术，特别是数据处理技术进行数据的采集、加工、整合后，形成企业内部一套标准统一的可复用共享数据集合，最后高效的把数据封装成服务提供给业务或是下游系统使用，从而实现D2V的理念。数据中台强调数据的整合复用及共享，可以建立在不对原有系统推倒重建的基础上构建共享数据服务。

1.3 驻云科技数据中台方案的优势

阿里云作为数据中台的概念输出者，是很多客户构建数据中台的第一选择。驻云是阿里云的最大合作伙伴之一，具有丰富全面的数据中台构建方法论及实施经验。如阿里云与驻云科技合作构建某物流企业的数据中台。
该物流企业是业界领先的零担物流平台。最早由区域合伙、联盟发展而来，目前主营业务是全国公路零担物流网络服务，致力于为客户提供高性价比的综合物流服务。
该物流企业建立数据中台效能：帮助企业建立完善的信息化解决方案，全面支撑公司业务发展，规范作业流程、提高工作效率,减少重复劳动，保障数据的准确性，通过数据分析，为管理提供有价值的决策依据。

2. 数据中台实施

数据中台实施全流程概览。

图2.1 数据中台实施流程

2.1 需求和业务调研

需求调研是个漫长又不特别明确的阶段,因为客户对于自己想要的东西,不是通过调研就清晰的,而是随着交付的过程慢慢清晰的. 所以当前阶段最关键的工作内容是通过调研清楚具体的业务情况,数据情况,进而明确整个项目的交付边界,而不是弄清楚交付细节.
需求和业务调研中间产出的交付件是数据资产调研表。
包含但不限于以下信息

调研信息项  说明

信息资源表名称               企业内所有表资源名称    

信息资源表所属系统        对应的系统名称    

信息资源表提供部门        表信息资源的提供部门    

信息资源表的更新周期    表的更新周期    

是否支持增量更新           是否有业务时间字段提供    

信息资源表的保密级别    跟数据资源的表的可访问级别相关    

表字段说明                     数据字典    

信息资源表维护人           表的指定维护方联系人    

信息资源表维护人联系方式    表的指定维护方联系方式    

需求和业务调研中间需要产出一个客户业务全局文档及相关指标体系作为内部实施核心文档。全局业务文档主要内容包含但不限于：

·客户所有业务部门及其业务介绍
·客户核心业务流程介绍
·客户全局数据来源和流向介绍
·客户所有业务系统及其功能介绍且标出重复建设部分

根据该物流企业核心业务流程我们在需求和业务调研阶段总结出物流企业常见业务流程如图2.2

图2.2物流企业常见业务流程

根据该物流企业运营指标库，我们归纳物流行业关注的几个核心运营指标主题如图2.3

图2.3 物流核心指标主题

2.2 数据域定义

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。其中， 业务过程可以概为一个个不可拆分的行为事件，在业务过程之下，可以定义指标; 维度是指度量的环境，如买家下单事件，买家是维度 。
阿里巴巴的OneData体系是一整套数据整合及管理的方法体系和工具。阿里巴巴的工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性。借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似大数据项目快速落地实现。
借助OneData体系，根据物流行业具体的业务全局及其数据资源调研表，我们遵循高内聚低耦合的架构设计策略。设计企业数据域也即公共数据中心。主要包含：

根据现有已分数据域，我们可将数据资产根据具体的业务划分到所归属的数据域中，为底层数据架构建立标准。

2.3 主数据定义

主数据是指高业务价值的，可以在企业内跨越各个业务部门被重复使用的数据，是单一，准确，权威的数据来源。主数据具有以下特征：

·特征一致性
·识别唯一性
·长期有效性
·业务稳定性

主数据是面向应用层面划分，我门遵循自上而下的设计策略，以客户需求场景为主来提取客户核心关注的主数据。
从物流行业应用场景来看，我们总结出如下物流行业主数据：

·用户
·商家
·订单
·车辆
·位置

阿里巴巴OneID体系基于行为中心数据，综合人口学、社会学理论知识及业界标签分类体系，构建用户社会学标签及业务场景标签，对“ID”进行全方位刻画，更生动的了解用户，更好的服务及触达用户。在对外赋能的过程中，不仅应用在to C 场景中对消费者的刻画，也可以应用在to B 场景中对租户等的刻画。

结合阿里巴巴OneID方法论我们为上文中提到的某物流企业构建用户，商家，订单，车辆，位置的统一ID为上层应用提供便捷数据服务。

2.4 架构设计

根据物流企业的业务和需求调研我们构建了，物流企业的数据域和主数据架构体系。如图2.4

图2.4 架构设计

数据中台的数据资产层共分为三个层：第一层是采集层，即垂直数据中心。在采集层，更多的工作是通过采集和同步工具，将业务系统的业务数据同步到数据中台，并形成一个个垂直数据，在此过程中，并不会做数据的清洗和处理。传统DW称此层为ODS层。

第二层是公共层，即公共数据中心。所有的数据的清洗、加工、处理都将在公共层完成。首先公共层横向划分为公共明细层和公共汇总层，其中公共明细层是按照不同维度生成的明细数据，公共汇总层是根据上层业务应用的输入，对数据进行轻度汇总。同时公共层又会纵向的，根据不同的业务主题划分为不同的数据域，每个数据域又划分不同的业务过程，每个业务主题的数据都会在各自的数据域进行加工和处理。

第三层是应用层，应用层会分为萃取数据中心和主题中心，其中萃取中心是以各个业务对象为核心的标签体系，主题数据中心是根据不同的上层应用，通过公共汇总层的模型构建出来的面向各个应用的应用层数据模型。最上层的业务应用都会通过统一的数据服务，从应用层调取数据。

2.5 数据仓库模型设计与规范定义

数据仓库模型设计全局一览如图

图2.5 数据仓库模型设计与规范定义

模型设计的基本原则主要有

· 高内聚低耦合：
将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型，将高概率同时访问的数据放一起 ，将低概率同时访问的数据分开存储。

· 核心模型与拓展模型分离：
建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要 ，不能让扩展模型的字段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。

· 公共处理逻辑下沉及单一：
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。

· 成本与性能平衡：
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

规范定义

构建企业的指标体系，指标体系：原子指标，派生指标，修饰类型，修饰词，时间周期组成体系之间的关系。

图2.6指标体系

2.6 开发过程管理与规范定义

1) 代码开发

将设计阶段产出的ETL设计文档、数据探查报告，结合开发自己的数据探查结果，同时根据自身对业务和数据的理解，转化为具体的代码。根据设计阶段产出的设计文档里关于工作流节点的设计和调度设计文档，在DIDE里新建工作流节点。

工作流节点类型包含：CHECK(虫洞)、同步中心、虚拟节点、ODPS SQL、ODPS PL、SHELL、ODPS MR、EXSTORE。根据需要，UDF、UDAF、UDTF类型还需要新建资源和注册函数。根据设计阶段产出的设计文档里关于需求与设计实现的阐述，转化成具体的代码；针对不同的功能设计，需要编写SQL、SHELL、JAVA、PERL、PATHON、MR等代码。

代码开发完成，提交的同时将根据预设好的扫描规则对工作流节点进行相关的检查(禁用关键字检查、命名规范检查、数据引用规范检查、注释规范检查等等)，检查结果分为：通过、警告但通过、警告不通过。

2) 单元测试

代码开发完成之后，开发人员需要对代码进行单元测试，单元测试阶段需要进行：规范性检查、代码质量/BUG检查、数仓特殊需求检查、指标特性检查。测试完成之后开发同学还需要整理发布操作文档,以便后面进行发布工作。输出代码、单元测试报告、发布操作文档。。

3) CODE REVIEW

单元测试完成之后，需要由其它开发人员进行CODE REVIEW。CODE REVIEW阶段需要进行：数据一致性检查、数据完整性检查、指标间逻辑检查。CODE VIEW完成之后开发阶段的工作即完结，由开发人员通知测试人员进行测试阶段的工作。此处需要提供CODE REVIEW模板，输出CODE REVIEW报告。

2.7数据质量管理

开发完成后的数据运营过程需要持久的数据质量管理，用来保证数据的质量持续可用。如图2.7

图2.7 数据质量管理

3. 数据中台应用

经过数据中台的数据梳理和指标体系的建立，可以为运营分析提供直接有效的服务。如数据大屏和BI报表

3.1 数据大屏应用

经过数据中台产出指标体系，某物流公司大屏效果展示

3.1数据大屏应用

3.2 自动化BI报表

根据成熟的指标体系构建商业智能BI分析报表，如结合阿里云quick BI产品构建部门运营分析报表。可由业务人员直接在数据门户中通过拖拉拽的方式实现业务运营分析。

3.3 数据服务

用户也可构建一套数据运营平台兼具门户功能，为企业内部提供一个可视化的数据共享服务。数据运营平台通过OneService服务来统一对接管理数据中台提供的上层数据应用服务。

4.总结与回顾

数据中台的建设节奏是个前松再紧后又松的过程,而且是随着业务的变化而变化的漫长的过程,建成的标志我们认为有两个: 第一个是指标的复用性,BI取数脱离被动的根据业务人员的指挥,业务人员可以从中台直接取到大部分指标数据;第二个是数据应用的建设脱离了从零起步,能够直接基于中台的结果快速建设所需的数据应用。