TDH-大數據基礎

------------------------------------------------------------------------------------
*******大數據概念和基礎**********
1.大數據的四個特色：數據規模大，生成、處理速度快，數據類型多樣，價值巨大密度低；
2.大數據歷史：三篇論文（GFS,mapReduce,bigTable）,CDH,HBASE,SPARK,TDH等；
-------------------------------------------------------------------------------

----------------------------------------------------------------------------------------
****************HDFS*********************
1.HDFS爲何不適合存儲大量小文件？
答：1.大量文件的元數據佔用NameNode大量內存空間
2.磁盤尋道時間超過讀取時間
-------------------------------------------------------------------------------------------- ----
2.HDFS 什麼時候離開安全模式？
答：ActiveNameNode啓動時HDFS進入安全模式只讀，datanode主動彙報可用block的可用狀況
即上報率=可用block數量/namenode元數據記錄的block數>=99.9%時離開安全模式
-------------------------------------------------------------------------------------------------
什麼時候觸發安全模式？
1.namenode磁盤不夠；2.DataNode沒法啓動；3.namenode重啓；4.block上報率低閾值；5.日至報錯；6.強制關機
----------------------------------------------------------------------------------------------------
3.ActiveNN與standbyNN的切換？
答：QJM機制實現最終一致，容許延遲，journalnode(2N+1)只要N+1個寫入成功便可，他寫edits編輯日誌
文件，activeNN掛掉standbyNN狀態變爲active
---------------------------------------------------------------------------------------------
4.HDFS寫文件過程？
答：1.客戶端請求上傳文件,輸入命令;
2.檢查HDFS目錄，容許上傳；
3.客戶端將文件切塊block並請求namenode;
4.namenode返回datanode信息;
5.客戶端與datanode創建傳輸，寫成功後通知namenode;/先寫數據再寫日誌
6.更新edits編輯日誌（當即）和fsimage文件（按期）寫入namenode，同時寫入journalnode,最後寫入內存(最新)；
7.後面standbyNN與activeNN按期同步。
------------------------------------------------------------------------------------
5.HDFS優缺點？
優勢：高可用（nameNode HA），高容錯(冗餘多副本)，高擴展(10k),海量數據，成本低
缺點：大量小文件不可存，不支持併發寫入，不支持低延時，不支持隨機寫
---------------------------------------------------------------------------------------------
6.HDFS元數據倆種存儲方式？
內存元數據：namenode
文件元數據：edits+fsimage
--------------------------------------------------------------------------------------------
7.HDFs最小文件存儲單元 block？
1.存儲在datanode,大小默認128M，多副本、均勻分佈在多個datanode(默認三個副本)；
2.block放置策略：副本1放在clinet 副本2放在另外一臺機架，副本3放在和副本2一塊兒的另外節點，其餘隨意；
3.block文件 命名：「 blk blk_文件大小」
-------------------------------------------------------------------------------------------------------
8.HDFS各個角色
1.ActiveNN做用：
惟一的集羣管理節點；管理HDFS文件系統命名空間；維護元數據信息（文件位置、權限、塊信息等）；處理客戶端請求；管理塊策略
2.standbyNN做用：
備份master節點宕機後替換activeNN；週期同步activeNN的edits文件，並按期合併fsimage文件和edits到本地磁盤；
3.nameNode做用：
存儲元數據（fsimage+edits）,fsimage(文件塊信息、位置、目錄、副本數)，edits（文件操做記錄）
4.dataNode做用：
Slive工做節點；存儲數據block;按期與namenode心跳彙報block信息（集羣啓動有可用block數彙報）；客戶端的數據讀寫操做；
---------------------------------------------------------------------------------------------
9.HDFS高可用？
經過QJM機制部署2N+1個journalNode節點，N+1個操做成功（寫edits）便可，利用ZK選舉Active節點

-------------------------------------------------------------------------------
***********************YARN*************************************
-------------------------------------------------------------------------------
1.yarn與mapreduce的關係？
答：
1.yarn是資源調度框架，mapreduce是分佈式計算框架；
2.yarn將jobTracker的資源管理和任務調度劃分開了，經過ResourceManager進行資源的統一管理和分配，
ApplicationManager進行解析mapreduce程序而後變成一個個小任務,須要多少資源向ResourceManager請求，
而後nodeManager和applicationManager協做分配containner執行任務。

2.如何部署yarn RM NM和hdfs的datanode namenode節點？
答：1.dataNode和nodeManager放在一塊兒
2.yarn的ResourceManager單獨放
3.倆個active不放在一塊兒，standby節點放在別的節點
4.namenode 和RM 至少倆個

3.Yarn三個角色ResourceManager/applicationManager/nodeManager介紹？
ResourceManager：統一管理集羣的全部資源，分配資源給applicationManager，接受nodemanager資源上報信息
applicationManager：管理應用程序，申請資源，任務調度
nodeManager：管理單個節點資源，上報資源使用，管理container生命週期

