品《阿里巴巴大数据实践-大数据之路》一书(下)

今天继续谈阿里的这本书,包括数据服务平台、数据挖掘平台、数据建模、数据管理及数据应用,希望于你有启示。

1、数据服务平台

数据服务平台可以叫数据开放平台,数据部门产出海量数据,如何能方便高效地开放出去,是我们一直要解决的难题,在没有数据服务的年代,阿里的数据开放的方式简单、粗暴,一般是直接将数据导出给对方,我想,现在大多公司的开放应该也是如此吧,虽然PaaS喊了这么多年,但真正成就的又有几个?

即使如阿里,在数据开放这个方向上的探索和实践,至今也有7个年头了,任何关于数据开放毕其功于一役的做法都将失败,任何一次数据开放的改进都是伴随着对于业务理解的深入而成长起来的。

阿里的数据开放经历四个阶段,DWSOA、OpenAPI、SmartDQ和OneService:

DWSOA:是数据服务的第一个阶段,也就是将业务方对数据的需求通过SOA服务的方式暴露出去,由需求驱动,一个需求开发一个或者几个接口,编写接口文档,开放给业务方调用。

这种架构简单,但接口粒度很粗,灵活性不高,扩展性差,复用率低,随着业务需求的增加,接口的数量大幅增加,维护成本高企,同时,开发效率不高,一个接口从需求开发到上线,按阿里说法至少1天,其实远远不止,如果要变更1-2个字段,也要走一整套流程,这应是大多数公司的常态。

OpenAPI:DWSOA的明显问题是烟囱式开发,很难沉淀共性数据,OpenAPI将数据按照统计粒度进行聚合,同样维度的数据,形成一张逻辑表,采用同样的接口描述,针对某一类的查询,只需要调用一个接口即成,这种形式可以有效收敛接口,笔者公司对外服务很多也是这种形式,比如通过封装几十个位置服务API,统一对外提供灵活查询能力,但其实复杂逻辑的接口还是需要采用一事一议的方式,即第一种方式。

SmartDQ:数据维度是非可控的,随着数据的深度使用,OpenAPI显然会急剧增加,维护映射的压力会很大,阿里于是再抽象一层,用DSL(Domain Specific Language,领域专用语言)来描述取数需求,支撑标准的SQL,至此,所有的简单查询服务减少到另一个接口,这降低了数据服务的维护成本。

传统的方式查问题需要查源码,确认逻辑,而SmartDQ只需要检查SQL的工作量,并可以开放给业务方通过写SQL的方式对外提供服务,SmartDQ封装了跨域数据源和分布式查询功能,通过逻辑表屏蔽了底层的物理表细节,不管是HBASE还是MySQL,是单表还是分库分表,这极大简化了操作的复杂度。

其实中国移动经营分析规范很早就提出了即席查询、伪代码等的封装方式,笔者企业也通过自助取数的方式在实践,阿里在落地上做的比较好,其是集大成者,传统企业的大数据类产品往往只能在单点实现突破,无法用一只团队始终如一的坚持做一个产品,比如企业的自助取数平台在设计时没想到需要支撑大数据时代的跨异构数据库,由于当初的自助取数团队和当前的DACP的团队完全是两拨人,很难实现既有能力的传承。

阿里的思路说不上很超前,但它不仅落地了,而且在不停演进,这也许就是企业自主研发的价值,它的产品始终流着同样的血液。

OneService:SQL显然无法解决复杂的业务逻辑,SmartDQ其实只能满足简单的查询服务需求,正如我们的自助取数也仅能满足50-60%的临时取数一样,企业遇到的场景还有以下几类:个性化的垂直业务场景、实时数据推送服务、定时任务服务,OneService主要是提供多种服务类型来满足客户需求,分别是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。

Lego被设计成一个面向中度和高度定制化数据查询需求,支持插件机制的服务容器,笔者理解就是提供定制环境和暴露接口,你要怎么做就怎么做。

iPush应用产品是一个面向TT、MetaQ等不同消息源,通过定制过滤规则,向Web、无线等终端推送消息的中间件平台。

