计算成本降80%,5亿用户下的数据治理建设实践

王平 2023-08-19 16:51:00

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

 

图片

 

作者介绍

王平,翼支付产品总监,现担任翼支付大数据与人工智能研究院产品中心负责人,牵头负责数智中台产品体系设计及公司数据治理项目推进。有丰富的企业数据治理、大数据平台建设及数据智能化应用经验。

 

分享概要

一、数据治理顶层设计

二、数据治理实践与思考

三、未来展望

 

一、数据治理体系顶层设计

 

 

1、数字化转型的机遇与挑战

 

图片

 

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

 

图片

 

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

 

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

 

 

2、如何让管理层和业务团队一起参与数据治理?

 

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

 

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

 

图片

 

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

 

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

 

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

 

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

 

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

 

图片

 

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

 

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

 

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

 

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

 

 

3、从哪些维度推进数据治理?

 

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

 

图片

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

  • 第一个是计算成本下降80%以上,即用原有的计算资源能计算更多的任务,这就是为公司进行降本;

 

  • 第二个是业务比较关注的,核心的任务、看板或报表的计算时效可以提前8.5个小时;

 

  • 第三个是查询时效提升了近40倍。

 

 

4、翼支付数据治理建设思路

 

图片

 

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

 

1)2个牵引:即标准牵引和应用牵引

 

  • 标准牵引:做数据治理,要先制定相关的标准,包括但不仅限于生产标准、研发标准、数据开发标准、使用标准、数据安全标准等;

 

  • 应用牵引:即业务需要什么,就治理什么,紧跟业务的诉求,开展端到端的数据治理。(端到端,即从数据产生的业务系统到最后数据使用场景,如报表/数据应用等)

 

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

 

  • 第一个是数据治理委员会,负责公司数据治理项目的决策;

 

  • 第二个是技术架构委员会,负责生产的系统架构,包括生产的在线业务和大数据侧离线业务,进行协同统一;

 

  • 第三个是治理实施项目组,不建议通过那种虚拟组织的形式来组建,而是需要把公司的数据开发人员全部归拢到一起,集中力量办大事。

 

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

 

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

 

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

 

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

 

二、数据治理实践思考

 

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

 

 

1、数据链路侧:核心数据链路治理

 

图片

 

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

 

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

 

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

 

 

2、计算引擎侧:计算引擎升级与小文件治理

 

图片

 

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

 

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

 

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

 

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

 

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

 

 

3、大数据产品侧:落地规范,释放效益

 

图片

 

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

 

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

 

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

 

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

 

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

 

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

 

 

4、实践案例-标签数据链路治理实践

 

图片

 

翼支付有大概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进行字段扩展。(原有全量更新可以走删表-建表方式自动化处理)

 

三、未来展望

 

图片

 

 

1、数据治理常态化

 

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

 

 

2、生产数据标准统一

 

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

 

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

 

 

3、数据智能化应用

 

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

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告