本文根据王平老师在〖2023 中国数据智能管理峰会-上海站〗现场演讲内容整理而成。

当下，数字化转型的浪潮席卷各个行业，对很多领域都有较为深远的影响。从埃森哲报告的数据来看，数字化转型领军者营收复合增长率是其他企业的5.5倍，增益显著；但转型领军者（转型成功企业）只占总体企业的7%，这说明数字化转型成功的效益巨大，但同时道路艰辛，目前只有7%的企业能达到这个目标。

在企业数字化建设过程中也面临着各种各样的挑战，主要可以概括为数据质量、数据安全、成本和效率4个方面。

《华为数据治理之道》一书中讲到：“清洁数据成就卓越运营，智慧数据驱动有效增长。”数据治理是数字化转型中基础设施的一部分。平台提供管道，数据治理提供数据血液，而且是清洁的数据血液。有了清洁的数据血液之后，才可以更好的服务于企业智慧化的用户增长。

很多公司的数据治理是从数据侧驱动，但往往很难推进，通常都会受到来自各方的阻力。

比如从业务视角来讲，业务只需要有好用、可用的数据即可。至于数据怎么来的，并不想管，同时认为数据治理与自己无关，这是很多企业在数据治理过程中面临的一个现状。

公司的管理层为什么要配合做数据治理？这里直接给出一个结论，能够把数据治理做好的企业，往往数据治理是这个企业的一号位工程，一号位指的是企业的最高决策者。数据治理是需要企业决策者直接挂帅去牵头推进的一个事情，只有自上而下才能推进落地。不然仅仅依靠少许内部员工和团队的热血，执行推进上是非常困难的。

因为数据治理不只是数据部门的职责，更是业务部门、生产系统、数据使用方对当前的数据产生、加工、消费习惯和流程的变革。

如果打动管理层来认可数据治理工作，可以从两个方面着手：

一是成本和效益。随着公司业务不断发展，企业数据量更是爆发式增长，对服务器的需求也会同比例增加。而通过数据治理，公司整体的离线计算资源投入、数据任务计算完成时间都将会大幅度缩减，预计节约一些新增服务器资源的成本，实现降本增效。

二是安全与合规经营，这也是企业的红线。通过数据治理，很多企业在数据存储、传输、使用管控等环节的数据泄露风险可以大大降低。这里也是借用中央的反腐策略，“不敢、不能、不想”，通过划定红线，制定规范，约束企业的生产经营，保证企业安全合规地经营。

从业务团队角度，业务方重点关注两个方面：效率和质量。

效率方面：我需要的数据什么时候能计算出来？有的企业会推进成本划小，给业务方划小的成本很高，以至于个别业务方无法接受，这时可以从效益的角度去打动业务方。

在这里分享一些我们的经验。针对业务方我们要主动挖坑：现在业务方的数据计算不出来，如果配合做数据治理，可以引导业务方开辟一条新的数据链路，数据能够快速计算出来；如果不做数据治理，就只能继续在老的链路里慢慢玩。主动给业务挖一些坑，从产品或者平台角度是很容易实现的，比如可以做适当的资源倾斜，因为在后台可以决定给哪些任务分配多少资源，这都是一些很简单的IT手段。

质量方面：可以直接跟业务团队直接签订SLA协议。数据治理之后，除了数据的采集加工和处理链路，我们会做7*24小时运维保障，还会通过数据质量稽核的管理工具进行数据质量问题预警，全部交给治理团队来保障任务的质量。

前面讲了管理层和业务方为什么要配合做数据治理，那么可以从哪些维度来启动这个数据治理的工作呢？以下是翼支付做数据治理过程中总结的几个方向。

第一个是组织协同模式。由于数据治理是一个自上而下、企业一号位工程，那么为了确保治理效益，需要按企业实际情况进行适当的组织变革，建议由数据治理委员会牵头，数据的使用方、所有方、治理方组成联合团队，共同推进数据治理工作，保障跨团队的协同和推进效率。