Utiming是基于在云端的任务调度应用,提供批量数据处理服务,支撑用户识别、用户画像、人群圈选三类服务的离线计算以及服务数据预处理、入库,这个感觉是非常个性化的一个应用。

2、数据挖掘

阿里构建了一套架构于阿里云MaxConpute、GPU等计算集群之上,汇聚了阿里大量优质的分布式算法,包括数据处理、特征工程、机器学习算法、文本算法等,可高效完成海量、亿级维度数据的复杂计算,同时提供一套极易操作的可视化编辑页面,大大降低了数据挖掘的门槛,提高了建模效率。

其选择的计算框架是MPI,其核心算法都是基于阿里云的MaxCompute的MPI实现的。

其算法平台也集成了绝大部分业界主流的机器学习算法。

让笔者有点吃惊的是阿里还搞了数据挖掘中台,这个笔者以前也想做过,但后来发现跟数据仓库的融合模型(比如宽表)有很多类似之处,因此没坚持下去。

阿里将数据中台分为三层:特征层(FDM)、中间层和应用层(ADM),其中中间层包括个体中间层(IDM)和关系中间层(RDM),如下图所示:

FDM层:用于存储在模型训练常用的特征指标,这个跟融合模型的宽表类似,笔者很好奇阿里的数据仓库的DWS仅仅是汇聚层还是包括了宽表,否则跟这个FDM是有很大雷同的。

IDM层:个体挖掘指标中间层,面向个体挖掘场景,用于存储通用性强的结果数据,其实在笔者看来就是通用标签库的源表,那个ADM就是个性标签的源表,不知道有没理解对。

数据挖掘这一章很短,缺乏一些细节,想来跟部门的定位有关,数据挖掘一般应用导向,核心的东西大多可能掌握在各类业务部门的挖掘师手中,笔者对于数据挖掘中台的实际价值还是有疑问的,毕竟挖掘千变万化,数据仓库建模好理解,但数据挖掘搞中台如何能跟得上变化?

3、数据模型

数据建模在这本书占据了三分之一篇幅,可见其重要性,首先谈谈阿里数据模型的历史吧,其实跟笔者还有很多渊源,因为2005-2007年间为公司服务的某合作伙伴大量BI人员跳槽到了阿里,据说构建了阿里的一代数据仓库系统,这些人员很多跟笔者共事过,现在读来,还是有点感慨。

(1)   历史发展

第一阶段:完全应用驱动的时代,数据完全以满足报表需求为目的,将数据以与源结构相同的方式同步到Oracle,这跟笔者当年刚进公司的情况类似。

第二阶段:随着阿里业务的快速发展,数据量飞速增长,性能成为一个较大问题,需要通过一些模型技术改变烟囱式的开发模型,消除数据冗余,提升数据一致性,来自传统行业的数据仓库工程师开始尝试架构工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团,构建出一个四层的模型架构,即ODL(数据操作层)+BDL(基础数据层)+IDL(接口数据层)+ADL(应用数据层)。ODL与源系统一致,BDL希望引入ER模型,加强数据的整合,构建一致的基础数据模型,IDL基于维度模型方法构建集市层,ADL完成应用的个性化和基于展现需求的数据组装,这个对应笔者所在企业的当前的ODS,DWD,DWA/DWI及ST层,但阿里在构建ER时碰到了较大的挑战,主要是业务快速发展,人员快速变化、业务知识功底的不够全面,导致ER模型产出困难。

阿里得出了一个结论:在不太成熟、快速变化的业务层面,构建ER模型的风险很大,不太适合去构建ER模型,说的有点道理,比如运营商业务相对比较稳定,国际上也有一些最佳实践,从概念-领域-逻辑-物理的全局把控上还能应对,但面对变化,的确有其限制。

第三个阶段:阿里业务和数据飞速发展,迎来了hadoop为代表的分部署存储计算的快速发展,同时阿里自主研发的分布式计算平台MaxCompute也在进行,因此开始建设自己的第三代模型架构,其选择了以Kimball的维度建模为核心理念的模型方法论,同时进行了一定的升级和扩展,构建了阿里巴巴集团的公共层模型数据架构体系。

