货拉拉大数据元数据控制体系演进和通常

一、元数据控制平台引见

首先来引见一下货拉拉大数据体系的全体架构，这一体系自底向上构建，其中基础层与接入层，这两层关键承载着最基础的存储才干、计算才干以及数据接入性能。向上是平台和数仓层，这里集成了数据研发平台、数据控制平台，以及数据资产控制。再向上是服务层，这层面向多样化服务场景，开发的大数据一系列运行，涵盖数据运行撑持、各类服待业具、数据服待业具，以及数据智能所需的撑持工具。最下层是运行层，汇集了辅佐决策类运行和赋能业务类运行，它们直接服务于公司的决策制订与业务优化。整个大数据体系中出现出一种相互依存、相互支持的严密相关。

本次分享的重点是元数据控制平台，该平台作为大数据体系的元数据中心，其外围职责涵盖了元数据控制、数据资产控制以及老本控制三慷慨面。

当大数据体系开展到肯定规模时，肯定会遇到一系列应战，例如：所需数据终究在何处？如何明晰梳理这些数据之间的高低游相关？数据控制靠什么来驱动？以及数据资产是如何控制的？为处置这些难题，元数据控制平台应运而生。接上去将重点围绕这四个外围议题，引见货拉拉针对这些疑问所制订的处置打算及通常阅历。经过这些内容，您将愈加片面地了解咱们如何应用元数据控制平台来保证数据的可寻、可溯、可治，进而优化数据的价值。

3. 元数据控制平台树立环节

元数据控制平台的开展轨迹严密贴合业务需求的演进，其开展历程可以划分为三个阶段。

早期（21 年之前） ：在这一期间，业务场景相对繁难，数据资产的规模也不大，关键依赖 Hive ETL 工具启动处置。因此，关于元数据的需求也逗留在基础层面，繁难的查问性能便足以满足业务需求。

开展阶段（21 年至 22 年） ：随着业务的迅猛增长，数据表和义务的资产规模急剧扩张，用户对“找数”和“找相关”的需求日益凸显。为应答这一变动，咱们构建了元数据控制系统，支持经过资产称号和形容消息启动搜查，还支持了数据血统才干。

成熟阶段（22 年之后） ：在这一阶段，大数据畛域的开源组件与自研平台纷繁退场，元数据控制平台须要承接更多种类的资产类型，并应答更为复杂且时效性要求更高的数据血统链路。为此，咱们更新了元数据控制平台，成功了字段级别的实时血统追踪才干，以满足上述需求。同时，面对存储与计算资源的弛缓，老本控制体系也提上日程。此外，随着资产量的剧增和研发团队的扩展，找数场景也越来越复杂，咱们联合大模型将检索才干演进为 AI 智能检索，提供了对话式的找数体验。

开展到现阶段，元数据控制平台的才干趋近于完善。

4. 元数据控制平台系统架构

元数据控制平台的系统架构如上图所示，其外围由采集层、服务层、存储层以及平台数仓层形成。在此架构的两侧，区分对接了多元化的接入方和丰盛的运行层。

接入方： 涵盖了大数据生态中的基础设备、各类平台工具以及业务系统，它们是元数据控制平台数据起源的基石。

采集层： 作为架构中的关键一环，采集层担任适配并对接消费方，采集各类元数据。

服务层： 该层提供了查问与剖析的服务。

平台数仓层： 平台数仓层专一于加工与老本控制相关的数据。经过对底层计算与存储资源的消耗数据的深度开掘与剖析，为企业的老本控制和控制决策提供有力支持。

运行层： 最终，这一架构撑持起了一系列运行场景，包括但不限于找数、找相关、资产控制等。这些运行充沛应用了元数据控制平台的才干，为用户提供方便、高效的数据服务体验。

二、元数据控制平台通常

数据血统作为元数据基础设备中的外围因素，其成功与演进环节至关关键。上方，我将详细论述咱们是如何构建和不时完善这一关键环节的。

