提早突擊了這近200道大數據面試題， 果真頭條、京東都給了Offer

面試題包括Java、大數據開發、大數據運維、大數據分析、大數據架構等等

Q1：老師線上 6000+規模集羣，拋開一些其它組件集羣，僅討論 HDFS 數據存儲集羣，保守理應也在有 3000 節點左右，想知道這些存儲節點只是單集羣NameNode 集羣來維護嗎？仍是多集羣獨立維護的，若是是多集羣存儲數據，它們之間數據是如何打通進行關聯的？若是僅是一個集羣的話，我想知道這個集羣的 NameNode 上的配置，是如何 Hold 住這些數據 DataNode的？

夏天老師：

咱們的集羣也是用的 Cloudera 公司的，咱們付了費用， Cloudera 沒有保障說 CM 可以納管 1000 節點以上的集羣，再加上咱們的機房有容量限制，因此咱們是建了多套集羣，最大集羣有 800+節點，最小集羣也有 300+節點；800+datanode 下， namenode 是能夠支撐的，像一些互聯網大廠，字節跳動、京東等他們的單集羣規模有上萬節點，此時就須要對 hdfs 進行深度定製了，他們改了不少源碼，並且有 200+高級技術維護人員；

多集羣建設要考慮業務狀況，好比咱們公司有 10 個以上業務， 5 大核心集羣，按業務相關狀況劃分集羣，不過也不免有跨集羣的做業，目前公司內部自研發了大數據採集交換平臺，你也可使用 distcp 進行數據對拷，目前咱們也正在準備自研發多集羣並行混算平臺。

Q2:集羣線上擴容如何達到自動化？線上擴容，規模正常都以 10+以上，若是都以課堂所示，人肉操做，時間投入與產出比不匹配，人力形成很大的沒必要要浪費，想學習老師線上集羣實際擴容的方案。

夏天老師：

課堂所示兼顧了小白同窗，因此是手把手純人肉搭建，產線環境擴容數量少則幾十多則上百，人肉確定不行，咱們公司的運維分爲 IAAS 運維、大數據運維、應用運維，大數據運維工程師在擴容集羣時，須要向 IAAS 運維工程師以工單的方式申請服務器並提出本身的需求， IAAS 運維工程師在提供服務器時不論是新採購服務器仍是其餘集羣退役的服務器都須要重裝系統，重裝系統的鏡像是針對大數據定製的，鏡像包含了大數據運維工程師的通用需求以及安裝操做系統後的網絡、磁盤以及其餘設置，好比關閉防火牆、時鐘同步、同構磁盤掛載、關閉大透明頁、關閉 SWAP、公用 YUM 源、禁用 SELinux 等模式化操做，大數據運維工程師收到服務器後準備工做基本準備完畢了，進行少許準備工做就能夠直接進入了 CM 可視化批量安裝模式，好比腳本批量設置hostname、腳本同步/etc/hosts 文件等； 固然如上所說的 IAAS 操做，如關閉防火牆、時鐘同步、同構磁盤掛載、關閉大透明頁、關閉 SWAP、公用YUM 源、禁用 SELinux 均可以腳本化，無非就是使用 SSH 通信方式設置，這就須要大數據運維同窗熟練使用 shell 了。

Q3:已知一個 HDFS 的目錄，想知道此目錄下的文件數，並且存儲於哪些DataNode 節點上。

夏天老師：

1.查看文件數使用 count 命令，以下查看/ops 目錄，目錄數爲 9606，文件數爲 1353 萬+，總文件大小爲 9.7P
2.2.查看/ops/test 目錄下的文件存儲的位置hdfs fsck /ops/test -files -blocks -locations -racks

Q4:DataNode 單節點，存儲容量大小與當前節點上的 CPU，內存硬件之間有什麼樣的關係，磁盤擴容很容易，但這不意味着單節點上數據盤就能夠無限地擴容，所以在這方面，有什麼實際線上的經驗分享，即這三者間能夠遵循怎樣合適的關係

夏天老師：

從咱們內部實踐來講沒有發現三者之間的規律，由於大數據業務每一個公司都不同，有的計算是 CPU 密集型的，有的計算是內存密集型的、有的計算是IO 密集型的；咱們的服務器都是中高配置，每一個服務器的磁盤是 4Tx十、 CPU24core、128G 內存

Q5： HDFS 存儲節點上的數據，存儲壓縮格式是如何選取的，默認採用哪一種文件存儲類型與存儲格式，冷熱數據如何界定的？

夏天老師：

咱們產線環境用了 gz 和 snappy 壓縮格式， gz 用於不經常使用的冷數據，snappy 用於熱數據；冷熱數據是跟業務相關的，後續集羣治理的課程中也有冷熱數據的區分。

Q6：課堂上看到 HDFS 集羣的 DataNode 與 HBASE 是集成在一塊兒部署的，我好奇， HBase 面向的都是高頻率讀寫的業務，老師肯定部署一塊兒後，線上業務沒有出現過問題嗎？

夏天老師：

