分享

阿里技术



公众号:
ali_tech

功能介绍
阿里巴巴官方技术号,关于阿里技术创新

经典文章推荐:

1.如何解决大规模机器学习的三大痛点?

阿里妹导读:阿里巴巴电商平台有上亿的用户和产品,每天产生百亿规模的用户反馈数据。比如淘宝首页的猜你喜欢场景,每天就有100亿规模的用户行为数据。如此超大规模的训练数据,给分布式机器学习带来了巨大的挑战,也引入了有趣的研究问题。

2017年,阿里巴巴推荐算法团队和计算平台PAI团队合作打造了eXtreme Parameter Sever (XPS) 机器学习平台,其中eXtreme寓意为“追求极致”, 体现我们希望设计具有极致性能和效果的机器学习平台的愿景。XPS平台已经广泛全流量运行在手机淘宝的猜你喜欢、生活研究所、飞猪旅行和天猫推荐等大数据场景。

2017年双11购物狂欢节当天,小时级XNN模型在猜你喜欢和天猫推荐场景上线,稳定和快速地使用了用户双11的实时行为信息,显著提升了双11当天的收入和用户价值。在性能上,XPS平台上的例行算法,现在每天能轻松处理100亿规模样本1000亿规模的特征,算法运行速度快,容错能力强,资源利用率高。本文将对XPS平台的整体结构进行介绍,希望通过这些分享和大家交流我们在分布式算法设计和框架优化上的经验。

近年来,阿里巴巴个性化推荐和个性化搜索给用户带来了很好的体验,用户行为数量也随之大幅增长。特别是移动终端的业务飞速发展,用户和商品两个维度都呈现爆发式增长,用户和产品状态也随时间持续动态变化。在这种动态的超大规模的数据体量下,打造高效的分布式机器学习平台,精准预测用户对产品的点击率和转化率是非常有价值的,也是很有挑战的。

规模庞大且高频变化的特征和样本,给分布式机器学习平台的设计带来的挑战具体可以归结为样本、特征和分布式规模三个方面:

  • 在样本方面,我们每天面对的是百亿规模的训练数据,累计六个月的历史训练数据就超过了万亿规模。显然,传统的全量多轮迭代的机器学习算法已经不太适合这样规模的训练样本,因为这类算法需要消耗的计算资源极多,也无法很好地引入数据的时序性。


  • 在特征方面,大规模样本下特征总量轻易超过千亿量级,传统的特征编号方法需要消耗极多的机器资源和耗费很长的计算时间来完成特征编号,而且对新出现的特征也难以及时进行编号。从资源消耗和时间消耗上看,特征序列化编号方法已经是不可承受的步骤。此外,采用类似TensorFlow里通过string_to_hash_bucket的方法将特征映射到固定范围的做法,虽然保证固定了tensor的shape,减少了参数总量,但是在特征总数巨大的时候则又引入了大量的哈希冲突,影响了算法效果。


  • 在分布式规模方面,大规模特征下给Server的存储和分布式计算性能带来巨大压力。举例来说,1万亿个32位float浮点数就需要3.63TB的存储空间,再加上需要保留的历史梯度等,往往需要300到600台server才能使各个进程的内存占用控制在一个合理范围。Server数成倍增长,导致并行请求数也线性增长,给通信也带来较大压力。同时,存储量以及单任务进程数的增长,也给集群调度、容错、网络、IO带来较大的压力。


面对这些挑战,XPS平台提出了很多创新的技术来应对,向“极限参数服务器”的目标前进了一步:

  • 在样本处理问题上,我们采用流式学习算法为主的算法选型来解决大规模样本问题。在流式学习下,对每一批新数据,直接在当前模型上进行增量训练,并产出下一个模型,无需加载全量数据进行多轮全量学习。流式学习算法选型,平衡了数据规模和资源消耗问题,更轻量级地应对了大规模样本的问题;


  • 在特征处理问题上,采用了将特征哈希映射为哈希值的方法替代特征编号机制。在节省内存、提升性能的同时,支持了特征的动态稀疏化正则机制和表示向量维度的动态扩张机制,解决了特征总量过大的问题;


  • 在分布式规模方面,通过异步Checkpoint和Exactly Once Failover以及高性能的ArrayHashMap等机制,加上动态稀疏化正则机制等特征处理技术,保证了分布式训练的性能,提高了Server的存储效率。