首先，从微观视角来看，咱们的数据全体链路明晰地划分为采集、存储、计算以及运行四大层面。这一流程始于数据采集阶段，咱们采集来自日志、埋点以及订单业务等多个维度的数据，并将这些数据会聚至大数据平台。

随后，这些数据被妥善存储在大数据平台中，为后续的处置与剖析奠定松软基础。而后经过实时和离线链路区分构建的数仓体系，对数据启动加工处置，加工好的数据提供应各类运行服务启动经常使用，比如各类报表、看板、用户画像等。这些运行附丽高品质的数据支持，为企业决策提供了有力依据。

在这个环节中，数据血统链路贯通一直，它详尽地记载了抢先数据从采集、存储、加工到最终运行于进口的每一个环节。这种片面的血统追踪才干不只要助于咱们更好地理解数据的前因结果，还能在数据出现疑问时迅速定位疑问源头，从而保证数据的品质与准确性。

在早期（1.0 版本），咱们的业务场景较为繁难，血统相关的需求也相对基础。因此咱们构建了一个基础的血统追踪系统。

随着血统才干在研发场景中的价值逐渐被认可，咱们对系统提出了更高的要求，特意是血统的时效性和字段级血统的支持。为此，咱们在 1.0 版本的基础上对系统架构启动了优化和更新。

经过上述更新，咱们的血统追踪系统不只优化了数据的时效性和准确性，还大大增强了处置复杂血统相关的才干，为研发场景提供了更为弱小的支持。

在业界关键有两种设计思绪。第一种打算是将义务作为节点，经过这些节点来关联不同表之间的相关。这种方式在触及以义务为切入点启动血统查问时愈加灵敏。但是，当查问表之间的关联，尤其是须要启动多层表相关查问时，这种打算或许会参与查问和保养的复杂度，尤其是在节点数量较多的状况下。

相比之下，第二种打算将义务作为边的属性，而表和表之间则树立直接的关联。这种设计在查问和保养方面更为直观和简便。思索到咱们的实践业务需求中，暂时没有须要经过义务作为切入点启动查问的场景，咱们选择采用第二种打算作为成功方式。这样做不只简化了查问门路，还优化了系统的保养效率，更贴合咱们的业务需求。

接上去是血统的解析，目前咱们以 Hive 作为主引擎，因此接上去关键解说 Hive 类的血统解析方式。

在咱们开发平台中，Hive 义务方式多样，包括纯 SQL、Python 程序及脚本类义务，这参与了解析的复杂性。

，业界关键讨论两种解析方法：一是经过 Hive hook 成功，即在义务口头时从 Hive hook 的高低文中捕捉输入输入消息，这种方式无需关心 SQL 的提交方式，但或许存在滞后，由于血统的更新仅在义务口头后才干失效；另一种是静态 SQL 解析，普通应用开源的语法解析工具在义务提交行启动，虽能即时反映 SQL 变卦，但对 Python 或脚转义务的 SQL 提取较为复杂。

因此综合思索背景和成功复杂度，咱们选用了 Hive hook 作为成功方式。

但是，这一环节中也面临了几个应战：

①血统与义务相关买通：由于 Hive hook 自身不可直接失掉义务消息，咱们推进研发平台启动了革新，要求在提交 SQL 时将义务消息一并放入 hiveConf 中，以便在 hook 中能够关联这些消息并传递给下游系统经常使用。

②义务更新与血统同步：为确保血统消息的时效性，咱们采用了研发平台被动上报义务下线和更新的机制。这样，当下线或更新义务时，相应的血统消息也会失掉及时更新。

③暂时表处置：关于蕴含暂时表的 SQL，如 CREATE TEMPORARY TABLE T1 AS SELECT ... FROM a; INSERT INTO b SELECT * FROM T1;，直接解析会发生不用要的暂季节点和相关，影响后续经常使用。因此，咱们在成功中引入了一个缓存机制，构建血统相关树，并在新血统来到时启动兼并判别。只要当暂时表的经常使用能够兼并为正式表之间的直接血统相关时（如 a 写 b），才会启动下一步的对比、更新和入库操作。

