首先来介绍一下当前企业数仓建设的现状。

数仓建设的意义，简单来说就是将业务数据通过整合、转换、计算以及其它一些操作，提取出有价值的信息，最终把这些信息反馈给业务，为业务的发展持续赋能。

(资料图片仅供参考)

从技术上来看，现在通用的模型遵循图中的分层设计准则。源头是ODS层，即引入层，严选的数据主要有两个来源，一个是数据库binlog对应的快照，另一个是日志，包括业务日志、埋点日志、APP日志等等。

中间部分是数仓建模。包括贴源层，我们命名为DWD事实层，然后是DWS明细层，第三层是DWS汇总层，再后面是DM集市层，主要是面向上层的应用以及数据产品的需求。

图中右边是严选数仓建模的生命周期。首先是业务调研和需求分析；然后定义ag旗舰厅指标，进行数据刻画；第三步就是进行逻辑模型的设计，把不同的指标和它们的维度进行关联，也就是进行数据组织的过程；第四步就是编码开发，将数据生产出来；接下来是上线交付、对外服务，也就是进行数据使用；最后就是长期的运行维护。

网易严选的核心业务是电商，数仓建设已有六七年时间，已经具有了相当大的规模，有大量的模型和指标都在服务于各种各样的生产环境上的产品。其中物理模型的数量有一万多个，开发任务有近万个，指标数也有近万个，产品和服务有数十个。

严选整个数仓建模流程中的各个步骤都有相应的一些产品进行承接，比如指标设计，就是通过我们的指标管理系统进行指标定义和模型设计；模型开发和任务运维是通过离线开发平台进行编码；数据对外提供服务是通过数据服务平台。由于历史原因，我们各个产品之间目前基本上是独立的状态，没有形成一个完整的体系，而各系统也存在着一些问题，包括接下来将重点介绍的指标管理系统。

旧的指标管理系统存在的问题大致可以归纳为四大方面：

首先是功能边界有限。当前系统不支持DW层模型的设计和管理，没有模型物理化能力，无法有效指导模型开发，缺乏与任务运维和数据服务关联的能力。

第二是指标定义不规范。存在比较多的指标重复定义、原子指标命名不规范、原子指标与派生指标混用等。比如包含派生词、未包含统计单位，另外非汇总数据也可能被错误的定义成一些指标，比如一些根据机器学习算法得出预测值。

第三是模型设计不规范。模型命名分层不清晰，模型开发线上化率比较低，存在大量没有进行登记的模型，模型与指标的关联关系也比较混乱。整个模型设计，没有跟模型开发进行强绑定，可能有些需求比较紧急就导致开发人员忽略了设计过程。

第四是模型构建不规范。逻辑模型与物理模型的结构存在差异。存在很多烟囱式的开发，导致指标被重复计算。还有跨层依赖问题，比如DM层直接依赖了最底下的DWD层；反向依赖问题，比如DWS层依赖了DM层，DM层的有些数据当作汇总表在用。

通过对现有系统的量化分析，我们整理出了当前数仓建设的痛点。

首先，业务复杂多变，比如电商会经常做活动，各种玩法带来很多复杂的业务流程，由此带来的就是数仓体量庞大，数据之间的关系网非常复杂。

其次，事前规划不足，模型设计能力欠缺，经常出现指标重复定义、描述不规范的情况，指标和模型缺乏严谨性。

第三，设计和实现过程就脱节，一方面开发效率低下，职责不清，存在重复计算的问题，另外，依赖关系混乱，人工编码也很容易引入错误。

第四，事后治理困难，由于事前和事中没有做好，就会导致事后治理起来非常困难，比如业务有变动，模型设计或者指标的计算方式就会有变化，但是很难追溯，变更过程非常复杂。数据质量也就无法保障，运维管理过程会非常低效。

第五，数据孤岛问题，指标口径不一致，观察视角不统一，比如开发人员看到的是指标模型，而上层应用可能看到的是表字段的视角，继而导致学习和使用数据的成本比较高。

针对上述痛点，我们制定了以建设完整、规范的数仓建模体系为目标的解决方案：制定一个标准，输出一款产品，落地一套规范。

我们在一开始的时候其实是有一个标准的，但仅停留在文档层面，并没有非常好的落地。所以希望通过产品化的方式，对这套标准进行强制的规范落地。产品会包括业务过程管理、维度管理、指标定义、模型设计等能力。通过这款产品，落地一整套的规范，比如指标定位数据、数据访问约束，以及后期的模型治理、任务运维规范等等。

我们的数仓建模平台，整体上还是以经典的数仓建模方法论为理论依据，结合网易严选的数仓建设现状，对标业界优秀的相关产品，借助大数据其它产品能力，指导数仓从设计、开发、使用到最后维护，这样一套全流程一站式的解决方案。