面对这些大规模下的机器学习问题,eXtreme Parameter Server在阿里巴巴内部应运而生,针对性地解决了大规模样本和大规模特征的挑战,并得到了广泛的应用。

XPS在阿里巴巴内部的猜你喜欢、天猫、购物链路、飞猪、生活研究所、阿里妈妈等业务场景广泛应用,对用户点击率、线上收入提升、线上用户价值提升效果显著。

下面我们对XPS平台的系统结构和数据流程、分布式优化、核心算法和算子体系进行介绍。


更多点击链接

2.十年前,他如何自学技术进阿里?



准备工作

一年一度的校园实习招聘开始了,最近接触了几个找工作的应届生同学。这让我回想当年找工作的时候,遇到了很多好心人,所以一直想写写如何加入阿里的文章,算是对自己有一个交代,也希望能够帮助到找工作的同学。
序:一颗种子的种下
我的母校是四川师范大学,专业是教育技术,在大一下期的一堂专业课上网站设计,我的专业课老师在讲网站开发过程中使用数据库的时候,介绍了这个数据库的管理者DBA,在当今是属于比较稀缺的技术人员,他们随着经验的不断增加,所获得的报酬也将会越来越大。在当时很多学计算机的人都觉得做程序员是一门年青饭,所以我一下子被打动了,在心里暗暗就下定决心我毕业后就要做一位出色的DBA,专业老师的不经意一句话,就在我内心中种下了一颗种子,等待着时间发芽成长。
暑期自学数据库  
有了这样一个想法之后,暑假里我在图书馆里借几本数据库原理这本书,打算在暑假的时候开始自学数据库,但其实回想起来这些书都应该没有看懂。到了大二,开始到图书馆中去借各种各样的数据库技术书籍,2007年的时候Oracle还是非常流行的数据库,所以自然想成为一名Oracle DBA,依然还记得最早Oracle入门书籍看的是eygle盖国强写的书,他坚持不懈的撰写Oracle相关的技术文章,让当时一大批DBA爱好者受益匪浅。

更多点击链接

3.首次公开!深度学习在知识图谱构建中的应用



深度学习模型介绍

DeepDive系统在数据处理阶段很大程度上依赖于NLP工具,如果NLP的过程中存在错误,这些错误将会在后续的标注和学习步骤中被不断传播放大,影响最终的关系抽取效果。为了避免这种传播和影响,近年来深度学习技术开始越来越多地在关系抽取任务中得到重视和应用。本章主要介绍一种远程监督标注与基于卷积神经网络的模型相结合的关系抽取方法以及该方法的一些改进技术。

Piecewise Convolutional Neural Networks(PCNNs)模型

PCNNs模型由Zeng et al.于2015提出,主要针对两个问题提出解决方案:

  • 针对远程监督的wrong label problem,该模型提出采用多示例学习的方式从训练集中抽取取置信度高的训练样例训练模型。
  • 针对传统统计模型特征抽取过程中出现的错误和后续的错误传播问题,该模型提出用 piecewise 的卷积神经网络自动学习特征,从而避免了复杂的NLP过程。


下图是PCNNs的模型示意图:

1.png

PCNNs模型主要包括以下几个步骤:
2.png

3.png

实验证明,PCNNs + 多实例学习的方法 Top N 上平均值比单纯使用多示例学习的方法高了 5 个百分点。


更多点击链接

4.如何在阿里技术面试中脱颖而出?(内部资料)



