【微信公众号:大数据学习与分享】专注于大数据领域常用技术,如Spark、Hadoop、Hive、HBase、Kafka、Zookeeper等技术的使用、实战技巧、源码解读,语言主要以Java和Scala为主
能力说明:
精通JVM运行机制,包括类生命、内存模型、垃圾回收及JVM常见参数;能够熟练使用Runnable接口创建线程和使用ExecutorService并发执行任务、识别潜在的死锁线程问题;能够使用Synchronized关键字和atomic包控制线程的执行顺序,使用并行Fork/Join框架;能过开发使用原始版本函数式接口的代码。
暂时未有相关云产品技术能力~
阿里云技能认证
详细说明对于Spark的初学者,往往会有一个疑问:Spark(如SparkRDD、SparkSQL)在处理数据的时候,会将数据都加载到内存再做处理吗?
在利用Spark和Kafka处理数据时,有时会同时在maven pom中引入Spark和Kafka的相关依赖。但是当利用Spark SQL处理数据生成的DataSet/DataFrame进行collect或者show等操作时,抛出异常NoSuchMethodError: net.jpountz.lz4.LZ4BlockInputStream
在大数据平台建设初期,安全也许并不是被重点关注的一环。大数据平台的定位主要是服务数据开发人员,提高数据开发效率,提供便捷的开发流程,有效支持数仓建设。大数据平台的用户都是公司内部人员。数据本身的安全性已经由公司层面的网络及物理机房的隔离来得到保证。那么数据平台建设过程中,需要考虑哪些安全性方面的问题?
对于Spark开发人员来说,一个比较普遍的问题就是如何合理的配置Spark的硬件?当然如何合理的对Spark集群进行硬件配置要视情况而定,在这里给出一些建议
【前言:本文主要从任务处理的运行模式为角度,分析Spark计算模型,希望帮助大家对Spark有一个更深入的了解。同时拿MapReduce和Spark计算模型做对比,强化对Spark和MapReduce理解】
【前言:笔者将分两篇文章进行阐述Spark和MapReduce的对比,首篇侧重于"宏观"上的对比,更多的是笔者总结的针对"相对于MapReduce我们为什么选择Spark"之类的问题的几个核心归纳点;次篇则从任务处理级别运用的并行机制方面上对比,更多的是让大家对Spark为什么比MapReduce快有一个更深、更全面的认识。通过两篇文章的解读,希望帮助大家对Spark和MapReduce有一个更深入的了解,并且能够在遇到诸如"MapReduce相对于Spark的局限性?"等类似的面试题时能够得到较好地表现,顺利拿下offer】
Spark集群组件、Spark基本执行流程以及注意点
Yarn(Yet Another Resource Negotiator)是一个资源调度平台,负责为运算程序如Spark、MapReduce分配资源和调度,不参与用户程序内部工作。同样是Master/Slave架构。
HDFS(Hadoop Distributed File System)分布式文件存储系统,主要为各类分布式计算框架如Spark、MapReduce等提供海量数据存储服务,同时HBase、Hive底层存储也依赖于HDFS。HDFS提供一个统一的抽象目录树,客户端可通过路径来访问文件,如hdfs://namenode:port/dir-a/a.data。HDFS集群分为两大角色:Namenode、Datanode(非HA模式会存在Secondary Namenode)
Scala中的IO操作及ArrayBuffer线程安全问题处理
在利用数据仓库进行数据处理时,通常有这样一个业务场景,为一个Hive表新增一列自增字段(比如事实表和维度表之间的"代理主键")。虽然Hive不像RDBMS如mysql一样本身提供自增主键的功能,但它本身可以通过函数来实现自增序列功能:利用row_number()窗口函数或者使用UDFRowSequence。
大家都知道在双十一这些电商大型营销活动期间,电商网站的访问量等是平时的N倍。每当这个时候到来,无论是开发还是运维人员都严阵以待生怕服务出现问题。很不幸,笔者的一个朋友在一家电商公司上班,在双十一时,恰恰就出现了NameNode宕机的生产事故。 鉴于涉及到一些公司私密信息,不便发一些排查问题截图,同时,JVM调优作为大数据从业者必备技能,笔者打算后续分篇系统阐述,这里仅就问题现象、问题分析、解决方案三个层面阐述这次生产事故从产生、排查到最终解决的历程。希望能给大家带来一定思考,避免此类事情的发生以及提供出现类似问题时处理的一个思路。
无论对于Java程序员还是大数据研发人员,JVM是必须掌握的技能之一。既是面试中经常问的问题,也是在实际业务中对程序进行调优、排查类似于内存溢出、栈溢出、内存泄漏等问题的关键
在利用Spark处理数据时,如果数据量不大,那么Spark的默认配置基本就能满足实际的业务场景。但是当数据量大的时候,就需要做一定的参数配置调整和优化,以保证业务的安全、稳定的运行。并且在实际优化中,要考虑不同的场景,采取不同的优化策略。
【前言:Spark目前提供了两种有限定类型的共享变量:广播变量和累加器,今天主要介绍一下基于Spark2.4版本的广播变量。先前的版本比如Spark2.1之前的广播变量有两种实现:HttpBroadcast和TorrentBroadcast,但是鉴于HttpBroadcast有各种弊端,目前已经舍弃这种实现,本篇文章也主要阐述TorrentBroadcast】
Spark算子主要划分为两类:transformation和action,并且只有action算子触发的时候才会真正执行任务。还记得之前的文章《Spark RDD详解》中提到,Spark RDD的缓存和checkpoint是懒加载操作,只有action触发的时候才会真正执行,其实不仅是Spark RDD,在Spark其他组件如SparkStreaming中也是如此,这是Spark的一个特性之一。像我们常用的算子map、flatMap、filter都是transformation算子,而collect、count、saveAsTextFile、countByKey、foreach则为action
通过上篇文章【Spark RDD详解】,大家应该了解到Spark会通过DAG将一个Spark job中用到的所有RDD划分为不同的stage,每个stage内部都会有很多子任务处理数据,而每个stage的任务数是决定性能优劣的关键指标。
本篇文章首先通过大家熟知的一个参数spark.default.parallelism为引,聊一聊Spark并行度都由哪些因素决定?
考虑到目前很多公司还都在用这个计算引擎,以及后续要讲的Hive原生支持的计算引擎也是MapReduce,并且为Spark和MapReduce的对比做铺垫,笔者今天详细阐述一下MapReduce。鉴于Hadoop1.X已过时,Hadoop3.X目前用的还不多,企业中目前大量运用的还是Hadoop2.X,所以以下都是基于Hadoop2.X版本的MapReduce
RDD(Resilient Distributed Datasets)弹性的分布式数据集,又称Spark core,它代表一个只读的、不可变、可分区,里面的元素可分布式并行计算的数据集。
Apache Spark是一种快速、通用、可扩展、可容错的、基于内存迭代计算的大数据分析引擎。首先强调一点, Spark目前是一个处理数据的计算引擎, 不做存储。首先咱们通过一张图来看看目前Spark生态圈都包括哪些核心组件:
开发了近两年(自2018年10月份至今)的Apache SparkTM 3.0.0正式发布! Apache SparkTM 3.0.0版本包含3400多个补丁,是开源社区做出巨大贡献的结晶,在Python和SQL功能方面带来了重大进展并且将重点聚焦在了开发和生产的易用性上。同时,今年也是Spark开源10周年,这些举措反映了Spark自开源以来,是如何不断的满足更广泛的受众需求以及更多的应用场景
提起大数据,不得不提由IBM提出的关于大数据的5V特点:Volume(大量)、Velocity(高速)、Variety(多样)、Value(低价值密度)、Veracity(真实性),而对于大数据领域的从业人员的日常工作也与这5V密切相关。大数据技术在过去的几十年中取得非常迅速的发展,尤以Hadoop和Spark最为突出,已构建起庞大的技术生态体系圈