阿里模型分为三层:操作数据层(ODS)、公共维度模型层(CDM)和应用数据层(ADS),模型层包括明细数据层(DWD)和汇总数据层(DWS)。

ODS:把操作系统数据几乎无处理的存放到数据仓库系统中。

CDM:又细分为DWD和DWS,分别是明细数据层和汇总数据层,采用维度模型方法作为理论基础,更多采用一些维度退化方法,将维度退化至事实表中,减少事实表和维表的关联,提高明细数据表的易用性,同时在汇总数据层,加强指标的维度退化,采取更多的宽表化手段构建公共指标数据层,提升公共指标的复用性。

ADS:存放数据产品个性化的统计指标数据,根据CDM与ODS加工生成。

具体见如下模型架构图:

关于模型的分层每个行业都可以基于自己的实际去划分,没有所谓的最佳实践,比如笔者所在的企业,源端维度一致性非常好,DWD主要做标准化工作,屏蔽ODS变化导致的上层改动,关于维度建模的理念更多体现在DWA/DWI层中。

(2)   模型实施

OneData是阿里的模型设计理论,我觉得写得很好,你看完这个过程,基本会搞清楚维度建模的各个步骤,强烈建议结合后面的维度和事实表建模进行精读,主要步骤如下:

数据调研:业务调研需要对业务系统的业务进行了解,需求分析则是收集分析师运营人员对数据或者报表的需求,报表需求实际是最现实的建模需求的基础。

架构设计:分为数据域划分和构建总线矩阵,数据域划分是指面向业务分析,将业务过程或者维度进行抽象的集合,业务过程可以概括为一个个不可拆分的行为事件,如下单、支付等。构建总线矩阵需要明确每个数据域下游哪些业务过程,业务过程与哪些维度相关,并定义每个数据域下的业务过程和维度。

规范定义:规范定义主要定义指标体系,包括原子指标、修饰词、时间周期和派生指标,关于指标的规范定义阿里有单独的一节描述,大家可以好好学习一下,很多时候细节决定成败。

模型设计:模型设计主要包括维度及属性的规范定义、维表、明细事实表和汇总事实表的模型设计。

最后,用一张图镇楼,这张图可值回书价哦。

本书后面用两大节来介绍维度设计和事实表设计,由于过于细节,笔者就不再展开了,如果你是建模人员,一定要好好看看,也可以参考《数据仓库工具箱-维度建模权威指南》这本书,一般在建模过程中你碰到的很多问题它都有解决策略,你未来可能碰到的建模问题,这本书也提及了很多,是建模人员的宝贵的实战参考材料。

4、数据管理

数据管理涉及的东西很多,这本书具体提到了元数据、计算管理、存储和成本管理和数据质量,相对内容比较单薄,我挑两点说一下:

一直听说阿里财大气粗,所有数据都永久保留,其实是谬传,人家也是节约过日子的,看下图你就知道了:

应对层出不穷的数据和应用,数据工程师其实很难确认哪些数据是最重要的,需要优先保障,阿里巴巴提出了数据资产等级的方案,旨在解决消费场景知晓的问题,其将数据划分为五个等级,毁灭性质、全局性质、局部性质、一般性质及未知性质,代号从A1到A5。

那么如何个每份资产打上等级标签呢,就是借助强大的元数据能力,了解哪些表服务于哪些数据产品,基于血缘分析可以讲整个消费链路上打上某一类资产的标签,假如将阿里巴巴生意参谋定位等级A2,则所有相关链路的表的等级都是A2,从而启动对应的保障措施,这个跟笔者企业的大数据保障方法类似,从应用重要程度确定表的保障等级。

5、数据应用

阿里主要介绍了对外的数据产品平台生意参谋和服务于内部的数据产品平台。

生意参谋本质上就是为自己的渠道提供的增值服务,是很成功的一款决策支持产品,体现了一个产品如何从小做起,逐步长成一个庞然大物的过程:

