一、电商目的体系树立背景
首先，在第一个章节中，会引见电商业务的全体状况，在此基础上讨论为什么电商业务须要一个目的平台，其对电商业务的关键性，并将深化剖析电商业务须要一个什么样的目的平台。
电商业务的开展阅历了三个阶段：探求期、生常年和稳固期。
在探求期，我们迅速迭代，以业务为导向，关键目的是极速适配业务调整，寻觅稳固的业务增长形式。进入生常年，我们开局器重数据消费的效率和品质，努力将数据积淀成体系，规范化地、高效、高品质地为业务提供允许。这一期间，数据产品丰盛多样，针对不同数据域和场景降生了多种数据产品。目前，我们处于稳固期，**谋求是数据的多元化才干，希冀每份数据能服务更多场景，并提供更规范、正当有效的数据方案。
在这三个期间中，如何在数据开发环节中谋求更高的品质和效率，一直是我们最关注的课题。
在我们的电商业务中，数据仓库表演着关键角色，服务于多种外部和外部业务系统。对内，数仓允许运营、剖析、产品控制和 DA 等多个角色的需求，这些角色散布在不同的业务线，如供应链、商品、买卖等十余个至二十个数据域。每个数据域不只为下游的目的提供数据，还服务于各种外部数据产品、BI 剖析工具、AB 试验和其余数据平台。
对外，数仓的运行愈加宽泛，服务于买家、卖家、主播审核等多种角色，并允许供应链广告等多个业务系统。这些系统又进一步对接更少数据产品和数据剖析形式，例如上图中的电商罗盘。
我们的电商业务数据具备三大特点：一是内外用户的多角色性，外部有多个团队，外部服务数千万商家；二是产品外形的多样性，无论是外部还是外部，都有多种类型的数据产品；三是这些数据产品运行的场景极为丰盛。
随着电商业务的一直开展，我们意识到提高数据品质和效率是关键应战。在这个环节中，我们遇到了三个关键难点：
综上所述，目的控制的不一致、口径的不一致以及目的消费的不一致，形成了我们在电商业务中提高数据品质和效率的三大阻碍。因此，我们的目的平台要想真正处置业务疑问，就必定针对性地处置这三个疑问。
为了处置上述三大疑问，目的平台须要满足以下六大要求：
我们的目的是应用目的平台在电商业务中成功消费促成消费，消费再反应促成消费的闭环才干。这样的良性循环将确保目的平台在电商业务中的价值，使其能够继续、有效地运转。
为了处置上述疑问，我们设计了一特性能完全的目的平台，其架构从基础元素层到目的定义、模型绑定，再到对下游的消费允许。在基础元素层，驳回了业界通用的元素，如数据域、期间周期、润色词等，这些是数据或目的控制方法论中的基础构件。
基于这些元素，构建了目的定义层，经常使用原子构建和衍生四则运算等规范方法。定义成功后，目的须要与模型绑定，这样就可以失掉目的的取数消息。模型绑定后，便能够对接外部的 BI 平台或业务数据平台，启动目的的一致消费。
为了便于业务灵敏方便地消费数据，我们还提供了一种称为 MetricDSL 的一致数据服务接口。这个接口是目的平台与外部系统交互的关键工具，使得数据的失掉和经常使用愈加高效和精准。后文中将详细引见这一性能。
在引见了我们的业务背景、思索环节和处置方案之后，接上去将详细论述我们在目的消费和控制方面的方法论。我们以为，目的控制的关键在于三个因素：目的的有效拆解、一致基础数据的树立，以及目的控制角色的明白划分。
目的拆解是目的控制的**环节，我们基于七个基础元素：数据域、期间周期、润色词、目的单位、业务环节、度量和数据类型来启动。例如，关于“支付订单金额”这个目的，我们会拆解出它所属的数据域（如买卖域）、业务环节（支付举措）、度量（订复数）等消息，从而生成原子目的。进一步联合润色词和期间周期，可以构建出衍生目的，如“最近一天直播载体支付订单金额”。
我们还有一个不凡的规定，即生成业务目的。这是经过去除衍生目的和复合目的中的期间周期，创立一个更易于业务了解的目的。这样做是为了降落业务对复杂目的的了解老本，并成功业务与数仓、技术侧在目的上的隔离，但实践上它们共享相反的底层目的。
经过这种拆解方法论，处置了两个关键疑问：一是缩小了目的与维度的重复树立，处置了目的命名不一致的疑问；二是确保了一切目的的口径，包括衍生和复合目的，都直观且官网，从而降落了数仓和业务人员对目的的了解老本。
在确立了方法论之后，第二步雷同至关关键，即构建一致的数据基础。我们的数仓树立环节阅历了从基础期到生常年，再到成熟期的演化，面临着烟囱式开发的疑问。特意是在电商这样数据量大且场景复杂的畛域，一致的数据基础显得尤为关键。
我们的数仓分为三层：接入层、公共层和运行层。接入层，即 ODS 层，关键担任高效、准确地接入数据。公共层承载着 DIM、DWD 或 DWM 层的表或模型，其目的是形象和积淀通用逻辑，确保数仓的规范一致和稳固易用。运行层则间接服务于 BI 看板和详细的数据运行场景，对应于 DM 层或 APP 层，以及数据集。
基于这三层划分，我们成功了电商数据基础的构建。在此基础上，我们将目的平台的目的与不同层级的表或模型启动了绑定。接入层和公共层的表关键用于绑定原子目的，而运行层和公共层中用于实践取数和消费的表，则绑定目的平台保养的衍生目的。这些衍生目的可以经过复合构建生成对应的复合目的。
一致的数据基础树立处置了两个关键疑问：一是缩小了针对每个消费场景的烟囱式开发，提高了研发和数仓的全体消费效率；二是确保了数仓基建的明晰性和体系化运转。
在我们电商业务的通常中，目的拆解和数据基础树立的落地成果清楚。目前，电商目的库涵盖了大概 15 个数据域，每个数据域蕴含不同的模块。目的库中现有原子目的 700 个，衍生和复合目的的数量则到达了数万个。这些衍生和复合目的进一步被形象为业务目的，以便于不同角色的了解和经常使用。
从业务角度来看，业务人员关键关注的是业务目的，由于这些目的间接反映了业务的形态和趋向。而关于数仓或开发人员来说，他们则须要关注衍生和复合目的，由于这些目的是间接用于数据取数和处置的工具。经过这种形式，我们能够满足不同角色对数据的不同需求，同时也确保了数据的分歧性和准确性。
在目的的消费和控制中，角色划分与职责明白至关关键。最后接触目的平台名目时，一个经常出现的疑问是：这个目的平台究竟属于谁？它仅仅是数仓的目的平台吗？随着电商目的控制体系名目的落地和深化思索，我们逐渐意识到目的平台不应仅限于数仓经常使用，而应定位为服务于数仓、业务、剖析师、数据产品以及各业务线数仓和基础树立数仓的一切人员。
因此，目的平台的控制和服务对象应涵盖从消费到消费整个生命周期的一切角色。我们的平台性能设计旨在服务于从基建侧的数仓到实践业务团队、数据产品剖析师等全链路的角色。我们的目的是经过全角色才干的控制，成功从消费到消费的完整循环，从而促成消费和消费的良性互动。
为了使概念愈加详细，这里提供一个实践案例。在目的平台外部，有一特性能称为“目的需求注销”，它记载了从数据剖析师或数据产品提出目的需求到数仓成功目的交付的全链路生命周期。
例如，剖析师提出一个新目的需求以允许外部数据产品。他们须要在目的平台上启动注销，经过平台提供的工具成功需求注销。数仓的开发人员收到注销后，首先要审核该目的能否已存在。假设不存在，开发人员须要启动目的拆解，构建出新的目的，包括原子目的、润色词等。接着，从基建侧开局，创立模型、表，并启动模型绑定，最终交付给数据产品或剖析师。
在整个生命周期中，模型的绑定、目的分类归属、原子目的对应等每个阶段都与目的消费买通。这使得每个目的的消费环节都有迹可循，为未来成功全链路的数据追溯和优化提供了基础。
下面这张截图展现了我们产品性能的一个外部示例，详细记载了从需求注销、目的消费、审核，到消费和业务确认的完整环节。经过这个示例，我们可以明晰地看到数据从提出需求到最终运行的每一步流程。
接上去，将简明引见我们外部如何成功目的消费与消费之间的无缝对接，即所谓的消费买通才干。
为了成功目的消费与消费之间的一致和分歧性，须要树立一个一致的目的服务。在没有一致目的服务之前，我们面临了诸多应战。数仓团队须要依据业务需求创立不同的 APP 层数据运行表，并保养对应的数据服务 API。每个运行表或许对应多个 API，口径和计算逻辑保养在 API 中，服务于 BI 看板、数据产品仪表盘等下游用数场景。
但是，这种形式存在多个疑问：数据准确性难以保障，由于口径保养在不同的 API 中；口径变动时，API 难以迅速顺应；复用性目的的开发和保养老本极高；新同窗接手和了解老本高，由于复杂的目的口径保养在 API 中。
为了处置这些疑问，我们转而构建一个目的服务，经过目的平台提供一致的数据服务进口。这样做不只提高了效率，降落了开发老本，还降落了了解和学习老本。
经过图片展现，我们可以更直观地看到在一致目的服务树立之前和之后的状况。在树立之前，当有需求时，我们须要开发许多两边层的 ClickHouse 表，并在其上构建数据集和 API。这些 API 通常比拟复杂且扩散。在树立之后，一切的目的取数和服务资产都保养在目的平台上。目的平台提供 MetricDSL 这样的目的化服务才干，作为一个一致的数据服务接入层，服务于一切下游的数据产品和消费渠道。这种形式成功了全体一致的数据服务树立和接口。这种一致数据服务带来的价值包括：
为了成功一致的目的查问，我们梳理出了三个**技术。首先是 MetricDSL，一种一致的目的查问言语。MetricDSL 允许多种查问类型，包括 OLAP 查问、明细查问、基于目的函数的查问，以及用户自定义的目的函数查问。其剖析因素包括目的维度模型、过滤条件、期间范围，并能允许多目的查问、跨模型查问、跨数据源查问以及基于公共维度的查问。
经过 MetricDSL，我们能够提供应用户和下游消费场景愈加灵敏和多元化的查问才干。例如，以前我们经过编写 SQL 来查问目的，如今经过 MetricDSL 提供了一个通用化的接口，从而成功了一致查问言语的语义表述。
在成功一致目的查问言语后，我们须要对口头流程启动规范化。用户经过 MetricDSL 构建查问语义后，首先进入元消息处置层，包括校验层、元消息失掉层和拆解层。元消息失掉层触及目的消息、模型消息和目的函数消息的失掉。拆解层担任将用户传入的复合目的拆分为基础组件元素，并拆分目的引擎，如将目的底表对应于 ClickHouse 或 StarRocks，以及拆分相应的目的函数。
元消息处置成功后，进入物理口头模块，该模块启动 SQL 优化，将 MetricDSL 经过 AST 语法树剖析转换为能被引擎口头的物理查问方案。接上去是数据处置阶段，为了兼容跨模型、跨数据源、跨集群的查问才干，我们会对不同模型或数据源的目的启动数据兼并和内存计算。
最后，对用户查问的目的函数，似乎环比等，在内存中启动计算，成功一致目的查问言语的完整口头流程。
在电商外部场景中，一个目的往往会绑定到多个不同的模型。例如，支付订复数目的或许触及域外和域内场景，域内场景又或许绑定到不同层级的表，如 DWD、DWS、DM 和 APP 层，每个表允许不同的粒度和主键，以及维度。
为了满足用户的查问需求，我们允许将同一个目的绑定到多个模型上。从全体视角登程，当用户查问支付订复数允许哪些维度时，我们提供的是该目的在所无关联模型中允许的维度，而不是单个模型。这样，用户可以从整个目的和一切模型的视角启动剖析，无需关心目的绑定在哪个模型上。
由于一个目的可以绑定到多个模型，智能路由成为必要。智能路由分为挑选和淘汰阶段，以及择优阶段。挑选阶段依据用户选用的目的维度、维度值和可累加性，删除不合乎要求的表。择优阶段则依据主题优先、效率优先、同模型优先等规定，选用最适宜用户场景的表。
在电商业务中，目的消费的环节触及多个实践进口。首先，我们外部有一个目的字典或目的专题性能，旨在让业务同窗能够基于目的平台极速构建属于自己的目的主题，无需一一去数仓失掉数据。他们可以间接经过构建的这些主题失掉到相应的目的数据。
第二个关键的消费进口是基于目的的路由。以往，数仓交付的是表，下游用户只能从这些表当选用构建目的。如今，下游数据的消费从选表转变为选目的，用户无需关心目的属于哪个表。他们看到的是整个电商业务或特定剖析主题下的一切目的，可以依据这些目的启动跨模型、跨数据源、跨数据域的全体剖析。
这种基于目的的消费形式在 BI 剖析看板中表现得尤为清楚。下游的 BI 平台可选用的内容增多，用户不再局限于保养基于固定数据集的目的和维度性能。如今，他们可以基于一个剖析主题，应用少量目的和维度的汇合，极速构建仪表盘和看板。
此外，基于目的的消费形式还带来了一个长处，在以前的基于表或数据集的洞察剖析中，我们只能剖析某一维度或字段，例如，当我们剖析国度占比时，只能看到目的全体回升时，哪些国度增长最为清楚。如今，由于我们领有了目的的血统消息，比如一个复合目的，我们可以启动更深化的剖析。例如，假设目的回升，我们可以剖析是分子参与了还是分母缩小了，甚至可以检查更详细的状况。基于目的构建的血统，我们可以启动更深入的洞察剖析。
在成功电商目的体系树立后，我们经过详细数据来验证其功效，能否成功了预期的消费促成消费、消费促成消费的良性循环。我们从四个方面启动评价：目的的笼罩度、电商规范化目的的水平、用户的消费状况以及分歧性疑问能否失掉处置。
为了权衡电商目的体系树立功效，我们设定了几个关键目的。首先，模型的绑定率到达了 83%，象征着电商保养的 1 万多个目的中有 83% 都启动了绑定。其次，我们关注一切电商视角目的的查问能否经过目的元数据或目的去除服务失掉笼罩。目前的笼罩度为 70%，这是一个相对较高的数值。
第三个关键目的是公共层的积淀率，即有多少目的积淀到了公共层。经过这三个目的值，我们发现目的平台在电商畛域处置了烟囱式开发和业务口径对齐的痛点，进一步成功了消费促成消费，一处消费多处消费的最终目的。
此外，我们还将关注点裁减到了外部场景，包括外部 BI 的数据买通、源数据取数，以及消费看板等内围业务场景。
展望未来，我们关键从三个智能化和大模型角度启动布局。首先，我们方案经过剖析用户查问日志的热点，智能化生成对应的物化视图，以优化查问性能。其次，我们将成功智能化的建模，经过已保养模型的血统推断新模型的目的和维度绑定相关，成功语义化的智能建模。我们还将努力于智能化的目的拆解，经过大模型的了解和消费血统，成功智能化拆解，减轻数仓在目的消费上的累赘。此外，我们方案应用大模型将高度规范化和低价值的目的消息启动整合，为未来的大模型了解目的语义提供允许。例如，当用户查问特定目的时，我们宿愿经过大模型将文本转换为 SQL，以提高查问的准确率。未来，大模型的找数场景将成为我们关注的重点。这些布局将有助于进一步优化电商业务的数据品质和效率。