招聘是团队管理者工作中的重要一环。本文会结合自己亲身经历以及接受的招聘培训,综合分析怎么找到我们要的人,也希望可以通过招聘这面镜子照亮自己,怎样成为一个更好的工程师。

招聘的目的

当今社会,技术已经成为影响商业成功的关键因素,工程师成为了这些公司最宝贵的财富,没有优秀的人组成团队来完成商业目标,公司根本不可能有今天的成就。所以招聘,就是选择最优秀的人。

招什么样的人?

招优秀的人显然是一个很模糊的概念,我们来度量的时候,我个人认为三个因素是最关键的:

  • 技能


工作项目经验,以及解决疑难问题的能力,毕竟招来的人首先必须很好的完成工作,这是最基本的要求,注意,是很好的完成,不是仅仅完成。

  • 潜力


这个概念看起来比较模糊,其实还是比较容易评价的,对计算机相关的专业的知识体系是不是完整,基础是不是扎实,平常是不是喜欢钻研,对这个世界充满好奇心,这几年走下来,沉淀的速度如何,都是判断一个人的潜力的方式,注意我们看潜力主要是基于候选人的之前的成长经历实事求是来看,过去的优秀经历才能给未来背书。潜力和技能的重要性一样重要,我们不能只看眼前,团队是需要不断发展和前进的,所以我们招人应该面向未来。

  • 软实力


软实力这里其实包含了性格,执行力,领导力等方方面面,它代表了候选人是否能快速融入团队,拿到结果,带领团队攻城拔寨,激励和影响身边的人变得更加优秀等等,软实力一般HR肯定会考察,虽然技术面不会特别去关注,但是从面试的过程中可以看出候选人的沟通能力,以及性格相关的特点,也值得我们注意。

说了这么多,其实在招人上有一个对比的标杆,就是你招的人是不是比团队中同一等级中50%的同学优秀,如果你觉得没有他们优秀,那不用纠结,这个候选人不要了,团队必须不停加入更好的同学,才能变得更加强大。


更多点击链接


5.阿里NIPS 2017论文解读:如何降低TensorFlow训练的显存消耗?


这篇介绍深度模型训练GPU显存优化的论文《TrainingDeeper Models by GPU Memory Optimization on TensorFlow》在NIPS 2017 ML Systems Workshop 中由作者做口头报告。这篇论文聚焦特征图,提出两种方法减少深度神经网络训练过程中的显存消耗,并且把这些方法的实现无缝整合到TensorFlow中,克服了TensorFlow训练大模型时无法有效优化显存的缺点。

近期深度学习在不同应用中发挥的作用越来越重要。训练深度学习模型的必要逻辑包括适合GPU的并行线性代数计算。但是,由于物理限制,GPU的设备内存(即显存)通常比主机内存小。最新的高端NVIDIA GPU P100具备12–16 GB的显存,而一个CPU服务器有128GB的主机内存。然而,深度学习模型的趋势是「更深更宽」的架构。例如,ResNet 包含多达1001个神经元层,神经网络机器翻译(NMT)模型包含8个使用注意力机制的层 ,且NMT模型中的大部分的单个层是按顺序水平循环展开的,难以避免地带来大量显存消耗。


简言之,有限的GPU显存与不断增长的模型复杂度之间的差距使显存优化成为必    然。下面将介绍深度学习训练流程中GPU显存使用的主要组成。

特征图(feature map)。对于深度学习模型,特征图是一个层在前向传输中生成的中间输出结果,且在后向传输的梯度计算中作为输入。图1是ResNet-50在ImageNet数据集上进行一次小批量训练迭代的GPU显存占用曲线。随着特征图的不断累积,曲线到达最高点。特征图的大小通常由批尺寸(batchsize)和模型架构决定(如CNN架构的卷积步幅大小、输出通道数量;RNN架构的门数量、时间步长和隐层大小)。不再需要作为输入的特征图占用的显存将会被释放,导致图1中显存占用曲线的下降。对于复杂的模型训练,用户必须通过调整批尺寸,甚至重新设计模型架构来避免「内存不足」的问题。尽管在分布式训练的情况下 ,训练任务可以分配到多个设备上来缓解内存不足的问题,但是这也导致了额外的通信开销。设备的带宽限制也可能显著拖慢训练过程。


