中通数据仓库目前是介于业务系统和数据平台之上，数据应用之下的组件，通过中通的大数据开发工具，构建了覆盖全公司所有业务线的数据仓库，支撑了中通庞大的数据应用，如驾驶舱、C端、光合、智能仲裁等业务系统的数据应用功能，直接为一线业务赋能。

ODS层：数据引入层ODS(Operation Data Store)，存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。

DW 层：数据清洗层(DW)，对ODS数据进行异常值数据和对变化数据进行合并，形成包含历史全量，规整的数据明细层，对ODS数据进行merge，字段异常清洗等操作。

DIM层：公共维度层(DIM)，基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层与数据清洗层在一个并列层次。

D M层：数据集市层(Data Market)，主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标集合，俗称”宽表”。

主题域现状：目前中通数仓主题域主要划分为财务、中转、件量、时效、运营、客户、网络管理等主题。

中通快递从2002年成立至今，业务量的规模正发生着巨大的变化。

图：中通快递近六年业务量增势情况

快递业务主要包括收发到派签5大扫描流程，在这个快递转运过程中产生了海量的数据。中通快递日均扫描量从19年初的3.5亿到2022年初日均10亿条扫描记录入库，翻了3倍。

时效方面： 面对与日俱增的数据量，核心调度任务的跑批时效捉襟见肘，时时面临业务报表出数不及时或者留存buffer及其紧张的情况。

存储方面：目前已同步的基础数据已达PB级别，大量冗余不活跃的脏数据占据着磁盘存储资源。

内存方面：早期为了尽快从hive切换到spark引擎，内存参数的设置滥用，无节制与规划，历史模型冗余重复，脚本书写不规范。

指标方面：早期大量“烟囱”式开发，导致指标混乱不清，下游口径不统一，无法高效输出应用与复用。

为了更好的进行“数智化”，中通数据仓库的治理就显得尤为紧迫与重要。

A.数据入仓治理

我们知道规范化的数据入仓要考虑：数据量的大小、数据变化的频率、数据使用的场景等因素，在业务端源数据同步入仓时采取相应的同步方式【增量/全量】、同步方法【比如DataX/Sqoop/CDC】、数据的分类分级等操作。

早期为了尽快使下游能够使用基础数据，针对入仓操作简单粗暴，以讲究数据快速入仓为目的进行的一系列操作带来大量的数据问题：

1> 错误的全量或者增量同步方式所引起的大量业务侧数据库慢SQL

首先在同步工具上面进行改造优化，针对数据同步本身进行初步评估，如下图：

在新增同步任务时，避免采取不合理的同步方式进行处理。同时通过对元数据的统计分析以及DBA提供的慢SQL清单，数仓按照数据量的规模、增量数据的大小、历史数据使用场景、数据变更的周期等因素开始针对历史的同步任务进行改造，大大降低了业务侧数据库抽取压力，同时规范数据同步。

2> 抽取方式繁多不统一，后续维护工作量大

在抽取方式上面，进行了平台侧改造，新增的普通抽取全部采用datax的方式，取消原先的sqoop，这种考虑主要的因素是要弱化数据同步的复杂性与提高数据同步操作的时效性，同时在数据同步选择存储时，优先选用orc格式，尽量避免text格式【目前支持不推荐】，降低存储与脏数据的容错性。在2022年，中通数仓完成了同步任务的全部切换与改造，同时将原先不合理的同步分层全部进行治理，比如多个ods写入一个dw。大表早期选择textFile的，也进行切换到orcFile上，这个过程主要通过new create table 然后rename的方式完成，而存在大量下游依赖的表，平台侧也开发了一键迁移依赖关系的功能，如下图：

表格式的切换，大大减少了下游调度任务读取磁盘的量，同时也降低了磁盘写入，时效提升15%+，从sqoop同步切换到datax同步，单个同步任务的同步时间节省了80%，大大节省同步开发的时间成本。

3> 大表同步优化