第二个是平台。有了数据治理的组织，就要有一套工具来满足业务方对数据的加工和使用诉求。

第三个是数据应用链路治理。这是数据治理最核心的部分，要把数据从端到端的链路全部交给一个团队承接治理。

第四个是数据规范与数据质量的提升。需要和平台紧密协同，制定数据规范，通过平台去约束保障规范落地，通过平台的数据质量稽核来提升数据质量。

最后是数据安全。在治理过程中，严格按照数据安全要求，整改数据链路过程中存在的安全问题，比如敏感信息存储和传输的加密等。

图中就是治理前后，基于评估机制，做的整体的评估，右下角展示了计算效益。其实治理完之后并不是所有板块都有显著提升，目前提升较为显著的是核心数据应用链路治理和平台建设板块。

治理效益体现在三个方面：

翼支付数据治理的总体思路，我们总结为234法则，即2个牵引3个组织4个步骤。

1）2个牵引：即标准牵引和应用牵引

2）3个组织：三个核心的团队（最开始做数据治理，也是分了很多团队，最后精简成这三个比较核心的）

3）4个步骤：从问题的调研、需求的提出、根据需求进行方案的设计/评审、实施组进行治理实施、业务验收。

PPT中的右图是翼支付数据治理能力体系的示意图。核心内容分为两个方面：

一方面是数据治理的推进，从数据架构与模型、主数据、元数据、数据安全、数据服务、质量治理这几个领域推进。

另一方面是大数据平台层，通过数据产品和数据管理工具，将数据集成、计算和服务进行有效整合。

前面介绍了数据治理体系的顶层设计，基于其中几个核心环节，简单阐述在翼支付数据治理实践过程中的一些思考。

针对数据链路治理，首先需要标准牵引，规范先行；然后再结合业务核心诉求，即业务需要什么，我们就治理什么。这是数据治理最核心的部分。

具体的治理过程就是从业务核心任务的提报——即业务告诉我们哪个应用或报表是核心的；再到上游依赖，把它上游依赖任务找出来；然后再做任务优先级的调整，以及整个链路任务的治理；最后通过配置任务时效和质量监控策略，结合7* 24小时运维保障机制，保障业务使用数据的时效和质量。

这里的应用牵引，一定要避免大而全，需要重点关注。在治理的过程中，会发现有些报表和看板会被自然淘汰掉。我们的核心策略应该是：集中80%的精力，解决20%业务核心的诉求。

数据链路侧更多是靠数仓工程师和业务分析师团队来开展治理。而在计算引擎侧，主要是大数据工程师对整个平台计算引擎的升级，以此来提升治理效益。

翼支付在数据治理过程中，大数据工程师从计算引擎升级和集群小文件治理来开展工作。

在计算引擎升级方面，将离线计算引擎由hive迁移到spark，没有做其他操作的情况下，引擎升级后，相同的计算资源，其计算效率提升了两倍。

针对迁移之后还会有一些资源消耗比较大的任务，特别是一些数据倾斜类任务，会导致整体计算时效偏慢。这时需要搭建离线资源的消耗和耗时的监控来识别待优化任务，然后由比较精通SparkSQL的大数据工程师进行定制优化。对识别出来的任务进行定制优化后，任务在运行前后，把它的消耗的资源及运行时长进行对比，如右图所示，它消耗的资源在降低，同时运行更快，这对整个链路的治理起到很关键的作用。

在集群文件治理治理方面，我们知道针对集群，如果小文件过多，集群整体的性能会显著下降。为了保证集群的文件数控制在一定范围，我们做了两件事情。第一个是集群参数调优，把 Spark参数并行度进行下降，调优之后小文件数大幅下降，这个时候保证集群的性能在一个平稳的水平，且整体的小文件数显著下降。第二个是开展了持续的小文件监控，如果文件数上升过多，就把小文件增长较多的任务找出来，然后做定制化的处理。总体保障任务稳步增长的同时，集群性能维持在一个相对理想的状态。