1.png

图1:ResNet-50的显存占用在一个训练步中的变化曲线。横轴代表分配/释放次数,纵轴代表当前显存占用的总比特数。

权重。与特征图相比,权重占用内存相对较少 。在这篇论文中,权重作为GPU内存中的持久内存,只有整个训练任务完成后才可以被释放。

临时显存(Temporary memory)。一些算法(如基于Fast-Fourier-Transform(FFT)的卷积算法)需要大量的额外显存。这些显存占用是暂时的,在计算结束后立即得到释放。临时显存的大小可以通过在GPU软件库(如cuDNN)中列举每个算法来自动调整,因此可以被忽略。


很明显,特征图是GPU显存使用的主要组成部分。论文作者聚焦特征图,提出了两种方法来解决GPU显存限制问题,即通用的「swap-out/in」方法以及适用于Seq2Seq模型的内存高效注意力层。所有这些优化都基于TensorFlow 。TensorFlow具备内置内存分配器,实现了「best-fit with coalescing」的算法。该分配器旨在通过coalescing支持碎片整理(de-fragmentation)。但是,它的内置内存管理策略未考虑大模型训练时的显存优化。

该论文的贡献如下。聚焦于特征图,提出两种方法减少深度神经网络训练过程中的GPU显存消耗。基于数据流图的「swap-out/in」方法使用主机内存作为更大的内存池,从而放宽GPU显存上限的限制;而内存高效的注意力层可用来优化显存消耗量大的Seq2Seq模型。这些方法的实现被无缝整合到TensorFlow中,且可透明地应用于所有模型,无需对现有模型架构的描述作任何改变。









已有(2)人评论

跳转到指定楼层
howtodown 发表于 2018-4-3 18:27:46
如何降低90%Java垃圾回收时间?以阿里HBase的GC优化实践为例


阿里妹导读:GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。
过去的一年里,我们准备在Ali-HBase上突破这个被普遍认知的痛点,为此进行了深度分析及全面创新的工作,获得了一些比较好的效果。以蚂蚁风控场景为例,HBase的线上young GC时间从120ms减少到15ms,结合阿里巴巴JDK团队提供的利器——AliGC,进一步在实验室压测环境做到了5ms。本文主要介绍我们过去在这方面的一些工作和技术思想。
背景

JVM的GC机制对开发者屏蔽了内存管理的细节,提高了开发效率。说起GC,很多人的第一反应可能是JVM长时间停顿或者FGC导致进程卡死不可服务的情况。但就HBase这样的大数据存储服务而言,JVM带来的GC挑战相当复杂和艰难。原因有三:
1、内存规模巨大。线上HBase进程多数为96G大堆,今年新机型已经上线部分160G以上的堆配置
2、对象状态复杂。HBase服务器内部会维护大量的读写cache,达到数十GB的规模。HBase以表格的形式提供有序的服务数据,数据以一定的结构组织起来,这些数据结构产生了过亿级别的对象和引用
3、young GC频率高。访问压力越大,young区的内存消耗越快,部分繁忙的集群可以达到每秒1~2次youngGC, 大的young区可以减少GC频率,但是会带来更大的young GC停顿,损害业务的实时性需求。

思路

