大數據

大數據

带你读《计算机网络原理》之一:计算机网络概述

高等院校精品课程系列教材点击查看第二章点击查看第三章计算机网络原理第2版王志文 陈 妍 夏 秦 何 晖 编著 第1章 计算机网络概述 1.1 计算机网络的定义 在计算机网络发展过程的不同阶段,人们对计算机网络提出了不同的定义。不同的定义反映着当时网络技术发展的水平,以及人们对网络的认知程度。这些定义从三种不同的观点来看待计算机网络,即广义的观点、资源共享观点与用户透明性的观点。从目前计算机网络的特点看,资源共享观点的定义能比较准确地描述计算机网络的基本特征。相比之下,广义的观点定义了计算机通信网络,而用户透明性的观点定义了分布式计算机系统。资源共享观点将计算机网络定义为 “以能够相互共享资源的方式互连起来的自治计算机系统的集合”。资源共享观点的定义符合目前计算机网络的基本特征,这主要表现在以下几个方面。1)计算机网络建立的主要目的是实现计算机资源的共享。计算机资源主要是指计算机硬件、软件与数据。网络用户不但可以使用本地计算机资源,而且可以通过网络访问联网的远程计算机资源,还可以调用网络中不同的计算机共同完成任务。2)互连的计算机是分布在不同地理位置的独立 “自治计算机”。互连的计算机之间没有明确的主从关系,每台计算机既可以联网工作,也可以脱离网络独立工作。联网计算机可以为本地用户提供服务,也可以为远程网络用户提供服务。3)联网计算机之间的通信必须遵循共同的网络协议。计算机网络是由多个互连的节点组成的,节点之间要做到有条不紊地交换数据,每个节点都必须遵守一些事先约定好的通信规则。这就和人们之间的对话一样,要么大家都说中文,要么大家都说英文,如果一个说中文,一个说英文,那么就需要找一个翻译人员。如果一个人只能说中文,另一个人又不懂中文,而又没有翻译人员,那么这两个人就无法进行交流。判断计算机是否互连成计算机网络,主要看它们是不是独立的 “自治计算机”。如果两台计算机之间有明确的主从关系,其中一台计算机能够强制另一台计算机开启与关闭,或者控制另一台计算机的自主运行,那么其中的受控计算机就不是 “自治”的计算机。根据资源共享观点的定义,由一个中心控制单元与多个从站组成的计算机系统不是一个计算机网络。同样,带有多个远程终端或远程打印机的计算机系统也不是一个计算机网络,只能称为联机系统(因为历史上的许多终端都不能算是 “自治计算机”)。但随着硬件价格的下降,许多终端都具有一定的智能,因而 “终端”和 “自治计算机”逐渐失去了严格的界限。因此,若把微型计算机作为终端使用,按上述定义,则早期的那种面向终端的计算机系统也可称为计算机网络。 “计算机通信”与 “数据通信”这两个名词在不同的领域经常混用。早期的数据通信与现代的计算机通信显然是有区别的。但随着技术的进步,数据通信的含义也在发生变化。因此,可以认为计算机通信与数据通信是可混用的名词,如美国的著名期刊《Data Communication》所刊登的文章现在也大多是计算机网络领域的文章。大多数情况下,数据通信网往往指的是计算机网络中的分组交换网络。对用户而言,计算机网络就是一种透明的传输机构,用户在访问网络共享资源时,无须考虑这些资源所在的物理位置。为此,计算机网络通常以网络服务的形式来提供网络功能和透明性访问。从上述计算机网络的定义中不难看出,它的核心功能就是资源共享,而我们经常提及的分布式系统也是为共享资源而提出的,二者究竟有何差异呢 计算机网络与分布式计算机系统虽然有相同之处,但二者并不等同。分布式计算机系统的主要特点是系统中的各计算机对用户是透明的。对用户而言,这种分布式计算机系统就好像是一台计算机一样,用户通过输入命令就可以运行程序,但用户并不知道是哪一台计算机在运行程序。实际上,是分布式系统在为用户选择最合适的计算机来运行其程序,并将运行的结果传送到合适的地方,而这些工作都不需要用户的干预。计算机网络则不同,用户必须事先明确登录要运行程序的计算机,然后按照该计算机的地址,将程序通过计算机网络传送到该目标计算机去运行。最后,根据用户的命令将结果传送到指定的计算机。由此可见,计算机网络不同于分布式计算机系统,二者的区别主要是软件的不同,尤其是应用软件方面表现得更为突出。一般说来,可以将分布式计算机系统看作计算机网络的一个特例。计算机网络已经存在了半个多世纪,为信息共享和人类交互提供了极大的方便,尽管时代的变迁使得计算机技术和网络通信技术发生了许多重大变化和进步,但它们在特定的领域总是表现出相似的变化过程。为此,一些专业人士提出了一系列关于IT技术变迁的论断和预言,其中最为著名的有下述四个。 Intel公司的创始人之一戈登·摩尔(Gordon Moore)先生在1964年曾预言:集成芯片的能力每18个月提高一倍,而其价格则降低一半,这就是著名的摩尔定律(Moore’s Law)。摩尔本人当初也没有预料到,这一预言一直延续到21世纪初仍然成立。 贝尔定律(Bell’s Law)作为对摩尔定律的补充,其核心思想是:如果保持计算机能力不变,微处理器的价格每18个月降低一半、体积每18个月减小一半。 […]