上面是翼支付大数据体系完整的产品矩阵。那么数据产品在数据治理过程中起到什么作用呢？我理解数据产品的作用更多的是落地数据规范，并结合数据应用释放数据的效能。

实际上，我们把数据给到业务使用场景中，大家普遍都认为业务希望得到的是质量高、时效好的数据，然而往往忽略了数据的可用性。“可用性”简单理解就是业务需要某个数据时，是否能快速提供？不要告诉业务目前数据还没计算完成，或者由于各种原因无法直接从底层获取，又或者存在数据安全问题不能提供使用，类似这类问题是需要平台去解决的。

大数据平台整体分为三大板块：

一是大数据平台最核心的底座，这和其他公司应该基本一致，包括核心的数据开发与治理平台，有BI平台、AI平台、元数据平台等。

二是数据管理平台，主要是用来做数据的加工、分析服务。数据管理平台主要是落地标准，数据标准平台做指标的管控；数据资产平台用来做资产的沉淀，并通过数据地图向客户进行开放；全景画像平台用来做标签的加工和管理服务等。

第三个是的数字运营，因为数据要向业务释放效益，仅仅有加工和服务的平台是不够的，要以大数据的视角来建设整个的数字运营工具，主要建设了智慧运营、智能决策和智能客服三个系统。智慧运营主要的能力是将推荐、营销策略进行编排整合，支持策略间的协同；智能决策是把治理之后的数据标签化、指标化，然后通过决策直接赋能业务的策略编排，如营销、风控等场景；智能客服方面，基于当前比较火的大模型技术，我们利用治理后的数据进行模型训练，主要面向客服场景提供智能化服务。

翼支付有大概5亿多的用户，标签数据体量比较大，传统的全量计算方式在数据准确性上有一定的优势，但是计算效率较低下，且数据故障恢复时间久。当标签数量到达一定阈值后，全量计算的弊端会更加凸显。基于此我们开展了标签数据体系的治理工作。

1）治理方案

我们利用Hive和Hbase映射表来解决标签的扩展问题。传统的Hive表是很难做加列操作，加列会对稳定性产生一定影响。通过Hive和HBase映射表来解决这个问题，再把数据推到Hive和ClickHouse，Hive用来做离线分析，ClickHouse用来圈定人群或OLAP查询分析等。

在整体的治理过程中，我们首先把数据架构进行升级，标签的计算架构由原来的全量计算改成增量计算，再把存储方式改为Hive多表的形式（之前是大宽表），以便于按照业务域、更新周期进行分表，新增的标签就可以单独开发。

有了这一系列拆分后的Hive表，再同步到Hive和ClickHouse汇总成一张宽表。在Hive-ClickHouse同步过程中，翼支付自研了一个ClickHouse表引擎，可以支持增量同步到ClickHouse之后再进行数据合并，并合成大宽表。

2）治理效益

• 通过标签架构升级，由全量更新变成增量更新，标签计算完成时效从11点提前至6点前，数据同步时间由3小时缩短到30分钟；

• 在新架构下，标签总体数量也突破了原有上限，满足更广泛的业务标签沉淀需求。

• 相较于原有HBase+全量更新模式，新的方案在新增标签时，需要在ClickHouse进行字段扩展。（原有全量更新可以走删表-建表方式自动化处理）

对于企业来说，数据治理不能只作为阶段性的治理工作，需要将其常态化，把数据治理的规范流程贯穿到日常的数据采集、加工和服务过程中。

生产数据的标准统一还有较大上升空间，当前在线业务和离线业务还是有比较大的割裂，并且团队的思想还不太统一，未来还需要将数据治理贯穿到生产侧。

同时，很多数据问题因生产源而起，所以后面需要把生产源头的标准和大数据开发标准协同统一。

数据智能化应用是做数字化转型&数据治理的一个最终目标，通过数据治理来释放数据资产价值，为企业的精细化运营和数字化发展做出更大的贡献。