对内数据产品的演进几乎是每一个公司BI系统的发展翻版,但显然它已经长成大树了,从临时取数阶段,到自动化报表阶段(比如BIEE),再到自主研发BI阶段(第三方满足不了自己了),最后到数据产品平台(更加体系化)。

当前阿里的数据产品平台,包括PC和APP版本,共有四个层次,即数据监控、专题分析、应用分析及数据决策。

到这里,基本就读完了,整本书都是经验之谈,读下来闪光频现,建议可以多读几遍。

这本书也引发了笔者一些思考,为什么他们能做成?我们传统企业大数据的差距在哪里?是机制流程问题?数据产品的传承问题?合作伙伴的问题?核心能力自控问题?业务对于数据产品的驱动力问题?小步快跑落地问题?企业产品的规划问题?

有些遗憾的是,这本书更多是就技术谈技术,鲜有数据内容方面的深度阐述,跟直接的价值创造还有距离,比如标签库的管理,核心算法研究,DMP怎么做的等等,当然这个可能跟阿里的大数据管理组织分工有关系,也涉及企业的一些商业秘密。

其实要想了解的东西还有很多,包括机制流程,团队分工,部门协同,中台战略在大数据的落地等等,希望有机会学习。

期盼有更多的企业能分享他们在大数据方面的实践经验,这对提升国内整体大数据管理水平很重要。

品《阿里巴巴大数据实践-大数据之路》一书(上)

转自与数据同行公众号

阿里巴巴大数据-玩家社区 /

---阿里大数据博文,问答,社群,实践,有朋自远方来,不亦说乎……

时间: 2017-08-21

品《阿里巴巴大数据实践-大数据之路》一书(下)的相关文章

品《阿里巴巴大数据实践-大数据之路》一书(上)

7月有人推荐阿里巴巴刚出的这本书<阿里巴巴大数据实践-大数据之路>,到亚马逊一看才是预售状态,拍下直到8月才拿到. 翻看目录一看,欢喜的很,正好出差两天就带在身边,由于在机场滞留超过12个小时,就把它读完了. 用"品"字有以下几个原因,一是市面上充斥着太多的大数据平台技术的书,诸如hadoop,spark等占据了大部,但对于如何管好大数据却缺乏真知灼见,二是这本书的确干货很多,诚意实足,明显来自阿里实操人员的经验,从作者是阿里巴巴数据技术与产品部就可知道,三是内容跟笔者的专

阿里巴巴大数据实践之数据建模

随着DT时代互联网.智能设备及其他信息技术的发展,数据爆发式增长,如何将这些数据进行有序.有结构地分类组织和存储是我们面临的一个挑战. 为什么需要数据建模 如果把数据看作图书馆里的书,我们希望看到它们在书架上分门别类地放置:如果把数据看作城市的建筑,我们希望城市规划布局合理:如果把数据看作电脑文件和文件夹,我们希望按照自己的习惯有很好的文件夹组织方式,而不是糟糕混乱的桌面,经常为找一个文件而不知所措. 数据模型就是数据组织和存储方法,它强调从业务.数据存取和使用角度合理存储数据.Linux的创始

阿里首度公开大数据系统架构《大数据之路:阿里巴巴大数据实践》来了

絮絮叨叨了很久,说阿里数据要出书.每天被催,什么时候写好,什么时候出版.终于,千呼万唤始出版了!!!! 点击阅读详情,即刻试读!!!   曾鸣教授作序 CSDN.ChinaUnix.ITPUB.segmentfault多家技术社区联名力荐 阿里巴巴官方首度公开大数据系统架构与技术细节 <大数据之路--阿里巴巴大数据实践>预售了 书籍内容简介 在阿里巴巴集团内,数据人员面临的现实情况是:集团数据存储已经达到EB级别,部分单张表每天的数据记录数高达几千亿条:在2016年"双11购物狂欢节

[连载]《大数据之路:阿里巴巴大数据实践》之日志采集

