ETL开发面试问题加吐槽加职业发展建议

浏览: 2531

写在前面:

作为甲方,对于乙方派来的开发人员,我是会自己面一下。总体来说遇到的水平不一,于是经过这三年多的面(cui)试(can),总结了一套自己的面试套路,中间也遇到过很多想吐槽的东西,于是大概记录了下来。在后面, 也写了些关于这方面的职业发展和我个人的建议。

问题很基础,DBA路过误笑,同行高手欢迎过来喷一喷,一起进步。

先说下面试的顺序,首先我们现有的开发人员问基本的SQL语句问题和SSIS组件问题,然后我继续问以下问题。

 

 

问题1:假如有一个job突然失败了,那么你第一时间应该先去看哪里。

我的答案:

首先去看job history,看具体的错误信息,根据这个信息决定如何去解决问题。

如果在ETL中有自定义的日志输出,那么再去看自定义日志的内容。

吐槽:

居然很大一部分人不看job history,而是看自定义的日至。还有看哪里都不知道的,开发ETL不管后期的维护和错误排查,就算再简单的ETL,也不可能一直不出问题,好比写个代码不知道如何排错一样,所以到底做没做过ETL开发 ,这个问题直接能看出来。

另,往往大型项目会有自定义日至输出,但是能说出这一点的先别给高分,因为很有可能只是知道而已,具体了解多少还要参考下面几个问题。

 

问题2:假如一个job本来应该在凌晨两点跑完的,但是早上上班的时候发现还没有跑完,接下来会怎么做。

我的答案:

这么久的延迟最有可能是阻塞,比如下游报表或者客户端仍在数据仓库里查数。

排除这个问题,先用系统自带的报表查看目前是否有阻塞,或者用sp_who3网上大家扩展的一个方法来进行查询。如果发现ETL进程被阻塞,kill掉阻塞的进程,确保ETL能正常进行下去。

避免类似阻塞的情况发生,可以在ETL进行之前终止报表服务或查询账号,ETL成功之后再启动他们。

吐槽:

很多人都归结到数据量的巨增导致,这对一个正常的业务来说可能性比较低一些,但如果能说出这个原因也会多少加一点分。能知道用sp_who3来看目前有哪些语句在转的会加很大一部分分数,这个意识很关键。

 

问题3:接到用户抱怨说一个报表运行的很慢,如何处理。

我的答案:

先跑一下这个报表,重现一下运行缓慢的现象。然后在sql server端sp_who3一下看看到底是卡在了哪条查询,把查询单独拿出来进行进一步分析和优化。

点评:

偶尔问题也会问成ETL运行很慢,像上一个问题一样,主要还是考察是否有查看当前哪些语句在跑的意识。

吐槽:

会有人回答说把报表源代码拿过来一行一行去分析,这样虽然有可能找到问题,但是很慢。所以我会对做这个超过三年经验的人产生质疑。

 

问题4:如何进一步优化

我的答案:

看执行计划,查看几个关键点,比如索引缺失,SQL语句需要优化等问题。

点评:

能第一时间想到索引问题的加分,能想到SQL语句写法不地道的也加分。

这个需要追问,进一步考察执行计划,详见下一个问题。

吐槽:

有不少说一行一行去看的,所以会继续追问执行计划的问题。

 

问题5:如何快速的知道是由于索引缺失导致的

我的答案:

看执行计划,通常执行计划会直接提示具体缺失哪个索引,并且提供相应语句创建索引。

另外这个时候在执行计划里,看是否有表扫描,如果有说明索引缺失,如果看到索引查找说明是命中索引的。

如果系统无法给出的,可以先看执行计划里哪部分消耗的资源(百分比)最高,然后看里面所消耗的io数值是否很高,如果是的话说明索引也是有缺失,需要根据具体的情况添加索引。

点评:

如果提到WHERE顺序的加分。

没提执行计划,但是提到看join条件,再看有没有索引的,我只能少加点分,毕竟这样查问题效率不高。

吐槽:

居然很少人提到系统自动的索引缺失提示。。。

半数人说看执行计划里每个步骤的时间 。。。

也有半数人知道看执行计划,但是说不出表扫描和索引扫描。

能看io消耗的真的很少很少。

 

问题6:索引的进一步问题。

比如:

聚集索引和非聚集索引的区别。(看对叶级结点的区别)

为什么聚集索引只能有一个。

一个表是否有聚集索引,对这个表的数据存储方式区别是什么。(这个回答不上来通常不减分)

吐槽:

具体答案就不写了,主要看回答是否能回答到点上,比如叶级结点的区别,数据排序,堆表等。

面试的所有人当中,能把部分问题说明白的很少,部分人也只是背书。

 

 

写在后面:

这些问题,估计做DBA的或者BI的同行应该是在边看边笑吧,但我吐槽的大家也看到了,能答到点子上的,在北京,很少,也许你说我们的vendor不给力,我可没这么说。

另外汇总了下我个人认为的,ETL开发对于不同工作年限的最低要求。

工作一年的要求:

熟悉各种SQL语句的写法,熟悉SSIS包里常用的模块。

三年:

知道索引,知道优化SQL语句,熟悉建模。能够处理日常ETL以及数据库级别的常见问题。

五年:

知道如何规划整个ETL,对设计数据仓库非常熟悉。

七年:

可以带领团队实施大规模的项目。

 

最后的最后:

说实在的,这行能一直干下来的很少很少,大多都是半路转过来,或者干不下去转别的了。

另外纯ETL开发从技能角度来说,如果只偏向这个方向确实以后的路越走越窄,同时配合些辅助的技能会路子宽很多,比如报表开发,DBA,架构,大数据等。

还有,甭管做什么,对业务的理解也很重要,而做BI这方面,是最适合对整个公司的系统架构有比较宽泛和略微深入的理解的,很多招聘要求里,都需要对某领域的业务有一定的了解,所以可以看出来这个的重要性,以及从乙方跳到甲方的重要资本。

推荐 5
本文由 哥本哈士奇 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

3 个评论

job出错看日志
同感
同感

要回复文章请先登录注册