大數據

带你读《Apache Kylin权威指南》之一:Apache Kylin概述

大数据技术丛书点击查看第二章点击查看第三章Apache Kylin权威指南(第2版)Apache Kylin核心团队 著 第1章 Apache Kylin概述 Apache Kylin是Hadoop大数据平台上的一个开源的联机分析处理(Online Analytical Processing, OLAP)引擎。它采用多维立方体预计算技术,将大数据的SQL查询速度从之前的分钟乃至小时级别提升到亚秒级别,这种百倍、千倍的速度提升,为超大规模数据集上的交互式大数据分析奠定了基础。Apache Kylin也是第一个由中国人主导的Apache顶级开源项目,在国际开源社区具有极大的影响力。本章将对Apache Kylin的历史和背景做一个完整的介绍,并从技术角度对Kylin做一个概括性的介绍。 1.1 背景和历史 现今,大数据行业发展得如火如荼,新技术层出不穷,整个生态欣欣向荣。作为大数据领域最重要的技术的Apache Hadoop最初致力于简单的分布式存储,然后在此基础之上实现大规模并行计算,到如今在实时分析、多维分析、交互式分析、机器学习甚至人工智能等方面有了长足的发展。2013年年初,在eBay内部使用的传统数据仓库及商业智能平台碰到了“瓶颈”,传统架构只支持垂直扩展,通过在一台计算机上增加CPU和内存等资源来提升计算机的数据处理能力。相对于数据指数级的增长,单机扩展很快达到极限,不可避免地遇到了“瓶颈”。此外,Hadoop大数据平台虽然能存储和批量处理大规模数据,但与BI平台的连接技术还不够成熟,无法提供高效的交互式查询。于是,寻找到更好的交互式大数据分析方案成为当务之急。2013年年中,eBay 公司启动了一个大数据项目,其中有一部分内容就是BI on Hadoop的预研。当时,eBay中国卓越中心组建了一支很小的团队,他们在分析和测试了多种开源和商业解决方案后,发现没有一种方案能够完全满足当时的需求,即在超大规模数据集上提供秒级的查询性能,并基于Hadoop与BI平台无缝整合等。在研究了多种可能性后,eBay最终决定自己来实现一套OLAP-on-Hadoop的解决方案,以弥补业界的此类空白。与此同时,eBay也非常鼓励各个项目开源、回馈社区,在给负责整个技术平台的高级副总裁做汇报的时候,得到的一个反馈就是“从第一天起就做好开源的准备”。经过一年多的研发,2014年9月底,代号Kylin的大数据平台在eBay内部正式上线。Kylin在Hadoop上提供标准和友好的SQL接口,并且查询速度非常快,原本要几分钟才能完成的查询现在几秒钟就能返回结果,BI分析的工作效率得到几百倍的提升,获得了公司内部客户、合作伙伴及管理层的高度评价,一上线便吸引了多个种子客户。2014年10月1日,Kylin项目负责人韩卿将Kylin的源代码提交到github.com并正式开源。当天就得到了业界专家的关注和认可。图1-1所示为Hortonworks的CTO对Apache Kylin的Twitter评价。很快,Hadoop社区的许多朋友都鼓励eBay将该项目贡献到Apache