经过这些措施，咱们成功成功了基于 Hive hook 的血统解析，既满足了业务需求，又有效处置了实施环节中遇到的疑问。

在数据运行方面，咱们聚焦于三个外围场景：数据开发效率优化、数仓开发优化、以及数据控制与安保保证。

这里罗列了大数据清晨值班时，链路出疑问，须要升级，数据血统才干在外面起到的一些作用。

在大数据值班的场景中，偶然会遇到链路缺点，造成某些关键数据表当日的数据不可按时产出。此时，为了保证数据供应的延续性，或许须要启动升级处置，比如经常使用前一日（T+2）的数据作为代替。但是，这一决策并非草率之举，它要求迅速评价升级操作对下游数据经常使用方的详细影响范围，并据此做出及时通知。

在这一紧急照应环节中，字段级的数据血统才干显得尤为关键。它能够直接追溯到受影响的最下游终端，特意是那些标志为 P0 或 P1 优先级的数据进口运行，协助值班人员极速、准确地评价影响面。这种才干不只优化了决策的效率和准确性，还有效防止了影响范围的扩展或因升级不当而引发的潜在缺点，乃至经济损失。

此外，为了减速消息传递，咱们还提供了一键拉群性能，使得值班人员能够迅速将相关团队和人员拉入紧急沟通群组，成功疑问的即时通报与协同处置。

在深化讨论了数据血统的关键性之后，接上去将引见咱们的元数据检索系统的演进环节。后来，咱们采用的是传统的基于关键字的检索方式，这种方式以其极速照应和直接前往婚配结果集列表的特点，满足了基本的检索需求。但是，随着数据经常使用场景的日益多样化，用户对检索性能的需求也变得愈加复杂和精细。

详细而言，传统的关键字检索在面对多关键字组合查问、查问数据表含意、征询数据口径以及业务咨询等场景时，显得力所能及。这些需求要求检索系统能够更深档次地理解用户的查问用意，并前往愈加精准和片面的结果。

为了应答这些应战，咱们紧跟技术开展的步调，特意是在 AIGC（人工智能生成内容）技术蓬勃开展的背景下，咱们探求性地将大模型的人造言语处置才干引入到了元数据检索的实践消费场景中。这一翻新动作旨在经过大模型对人造言语的深入了解，来更好地捕捉用户的查问用意，从而提供愈加智能化、共性化的检索服务，以满足用户多样化的需求。

为了应答大模型在实践企业运行中面临的本地常识库匮乏及更新时效性疑问，咱们选用了业界宽泛采用的 RAG（Retrieval-Augmented Generation）打算来落地元数据检索场景。

RAG 打算的外围在于，它不只仅依赖于大模型自身训练时失掉的静态常识（这通常关键起源于互联网上的地下消息，且难以实时更新），而是经过引入外部数据源的检索机制，为大模型提供实时的高低文消息。这一机制准许大模型在回答企业专业畛域的疑问时，能够联合最新的、特定于企业的数据，从而大大优化了答案的准确性和时效性。

详细来说，RAG 打算首先会应用检索技术从外部数据源中检索与用户查问相关的高低文消息，而后将这些消息与用户的原始查问一同输入到大模型中。大模型在接纳到这些消息后，会综合思索检索到的高低文内容和自身的常识库，生成愈加精准、片面的回答。这种方式不只处置了大模型在本地常识库上的局限性，还防止了因直接暴露企业外部数据给大模型而或许引发的数据安保疑问。

因此，经过采用 RAG 打算，咱们能够更好地将大模型的人造言语处置才干运行于企业的实践消费场景中，为用户提供愈加智能、高效的元数据检索服务。

在 RAG 打算的成功中，咱们的两边服务层（rag）聚焦于四大外围流程：数据提取、检索、索引与生成。首先，业务常识被接入并分块处置，随后灌入向量数据库中，以便启动高效的向量相似度检索。检索结果随后被送入大模型，联合定制的 prompt 生成最终照应。模型层则灵敏适配多种模型，支持找数、口径查问、业务咨询等多样化场景。