4.ResourceManagerHA高可用？
1個activeRM 多個standby RM;ZK選舉ActiveRM,宕機後主備切換;

5.yarn的資源調度策略？
1.FiFo Scheduler：先進先出，不靈活，利用率低；
2.capacity Scheduler：提早作預算；多個隊列共享資源；空閒資源優先給實際資源/預算資源小的隊列;
特色：彈性分配；多租戶；多層次；保證容量
3.fair scheduler:見面分一半 資源搶佔；佔用資源小於最低資源限制 則強制中止其餘隊列任務；隊列中有任務等待，則根據權重分配


-------------------------------------------------------------------------------
***********************mapreduce*************************************
-------------------------------------------------------------------------------
1.mapreduce核心思想？
1.分治思想；2.移動計算而不是移動數據

2.特色：計算跟着數據走，批處理，高容錯，擴展好

3.MR的幾個階段？
split:Split的大小默認 等於 Block大小，決定map任務數量；
map：split切片輸入，key-value輸出
reduce:由若干Reduce任務組成，數量由程序指定
shuffle:中間環節，包括分區（哈希取模）將map中間結果輸出到buffer區，而後分區排序，當達到閾值溢將
一個臨時文件寫到磁盤上，map任務結束前臨時文件合併爲一個map文件，fetch等

Partition決定了Map任務輸出的每條數據放入哪一個分區，交給哪一個Reduce任務處理
• Reduce任務的數量決定了Partition數量
• Partition編號 = Reduce任務編號 =「key hashcode % reduce task number」

Hadoop1和2的區別？
1.1有單點故障，資源描述簡單，負載過重；2融合yarn 高可用，高擴展，資源有專門的角色管理，任務和資源分開

4.mapreduce key-value輸入輸出的緣由？
答：
1.通用數據格式
2.shuffle過程要排序合併，哈希取模能夠決定分區partition

5.shuffle是調優關鍵？
答：shuffle的過程：先寫內存（內存中先分區後排序） 而後溢寫硬盤 再合併（大文件的分區排序）

-------------------------------------------------------------------------------
***********************spark*************************************
-------------------------------------------------------------------------------
1.RDD?
數據集拆分；數據存儲在內存或者磁盤；多分區；失效自動重構；轉換操做構造

2.RDD倆種依賴？
窄依賴（父RDD中的分區最多隻能被一個子RDD的一個分區使用）和寬依賴（子RDD依賴於全部父RDD）

3.spark 角色？
1.driver；main函數在裏面
2.sparContext：加載配置信息，初始化運行環境，建立DAGScheduler和TaskScheduler
3.Executor：能夠有多個 多線程
4.task:

4.spark的幾種運行模式？
1.local:單機運行，spark以多線程形式運行在本地；
2.standlone：集羣運行（規模不大）
3.yarn-client/yarn-cluster(生產環境)；

5.spark運行過程：
生成邏輯查詢計劃-物理查詢計劃-任務調度-執行任務

6.mapreduce比起saprk優缺點：
答：1.通用性強
2.mapreduce對現實的描述過於簡單隻有map,reduce倆個，spark細分rdd,分多個partition

----------------------------------------------------------------
********************Sqoop*********************
------------------------------------------------------------
Sqoop：用於rdbms和hadoop之間的數據導入導出
1.1和2版本的對比：
1.不安全，可是簡單快速高效，2.增長安全機制，多用戶，集中管理，穩定性和速度都很差

----------------------------------------------------------------
********************flume*********************
-----------------------------------------------------------
1.數據流模式：source---channel(能夠緩存)---sink
2.事務機制：支持重讀重寫
3.agent:jvm的運行單元，將外部數據送到目的地，內涵一個數據流，以event做爲數據單元進行傳輸
4.1個souece對應多個channel,1channel對應1個sink
5.flume單層架構（數據暴露，安全性差，產生許多小文件），多層架構（安全可是複雜）

-----------------------------------------------------------------
********************kafka*****************
------------------------------------------------------------------
1.kafka的幾個角色？
broker：server；
topic：消息貼標籤組成一類 分類的過程，同一類，方便處理，有了topic
就能夠隔離其餘類數據，他是一個邏輯概念；
partiion:物理概念要落盤 不可更改只讀，一個topic多個分區，一個分區一個目錄，
一個分區表明一個文件夾 一個分區多個副本 放在不一樣的broker上；
zk:broker的負載均衡，leader的選舉，元數據存儲，CG之間的rebalance，配置管理等；


2.kafka的partiton是一個先進先出隊列，寫入消息追加尾部，消費消息在隊列頭部；

3.kafka的CG內部的cosumer是互斥的，不一樣CG之間是共享消息的；

