《大数据大创新:阿里巴巴云上数据中台之道》:解密阿里数据中台建设(1)

文章目录

一、前言

早在今年四月份,便看完了《大数据之路:阿里巴巴大数据实践》一书,再迅速过了邓中华老师这本《大数据大创新:阿里巴巴云上数据中台之道》,基本上可以窥见阿里数据中台的建设过程以及一些技术细节。其中宗华作为一位阿里老数据人的经验分享和心路历程,更是让我这个后辈受益匪浅。

在这里插入图片描述

二、大数据的发展历程和价值探索

从大数据的概念被正式提出,到马老师预言人类从IT时代走向DT时代,大数据浪潮迭起。

身为大数据开发者,我认同并且深信的一点就是,大数据一定会对社会创新、产业变革、业务创新及每个人的角色定位都会产生近乎决定性的影响。

在这里插入图片描述
阿里的云上数据中台,是历经阿里生态内各种业态挑剔的实战历练,云上数据中台除了自身具备的内核能力外,还向上与“赋能业务前台”连接,向下与“统一计算后台”连接,并与之融为一体,形成云上数据中台业务模式,因此也具备了对全社会赋能的可能。

2.1 大数据发展的关键事件

接下来简单介绍下国内外大数据发展的关键事件:
在这里插入图片描述
这其中重要的一点需要了解,那就是2003年谷歌公开了著名的“三驾马车”—内部对于海量文件的处理技术、GFS分布式文件系统、并行计算处理框架MapReduce、高效数据存储模型BigTable,这些促成了分布式系统基础架构—Hadoop,为各个大数据组件的诞生打下基础。

2.1 大数据的内涵和外延

酝酿20年才发展起来的大数据技术,究竟会给现实世界带来怎样的改变?可以探索的大数据市场又在哪里?书中从以下四个方面进行了介绍。

  • 语义层面:‘数据’即所有信息的记录,例如用户访问网站的信息的转化过程的行为属性;大是巨量的意思,可以隐身为数量、形式、含义的丰富,保障实现被高保真的记录与回放
  • 实现层面:大数据是一套数据处理技术活方法体系,实现具体以上特征的数据的存储、计算、共享、备份和容灾、保密等,保证数据处理的时效性和拓展性
  • 服务层面:大数据的数据技术变革引发的新型信息服务模式,例如从数据探索出发,系统主动推送信息给用户做决策、给及其优化参数、基于数据的量变完成数据的质变
  • 应用层面:大数据是数据服务组合生成的新场景、新体验、日益增长的数据量非但不会使信息获取效率降低、质量下降,反而会让每个人都能得到快速的迭代,个性化的互联网服务。

三、阿里的大数据主张

在数据提供服务的基础上,阿里对数据的要求是准、快、全、统、通,简单的解释是标准统一融会贯通、资产化、服务化、闭环自优,这是阿里数据中台实现目标的核心。

3.1 云上数据中台赋能业务运行图

在这里插入图片描述
在这张运行图中,我们需要理解四个关键词:数据全面、数据打通、数据统一以及数据的闭环优化。

要实现上面的目标,如何做呢?

图片展示了数据中台运行的过程,主要抽象成三个部分。但在阿里最新的OneData方法论中,则是划分为OneID、OneModel、OneService。

  • 第一部分:OneModel 致力于实现数据的标准与统一。
  • 第二部分:OneID 致力于实现实体的统一,让数据融通而非以孤岛存在,为精准的用户画像提供基础。
  • 第三部分:OneService 致力于实现数据服务统一,让数据复用而非复制。
3.2 阿里数据中台赋能业务全景图

在这里插入图片描述
在架构图中,看到最下面的内容主要是数据采集和接入,按照业态接入数据(比如淘宝、天猫、盒马等),把这些数据抽取到计算平台;通过OneData体系,以“业务板块+分析维度”为架构去构建“公共数据中心”。

基于公共数据中心在上层根据业务需求进行建设:消费者数据体系、企业数据体系、内容数据体系等。

经过深度加工后,数据就可以发挥其价值被产品、业务所用;最后通过统一的数据服务中间件“OneService”提供统一数据服务。

四、阿里云上数据中台的建设过程

4.1 烟囱式开发造成业务困扰和技术浪费

阿里的数据中台治理主要是在2014年开始的,在2014年以前,阿里的大数据建设处于烟囱式开发状态,这样的开发带来了许多业务的困扰和资源的浪费。如图,是2014年以前的阿里巴巴分业务自建数据体系的抽象图。

在这里插入图片描述
不难看出,阿里的每一块业务都有对应的ETL开发团队为其提供数据支持,而每个ETL开发团队都会按照自己的思路建设自己的数据体系,可见:

  • 数据流向会乱,无方向性的
  • 数据管理式无序的,处于失控状态
  • 除了浪费研发人力和计算存储资源、也必然满足不了业务的需求

当然,这个问题被放大式在本身业务以极快的速度发展的前提下,这样的开发导致的问题我们从两个方面来看。

业务困扰

在混乱的开发中,会造成诸多的数据问题,如因为指标的定义问题,导致同一指标有多个数据,最常见的指标为UV,总结最业务的困扰主要一下三点:

  • 数据统一:数据标准规范难(命名不规范、口径不统一、算法不一致),数据任务响应慢,从而导致业务部门产生困扰而导致不满。
  • 数据未打通:各个数据团队各自为政,存在严重的数据孤岛现状;缺乏数据融通,数据价值发掘不够,从而导致业务部门看不清数据。
  • 成为成本中心且服务化不足:数据无方向性,依赖混乱,,数据管理无序,失控,成本化严重,面向应用的服务化投入不足甚至缺失。

技术困扰