你應該是理解錯了， HBase 不能跟 YARN 在一塊兒部署； HBase 須要跟HDFS 部署在一塊兒的，這樣能夠利用數據本地性提高 IO 性能，而且能夠下降網絡延遲，下降帶寬負載。

Q7： Yarn 集羣計算層，目前集羣面向用戶使用羣體少，故白天僅是數據寫入，集羣 CPU 資源都較爲存在大量冗餘狀態，但對於凌晨執行集中高頻提交跑批做業計算任務時，集羣的 CPU 資源明顯不夠，甚至引發節點 CPU 負載太高致使節點的宕機，從而形成集羣雪崩。簡單來講，白天集羣資源使用率在5%，凌晨執行高頻跑批做業任務時，資源使用率上到 100%，引發集羣宕機。在不增長資源的前提下，資源老師會如何劃分隊列？

夏天老師：

這個劃分隊列沒法解決根本問題，建議將業務劃分優先級，錯開時間執行。

Q8.某一臺 CDH 物理機 12 塊 RAID0 硬盤，若是其中有 4 塊 RAID0 硬盤同時損壞,請問接下來大數據運維人員的詳細處理流程是什麼？

夏天老師：

HDFS 有個參數 dfs.datanode.failed.volumes.tolerated，值爲 0 的時候表示當有任何盤損壞後 datanode 則中止服務，若是 4 快盤同時損壞了，此時datanode 進程已經中止了，你能夠修改 hdfs-site.xml 配置文件將損壞的磁盤路徑去掉，重啓 datanode 便可，而後進入磁盤報修流程，待磁盤更換後，中止 datanode，在 hdfs-site.xml 配置文件中假如新的磁盤，啓動 datanode 便可。

Q9.CDH 若是爲開發人員提供 HIVESERVER2 服務，可讓開發人員經過beeline 命令訪問?

夏天老師：

是的， beeline 使用 JDBC 協議來鏈接 HIVESERVER2

Q10.在晚高峯期 HDFS 集羣會出現某些 datanode 不穩定的狀況，頻繁有datanode 脫離節點,該如何處理呢？

夏天老師：

須要找到 datanode 的具體緣由， datanode 相對來講仍是比較穩定的，須要看下是不是 GC 問題，若是是的話適當調大內存，再看下最大的打開文件數或進程數的限制是否過小

Q11.CDH 集羣擴容 10 臺機器後，新加入的 Datanode 角色數據相對較少，如何處理 HDFS 的數據分佈不均衡的現象呢?

夏天老師：

在內存佔用較低的節點上啓動 balancer 腳本，將 HDFS 中全部節點的存儲值中的最低值和平均值的差值設置爲 5%。命令： ./start-balancer.sh -threshold 5

Q12.CDH 監控項從某種角度來講並非很細粒度，老師課上可能時間有限等緣由只是稍微提了一下監控思路，請問您線上是如何監控的呢，能將詳細步驟給咱們刨析一下嗎?

夏天老師：

目前咱們產線環境仍是以 CDH 監控爲主， CDH 的指標仍是挺多的，只不過保留的週期不長，對於排障來講基本夠用了，固然咱們會推動一些監控工具，不過在課堂不會展開細講，後續有 Flink 監控方面的實戰。

Q13.如何基於 CDH 集羣監控大量的小文件的呢？衡量小文件標準，以及出現大量小文件在生產環境該如何解決呢?

夏天老師：

CM 解決不了大量小文件的監控，須要額外作其餘工做，這塊在集羣治理裏面咱們會詳細講；對於怎麼衡量小文件的標準，你能夠簡單認爲小於 blocksize 的文件就是小文件，可是在企業真實狀況下小文件問題可能更加嚴重，好比大量 10M、幾十 M 如下的文件，單純技術沒法解決問題，須要組織協同，這個在集羣治理裏面咱們會詳細講。

Q14.以前上課只是大體提了一下 YARN 資源調度，生產環境使用 CDH 如何配置 YARN 資源隊列調度，在我們後續的課程還會講嗎？

夏天老師：

這個會講解的，也會講解咱們產線環境是如何劃分隊列的。

Q15.CDH 如何對 HDFS 各級目錄作權限管理，目錄的配額(即便用 HDFS 的容量限制)限制呢?

夏天老師：

HDFS 可經過 ACL 精細控制目標權限，除了 ACL 後續咱們也會講sentry；目前咱們產線環境沒有作容量配額限制，怕影響生產，咱們經過集羣治理來解決容量問題，集羣治理是咱們的課程內容之一，後續會講解

Q16.Hdfs,Yarn,MapReduce,Hive,Spark,Storm,Kafka,Flink 這些組件您在生產環境的調優參數是如何配置的，後續會爲咱們分享一些調優參數及說明麼?咱們也方便對照本身的集羣做爲參考適當調整。

夏天老師：

這個是會的，咱們會講組件的運維、巡檢、監控、參數配置、故障排查等課程內容。

Q17.後期的大數據組件監控項目是針對課上全部的組件進行監控的麼？仍是隻是分享監控思路，代碼能給咱們學員嗎？

夏天老師：

大數據組件監控主要在 CM 上進行監控，後續有集羣治理案例實戰，實戰代碼能夠給學員的。未完待續………