介紹
針對大數據組件特點歸納如下:
- 存儲：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.kafka rebalance機制，架構及寫入存儲機制？
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,會跨網絡拉取數據； 窄依賴在一個節點內就可以完成轉換。
數據傾斜解決方案：
- 針對hive數據分布不均勻，Hive ETL 預處理數據
- 過濾少數導致數據傾斜的key
- 提高shuffle操作的並行度
- 雙重聚合，局部聚合先給每個key都打上一個隨機數，再全局聚合
- 將reduce join轉為map join， BroadCast+filter(或者map)
- 采樣傾斜key分拆join操作， 將兩次join的結果union合並起來，就是join的結果
6.flink狀態存儲，架構，如何實現精確一次語義？
Flink提供了三種開箱即用的狀態存儲方式：
- MemoryStateBackend 內存存儲
- FsStateBackend 文件系統存儲
- 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調度算法有哪些，以及調度過程？
調度算法：
- 先進先出調度器(FIFO) 單隊列，根據提交作業的先后順序，先到先得。
- 容量調度器
- 公平調度器
容量調度器：優先選擇資源利用率低的隊列；
公平調度器：優先選擇對資源缺額比例大的。
9.flink作業提交流程？
Yarn-session: 應用模式與單作業模式的提交流程非常相似，只是初始提交給Yarn資源管理器的不再是具體的作業，而是整個應用。一個應用中可能包含了多個作業，這些作業都在Flink集群中啟動各自對應的JobMaster。
Per-job: 與會話模式不同的是JobManager的啟動方式，以及省去了分發器。作業提交給JobMaster之后的步驟是一樣的
參考
- 列式存儲： https://juejin.cn/post/7080504990900420644
- Yarn調度器和調度算法(FIFO、容量調度器 與 公平調度器)：https://blog.csdn.net/FunnyPrince_/article/details/120244552
- Flink作業提交流程（Yarn集群模式: https://blog.csdn.net/FlatTiger/article/details/124195400