作者简介 阿里巴巴数据技术及产品部.定位于阿里集团数据中台,为阿里生态内外的业务.用户.中小企业提供全链路.全渠道的数据服务.作为阿里大数据战略的核心践行者,致力于"让大数据赋能商业,创造价值".现在,阿里巴巴数据技术及产品部正通过技术和产品上的创新,探索全域数据的价值,将阿里在大数据上沉淀的能力对外分享,为各行各业的发展带来更多可能性. 本章内容摘要 数据采集作为阿里大数据系统体系的第一环尤为重要.因此阿里巴巴建立了一套标准的数据采集体系方案,致力全面.高性能.规范地完成海量数据的采

【直播回顾】通过MaxCompute Studio实践大数据时代的DevOps

内容简介:阿里云大数据平台 MaxCompute 系统为开发者提供全托管的.PB 级的数据仓库解决方案,MaxCompute Studio 是 MaxCompute 新推出的数据集成开发环境(IDE),为开发者提供了 数据开发调试 - 命令行工具集成 - 自助作业分析诊断 的全面解决方案. 我将通过 MaxCompute Studio 的智能代码编辑能力.数据管理及浏览能力.作业可视化和自助诊断能力等展现 MaxCompute 平台的数据开发和部署的强大和敏捷性. 观众受益:带领大家实现数据仓库

阿里巴巴高级技术专家朱震杰:御膳房——探索大数据开放处理平台之路

大流量高并发互联网应用实践在线峰会官网:https://yq.aliyun.com/activity/112 峰会统一报名链接:http://yq.aliyun.com/webinar/join/49 议题名称:<御膳房:探索大数据开放处理平台之路> 议题简介:本次演讲将重现御膳房在探索大数据开放处理平台的道路上,面临的用户的迫切需求和技术架构上以及安全上的强大挑战,通过大家的努力,逐步构建起可满足用户多层次数据加工需求的立体化的安全平台. 听众收益: 1)了解御膳房的技术演进之路: 2)了解

MaxCompute大数据实践,电商数据仓库选择雪花还是星型模型?

作者:王永伟 规范化和反规范化   当属性层次被实例化为一系列维度,而不是单一的维度时,此模式被称为雪花模式.大多数联机事务处理系统(OLTP)的底层数据结构在设计时采用此种规范化技术,通过规范化处理将重复属性移至其自身所属的表中,删除冗余数据.   此种方法用在OLTP系统中可以有效避免数据冗余导致的不一致性.比如在OLTP系统中,存在商品表和类目表,且商品表中冗余有类目表的属性字段,假设对某类目进行更新,则必须更新商品表和类目表,且由于商品和类目是一对多的关系,商品表可能每次需要更新几十万甚

MaxCompute大数据实践,电商数据仓库的星型模型和传统星型的区别

作者:王永伟   在Kimball所著的<数据仓库工具箱>一书中,对于维度模型设计采用的4步设计方法:1.选择业务过程 2.声明粒度 3.确定维度 4.确定事实. 在当前的互联网大数据环境下,面对复杂的业务场景,为了更有效准确地进行维度模型建设,基于Kimball的4步维度建模方法,我们进行了更进一步的改进. 第一步:选择业务过程及确定事实表类型 在明确了业务需求以后,接下来需要进行详细的需求分析,对业务的整个生命周期进行分析,明确关键的业务步骤,从而选择与需求有关的业务过程. 以淘宝的正向订

品友互动与亚信数据合作大数据实验室

文章讲的是品友互动与亚信数据合作大数据实验室,近日,中国最大的程序化购买DSP平台品友互动宣布与全球领先的通信行业IT解决方案和大数据技术公司亚信数据独家成立"大数据联合实验室",该实验室已于近日正式运转.该大数据联合实验室旨在结合双方在大数据营销和运营商资源.云计算等方面优势,研究运营商级别数据在数字广告领域的创新应用与实践. 如何在保护用户个人隐私的前提下,合法高效地帮助运营商数据参与到大数据营销环节中,真正激活用户数据的商业价值,是一个非常有挑战且有价值的课题,对于推动程序化广告