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

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

1、数据服务平台

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

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

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

e331f7bee4fb6bb806f1b55e91fee5770741fb47

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

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

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

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

eebc00a20c373bc02b424e53c25b7defe5f0f0ec

传统的方式查问题需要查源码,确认逻辑,而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、数据挖掘

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

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

2078d4f5d3cd7c8f910399c3f414bda903fe8aa8

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

fea99148d504d720a4f71c434a4d776b24d35502

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

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

fee1b55aa4a66b66124bcf4e4ec7317c8e9b739a

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加工生成。

具体见如下模型架构图:

83dbcea994184e95f524410c57fc218f15380752

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

(2)   模型实施

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

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

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

04d4712543e68923e5e9f2a54ebac229a222bc39

a3791d9923b432b3a612120742de8f48742896e4

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

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

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

afccf7c5962cef942665e9d15c233a4386848e80

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

4、数据管理

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

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

cc31fcb6eddde483143b7b6a4ef46420f6e50504

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

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

5、数据应用

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

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

bd89b6bc444390d350a13e9802c1fe471ab9311a

0a6875dd01f58861b9305af2759113c3133e465b

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

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

1fe9f37f9355285b1076fad5476eda3428607239

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

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

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

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

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


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


阿⾥巴巴⼤数据之路 阿⾥巴巴⼤数据之路——数据技术篇 数据技术篇 ⼀、整体架构 ⼀、整体架构      从下⾄上依次分为数据采集层、数据计算层、数据服务层、数据应⽤层    数据采集层:以DataX为代表的数据同步⼯具和同步中⼼    数据计算层:以MaxComputer为代表的离线数据存储和计算平台    数据服务层:以RDS为代表的数据库服务(接⼝或者视图形式的数据服务)    数据应⽤层:包含流量分析平台等数据应⽤⼯具 ⼆、数据采集(离线数据同步) ⼆、数据采集(离线数据同步)   数据采集主要分为⽇志采集和数据库采集。⽇志采集暂略(参考书籍原⽂)。我们主要运⽤的是数据库采集(数据库同步)。   通常情况下,我们需要规定原业务系统表增加两个字段:创建时间、更新时间(或者⾄少⼀个字段:更新时间)   数据同步主要可以分为三⼤类:直连同步、数据⽂件同步、数据库⽇志解析同步   1.直连同步     通过规范好的接⼝和动态连接库的⽅式直接连接业务库,例如通过ODBC/JDBC进⾏直连     当然直接连接业务库的话会对业务库产⽣较⼤压⼒,如果有主备策略可以从备库进⾏抽取,此⽅式不适合直接从业务库到数仓的情景   2.数据⽂件同步     从源系统⽣成数据⽂本⽂件,利⽤FTP等传输⽅式传输⾄⽬标系统,完成数据的同步     为了防⽌丢包等情况,⼀般会附加⼀个校验⽂件 ,校验⽂件包含数据量、⽂件⼤⼩等信息     为了安全起见还可以加密压缩传输,到⽬标库再解压解密,提⾼安全性   3.数据库⽇志同步     主流数据库都⽀持⽇志⽂件进⾏数据恢复(⽇志信息丰富,格式稳定),例如Oracle的归档⽇志   (数据库相关⽇志介绍,参考:)    4.阿⾥数据仓库同步⽅式     1)批量数据同步     要实现各种各样数据源与数仓的数据同步,需要实现数据的统⼀,统⼀的⽅式是将所有数据类型都转化为中间状态,也就是字符串类型。以此来实现数据格式的统⼀。     产——阿⾥DataX:多⽅向⾼⾃由度异构数据交换服务产,产解决的主要问题:实现跨平台的、跨数据库、不同系统之间的数据同步及交互。     产简介:     开源地址:     更多的介绍将会通过新开随笔进⾏介绍!(当然还有其他主流的数据同步⼯具例如kettle等!)     2)实时数据同步     实时数据同步强调的是实时性,基本原理是通过数据库的⽇志(MySQL的bin-log,Oracle的归档⽇志等)实现数据的增量同步传输。     产——阿⾥TimeTunnel(简称TT)。TT产本质是⼀个⽣产者、消费者模型的消息中间件     3)常见问题       1.增量数据与全量数据的合并         主要的场景是数据同步中周期全量同步,对应的解决⽅案是每次只同步变更的数据,然后和上⼀周期合并,形成最新的全量数据(选择此⽅案的原因是绝⼤多 数⼤数据平台不⽀持update操作)         具体的⽅案主要有union的联合操作(可以通过⽣成增量中间表detal)与阿⾥主推的全外连接full outer join+全量覆盖insert overwrite的形式。实例参考如下: SQL的Join语法有很多, inner join(等值连接) 只返回两个表中联结字段相等的⾏, left join(左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录, right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录, 假设我们有两张表。Table A 是左边的表。Table B 是右边的表。其各有四条记录,其中有两条记录name是相同的,如下所⽰: A表 id name 1 Pirate 2 Monkey 3 Ninja 4 Spaghetti B表 id name 1 Rutabaga 2 Pirate 3 Darth Vade 4 Ninja 让我们看看不同JOIN的不同。 FULL [OUTER] JOIN (1) SELECT * FROM TableA FULL OUTER JOIN TableB ON TableA.name = TableB.name TableA.name = TableB.name 的情况,A和B的交集有两条数据,那么 FULL OUTER JOIN的结果集, 应该是2+2+2=6条,即上⾯的交集,再加剩下的四条数据,没有匹配,以null补全。 结果集 (TableA.) (TableB.) id name id name 1 Pirate 2 Pirate 2 Monkey null null 3 Ninja 4 Ninja 4 Spaghetti null null null null 1 Rutabag
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值