一面：阿裡雲大資料開發一面面經，已過，面試題已配答案
這份面試題時群裡一位小夥伴分享的，我給這份面試題找了一些參考答案
參考答案來源： 大資料面試題V3.0，523道題，779頁，46w字
1、資料庫三範式
第一範式：（字段不能重複且不能分解）
我們也叫1NF。這個範式主要還是讓我們去看看表中不要存在可以被分割的列，同時表的列不能重複。當然，在實際操作過程中，我們如果錄入相同的列，系統也是會報錯的。
第二範式：（增加主鍵）
我們也叫2NF。這個範式的前提是必須要先滿足第一範式的要求。當然，2NF的主要特點還是主鍵（從候選碼挑選出來的字段，候選碼是能決定唯一一行記錄的屬性組），所謂主鍵也是是能夠決定一行資料的候選碼。也就是說，主鍵可以是一列或者多列組成的，隻要能夠根據主鍵，馬上能精确到特定的一行資料即可。
這裡要注意的是，主鍵（我們有時候也會叫主屬性）記憶體的值不能為空！
第三範式：（消除非主鍵的傳遞關系）
我們也叫3NF。這個範式的前提必須先滿足第二範式的要求。第三範式主要是要看表中的非主鍵字段（列）與主鍵字段是否含有傳遞關系。什麼叫是否有傳遞關系呢？
假設有一張表如下圖：
這個表中的“商品類别名稱”、“商品類别描述”其實是可以根據“商品類别編号”這個字段去檢索到的，在這個表中具有字段傳遞關系。如果按照這個表去存儲資料庫的話，意味着要将“商品類别名稱”、“商品類别描述”兩個字段的資料重複很多次，使得表的空間産生嚴重備援。是以，我們考慮将這個表拆分為兩個表，如圖所示。
這樣建立資料表，就符合了資料庫第三範式3NF規範。如果我們想要在表内單獨增加一個商品類别也相當友善，假設我們系統想要顯示出來我們的商品類别，那麼就更友善了。
在實際開發中，我們的系統一般符合3NF就可以了，但是在實際工作生産過程中，為了優化我們的系統性能，有時候可能會犧牲資料空間換取工作性能，最終部分表的關系隻能符合2NF。這種情況也是非常正常的。
2、隊列
隊列（Queue）。隊列簡稱隊。是一種操作受限的線性表，隻允許在表的一端進行插入，而在表的另一端進行删除。向隊列中插入元素稱為入隊或進隊；删除元素稱為出隊或離隊。其操作特性為先進先出（First In First Out，FIFO），并且隻允許在隊尾進，隊頭出。
至于其他的内容，網上也有很多了，這裡就不多概述了。
3、OSI七層協定
4、三次握手
三次握手（Three-way Handshake）其實就是指建立一個TCP連接配接時，需要用戶端和伺服器總共發送3個包。進行三次握手的主要作用就是為了确認雙方的接收能力和發送能力是否正常、指定自己的初始化序列号為後面的可靠性傳送做準備。實質上其實就是連接配接伺服器指定端口，建立TCP連接配接，并同步連接配接雙方的序列号和确認号，交換TCP視窗大小資訊。
剛開始用戶端處于 Closed 的狀态，服務端處于 Listen 狀态。
進行三次握手：
第一次握手：用戶端給服務端發一個 SYN 封包，并指明用戶端的初始化序列号 ISN。此時用戶端處于 SYN_SENT 狀态。
首部的同步位SYN=1，初始序号seq=x，SYN=1的封包段不能攜帶資料，但要消耗掉一個序号。
第二次握手：伺服器收到用戶端的 SYN 封包之後，會以自己的 SYN 封包作為應答，并且也是指定了自己的初始化序列号 ISN(s)。同時會把用戶端的 ISN + 1 作為ACK 的值，表示自己已經收到了用戶端的 SYN，此時伺服器處于 SYN_RCVD 的狀态。
在确認封包段中SYN=1，ACK=1，确認号ack=x+1，初始序号seq=y。
第三次握手：用戶端收到 SYN 封包之後，會發送一個 ACK 封包，當然，也是一樣把伺服器的 ISN + 1 作為 ACK 的值，表示已經收到了服務端的 SYN 封包，此時用戶端處于 ESTABLISHED 狀态。伺服器收到 ACK 封包之後，也處于 ESTABLISHED 狀态，此時，雙方已建立起了連接配接。
确認封包段ACK=1，确認号ack=y+1，序号seq=x+1（初始為seq=x，第二個封包段是以要+1），ACK封包段可以攜帶資料，不攜帶資料則不消耗序号。
發送第一個SYN的一端将執行主動打開（active open），接收這個SYN并發回下一個SYN的另一端執行被動打開（passive open）。
在socket程式設計中，用戶端執行connect()時，将觸發三次握手。
5、四次揮手
建立一個連接配接需要三次握手，而終止一個連接配接要經過四次揮手（也有将四次揮手叫做四次握手的）。這由TCP的半關閉（half-close）造成的。所謂的半關閉，其實就是TCP提供了連接配接的一端在結束它的發送後還能接收來自另一端資料的能力。
TCP 連接配接的拆除需要發送四個包，是以稱為四次揮手(Four-way handshake)，用戶端或服務端均可主動發起揮手動作。
剛開始雙方都處于ESTABLISHED 狀态，假如是用戶端先發起關閉請求。四次揮手的過程如下：
第一次揮手：用戶端發送一個 FIN 封包，封包中會指定一個序列号。此時用戶端處于 FIN_WAIT1 狀态。
即發出連接配接釋放封包段（FIN=1，序号seq=u），并停止再發送資料，主動關閉TCP連接配接，進入FIN_WAIT1（終止等待1）狀态，等待服務端的确認。
第二次揮手：服務端收到 FIN 之後，會發送 ACK 封包，且把用戶端的序列号值 +1 作為 ACK 封包的序列号值，表明已經收到用戶端的封包了，此時服務端處于 CLOSE_WAIT 狀态。
即服務端收到連接配接釋放封包段後即發出确認封包段（ACK=1，确認号ack=u+1，序号seq=v），服務端進入CLOSE_WAIT（關閉等待）狀态，此時的TCP處于半關閉狀态，用戶端到服務端的連接配接釋放。用戶端收到服務端的确認後，進入FIN_WAIT2（終止等待2）狀态，等待服務端發出的連接配接釋放封包段。
第三次揮手：如果服務端也想斷開連接配接了，和用戶端的第一次揮手一樣，發給 FIN 封包，且指定一個序列号。此時服務端處于 LAST_ACK 的狀态。
即服務端沒有要向用戶端發出的資料，服務端發出連接配接釋放封包段（FIN=1，ACK=1，序号seq=w，确認号ack=u+1），服務端進入LAST_ACK（最後确認）狀态，等待用戶端的确認。
第四次揮手：用戶端收到 FIN 之後，一樣發送一個 ACK 封包作為應答，且把服務端的序列号值 +1 作為自己 ACK 封包的序列号值，此時用戶端處于 TIME_WAIT 狀态。需要過一陣子以確定服務端收到自己的 ACK 封包之後才會進入 CLOSED 狀态，服務端收到 ACK 封包之後，就處于關閉連接配接了，處于 CLOSED 狀态。
即用戶端收到服務端的連接配接釋放封包段後，對此發出确認封包段（ACK=1，seq=u+1，ack=w+1），用戶端進入TIME_WAIT（時間等待）狀态。此時TCP未釋放掉，需要經過時間等待計時器設定的時間2MSL後，用戶端才進入CLOSED狀态。
收到一個FIN隻意味着在這一方向上沒有資料流動。用戶端執行主動關閉并進入TIME_WAIT是正常的，服務端通常執行被動關閉，不會進入TIME_WAIT狀态。
在socket程式設計中，任何一方執行close()操作即可産生揮手操作。
6、ACID
分别是原子性、一緻性、隔離性、持久性。
1、原子性（Atomicity）
原子性是指事務包含的所有操作要麼全部成功，要麼全部失敗復原，是以事務的操作如果成功就必須要完全應用到資料庫，如果操作失敗則不能對資料庫有任何影響。
2、一緻性（Consistency）
一緻性是指事務必須使資料庫從一個一緻性狀态變換到另一個一緻性狀态，也就是說一個事務執行之前和執行之後都必須處于一緻性狀态。舉例來說，假設使用者A和使用者B兩者的錢加起來一共是1000，那麼不管A和B之間如何轉賬、轉幾次賬，事務結束後兩個使用者的錢相加起來應該還得是1000，這就是事務的一緻性。
3、隔離性（Isolation）
隔離性是當多個使用者并發通路資料庫時，比如同時操作同一張表時，資料庫為每一個使用者開啟的事務，不能被其他事務的操作所幹擾，多個并發事務之間要互相隔離。關于事務的隔離性資料庫提供了多種隔離級别，稍後會介紹到。
4、持久性（Durability）
持久性是指一個事務一旦被送出了，那麼對資料庫中的資料的改變就是永久性的，即便是在資料庫系統遇到故障的情況下也不會丢失送出事務的操作。例如我們在使用JDBC操作資料庫時，在送出事務方法後，提示使用者事務操作完成，當我們程式執行完成直到看到提示後，就可以認定事務已經正确送出，即使這時候資料庫出現了問題，也必須要将我們的事務完全執行完成。否則的話就會造成我們雖然看到提示事務處理完畢，但是資料庫因為故障而沒有執行事務的重大錯誤。這是不允許的。
7、HDFS架構
架構主要由四個部分組成，分别為HDFS Client、NameNode、DataNode和Secondary NameNode。下面我們分别介紹這四個組成部分。
1）Client：就是用戶端
（1）檔案切分。檔案上傳HDFS的時候，Client将檔案切分成一個一個的Block，然後進行存儲；
（2）與NameNode互動，擷取檔案的位置資訊；
（3）與DataNode互動，讀取或者寫入資料；
（4）Client提供一些指令來管理HDFS，比如啟動或者關閉HDFS；
（5）Client可以通過一些指令來通路HDFS；
2）NameNode：就是Master，它是一個主管、管理者
（1）管理HDFS的名稱空間；
（2）管理資料塊（Block）映射資訊；
（3）配置副本政策；
（4）處理用戶端讀寫請求。
3）DataNode：就是Slave。NameNode下達指令，DataNode執行實際的操作
（1）存儲實際的資料塊；
（2）執行資料塊的讀/寫操作。
4）Secondary NameNode：并非NameNode的熱備。當NameNode挂掉的時候，它并不能馬上替換NameNode并提供服務
（1）輔助NameNode，分擔其工作量；
（2）定期合并Fsimage和Edits，并推送給NameNode；
（3）在緊急情況下，可輔助恢複NameNode。
8、Spark RDD
RDD（Resilient Distributed Dataset）叫做分布式資料集，是Spark中最基本的資料抽象。代碼中是一個抽象類，它代表一個彈性的、不可變、可分區、裡面的元素可并行計算的集合。
RDD特點：
1）彈性
存儲的彈性：記憶體和磁盤的自動切換；
容錯的彈性：資料丢失可以自動回複；
計算的彈性：計算出錯重試機制；
分片的彈性：可根據需要重新分片。
2）分布式
資料存儲在大資料叢集的不同節點上
3）資料集
RDD封裝了計算邏輯，并不儲存資料
4）資料抽象
RDD是一個抽象類，需要子類具體實作
5）不可變
RDD封裝了計算邏輯，是不可以改變的，想要改變，隻能産生新的RDD，在新的RDD裡面封裝計算邏輯
6）可分區、并行計算
RDD屬性：
1）一組分區（Partition），即是資料集的基本組成機關；
2）一個計算每個分區的函數；
3）RDD之間的依賴關系；
4）一個Partitioner，即RDD的分片函數；控制分區的資料流向（鍵值對）；
5）一個清單，存儲存取每個Partition的優先位置（preferredlocation）。移動資料不如移動資源，除非資源不夠。
9、分布式一緻性協定
為了解決資料一緻性問題，出現了很多的一緻性協定和算法。比如 2PC（兩階段送出），3PC（三階段送出），Paxos算法等等。
2PC（兩階段送出）
Two-phase Commit（2PC）：保證一個事務跨越多個節點時保持 ACID 特性；
兩類節點：協調者（Coordinator）和參與者（Participants），協調者隻有一個，參與者可以有多個。
過程：
- 準備階段：協調者詢問參與者事務是否執行成功；
- 送出階段：如果事務在每個參與者上都執行成功，協調者發送通知讓參與者送出事務；否則，協調者發送通知讓參與者復原事務。
需要注意的是，在準備階段，參與者執行了事務，但是還未送出。隻有在送出階段接收到協調者發來的通知後，才進行送出或者復原。
存在的問題
- 參與者發生故障。解決方案：可以給事務設定一個逾時時間，如果某個參與者一直不響應，那麼認為事務執行失敗。
- 協調者發生故障。解決方案：将記錄檔同步到備用協調者，讓備用協調者接替後續工作。
3PC（三階段送出）
2PC存在的一系列問題，比如單點，容錯機制缺陷等等，進而産生了 3PC（三階段送出） 。那麼這三階段又分别是什麼呢？
千萬不要吧PC了解成個人電腦了，其實他們是 phase-commit 的縮寫，即階段送出。
- CanCommit階段：協調者向所有參與者發送 CanCommit 請求，參與者收到請求後會根據自身情況檢視是否能執行事務，如果可以則傳回 YES 響應并進入預備狀态，否則傳回 NO 。
- PreCommit階段：協調者根據參與者傳回的響應來決定是否可以進行下面的 PreCommit 操作。如果上面參與者傳回的都是 YES，那麼協調者将向所有參與者發送 PreCommit 預送出請求，參與者收到預送出請求後，會進行事務的執行操作，并将 Undo 和 Redo 資訊寫入事務日志中 ，最後如果參與者順利執行了事務則給協調者傳回成功的響應。如果在第一階段協調者收到了 任何一個 NO 的資訊，或者 在一定時間内 并沒有收到全部的參與者的響應，那麼就會中斷事務，它會向所有參與者發送中斷請求（abort），參與者收到中斷請求之後會立即中斷事務，或者在一定時間内沒有收到協調者的請求，它也會中斷事務。
- DoCommit階段：這個階段其實和 2PC 的第二階段差不多，如果協調者收到了所有參與者在 PreCommit 階段的 YES 響應，那麼協調者将會給所有參與者發送 DoCommit 請求，參與者收到 DoCommit 請求後則會進行事務的送出工作，完成後則會給協調者傳回響應，協調者收到所有參與者傳回的事務送出成功的響應之後則完成事務。若協調者在 PreCommit 階段 收到了任何一個 NO 或者在一定時間内沒有收到所有參與者的響應 ，那麼就會進行中斷請求的發送，參與者收到中斷請求後則會 通過上面記錄的復原日志 來進行事務的復原操作，并向協調者回報復原狀況，協調者收到參與者傳回的消息後，中斷事務。
這裡是 3PC 在成功的環境下的流程圖，你可以看到 3PC 在很多地方進行了逾時中斷的處理，比如協調者在指定時間内為收到全部的确認消息則進行事務中斷的處理，這樣能 減少同步阻塞的時間 。還有需要注意的是，3PC 在 DoCommit 階段參與者如未收到協調者發送的送出事務的請求，它會在一定時間内進行事務的送出。為什麼這麼做呢？是因為這個時候我們肯定保證了在第一階段所有的協調者全部傳回了可以執行事務的響應，這個時候我們有理由相信其他系統都能進行事務的執行和送出，是以不管協調者有沒有發消息給參與者，進入第三階段參與者都會進行事務的送出操作。
總之，3PC 通過一系列的逾時機制很好的緩解了阻塞問題，但是最重要的一緻性并沒有得到根本的解決，比如在 PreCommit 階段，當一個參與者收到了請求之後其他參與者和協調者挂了或者出現了網絡分區，這個時候收到消息的參與者都會進行事務送出，這就會出現資料不一緻性問題。
Paxos 算法
Paxos 算法是基于消息傳遞且具有高度容錯特性的一緻性算法，是目前公認的解決分布式一緻性問題最有效的算法之一，其解決的問題就是在分布式系統中如何就某個值（決議）達成一緻 。
在 Paxos 中主要有三個角色，分别為 Proposer提案者、Acceptor表決者、Learner學習者。Paxos 算法和 2PC 一樣，也有兩個階段，分别為 Prepare 和 accept 階段。
1）prepare 階段
- Proposer提案者：負責提出 proposal，每個提案者在提出提案時都會首先擷取到一個 具有全局唯一性的、遞增的提案編号N，即在整個叢集中是唯一的編号 N，然後将該編号賦予其要提出的提案，在第一階段是隻将提案編号發送給所有的表決者。
- Acceptor表決者：每個表決者在 accept 某提案後，會将該提案編号N記錄在本地，這樣每個表決者中儲存的已經被 accept 的提案中會存在一個編号最大的提案，其編号假設為 maxN。每個表決者僅會 accept 編号大于自己本地 maxN 的提案，在準許提案時表決者會将以前接受過的最大編号的提案作為響應回報給 Proposer 。
下面是 prepare 階段的流程圖，你可以對照着參考一下。
2）accept 階段
當一個提案被 Proposer 提出後，如果 Proposer 收到了超過半數的 Acceptor 的準許（Proposer 本身同意），那麼此時 Proposer 會給所有的 Acceptor 發送真正的提案（你可以了解為第一階段為試探），這個時候 Proposer 就會發送提案的内容和提案編号。
表決者收到提案請求後會再次比較本身已經準許過的最大提案編号和該提案編号，如果該提案編号 大于等于 已經準許過的最大提案編号，那麼就 accept 該提案（此時執行提案内容但不送出），随後将情況傳回給 Proposer 。如果不滿足則不回應或者傳回 NO 。
當 Proposer 收到超過半數的 accept ，那麼它這個時候會向所有的 acceptor 發送提案的送出請求。需要注意的是，因為上述僅僅是超過半數的 acceptor 準許執行了該提案内容，其他沒有準許的并沒有執行該提案内容，是以這個時候需要向未準許的 acceptor 發送提案内容和提案編号并讓它無條件執行和送出，而對于前面已經準許過該提案的 acceptor 來說 僅僅需要發送該提案的編号 ，讓 acceptor 執行送出就行了。
而如果 Proposer 如果沒有收到超過半數的 accept 那麼它将會将 遞增 該 Proposal 的編号，然後 重新進入 Prepare 階段 。
這個題可以仔細看看JavaGuide的解釋，講的很詳細
10、實習經曆
這個每個人肯定是都不一樣了，跟一面一樣，說清楚自己的就行
11、資料倉庫次元模組化
次元模型如圖所示，主要應用于OLAP系統中，通常以某一個事實表為中心進行表的組織，主要面向業務，特征是可能存在資料的備援，但是能友善的得到資料。
關系模型雖然備援少，但是在大規模資料，跨表分析統計查詢過程中，會造成多表關聯，這會大大降低執行效率。是以一般都會采用次元模型模組化，把相關各種表整理成兩種：事實表和次元表兩種。
在次元模組化的基礎上又可分為三種模型：星型模型、雪花模型、星座模型。
次元模組化是從分析決策的需求出發構模組化型，為分析需求服務，是以它重點關注使用者如何更快速的完成需求分析，同僚具有較好的大規模複雜查詢的相應能力。其典型的代表是星型模型，以及在一些特殊場景下使用的雪花模型。
次元模組化設計分為以下步驟：
- 選擇需要進行分析決策的業務過程
- 定義粒度
- 識别次元
- 确認事實
1）星型模型
星型模式是次元模型中最簡單的形式，也是資料倉庫以及資料集市開發中使用最廣泛的形式。星型模式由事實表和次元表組成，一個星型模式中可以有一個或多個事實表，每個事實表引用任意數量的次元表。
星型模型與雪花模型的差別主要在于次元的層級，标準的星型模型次元隻有一層，而雪花模型可能會涉及多層。
2）雪花模型
雪花模式是一種多元模型中表的邏輯布局，與星型模式相同，雪花模式也是由事實表和次元表所組成。所謂的“雪花化”就是将星型模型中的次元表進行規範化處理。當所有的次元表完成規範化後，就形成了以事實表為中心的雪花型結構，即雪花模式。
3）星座模型
資料倉庫由多個主題構成，包含多個事實表，而維表是公共的，可以共享（例如兩張事實表共用一些次元表時，就叫做星型模型），這種模式可以看做星型模式的彙集，因而稱作星系模式或者事實星座模式。
4）模型選擇
在資料倉庫模組化時，會涉及到模式的選擇，我們要根據不同模式的特點選擇适合具體業務的模式。
星型還是雪花，取決于性能優先，還是靈活更優先。
在實際開發中，不會絕對選擇一種，根據情況靈活組合，甚至并存（一層次元和多層次元都儲存）。但是整體看來，更傾向于次元更少的星型模型。
12、模組化常用理論
可以看一下我整理的資料倉庫的内容：https://www.nowcoder.com/discuss/934440
13、大資料的發展
先往好的說一通，然後再一個“但是”轉折，凡事都有利有弊，吹牛就行~
比如：
1、黨的十九大提出“推動網際網路、大資料、人工智能和實體經濟深度融合”。 2、2020年初，中央推出34萬億“新基建”投資計劃
| "新基建"投資規模拆分 | |
| 項目 | 2020年投資規模（億元） |
| 5G | 3000 |
| 特高壓 | 600 |
| 軌道交通 | 5000 |
| 充電樁 | 100 |
| 資料中心 | 1000 |
| 人工智能 | 350 |
| 工業網際網路 | 100 |
| 合計 | 10150 |
3、下一個風口
2020年是5G的元年，國家在大力鋪設5G裝置，2021年就是5G手機應用的開 始，也是大資料要爆發的1年。5G帶來的是每秒鐘10g的資料，會給每家公司都帶來海量的資料。那麼傳統的Java工具根本解決不了海量資料的存儲。就更不用說海量資料的計算了。如果你對5G的感觸不夠深，可以回憶一下3G和4G的差別。3G時隻能打電話、發短信，當時還覺得很好，覺得3G不錯。但是4G來了後，大家很少打電話和發短信了，都改為語音、視訊、直播、網上購物等生活方式，帶火了淘寶、京東、美團、位元組跳動等企業。沒有跟上節奏的百度，有點搖搖欲墜。
自古不變的真理：先入行者吃肉，後入行者喝湯，最後到的買單！
4、人才緊缺、競争壓力小
有句話叫：“選擇大于努力”選擇一個好的方向，少奮鬥十年。是否記得國家在2017年才開設大資料課程，當時是北京大學、人民大學等25所高校開設 第一批大資料課程。今年才2021年。也就是今年才畢業，那麼像Java、前端大學已經開設多少年了，包括教育訓練班都加在一起，10多年，可想而知目前市場上， Java和前端的人才有多少。
大資料的人才目前除了教育訓練機構培養的，沒有真正的科班畢業，而且真正能培養好大資料人才的教育訓練機構又有幾個。 是以目前選擇大資料是最佳選擇。如果擔心自己不是科班，其實也大可不必，因為大學真的學不了啥。隻要是能考上大學，說明你不笨，那學大資料就沒問題。