• 作者:老汪软件技巧
  • 发表时间:2024-11-21 17:02
  • 浏览量:

京东零售在数据管理和治理上面临着多方面的挑战:首先,数据量的持续增加导致了大量低效及冗余的数据模型,增加了维护成本并影响数据质量和准确性,用户找表难,用表难;其次,数据管理和开发使用相同账号资源,缺乏有效的变更管理,容易因误操作引起线上问题;再次,表数量和存储规模的增大,进一步加剧了计算、存储资源消耗。面对这些挑战,京东零售提出了一套全面的数据治理方案,包括建立数据标准、优化数据架构、规范数据开发流程和控制数据成本等措施,旨在通过技术手段提高数据管理的效率和效果,促进企业的数据高效运转。

01

数据管理挑战

图片

编辑

京东零售数据管理存在以下四大痛点:

1. 资产感知弱

2. 数据架构不敏捷

3. 开发质量、安全问题

4. IT 资源成本不断攀升

因此,有必要加强数据治理,让数据有序可管,从而保证企业数据管理高效运转。

02

数据治理体系建设

1. 数据治理思路

图片

编辑

数据治理的整体思路是,从数据标准、数据架构、数据开发以及数据成本多方面着手,用技术去牵引数据全链路的降本增效。具体体现在以下几个方面:

2. 数据治理体系建设

图片

编辑

(1)标准治理

在数据治理体系建设中,首先是数据标准的治理。

京东零售制定并发布了零售统一数据语言标准,该标准定义了数据模型的标准要素,包括业务体系、业务域、主题、业务过程、主体、主体属性、更新周期/频率、更新方式、粒度等,数据模型通过标准要素进行描述刻画。

首先,基于该标准进行数据资产认证,对质量高、价值大的模型进行认证打标,逐步形成统一的资产目录,方便用户查找和使用;而对于质量差、价值低的模型,关停并转,释放资源。

其次,将标准要素系统化,提升维度和指标的注册效率,在开发和治理的同时实现表元信息的收集,为后续逻辑建模、系统智能巡表、智能生产做准备。

(2)架构治理

接下来是架构的治理,其核心是让架构更敏捷。

首先,基于逻辑虚拟表进行维度建模能力升级,相对物理宽表,逻辑宽表从语义上定义了数据模式,并将数据模型抽象为维度和指标,更加敏捷,大大减少后续的改动工作量。

逻辑宽表虽然方便定义,但面对大量数据,通常难以达到和物理宽表相当的查询性能和访问体验,这就需要智能物化的能力;因此系统需要基于 HBO、CBO 以及 RBO 等优化模型对分析路径进行自动决策和优化,如哪些需要提前物化,哪些无需物化;相比传统研发人员手动建表建任务,这种系统自动物化的方案节省了大量人力成本和 IT 成本。

另外,京东零售作为电商企业,用户行为大多在线上发生,有大量的数据需要处理、分析;近期在探索湖仓一体架构,利用增量状态更新和流批一体能力,提升数据处理效率,降低数据成本。

(3)开发治理

通过构建开发生产隔离能力,将账号、表、队列资源进行隔离,保障数据安全生产。

(4)资源治理

资源治理的手段主要包括存储治理和计算治理。其中存储治理包括表生命周期治理,无效表/相似表的识别与下线,转 EC、数据重分布与压缩等;计算治理包括无效任务识别与下线,低资源利用率任务治理,暴力扫描、高频失败任务治理等,以及计算算子和引擎的优化,还有计算任务错峰执行等。

各类优化治理的手段其实是相似的,但是如何让治理变得高效、安全、可持续,让用户“敢治、愿治”,是一件非常有挑战性的事情。因此我们的思路是对主动元数据进行充分挖掘,构建治理模型,并将治理可视化,让数据治理有依据有章法。

