------------------------------------------------------------------------------------
*******大數據概念和基礎**********
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；