大數據

带你读《Apache Kylin权威指南》之二:快 速 入 门

点击查看第一章点击查看第三章 第2章 快 速 入 门 第1章介绍了Apache Kylin的概况,以及它与其他SQL-on-Hadoop技术的不同,相信读者对Apache Kylin有了一个整体的认识。本章将详细介绍Apache Kylin的一些核心概念,然后带领读者一步步创建Cube,构建Cube,并通过SQL来查询Cube,使读者对Apache Kylin有更为直观的了解。 2.1 核心概念 在使用Apache Kylin之前,需要先了解一下Apache Kylin中的各种概念和术语,为后续章节的学习奠定基础。 2.1.1 数据仓库、OLAP与BI 数据仓库(Data Warehouse)是一种信息系统的资料储存理论,此理论强调的是利用某些特殊资料储存方式,让所包含的资料特别有利于分析处理,从而产生有价值的资讯并依此做决策。利用数据仓库方式存放的资料,具有一旦存入,便不随时间变化而变动的特性,此外,存入的资料必定包含时间属性,通常,一个数据仓库会含有大量的历史性资料,并且它利用特定分析方式,从中发掘出特定的资讯。OLAP(Online Analytical Process),即联机分析处理,它可以以多维度的方式分析数据,并且能弹性地提供上卷(Roll-up)、下钻(Drill-down)和透视分析(Pivot)等操作,是呈现集成性决策信息的方法,其主要功能在于方便大规模数据分析及统计计算,多用于决策支持系统、商务智能或数据仓库。与之相区别的是联机交易处理(OLTP),联机交易处理侧重于基本的、日常的事务处理,包括数据的增、删、改、查。

大數據

带你读《Apache Kylin权威指南》之三:Cube优化

点击查看第一章点击查看第二章 第3章 Cube优化 Apache Kylin的核心思想是根据用户的数据模型和查询样式对数据进行预计算,并在查询时直接利用预计算结果返回查询结果。相比普通的大规模并行处理解决方案,Kylin具有响应时间快、查询时资源需求小、吞吐量大等优点。用户的数据模型包括维度、度量、分区列等基本信息,也包括用户通过Cube优化工具赋予其的额外的模型信息。例如,层级(Hierarchy)是用来描述若干个维度之间存在层级关系的一种优化工具,提供层级信息有助于预计算跳过多余的步骤,减少预计算的工作量,最终减少存储引擎所需要存储的Cube数据的大小。数据模型是数据固有的属性,除此之外,查询的样式如果相对固定,有助于Cube优化。例如,如果知道客户端的查询总是会带有某个维度上的过滤(Filter)条件,或者总是会按照这个维度进行聚合(Group By),那么所有的不带这个维度的场景下的预计算都可以跳过,因为即使为这些场景进行了预计算,这些预计算结果也不会被用到。总的来说,在构建Cube之前,Cube的优化手段提供了更多与数据模型或查询样式相关的信息,用于指导构建出体积更小、查询速度更快的Cube。可以看到Cube的优化目标始终有两个大方向:空间优化和查询时间优化。 3.1 Cuboid剪枝优化 3.1.1 维度的组合 由之前的章节可以知道,在没有采取任何优化措施的情况下,Kylin会对每一种维度的组合进行聚合预计算,维度的一种排列组合的预计算结果称为一个Cuboid。如果有4个维度,结合简单的数学知识可知,总共会有24=16种维度组合,即最终会有24=16个Cuboid需要计算,如图3-1所示。其中,最底端的包含所有维度的Cuboid称为Base Cuboid,它是生成其他Cuboid的基础。在现实应用中,用户的维度数量一般远远大于4个。假设用户有10个维度,那么没做任何优化的Cube总共会存在210=1024个Cuboid,而如果用户有20个维度,那么Cube中总共会存在220=1048576个Cuboid!虽然每个Cuboid的大小存在很大差异,但是仅Cuboid的数量就足以让人意识到这样的Cube对构建引擎、存储引擎来说会形成巨大的压力。因此,在构建维度数量较多的Cube时,尤其要注意进行Cube的剪枝优化。 3.1.2 检查Cuboid数量 Apache Kylin提供了一种简单的工具供用户检查Cube中哪些Cuboid最终被预计算了,将其称为被物化(materialized)的Cuboid。同时,这种工具还能给出每个Cuboid所占空间的估计值。该工具需要在Cube构建任务对数据进行一定的处理之后才能估算Cuboid的大小,具体来说,就是在构建任务完成“Save Cuboid Statistics”这一步骤后才可以使用该工具。由于同一个Cube的不同Segment之间仅是输入数据不同,模型信息和优化策略都是共享的,所以不同的Segment中被物化的Cuboid是相同的。因此,只要Cube中至少有一个Segment完成了“Save Cuboid Statistics”这一步骤的构建,那么就能使用如下的命令行工具去检查这个Cube中的Cuboid的物化状态:bin/kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader CUBE_NAME CUBE_NAME

