介紹

針對大資料元件特點歸納如下:

• 儲存：HDFS，hudi，Hbase, Kafka
• 計算引擎：Spark,Flink
• OLAP: Doris
• 排程: Yarn

下面主要從架構、元件原理、業務場景等角度針對相關元件的技術要點進行總結. 主要以問題驅動.

元件技術要點

1.hudi的cow,mor區別和應用場景？

Cow:
 寫時複製技術就是不同程序在訪問同一資源的時候，只有更新操作，才會去複製一份新的資料並更新替換，否則都是訪問同一個資源
 
 讀多寫少的資料，適合cow，離線批量更新場景
 
Mor:
新插入的資料儲存在deltalog 中，定期再將delta log合併進行parquet資料檔案。讀取資料時，會將deltalog跟老的資料檔案做merge，得到完整的資料返回
 
由於寫入資料先寫deltalog，且delta log較小，所以寫入成本較低，適用實時高頻更新場景

2. hdfs架構及各角色的作用，如何實現namenode 高可用？

Namenode: 管理節點，儲存元資料、檔案與資料塊對應關係的節點，資料以fsimage和editlog儲存在namenode本地磁碟

Datanode：檔案系統工作節點，根據需要儲存和檢索資料塊，定期向他們傳送儲存的塊列表
 
雙機熱備份，standby和active， 備用namenode為活動的namenode設定週期性的檢查點，判斷活動namenode是否失效

3. hbase架構，如何解決寫熱點問題？

• RegionServer：負責資料的讀寫服務，使用者通過與Region server互動來實現對資料的訪問
• HBaseHMaster：負責Region的分配及資料庫的建立和刪除等操作
• ZooKeeper：負責維護叢集的狀態（某臺伺服器是否線上，伺服器之間資料的同步操作及master的選舉等）
   
  熱點：

建立表的指定多個region，預設情況下一個表一個region

對rowkey進行雜湊，把多個請求寫分到不同的region上，需要對key進行md5，進行雜湊，這樣就可以把寫請求分到不同的region上面去

4.kafkarebalance機制，架構及寫入儲存機制？

rebalance機制：

當kafka遇到如下四種情況的時候，kafka會觸發Rebalance機制：
 
消費組成員發生了變更，比如有新的消費者加入了消費組組或者有消費者宕機
消費者無法在指定的時間之內完成訊息的消費
消費組訂閱的Topic發生了變化
訂閱的Topic的partition發生了變化
 
kafka中的重要概念:

Producer： 訊息生產者，向 Kafka Broker 發訊息的客戶端。
Consumer： 訊息消費者，從 Kafka Broker 取訊息的客戶端。
Consumer Group：消費者組（CG），消費者組內每個消費者負責消費不同分割槽的資料，提高消費能力。一個分割槽只能由組內一個消費者消費，消費者組之間互不影響。所有的消費者都屬於某個消費者組，即消費者組是邏輯上的一個訂閱者。
Broker： 一臺 Kafka 機器就是一個 broker。一個叢集由多個 broker 組成。一個 broker可以容納多個 topic。
Topic： 可以理解為一個佇列，topic 將訊息分類，生產者和消費者面向的是同一個 topic。
Partition： 為了實現擴充套件性，提高併發能力，一個非常大的 topic 可以分佈到多個 broker（即伺服器）上，一個 topic 可以分為多個 partition，每個 partition 是一個 有序的佇列。
Replica： 副本，為實現備份的功能，保證叢集中的某個節點發生故障時，該節點上的 partition 資料不丟失，且Kafka 仍然能夠繼續工作，Kafka 提供了副本機制，一個 topic 的每個分割槽都有若干個副本，一個 leader 和若干個 follower。
Leader： 每個分割槽多個副本的“主”副本，生產者傳送資料的物件，以及消費者消費資料的物件，都是 leader。
Follower： 每個分割槽多個副本的“從”副本，實時從 leader 中同步資料，保持和 leader資料的同步。leader 發生故障時，某個 follower 還會成為新的 leader。
offset：消費者消費的位置資訊，監控資料消費到什麼位置，當消費者掛掉再重新恢復的時候，可以從消費位置繼續消費。
Zookeeper： Kafka 叢集能夠正常工作，需要依賴於 zookeeper，zookeeper 幫助 Kafka儲存和管理叢集資訊。
 
寫入儲存機制：