针对库表源数据的检索，咱们采用的切片战略，是以单个字段为单位启动切割。这种方式确保每个字段独立成块，并在块中保管必要的表消息，优化向量数据库中的存储与检索效率。相较于整表切割，字段级切片有效防止了检索结果超出大模型处置 token 限度的疑问。

问答流程简述如下：用户疑问首先经过增强处置，并转化为向量化表示；随后经过检索系统失掉相关结果，并启动智能重排序；优化后的检索结果联合 prompt 工程启动精细组装，最终由大模型生成准确答案。这一环节确保了问答系统的高效、准确与灵敏性。

在成功环节中，咱们遭逢了检索漏召、大模型体现不稳固、照应速度慢及测评难题等应战。针对这些疑问，咱们采取了以下优化措施：

树立更完善的测评体系，包括智能化测试和人工查看，确保系统性能与用户体验继续优化。

此外，咱们意识到最终体现效果还遭究竟层常识完备率的影响，因此增强与数仓等部门的协作，独特构建和完善专业常识库，为系统提供松软的数据撑持。

这是咱们上线的一版库表智能检索产品的示用意。用户提出查问需求，寻觅特定字段消息。系统首先应用大模型启动智能总结回答，直接出现给用户一个概括性的结果。随后，系统进一步开掘并展现与该字段相婚配或相关的库表消息，以满足用户的深化查问需求。

在讨论货拉大数据老本控制面临的应战时，咱们留意到，未经有效控制前，老本与单均老本均出现极速下跌趋向，且不足有效管控手腕。详细而言，存在三大疑问：一是老本调配不明，难以追踪至详细资产及责任人；二是老本经常使用效率存疑，能否存在糜费现象难以评价；三是老本水位肥壮状况含糊，不足明晰判别规范。

为应答上述应战，咱们构建了大数据老本控制体系，该体系以元数据为外围驱能源，经过以下战略成功继续降本：

数据资产度量体系旨在量化大数据资产的消耗与老本，并提供弱小的查问与统计剖析性能。以下是该体系的框架概述：

咱们聚焦于义务产出的外围资产，如表、报表、看板目的等，从底层存储与计算引擎精准采集其消耗数据。这些数据随后经过平台数仓的精细加工，转化为按团体及部门维度划分的老本数据，经常使用户能直观了解各自名下资产的消耗状况。

此外，系统还能智能生成部门级别的老本账单，为资源优化、义务调度优化、存储控制及老本运营等关键场景提供松软的数据撑持，助力企业成功愈加精准与高效的老本控制。

第二局部聚焦于辅佐控制才干，特意针对货拉拉大数据中占据主导位置的离线存储老本。鉴于大数据环境中普遍存在的“冰数据”现象，即少量数据虽占用资源却鲜少被访问，咱们努力于优化存储效率。

首先，咱们面对的应战在于如何界定冷热数据，因业界规范不一且难以直接套用于我司业务。为此，咱们自创了美团的数据分类方法（基于 90 天内访问频次），并联合云厂商的归档存储费用模型，启动了深化的剖析与调整。

经过剖析最近 90 天内的数据访问次数与归档收益的相关，咱们发现访问次数为 0的数据占比最高且归档收益清楚，而访问次数极少的数据归档收益则相对较低。基于这一发现，咱们制订了数据温度的打标战略，将数据明白划分为不同热度等级。

针对不同温度的数据，实施差异化的控制措施：关于冰数据（常年未访问的数据），倡导用户优先删除以监禁存储资源；关于冷数据（偶然被访问的数据），则介绍用户启动归档处置，以平衡存储老本与数据可访问性。这一战略旨在最大化存储效益，缩小不用要的资源糜费。

通常上，数据随期间推移会逐渐失去生动性，即“冷却”。为此，咱们为数据表设定了生命周期与归档周期两大属性，以成功对超出特定存活期限数据的智能化滚动清算与归档。在图示中，该表的生命周期被设定为180 天，归档周期为 90 天。这象征着，超越 180 天的数据将被系统删除以监禁资源，而介于 90 天至 180 天之间的数据则会被智能归档至更低老本的存储介质中。