大表数仓同步，其实本身是存在历史因素的，基于当初的数据体量与技术选型，完成数据同步是首要目标。随着时间的推移，大表的同步有了更多的选择时，中通数仓积极进行尝试，缩短链路过程，强力保证核心应用时效，拥抱中通快递日新增亿级体量的数据规模，这里主要从具有实时性的订单数据以及超级大表账单数据进行实践分享介绍。

订单数据同步优化：

中通快递的业务量主要来自于电商平台，所以订单表是个超级大表，订单数据本身又需要进行实时的跟踪统计分析，所以早期在数据同步时，数仓选择了大数据hbase组件进行同步。先通过binlog解析工具进行日志解析，解析后变为JSON数据格式发送到Kafka 队列中，通过Spark Streaming 进行数据消费写入HBase，然后将订单在HBASE中的快照通过datax工具同步到数仓ODS层，再由ODS处理后到数仓DW层，总共需要经历4步，流程长，链路耗时高，且存在多份冗余的存储，资源消耗大。

图-订单数据入仓【旧】

为了提高订单数据入仓的时效又要保证数据能进行实时的统计分析，中通数仓开始尝试引入hudi，构建了一套新的入仓流程。

Hudi入仓相比与HBASE的优势在于，hudi表能与hive、spark、presto关联查询，直接省去了hbase同步到ODS的过程，通过对数据的校验以及同步流程稳定性的监控，经历了3个月的数据联测跟踪试运行后，进行了任务切换，链路时效直接提升了1hour+，大大提前了下游核心任务的启动时间，为链路空余出足够的buffer效用。

账单数据同步优化：账单数据在实时统计分析上虽然不及订单要求的及时性，但是中通快递这种加盟形式运营，在网点账单结算上会存在大量的数据。早期的网点账单数据粗暴的通过数据库直接datax增量同步到hadoop，随着业务量的暴增，账单数据日均已达10亿体量，而账单又存在较长的结算变更周期，所以每次回刷的体量达到100亿+的数据规模，耗时严重。为了满足下游核心应用时效，数仓尝试将大体量的数据同步采用消息同步的方式分小时批次入仓，最后统一处理。通过将T-1日数据提前到T日处理的方式，直接将链路时效提升2hour，同时大大减轻了源库抽取的压力。

B.核心模型治理

传统的模型优化治理都是重构代码，横向扩大指标的使用，纵向裁剪不活跃的指标。但是，中通数仓采用了一些其他的代码重构策略：

a、早期，调度平台还未引入step开发模式，后续升级平台开发功能后，将指标重新分模块与批次，加大代码内部的并行度，充分利用CPU资源：比如快件跟踪轨迹宽表中使用到的收、发、到、派、签等基础扫描数据，统一放在相同的step中进行并行提取处理；

b、中通数仓从构建都目前，随着硬件资源的扩充，内存的瓶颈阶段性的解决后，数仓将tmp表适时的切换成view视图形式，充分使用内存，减少磁盘IO的读写；

c、自从大数据平台进行了Spark小文件治理后，原先需要回刷1个月以上的分区脚本因为分区写入过大导致失败而拆分多次插入的动作，可以一律切换成使用spark引擎，一次插入，淘汰旧的hive写入方式，在时效上得到大大改善；

d、从数据业务场景优化数据的读取，比如一般的快递扫描操作的生命周期都是在一周内，那么在提取扫描数据时，按照不同的扫描数据业务生命周期提取适当的数据分区范围，避免过度读取数据，大大减少IO，提升整体跑批时效；

e、通过统计分析下游不同对象对于模型时效的诉求，针对性的构建新模型，而不是一味追求宽表的复用性，比如数仓专门为分析部门构建全链路轨迹宽表，突出分析实用性而非时效，而将原有冗余的宽表进行大幅度的指标裁剪突出核心指标的时效，从而大大改善不同对象对于模型易用性与时效性的平衡；