1.  HBase作为一个存储系统,使用了大量的内存作为写buffer和读cache,比如96G的大堆(4G young + 92G old)下,写buffer+读cache会占用70%以上的内存(约70G),本身堆内的内存水位会控制在85%,而剩余的占用内存就只有在10G以内了。所以,如果我们能在应用层面自管理好这70G+的内存,那么对于JVM而言,百G大堆的GC压力就会等价于10G小堆的GC压力,并且未来面对更大的堆也不会恶化膨胀。 在这个解决思路下,我们线上的young GC时间获得了从120ms到15ms的优化效果。

2.  在一个高吞吐的数据密集型服务系统中,大量的临时对象被频繁创建与回收,如何能够针对性管理这些临时对象的分配与回收,AliJDK团队研发了一种新的基于租户的GC算法—AliGC。集团HBase基于这个新的AliGC算法进行改造,我们在实验室中压测的young GC时间从15ms减少到5ms,这是一个未曾期望的极致效果。

下面将逐一介绍Ali-HBase版本GC优化所使用的关键技术。
消灭一亿个对象:更快更省的CCSMap

目前HBase使用的存储模型是LSMTree模型,写入的数据会在内存中暂存到一定规模后再dump到磁盘上形成文件。
下面我们将其简称为写缓存。写缓存是可查询的,这就要求数据在内存中有序。为了提高并发读写效率,并达成数据有序且支持seek&scan的基本要求,SkipList是使用得比较广泛的数据结构。
1.png

我们以JDK自带的ConcurrentSkipListMap为例子进行分析,它有下面三个问题:
1.  内部对象繁多。每存储一个元素,平均需要4个对象(index+node+key+value,平均层高为1)
2.  新插入的对象在young区,老对象在old区。当不断插入元素时,内部的引用关系会频繁发生变化,无论是ParNew算法的CardTable标记,还是G1算法的RSet标记,都有可能触发old区扫描。
3.  业务写入的KeyValue元素并不是规整长度的,当它晋升到old区时,可能产生大量的内存碎片。

问题1使得young区GC的对象扫描成本很高,young GC时晋升对象更多。问题2使得young GC时需要扫描的old区域会扩大。问题3使得内存碎片化导致的FGC概率升高。当写入的元素较小时,问题会变得更加严重。我们曾对线上的RegionServer进程进行统计,活跃Objects有1亿2千万之多!
分析完当前young GC的最大敌人后,一个大胆的想法就产生了,既然写缓存的分配,访问,销毁,回收都是由我们来管理的,如果让JVM“看不到”写缓存,我们自己来管理写缓存的生命周期,GC问题自然也就迎刃而解了。
说起让JVM“看不到”,可能很多人想到的是off-heap的解决方案,但是这对写缓存来说没那么简单,因为即使把KeyValue放到offheap,也无法避免问题1和问题2。而1和2也是young GC的最大困扰。
问题现在被转化成了:如何不使用JVM对象来构建一个有序的支持并发访问的Map。
当然我们也不能接受性能损失,因为写入Map的速度和HBase的写吞吐息息相关。
需求再次强化:如何不使用对象来构建一个有序的支持并发访问的Map,且不能有性能损失。
为了达成这个目标,我们设计了这样一个数据结构:
·      它使用连续的内存(堆内or堆外),我们通过代码控制内部结构而不是依赖于JVM的对象机制
·      在逻辑上也是一个SkipList,支持无锁的并发写入和查询
·      控制指针和数据都存放在连续内存中


更多点击链接

阿里90后工程师,如何用AI程序写出双11打call歌?


芦阳:把AI写歌儿这个事儿抽象起来看,其实是有一个模型,或者更通俗一点讲,是有一个函数。就像Y=WX+B,给一个X,就可以产出一个Y。所以,问题的关键是我如何抽象出这个函数,并使其尽可能的精准。

深度学习可以做到的是抽象模型。举例,我给出一段序列A作为X,给出一段序列B作为Y,它会通过不断的有监督学习从而获得函数Y=WX+B。接着,我又给出一段序列C作为X,给出一段序列D作为Y,它通过调整函数的参数尽力去满足A->B && C->D。当学习的量达到一定阶段的时候,模型也就基本可用了。

