精华内容
下载资源
问答
  • 阿里集团大数据建设OneData体系
  • ember-cli-onedata-common 关于 ember-cli-onedata-common是一个EmberJS回购附加组件,它包含组件,服务,样式和其他EmberJS应用程序资源以及用于构建Onedata Web应用程序的静态资源(图像,字体): op-gui-...
  • 第二篇:阿里数据中台之OneData体系1

    万次阅读 2019-07-25 10:17:29
    今天来介绍数据中台的第二篇,第二篇共分为三个大部分分别对应的是阿里的数据中台三大体系(阿里的数据中台体系架构见上一篇),OneData体系,OneEntity体系,OneService体系,三大体系相辅相成、相互依赖,OneData...

    今天来介绍数据中台的第二篇,第二篇共分为三个大部分分别对应的是阿里的数据中台三大体系(阿里的数据中台体系架构见上一篇),OneData体系,OneEntity体系,OneService体系,三大体系相辅相成、相互依赖,OneData体系为基础。这次我们把OneData体系分为两部分介绍,因为OneData体系包括数据模型设计和数据资产管理两部分,今天我们介绍OneData的数据模型篇章。

    1. 烟囱式开发带来的困扰和资源浪费
    阿里的数据中台治理主要是在2014年开始的,在2014年以前,阿里的大数据建设处于烟囱式开发状态,这样的开发带来了许多业务的困扰和资源的浪费,2014数据依赖如下图

    由图可见

    数据流向会乱,无方向性的
    数据管理式无序的,处于失控状态
    除了浪费研发人力和计算存储资源、也必然满足不了业务的需求
    当然,这个问题被放大式在本身业务以极快的速度发展的前提下,这样的开发导致的问题我们从两个方面来看
    业务困扰
    在混乱的开发中,会造成诸多的数据问题,如因为指标的定义问题,导致同一指标有多个数据,最常见的指标为UV,总结最业务的困扰主要一下三点

    数据统一:数据标准规范难(命名不规范、口径不统一、算法不一致),数据任务响应慢,从而导致业务部门产生困扰而导致不满
    数据未打通:各个数据团队各自为政,存在严重的数据孤岛现状;缺乏数据融通,数据价值发掘不够,从而导致业务部门看不清数据
    成为成本中心且服务化不足:数据无方向性,依赖混乱,,数据管理无序,失控,成本化严重,面向应用的服务化投入不足甚至缺失。
    技术困扰
    浪费主要分两方面看,一方面是开发人力技术的浪费,开发人员日常在数据异常排查和数据调研上疲于奔命。另外一个是计算存储资源的浪费,在没有公共层的情况下,数据重复存储和计算非常常见。简单的总结为一下的三点

    研发苦恼:烟囱式开发周期长、效率低
    维护困难:源系统乎或业务变成不能及时反应到数据上,加之数据不标准,不规范,上线难,下线更难。
    时效性差:重复建设导致任务链路冗长、任务繁多,计算资源紧张;数据批量计算慢,时效性不强且覆盖 业务范围窄,即时查询返回结果慢
    2. 数据公公层建设
    从上面的问题来看,数据的公共层建设是一件迫在眉睫的事情,那么数据公共层建设到底该如何进行,建设之前又要如何准备。
    这里就是OneData体系建设数据建设篇,OneData体系的主要四个组成部分为

    规范化数据建模:规范化数据建模,特别关注数据规范定义、数据模型设计和ETL开发等全流程
    规范化研发工具:用来落地和承载规范化建模的工具
    数据模型数据小库:规范化数据建模产生的所有分层数据模型的数据被统一存放在数据小库中
    面向应用的数据监控:所有的数据在面向应用是都会被监控和调用,且对上线、下线调优监控则会反馈到规范化数据建模中。
    四个部分的运行图如下

    从四部分看,首先应该是执行数据建模规范,其中包括数据规范定义、数据模型设计、ETL开发规范。各个规范都有对应的规范文件输出。

    在OneDataIII体系体系中,升级了原有的体系,讲数据规范定义,数据模型设计,ETL开发连在一起,时间设计即开发,所建即所得。即将数据规范定义从工具层面的数据命名+结构化抽象定义合二而一,与数据模型设计连接,进而直接影响ETL.
    $\color{red}{下面是核心部分} $
    也就数说数据规范定义完成之后,每一个指标都可以根据结构化明明规则和计算逻辑快速相应到对应的物理上存在的数据表中。
    因此在理论上,只要某个指标能够被规范定义(除非复杂到无法被规范定义的指标),而一系列经过规范定义的指标则会根据相同的计算粒度,汇集到若干物理上存在的表中或者逻辑上存在的表中,这样生成的物理表或者逻辑表,其代码都可以自动化生成。而中间生成过程则不必关心,因为这是系统内部的只能黑盒要以智能化的方式来解决的。并且从长远来看,只能黑盒不仅要实现代码自动化生成,还要关注自动化生成代码机器任务调度所对应的计算逻辑,特别是从全局来看,这些计算逻辑能不能胜于人工做法,甚至胜于人工做法
    具体的OneData体系的方法论,包含三个关键点分别是数据仓库规划、数据规范定义、数据模型设计,这里我们不介绍技术细节,后面技术细节在《大数据之路:阿里大数据实践》一书中会重点讲述。

    1. 数据仓库规划和数据规范定义
    数据规范定义是与需求分析和产品设计同时进行的工作,数据规范定义是在开发之前,以业务的视角进行数据统一和标准定义,确保计算的口径一致,算法一致,甚至命名是规范且统一的,后续的数据模型设计和ETL开发都是在此基础上进行的

    那么数据规范定义到底是如何实现的呢

    抽象出业务板块 我们基于对业务和数据的理解,对数据进行基于业务的抽象,这种抽象要求不会随着业务团队的组织架构变动而变动。例如阿里的除了公共板块外还会划分出如电商,金融,云业务等板块。
    抽象出数据域 在业务板块下面由抽象出数据域,以电商业务板块为例,可以抽象出交易、会员、商店、浏览、搜搜、广告、公共、等不以团队转移的数据区域。
    抽象出数业务过程 在数据域下又抽象出业务过程,例如对于交易的数据域,可以抽象出加入购物车、下单、支付、确认收货、申请退款等。
    抽象出维度 也可以在数据与下抽象出维度,订单维度、买家维度、卖家维度、在会员数据域下抽象出会员维度等
    那么下面我们可以基于业务过程和维度,可以进一步定义一下
    原子指标 例如 支付的业务过程中可以定义 ‘支付订单金额’、'支付买家数’等原子指标,原子子表自带算法,可解读的中英文命名,数据类型等,并会被后续的派生指标继承;
    定义业务限定:在支付业务过程中可以定义业务限定,即最终计算派生指标的一些限制条件,入支付方式是支付宝、银联等
    定义计算周期:计算周期是一个非常特殊的业务限定条件,例如最近1天、最近7天、最近30天,几乎所有的最终面向业务的数据都有计算周期这个限制条件,因此其不属于任何一个数据域下的任何一个业务过程,需要独立定义
    定义计算粒度:关于维度,如BU维度,下会定义出很多维度属性,同时也会产生一些计算粒度


    最后基于原子指标,计算周期、业务限定、计算粒度可以结构化定义出派生指标,并以继承原子指标的数据类型、算法、以及可以解读的中英文命名为主,结合计算周期,业务限定和计算粒度的算法,中英文命名形成派生指标的算法,中英文命名。假派生指标是 最近30天天猫支付支付宝支付订单金额,则原子指标是 订单支付金额,计算周期是最近30天,业务限定是支付宝支付,计算粒度是天猫。如果钉钉最近7天天猫支付宝支付订单金额,则只需要用同样的方法将最近30天调整为最近7天即可快速定义。如果此时存在指标命名一样但结构不同,或者命名不同但结构相同,则系统会校验并给出错误提示。

    2. 数据模型设计
    经典的数据模型有很多理论和实战指导,但是阿里在结合自身的业务做了改进和突破
    首先,数据设计模型是建立在数据规范定义的基础上,这就从业务应用或者需求来源空值了数据模型设计的重要输入源头,其次,对数据迷行严格分层,在统一数据公共层的同事允许数据应用层百花齐放,第三 从业务和技术双视角出发,严格遵循数据模型设计的高内聚低耦合的六项技术要求


    1. 高内聚低耦合
    主要是指从数据业务特性和访问特性两个角度来考虑,将业务相近或者相关的数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放在一起,将低概率同时访问的数据分开存储。
    2. 核心模型和拓展模型分离
    建立核心模型和拓展模型体系,核心模型包括子弹支持常用的核心业务,拓展模型包括字段支持个性化和少量应用的需要,不能让拓展模型的字段过度入侵到核心模型,以免破坏核心迷行的架构简洁性和可维护性
    3. 公共逻辑下沉及单一
    越是底层公用的处理逻辑越应该在数据调用依赖的底层进行封装与实现,不要让公共逻辑暴露在应用层实现,不要让公共逻辑多出同时存在。
    4. 成本与性能平衡
    适当的数据冗余可换取查询和刷新性能,不以过度冗余与数据复制
    5.数据可回滚
    处理逻辑不变,在不同时间多次运行数据结果确定不变
    6.一致性
    具有相同含义的字段在不同的表中命名必须相同,必须使用规范定义的名称
    7.表名清晰可理解
    表名需要清晰,一直,表名易与消费者理解和使用

    最后增加模型架构的流程图,不做过多解释,欢迎点赞订阅,多多支持!
     

    展开全文
  • 美团OneData探索之路

    2021-04-20 00:45:11
    在现有大数据平台的基础上,借鉴业界成熟OneData方法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变化的业务并驱动业务的发展,最终形成我们自己的One...

    在现有大数据平台的基础上,借鉴业界成熟OneData方法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变化的业务并驱动业务的发展,最终形成我们自己的OneData理论体系与实践体系。

    背景

    随着业务的发展,频繁迭代和跨部门的垂直业务单元变得越来越多。但由于缺乏前期规划,导致后期数仓出现了严重的数据质量问题,这给数据治理工作带来了很大的挑战。在数据仓库建设过程中,我们总结的问题包括如下几点:

    • 缺乏统一的业务和技术标准,如:开发规范、指标口径和交付标准不统一。

    • 缺乏有效统一的数据质量监控,如:列值信息不完整和不准确,SLA时效无法保障等。

    • 业务知识体系散乱不集中,导致不同研发人员对业务理解存在较大的偏差,造成产品的开发成本显著增加。

    • 数据架构不合理,主要体现在数据层之间的分工不明显,缺乏一致的基础数据层,缺失统一维度和指标管理。

    目标

    在现有大数据平台的基础上,借鉴业界成熟OneData方法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变化的业务并驱动业务的发展,最终形成我们自己的OneData理论体系与实践体系。

    OneData探索

    OneData:行业经验

    在数据建设方面,阿里巴巴提出了一种OneData标准,如图-1所示:

    图1 OneData标准

    OneData:我们的思考

    他山之石,可以攻玉。我们结合实际情况和业界经验,进行了如下思考:

    1. 对阿里巴巴OneData的思考

    • 整个OneData体系覆盖范围广,包含数据规范定义体系、数据模型规范设计、ETL规范研发以及支撑整个体系从方法到实施的工具体系。

    • 实施周期较长,人力投入成本较高。

    • 推广落地的工作比较依赖工具。

    2. 对现有实际的思考

    • 现阶段工具保障方面偏弱,人力比较缺乏。

    • 现有开发流程不能全部推翻。

    经过综合考量,我们发现直接全盘复用他人经验是不合理的。那我们如何定义自己的OneData,即能在达到目标的前提下,又能避免上述的难题呢?

    OneData:我们的想法

    首先,结合行业经验,自身阶段的实践及以往的数仓经验,我们预先定义了OneData核心思想与OneData核心特点。

    OneData核心思想:从设计、开发、部署和使用层面,避免重复建设和指标冗余建设,从而保障数据口径的规范和统一,最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。

    OneData核心特点:三特性和三效果。

    • 三特性:统一性、唯一性、规范性。

    • 三效果:高扩展性、强复用性、低成本性。

    图2 OneData的六个特性

    OneData:我们的策略

    OneData即有核心思想又有核心特点,到底怎么来实现核心思想又能满足其核心特点呢?通过以往经验的沉淀,我们提出两个统一方法策略:统一归口、统一出口。

    根据两个统一的方法策略,我们开启了OneData的实践之路。

    OneData实践

    统一业务归口

    数据来源于业务并支撑着业务的发展。因此,数仓建设的基石就是对于业务的把控,数仓建设者即是技术专家,也应该是“大半个”业务专家。基于互联网行业的特点,我们基本上采用需求推动数据的建设,这也带来了一些问题,包括:数据对业务存在一定的滞后性;业务知识沉淀在各个需求里,导致业务知识体系分散。针对这些问题,我们提出统一业务归口,构建全局知识库,进而保障对业务认知的一致性。


    图3 支持业务的数据源知识库

    设计统一归口

    为了解决数据仓库建设过程中出现的各种痛点,我们从模型与规范两个方面进行建设,并提出设计统一归口。

    1. 模型

    规范化模型分层、数据流向和主题划分,从而降低研发成本,增强指标复用性,并提高业务的支撑能力。

    (1) 模型分层

    优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长。结合这些原则及以往的工作经验,我们将分层进行统一定义为四层:

    图4 数据分层架构

    (2) 模型数据流向

    重构前,存在大量的烟囱式开发、分层应引用不规范性及数据链路混乱、血缘关系很难追溯和SLA时效难保障等问题。

    图5 重构前和重构后的数据流向图

    重构之后,稳定业务按照标准的数据流向进行开发,即ODS-->DWD-->DWA-->APP。非稳定业务或探索性需求,可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP两个模型数据流。在保障了数据链路的合理性之后,又在此基础上确认了模型分层引用原则:

    • 正常流向:ODS>DWD->DWT->DWA->APP,当出现ODS >DWD->DWA->APP这种关系时,说明主题域未覆盖全。应将DWD数据落到DWT中,对于使用频度非常低的表允许DWD->DWA。

    • 尽量避免出现DWA宽表中使用DWD又使用(该DWD所归属主题域)DWT的表。

    • 同一主题域内对于DWT生成DWT的表,原则上要尽量避免,否则会影响ETL的效率。

    • DWT、DWA和APP中禁止直接使用ODS的表, ODS的表只能被DWD引用。

    • 禁止出现反向依赖,例如DWT的表依赖DWA的表。

    2. 主题划分

    传统行业如银行、制造业、电信、零售等行业中,都有比较成熟的主题划分,如BDWM、FS-LDM、MLDM等等。但从实际调研情况来看,主题划分太抽象会造成对业务理解和开发成本较高,不适用互联网行业。因此,结合各层的特性,我们提出了两类主题的划分:面向业务面向分析

    • 面向业务:按照业务进行聚焦,降低对业务理解的难度,并能解耦复杂的业务。我们将实体关系模型进行变种处理为实体与业务过程模型。实体定义为业务过程的参与体;业务过程定义是由多个实体作用的结果,实体与业务过程都带有自己特有的属性。根据业务的聚合性,我们把业务进行拆分,形成了七大核心主题。

    • 面向分析:按照分析聚焦,提升数据易用性,提高数据的共享与一致性。按照分析主体对象不同及分析特征,形成分析域主题在DWA进行应用,例如销售分析域、组织分析域。

    3. 规范

    模型是整个数仓建设基石,规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,我们统一按照最详细、可落地的方法进行规范建设。

    (1) 词根

    词根是维度和指标管理的基础,划分为普通词根与专有词根,提高词根的易用性和关联性。

    • 普通词根:描述事物的最小单元体,如:交易-trade。

    • 专有词根:具备约定成俗或行业专属的描述体,如:美元-USD。

    (2) 表命名规范

    通用规范

    • 表名、字段名采用一个下划线分隔词根(示例:clienttype->client_type)。

    • 每部分使用小写英文单词,属于通用字段的必须满足通用字段信息的定义。

    • 表名、字段名需以字母为开头。

    • 表名、字段名最长不超过64个英文字符。

    • 优先使用词根中已有关键字(数仓标准配置中的词根管理),定期Review新增命名的不合理性。

    • 在表名自定义部分禁止采用非标准的缩写。

    表命名规则

    表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾,如下图所示:

    图6 统一的表命名规范

    (3) 指标命名规范

    结合指标的特性以及词根管理规范,将指标进行结构化处理。

    A. 基础指标词根,即所有指标必须包含以下基础词根:

    B. 业务修饰词,用于描述业务场景的词汇,例如trade-交易。

    C.日期修饰词,用于修饰业务发生的时间区间。

    D.聚合修饰词,对结果进行聚集操作。

    E.基础指标,单一的业务修饰词+基础指标词根构建基础指标 ,例如:交易金额-trade_amt。

    F.派生指标,多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性,例如:安装门店数量-install_poi_cnt。

    G.普通指标命名规范,与字段命名规范一致,由词汇转换即可以。

    图7 普通指标规范

    H.日期类型指标命名规范,命名时要遵循:业务修饰词+基础指标词根+日期修饰词/聚合修饰词。将日期后缀加到名称后面,如下图所示:

    图8 日期类型指标规范

    I.聚合类型指标,命名时要遵循:业务修饰词+基础指标词根+聚合类型+日期修饰词。将累积标记加到名称后面,如下图所示:

    图9 聚合类指标规范

    (4) 清洗规范

    确认了字段命名和指标命名之后,根据指标与字段的部分特性,我们整理出了整个数仓可预知的24条清洗规范:

    结合模型与规范,形成模型设计及模型评审两者的工作职责,如下图所示:

    图10 模型设计和审计职责

    统一应用归口

    在对原有的应用支持流程进行梳理的时候,我们发现整个研发过程是烟囱式。如果不进行改善就会导致前面的建设“毁于一旦”,所以需对原有应用支持流程进行改造,如下图所示:

    图11 应用归口

    从图中可以看出,重构前一个应用存在多次迭代,每次迭代都各自维护自己的文档。烟囱式开发会导致业务信息混乱、应用无法与文档对齐、知识传递成本、维护成本和迭代成本大大增加等问题。重构后,应用与知识库相对应,保证一个应用只对应一份文档,且应用统一要求在一份文档上进行迭代,从根源上改变应用支持流程。同时,针对核心业务细节和所支撑的数据信息,进行了全局调研并归纳到知识库。综合统一的知识库,降低了知识传递、理解、维护和迭代成本。

    统一归口策略包含业务归口统一、设计归口统一和应用归口统一,从底层保证了数仓建设的三特性三效果

    统一数据出口

    数仓建设不仅仅是为了数据内容而建设,同时也为了提高交付的数据质量与数据使用的便利性。如何保证数据质量以及推广数据的使用,我们提出了统一数据出口策略。在进行数据资产管理和统一数据出口之前,必须高质量地保障输出的数据质量,从而树立OneData数据服务体系的权威性。

    1. 交付标准化

    如何保证数据质量,满足什么样的数据才是可交付的,是数据建设者一直探索的问题。为了保证交付的严谨性,在具体化测试方案之前,我们结合数仓的特点明确了数据交付标准的五个特性,如下图所示:

    图12 交付标准化

    《交付标准化》完善了整个交付细节,从根本上保证了数据的质量,如:业务测试保障数据的合理性、一致性;技术测试保障数据的唯一性、准确性;数据平台的稳定性和后期人工维护保障数据的及时性。

    2. 数据资产管理

    针对如何解决数据质量中维度与指标一致性以及如何提高数据易用性的问题,我们提出数据资产的概念,借助公司内部平台工具“起源数据平台”实现了整个数据资产管理,它的功能如下图所示:

    图13 起源功能体系

    借用起源数据平台,我们实现了:

    • 统一指标管理,保证了指标定义、计算口径、数据来源的一致性。

    • 统一维度管理,保证了维度定义、维度值的一致性。

    • 统一数据出口,实现了维度和指标元数据信息的唯一出口,维值和指标数据的唯一出口。

    通过交付标准化和数据资产管理,保证了数据质量与数据的易用性,同时我们也构建出OneData数据体系中数据指标管理的核心。

    实践的成果

    流程改善

    我们对开发过程进行梳理,服务于整个OneData体系。对需求分析、指标管理、模型设计、数据验证进行了改善,并结合OneData模型策略,改善了数仓管理流程。

    图14 数仓管理流程

    数仓全景图

    基于OneData主题建设,我们采用面向业务面向分析的建设策略,形成数仓全景图,如下图所示:

    图15 数仓全景图

    资产管理列表

    基于起源数据平台形成的资产管理体系,如下图所示:

    图16 数据资产管理

    项目收益

    基于OneData建设成果,我们结合实际项目建设样例,对比以前未进行OneData建设时的收益。如下图所示:


    图17 价值收益

    总结和展望

    我们结合了OneData核心思想与特点,构建一种稳定、可靠的基础数据仓库,从底层保障了数据质量,同时完成OneData实践,形成自有的OneData理论体系。

    未来,我们还将在技术上引入实时数据仓库,满足灵活多样、低延时的数据需求;在业务层面会横向拓展其他业务领域,不间断地支撑核心业务的决策与分析。下一步,我们将为企业级One Entity数据中台(以Data As a Service为理念),提供强有力的数据支撑。在后续数仓维护过程中,不断地发现问题、解决问题和总结问题,保障数据稳定性、一致性和有效性,为核心业务构建价值链,最终形成企业级的数据资产。

    作者简介

    禄平,周成,黄浪,健平,高谦,美团数据研发工程师。

    最后给大家一个小福利:公众号“数据社”后台回复“资料”,即可直接下载!

    欢迎大家加我微信好友,交个朋友,有需要的可以拉你进大数据交流群!

    历史好文推荐

    1. 数据人上班划水都聊什么?

    2. 收藏,Spark调优笔记

    3. 《数据社日知录》

    4. 阿里集团大数据建设OneData体系.ppt

    5. 美团配送数据治理实践

    展开全文
  • 数据中台之OneData体系

    2020-06-14 14:57:34
    数据中台之OneData体系 知其然知其所以然,本篇的博文总结和自己公司现在用到的数据中台的OneData的体系类似,使用的情景也很相似,所以我就把它放到自己的博文里,不仅自己可以重温一下,同时也可以帮到...

    数据中台之OneData体系

    知其然知其所以然,本篇的博文总结和自己公司现在用到的数据中台的OneData的体系类似,使用的情景也很相似,所以我就把它放到自己的博文里,不仅自己可以重温一下,同时也可以帮到那些同样使用OneData数据中台的同学。

    背景

    随着公司业务的发展,频繁迭代和跨部门的垂直业务单元变得越来越多。但由于缺乏前期规划,导致后期数仓出现了严重的数据质量问题,这给数据治理工作带来了很大的挑战。在数据仓库建设过程中,总结的问题包括如下几点:

    • 缺乏统一的业务和技术标准,如:开发规范、指标口径和交付标准不统一。
    • 缺乏有效统一的数据质量监控,如:列值信息不完整和不准确,SLA时效无法保障等。
    • 业务知识体系散乱不集中,导致不同研发人员对业务理解存在较大的偏差,造成产品的开发成本显著增加。
    • 数据架构不合理,主要体现在数据层之间的分工不明显,缺乏一致的基础数据层,缺失统一维度和指标管理。

    计划

    在现有大数据平台的基础上,借鉴阿里成熟OneData体系,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变化的业务并驱动业务的发展,最终形成我们自己的OneData理论体系与实践体系。

    一、OneData探索

    在数据建设方面,阿里巴巴提出了一种OneData标准,如图所示:

    基于此,我们做了如下思考:

    1. 对阿里OneData的思考

    • 整个OneData体系覆盖范围广,包含数据规范定义体系、数据模型规范设计、ETL规范研发以及支撑整个体系从方法到实施的工具体系。
    • 实施周期较长,人力投入成本较高。
    • 推广落地的工作比较依赖工具。

    2. 对公司实际情况的思考

    • 现阶段工具保障方面偏弱,人力比较缺乏。
    • 现有开发流程不能全部推翻重来。

    经过综合考量,我们发现直接全盘复用他人经验是不合理的。那我们如何定义自己的OneData,即能在达到目标的前提下,又能避免上述的难题呢?

    我们自己的想法

    首先,结合行业经验,自身阶段的实践及以往的数仓经验,我们预先定义了OneData核心思想与OneData核心特点。

    OneData核心思想:从设计、开发、部署和使用层面,避免重复建设和指标冗余建设,从而保障数据口径的规范和统一,最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。

    OneData核心特点:三特性和三效果

    • 三特性:统一性、唯一性和规范性
    • 三效果:高扩展性、强复用性和低成本性

    OneData:我们的策略

    OneData即有核心思想又有核心特点,到底怎么来实现核心思想又能满足其核心特点呢?通过以往经验的沉淀,我们提出两个统一方法策略:统一归口、统一出口。

    根据两个统一的方法策略,我们开启了OneData的实践之路。

    二、OneData实践

    统一业务归口

    数据来源于业务并支撑着业务的发展。因此,数仓建设的基石就是对于业务的把控,数仓建设者即是技术专家,也应该是“大半个”业务专家。基于互联网行业的特点,我们基本上采用需求推动数据的建设,这也带来了一些问题,包括:数据对业务存在一定的滞后性;业务知识沉淀在各个需求里,导致业务知识体系分散。针对这些问题,我们提出统一业务归口,构建全局知识库,进而保障对业务认知的一致性。

    设计统一归口

    为了解决数据仓库建设过程中出现的各种痛点,我们从模型与规范两个方面进行建设,并提出设计统一归口。

    1. 模型

    规范化模型分层、数据流向和主题划分,从而降低研发成本,增强指标复用性,并提高业务的支撑能力。

    (1) 模型分层

    优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长。结合这些原则及以往的工作经验,我们将分层进行统一定义为四层:

    (2) 模型数据流向

    重构前,存在大量的烟囱式开发、分层应引用不规范性及数据链路混乱、血缘关系很难追溯和SLA时效难保障等问题。

    重构之后,稳定业务按照标准的数据流向进行开发,即ODS-->DWD-->DWA-->APP。非稳定业务或探索性需求,可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP两个模型数据流。在保障了数据链路的合理性之后,又在此基础上确认了模型分层引用原则:

    1. 正常流向:ODS>DWD->DWT->DWA->APP,当出现ODS >DWD->DWA->APP这种关系时,说明主题域未覆盖全。应将DWD数据落到DWT中,对于使用频度非常低的表允许DWD->DWA。
    2. 尽量避免出现DWA宽表中使用DWD又使用(该DWD所归属主题域)DWT的表。
    3. 同一主题域内对于DWT生成DWT的表,原则上要尽量避免,否则会影响ETL的效率。
    4. DWT、DWA和APP中禁止直接使用ODS的表, ODS的表只能被DWD引用。
    5. 禁止出现反向依赖,例如DWT的表依赖DWA的表。

    2. 主题划分

    传统行业如银行、制造业、电信、零售等行业中,都有比较成熟的主题划分,如BDWM、FS-LDM、MLDM等等。但从实际调研情况来看,主题划分太抽象会造成对业务理解和开发成本较高,不适用互联网行业。因此,结合各层的特性,我们提出了两类主题的划分:面向业务面向分析

    1. 面向业务:按照业务进行聚焦,降低对业务理解的难度,并能解耦复杂的业务。我们将实体关系模型进行变种处理为实体与业务过程模型。实体定义为业务过程的参与体;业务过程定义是由多个实体作用的结果,实体与业务过程都带有自己特有的属性。根据业务的聚合性,我们把业务进行拆分,形成了七大核心主题。
    2. 面向分析:按照分析聚焦,提升数据易用性,提高数据的共享与一致性。按照分析主体对象不同及分析特征,形成分析域主题在DWA进行应用,例如销售分析域、组织分析域。

    3. 规范

    模型是整个数仓建设基石,规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,我们统一按照最详细、可落地的方法进行规范建设。

     

    (1) 词根

    词根是维度和指标管理的基础,划分为普通词根与专有词根,提高词根的易用性和关联性。

    1. 普通词根:描述事物的最小单元体,如:交易-trade。
    2. 专有词根:具备约定成俗或行业专属的描述体,如:美元-USD。

    (2) 表命名规范

        通用规范

    1. 表名、字段名采用一个下划线分隔词根(示例:clienttype->client_type)。
    2. 每部分使用小写英文单词,属于通用字段的必须满足通用字段信息的定义。
    3. 表名、字段名需以字母为开头。
    4. 表名、字段名最长不超过64个英文字符。
    5. 优先使用词根中已有关键字(数仓标准配置中的词根管理),定期Review新增命名的不合理性。
    6. 在表名自定义部分禁止采用非标准的缩写。

        表命名规则

    表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾,如下图所示:

    (3) 指标命名规范

    结合指标的特性以及词根管理规范,将指标进行结构化处理。

    A. 基础指标词根,即所有指标必须包含以下基础词根:

    B. 业务修饰词,用于描述业务场景的词汇,例如trade-交易。

    C. 日期修饰词,用于修饰业务发生的时间区间。

    D. 聚合修饰词,对结果进行聚集操作。

    E. 基础指标,单一的业务修饰词+基础指标词根构建基础指标 ,例如:交易金额-trade_amt。

    F. 派生指标,多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性,例如:安装门店数量-install_poi_cnt。

    G. 普通指标命名规范,与字段命名规范一致,由词汇转换即可以。

    H. 日期类型指标命名规范,命名时要遵循:业务修饰词+基础指标词根+日期修饰词/聚合修饰词。将日期后缀加到名称后面,如下图所示:

    I. 聚合类型指标,命名时要遵循:业务修饰词+基础指标词根+聚合类型+日期修饰词。将累积标记加到名称后面,如下图所示:

    (4) 清洗规范

    确认了字段命名和指标命名之后,根据指标与字段的部分特性,我们整理出了整个数仓可预知的24条清洗规范:

    结合模型与规范,形成模型设计及模型评审两者的工作职责,如下图所示:

    统一应用归口

    在对原有的应用支持流程进行梳理的时候,我们发现整个研发过程是烟囱式。如果不进行改善就会导致前面的建设“毁于一旦”,所以需对原有应用支持流程进行改造,如下图所示:

    从图中可以看出,重构前一个应用存在多次迭代,每次迭代都各自维护自己的文档。烟囱式开发会导致业务信息混乱、应用无法与文档对齐、知识传递成本、维护成本和迭代成本大大增加等问题。重构后,应用与知识库相对应,保证一个应用只对应一份文档,且应用统一要求在一份文档上进行迭代,从根源上改变应用支持流程。同时,针对核心业务细节和所支撑的数据信息,进行了全局调研并归纳到知识库。综合统一的知识库,降低了知识传递、理解、维护和迭代成本。

    统一归口策略包含业务归口统一、设计归口统一和应用归口统一,从底层保证了数仓建设的三特性三效果

    统一数据出口

    数仓建设不仅仅是为了数据内容而建设,同时也为了提高交付的数据质量与数据使用的便利性。如何保证数据质量以及推广数据的使用,我们提出了统一数据出口策略。在进行数据资产管理和统一数据出口之前,必须高质量地保障输出的数据质量,从而树立OneData数据服务体系的权威性。

    1. 交付标准化

    如何保证数据质量,满足什么样的数据才是可交付的,是数据建设者一直探索的问题。为了保证交付的严谨性,在具体化测试方案之前,我们结合数仓的特点明确了数据交付标准的五个特性,如下图所示:

    《交付标准化》完善了整个交付细节,从根本上保证了数据的质量,如:业务测试保障数据的合理性、一致性;技术测试保障数据的唯一性、准确性;数据平台的稳定性和后期人工维护保障数据的及时性。

    2. 数据资产管理

    针对如何解决数据质量中维度与指标一致性以及如何提高数据易用性的问题,我们提出数据资产的概念,借助公司内部平台工具“起源数据平台”实现了整个数据资产管理,它的功能如下图所示:

    借用起源数据平台,我们实现了:

    1. 统一指标管理,保证了指标定义、计算口径、数据来源的一致性。
    2. 统一维度管理,保证了维度定义、维度值的一致性。
    3. 统一数据出口,实现了维度和指标元数据信息的唯一出口,维值和指标数据的唯一出口。

    通过交付标准化和数据资产管理,保证了数据质量与数据的易用性,同时我们也构建出OneData数据体系中数据指标管理的核心。

    三、实践的成果

    流程改善

    我们对开发过程进行梳理,服务于整个OneData体系。对需求分析、指标管理、模型设计、数据验证进行了改善,并结合OneData模型策略,改善了数仓管理流程。

    数仓全景图

    基于OneData主题建设,我们采用面向业务面向分析的建设策略,形成数仓全景图,如下图所示:

    资产管理列表

    基于起源数据平台形成的资产管理体系,如下图所示:

    项目收益

    基于OneData建设成果,我们结合实际项目建设样例,对比以前未进行OneData建设时的收益。如下图所示:

     

    四、总结和展望

    我们结合了OneData核心思想与特点,构建一种稳定、可靠的基础数据仓库,从底层保障了数据质量,同时完成OneData实践,形成自有的OneData理论体系。

    未来,我们还将在技术上引入实时数据仓库,满足灵活多样、低延时的数据需求;在业务层面会横向拓展其他业务领域,不间断地支撑核心业务的决策与分析。下一步,我们将为企业级数据中台(以Data As a Service为理念),提供强有力的数据支撑。在后续数仓维护过程中,不断地发现问题、解决问题和总结问题,保障数据稳定性、一致性和有效性,为核心业务构建价值链,最终形成企业级的数据资产。

    参考:https://blog.csdn.net/fenglei0415/article/details/102640743

    展开全文
  • 如何使用阿里的OneData方法论

    千次阅读 2020-10-26 07:00:00
    点击上方“蓝字”关注我吧!#本文参考:美团OneData建设探索之路1背景由于前期缺少规划,随着集团业务发展,暴露的问题越来越多,给数据治理工作带来了很大的挑战,在数据仓库建设过程中,主...

    点击上方“蓝字”关注我吧!

    #本文参考:美团OneData建设探索之路

    1

    背景

    由于前期缺少规划,随着集团业务发展,暴露的问题越来越多,给数据治理工作带来了很大的挑战,在数据仓库建设过程中,主要发现了以下几个问题:

    • 缺乏统一的标准,如:开发规范、指标口径等。

    • 缺乏统一数据质量监控,如:字段数据不完整和不准确,数据发散等。

    • 业务知识体系混乱,导致数据开发人员开发成本增加。

    • 数据架构不合理,层级之间分工不明显,数据流向混乱。

    • 缺失统一维度和指标管理。

    2

    目标

    基于公司现有的数据平台,完善数据体系架构、数据规范、模型标准和开发模式,从而驱动业务快速发展

    高人力成本、数据错误、浪费资源、杂乱无章、效率低下,这些经常出现的痛点,OneData都能轻松解决

    1

    核心思想

       从设计,开发和使用上保障规范和统一,实现数据资产全链路管理,提供标准的数据输出,包含数据规范定义,数据模型设计规范,ETL规范

    2

    核心特点

    3

    策略

    3

    应用

    1

    统一规范

    数据来源于业务并支撑着业务的发展。因此,数仓建设的基石就是对于业务的把控。基于互联网行业的特点,基本上采用需求推动数据的建设,这也带来了一些问题,包括:数据对业务存在一定的滞后性;业务知识沉淀在各个需求里,导致业务知识体系分散。针对这些问题,我们提出统一业务规范,构建全局知识库,进而保障对业务认知的一致性。

    设计统一规范

    为了解决数据仓库建设过程中出现的各种痛点,我们从模型与规范两个方面进行建设,并提出设计统一规范。

    1.模型

    规范化模型分层、数据流向和主题划分,从而降低研发成本,增强指标复用性,并提高业务的支撑能力。

    (1) 模型分层

    优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长。结合这些原则及以往的工作经验,在数仓层面,我们将分层进行统一定义为四层:

    (2) 模型数据流向

           重构之后,业务按照标准的数据流向进行开发,即ODS->DWD->DW->DWS->ADS。在保障了数据链路的合理性之后,又在此基础上确认了模型分层引用原则:

    • 正常流向:ODS->DWD->DW->DWS->ADS,当出现ODS->DWD->DWS->ADS这种关系时,说明主题域未覆盖全。应将DWD数据落到DW中,对于使用频度非常低的表允许DWD->DWS。

    • 尽量避免出现DWS宽表中使用DWD又使用(该DWD所归属主题域)DW的表。

    • 同一主题域内对于DW生成DW的表,原则上要尽量避免,否则会影响ETL的效率。

    • DW、DWS和ADS中禁止直接使用ODS的表, ODS的表只能被DWD引用。

    • 禁止出现反向依赖,例如DW的表依赖DWS的表。

    2.主题划分

    • 面向业务:按照业务进行聚焦,降低对业务理解的难度,并能解耦复杂的业务。我们将实体关系模型进行变种处理为实体与业务过程模型。实体定义为业务过程的参与体;业务过程定义是由多个实体作用的结果,实体与业务过程都带有自己特有的属性。根据业务的聚合性,我们把业务进行拆分,形成了几个核心主题。

    • 面向分析:按照分析聚焦,提升数据易用性,提高数据的共享与一致性。按照分析主体对象不同及分析特征,形成分析域主题在DWS 进行应用,例如用户分析域、订单分析域。

    3.规范

    模型是整个数仓建设基石,规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,我们统一按照最详细、可落地的方法进行规范建设。

    (1) 词根

    词根是维度和指标管理的基础,也是表字段命名的参考

    (2) 表命名规范

    通用规范

    • 表名、字段名采用下划线分隔词根(consultorder->consult_order)

    • 每部分使用小写英文单词,属于通用字段的必须满足通用字段信息的定义。

    • 表名、字段名需以字母为开头。

    • 表名、字段名最长不超过64个英文字符。

    • 优先使用词根中已有关键字(数仓标准配置中的词根管理),定期Review新增命名的不合理性。

    • 在表名自定义部分禁止采用非标准的缩写。

    表命名规则

    ods dwd层

    • 建表表名一律小写

    • 表名命名规则: [层次].[业务]_[表内容]_[周期+处理方式]

    dw dws层

    • 建表表名一律小写

    • 表名命名规则: [层次].[主题]_[表内容]_[周期+处理方式]  主题在dw层以后,表内容 参考业务系统表名,做适当处理,分表规则可以没有

      如:wedw_ods.test_order_info_df

      wedw_ods表示层次,test表示主题,order_info表示表内容,d表示周期()f表示处理方式(全量抽取)

    • 临时表命名规则:[层次].tb_目标表名_程序开始执行时间_序号

    (3) 指标命名规范

    结合指标的特性以及词根管理规范,将指标进行结构化处理。

    A. 基础指标词根,即所有指标必须包含以下基础词根:

    B.日期修饰词,用于修饰业务发生的时间区间。

    C.聚合修饰词,对结果进行聚集操作

    D. 基础指标,单一的业务修饰词+基础指标词根构建基础指标

    E. 派生指标,多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性.

    F.普通指标命名规范,与字段命名规范一致,由词汇转换即可以。

    G.日期类型指标命名规范,命名时要遵循:业务修饰词+基础指标词根+日期修饰词/聚合修饰词。将日期后缀加到名称后面,

    H.聚合类型指标,命名时要遵循:业务修饰词+基础指标词根+聚合类型+日期修饰词。将累积标记加到名称后面,

    2

    统一输出

    数仓建设不仅仅是为了数据内容而建设,同时也为了提高交付的数据质量与数据使用的便利性。所以我们交付出去的数据必须是符合标准的高质量的数据,必须做到准确性,完整性,关联性等标准

    数据质量满足以下几点是可以进行输出的

    1. 数据资产管理

    针对如何解决数据质量中维度与指标一致性以及如何提高数据易用性的问题,我们提出数据资产的概念,借助公司内部平台工具“大数据平台”实现了整个数据资产管理,它的功能如下图所示:

    借用大数据平台,我们实现了:

    • 统一指标管理,保证了指标定义、计算口径、数据来源的一致性。

    • 统一维度管理,保证了维度定义、维度值的一致性。

    • 统一维表管理,保证了维表及维表主键编码的唯一性。

    • 统一数据出口,实现了维度和指标元数据信息的唯一出口,维值和指标数据的唯一出口。

    3

    成就

    3.3.1优化开发流程

    我们对开发过程进行梳理,服务于整个OneData体系。对需求分析、指标管理、模型设计、数据验证进行了改善,并结合OneData模型策略,改善了数仓管理流程。

    1. 需求分析:明确口径,评估排期,需求正规流程提交

    2. 指标管理:完善指标命名规范,指标同名同义,指标与业务强相关,明确指标构成要素

    3. 模型设计:完善开发流程规范,标准化业务调研,知识库文档集中管理,建立模型评审机制

    4. ETL开发:ODS->DWD->DW->DWS->ADS 

    5. 数据验证:制定数据测试标准

    6. 任务调度:规范化调度参数配置

    7. 上线管理

    3.3.2资产管理列表

    基于数据平台形成的资产管理体系,如下图所示:

    4

    总结

    结合阿里的onedata方法论,我们构建了稳定成熟的基础数据仓库,并且从数据底层保证了数据质量,形成了我们自己的onedata理论体系

    未来,我们还将在内部引入flink,clickhouse等技术,搭建实时数仓,满足灵活多样,低延迟的数据分析

    在后续数仓维护过程中,不断地发现问题、解决问题和总结问题,保障数据稳定性、一致性和有效性,为核心业务构建价值链,最终形成企业级的数据资产。

    历史好文推荐

    1. 面试!什么是数据仓库?

    2. 面试,如何使用数据仓库?

    3. 面试,数据仓库的元数据包含哪些?

    4. 谈谈ETL中的数据质量

    展开全文
  • 阿里数据中台与OneData

    千次阅读 2019-11-13 17:16:37
    企业发展初期,数据研发是紧贴业务发展而演变的,数据体系基于业务单元垂直建立,...在建立OneData之前,阿里数据有30000多个指标,其中,即使是同样的命名,但定义口径却不一致。例如,仅uv这样一个指标,就有十...
  • 比如当时我们运营提了一个比较有指导意义的数据指标叫爆款率,我们以爆款率为例先说一下OneData每个步骤实施的流程和涉及的角色。业务口径应该由数据中台的产品经理主导,找到提出该指标的运营负责人沟通。首先要问...
  • 今天来介绍数据中台的第二篇,第二篇共分为三个大部分分别对应的是阿里的数据中台三大体系(阿里的数据中台体系架构见上一篇),OneData体系,OneEntity体系,OneService体系,三大体系相辅相成、相互依赖,OneData...
  • 数据仓库与数据中台(onedata)整理

    千次阅读 2019-08-05 18:00:13
    干货:解码OneData,传说中的阿里数据中台是如何练成的? https://yq.aliyun.com/articles/44991 阿里首次披露中台战略:OneData的统一数据标准和实时数据分析是核心 ... 从方法论到零售客户实践 解码阿里巴...
  • All O`one Data Structure题目解法1:暴力O(N)follow up:O(1)解法 题目 解法1:暴力O(N) class AllOne: def __init__(self): """ Initialize your data structure here. """ self.data = {} def inc...
  • 总第363篇2019年 第41篇在现有大数据平台的基础上,借鉴业界成熟OneData方法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变...
  • 432. All O`one Data Structure Implement a data structure supporting the following operations: Inc(Key) - Inserts a new key with value 1. Or increments an existing key by 1. Key is guarante
  • 本节先简单介绍业界常用的模型实施过程,然后重点讲解阿里巴巴OneData模型设计理论及实施过程。 1.业界常用的模型实施过程 **Kimball模型实施过程 ** Kimball维度建模主要探讨需求分析、高层模型、详细模型和模型...
  • 在现有大数据平台的基础上,借鉴业界成熟OneData方法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变化的业务并驱动业务的发展,最终形成我们自己的OneData理论体系与实践体系...
  • OneData即是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下,构建统一、规范、可共享的全域数据体系,避免数据的冗余和重复建设,规避数据烟囱和不一致性,充分发挥阿里巴巴...
  • 阿里巴巴 数据中台 — OneData体系方法论 第一个关键点:数据仓库规划和数据规范定义 基于业务但超越和脱离业务需求限制的抽象:例子 业务:电商 数据域:交易 业务过程:加入购物车 业务过程:下单 业务过程:...
  • 在现有大数据平台的基础上,借鉴业界成熟OneData方法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速支撑不断变化的业务并驱动业务的发展,最终形成我们自己的On...
  • 今天介绍OneData体系的第二部分,这部分主要的内容是从成本中心向资源中心转变的一个过程。这个过程的主要内容是有元数据做底层构建的。核心思想是将存储和计算成本与数据的价值挂钩,形成数据资产的概念。简单的...
  • 一个layout标签只能有一个直接子元素 原因:控件,如TextView并列跟ViewGroup如LinearLayout在一起了 解决:将控件放进ViewGroup中或是在外围增加一个ViewGroup
  • 22.Identify the logical structure that will never have more than one data segment created for it.
  • end Flink 从入门到精通系列文章 基于 Apache Flink 的实时监控告警系统关于数据中台的深度思考与总结(干干货)日志收集Agent,阴暗潮湿的地底世界 公众号...
  • 阿里巴巴高级技术专家王赛先生将作为DTCC2016中国数据库技术大会特邀嘉宾出席。并将于5月13日“数据挖掘&BI”专场分享题为《OneData-数据模型设计与管理》的演讲,敬请...
  • public class AllOne { /** Initialize your data structure here. */ public AllOne() { } int Inc = 0; HashMap,Set<String>> hm = new HashMap();//key是字符串的次数,set放这个数量的字符串 Has
  • All O`one Data Structure

    2016-12-11 18:23:02
    /** Returns one of the keys with Minimal value. */ string getMinKey() { return buckets.empty() ? "" : *(buckets.rbegin()->keys.begin()); } private: struct Bucket { int val; unordered_set<string>...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 139,966
精华内容 55,986
关键字:

OneData