f、另外中通数仓部分模型采用离线与实时融合的方式，充分利用实时计算的能力提高时效，又结合离线数仓数据覆盖范围广，保证数据质量。

构建于大数据平台上的中通数仓，随着中通业务量的高增长，对于有限的存储资源面对每日同步TB级别的数据进入数据仓库，存储与运维都日趋紧张。如何进行降本增效，真正将高热点数据进行专业化处理，有效提高数据的加工能力，将大数据化为实用的大数据才能更好实现数据的增值。那么中通数仓是如何有效甄别高热点数据来实现降本增效？

从数据的生命周期进行切入，中通数仓采取对表的访问进行活跃度监控，分别从周期角度【近30天、近60天、近90天】与操作角度【调度层级（优先级：低中高，状态：测试、试运行、上线）】两大数据特征，持续性的进行表使用情况的监控，从而达到有效准确的删除过期无效数据。通过利用表活跃度进行存储治理，中通数仓节省了PB级别的存储空间。

中通数仓在调度开发使用引擎方面，经历了从单一的Hive引擎到Hive、Presto以及Spark自有切换的过程，从大面积开始使用Spark引擎，在内存的使用上面，任务开发人员为了完成开发任务，而未有效关注内存参数的正确使用，故而出现大量滥用内存的情况。同时，部分任务频繁的出现失败重跑，究其原因普遍是由于内存不足与数据倾斜。内存资源的不合理使用，导致核心报表的时效经常不能稳定输出，特别是面对大促期间，营运效率提升更显突出。那么中通数仓具体的内存治理该如何进行？

第一步：内存浪费治理

内存浪费治理的关键是如何识别内存资源浪费，那么调度任务如何打上浪费内存的标签？这里我们进行了实际的物理参数的统计分析。中通数仓的物理机内存是256G，实际参与内存调度有220G, CPU是50个vcore，所以⼀个CPU理想情况下是最好使⽤220/50=4.4G内存，这个样⼦数仓整个集群的cpu与内存资源占⽐是均衡的，如果⼤量任务申请的内存资源超过4.4G，就会导致我们整个集群的内存资源已完全占⽤，但是cpu资源还有很⼤的富裕，导致集群利⽤率低下，从⽽导致任务的时效的⽆法保障。

图-内存与CPU使用情况资源图

在集群层面进行了内存参数的限额配置后，中通数仓分批次从20G->16G->10G->8G开始进行有计划的管控，资源严重浪费的TOP任务优先进行整治，成效显著。

第二步：数据倾斜治理

通常当我们查看长时效调度任务的时候，在具体到step SQL时，明显看到该段SQL跑批异常慢，再结合对应的stage，可以准确的找出发生数据倾斜的SQL，进而通过join的条件找出发生倾斜的key。

图-发现数据倾斜的STAG

图-发生数据倾斜的SQL DAG图

中通数仓在处理数据倾斜这一常见的SQL问题上有几点思考：

1> 什么样的业务数据会导致数据倾斜？

2> 如何避免不必要的数据倾斜而编写大量的group by语句？

针对以上两点，中通数仓进行业务数据调研，以扫描操作数据为例，当中心或者网点进行新设备引进时可能会因为操作人员的误操作而导致大量扫描重复数据的上传，针对这种业务场景，及时的透传设备问题，止血脏数据，避免更多重复数据上传至关重要，为此中通数仓联合产研团队进行了相关业务数据治理，通过对设备端的监控，将问题设备直接透传到网点或者中心，高效的解决热点数据，从而避免此类问题导致的数据倾斜。

当然，从业务数据视角去探查规避数据倾斜是一方面，本身数据倾斜也是常见的SQL问题，开发人员如何定期定点的进行处理优化SQL，只有将数据倾斜的SQL标签化，才能省去费时费力的定位key。目前中通数仓，SQL数据倾斜通过shuffle等一些列实际运行值进行统计分析标签化。

第三步：内存不足治理