由於生產者生產的訊息會不斷追加到 log 檔案末尾，為防止 log 檔案過大導致資料定位效率低下，Kafka 採取了分片和索引機制，將每個 partition 分為多個 segment，每個 segment 對應兩個檔案：“.index” 索引檔案和 “.log” 資料檔案。這些檔案位於同一檔案下，該資料夾的命名規則為：topic 名-分割槽號。例如，first 這個 topic 有三分分割槽，則其對應的資料夾為 first-0，first-1，first-2。

 ls/root/data/kafka/first-0

00000000000000009014.index   
00000000000000009014.log
00000000000000009014.timeindex
00000000000000009014.snapshot
leader-epoch-checkpoint

".index”檔案儲存大量的索引資訊，“.log” 檔案儲存大量的資料，索引檔案中的元資料指向對應資料檔案中 message 的物理偏移量。

5.spark寬依賴，窄依賴，資料傾斜問題解決方案？

寬依賴:是指1個父RDD分割槽對應多個子RDD的分割槽

窄依賴:是指一個或多個父RDD分割槽對應一個子RDD分割槽

寬依賴會產生shuffle,會跨網路拉取資料； 窄依賴在一個節點內就可以完成轉換。
 
資料傾斜解決方案：

1. 針對hive資料分佈不均勻，Hive ETL 預處理資料
2. 過濾少數導致資料傾斜的key
3. 提高shuffle操作的並行度
4. 雙重聚合，區域性聚合先給每個key都打上一個隨機數，再全域性聚合
5. 將reduce join轉為map join， BroadCast+filter(或者map)
6. 取樣傾斜key分拆join操作， 將兩次join的結果union合併起來，就是join的結果

6.flink狀態儲存，架構，如何實現精確一次語義？

Flink提供了三種開箱即用的狀態儲存方式：

1. MemoryStateBackend 記憶體儲存
2. FsStateBackend 檔案系統儲存
3. RocksDBStateBackend RocksDB儲存

如果沒有特殊配置，系統預設使用記憶體儲存方式
 
架構：
 
JobManager:
    JobManager具有許多與協調 Flink 應用程式的分散式執行有關的職責：它決定何時排程下一個 task（或一組 task）、對完成的 task 或執行失敗做出反應、協調checkpoint、並且協調從失敗中恢復等等
 
TaskManagers:
    TaskManager（也稱為worker）執行作業流的 task，並且快取和交換資料流
 
精確一次語義保證：
source端：  Flink Kafka Source 負責儲存 Kafka 消費 offset， Chckpoint成功時 Flink 負責提交這些寫入
sink端： 從 Source端開始，每個內部的 transform 任務遇到 checkpoint barrier（檢查點分界線）時，都會把狀態存到 Checkpoint 裡，  
資料處理完畢到 Sink 端時，Sink 任務首先把資料寫入外部 Kafka，這些資料都屬於預提交的事務（還不能被消費)
當所有運算元任務的快照完成, 此時 Pre-commit 預提交階段才算完成。才正式到兩階段提交協議的第二個階段：commit 階段。該階段中JobManager 會為應用中每個 Operator 發起 Checkpoint 已完成的回撥邏輯， 當 Sink任務收到確認通知，就會正式提交之前的事務，Kafka 中未確認的資料就改為“已確認”，資料就真正可以被消費了

7.doris架構設計，如何實現查詢計算較快？

架構：
FE: 主要負責查詢的編譯，分發和元資料管理（基於記憶體，類似HDFS NN）
BE: 主要負責查詢的執行和儲存系統
 
查詢計算快原因：
 1. MPP架構
 2. 列式儲存

8.yarn排程演算法有哪些，以及排程過程？

排程演算法：

1. 先進先出排程器(FIFO)    單佇列，根據提交作業的先後順序，先到先得。

2. 容量排程器

3. 公平排程器

容量排程器：優先選擇資源利用率低的佇列；
公平排程器：優先選擇對資源缺額比例大的。

9.flink作業提交流程？

Yarn-session: 應用模式與單作業模式的提交流程非常相似，只是初始提交給Yarn資源管理器的不再是具體的作業，而是整個應用。一個應用中可能包含了多個作業，這些作業都在Flink叢集中啟動各自對應的JobMaster。

Per-job:  與會話模式不同的是JobManager的啟動方式，以及省去了分發器。作業提交給JobMaster之後的步驟是一樣的

參考

1. 列式儲存： https://juejin.cn/post/7080504990900420644
2. Yarn排程器和排程演算法(FIFO、容量排程器 與 公平排程器)：https://blog.csdn.net/FunnyPrince_/article/details/120244552
3. Flink作業提交流程（Yarn叢集模式:  https://blog.csdn.net/FlatTiger/article/details/124195400