又到了金三银四的招聘旺季,很多想入行大数据开发的程序员却在面试上发了愁。大数据方向技术栈繁多,不同的面试官和公司用到的技术栈也不一样,问的问题也是各有不同。 大厂面试题回忆: 【腾讯 PCG 事业部 大数据开发岗】 spark 数据分发机制 Spark Streaming 给个具体视频应用场景阐述开发思路及任务架构【阿里创新业务事业群 大数据开发工程师】 spark partition 的类型及特点 yarn 任务启动的具体流程 spark 任务分发机制 为了帮助想要入行大数据开发的程序员们在金三银四
大数据开发岗大厂面试30天冲刺 - 日积月累,每日五题【Day01】——Hive1
又到了一年一度的金三银四,每次总能听到一些读者的反馈,问:有没有关于 xxx 的面试题,索性就把我所收集的 GitHub 上关于面试题的项目分享给大家。
•消费者组负责订阅Topic,消费者负责消费Topic分区的数据 •消费者组中可以包含多个消费者,多个消费者共同消费数据,增加消费并行度,提高消费性能 •消费者组的id由开发者指定,消费者的id由Kafka自动分配
消息队列就是用于当两个系统之间或者两个模块之间实现消息传递时,基于队列机制实现数据缓存的中间件
•step1:构建消费者连接对象:KafkaConsumer –需要配置对象:管理配置,例如连接地址:Properties •step2:消费者需要订阅Topic –KafkaConsumer:subscribe(List) •step3:消费数据 –KafkaConsumer:poll:实现拉取消费数据 –ConsumerRecords:拉取到的所有数据集合 –ConsumerRecord:消费到的每一条数据 •topic:获取数据中的Topic •partition:获取数据中的分区编号 •offset:获取数据的offset •key:获取数据中的Key •value:获取数据中的Value
•功能:Hbase是一个分布式的、基于分布式内存和HDFS的按列存储的NoSQL数据库 •应用:Hbase适合于需要实时的对大量数据进行快速、随机读写访问的场景
Hive 和数据库除了拥有类似的查询语言,再无类似之处。 1)数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2)数据更新 Hive中不建议对数据的改写。而数据库中的数据通常是需要经常进行修改的, 3)执行延迟 Hive 执行延迟较高。数据库的执行延迟较低。当然,这个是有条件的,即数据规模较小,当数据规模大到超过数据库的处理能力的时候,Hive的并行计算显然能体现出优势。 4)数据规模 Hive支持很大规模的数据计算;数据库可以支持的数据规模较小。
•Hive是通过构建元数据,映射HDFS文件构建成表,本质还是HDFS,实现离线大数据仓库 •Hbase是通过构建上层分布式内存,底层HDFS,实现大数据实时存储的NoSQL数据库
一个CPU core同一时间只能执行一个线程。而每个Executor进程上分配到的多个task,都是以每个task一条线程的方式,多线程并发运行的。
•加快查询效率:将数据划分到多个小文件中,通过offset匹配可以定位某个文件,从小数据量中找到需要的数据 •提高删除性能:以Segment为单位进行删除,避免以每一条数据进行删除,影响性能
•Region划分规则:范围划分,一张表可以在Rowkey行的方向上划分多个Region,每个Region构成一段连续的区间 •数据划分规则:根据Rowkey属于哪个Region的范围,就将这条数据写入哪个Region分区中
但是不管怎么说,有些硬技能还是需要的,比如做大数据来说,如果只是了解各种组件的使用,是远远不够的。真正做过大数据研发的肯定是需要写SQL,写各种算子的。对于组件的使用可以通过面试问出来,但SQL和一些编码的硬实力就需要笔试来搞定了。
•MapReduce写入Hbase原理:封装了一个TableOutputFormat来实现写入Hbase的数据 •要求 –写入Hbase的数据的V的类型必须为Put类型
•个数原则:如果列的个数比较多,建议2 ~ 3个,如果列的个数比较少,建议1个 –列族个数多了,导致比较次数变多,降低性能 –列族个数少了,导致列的比较次数变多,降低性能 •长度原则 :能满足业务需求的情况下,越短越好
① 构建Application的运行环境,Driver创建一个SparkContext
大家好,我是 梦想家 Alex 。我们都知道 github 对于程序员们而言,就是一个巨大的“聚宝盆”,上面不仅有很多优质的开源项目,还有很多热爱开源分享的开发者。但如何从浩如烟海的宝藏中,筛选出适合自己的优质项目呢?本期内容,我就为大家推荐几个我认为还不错的大数据学习必备的 牛 X 项目,希望大家看完有所收获。
rdd分布式弹性数据集,简单的理解成一种数据结构,是spark框架上的通用货币。 所有算子都是基于rdd来执行的,不同的场景会有不同的rdd实现类, 但是都可以进行互相转换。rdd执行过程中会形成dag图,然后形成lineage保证容错性等。从物理的角度来看rdd存储的是block和node之间的映射。 1)粗粒度:启动时就分配好资源, 程序启动,后续具体使用就使用分配好的资源,不需要再分配资源;优点:作业特别多时,资源复用率高,适合粗粒度;缺点:容易资源浪费,假如一个job有1000个task,完成了999个,还有一个没完成,那么使用粗粒度,999个资源就会闲置在那里,资源浪费。 2)细粒度分配:用资源的时候分配,用完了就立即回收资源,启动会麻烦一点,启动一次分配一次,会比较麻烦。
1)用于设置RDD持久化数据在Executor内存中能占的比例,默认是0.6,,默认Executor 60%的内存,可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略,如果内存不够时,可能数据就不会持久化,或者数据会写入磁盘; 2)如果持久化操作比较多,可以提高spark.storage.memoryFraction参数,使得更多的持久化数据保存在内存中,提高数据的读取性能,如果shuffle的操作比较多,有很多的数据读写操作到JVM中,那么应该调小一点,节约出更多的内存给JVM,避免过多的JVM gc发生。在web ui中观察如果发现gc时间很长,可以设置spark.storage.memoryFraction更小一点。
1)运行ApplicationMaster的Container:这是由ResourceManager(向内部的资源调度器)申请和启动的,用户提交应用程序时, 可指定唯一的ApplicationMaster所需的资源; 2)运行各类任务的Container:这是由ApplicationMaster向ResourceManager申请的,并由ApplicationMaster与NodeManager通信以启动之。
1)累加器在全局唯一的,只增不减,记录全局集群的唯一状态; 2)在exe中修改它,在driver读取; 3)executor级别共享的,广播变量是task级别的共享两个application不可以共享累加器,但是同一个app不同的job可以共享。
不一定,除了一对一的窄依赖,还包含一对固定个数的窄依赖(就是对父RDD的依赖的Partition的数量不会随着RDD数量规模的改变而改变), 比如join操作的每个partiion仅仅和已知的partition进行join,这个join操作是窄依赖,依赖固定数量的父rdd,因为是确定的partition关系。
•创建全局索引,会自动构建一张索引表 •索引表结构 –Rowkey:索引字段+原表的rowkey –列:占位置x •特点:如果查询字段或者查询条件不是索引字段,就不会走索引 •应用:适合于读多写少
解决方案:避免数据源的数据倾斜 实现原理:通过在Hive中对倾斜的数据进行预处理,以及在进行kafka数据分发时尽量进行平均分配。这种方案从根源上解决了数据倾斜,彻底避免了在Spark中执行shuffle类算子,那么肯定就不会有数据倾斜的问题了。 方案优点:实现起来简单便捷,效果还非常好,完全规避掉了数据倾斜,Spark作业的性能会大幅度提升。 方案缺点:治标不治本,Hive或者Kafka中还是会发生数据倾斜。 适用情况:在一些Java系统与Spark结合使用的项目中,会出现Java代码频繁调用Spark作业的场景,而且对Spark作业的执行性能要求很高,就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL,每天仅执行一次,只有那一次是比较慢的,而之后每次Java调用Spark作业时,执行速度都会很快,能够提供更好的用户体验。 总结:前台的Java系统和Spark有很频繁的交互,这个时候如果Spark能够在最短的时间内处理数据,往往会给前端有非常好的体验。这个时候可以将数据倾斜的问题抛给数据源端,在数据源端进行数据倾斜的处理。但是这种方案没有真正的处理数据倾斜问题。
可以减少数据的体积,减少存储空间,高效存储和传输数据,不好的是使用的时候要反序列化,非常消耗CPU。 配,用完了就立即回收资源,启动会麻烦一点,启动一次分配一次,会比较麻烦。
•step1:数据写入的时候,只写入内存 •step2:将数据在内存构建有序,当数据量大的时候,将有序的数据写入磁盘,变成一个有序的数据文件 •step3:基于所有有序的小文件进行合并,合并为一个整体有序的大文件
1)如果说HDFS是大数据时代分布式文件系统首选标准,那么parquet则是整个大数据时代文件存储格式实时首选标准。 2)速度更快:从使用spark sql操作普通文件CSV和parquet文件速度对比上看,绝大多数情况会比使用csv等普通文件速度提升10倍左右,在一些普通文件系统无法在spark上成功运行的情况下,使用parquet很多时候可以成功运行。 3)parquet的压缩技术非常稳定出色,在spark sql中对压缩技术的处理可能无法正常的完成工作(例如会导致lost task,lost executor)但是此时如果使用parquet就可以正常的完成。 4)极大的减少磁盘I/o,通常情况下能够减少75%的存储空间,由此可以极大的减少spark sql处理数据的时候的数据输入内容,尤其是在spark1.6x中有个下推过滤器在一些情况下可以极大的减少磁盘的IO和内存的占用,(下推过滤器)。 5)spark 1.6x parquet方式极大的提升了扫描的吞吐量,极大提高了数据的查找速度spark1.6和spark1.5x相比而言,提升了大约1倍的速度,在spark1.6X中,操作parquet时候cpu也进行了极大的优化,有效的降低了cpu消耗。 6)采用parquet可以极大的优化spark的调度和执行。我们测试spark如果用parquet可以有效的减少stage的执行消耗,同时可以优化执行路径。
1)参数用于设置每个stage的默认task数量。这个参数极为重要,如果不设置可能会直接影响你的Spark作业性能; 2)很多人都不会设置这个参数,会使得集群非常低效,你的cpu,内存再多,如果task始终为1,那也是浪费, spark官网建议task个数为CPU的核数*executor的个数的2~3倍。
无论你是想从事大数据相关职位的职场小白,还是准备往高处走的牛牛。小白有了这些在校招中过关斩将,牛牛们温故知新跨过业务壁垒。 B格高的HR,或者想要个助理的大数据工作者也可以了解下同行是怎么筛选人。 非主流的可以拿来撩HR妹纸,折腾面试的小鲜肉………………………… 数据分析 1、提前想好答案 数据分析师面试常见的77个问题 http://www.ppvke.com/Answer/question/25782 (典型的面试题,有些题是与业务结合的,不深不浅,忽悠漂亮HR妹纸必不可缺的神器。HR也可以看看提升
1)原理: 计算能力调度器支持多个队列,每个队列可配置一定的资源量,每个队列采用 FIFO 调度策略,为了防止同一个用户的作业独占队列中的资源,该调度器会对 同一用户提交的作业所占资源量进行限定。调度时,首先按以下策略选择一个合适队列:计算每个队列中正在运行的任务数与其应该分得的计算资源之间的 比值(即比较空闲的队列),选择一个该比值最小的队列;然后按以下策略选择该队列中一个作业:按照作业优先级和提交时间顺序选择, 同时考虑用户资源量限制和内存限制 2)优点: (1)计算能力保证。支持多个队列,某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源,且所有提交到队列中的作业 共享该队列中的资源; (2)灵活性。空闲资源会被分配给那些未达到资源使用上限的队列,当某个未达到资源的队列需要资源时,一旦出现空闲资源资源,便会分配给他们; (3)支持优先级。队列支持作业优先级调度(默认是FIFO); (4)多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源; (5)基于资源的调度。支持资源密集型作业,允许作业使用的资源量高于默认值,进而可容纳不同资源需求的作业。不过,当前仅支持内存资源的调度。
Spark中的内存使用分为两部分:执行(execution)与存储(storage)。
1)粗粒度:启动时就分配好资源, 程序启动,后续具体使用就使用分配好的资源,不需要再分配资源;优点:作业特别多时,资源复用率高,适合粗粒度;缺点:容易资源浪费,假如一个job有1000个task,完成了999个,还有一个没完成,那么使用粗粒度,999个资源就会闲置在那里,资源浪费。 2)细粒度分配:用资源的时候分配,用完了就立即回收资源,启动会麻烦一点,启动一次分配一次,会比较麻烦。
为什么要进行持久化? spark所有复杂一点的算法都会有persist身影,spark默认数据放在内存,spark很多内容都是放在内存的,非常适合高速迭代,1000个步骤只有第一个输入数据,中间不产生临时数据,但分布式系统风险很高,所以容易出错,就要容错,rdd出错或者分片可以根据血统算出来,如果没有对父rdd进行persist 或者cache优化,就需要重头做。 以下场景会使用persist 1)某个步骤计算非常耗时,需要进行persist持久化 2)计算链条非常长,重新恢复要算很多步骤,很好使,persist 3)checkpoint所在的rdd要持久化persist。checkpoint前,要持久化,写个rdd.cache或者rdd.persist,将结果保存起来,再写checkpoint操作,这样执行起来会非常快,不需要重新计算rdd链条了。checkpoint之前一定会进行persist。 4)shuffle之后要persist,shuffle要进性网络传输,风险很大,数据丢失重来,恢复代价很大 5)shuffle之前进行persist,框架默认将数据持久化到磁盘,这个是框架自动做的。
网申情况介绍 春招实习生网申一般在4月初开始,上一篇面经主要是聊了很多自己的看法之类的,这一次面经就写自己的其他面试的经过以及面试题吧 笔试介绍 笔试的话,携程、去哪儿的笔试题还是比较友好的,没有很多行测题,选择题也是考验一个行业术语解释,题量还可以,主观题比较多,不过主观题也比较适合PM答。 小米笔试题是邮件发过去的,一个是做一个音乐软件的竞品分析,另一个附加题是画一个原型图 面试问题 携程 携程的问题就是深挖简历,携程大多数事业群只有一面,那一面也不是很难,个人感觉还是比较水一些,不过也是看面试官
随着 5G 时代的到来,大数据人工智能产业链又一次迎来了井喷式的爆发,随着岗位需求的不断增加,越来越多的人选择大数据课程,但是没有真正从事大数据工作的人面对企业面试有种无从下手的感觉,面对面试说不到技术的重点,每次面试只能靠队友,靠兄弟支援,尤其是面对架构,编程更是无从下手。于是我决定对市场上大多的有关大数据核心的面试题做一个详细的分析,也希望大家尽可能的做到举一反三,而不是局限于题目本身。
下面是面试题: 由于我准备面试时大部分的项目准备是围绕数据仓库开发准备的, 而我面试的是货拉拉的大数据开发岗, 所以整个面试过程面试官也在反复和我确认到底是面试应用开发还是数仓开发。。。
我参与了阿里巴巴中间件部门的提前批面试,一共经历了四次面试,拿到了口头offer。
在工作中,作为 Java 开发的程序员,Tomcat 服务器是大家常用的,也是很多公司现在正在用的。但是,在系统并发量比较大的情况下,Tomcat 就会出现卡死和自动关闭等问题。如何优化 Tomcat,让它更高效的运行就成了问题,在本次面试题分享中,我将为你解答如何更好的提升 Tomcat 性能。
这个国庆,大家过的怎么样啊,是到处去玩[smiley_95.png?tp=webp&wxfrom=5&wx_lazy=1&wx_co=1],还是继续勤勤恳恳地学习呢[u1F602.png?tp=web
实际上算法这块我还是个菜狗 没办法机会难得,不知道下次能不能这么走运 只能硬着头皮上了……!
数据结构表征数据存储的格式及操作数据的方式,了解这些便于我们大数据开发人员设计更好的存储,读取,计算策略。所以在java基础,大数据基础,大数据框架源码等都有一定基础之后应该去追求写出更加精致高效的代码。
工作中 Git 是一项必不可少的技能,在项目的开发进程中起着至关重要的作用。下面介绍一些 Git 在工作中的一些使用实践、常用流程、常用命令,供大家参考!
上海 985 计算机专业大三在读,有 acm 经验,无牌子,有一些算法竞赛和数模小奖,写在简历上的都是课程项目。
5)计算各分区时优先的位置列表(可选),比如从HDFS上的文件生成RDD时,RDD分区的位置优先选择数据所在的节点,这样可以避免数据移动带来的开销。
小编分享的这份Java后端开发面试总结包含了JavaOOP、Java集合容器、Java异常、并发编程、Java反射、Java序列化、JVM、Redis、Spring MVC、MyBatis、MySQL数据库、消息中间件MQ、Dubbo、Linux、ZooKeeper、 分布式&数据结构与算法等25个专题技术点,都是小编在各个大厂总结出来的面试真题,已经有很多粉丝靠这份PDF拿下众多大厂的offer,今天在这里总结分享给到大家!【已完结】
作为 Java 的从业者,在找工作的时候,一定会被问及关于 JVM 相关的知识。JVM 知识的掌握程度,在很多面试官眼里是候选人技术深度的一个重要评判标准。在这里我们将详细的整理常见的 JVM 面试题目,并给出标准答案,这里小编也整理了一份思维导图分享给到大家,提供给大家学习参考。
1.分享经验。从去年五月份到今年五月份,我面试了n家公司,也收了(n/2+10)家的offer,经历了两个春招一个秋招,其中有腾讯、今日头条、京东等offer。通过这篇文章分享一些经验,让后面的同学少走弯路。
领取专属 10元无门槛券
手把手带您无忧上云