一、背景
雪球数仓经过多年的建设，已经支撑起了各类业务对数据的需求。而随着社区与基金、股票等业务的进一步融合，管理层以及各业务方对数据的准确性、及时性等要求进一步提高，业务的发展壮大也使得数仓规模越来越大。雪球大数据团队在支持现有数据需求的同时，也对历史沉积的数据做了梳理和优化。在这过程中，经常会碰到诸如指标二义性、同名不同义、重复开发等问题，这些问题的存在，已然很难做到高效的生产数据，更不用说利用数据了。而在现有的数据架构和开发模式下，要解决以上问题，其花费的时间成本、人力成本等可以预见的都会很大，而且还只是能解决已出现的问题，很难形成一整套的开发流程，所以我们需要寻求一个能解决短期问题并且长期也能适用的解决方案。同时，公司的组织结构及业务架构也发生了变化，数据分析团队正在根据相应的变化重新梳理指标体系。为了能够做到更好的满足公司各业务方对数据的需求，实现高效且准确的目标，两个团队不谋而合，决定将两者结合在一起，对数据体系做一个更长远的规划。
二、数据仓库模型
在大数据的数据仓库建设中，模型是数仓实施的基础，它关系到数仓开发人员建设数仓的难易程度和周期，也关系到数据使用人员使用数据的便利程度，甚至会影响某些数据产品的选型，进而影响到整个数据体系和生态。在大数据的数据仓库建模过程中，一般有以下几种建模方式：
1. ER实体关系模型
在信息系统中，将事务抽象为“实体”（Entity）、“属性”（Property）、“关系”（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。ER实体模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。但由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。
2. 维度建模
维度建模是数据仓库大师Ralph Kimball所倡导的一种建模方式，主要是面向分析场景。维度建模将数据仓库中的表划分为事实表、维度表两种类型。事实表包含了与各维度表相关联的外键，并通过JOIN方式与维度表关联。依据对维度表不同的处理方式，又可分为星型模型和雪花模型。
3. DataVault建模
Data Vault是Dan Linstedt发起创建的一种模型，它强调建设一个具有原子性、可追踪历史的基础数据层。Data Vault模型包括Hub、Link和Satellite三部分。Hub是核心业务实体，由实体key、数仓序列代理键、装载时间和数据来源组成；Link是Hub之间的关系，它由Hub的代理键、装载时间和数据来源组成；Satellite是Hub的详细描述信息，它由Hub的代理键、装载时间、来源类型和详细的Hub描述信息组成，一个Hub可以有多个Satellite。Data Vault模型是ER模型的衍生，它会比ER模型更容易设计和和产出，并且它的ETL开发可以实现配置化，但是它设计的出发点是为了实现数据的整合，无法直接应用于数据分析决策。
4. Anchor建模
Anchor模型由Anchors、Attributes、Ties和Knots组成。Anchors是类似于Data Vault的Hub，代表业务实体，且只有主键；Attributes是功能类似于Data Vault的Satellite，但是它更加规范化，将其全部K-V结构化，一张表只有一个Anchors的属性描述；Ties就是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力；Knots代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、地理位置等这种枚举类型且被公用的属性。在上述四个基本对象的基础上，又可以细划分为历史的和非历史的，其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。Anchor模型是对Data Vault模型做了进一步规范化处理，其核心思想是所有扩展只是添加而不是修改，因此将模型规范到6NF。但是这样大大增加了查询join操作，不太适合有比较多的join操作的数据仓库。这种建模方法实际应用较少，就不再做过多介绍。
当前主流建模方法为：ER实体模型、维度建模。其两者的优缺点对比入下：
建模方法 |
优点 |
缺点 |
适用场景 |
ER实体模型 |
|
|
OLTP |
维度建模 |
|
|
OLAP |
三、雪球数仓现状
在雪球的数仓建设中，采用的是维度建模方法，这样既可以让我们迅速响应数据需求，又能让业务方很方便的使用数仓里的数据，同时还兼备结构清晰等特点，让我们能顺利的组建企业级数仓。但由于维度建模自身的限制，在越来越广泛的数据应用中暴露出了越来越多的问题，如指标二义性，数据出口不统一，没有整体的指标体系，指标重复开发程度高以及数据冗余度高等，对数据开发、业务方使用数据等都造成了困扰，同时也对集群的存储和计算资源也带来了挑战。
指标二义性： 指的是指标的定义会产生多种理解。这样的指标定义不仅会误导数仓的开发，还会影响业务方的使用。
指标同名不同值： 指的是指标名相同，但是实际上在不同表里计算结果的值却有差异，有的甚至相差悬殊。如帖子的阅读数，有的业务指的是帖子的曝光数，有的业务指的是帖子的点击数，这样的不同的口径结算的结果肯定是不同的，不仅会造成理解上的困难，还会造成指标难以复用的局面。
指标重复建设： 数仓本身是用空间换时间的技术，但是指标如果存在较大重复开发的问题，则会浪费集群的存储空间、计算资源，影响整体数据产出的效率。而且模型的复用率不能提高的话，会导致数仓一直处在开发--重构的循环之中，很难做到对业务的快速响应和保证数据产出的稳定性、及时性等要求。
数据成本/收益无法量化： 在现有的公司数据流转和服务体系中，数据仓库作为数据存储和生产方，一直为业务方扮演着支持者的角色，为公司各类服务提供基础的数据支撑。但由于集群、机房等物理条件和团队属性等客观条件的限制，数据仓库成为了事实上的成本中心，其创造的收益却难以衡量。在所有的优化手段中，其提到的目的都是节省了多少成本，而不是能创造多少收益。
所以，基于以上的原因和事实，我们需要寻找一个构建在模型结构之上来解决上述问题的方案。经过学习和了解，目前较为成熟的方案有阿里提出的OneData建设体系，可以帮助我们解决雪球数仓建设中的上述问题。
四、OneData体系
1. 概念
OneData体系是基于维度建模的基础，利用对企业指标体系分析的结果，对数据仓库的需求分析、模型设计和数据出口等环节进行统一规划的解决方案。OneData体系是阿里数据中台的核心方法论，其包含了三个方面内容：OneModel 即建立企业统一的数据公共层，从设计、开发、部署和使用上保障了数据口径规范和统一，实现数据资产全链路管理，提供标准数据输出；OneID 即建立业务实体要素资产化为核心，实现全域链接、标签萃取、立体画像，其数据服务理念根植于心，强调业务模式；OneService 即数据被整合和计算好之后，需要提供给产品和应用进行数据消费，为了更好的性能和体验，需要构建数据服务层，通过统一的接口服务化方式对外提供数据服务。
2. OneModel
OneModel方法论保障了数据唯一性的数据域、业务过程，以及在数据域、业务过程之下的指标、实体属性等的结构性封装、命名和定义。数据规范定义是在开发之前，以业务的视角进行数据的统一和标准定义，确保计算口径一致、算法一致、命名一致，后续的数据模型设计和ETL开发都是在此基础上进行的。其规范定义主要包括了数据模型标准化和业务指标标准化两部分。
数据模型的标准化是规范和统一业务定义、业务规则、字段命名、字段长度、字段类型等内容，本质上是元数据管理。其包含的元数据内容入下图所示：
业务指标的标准化主要是对企业业务指标所涉及的指标项的统一定义和管理，构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标。
3. OneID
OneID是对用户的精准识别，是打通用户在各端行为的重要手段。通过统一数据萃取，OneID是一套解决数据孤岛问题的思想和方法。
数据孤岛是企业发展到一定阶段后普遍遇到的问题。各个部门、业务、产品，各自定义和存储其数据，使得这些数据间难以关联，变成孤岛一般的存在。
OneID的做法是通过统一的实体识别和连接，打破数据孤岛，实现数据通融。简单来说，用户、设备等业务实体，在对应的业务数据中，会被映射为唯一识别（UID）上，其各个维度的数据通过这个UID进行关联。
4. OneService
OneService是通过统一的统一数据服务，为数据仓库提供数据接入和为业务方提供查询服务。在数据仓库建设中，我们常面临这些数据服务问题：
-
异构数据： 各种数据存储在各种文件系统、消息队列、 RMDBs 和 NoSQL 中，访问困难
-
重复建设： 因为缺少协同合作，各数据应用方重复开发查询服务，重复存储业务数据
-
缺少跟踪： 数据应用方自建查询服务，难以进行访问审计、质量控制等数据全链路管理
-
理解困难： 因为效率、管理等原因，数据存储在多个物理表，与业务视角的映射复杂不直观
OneService 的中心思想是数据复用而不是复制，通过提供满足数据应用方真实访问和接入需求的数据服务来实现这一点。
五、OneData体系实践
在OneData的实施过程，主要分为4个部分：需求分析及评审、模型设计及评审、ETL开发及测试和上线使用。每个过程都有自己的输入及输出成果，整个过程按照软件开发的螺旋模型往前推进。
1. 需求分析及评审
当分析师收到业务方需求，或者是想对某类行为进行分析时，他可以在大数据平台的相关模块中去搜寻自己想要获得的信息，如果已有数据能够满足需求，则直接在系统上申请权限后使用；如果已有数据无法满足需求，则需要根据业务需求整理需求文档，并会同业务方、数仓开发等相关方开展需求审评流程，最终产出定稿的需求文档。
雪球的业务版块主要有基金、股票和社区三大块，其下分别涵盖了各自不同的业务域。另外还有第三方和用户行为的一些数据。分析人员在整理需求时，需要明确该需求所属的业务版块，以便能准确的对指标进行OneData体系的拆分。OneData的指标构成主要分为修饰词，时间维度和原子指标三部分，以指标“最近7天蛋卷APP用户基金申购金额”为例，演示一下指标拆分的过程：
数据域： 是指面向业务分析，将业务过程或者维度进行抽象的集合。我们可以将基金作为一个数据域。
业务过程： 是指企业的业务活动事件，如下单、支付、退款都是业务过程。这里的业务过程是申购，它是一个在实际业务上不可再拆分的行为事件。
时间周期： 用来明确数据统计的时间范围或者时间点，如日、周、月、最近30天等。指标计算的时间周期为最近7天，便可将【最近7天】作为时间维度。
修饰类型： 是对修饰词的一种抽象划分。这个例子中，修饰类型可以分成两个：【渠道】和【产品】。
修饰词： 是指除了统计维度以外指标的业务场景限定抽象。例子中的修饰词可以分为【蛋卷APP】和【基金】，其所属的修饰类型分别为【渠道】和【产品】。
度量/原子指标： 原子指标和度量的定义相同，是指业务定义中不可再拆分的指标。这里的原子指标定义为【申购金额】，其在申购的业务过程中属于不可再拆分指标。
派生指标： 是一个原子指标+多个修饰词（可选）+时间周期的结果，可以理解为对原子指标业务统计范围的圈定。在这个例子中，【最近7天蛋卷APP用户基金申购金额】就是派生指标。
对基金、股票和社区三个数据域下业务过程的划分，按照实际的业务活动事件可以大致分为如下几块：
基金：其业务过程分为开户、认购、申购、确认、转换、赎回和收益
股票：其业务过程分为开户和交易
社区：其业务过程分为注册、发帖、读贴、评论、关注/取关
对于业务需求，分析人员除了需要拆解出时间周期、修饰类型和修饰词、原子指标外，还需要跟业务、数仓开发等各方一起确认好原子指标的计算口径，最终形成完整的需求文档。
2. 模型设计及评审
经过评审的需求会进入模型设计阶段，模型设计的目的一是从整体考虑问题，保证系统良好的扩展性；二是将风险点提前，减少后续开发中遇到的问题，提高按时交付的可能性。雪球数仓目前按照四层来建设，分别是ODS层、DWD层、DWS层和ADS层，另外还有DIM层，用来存放维度信息表。
ODS层： 用来存放对接业务系统的数据表，其表结构与业务数据表保持一致，对应的数据更新方式根据表的具体情况分为全量抽取和增量抽取。上述需求中根据计算口径需用到交易表、用户表和渠道编码表。
DWD层： 用来存放按照模型设计过的表。按照Onedata体系的建设方案，此层的表会按照业务过程进行设计，如用户交易明细表用来存放所有订单粒度的数据，用户交易状态表用来存放用户历史累积的交易状态信息，用户信息表用来存放用户的基础信息等。
DWS层： 用来存放汇总数据，包括轻度汇总和高度汇总数据。此层的表会按照Onedata指标体系的要求进行设计，同个业务过程中相同时间周期和修饰词的数据会一并计算。为了保证良好的扩展性，高度汇总的数据会在轻度汇总的基础上进行计算，如交易核心指标_近7天会在用户交易汇总天表之上进行计算。
ADS层： 用来存放应用系统实际需要的数据。比如管理层日报、周报、月报等，这些数据可能需要跨越多个业务过程，所以在这层进行组装。
3. ETL开发及测试
经过评审的模型会进入开发阶段。为了达到OneData体系对表规范性和字段统一性的要求，并且能将业务过程、修饰词、原子指标等命名等统一起来，最好的办法是将这些规则融合到开发系统中。目前雪球大数据的开发系统【鲁班】已经能够支持OneData体系的开发功能，在建表时会自动匹配唯一性字段，表名等也会根据数仓规范和OneData要求自动生成。
表创建之后，鲁班会记录相应的元数据信息，供上线之后用户能更方便的检索和使用。
4. 数据上线及使用
数据和任务上线时，需要经过血缘模块的分析，自动添加依赖关系。任务上线后，元数据系统【天眼】会收集表的各类信息，如基本属性、字段信息、分区信息、依赖关系等，也能展示样例数据，方便用户的检索和使用。
六、建设成果
实施OneData后，对BI系统的性能提升是巨大的。以前BI系统的取数不会太遵循数仓的规范，为了方便会从各层直接取数，这样造成的后果一是重复计算的问题特别严重，同样的指标在多个数据集中都会计算，对集群的计算资源造成了严重的浪费。而且计算资源的浪费，使得BI看板的出数时间不稳定，对与业务分析人员的工作安排造成了影响；二是指标口径不统一，就像每个需求定制化的定义似的，结果就是数据看板上的数值千差万别，这对管理层分析数据造成了困扰，干扰了他们的决策；再次就是造成了数仓模型的混乱，加大了成体系输出的难度。实施了OneData后，整个BI按照统一的体系进行开发，其产生的成果也是很明显的。首先是数仓更加规范化和系统化，各个分层更加清晰，层次更为清楚；其次对指标进行了统一管理，极大地减少了指标二义性和同名不同义的情况，使得数据更加统一和准确；再次是计算效率的提升，让BI看板的出数时间提前了30%，更好的满足了管理层和业务分析人员的数据使用需求。
七、总结
雪球数仓在建设中使用了维度建模的方式，由于维度建模自身的限制，以及数仓的定位和业务使用数据的方式等历史原因，导致现在的数仓存在较严重的指标重复构建、模型不明确、没有清晰的指标体系等诸多问题，这样不仅会浪费集群的存储和计算资源，加大业务方使用数据的难度和增加开发人员的工作量，而且容易造成把数据只当成工具而非资产来使用的情况。不过，正是因为有这些问题的存在，反倒是成为了实施OneData的内驱力。同时，数据分析团队在梳理的统一的指标体系，是实施OneData的前提，但不论有没有OneData，它都至关重要，是指导数仓建设方向的明灯。数仓开发工具及配套系统的开发，是为了达到提高开发效率，严格执行数仓规范，简化开发流程和打通数据体系等目的。所以，在雪球实施OneData，是数仓发展到现阶段后一件自然而然的升级过程。
实施OneData后，能够帮助我们避免开发路程中的单点故障，提升整体开发效率；也有助于降低或消除指标二义性，减少模型重复构建的问题，节省存储和计算资源，提高数据生产的效率；也可以在其体系下进一步丰富大数据生态，完善各类场景下使用的工具，降低数据使用难度，沉淀数据资产；最后，一个规范且高效的数据体系可以让我们对以数据驱动决策有了期待。
八、未来规划
1. 数据地图
数仓的建设是为了满足业务的需求，而数仓是否好用一个最直接的评价手段就是看获取内容的便利程度。目前我们在这方面还没有很完善的设施，未来需要能全面、形象的展示数仓里的内容，提高用户对数仓的了解程度，让数仓更加开放，进而降低用户的使用成本。
2. 模型评价体系
数仓的每次需求、每次迭代都会去做模型设计，尽管有模型评审环节，但业务多变且各环节参与人员水平不一，且有时候还会因为工期紧张而缩短开发周期，所以很难百分百保证每个模型都能做到良好的扩展性。一旦业务需求发生变化，如果原来的模型不足以支持所需要的数据粒度时，从数仓的整体来说，重构是最好的选择。但是如何在业务需求变化之前主动发现模型的不足然后自发地去推送重构优化，成为了数仓管理和优化的难点。不过，基于OneData体系的数仓模型具备良好的系统延展性，各业务模块间低内聚高偶尔，可以通过多角度的评分来达到整体模型评价的目的。未来我们要建立健全这套评价机制，主动推动数仓的优化，进一步提高数仓的利用效率。
3. 表生命周期管理
业务是有生命周期的，所以数仓里的表同样也存在生命周期。业务上线时会因为需要分析数据而开发表，但是业务下线时很少会主动通知到数仓。随着时间的推移，数仓中积累的历史表会逐渐增多，对存储和计算的压力都会带来挑战，如果能有一套能自动识别已下线业务对应的表的话，对表生命周期的管理就会变得容易很多，数仓的效率也能进一步提高。
本文使用 文章同步助手 同步