浪费主要分两方面看,一方面是开发人力技术的浪费,开发人员日常在数据异常排查和数据调研上疲于奔命。另外一个是计算存储资源的浪费,在没有公共层的情况下,数据重复存储和计算非常常见。简单的总结为一下的三点:

  • 研发苦恼:烟囱式开发周期长、效率低。
  • 维护困难:源系统乎或业务变成不能及时反应到数据上,加之数据不标准,不规范,上线难,下线更难。
  • 时效性差:重复建设导致任务链路冗长、任务繁多,计算资源紧张;数据批量计算慢,时效性不强且覆盖 业务范围窄,即时查询返回结果慢。
4.2 数据公共层力求让业务和技术都满意

从上面的问题来看,数据的公共层建设是一件迫在眉睫的事情,那么数据公共层建设到底该如何进行,建设之前又要如何准备。这里就是OneData体系建设数据建设篇,OneData体系的主要四个组成部分为:

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

四个部分的运行图如下:

在这里插入图片描述

这些规范肯定是会与时俱进地被调优,但大部分的内容至今仍具有重要的指导意义,特别式其中的数据规范定义和数据模型设计,它们也因此被保留在从2016年开始再次升级的OneData体系中。

在这里插入图片描述

具体的OneData体系的方法论,包含三个关键点分别是数据仓库规划、数据规范定义、数据模型设计,这里我们不介绍技术细节,我在《大数据之路:阿里巴巴大数据实践》:看阿里人从IT时代走向DT时代的经验之谈!里都有讲述,大家可以自行学习。

4.3 阿里云上数据中台三大体系

在这里插入图片描述
经过多年实战,沉淀出了阿里云上数据中台内核能力框架体系:产品+技术+方法论。

历经阿里生态内各种实战历练后,云上数据中台从业务视角而非纯技术视角出发,智能化构建数据、管理数据资产,并提供数椐调用、数据监控、数据分析与数据展现等多种服务。

承技术启业务,是建设智能数据和催生数据智能的引擎。在OneData、OneEntity、OneService三大体系,特别是其方法论的指导下,云上数据中台本身的内核能力在不断积累和沉淀。在阿里巴巴,几乎所有人都知道云上数据中台的三大体系,如上图所示。

在这里插入图片描述
(OneEntity,现在应该是OneID,讲数据从多终端、全渠道被采集到,并,与“人”相关的数据ID就有:业务账号信息、PC cookie、无线imei与idfa等设备标志、身份属性信息),这些信息加剧数据孤岛的形成,我们通过OneID进行打通。这里涉及OneID的设计,二维关系的构建和倒排表等,我会在后面阿里数据中台的文章中再详细讲述。

以下便是通过OneID构建的人物画像:

在这里插入图片描述

OneData致力干统一数据标准,让数据成为资产而非成本;OneEntity(OneID)致力于统一实体,让数据融通而以非孤岛存在;OneService致力于统一数据服务,让数据复用而非复制。

这三大体系不仅有方法论,还有深刻的技术沉淀和不断优化的产品沉淀,从而形成了阿里巴巴云上数据中台内核能力框架体系。

4.4 阿里数据中台及赋能业务模式支撑

在这里插入图片描述
阿里数据中台,经历了所有阿里生态内业务的考验,包括新零售、金融、物流、营销、旅游、健康、大文娱、社交等领域。

数据中台除了建立起自已的内核能力之外,向上赋能业务前台,向下与统一计算后台连接,融为一体。

4.5 数据中台技术的数字表现

在这里插入图片描述
今天,阿里处理的数据量已达EB级,相当于10亿部高清电影的存储量。在 2016年双十一当天,实时计算处理的数据量达到9400万条/秒。而从用户产生数据源头采集、整合并构速数据、提供数据服务,到前台展现完成仅需2.5秒。

"友盟+”是阿里把收购的几家数据公司整合升级后,组成的一家数据公司。这里仅以2017年“友盟+”对外公开的部分指标为例,其中的数据覆盖14亿部活跃设备、685 万家网站、135万个应用程序,日均处理约280亿条数据,这一切都建立在阿里强大的数据处理技术底座之上。

4.6 数据中台六大数据技术领域

在这里插入图片描述
阿里建设数据公共层之初,规划了六大数据技术领域,即数据模型领域、存储治理领域、数据质量领域、安全权限领域、平台运维领域、研发工程领域。

而在阿里数据公共层建设项目第二阶段完成存储治理领域,已经被扩大到资源治理领域,进而升级到数据资产管理领域,安全权限领域,升级到数据信任领域,因为很多工作已经在产品中实现,平台运维领域不再作为一个数据技术领域被推进,数据模型领域与数据质量领域还在持续推进中,不过增加了许多新的内涵,智能黑盒领域则是新起之秀。

由此可见,数据技术领域不是一成不变的,而是随着业务的发展和技术的突破不断扩大、 升华的。

4.7 数据中台建设方法论

在这里插入图片描述

4.7.1 数据中台建设方法论体系的全局

(1) 全流程一体化:即从数据采集到数据服务实现全链路通。在产品层面,不会让用户在不同使用阶段来回切换于不同产品。

例如,用户要做实体识别、用户标签画像等,如果要依赖的数据在另外一个产品中, 甚至需要使用风格迥异的产品来完成,则用户会不知所措。所以,以数据建设为例,要实现数据从采集到标准化、实体识別、标签画像及最终面向应用的一站式服务。

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

.(img-qJGGjSLw-1714716730570)]

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

  • 11
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
阿⾥巴巴⼤数据之路 阿⾥巴巴⼤数据之路——数据技术篇 数据技术篇 ⼀、整体架构 ⼀、整体架构      从下⾄上依次分为数据采集层、数据计算层、数据服务层、数据应⽤层    数据采集层:以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、付费专栏及课程。

余额充值