4.kafka最小數據存儲單元是segment，它包含（offset.index offset.timeindex,offset.log）三個文件，offset
是消息在分區中的惟一標識，他是有序的。
offset.index數據格式：偏移量，位置；
offset.timeindex數據格式：時間，偏移量；

5.kafka機制：
消息在broker中（server）按照topic分類，打上標籤；而後 每一個topic劃分爲多個partition，每一個partition進行
多個備份副本；多個consumer組成CG 進行訂閱消費數據

6.隊列在資源調度的做用？
答：共享集羣資源，隔離任務

7.kafka分了topic和partition做用？
答：利用多分區多副本實現高可用，一個topic（邏輯概念）表明一類數據，一個topic分爲多個partition（物理概念），
一個partition爲一個文件夾表示一種業務

8.kafka partition leader 和follower如何工做》？
答：partition leader 是選舉出來的主要負責一個分區的讀寫；follower同步分區信息到各個副本

9.zookeeper爲何不親自負責kafka的partition和副本之間的leader的選舉？
答：經過Zookeeper，從Kafka集羣中選舉出一個Broker做爲Kafka Controller Leader
• Kafka Controller Leader負責管理Kafka集羣的分區和副本狀態，避免分區副本直接在Zookeeper
上註冊Watcher和競爭建立臨時Znode，致使Zookeeper集羣負載太重，Kafka Controller Leader經過ISR(分區和備份列表)來選舉
partition Leader

-----------------------------------------------------------------
********************inceptor*****************
------------------------------------------------------------------
1.架構？
1.metastore:元數據存儲在TxSQL
2.client:waterdrop

2.數據模型？
1.database:系統會爲每一個數據庫建立一個目錄，目錄名=數據庫名.db;先刪表再刪庫；
2.table:內表：外表：
3.分區：
含義：將表按照某個或某幾個字段（分區鍵） 劃分爲更小的數據集；
存儲：分區數據存儲在表目錄下的子目錄中，一個分區對應一個子目錄，分區目錄名爲「分
區鍵=value」；
目的：減小全盤掃描，提升查詢效率
選取分區鍵：離散值、大量出現再select where中
4.分桶：
1.分桶時候 倆張表一樣操做，join的列，表一 join表二 where A1=A2 倆表各自利用哈希取模分桶，
一樣值的分在一樣的桶裏面，分桶有"打散"和"聚合"的功能（一樣值的在一個桶，也可能成倍數的桶裏）
2.提升取樣效率；
3.先分區再分桶；

5.讀時模式：
數據入庫不檢查規範性，在查詢時驗證

-----------------------------------------------------------------
********************slipertream*****************
------------------------------------------------------------------
1.輸入流的模式：
微批（Micro-batch）模式：將Input Stream按時間劃分紅若干小數據塊（Batch）來處理；
事件驅動（Event-driven）模式：以單條數據被Input Stream接收爲事件，逐條讀取並處理；

2.Derived Stream（衍生流）
含義：對已有的Stream變形（Transform）得來
－Transform一般由CSAS（Create Stream As Select）完成
3.streamSQL與普通SQL的區別
無阻塞模式

-----------------------------------------------------------------
********************hyperbase*****************
------------------------------------------------------------------
1.特色：高可靠，高併發，高性能，基於列，
key-value存儲，半結構化，newSQL，HFile落地，數據強一致性

2.表結構： RowKey | 列族 | 列限定符 | 時間戳
3.表特色：多版本，稀疏，無類型，動態增長列，大規模，
4.角色？
HMaster:
管理元數據;
管理表的建立、刪除和修改;
爲HRegionServer分配Region；
HRegionServer宕機後，從新分配其上的Region；
負責HRegionServer的負載均衡；

HRegionServer：
處理客戶端請求；
region的分裂；
storeFile的合併；

ZK：
HMaster高可用；
監控HRegionServer的上下線信息， 並通知HMaster；
存儲元數據的尋址入口；
存儲全部Region的尋址入口；

5.數據存儲過程？
1.Client 訪問ZK獲取meta表的region位置,而後記錄在ClientCache中；
2.讀取meta表，根據namespace/表名、rowkey獲取要寫入的region位置,並將meta表寫入ClientCache中；
3.HRegionServer先寫HLog文件（數據和操做）；
4.HRegionServer先寫MemStore，當數據量超過閾值時，溢寫到磁盤爲一個storefile(Hfile);
5.當Store中的StoreFile數量超過閾值時，若干小StoreFile合併爲一個大StoreFile;
6.當Region中最大Store的大小超過閾值時，region會等分爲兩個子Region；

6.數據讀過程？
1.12步驟同寫過程；
2.先從memStore讀再從storeFile中讀；

7.

----------------------------------------------------------------**********************search***********************----------------------------------------------------------------1.es基於lucene（單機），solr(實時性能差)，search增長了sql；