上图中右边是我们新建的数据建模平台在大数据体系中的定位，以及与其它一些平台的关联。

上图是整体的产品框架，产品功能重点在红框中的数据模型设计部分。主要分为五大块内容：数据规划、数据标准、维度建模、数据指标和数据资产。其中维度建模和数据指标是我们整个产品设计的核心。数据规划和数据标准主要是结合严选现状，做一些定制化内容，相对来说没有后面几块做的灵活。

下面一层是数据开发，这一层就是将上面的逻辑定义设计真正落实到代码当中。最下面是物理层，包括引擎、存储、计算等等。

右边的应用场景包括数据报表、风控引擎、用户画像、榜单服务、舆情管理等等。

功能模块中，有三个核心的功能模块：

第一块是业务过程和指标定义，包括业务过程定义、总线矩阵设计、维度管理、度量定义、原子指标管理、派生指标管理等等。

第二块是逻辑模型设计，结合现状设计了一个分层模型，最底下是数据引入层ODS层；通过清洗转换，形成了明细模型DWD层；再通过一些细粒度计算，以及一些复杂的数据规划（如归一化、标准化、维度计算等），形成数据服务模型DWS明细层，在这个明细层关联原子指标；然后再把原子指标这一层数据进行派生汇总，形成汇总DWS层，这一层模型跟派生指标进行关联；最后上面是面向应用的集市层DM，按需进行取数。

第三块是模型物理化和构建，主要包括模型进行物理化，任务的发布和运维，以及数据服务的生成和绑定。

严选数仓规范化建设制定了三步走的战略：

第一步是规范指标定义体系建设，包括规范业务过程、度量、指标命名、指标分类、派生依赖、汇总算法、派生算法、派生词关联等等。

第二步是规范模型的设计体系建设，在指标定义规范的前提下，进行模型设计的规范，包括模型命名、分层、依赖、数据时效、维度关联等等。

第三步是规范指标计算和模型构建的过程，我们希望不仅模型是规范的，数据的生产过程也必须是规范的，包括结构的一致性、自动构建任务、任务运维、变更通知、算法优化、参数调优等。

第一个实施步骤是规范指标定义体系的建设。原先的设计流程通常仅仅是很随意地录入到旧的指标管理系统中，经常存在指标含义表述不清、重复设计等问题；此外还存在不少指标只记录在离线文档，口口相传。

规范后的定义流程按照下面五步强制流程来走：

（1）切分业务域。

（2）进行维度设计，生成派生词，也就是业务限定。

（3）设计业务过程，包括确定业务流程，设计维度矩阵以及度量。

（4）设计原子指标、衍生原子指标，包括关联度量，明确数据类型、汇总方式，公式化地描述衍生原子指标的计算方式。

（5）基于原子指标，设计派生指标、派生计算指标，保证派生指标能够自动关联依赖的原子指标，确定派生词集合以及时间周期，自动生成中英文标识。

对于指标派生和依赖的规范建设，我们制定了各类指标派生的原则，定义派生指标=统计周期+派生词集合+原子指标。比如”日支付成功抖音渠道销售额“，“日”就是统计周期，“支付成功”是支付状态维度的一个派生词，“抖音渠道”是渠道维度的一个派生词，“销售额”是原子指标。

在产品层面，如上图右边所示，做了一些限定去保证指标完全按照我们的设计规范进行设计。

我们希望形成图中的逻辑闭环，首先在设计规范上达成共识，使得指标是可描述、可理解、可查询、可管理，并且可使用的，最后要达到可验证，通过验证来优化指标定义规范，从而形成一个逻辑闭环。我们单独对于指标的可查询、可管理、可理解这一块做了一个指标地图，目的就是对于指标的一些必要信息能够快速定位和快速查询，能够快速消除理解上的歧义，降低指标的使用门槛。

第二个实施步骤是规范模型设计体系建设。为了打破原有数据开发的一些不好的工作习惯，我们设计了一整套严格的模型设计流程：

（1）设计DWD事实模型，要关联业务过程和度量设计。

（2）设计DWS底层模型，要实现标识自动生成，关联原子指标、维度，以及模型物理化。

（3）设计DWS汇总模型，因为DWS底层模型是关联原子指标的，而DWS汇总层模型是关联派生指标的，派生指标本身就有严格的量化定义，所以DWS汇总模型的指标依赖包括模型的依赖关系是可以自动发现并自动关联的。借助产品的能力，可以做到所有指标、维度等信息都是可以溯源的，从而达到模型设计规范化建设的目的。

（4）设计DM集市层模型，我们将这一层定位为仅取数，不做任何数据计算汇总、转换的工作，也就是达到one data的效果。我们的模型指标只会在一个地方进行设计和计算，其它地方都是从这个地方取数就行了。