因此,我最终想要的效果是,一个比较合理的模型。这个模型可以做到,我给一个序列X,它可以去生成序列Y1,同时生成隐状态H1。接着,用Y1以及H1作为输入,继续生成Y2和H2,以此类推。最终达到所定义序列长度标准。

步骤为:

1. 收集歌词
2. 对歌词进行预处理,去除标点符号、特殊字符
3. 不断训练seq2seq模型
4. 使用模型产出歌词

收集歌词

我用Python爬取了XX音乐上的Hip-hop歌单,分析rapper如何押韵,收集到了几万首嘻哈歌词。

数据预处理

原始的歌词因为都是网友们上传上去的,所以格式并不完全统一,而且还会有一些非主流符号。因此,需要把所有歌词都进行同样的预处理,过滤了标点符号、特殊字符,写入到文件中,目的是使剩下的文本足够的整洁。



训练模型

首先是建立LSTM模型。

1.png

根据传入的引状态initial_state与序列inputs_split,执行rnn的decoder获得输出outputs_split。

2.png
把输出用softmax层处理,得到logits,与原本要学习的文本训练targets,计算总损失函数值total_loss。

3.png

循环去学习feed的文本,不断调整模型,降低损失函数值。


4.png

生成模型过程:

更多点击链接


深度 | 两个案例,掌握AI在大数据领域的前沿应用



如果大家对阿里巴巴的新闻比较关注,最近可能会频繁听到阿里巴巴谈到“五新”这个词,“五新”中的其中一个概念是新能源。其实新能源就是大数据本身。技术、数据和算法三个方面结合在一起,才可以把数据真正用起来。

1.png

大家都知道,Google的数据量很大,但是它的数据源本身其实比较单一。以Google  search,Google  map等为主导。再来看看Facebook,它更多的是社交行为数据,缺少出行数据、 浏览器数据、或者类似优酷的视听数据。但是,对于阿里来说,上述的这些数据我们都有。我们面临的极大挑战是:怎么样有效的把这些全域数据融合在一起。

首先我们需要把数据有效地收集起来。把数据有效地收集、存储起来之后,接着要做的就是怎么通过算法把这些数据打通,并且真正有效、智能地把这些数据提炼出来。

2.png

这是阿里的一个生态体系图。最底层是阿里云,这是我们的一个计算存储框架。上面是阿里妈妈,阿里妈妈是负责整个阿里巴巴计算广告的一个部门,再上面是菜鸟、支付宝和蚂蚁金服。然后是与电商业务相关的,像淘宝网、天猫、聚划算等等,或者是跟文娱相关的,优酷土豆,还有像阿里旅行,口碑之类的业态。

阿里巴巴数据中台要做的事情是什么呢?举一个最简单的例子,之前有一个比较火的电视剧《三生三世》。《三生三世》火热上映的时候,与之相关的商品元素,比如饮食或者穿戴之类的商品,也会瞬间在淘宝网上火爆起来。那么如果我提前就知道某一类人群是《三生三世》的粉丝,我就可以在淘宝网上做非常高效的、准确的定位推广。阿里数据要做的是:把数据真正打通,深度挖掘数据的价值,为业务创新应用提供数据决策基础和依据。

下面具体介绍一下数据融合的技术框架。因为在真正进入算法之前,我们一定要对数据进行非常认真、仔细地进行清洗过程。俗话说,如果你的数据不清洗,其实就是“learn trash from trash”。所以数据本身一定要做得非常干净。


更多点击链接

权威详解 | 阿里新一代实时计算引擎 Blink,每秒支持数十亿次计算



实时计算时代来临

随着互联网应用的普及、智能硬件的发展,数据的种类和规模都呈现了爆炸式的增长,各行各业都希望能够从大数据中发掘出更深层次的信息和知识,并产生实际价值。数据挖掘手段也逐渐从基本的数据统计向更高层次的机器学习和深度学习演变,但这些都需要强大的计算能力作为支撑,因此大数据价值的体现离不开大数据计算平台的发展。

