如何降低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是使用得比较广泛的数据结构。
我们以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模型。
根据传入的引状态initial_state与序列inputs_split,执行rnn的decoder获得输出outputs_split。
把输出用softmax层处理,得到logits,与原本要学习的文本训练targets,计算总损失函数值total_loss。
循环去学习feed的文本,不断调整模型,降低损失函数值。
生成模型过程:
更多点击链接
深度 | 两个案例,掌握AI在大数据领域的前沿应用
如果大家对阿里巴巴的新闻比较关注,最近可能会频繁听到阿里巴巴谈到“五新”这个词,“五新”中的其中一个概念是新能源。其实新能源就是大数据本身。技术、数据和算法三个方面结合在一起,才可以把数据真正用起来。
大家都知道,Google的数据量很大,但是它的数据源本身其实比较单一。以Google search,Google map等为主导。再来看看Facebook,它更多的是社交行为数据,缺少出行数据、 浏览器数据、或者类似优酷的视听数据。但是,对于阿里来说,上述的这些数据我们都有。我们面临的极大挑战是:怎么样有效的把这些全域数据融合在一起。
首先我们需要把数据有效地收集起来。把数据有效地收集、存储起来之后,接着要做的就是怎么通过算法把这些数据打通,并且真正有效、智能地把这些数据提炼出来。
这是阿里的一个生态体系图。最底层是阿里云,这是我们的一个计算存储框架。上面是阿里妈妈,阿里妈妈是负责整个阿里巴巴计算广告的一个部门,再上面是菜鸟、支付宝和蚂蚁金服。然后是与电商业务相关的,像淘宝网、天猫、聚划算等等,或者是跟文娱相关的,优酷土豆,还有像阿里旅行,口碑之类的业态。
阿里巴巴数据中台要做的事情是什么呢?举一个最简单的例子,之前有一个比较火的电视剧《三生三世》。《三生三世》火热上映的时候,与之相关的商品元素,比如饮食或者穿戴之类的商品,也会瞬间在淘宝网上火爆起来。那么如果我提前就知道某一类人群是《三生三世》的粉丝,我就可以在淘宝网上做非常高效的、准确的定位推广。阿里数据要做的是:把数据真正打通,深度挖掘数据的价值,为业务创新应用提供数据决策基础和依据。
下面具体介绍一下数据融合的技术框架。因为在真正进入算法之前,我们一定要对数据进行非常认真、仔细地进行清洗过程。俗话说,如果你的数据不清洗,其实就是“learn trash from trash”。所以数据本身一定要做得非常干净。
更多点击链接
权威详解 | 阿里新一代实时计算引擎 Blink,每秒支持数十亿次计算
实时计算时代来临
随着互联网应用的普及、智能硬件的发展,数据的种类和规模都呈现了爆炸式的增长,各行各业都希望能够从大数据中发掘出更深层次的信息和知识,并产生实际价值。数据挖掘手段也逐渐从基本的数据统计向更高层次的机器学习和深度学习演变,但这些都需要强大的计算能力作为支撑,因此大数据价值的体现离不开大数据计算平台的发展。
目前大数据业界在计算技术上已经取得了显著的成果,例如:第一代开源的大数据处理技术Hadoop已经可以处理超大规模的数据集合,第二代开源的大数据处理技术Spark更好的利用了内存,并进一步加快了大数据处理的性能。
各大公司也都基于自身业务场景和数据规模定制了自己的大数据计算平台,但这些大数据计算平台大都是批处理系统,虽然具备海量数据处理能力,但在时效性上有明显的滞后。显然,数据的价值不仅体现在空间维度上,同时也在时间维度上进行伸展,很多场景下数据的价值也会随着时间的流逝而逐渐消失。因此,大数据计算平台需要能够尽可能的提升计算的时效性,越快地从数据中挖掘出信息就意味着能够获取到更大的价值。
时效性对数据价值的影响尤其在电子商务领域更加明显。通常人们在不同时刻会有着不同的消费需求和潜在目标。很多时候,这些需求和目标都是临时的(即和历史行为关联度较低),并且从产生到结束之间的时间是非常有限的。这种情况在阿里巴巴双十一大促这样的场景中表现的尤为明显。
大促场景下,用户会由于丰富的促销活动和环境而临时产生更多的购物需求,并且每个购物需求的有效期是有限的。因此,搜索和推荐系统需要及时发现用户的需求变化,在数据有效期内完成模型更新,推荐用户当前感兴趣的商品。此外,阿里巴巴的数据大屏也需要在大促期间实时展示成交额等大家关注的统计信息,而不是大促结束后第二天再让大家看到数据。
其实目前不仅在阿里巴巴,各个行业都对大数据时效性的计算需求在日益增加,因此,阿里巴巴需要研发世界级一流的流式计算引擎,实时处理海量数据,提供在线统计、学习和预测能力,不仅支持阿里巴巴自己的核心电商场景,同时也能通过阿里云向外部中小企业提供流式计算服务,输出实时计算能力,这就是我今天要分享的最新一代阿里巴巴实时计算引擎Blink。
流式计算介绍
显然批量计算模型是无法满足当前大数据实时计算需求的,只有流式计算模型才是实时计算的天然计算模型,因此我先介绍下流式计算的基本思想,尤其是区别于传统批量计算的一些概念。批量计算是对于有限固定的数据集合进行处理,流式计算是对无限数据流的处理,即计算无法确定数据何时会结束。从另一个角度看,批量计算其实也可以认为是流式计算的一种特例,因此批量计算可以看做是一个数据流中的片段,即有明确开始和结束标记的数据流,如下图所示:
完善的流式计算不仅应该提供实时计算能力,还应该支持计算过程中的状态管理,状态主要是指计算过程中需要的数据或者变量,例如:统计计算中的aggregation(sum/min/max…),机器学习中的feature和model,状态管理包括这些数据的存储、备份、恢复,版本管理,提供读写访问API,并保证一致性,如下图所示:
更多点击链接
阿里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的能力特点,可以简单概括为下表,基于这些能力,其被广泛应用于海量结构化数据在线访问、大数据实时计算、大对象存储等领域。
阿里从2011年初开始步入HBase的发展、建设之路,是国内最早应用、研究、发展、回馈的团队,也诞生了HBase社区在国内的第一位Committer,成为HBase在中国发展的积极布道者。过去的几年时间,阿里累积向社区回馈了上百个Patch, 在诸多核心模块的功能、稳定性、性能作出积极重大的贡献,拥有多位Committer,成为推动HBase的长远发展的重要力量之一。 阿里是一家综合生态型公司,内部庞大业务矩阵高速发展,在基础存储方面,需要更好的功能灵活性、基础设施适应性、服务稳定性、效率成本。 因此,阿里HBase团队发展维护了HBase的内部分支,其基于阿里巴巴/蚂蚁金服的环境和业务需求,对社区HBase进行深度定制与改进,从软件系统、解决方案、稳定护航、发展支撑等全方位提供一站式大数据基础存储服务。 HBase在阿里的使用
Ali-HBase作为阿里巴巴技术大厦的基础存储设施,全面服务于淘宝、天猫、蚂蚁金服、菜鸟、阿里云、高德、优酷等各个领域,满足业务对于大数据分布式存储的基本需求。 在刚刚过去的2016年双11,HBase承载访问量达到了上百GB/秒(写入)与上百GB/秒(读取),相当于全国人民一秒收发一条短信,在业务记录、安全风控、实时计算、日志监控、消息聊天等多个场景发挥重要价值。面对如此规模的业务体量,阿里巴巴团队对于如何基于HBase打造稳定、高效、易用的存储服务,形成了一套完善的产品体系与实践经验,其整体大图如下:
总体上,我们以定制的软件内核为中心,建设质量平台、运维平台、业务平台和数据流设施四大内容,以支持业务对于基础数据服务的全方位需求。
接下来,本文会围绕可用性、数据流、性能优化等方面介绍最近的一些具体工作,希望能够给相关领域的同学带来一点帮助。
更多点击链接
[干货]基础机器学习算法
本篇内容主要是面向机器学习初学者,介绍常见的机器学习算法,当然,欢迎同行交流。
哲学要回答的基本问题是从哪里来、我是谁、到哪里去,寻找答案的过程或许可以借鉴机器学习的套路:组织数据->挖掘知识->预测未来。组织数据即为设计特征,生成满足特定格式要求的样本,挖掘知识即建模,而预测未来就是对模型的应用。
特征设计依赖于对业务场景的理解,可分为连续特征、离散特征和组合高阶特征。本篇重点是机器学习算法的介绍,可以分为监督学习和无监督学习两大类。
更多点击链接
|