对于模型设计规范，举几个例子来说明。首先，我们做了模型命名规范的分层，前后缀当中要体现分层和业务过程，后缀代表模型数据的更新方式。

模型分层职责划分为，DWD事实层只做清洗、转换、归一化等工作；DWS明细层做一些细粒度计算，包括一些复杂的计算，比如有的订单数据里面需要对每一件商品的销售额计算用户支付的金额，要把这一单商品的运费均摊到每一件商品当中，那么就要在明细层中实现运费均摊计算；DWS汇总层就是基于明细层做派生计算；DM集市层仅仅是面向应用，只取数不计算。

最后，模型内容限定，就是不同层对应不同类型的指标，且只包含维度、汇总粒度、时间周期等这些信息。

上图是我们产品设计的一个demo。可以看到，汇总信息是基于派生指标得到的，所依赖的原子指标都可以自动发现，并且定位到上游的模型以及计算的逻辑。基于规范的指标依赖和规范的模型定义，就可以实现对模型构建和指标计算的规范化。

第三个步骤是规范指标计算和模型构建。原来我们存在一些不规范的模型开发习惯，首先，我们的模型设计和开发几乎是独立的，导致人工编码工作量大，还有可能前后不一致，存在实际的业务逻辑与定义不符。另外为了快速交付，存在一些烟囱式开发、指标重复计算和跨层依赖的情况。

在规范后的模型开发流程中，我们对DWD层和DWS底层模型还是按照平台设计+人工开发的方式。但对DWS汇总层进行了自动构建能力的建设，平台基于指标定义和模型设计，完全能自动发现依赖并按指标汇总逻辑生成计算代码，自动完成任务的开发、调度和运维。最后DM层相对简单，且定位清晰：只取数不计算，平台也做了自动构建能力的建设，并支持自动生成和绑定标准数据服务。

从DWD层模型到DM层模型构建的职责划分如上图所示。前两层虽然是人工开发的，但为了尽可能规范整个数仓体系的建设，模型的设计必须在平台上完成，并且平台能够对这两层模型进行持续规范化扫描和监控，防范指标模型体系的快速腐化。

后面两层则完全由平台进行设计，基于指标之间的关联派生关系，黑盒形式实现数据的计算可以从源头保障指标口径统一、数据质量稳定。减少开发工作量、降低变更的复杂性，达到指标可定位、可管理、可追溯，并且可控制。整个数仓体系的指标实现“定义即实现，所见即所得”是本平台建设的最终目标。

我们还实现了一个指标汇总代码生成引擎，支持并抽象了严选离线数仓几乎所有常用的指标计算场景。主要包括9步：首先是找到派生指标依赖的原子指标，绑定底层模型，根据派生词拼接汇总时的过滤条件，然后根据指标汇总方法拼接聚合函数，根据维度关联相应维度表，再从维度表中获取维度属性，接着是根据取数范围拼接取数的时间周期条件，根据模型粒度拼接分组条件，最后根据回刷周期拼接目标分区。

这是我们系统自动生成的汇总代码的一个demo，里面每一部分都能体现出前面描述的流程。

模型的发布、更新和运维是指标数据真正落地的过程，通过对接严选大数据体系的其它相关产品如离线开发平台、实时开发平台、数据质量平台等实现。

上图是产品设计的一个demo，对模型的发布、更新和运维完全实现了黑盒化。这样做的好处一方面是大大降低了数据开发人工操作的工作量，他们只需要在平台上直接点发布，就可以完成一整套流程；另一方面也可以避免数据质量以及时效性、产出效率等方面的问题。

网易严选已有一个相对比较完整和成熟的数据服务平台，所以我们就直接对接即可实现数据的对外服务。我们通过规范化的指标和模型的定义，生成标准的数据服务的查询代码，形成了代码的模板化构建，减少了人工干预，为下游数据使用规范化进行了约束。

最后做一个成果总结，现在我们这个平台在模型指标的定义和设计规范化，以及模型的自动化构建这两块已经全面落地。一方面是增量的指标模型，已经实现完全的规范化，对于存量的指标模型正在逐步进行切换。另一方面由于DWS汇总层以及DM层的自动化构建能力的交付，使得模型的开发效率、业务需求的交付效率都有了大幅提升。

我们的产品最重要的价值是解决了指标口径不一致的核心问题，对于数据的设计、生产、使用、维护治理都形成统一的视角，达到了降本增效的目的。

在整个实施过程中，比较重要的一点就是我们一直在探索规范性和灵活性之间的平衡点，有些规范定的太死可能会导致需求不能满足，即数仓建模一些现有的场景可能无法满足；但是太灵活又可能会导致逐渐腐化的后果。所以其间的平衡是很重要的一项工作。