BigData
【大内存服务GC实践】- “ParNew+CMS”实践案例 (一)- NameNode YGC诊断优化
案例一 NameNode升级之后RPC大毛刺问题探究
问题背景

问题分析
为什么RPC排队毛刺会出现?
【大内存服务GC实践】- “ParNew+CMS”实践案例 : HiveMetastore FullGC诊断优化
线上案例一
【大内存服务GC实践】- 一文看懂”ParNew+CMS”垃圾回收器
因为工作的需要,笔者前前后后分别接触了HBase RegionServer、HiveServer\Metastore以及HDFS NameNode这些大内存JVM服务。 在和这些JVM系统打交道的过程中,GC优化始终是一个绕不过去的话题,有的是因为GC导致NameNode RPC请求耗时增大,有的是因为GC导致RegionServer/HiveServer/Metastore经常宕机。在优化的过程中,笔者花时间系统地学习并梳理了CMS、G1GC以及ZGC这几款垃圾回收器的原理,并基于这些原理进行了多次线上GC问题的定位以及优化。这个系列的文章初步安排了多篇
- 【大内存服务GC实践】- 一文看懂"ParNew+CMS"组合垃圾回收器
- 【大内存服务GC实践】- "ParNew+CMS"组合垃圾回收器实践案例(一
- 【大内存服务GC实践】- "ParNew+CMS"组合垃圾回收器实践案例(二
- 【大内存服务GC实践】- 一文看懂G1垃圾回收器...
Hello World – 大数据实践之路
对大数据生态现状的认识
随着近两年大数据技术的蓬勃发展,很多新的发展趋势、研究热点层出不穷。因为这个专题主要是基于Hadoop生态组件的生产线实践,所以谈几个关...
BigData-‘基于代价优化’究竟是怎么一回事?
还记得笔者在上篇文章无意中挖的一个坑么?如若不知,强烈建议看官先行阅读前面两文-SparkSQL – 有必要坐下来聊聊Joi》和BigData – Join中竟然也有谓词下推!》。第一篇文章主要分析了大数据领域Join的三种基础算法以及各自的适用场景,第二篇文章在第一篇的基础上进一步深入,讨论了Join基础算法的一种优化方案 - Runtime Filter,文章最后还引申地聊了聊谓词下推技术。同时,在第二篇文章开头,笔者引出了两个问题,SQL执行引擎如何知晓参与Join的两波数据集大小?衡量两波数据集大小的是物理大小还是纪录多少抑或两者都有?这关系到SQL解析器如何正确选择Join算法的问题。好了,这些就是这篇文章要为大家带来的议题-基于代价优化(Cost-Based Optimization,简称CBO)。
CBO基本原理
提到CBO,就不得不提起一位’老熟人’ - 基于规则优化(...
BigData – Join中竟然也有谓词下推!?
作者:何李夫、范欣欣
上文简要介绍了Join在大数据领域中的使用背景以及常用的几种算法-broadcast hash join 、shuffle hash join以及sort merge join等,对每一种算法的核心应用场景也做了相关介绍,这里再重点说明一番:大表与小表进行join会使用broadcast hash join,一旦小表稍微大点不再适合广播分发就会选择shuffle hash join,最后,两张大表的话无疑选择sort merge join。
好了,问题来了,说是这么一说,但到底选择哪种算法归根结底是SQL执行引擎干的事情,按照上文逻辑,SQL执行引擎肯定要知道参与Join的两表大小,才能选择最优的算法喽!那么斗胆问一句怎么知道两表大小?衡量两表大小的是物理大小还是纪录多少抑或两者都有?其实这是另一门学问-基于代价优化(Cost BaseOptimization,简称CB...