具体来讲,首先是元数据建设能力。元数据主要包括表分区存储、计算成本以及任务执行内存、CPU 利用率,分区访问等数据生产消费血缘,以及资产认证、任务等级、应用场景等元数据。在这些元数据的基础上,构建诸如智能生命周期推荐、模型识重、任务归属识别等模型,自动识别治理空间并给出相应治理建议。相比人工逐一评估,更高效客观,且可持续。最后建立了一套面向管理者、推动者、治理者的可视化看板,帮助用户看清资源分布以及治理成果、待解决问题等。在 23 年存算治理中超额完成了治理目标,同时该体系能够让整个治理活动持续的运营下去。

03

主动元数据治理实践

接下来通过两个案例介绍基于主动元数据的治理实践和探索。

1. 主动元数据

(1)什么是主动元数据?

Gartner 对主动元数据的定义是:一组能够持续访问、处理和分析的元数据的功能。因此,主动元数据的特点是:自动生成与更新,支持持续访问。在此基础上构建智能分析、形成决策建议,指导行动。

图片

编辑

因此,在系统设计和运行过程中,收集元数据,利用运行时元数据与设计元数据进行对比,进而不断积累并信任元数据;最后,利用元数据在环境发生变更时,给出预警和建议,让用户及时做出反应。

(2)主动元数据管理工具核心能力

Gardener 在提出主动元数据这一概念的同时,也指出主动元数据管理工具应具备的能力,包括聚类分析、诊断资源分配、告警、推荐等。Gardener 的这一观点指引京东零售数据治理实践的方向。

编辑

接下来通过案例分享如何将主动元数据应用在数据治理能力建设上,基于主动元数据,构建智能生命周期评估体系。

2. 存储治理的挑战

存储治理存在以下挑战:

(1)盲治

(2)不敢治,不愿治

(3)不能治

因此不论从治理推动者还是从治理者的角度来看,都迫切需要一套方案机制,保证治理工作有数据支撑,且客观公正,能够直接给出治理建议,并支持自助分析,且具备持续性。

存储治理的能力诉求包括:

图片

编辑

因此,提出了基于主动元数据构建智能生命周期评估体系。

3. 智能生命周期评估体系建设

这里所说的生命周期是狭义的生命周期,是指一个表分区数据从写入到被删除经过了多长时间;例如某个表的生命周期是 100,意味着这份数据写入到某个分区后,100 天之后会被清除。

生命周期评估体系的建设,首先要构建代价模型,其核心是将数据的计算成本看作生产数据的“代价”,将数据的存储成本看作拥有”成本”,将两者的比值作为代价均衡系数,计算每个模型在每个分区的访问次数,两者的交点即为代价的均衡点,即为最理想的生命周期值。

此外,在实际模型构建中,还考虑模型所属分层、是否精选、认证、任务等级、加工时长等因素,在均衡的基础上,通过容忍系数使推荐的生命周期值更稳定、更符合业务场景,最终得到推荐的生命周期值。

图片

编辑

智能数据构建与管理__数据治理体系建设的核心领域

下图是生命周期推荐模型的可视化拆解,可以帮助用户进行自助式分析。

编辑

(1)基于代价的智能生命周期评估体系

(2)生命周期评估模型可视化拆解

4. 智能生命周期消费模式识别提升

假如直接统计一张表在一段时间分区访问的范围,则统计结果会严重受到考察周期的影响。举一个例子,假设一个表有 10 个访问,每天都是访问昨天分区;当选择 15 天作为考察周期时,得到的结果是用户需要访问近 15 天的数据;而当选择 31 天作为考察周期时,则会得到用户需要访问近 31 天数据这一结果。为了消除这类干扰,选择统计表分区访问时间与分区的生成时间的差值,即偏移天数来统计访问次数。

经验证,使用这种统计方案,选择不同偏移天数得出的结果差异很小。考虑到治理的及时性,最终选择通过近 90 天的访问信息来计算均衡天数。

图片

编辑

5. 智能生命周期产品化

由于其在识别消费模式准确度上表现优异,能够极致地挖掘治理空间,并且是基于主动的、客观的元数据自动计算得到的,非常容易复用到其他 BG、BU。在完成 POC 的试点验证后,将方案集成到大数据平台。