大數據

基于归纳网络的少样本文本分类 | EMNLP 2019 会议论文解读

作者:耿瑞莹,黎斌华,李永彬,孙健 1.摘要 深度学习方法在数据稀缺的场景下往往表现很差,在这种挑战性的场景下,近期的工作往往使用meta-learning的方法来模拟少样本学习任务,通过在样本级别把query和支撑集进行比较来完成分类。但是这种样本级别的比较往往会被同一个类中各种不同的表述方式所干扰,因此我们需要为支撑集中的每个类别学习一种泛化的表示,然后去和query进行度量。在本工作中,我们提出了一个新的归纳网络(Induction Networks)来学习这样的一般化的类别表示,通过在meta learning的过程中引入动态路由算法(dynamic routing),我们的模型对于未见过的类别有良好的适应能力。我们在一个通用的英文基准数据集和一个真实场景的中文意图分类数据集上验证我们的模型,均取得了state-of-the-art的结果,证明了在少样本学习场景下学习类级别表示的有效性。 2.问题定义 少样本学习的的目标是模型在大量类别中学会通过少量数据正确地分类后,对于新的类别,只需要少量的样本就能快速学习。形式化来说,few-shot的训练集中包含了大量的类别,每个类别中有少量样本。在训练阶段,会在训练集中随机抽取C个类别,每个类别K个样本(总共C×K个数据)构建一个meta-task,作为模型的支撑集(Support set)输入;再从这C个类中抽取一批样本作为模型的询问集(Query set)。即要求模型从C×K个数据中学会如何区分这C个类别,这样的任务被称为C-way K-shot问题。 模型训练的过程中在每次迭代时把支撑集送入模型,并优化模型在询问集上产生的损失函数,这种训练方式一般称为Episode-based meta-training,详情见Algorithm 1。值得注意的是这种训练机制使得模型很难过拟合,假设我们训练集中包含159个类,可以产生( █(159@5))=794,747,031个不同的5-way 任务。 3.引言 少样本学习相关的研究致力于通过极少量的样本学习心得类别来解决数据缺失的问题,当数据量极少时,基于finetune的方法将难以生效,早期的工作使用数据增强和正则化来缓解数据不足时的过拟合问题,但是也只能在一定程度上有效。近期的工作往往基于meta learning的方法,把训练过程分解为一系列的meta-task,通过将训练过程的task和测试阶段的task定义一致,可以通过在不同的meta task之间切换来抽取一些可迁移的知识。因此few-shot

大數據

最佳实践 | RDS & POLARDB归档到X-Pack Spark计算