目前大数据业界在计算技术上已经取得了显著的成果,例如:第一代开源的大数据处理技术Hadoop已经可以处理超大规模的数据集合,第二代开源的大数据处理技术Spark更好的利用了内存,并进一步加快了大数据处理的性能。

各大公司也都基于自身业务场景和数据规模定制了自己的大数据计算平台,但这些大数据计算平台大都是批处理系统,虽然具备海量数据处理能力,但在时效性上有明显的滞后。显然,数据的价值不仅体现在空间维度上,同时也在时间维度上进行伸展,很多场景下数据的价值也会随着时间的流逝而逐渐消失。因此,大数据计算平台需要能够尽可能的提升计算的时效性,越快地从数据中挖掘出信息就意味着能够获取到更大的价值。

时效性对数据价值的影响尤其在电子商务领域更加明显。通常人们在不同时刻会有着不同的消费需求和潜在目标。很多时候,这些需求和目标都是临时的(即和历史行为关联度较低),并且从产生到结束之间的时间是非常有限的。这种情况在阿里巴巴双十一大促这样的场景中表现的尤为明显。

大促场景下,用户会由于丰富的促销活动和环境而临时产生更多的购物需求,并且每个购物需求的有效期是有限的。因此,搜索和推荐系统需要及时发现用户的需求变化,在数据有效期内完成模型更新,推荐用户当前感兴趣的商品。此外,阿里巴巴的数据大屏也需要在大促期间实时展示成交额等大家关注的统计信息,而不是大促结束后第二天再让大家看到数据。

其实目前不仅在阿里巴巴,各个行业都对大数据时效性的计算需求在日益增加,因此,阿里巴巴需要研发世界级一流的流式计算引擎,实时处理海量数据,提供在线统计、学习和预测能力,不仅支持阿里巴巴自己的核心电商场景,同时也能通过阿里云向外部中小企业提供流式计算服务,输出实时计算能力,这就是我今天要分享的最新一代阿里巴巴实时计算引擎Blink。

流式计算介绍

显然批量计算模型是无法满足当前大数据实时计算需求的,只有流式计算模型才是实时计算的天然计算模型,因此我先介绍下流式计算的基本思想,尤其是区别于传统批量计算的一些概念。批量计算是对于有限固定的数据集合进行处理,流式计算是对无限数据流的处理,即计算无法确定数据何时会结束。从另一个角度看,批量计算其实也可以认为是流式计算的一种特例,因此批量计算可以看做是一个数据流中的片段,即有明确开始和结束标记的数据流,如下图所示:

1.png

完善的流式计算不仅应该提供实时计算能力,还应该支持计算过程中的状态管理,状态主要是指计算过程中需要的数据或者变量,例如:统计计算中的aggregation(sum/min/max…),机器学习中的feature和model,状态管理包括这些数据的存储、备份、恢复,版本管理,提供读写访问API,并保证一致性,如下图所示:

2.png


更多点击链接


阿里HBase超详实践总结 | 一文读懂大数据时代的结构化存储


