大数据开发的领域不同,面试的锚定点也不同,从我过往的经验来说,可以大致来将大数据领域的开发分为如下几种:
离线开发:数据仓库、离线计算、ETL开发
首先讲几点,在技术面试中几个共性问题,这些问题无论是从事哪个领域的开发,都必须要掌握的基本能力。
1. 具备一定的逻辑表达能力
为什么一定要强调逻辑表达能力?面试本质上来说是人与人的沟通交流,你需要向面试官输出你的能力、你过往的经历,来证明你能够胜任所面试的岗位,那么如果连你做过什么都讲不清楚的话,那基本上面试就没有下文了。
对于很多技术人员来说,其实表达沟通能力都会表现出些许的不足,原因在于我们日常的工作对象面对的主要是计算机,跟计算机交流都是大脑思维+敲击键盘的速度,与人之间的交流会明显少一些,那么为了对应面试我们不得不抽出时间来锻炼一下这方面的能力。
其实,很简单,在过去面试经验中,我有一个小技巧,比如:做一个数仓项目,我当时是怎么考虑这个项目架构的?在项目里周边同事都负责什么?项目中代码编写我遇到哪些问题,无论是性能问题还是功能实现思路问题,这些问题我怎么解决的?只需要将这些东西我重新梳理一下,并手动的在A4纸上面画出来,整个的逻辑就清晰了,那么在面试的时候我只需要按照我的逻辑来讲出来即可。至于面试官会问到具体问题,我们再针对性的回答。
2. 对于业务相关的技术选型问题要了解清楚
不得不说,大数据组件真是越来越多,越来越复杂,那么,在面试的时候,面试官通常会问为什么你们现在Sqoop来同步数据而没有使用Datax呢?为什么使用Flink来做计算引擎,而不是用Spark呢?等等,这种技术对比性的问题,你一定会遇到。
这时候,就需要详细了解当初在选型时,为什么会选择Flink而没有选择Spark?有些同学可能会说,是为了追赶新技术趋势,而并不是真的是业务场景必须要这个组件来实现,这个说法不能说不对,只能说不完整。你不能将这个答复作为仅有的答复,至少要罗列出3条技术对比才可以,比如说:Flink可以做到实时计算、Spark是微批处理,Flink是一种批流统一的引擎,Spark要单独编写SparkCore或者SparkStreaming等等,如果你不是很清楚的,可以google一下看看相关技术的对比,然后摘录三条左右记下来(这不也是学习到了么?)。
3. 自己所负责的项目架构图要熟练掌握
对于做业务或者做平台的开发者来说,基本上在面试的时候,面试官都会让你画出你的项目架构图,然后根据项目架构图来提问,一方面,你能画出来说明你是真的做过这个项目,并不是虚假的项目经验,另一方面就是看看你在项目中是否是核心角色,通过你讲述的技术点好所负责的功能,就能判断出你当前的水平是初级、中级还是高级。
针对这一点,你可以参考第一点的内容,这里就不多加赘述了!
无论是你面试的下面哪一种开发岗位,上面的三条都是作为基础需要掌握的,下面,我们来讲一下,在不同开发领域内需要关注的面试问题有哪些?
如果你是一名做离线数仓开发相关、或者做ETL开发、或者做离线分析相关领域的工作的话,下面几点你可以对照的来看,从中摘取出你日常工作中确实有使用到的技术点。
上面的内容,你不一定都在工作中具体的应用过,没关系,你只需要将你日常开发中应用的点来对照上,并且将这个点逐步放大来看,比如你平时就是做数仓开发,平时就写一些SQL,然后就跑起来了。那么这就需要你对于SQL方面要有足够的准备,面试会考察你SQL编写能力,与此同时,如果你对于建模理论、数据同步在掌握多一点的话,那么你就会比别人多一份胜出的把握。
同理,如果你平时就是写一些离线作业分析,那么你就需要掌握好离线分析计算引擎的原理相关内容,要不断复习、学习这些计算引擎背后的核心原理,还有一点就是学会抛出问题,引导问题这一点我们放在最后来讲。
作为离线数仓开发而言,涉及面是非常广泛的,不可能每一条都掌握,还是那句话,你需要将自己工作的内容,转换为自己的价值能力,不能说我就做了这点东西,没什么可讲的。这是一种不重视自己的思维方式,俗话说的好:世上没有白走的话,走的每一步都算数,所有的经历都可以转化为成长,我经常拿这句话来勉励校招新人,并且会引导他们发现自己所做的工作的价值,以及带给他的成长是什么。
流计算相对离线数仓来说,从技术栈上来看会更加专注一些,涉及到的技术组件会比较少,但是原理性的东西会更多更复杂一些,而且通常这种一般都是问有一些深入的技术问题,业务性的问题可面试的点比较少,你需要重点关注以下几方面:
真正意义上只做流计算的人不是很多,相比离线数仓来看的话比例是很小的,但是能够长时间专注于流计算开发的人也是很牛的人,我记得当开始做大数据方向的时候,那两年一直都在做实时类系统的开发,包括:行为推荐、实时BI报表,广告推送等等,那是我一定想着坚定的朝着流计算方向发展,因为技术越来越来成熟,企业对于效率要求会越来越高,时间就是金钱这句话就充分体现了实时即未来的命题。
所以,如果你的条件允许的话,推荐你做实时流方向的开发,去深入研究那两三个大数据组件,至少你混的不会差。
话说,对于流计算的面试技巧,除了上面四条比较宽泛的点之前呢?还有一个技巧就是对于组件本身性能的核心关键点的掌握,例如说:kafka能够比其他消息队列组件性能更高的原因是什么?到底是用了那些技术导致性能高的,这时候你就需要了解到零拷贝、LSM、顺序写、二分算法、分区概念等等底层核心逻辑(后面我会单独讲一些关于底层核心原理的通用知识,欢迎关注KubeData),万变不离其宗,你会发现大部分的组件其实底层原理都是互通的,kafka的这些技术在HBase里面也有提现到,区别点在于架构设计原理的不同。
基础架构方向的研发相对业务开发来说,接触到的都是偏向于组件核心原理的实现,甚至于对于语言层面也会有相对比较深入的掌握,在网络层、存储层、CPU调度策略、硬件选型等等方面也会有一定的要求,因为这些往往会影响到组件的性能和稳定性(大数据量、高并发场景下)。
基础架构部门一般是中大型公司的技术团队会有单独的一个部门或者一个小组,来做基础架构方面的研发支持,那么从面试技巧上来,相对考察的都是偏向于组件核心原理和计算机操作系统原理、内核原理相关,你可能需要重点关注以下几点:
基础架构工作,很适合沉浸式写代码做技术的人,往往经过一段时间的历练之后,都会达到一定的技术造诣,而且不用担心所谓的年龄危机(虽然我极其不认同所谓的35岁危机),一般好的基础架构工程师都是经历过长时间实战问题排查、历练、总结学习得到的,是一个铁杵磨成针的过程。
相比于业务属性比较强的技术开发来讲,基础架构可替代性不强,而且职业的生命周期更长一些,我身边现在相对底层的技术研发来讲,基本上都在40左右了,例如有做网关服务开发大哥今年45岁,有做K8s内核开发的大哥今年39岁,有做计算引擎开发的大哥今年41岁等等,大概算了一下差不多有10多个人。
对于面试技巧来说,基础架构没有太多的技巧类可以提供,上面提到的也只是你要重点学习和掌握的知识点,毕竟对于基础架构来说硬技术是最重要的条件。
大数据运维不得不说是一个很繁重的工作,要时刻“盯着”集群的稳定性,一出现问题上层的业务都开始夺命连环call,这时候运维工程师提溜着裤子就要跑向电脑边排查故障(如果你是运维的话,是不是有点场景浮现的感觉?)
很多公司大数据团队没有单独的大数据运维岗位的,基本上是大数据工程师会兼职负责大数据集群的运维工作,一般这种集群规模都会比较小,规模比较大的话就必然会需要专门人员来运维,其实对于大数据运维工程师来讲面试技巧上没有太多业务性的,底层原理性的,更多是问题排查,运维思路,脚本编写、效率提升、SLA保障等等,以下几个方面可能是需要重点关注的:
最后一点,也是最重要的一点,来讲讲面试的时候来引导面试官问我熟悉的问题的重要性。
如果面试过程中不怎么去突出你的优势的话,那么一般面试官会对比着简历内容来按照他熟悉的领域来进行提问,通常技术人简历中都会包含很多大数据组件以及框架在里面,你不能保证每个都熟悉,只能说这些当时都用到了。如果你不懂的引导面试的技巧,那么你就会很吃亏。
近些年来,社保面试、校招面试、实习生面试大大小小差不多有1000人(仅现在公司5年有600人),我就发现有些面试者比较擅长于做“埋伏”,他会引导面试官朝着他自己熟悉的领域、熟悉的技术栈、熟悉的内容来提问,这样面试官一旦提问了相关问题,他就可以不断输出,这种对于面试感受也是非常好的,举一个具体点的例子:
比如,我之前面试过一个做大数据开发的高级工程师,他本身是对于Flink比较熟悉,所以在讲解项目流程、技术架构、选型的时候,会着重突出Flink相关的技术点,然后Flink这个词听的比较多的话,面试官就是问很多Flink的问题,如果他真的对于Flink技术掌握的很熟练,那对于这种问题的应答就很轻松。
这个候选人,在面试答题过程中,的的确确做到了问到的问题都给出了正确的答案,并且扩展性、回答的深度都达到了面试官的要求,所以说,你看,这种属于有一门足够掌握熟悉的技术领域,朝着专研的方向进行深耕的技术人才。
还有一种,是平时偏向于业务开发,可能只是写一些SQL或者编写一些Spark分析代码,那么怎么样来引导面试官提问呢?
第一:参考本文第一条所提到的建议。
第二:仔细复盘近几年工作的突出点、技术的突出点,那些是能够讲的出来的,将这些点罗列出来,并进行google搜索加强一下这些技术点的掌握水平
第三:面试过程中,要将这些内容按照自己思路凸显出来,SQL能力强就多说一下SQL高级函数的使用,数据同步的工作做的比较多,就多讲一点不同的数据集成工具之间的区别,讲一下数据同步的问题、技术原理等等。