前述技术辅佐才干为业务老本控制提供了有力支持，但要激起业务团队的被动介入，还需构建一套完善的老本运营才干。该体系能够智能侦测数据资产在计算与存储层面的老本糜费疑问，生成控制点并即时通知相关用户，促其采取被动控制措施。控制点涵盖未性能生命周期的存储与计算资源、未归档的冗余数据、常年未访问的数据或义务等。

联合老本消耗数据，咱们设计了一套肥壮分模型，以量化评价控制效果。此模型不只为团体及部门提供老本肥壮形态的直观展现，还辅以奖惩机制与红黑榜排名，处罚用户继续优化存储与计算老本，独特保养老本水位处于肥壮形态。图示展现了资产肥壮分的评价结果，涵盖团体与部门两个维度，以及控制效果的排行榜，确保每位用户及其指导层都能及时取得反应，独特推进老本控制上班的深化启动。

经过一系列存储优化战略的实施，包括生命周期控制、数据归档、文件紧缩、格局算法更新以及深度专项控制等，咱们取得了清楚的功效。上图展现了存储老本的优化成绩：在优化前，存储老本出现极速线性增长趋向；而优化后，存储老本在八个月内成功了零增长，并继续走低，累计节俭了高达 54% 的存储老本，功效颇为可观。

元数据服务离不开分级打标，分级关键是法律法规的要求，二是权限控制的须要，三是繁难控制与审计，这方面的上班会借助安保定级系统，由其担任对元数据启动分类定级打标，打标成功后会针对 C4 以上的团体敏感消息启动消息加密并打标以成功敏感的管控，降落数据暴露的危险。

元数据作为数据控制平台的底层基座，撑持库表安保和数据下载两大安保运行场景。

数据的分类分级规范与规范

数据的分类分级联合了公司的业务场景，关键从数据的敏理性与价值性登程，同时参考了金融数据安保分类分级规范《金融数据安保数据安保分级指南》，将货拉拉的数据安保等级分为四大等级：

库表的分类分级分为增量数据与存量数据，二者类别采用不同的分级达标打算；

针对算法打标的误判，也支持人工批改，关键由有安保阅历的安保人员来启动判别并批改。

分类分级在库表的详细运行场景，货拉拉采用依照人员类别以及入职天数放开不同权限的数据安保战略。

针对以下的情景采用不同的安保权限战略：

限度人员若须要放开相应库表权限，需经过邮件放开白名单。在详细的库表审批方面，会针对 C3、C4 敏感等级数据智能启动标红处置，提示审批人员对此局部数据的权限启动愈加严厉的审批，确保权限不会被错误授权。

加密字段打标打算关键依赖于元数据服务和数据研发平台。

经过元数据服务会设置定时义务定时扫描敏感数据，像扫描到 C3、C4 数据，会启动 select列 from 表 limit 多少条数据 后口头 SQL 查问，前往失掉这些样例数据，而后依据数据的规定启动打标，详细的达标规定会对数据启动长度检测和字符规定检测。

经过自研的数据研发平台，口头 SQL 查问，后盾解析此 SQL 查问蕴含哪些表、哪一些字段，后向元数据服务放开调用失掉相关的元数据，后经过数据研发平台查问此局部数据的 Hive 结果。若须要下载，会依据元数据的加密以及敏感等级走不同的审批流。

详细的审批战略针对敏感数据和非敏感数据采用不同的方式：

加密打标的运行场景：数据下载。

数据下载需走审批程序，针对 C3、C4 敏感数据的下载，会有敏感数据下载标识启动提示，数据下载概略里会有解析到的敏感字段，如表名、字段名、注释等，以供应审批人员参考。针对一些特意敏感的团体消息而且量多的情景，此时安保人员会找放开人员启动核查，以确保数据可以下载。

数据安保更多的运行场景：

未来的布局与树立重点包括更高效的检索服务、数据血统的规范化以及降本增效三个方面。