大多数时候，开发人员完成SQL脚本后，只要开始任务正常完成上线后，日后的关注度会随着上线时间的推移，渐渐降低，那么核心关键任务如何保证在大促阶段，随着数据量的徒增而不会因为内存不足连续失败重试？

显然有了前面的内存指标使用的监控，内存不足的标签也打在的任务治理上。当然，内存的治理还有其他一些重要指标项，比如全局排序、多对多join等等。

图-内存异常监控指标分析list图

通过一系列的内存资源治理，集群的内存使用基本保持一个稳定的状态，充分保证集群资源的高效使用，任务时效大幅度提升。

指标管理的难度随着数据规模与复杂度的攀升，特别是达到PB级时，在复杂的业务分析场景中如何保证输出的数据指标是高质量的？中通数仓是如何持续进行指标治理的呢？

图-指标治理的现状与目标

A. 定义标准

中通数仓指标如何构建一套标准？老旧的方式是大家采用原始表格达成一套约定俗成的定义，而这带来的最大问题是低效的执行度。所以，今年中通数仓借助线上化的指标字典来进行指标规范化。

图-指标规范化定义及样例图

图-基础指标与衍生指标公式图

在指标主题域方面：为了更好的组织和分类各种指标，根据业务过程、或者业务对象划分了客服、财务、中转、件量、时效、运营、客户、网络管理等不同的指标主题，同时又将一级主题域细分到二级主题。

在指标的具体定义上，将指标进行业务定义与技术定义双标准规划。

业务口径包括如下要素：指标解释+指标目的+主要维度说明+公式。

技术口径包括如下要素：包含涉及到的表，取什么信息，关联条件，过滤条件等。

基础指标定义后如何维护衍生指标也是很关键的。

B. 具体执行

指标的管理上，主要强化开发流程、审批流程、指标数据质量监控。

1>开发流程：从产品需求对接到具体分析评估，设计及开发，数据检验测试，最后上线，强管控6大步。

2>审批流程：通过拆分三大指标管理的对象，字典管理员、DBA、数仓进行指标的录入。

3> 指标数据质量监控：要保证指标的准确率与使用率，必须要有一套完整的数据质量监控体系平台。

通过数据质检规则红绿灯模式干预调度流程，当指标监控处于强规则校验模式下，异常指标直接阻塞任务执行，发出任务失败告警，强人工干预检查；当指标监控处于弱依赖规则校验模式下，出现指标异常告警，则对应开发人员可以在白天进行异常指标分析，确认详细的情况后再进行指标监控的优化以及下游指标使用情况的输出反馈。

C. 推广与使用

由于原先的指标混乱、定义不清晰、统计口径模糊、数据质量等等问题，下游使用对象在指标定位查找以及使用上存在较大的难度，另外很多核心宽表的指标都是通过数仓开发人员进行”翻译”推广的，从而进一步造成指标的复用度低下，反复构建相似指标，冗余突出。

为了提高指标的推广与正确使用，中通数仓搭建了一套元数据管理系统。这套元数据管理系统打通了表、SQL、报表、指标四维关系，当使用者想要查询某个业务系统某个报表的某个具体指标的来源与口径，可以通过元数据管理系统精准搜索、高效定位、准确捕获，完成数据一体化查询服务。

如何清晰描述指标的来龙去脉，离不开元数据管理系统的血缘能力，通过明晰当前指标的来源去向，更好地进行指标的正确使用与推广。

1、目前元数据的内容建设还要持续进行，通过数据质量的监控逆向反馈到业务系统进行数据治理预警还欠缺，还不能进行智能化调整质检任务，比如大促与日常订单量趋势的监控能否通过订单量的预测分析进行质检规则的调整。

2、目前元数据平台提供的血缘分析局限于调度任务级别，热度停留在表的收藏、点赞、关注，后续考虑进行指标层级的血缘分析，比如将指标进行热、温、常、冰四维一体的热度值标签，精准指标颗粒度的使用场景分析，进而提供模型优化及新增下线的智能建议。

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