(1)业务策略与平台共建

图片

编辑

(2)看得清、看得全

(3)一键式治理

(4)自主挖掘治理模型

6. 智能生命周期建设效果

目前大数据平台已经构建了完善的治理功能体系,包括治理分析能力和治理实施能力。治理实施包括治理行动、通知催办、一键回滚等功能,这些功能可以大幅提升操作的效率及治理安全。将业务治理策略通过平台化工具进行整合共建,将治理经验推广到整个京东集团,赋能整个集团的存储治理。

数据驱动、智能推荐,从分散到集约、从被动到主动、从经验到智能。

图片

编辑

该方案将分散在各处的主动元数据进行收集,对元数据进行挖掘识别,实现生命周期的智能推荐。由于使用主动元数据,采用同一套评估体系,因此其依据是清晰的、客观的;同时支持治理模型可视化,方便查看分区及访问明细、数据生产代价等,精准的模式识别结合平台安全回滚机制,让治理更安全、更有效。

当前能够对几十万张模型实现自动评估生命周期值,并识别出数百 PB的治理空间,推荐的生命周期值接受度大于 70%。同时,在前期试点过程中,已经完成了一百多 PB 的存储治理,每年为公司节省数千万元。

由于该体系基于主动元数据,因此能够持续、动态地推荐合理的生命周期。因此从更长的生命周期来看,数据从创建到成熟,再到最后的逐步衰退直到淘汰,我们的体系能够动态更新模型的生命周期值,同时通过能力开放,这套能力未来能为公司带来更大的价值。

7. 数据回填挑战

接下来分享另外一个基于主动元数据的治理实践——数据回填。

在离线数据开发运营中,不管是新需求迭代,还是岗位变更,都会有数据重算的需求。目前的数据补录功能尚不完善,需要手工确认等大量系统外协调工作。例如,用户需要回溯 2023 年前的数据,研发人员就需要手动检查所依赖的上游甚至更上游的数据;确认完上游数据,需要进行数据回刷,完成后再通知下游。因此,整个过程是环环相扣的,需要很多人参与沟通和衔接,不仅耗时,且效率低、易出错。

同时,很多场景直接使用线上脚本进行回溯;当业务数据远小于维表时,例如业务表每天数据量级为千万级,而需要关联的维表(如商品表)则是百亿的量级;如果按天回溯,则需要关联这个商品表超过 300 次;而反复关联会浪费大量的资源,并影响数据回溯并发度。据统计,回刷计算的资源消耗占部门计算资源消耗的 18%。

因此,考虑将上述人工确认的过程自动化,让用户只关注结果而无需关注过程,同时能够对回溯脚本进行自动优化和改写,减少大量维表的关联次数,更高效地完成数据回填。因此需要构建更高效的自动重算能力。

图片

编辑

8. 智能回填方案架构

图片

编辑

上图是数据回填的架构图,主要基于数据的生产血缘,包括表依赖血缘、任务依赖血缘等。

该方案主要包括以下几个功能模块:

该方案的核心思路是充分挖掘数据生产消费血缘,依据血缘进行自动检查和确认,从而替代手工检查,提升回填效率;该项能力的依赖项是需要算子级的数据血缘能力。目前平台已经具备此能力,同时依据任务执行元数据进行多分区合并,并提交批次,大幅降低资源消耗,使用户从关注过程到仅关注结果,把更多的时间放在有价值的事情上。目前该方案正在建设中,预计今年 Q2 上线。

04

总结与未来展望

1. 总结

前文的分享主要包括以下 3 部分:

(1)基于主动元数据的 Data Fabric 治理能力建设

(2)基于数据血缘的智能回填

(3)逻辑建模、智能物化与生产

以上都离不开主动元数据,离不开对主动元数据的充分挖掘与分析。

图片

编辑

