ETL開發面試問題加吐槽加職業發展建議

 

寫在前面：

做爲甲方，對於乙方派來的開發人員，我是會本身面一下。整體來講遇到的水平不一，因而通過這三年多的面(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這方面，是最適合對整個公司的系統架構有比較寬泛和略微深刻的理解的，不少招聘要求裏，都須要對某領域的業務有必定的瞭解，因此能夠看出來這個的重要性，以及從乙方跳到甲方的重要資本。