前言
时间回到2011年,Hadoop作为新生事物,在阿里巴巴已经玩得风生水起,上千台规模的”云梯”是当时国内名声显赫的计算平台。
这一年,Hadoop的好兄弟HBase由毕玄大师带入淘宝,开启了它的阿里之旅。从最初的淘宝历史交易记录,到去年的支付宝消费记录存储在线历史存储统一;从蚂蚁安全风控的多年存储演进,到HBase、TT、Galaxy的大数据激情迭代;HBase在阿里经历过年轻的苦涩,释放过青春的活力,也付出过成长的代价。几代人的不懈努力下,五年陈的HBase开始表现出更成熟、更完善、更丰富的一面,成为公司内部被广泛使用的存储产品之一。
经过阿里集团内部的锤炼,集团将这个技术红利输送给广大阿里云客户。现已推出云数据库HBase产品,支持海量的PB级的大数据存储,适用于高吞吐的随机读写的场景。
本篇会系统性的阐述HBase的定位、建设思路,其中相关内容可能并未深入展开,后续会有专项介绍,请大家随时关注阿里技术相关文章。
概述
HBase是一个开源的非关系型分布式数据库(NoSQL),基于谷歌的BigTable建模,是一个高可靠性、高性能、高伸缩的分布式存储系统,使用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
HBase最初是以Hadoop子项目的形式进行开发建设,直到2010年5月才正式成为Apache的顶级项目独立发展。伴随着互联网时代数据的澎湃增长,HBase作为基础存储系统得到了快速发展与应用,大批知名商业公司(Facebook、Yahoo、阿里等)不自主地加入到了HBase生态建设队伍,成为Apache最活跃的社区之一。
HBase的能力特点,可以简单概括为下表,基于这些能力,其被广泛应用于海量结构化数据在线访问、大数据实时计算、大对象存储等领域。
1.png
阿里从2011年初开始步入HBase的发展、建设之路,是国内最早应用、研究、发展、回馈的团队,也诞生了HBase社区在国内的第一位Committer,成为HBase在中国发展的积极布道者。过去的几年时间,阿里累积向社区回馈了上百个Patch, 在诸多核心模块的功能、稳定性、性能作出积极重大的贡献,拥有多位Committer,成为推动HBase的长远发展的重要力量之一。
阿里是一家综合生态型公司,内部庞大业务矩阵高速发展,在基础存储方面,需要更好的功能灵活性、基础设施适应性、服务稳定性、效率成本。
因此,阿里HBase团队发展维护了HBase的内部分支,其基于阿里巴巴/蚂蚁金服的环境和业务需求,对社区HBase进行深度定制与改进,从软件系统、解决方案、稳定护航、发展支撑等全方位提供一站式大数据基础存储服务。
HBase在阿里的使用
Ali-HBase作为阿里巴巴技术大厦的基础存储设施,全面服务于淘宝、天猫、蚂蚁金服、菜鸟、阿里云、高德、优酷等各个领域,满足业务对于大数据分布式存储的基本需求。
在刚刚过去的2016年双11,HBase承载访问量达到了上百GB/秒(写入)与上百GB/秒(读取),相当于全国人民一秒收发一条短信,在业务记录、安全风控、实时计算、日志监控、消息聊天等多个场景发挥重要价值。面对如此规模的业务体量,阿里巴巴团队对于如何基于HBase打造稳定、高效、易用的存储服务,形成了一套完善的产品体系与实践经验,其整体大图如下:
2.png


总体上,我们以定制的软件内核为中心,建设质量平台、运维平台、业务平台和数据流设施四大内容,以支持业务对于基础数据服务的全方位需求。

接下来,本文会围绕可用性、数据流、性能优化等方面介绍最近的一些具体工作,希望能够给相关领域的同学带来一点帮助。

更多点击链接
[干货]基础机器学习算法


本篇内容主要是面向机器学习初学者,介绍常见的机器学习算法,当然,欢迎同行交流。
1.png
哲学要回答的基本问题是从哪里来、我是谁、到哪里去,寻找答案的过程或许可以借鉴机器学习的套路:组织数据->挖掘知识->预测未来。组织数据即为设计特征,生成满足特定格式要求的样本,挖掘知识即建模,而预测未来就是对模型的应用。
2.png
特征设计依赖于对业务场景的理解,可分为连续特征、离散特征和组合高阶特征。本篇重点是机器学习算法的介绍,可以分为监督学习和无监督学习两大类。


更多点击链接





回复

使用道具 举报

caiqingfei 发表于 2018-7-13 09:56:58
6666666666
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条