对于 data fabric 架构,最先由 Gartner 提出,主要是为了解决复杂数据的管理和使用问题,并且连续几年被评为十大 IT 技术发展趋势。Data fabric 架构主要包括在互联的知识图谱上访问和表示所有类型元数据,应用知识图谱技术激活元数据,将机器学习技术运用到元数据上,去简化数据集成设计、动态数据集成以及数据编排等;其中涉及的核心技术主要包括数据虚拟化、语义知识图谱以及主动元数据等。Data fabric 更多是一种架构理念,而非一种新的技术,因此每个个人或企业都可以去探索和实践 data fabric 架构,从内部实践效果来看,无论在数据治理上,还是在数据集成编排上,都取得了良好的效果。

核心技术:数据虚拟化、语义知识图谱、主动元数据

2. 未来展望

图片

编辑

最后是对未来的展望。当前对基于主动元数据的探索和实践尚处于起步阶段,未来将持续进行探索。

首先是更自动、更智能。当前的数据任务优化仍然由人工来逐一优化治理,不仅耗时,也依赖人工经验;所以需要基于主动元数据来构建任务的智能诊断与智能调优能力,提升任务的优化效率。

此外,对于前文提到的数据模型认证。当前的认证主要依靠人工逐一认证,认证工作量非常大;而且数据会不断地新增和变更,需要持续投入大量精力。因此,需要探索语义实体识别以及图挖掘技术,去构建更智能的资产图谱,提升资产认证效率,实现从“人找资产”到“资产找人”的转变。

另一个探索是如何将治理经验沉淀出来,将其系统化,实现开发即治理。2023 年是人工智能元年,人工智能创新正在逐渐转化为实际生产力,基于人工智能的数据架构能力已经到来。希望通过今天的分享,抛砖引玉,能够对大家有一些思考和启发。以上就是我的分享,谢谢大家。

05

Q&A

Q1 :元数据是数据的数据,在数据治理的过程中承担怎样的角色?在数据治理的过程中,对开发工程师来说,最大的挑战是什么?

A1:在数据开发或者治理过程中,更多指的是数据加工的存储成本、计算成本,以及执行信息等。在数据治理过程中,元数据承担了非常基础、非常核心的能力。例如当数据存储资源告警时,会通知用户去做数据生命周期治理,然而数据研发工程师拿到数据表时,不知道从什么地方入手,也不知道如何评估该生命周期值设置多少合适。早期往往是基于一些规则(比如原始数据永久保留,通用层保留五年,应用层保留两年等等)来制定,而这种方法带来的弊端,就是会产生很多的冷僵尸数据。因此,元数据相当于粮草,基于元数据去做分析模型,构建生命周期的评估体系;通过对元数据的挖掘,实现更高效的数据治理。而在治理过程中,对于数据治理实施者,最大的挑战包括两点,第一是不知道如何治理,设置多少合适,第二是没有时间,担心风险,所以缺乏治理的意愿。如我们构建的这些治理能力,旨在去帮助数据的开发工程师和数据治理实施者,更快速、安全地完成各项治理。

Q2 :主动元数据的约束是什么?(被动元数据相对理解,收到解析即可)对于主动元数据,其规范约束性强吗?推动力如何?

A2:不管是被动元数据还是主动元数据,都有一个前提,即数据是准确可信的。由于被动元数据往往是人工收集的,已经经过了审核和验证;而主动元数据往往是系统自动生成的,因此其准确度是个非常重要的约束。包括最初做生命周期推荐时,很多信息是不完善的,因此首先联合平台提升元数据的准确性,随后才能放心地开展基于元数据的分析和推荐,否则系统可能会错误推荐,准确性差。对于推动力如何,作为零售数仓的主要建设方,很多数据需要全部保留,因此治理压力很大,必须在治理模型上进行极致的挖掘,所以引入了更严格的代价模型;在推动前期是有很大阻力,但是从去年 Q2 开始启动、Q3 开始试点,到了 Q4 在整个京东集团推广,整体上的治理效果还是比较理想的;在试点过程中,完成了超过 100PB 数据的治理,并联平台共建,平台有非常好的通知机制,支持催办、恢复等功能。