X-Pack Spark服务通过外部计算资源的方式,为Redis、Cassandra、MongoDB、HBase、RDS存储服务提供复杂分析、流式处理及入库、机器学习的能力,从而更好的解决用户数据处理相关场景问题。 RDS & POLARDB分表归档到X-Pack Spark步骤 一键关联POLARDB到Spark集群 一键关联主要是做好spark访问RDS & POLARDB的准备工作。 POLARDB表存储 在database ‘test1’中每5分钟生成一张表,这里假设为表 ‘test1’、’test2’、’test2’、… 具体的建表语句如下: *请左右滑动阅览 CREATE TABLE `test1` (

大數據

带你读《金牌电商客服实战》之一:金牌客服是如何炼成的

金牌电商客服实战 江南北商学院 组编高攀 等著 第1章 金牌客服是如何炼成的 1.1 电商客服岗前准备   2019年2月21日下午,商务部新闻发言人在介绍2018年我国网络零售市场发展情况时指出,2018年我国网络零售市场规模持续扩大,全国网上零售额突破9万亿元,其中,实物商品网上零售额达7万亿元,同比增长25.4%,对社会消费品零售总额增长的贡献率达到45.2%,较上年提升了7.3个百分点。  自2019年1月,《电子商务法》开始施行,在法律和监管的力量下,整个行业正朝着更加合法、合规的方向前进。  电子商务的快速发展也吸引了众多人才的不断涌入。据电子商务交易技术国家工程实验室、中央财经大学中国互联网经济研究院测算,2017年,中国电子商务从业人员达4250万人,成为一支庞大的就业群体。这个庞大群体中,兴起了一个极富生命力的新兴行业—网店客服。  客服是电商成交的关键,电商业务成功与否,与客服的工作息息相关。下面我们就一起系统地了解下电商客服。 1.1.1 电商客服岗位概述   首先我们思考一下为什么要学习电商客服这门课程呢?  随着电子商务的不断发展,网络购物平台交易竞争日趋激烈,商品的同质化及低价竟争日益激烈,如今的网购市场已经逐渐发展成由买方来主导其趋势。提供优质商品是每个商家的基本义务,但是顾客并不只满足于为产品本身买单,他们需要更加完美的购物体验,通常顾客会经过“搜索”→“单击”→“浏览”→“询单”等几个步骤,最终凭自己对产品及店铺的感受决定是否下单购买。也就是说,顾客的购物体验是决定其购买行为的重要因素。在整个网络交易过程中,电商客服作为直接通过平台交流软件,为客户提供服务和解决问题的人员,成为决定顾客购物体验优劣的重要角色。  在淘宝上,一年销售额为1000万元的电商企业,约有10个客服,平均每个客服能够创造100万元的流水额。一个熟练的客服可以同时和20位左右的客户沟通,行业内最高水平达到90人!从以上数据分析来看,伴随互联网+时代电子商务的飞速发展,客户服务岗位的人才缺口是巨大的。并且在网店经营岗位中,客服是必不可少的重要角色,如图1-1所示。 图1-1 客服的角色   对于一家店铺来说:客户看到的商品都是一张张的图片,既看不到商家本人,也看不到产品本身,无法了解各种实际情况,因此往往会产生距离感和怀疑感。这个时候,平衡顾客与店铺之间的利益,客服就显得尤为重要了。  客服的重要性具体来说主要体现在5个方面,如图1-2所示。 图1-2 客服的重要性   1.优化顾客的购物体验  客服作为一个直接影响顾客购物体验的岗位,对于店铺的整体运营具有很重要的意义。好的客服可以提高顾客的购物体验,顾客在与客服交流的过程中,通过客服耐心的询问、认真的倾听,主动为顾客提供帮助,让顾客享受良好的购物体验。  2.提升店铺的复购率  由于现在网络平台商品繁杂,顾客的搜索浏览成本也越来越高,所以,当顾客选择一家店铺以后,只要产品满意、服务贴心,一般不会轻易更换到其他店铺购买。因为更换到其他店铺会增加新的购物风险及时间成本。所以,良好的客户服务能有效地提高顾客对店铺的忠诚度,即提升店铺的复购率。  3.改善店铺服务数据  目前,天猫等电商平台会对店铺的服务质量有一系列的评分,当店铺评分不符合标准时,会影响其产品在搜索中的排名,以及参加活动的资质。因此商家会尽量保证自己店铺的服务类评分达到或者超过同行业的均值。客服岗位在售前和售后环节都会和顾客有亲密接触,因此客服服务质量的优劣会直接影响店铺服务类数据的分值。天猫店铺首页会显示店铺综合评分。如图1-3所示为某天猫店铺DSR(店铺评分系统)评分截图,顾客可以通过综合评分来判断店铺经营的状况,以及各种服务指标。平台也会在后台数据中考核店铺的综合评分,来判断店铺是否被广大顾客喜欢,是否值得把店铺推荐给平台的顾客。 图1-3 天猫店铺DSR评分   4.降低店铺经营风险  商家在开店当中难免会遇到包括退换货、退款、交易纠纷、顾客投诉、顾客给出不良评价、平台处罚,甚至欺诈、诈骗等经营风险。客服对产品熟悉,如果能够做到精准推荐,就会有效地控制退换货、退款,尽量避免交易纠纷;客服对规则熟悉,如果能够很好地应对顾客投诉,并且不触犯平台规则,就不会导致平台对店铺的处罚;客服积极、良好地与顾客沟通,就有可能降低顾客给出不良评价的状况发生;客服警惕性高,就可以避免发生店铺被少数不良分子敲诈而导致损失的情况。  5.提高流量价值  随着平台竞争越来越激烈,店铺引流成本越来越高,进入店铺的每一个流量对商家来说都是尤为重要的,都应该使之产生效益。而客服的优质服务有助于提高顾客的购买欲望,从而提高客单价,实现单个流量价值的最大化;客服的优质服务也有助于顾客多次复购或介绍他人在店铺中购物,从而把顾客单个流量的价值发挥到极致。这就是我们所说的提高流量价值。如图1-4所示为京东平台某时间段某店铺UV价值数据。

大數據

带你读《增强型分析:AI驱动的数据分析、 业务决策与案例实践》之一:数据科学家的成长之路

数据分析与决策技术丛书点击查看第二章点击查看第三章增强型分析:AI驱动的数据分析、业务决策与案例实践 彭鸿涛 张宗耀 聂磊 著 第1章 数据科学家的成长之路 一次偶然的机会,有一位正在深造机器学习方面学位的朋友问了笔者一个问题:如何成为一名合格的数据科学家?这个问题回答起来亦简亦难。简单回答的话可以拿出标准答案,坐而论道地说需要编程能力、数据操作能力、数学基础、算法库应用能力、算法调优能力与业务对接的能力等。但是这样的答案笔者其实是不满意的,因为有太多的技术意味。做数据分析、将数据的价值发挥出来,是一个“工程 + 科学”的过程,只要在这个过程中的任意一处找到自己的位置,就无谓数据科学家这种称号了。大数据时代方兴未艾,人工智能时代又呼啸而至。人们在很多场合下能看到诸多新应用,加之整个社会都在热切地拥抱人工智能技术,使得大家都相信人工智能时代势必会改变社会的方方面面,笔者对此也深信不疑。在人工智能时代,将数据的价值发挥出来的要素有资金、数据、平台、技术、人员等。数据科学家是人员要素中最为重要的部分,是需要企业非常重视的。在数据科学家自身发展的方向、组织结构,以及如何体现出价值等方面,相信大家肯定会有很多想法。笔者从十几年前加入IBM SPSS进入数据分析领域开始,至今担任过分析软件工具的开发者、解决实际业务问题的数据挖掘者、数据驱动业务以及数字化转型的咨询者等多种角色。反观这些年的成长路径,将一些较为重要的经验做一个粗浅的总结,抛砖引玉,以供读者参考。 1.1算法与数据科学家 我们随便打开一些教科书,会发现机器学习、人工智能、数据挖掘等经典领域所谈论的很多知识点是共通的,比如从历史数据中学习到事物模式并用于对未来做出判断,是机器学习中的重要内容,也是人工智能的重要方面,更是数据挖掘的重点内容。现在有一个很时髦的说法,认为机器学习是比数据挖掘更为高深的学科,实现人机对话那肯定是人工智能的范畴。其实,从一个更为宏观的视角来看的话,这几个学科都是在将数据的价值通过算法和算法的组合(数据分析的流程)发挥出来,没有一个清晰的标准说某类算法必须属于人工智能范畴、某类算法必须属于机器学习的范畴。 1.1.1数据科学、人工智能、机器学习等 有国外的学者试图给出一个机器学习、数据科学、人工智能等时髦名词之间关系的示意图,如图1-1所示,我们发现,这些学科间的关系可以说是交缠不清。 图1-1数据科学相关的学科之间的关系 笔者也就这些学科之间的关系进行了深入探索,查询了很多的资料,发现图1-1的中间部分,其实是来自SAS在1998年提供的数据分析的课程。除此之外,很少有人能将它们的关系说清楚,因为这本来就说不清楚。所以,对上图,读者只当其是一个参考即可。重点是图1-1所表达的含义:这些技术都是围绕“问题解决” →“分析” →“策略” →“领域知识” →“沟通” →“表达” →“探索”等问题来展开的,而这些问题都是人们在认识世界、解决问题时所涉及的方面。所以,本节采用图1-1想表达的含义也是如此:计算机的技术在迅猛发展,现在很多的技术都可以融合使用来解决复杂问题了;对于数据科学相关的这些技术,很多方面都是通用的。

大數據

EMR 打造高效云原生数据分析引擎

本场视频链接:EMR打造高效云原生数据分析引擎 本场ppt材料:https://www.slidestalk.com/AliSpark/2019___0926_110365 基于开源体系打造云上数据分析平台 客户选择开源方案的原因主要有以下几点: • 灵活多样的业务场景:目前即便是一个小企业,其数据存储也可能是多种多样的,比如业务数据、日志数据和图数据等,这种情况下,需要有一个高度定制化的系统来串联不同的业务场景;• 自己有专业的运维能力:开源系统有充足的人才储备,丰富的网上资料与开源的强大后盾,可以确保公司业务的顺利开展;• 多种业务需求vs成本压力:每种云上产品有自己的使用场景,对于中小企业来说购买多种云产品将会造成很大的成本压力,而通过开源体系维护一套系统,在集成用户业务中所需组件的同时,可以降低用户的成本。 下图是阿里巴巴EMR系统的产品架构图。用户上云的方式主要有两种,一种是购买ECS资源自己搭建一套开源系统;另一种是直接选择阿里巴巴的EMR系统。第一种方式由于开源系统组件多,涉及到了Spark、Hive、Flink和TensorFlow等,从零搭建一套完整的大数据系统对于用户来讲非常复杂,尤其是成百上千的集群规模也给运维造成了很大的挑战。而使用EMR系统具有以下优点:1) 阿里云EMR系统可以帮助用户一键化自动部署、配置相关组件,开箱即用,同时还会根据用户的机器类型进行参数的自动推荐调优。2) 阿里云EMR系统与阿里云其他产品实现了打通,比如数据存放在OSS,EMR系统无需额外再做认证配置,便可以很方便地读取OSS上的数据;3) 阿里云EMR系统集成了很多自研插件,这些插件在其他产品中是没有的;4) 阿里云EMR系统的所有组件兼容开源但优于开源,如Flink集成了阿里云自研的Blink和TensorFlow(PAI),这也是阿里云为社区做的一点贡献,目的是为了让用户能用到阿里云内部的技术;5) 阿里云EMR系统提供了全平台的作业诊断与告警组件APM来实现自动化运维,大大降低集群运维的复杂性;6) 阿里云EMR系统还与DataWorks对接,用户可以以DataWorks为入口,傻瓜式地使用EMR系统。 EMR系统的目标主要有以下三个: • 平台化:将EMR做成一个统一的云上数据分析平台,帮助用户打造全栈式的大数据解决方案,支持全系列VM容器化,提供企业级HAS和大数据APM;• 技术社区&深度:持续深耕技术社区,打造大数据友好的云 Native

大數據

阿里巴巴飞天大数据平台计算引擎MaxCompute最新特性

摘要:距离上一次MaxCompute新功能的线上发布已经过去了大约一个季度的时间,而在这一段时间里,MaxCompute不断地在增加新的功能和特性,比如参数化视图、UDF支持动态参数、支持分区裁剪、生成建表DDL语句功能等功能都已经得到了广大开发者的广泛使用。那么,近期MaxCompute究竟还有哪些新特性呢?本文就为大家揭晓答案。 以下内容根据视频以及PPT整理而成。 MaxCompute与阿里云大数据产品解决方案 在介绍MaxCompute新功能前,我们先快速对阿里云的大数据产品解决方案进行介绍,以便不熟悉MaxCompute的朋友能快速建立认知。阿里云大数据解决方案中包含了数据接入、数据存储及处理分析、数据服务以及在线应用等这样的几个维度。通常的情况下,基于MaxCompute和阿里云大数据解决方案搭建的系统会通过DataWorks实现离线多源异构数据的同步,并向MaxCompute大数据平台加载数据。与此同时,借助于DTS日志服务、Kafka消息队列服务实现对实时数据的收集。之后,通过流式计算服务实现对于数据的实时计算和分析,并将数据投递到实时在线的服务或者回流到统一的数据仓库服务中去。数据落盘保留下来之后,将进行数据仓库相关的处理分析,加工成为可以被业务消费、高质量的数据集。同时,利用机器学习平台可以开展包含数据准备、模型训练、模型部署在线推理在内的完整智能应用。 在数据服务(data serving)维度,阿里云大数据产品解决方案中也提供了多种的服务,包括了关系型数据库、分析型数据库、ES等,这些服务能够帮助用户加速在面向在线应用场景下的数据消费。同时,阿里云大数据产品解决方案还能够与阿里云线上的Quick BI、DataV以及第三方客户自行购买的BI等工具进行结合。在云上大数据场景下,DataWorks则承担的是整体的数据开发、编排调度以及数据管理的职能。 What’s New?MaxCompute产品近期发布预览 本次分享面对的主要群体是对于阿里云MaxCompute产品有所了解并且有一定使用经验的客户,因此所介绍的内容会比较细致,但不会过多展开相关背景及原理介绍,更多地会面向MaxCompute已有的问题以及新推出的特性本身进行分享。 近期以来,MaxCompute大约每三个月就会迭代一个大版本发布到线上,而中间则会有很多个小版本。到8月份的时候,已经距离上次MaxCompute线上发布会经过了大约一个季度的时间,因此需要再做一次新特性的发布。所以本次分享不仅涵盖了MaxCompute针对日常需求的功能发布,也包括了大版本发布的内容。 本次所要介绍的MaxCompute产品近期的发布情况主要包括三个部分,首先是近几个月已经陆续发布上线,并且产品文档已经完备的功能,希望希望通过本次介绍让开发者能够更好地了解这些新的功能;其次是目前MaxCompute在线上所正在做的大版本升级中已经实现的一批灰度升级项目,本次也会对于其中一些比较成熟的功能进行分享;最后就是一些即将面向更大规模的用户进行发布的功能,也就是目前还处于定向内测阶段的功能。 新Region开服:西南成都节点正式开服、国际Region提供Spark服务 随着阿里云西南成都节点的正式开服,大数据计算服务MaxCompute也正式在西南成都节点开服售卖。与此同时,MaxCompute也提供了很多国际的Region,阿里云根据用户需求的强烈程度优先在香港、德国、新加坡、印度和美西这五个国际Region推出了Spark服务。 新功能:SQL-参数化视图 MaxCompute近期发布上线的版本围绕着SQL核心功能的一些细节做了大量的优化和提升,其中一点就是参数化视图。MaxCompute传统的视图(VIEW)中实现了一定的封装与重用,但是并不接受调用者传递的任何参数,例如:调用者无法对视图读取的底层表进行数据过滤或传递其它参数,导致代码重用能力低下。MaxCompute近期发布上线的版本的SQL引擎支持带参数的视图,支持传入任意表或者其它变量来定制视图的行为,从而增强了视图的可用性和复用度。 新功能: SQL-UDTF/UDAF支持动态参数 新发布的MaxCompute版本的SQL能够支持UDF相关的动态参数。如下图中的代码所示,其中含有一个命名为JsonTuple的UDTF。这里JsonTuple的业务需求就是首先读取一个JSON串,其中包含了一系列JSON内容,并且需要解析其中某些节点的信息。 面对像JsonTuple这样的函数设计,虽然给定了一个JSON,但是可能需要根节点的参数,也可能需要根节点+子节点或者多个子节点的参数去提取并解析JSON字符串中的信息,此时就造成了函数的不确定性,因此函数最好能够支持用户动态的参数输入,也就是可以根据用户的动态参数输入提取相应的信息。MaxCompute的UTDF和UTAF在参数列表中支持使用*的模式,表示接受任意长度、任意类型的输入参数,从而满足了上述场景的需求。

Scroll to Top