第一講

大數(shù)據(jù)的基本特征是什么?

• 數(shù)據(jù)規(guī)模巨大(Volume)

傳統(tǒng)數(shù)據(jù) GB->TB
大數(shù)據(jù) TB->PB

• 數(shù)據(jù)類型多樣(Variety)

傳統(tǒng)數(shù)據(jù)：結(jié)構(gòu)化數(shù)據(jù)
大數(shù)據(jù)：結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)

• 生成和處理速度極快(Velocity)

傳統(tǒng)數(shù)據(jù)：數(shù)據(jù)量穩(wěn)定，增長(zhǎng)不快
大數(shù)據(jù)：實(shí)時(shí)產(chǎn)生處理、年增長(zhǎng)率超60%

• 價(jià)值巨大但密度較低(value)

傳統(tǒng)數(shù)據(jù)：統(tǒng)計(jì)報(bào)表
大數(shù)據(jù)：機(jī)器學(xué)習(xí)，深度學(xué)習(xí)

Hadoop經(jīng)歷了幾個(gè)發(fā)展階段，各有什么特點(diǎn)?

前hadoop時(shí)代

2003.10 Google發(fā)表了Google File System論文
2004.10 Google發(fā)表了MapReduce論文
2006.02 Apache Hadoop項(xiàng)目正式啟動(dòng)，并支持MapReduce和HDFS獨(dú)立發(fā)展
2006.11 Google發(fā)表了Bigtable論文

hadoop時(shí)代

2008.01Hadoop成為Apache頂級(jí)項(xiàng)目
2009.03Cloudera推出世界上首個(gè)Hadoop發(fā)行版——CDH，并完全開放源碼
2012.03HDFS NameNode HA加入Hadoop主版本

后hadoop時(shí)代

2013.11 星環(huán)科技發(fā)布了國(guó)內(nèi)首個(gè)全面支持Spark和Hadoop2.0的大數(shù)據(jù)基礎(chǔ)平臺(tái)軟件——TDH
2014.02Spark代替MapReduce成為Hadoop的缺省計(jì)算引擎，并成為Apache頂級(jí)項(xiàng)目

大數(shù)據(jù)技術(shù)體系大致分為幾層?每層包含哪些技術(shù)?

七層
數(shù)據(jù)源、數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)與管理、資源管理、通用計(jì)算、數(shù)據(jù)分析、數(shù)據(jù)展現(xiàn)

Apache Hadoop項(xiàng)目包含哪些子項(xiàng)目?簡(jiǎn)述一下它們的功能。

1、分布式文件系統(tǒng) HDFS（數(shù)據(jù)存儲(chǔ)與管理）
2、批處理計(jì)算框架 MapReduce (面向批處理的分布式計(jì)算框架)
3、高性能計(jì)算框架 Spark
（2、3都是用于計(jì)算，其中mapreduce有兩個(gè)功能 <計(jì)算框架+資源管理>，所以后面又出現(xiàn)yarn來分離功能資源管理）
4、分布式資源管理系統(tǒng) YARN （另一種資源管理器）專注于資源管理和作業(yè)調(diào)度
5、容器引擎 docker 打包應(yīng)用及依賴包到一個(gè)可移植的容器中，然后任意發(fā)布到linux上
6、容器化集群操作系統(tǒng) Kubernetes 容器化集群管理引擎、生產(chǎn)級(jí)容器編排工具
7、hadoop數(shù)據(jù)倉(cāng)庫(kù)&SQL引擎 Hive
Hadoop數(shù)據(jù)倉(cāng)庫(kù):企業(yè)決策支持
SQL引擎:對(duì)海量結(jié)構(gòu)化數(shù)據(jù)進(jìn)行高性能SQL查詢
8、分布式NoSQL數(shù)據(jù)庫(kù) HBase 主要用于半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)
9、分布式搜索引擎 ElastisSearch PB級(jí)以上基于Lucene實(shí)現(xiàn)全文數(shù)據(jù)的快速存儲(chǔ)、搜索和分析

Spark包含哪些組件?簡(jiǎn)述一下它們的功能。

(高性能分布式通用計(jì)算框架)

Spark Core:基礎(chǔ)計(jì)算框架(批處理、交互式分析)
Spark SQL:SQL引擎(海量結(jié)構(gòu)化數(shù)據(jù)的高性能查詢)
Spark Streaming:實(shí)時(shí)流處理(微批)
Spark MLlib:機(jī)器學(xué)習(xí)
Spark GraphX:圖計(jì)算

第二講

HDFS架構(gòu)中包含哪幾種角色?各自承擔(dān)什么功能?

Client
? 將文件切分為Block
? 與NameNode交互，獲取文件訪問計(jì)劃和相關(guān)元數(shù)據(jù) ? 與DataNode交互，讀取或?qū)懭霐?shù)據(jù)
? 管理HDFS

NameNode （master層）包括active 和 standby兩種形式standby是avtive的熱備節(jié)點(diǎn)

• active namenode 活動(dòng)master管理結(jié)點(diǎn)（一般只有一個(gè)，微小可能存在2個(gè)成為“腦裂”）它管理命名空間、管理元數(shù)據(jù)、管理block副本策略、處理客戶端請(qǐng)求，為DataNode分配任務(wù)
  *standby namenode AN的熱備節(jié)點(diǎn)（允許多個(gè)）AN當(dāng)機(jī)后通過法定人數(shù)選舉法快速升級(jí)為新的AN、同步元數(shù)據(jù)，即周期性下載edits編輯日志，生成fsimage鏡像檢查點(diǎn)文件

DataNode(slave層)
? Slave工作節(jié)點(diǎn)(可大規(guī)模擴(kuò)展)
? 存儲(chǔ)Block和數(shù)據(jù)校驗(yàn)和
? 執(zhí)行客戶端發(fā)送的讀寫操作
? 通過心跳機(jī)制定期(默認(rèn)3秒)向NameNode匯報(bào)運(yùn)行狀態(tài)和Block列表信息 ? 集群?jiǎn)?dòng)時(shí)，DataNode向NameNode提供Block列表信息

PS：master/slave：也就是我們所說的主從復(fù)制，主機(jī)數(shù)據(jù)更新后根據(jù)配置和策略，自動(dòng)同步到備機(jī)的master/slaver機(jī)制，Master以寫為主，Slave以讀為主。
可以實(shí)現(xiàn)讀寫分離等

為什么HDFS不合適存儲(chǔ)大量的小文件?（上課的時(shí)候講過?。。。?/h4>

• 元數(shù)據(jù)占用NameNode大量?jī)?nèi)存空間
  • 每個(gè)文件、目錄和Block的元數(shù)據(jù)都要占
    用150Byte
  • 存儲(chǔ)1億個(gè)元素，大約需要20GB內(nèi)存
  • 如果一個(gè)文件為10KB，1億個(gè)文件大小僅
    有1TB，卻要消耗掉20GB內(nèi)存
• 磁盤尋道時(shí)間會(huì)超過讀取時(shí)間,大文件可以使磁盤尋道時(shí)間不超過讀取時(shí)間

---

Block副本的放置策略是什么?如何理解?

• 副本1:放在Client所在節(jié)點(diǎn) -對(duì)于遠(yuǎn)程Client，系統(tǒng)會(huì)隨機(jī)選擇節(jié)點(diǎn)
• 副本2:放在不同的機(jī)架節(jié)點(diǎn)上
• 副本3:放在與第二個(gè)副本同一機(jī)架的不同節(jié)點(diǎn)上
• 副本N:隨機(jī)選擇
• 節(jié)點(diǎn)選擇:同等條件下優(yōu)先選擇空閑節(jié)點(diǎn)

HDFS離開安全模式的條件是什么?

• Block上報(bào)率:DataNode上報(bào)的可用Block個(gè)數(shù) / NameNode元數(shù)據(jù)記錄的Block個(gè)數(shù)
• 當(dāng)Block上報(bào)率 >= 閾值時(shí)，HDFS才能離開安全模式，默認(rèn)閾值為0.999
• 不建議手動(dòng)強(qiáng)制退出安全模式

HDFS是如何實(shí)現(xiàn)高可用的?（上課的時(shí)候也講過！?。。ǚǘㄈ藬?shù)機(jī)制）單數(shù)

利用QJM實(shí)現(xiàn)元數(shù)據(jù)高可用

• QJM機(jī)制(Quorum Journal Manager)
  • 只要保證Quorum(法定人數(shù))數(shù)量的操作成功，就認(rèn)為這是一次最終成功的操作
• QJM共享存儲(chǔ)系統(tǒng)
  • 部署奇數(shù)(2N+1)個(gè)JournalNode
  • JournalNode負(fù)責(zé)存儲(chǔ)edits編輯日志 -寫edits的時(shí)候，只要超過半數(shù)(>=N+1)的JournalNode返回成功，就代表本次寫入成功
  • 最多可容忍N(yùn)個(gè)JournalNode宕機(jī)
  • 基于Paxos算法實(shí)現(xiàn)

ps：“高可用(High Availability)“是系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一,它通常是指,通過設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。

第三講

簡(jiǎn)述YARN與MapReduce的關(guān)系。

YARN的出現(xiàn)為了處理MapReduce的缺陷（身兼兩職:計(jì)算框架 + 資源管理系統(tǒng)。它的JobTracker ：既做資源管理，又做任務(wù)調(diào)度 、任務(wù)太重，開銷過大 、存在單點(diǎn)故障）yarn是分布式通用資源管理系統(tǒng)，可以讓mapreduce只做計(jì)算框架一件事，而且可以將JobTracker的資源管理、任務(wù)調(diào)度功能分離。

為什么要設(shè)計(jì)ApplicationMaster這一角色?

它用來管理應(yīng)用程序?qū)嵗恼麄€(gè)生命周期，包括任務(wù)調(diào)度和資源申請(qǐng)
主要功能是：管理應(yīng)用程序?qū)嵗?、向ResourceManager申請(qǐng)任務(wù)執(zhí)行所需的資源 、任務(wù)調(diào)度和監(jiān)管
ApplicationMaster 的職責(zé)有：向調(diào)度器索要適當(dāng)?shù)馁Y源容器，運(yùn)行任務(wù)，跟蹤應(yīng)用程序的狀態(tài)和監(jiān)控它們的進(jìn)程，處理任務(wù)的失敗原因。

Zookeeper在YARN中承擔(dān)了哪些功能?

Active節(jié)點(diǎn)選舉
恢復(fù)Active RM的原有狀態(tài)信息

在項(xiàng)目實(shí)踐中，如何部署YARN的ResourceManager、NodeManager和HDFS的NameNode、DataNode?

（1）HDFS集群：負(fù)責(zé)海量數(shù)據(jù)的存儲(chǔ)，集群中的角色主要有 NameNode / DataNode/SecondaryNameNode。

（2）YARN集群：負(fù)責(zé)海量數(shù)據(jù)運(yùn)算時(shí)的資源調(diào)度，集群中的角色主要有 ResourceManager /NodeManager

可以把Hadoop想象成單機(jī)操作系統(tǒng)擴(kuò)展到一個(gè)集群的情況，其中的NameNode就是文件系統(tǒng)的中央管理樞紐，ResourceManager就相當(dāng)于單機(jī)中負(fù)責(zé)管理機(jī)器中的內(nèi)存、cpu的那個(gè)操作系統(tǒng)的調(diào)度系統(tǒng)。

隊(duì)列在資源調(diào)度中起什么作用?

將需要調(diào)度的資源放在隊(duì)列中，然后進(jìn)行不同資源調(diào)度策略時(shí)，對(duì)不同隊(duì)列中的資源可以進(jìn)行不同的處理。

容量調(diào)度器與公平調(diào)度器的區(qū)別是什么?

容器調(diào)度器的每個(gè)隊(duì)列都要預(yù)設(shè)資源分配的比列（提前做預(yù)算），而公平調(diào)度器通過平分的方式，動(dòng)態(tài)分配資源，無需預(yù)先設(shè)定資源分配比例

容量調(diào)度器會(huì)嚴(yán)格按預(yù)設(shè)比例分配資源嗎?

彈性分配:空閑資源可以分配給任何隊(duì)列，當(dāng)多個(gè)隊(duì)列爭(zhēng)用時(shí)，會(huì)按比例進(jìn)行平衡

簡(jiǎn)述公平調(diào)度器中隊(duì)列權(quán)重和資源搶占的含義。

隊(duì)列權(quán)重：當(dāng)隊(duì)列中有任務(wù)等待，并且集群中有空閑資源時(shí)，每個(gè)隊(duì)列可 以根據(jù)權(quán)重獲得不同比例的空閑資源

資源搶占：終止其他隊(duì)列的任務(wù)，使其讓出所占資源，然后將資源分配給占用資源量少于最小資源量限制的隊(duì)列

第四講

簡(jiǎn)述MR Split與HDFS Block的關(guān)系。

沒有關(guān)系，Split的劃分方式由程序設(shè)定，Split與HDFS Block沒有嚴(yán)格的對(duì)應(yīng)關(guān)系

為什么MapReduce要求輸入輸出必須是key-value鍵值對(duì)?

MapReduce框架只操作鍵值對(duì)<key, value>，因此這個(gè)框架中任務(wù)的輸入和輸出都是鍵值對(duì)形式<key, value>
（廢話？）

簡(jiǎn)述Shuffle的工作原理。

? Map端
-Map任務(wù)將中間結(jié)果寫入專用內(nèi)存緩沖區(qū)Buffer(默認(rèn)100M)，同時(shí)進(jìn)行Partition和Sort(先按“key
hashcode % reduce task number”對(duì)數(shù)據(jù)進(jìn)行分區(qū)，分區(qū)內(nèi)再按key排序)
-當(dāng)Buffer的數(shù)據(jù)量達(dá)到閾值(默認(rèn)80%)時(shí)，將數(shù)據(jù)溢寫(Spill)到磁盤的一個(gè)臨時(shí)文件中，文件內(nèi)數(shù)據(jù)先分區(qū)后排序
-Map任務(wù)結(jié)束前，將多個(gè)臨時(shí)文件合并(Merge)為一個(gè)Map輸出文件，文件內(nèi)數(shù)據(jù)先分區(qū)后排序
? Reduce端
-Reduce任務(wù)從多個(gè)Map輸出文件中主動(dòng)抓取(Fetch)屬于自己的分區(qū)數(shù)據(jù)，先寫入Buffer，數(shù)據(jù)量達(dá)到閾值后，溢寫到磁盤的一個(gè)臨時(shí)文件中
-數(shù)據(jù)抓取完成后，將多個(gè)臨時(shí)文件合并為一個(gè)Reduce輸入文件，文件內(nèi)數(shù)據(jù)按key排序

從編程模型的視角，MapReduce有哪些優(yōu)缺點(diǎn)?

1、優(yōu)點(diǎn)

• 高容錯(cuò):任務(wù)失敗，自動(dòng)調(diào)度到其他節(jié)點(diǎn)重新執(zhí)行
• 高擴(kuò)展:計(jì)算能力隨著節(jié)點(diǎn)數(shù)增加，近似線性遞增
• 適用于海量數(shù)據(jù)的離線批處理
• 降低了分布式編程的門檻

2、缺點(diǎn)(不適合)

? OLAP
-要求毫秒或秒級(jí)返回結(jié)果
? 流計(jì)算
-流計(jì)算的輸入數(shù)據(jù)集是動(dòng)態(tài)的，而MapReduce是靜態(tài)的
? DAG計(jì)算
-多個(gè)任務(wù)之間存在依賴關(guān)系，后一個(gè)的輸入是前一個(gè)的輸出，構(gòu)成有向無環(huán)圖DAG -每個(gè)MapReduce作業(yè)的輸出結(jié)果都會(huì)落盤，造成大量磁盤IO，導(dǎo)致性能非常低下

RDD的“彈性”主要體現(xiàn)在哪里?

失效后自動(dòng)重構(gòu)
1.自動(dòng)進(jìn)行內(nèi)存和磁盤切換
2.基于lineage的高效容錯(cuò)
3.task如果失敗會(huì)特定次數(shù)的重試
4.stage如果失敗會(huì)自動(dòng)進(jìn)行特定次數(shù)的重試，而且只會(huì)只計(jì)算失敗的分片
5.checkpoint【每次對(duì)RDD操作都會(huì)產(chǎn)生新的RDD，如果鏈條比較長(zhǎng)，計(jì)算比較笨重，就把數(shù)據(jù)放在硬盤中】和persist 【內(nèi)存或磁盤中對(duì)數(shù)據(jù)進(jìn)行復(fù)用】(檢查點(diǎn)、持久化)
6.數(shù)據(jù)調(diào)度彈性：DAG TASK 和資源管理無關(guān)
7.數(shù)據(jù)分片的高度彈性repartion

RDD寬依賴為什么又稱為Shuffle依賴?

子RDD的部分或全部分區(qū)數(shù)據(jù)丟失或損壞，從所有父RDD分區(qū)重新計(jì)算，必須進(jìn)行Shuffle

Spark運(yùn)行模式有幾種?Driver的主要功能是什么?

? Local模式

? 單機(jī)運(yùn)行，通常用于測(cè)試
? Spark程序以多線程方式直接運(yùn)行在本地

? Standalone模式

? Spark集群獨(dú)立運(yùn)行，不依賴于第三方資源
管理系統(tǒng)，如:YARN、Mesos
? 采用Master/Slave架構(gòu)
? Driver在Worker中運(yùn)行，Master只負(fù)責(zé)集群
管理
? ZooKeeper負(fù)責(zé)Master HA，避免單點(diǎn)故障
? 適用于集群規(guī)模不大，數(shù)據(jù)量不大的情況

? YARN/Mesos模式

? YARN-Client模式:適用于交互和調(diào)試
? YARN-Cluster模式:適用于生產(chǎn)環(huán)境

Driver主要功能

• 一個(gè)Spark程序有一個(gè)Driver，一個(gè)Driver創(chuàng)建一個(gè)SparkContext，程序的main函數(shù)運(yùn)行在Driver中
• 負(fù)責(zé)解析Spark程序、劃分Stage、調(diào)度任務(wù)到Executor上執(zhí)行

簡(jiǎn)述Spark的程序執(zhí)行過程。

? Driver -一個(gè)Spark程序有一個(gè)Driver，一個(gè)Driver創(chuàng)建一個(gè)SparkContext，程序的main函數(shù)運(yùn)行在Driver中 -負(fù)責(zé)解析Spark程序、劃分Stage、調(diào)度任務(wù)到Executor上執(zhí)行
? SparkContext -負(fù)責(zé)加載配置信息，初始化運(yùn)行環(huán)境，創(chuàng)建DAGScheduler和TaskScheduler
? Executor -負(fù)責(zé)執(zhí)行Driver分發(fā)的任務(wù)，一個(gè)節(jié)點(diǎn)可以啟動(dòng)多個(gè)Executor，每個(gè)Executor通過多線程運(yùn)行多個(gè)任務(wù)
? Task -Spark運(yùn)行的基本單位，一個(gè)Task負(fù)責(zé)處理若干RDD分區(qū)的計(jì)算邏輯

DAGScheduler是如何劃分Task的?

? 根據(jù)任務(wù)的依賴關(guān)系建立DAG

? 根據(jù)依賴關(guān)系是否為寬依賴，即是否存在Shuffle，將DAG劃分為不同的階段(Stage)
? 將各階段中的Task組成的TaskSet提交到TaskScheduler

第七講

為什么要對(duì)Consumer進(jìn)行分組?

為了加快讀取速度，多個(gè)Consumer可劃分為一個(gè)組(Consumer Group, CG)，并行消費(fèi)同 一個(gè)Topic

為什么Kafka分了Topic之后，還要分Partition?

一個(gè)Topic可分為多個(gè)分區(qū)，相當(dāng)于把一個(gè)數(shù)據(jù)集分成多份，分別存儲(chǔ)不同的分區(qū)中,然后分區(qū)可以設(shè)置多個(gè)副本，副本存儲(chǔ)在不同的Broker中，這樣就可以避免Kafka早期版本沒有Replication概念，一旦某個(gè)Brocker宕機(jī)，其上的分區(qū)數(shù)據(jù)就可能丟失，這樣的錯(cuò)誤。

Partition Leader和Follower是如何分工合作的?

從一個(gè)分區(qū)的多個(gè)副本中選舉一個(gè)Partition Leader，由Leader負(fù)責(zé)讀寫，其他副本作為Follower從Leader同步消息

*為什么Zookeeper不親自負(fù)責(zé)Partition Leader選舉?

Kafka Controller Leader負(fù)責(zé)管理Kafka集群的分區(qū)和副本狀態(tài)，避免分區(qū)副本直接在Zookeeper上注冊(cè)Watcher和競(jìng)爭(zhēng)創(chuàng)建臨時(shí)Znode，導(dǎo)致Zookeeper集群負(fù)載過重

第十一講

如何定位Inceptor?它與Hive有什么區(qū)別?

定位

? 分布式通用SQL引擎 -支持Slipstream、ArgoDB、Hyperbase和Search -構(gòu)建星環(huán)新一代邏輯數(shù)據(jù)倉(cāng)庫(kù)
? 分布式數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)
? 基于Hive和Spark打造
? 用于離線分析和交互式分析(Holodesk -> ArgoDB)

它是在hive和spark的基礎(chǔ)上進(jìn)一步優(yōu)化的，它是hadoop領(lǐng)域中SQL支持最完善的。與Apache Hive相比，數(shù)據(jù)分析處理速度有顯著提升

如何理解Inceptor讀時(shí)模式。

? 含義:數(shù)據(jù)寫入數(shù)據(jù)倉(cāng)庫(kù)時(shí)，不檢查數(shù)據(jù)的規(guī)范性，而是在查詢時(shí)再驗(yàn)證
?特點(diǎn)
-數(shù)據(jù)寫入速度快，適合處理大規(guī)模數(shù)據(jù)
-查詢時(shí)處理尺度很寬松(弱校驗(yàn))，盡可能恢復(fù)各種錯(cuò)誤

分區(qū)的目的是什么?分區(qū)有幾種類型?如何將數(shù)據(jù)導(dǎo)入分區(qū)表?

目的:減少不必要的全表掃描，縮小查詢范圍，提升查詢效率

類型：
單值分區(qū):一個(gè)分區(qū)對(duì)應(yīng)分區(qū)鍵的一個(gè)值
-單值靜態(tài)分區(qū):導(dǎo)入數(shù)據(jù)時(shí)，必須手動(dòng)指定目標(biāo)分區(qū)
-單值動(dòng)態(tài)分區(qū):導(dǎo)入數(shù)據(jù)時(shí)，系統(tǒng)可以動(dòng)態(tài)判斷目標(biāo)分區(qū)

范圍分區(qū):一個(gè)分區(qū)對(duì)應(yīng)分區(qū)鍵的一個(gè)范圍(區(qū)間)
? 每個(gè)分區(qū)對(duì)應(yīng)分區(qū)鍵的一個(gè)區(qū)間，凡是落在指定區(qū)間內(nèi)的記錄都被存儲(chǔ)在對(duì)應(yīng)的分區(qū)下
? 各范圍分區(qū)按順序排列，前一個(gè)分區(qū)的最大值即為后一個(gè)分區(qū)的最小值
? 創(chuàng)建范圍分區(qū)

分桶的目的是什么?如何將數(shù)據(jù)導(dǎo)入分桶表?

? 含義:按分桶鍵哈希取模的方式，將表中數(shù)據(jù)隨機(jī)、均勻地分發(fā)到若干桶文件中
? 目的:通過改變數(shù)據(jù)的存儲(chǔ)分布，提升取樣、Join等特定任務(wù)的執(zhí)行效率
? 將數(shù)據(jù)寫入分桶表
-分桶表在創(chuàng)建的時(shí)候只定義Schema，且數(shù)據(jù)寫入時(shí)系統(tǒng)不會(huì)自動(dòng)分桶，所以需要先人工分桶再寫入
-寫入分桶表只能通過Insert，而不能通過Load，因?yàn)長(zhǎng)oad只導(dǎo)入文件，并不分桶
-如果分桶表創(chuàng)建時(shí)定義了排序鍵，那么數(shù)據(jù)不僅要分桶，還要排序
-如果分桶鍵和排序鍵不同，且按降序排列，使用Distribute by ... Sort by分桶排序
-如果分桶鍵和排序鍵相同，且按升序排列(默認(rèn))，使用Cluster by分桶排序

第十二講

事件驅(qū)動(dòng)模式與微批模式有什么不同?

微批(Micro-batch)模式:將Input Stream按時(shí)間劃分成若干小數(shù)據(jù)塊(Batch)來處理，即在由若干單位時(shí)間組成的時(shí)間間隔內(nèi)，將接收的數(shù)據(jù)放到一個(gè)Batch中(Batch的時(shí)間長(zhǎng)度稱為Batch Duration)
-事件驅(qū)動(dòng)(Event-driven)模式:以單條數(shù)據(jù)被Input Stream接收為事件，逐條讀取并處理

兩種處理模式下的窗口變形有什么不同?

-微批模式
窗口變形(多Batch變形)
*對(duì)一個(gè)時(shí)間窗口(Window)內(nèi)的多個(gè)Batch進(jìn)行計(jì)算得到新Batch的過程
*Window Stream:通過窗口變形得到的Derived Stream
*兩個(gè)重要參數(shù):Length和Slide，Length是窗口持續(xù)時(shí)間，Slide是兩個(gè)相鄰窗口之間的間隔時(shí)間， Length和Slide必須是Batch Duration的倍數(shù)

窗口變形(多數(shù)據(jù)變形):對(duì)一個(gè)時(shí)間窗口(Window)內(nèi)的多條數(shù)據(jù)進(jìn)行計(jì)算得到新數(shù)據(jù)的過程

簡(jiǎn)述一下SteamJob的主要作用。

對(duì)一個(gè)或多個(gè)Stream進(jìn)行計(jì)算，并將結(jié)果寫入一張表的任務(wù)
StreamJob是觸發(fā)StreamSQL執(zhí)行的Action，一般具有插入結(jié)果表語(yǔ)義
StreamJob主要存儲(chǔ)StreamJob Level的配置參數(shù)，以及對(duì)應(yīng)的SQL

StreamSQL與普通SQL有什么區(qū)別?

• DML語(yǔ)句的運(yùn)行機(jī)制不同
  ? 普通SQL:阻塞式運(yùn)行
  -提交SQL后，用戶需等待SQL執(zhí)行結(jié)束，期間命令被持續(xù)阻塞，無法執(zhí)行其他命令
  ? StreamSQL:背景運(yùn)行
  -計(jì)算任務(wù)持續(xù)在后臺(tái)運(yùn)行
  -執(zhí)行StreamSQL的DML語(yǔ)句會(huì)立即返回結(jié)果
• 查詢結(jié)果的輸出不同
  ? 普通SQL:查詢結(jié)果或者顯示在Console，或者通過JDBC讀取
  ? StreamSQL:用戶必須顯式地指定查詢結(jié)果輸出到某個(gè)地方
  -后臺(tái)持續(xù)運(yùn)行的SQL無法直接跟Console交互

-查詢結(jié)果通常會(huì)插入到表中，如:Insert Into result_table Select ...

第十三講

Search的數(shù)據(jù)模型與關(guān)系數(shù)據(jù)庫(kù)有怎樣的對(duì)應(yīng)關(guān)系?

index(索引)->table(表)

document(文檔)->row(行)
field(字段)->column(列)

Seach包含哪幾類節(jié)點(diǎn)，它們各自負(fù)責(zé)哪些工作?

節(jié)點(diǎn):一個(gè)運(yùn)行中的ElasticSearch實(shí)例

主節(jié)點(diǎn)(MasterNode)
? 負(fù)責(zé)管理集群內(nèi)的所有變更，如增刪節(jié)點(diǎn)、增刪索引、分配分片等，不負(fù)責(zé)文檔更新和搜索
? 每個(gè)集群只有一個(gè)主節(jié)點(diǎn)，默認(rèn)情況下任何節(jié)點(diǎn)都可能被選為主節(jié)點(diǎn)
? 硬件配置:普通服務(wù)器(CPU、內(nèi)存消耗一般)

數(shù)據(jù)節(jié)點(diǎn)(DataNode)
? 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，即文檔的增刪改查
? 分離主節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)是一個(gè)比較好的選擇，因?yàn)樗饕退阉鞑僮鲿?huì)消耗大量資源
? 硬件配置:較高配置服務(wù)器(主要消耗磁盤和內(nèi)存)

客戶端節(jié)點(diǎn)(ClientNode / 路由節(jié)點(diǎn))
? 負(fù)責(zé)路由請(qǐng)求，實(shí)現(xiàn)集群訪問的負(fù)載均衡
? 集群規(guī)模較大時(shí)非常有用，協(xié)調(diào)主節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)，根據(jù)集群狀態(tài)直接路由請(qǐng)求

簡(jiǎn)述Index、Document、Shard與副本Shard的關(guān)系。

? Shard分為主Shard和副本Shard，后者是前者的精確復(fù)制，每個(gè)Shard可有零個(gè)或多個(gè)副本
? Index的任意一個(gè)Document都?xì)w屬于一個(gè)主Shard，主Shard的數(shù)量決定了Index的最大數(shù)據(jù)量
? Index建立時(shí)就必須明確主Shard數(shù)且不能修改，但副本Shard數(shù)可以隨時(shí)修改
? 寫操作只能被主Shard處理，讀操作可同時(shí)被主Shard或副本Shard處理
-對(duì)于讀操作，理論上擁有更多的副本，將擁有更高的吞吐量，但如果只在相同節(jié)點(diǎn)數(shù)目的集群上增加
副本并不能提高性能，因?yàn)槊總€(gè)Shard獲得的資源會(huì)變少，這時(shí)需要增加更多的硬件資源來提升吞吐 量

簡(jiǎn)述Search更新文檔的基本流程。

更新文檔
(1)客戶端向Node1(路由節(jié)點(diǎn))發(fā)送新建、索引或刪除文檔請(qǐng)求

(2)通過文檔id確定該文檔屬于分片0，請(qǐng)求被轉(zhuǎn)發(fā)到Node3，因?yàn)榉制?的主分片在Node3上
(3)Node3在主分片上執(zhí)行更新操作，如果成功了，Node3將請(qǐng)求并行轉(zhuǎn)發(fā)到Node1和Node2的 副本分片上，一旦所有副本分片都報(bào)告同步成功，Node3將向Node1報(bào)告更新成功， 最后 Node1向客戶端報(bào)告成功

第十四講

為什么可以將Hyperbase表看作是一張四維表?

因?yàn)樗紫鹊谝涣惺荝owKey，下是每一行（包含多行），然后第二列是列族，下面包括很多列限定符，再是時(shí)間戳，表示存入時(shí)間所以是一張四維表。

為什么說Hyperbase是一個(gè)Key-Value數(shù)據(jù)庫(kù)?

簡(jiǎn)述Table、Region、Store和StoreFile的關(guān)系。

一個(gè)table由多行組成，而系統(tǒng)將表水平劃分(按行)為多個(gè)Region，每個(gè)Region保存表的一段連續(xù)數(shù)據(jù)，默認(rèn)每張表開始只有一個(gè)Region，隨著數(shù)據(jù)不斷寫入，Region不斷增大，當(dāng)Region大小超過閥值時(shí)，當(dāng)前Region會(huì)分裂成兩個(gè)子Region，而一個(gè)Region由多個(gè)Store組成，每個(gè)Store存儲(chǔ)一個(gè)列族，而store由內(nèi)存中的MemStore和磁盤中的若干StoreFile組成，MemStore是Store的內(nèi)存緩沖區(qū)，數(shù)據(jù)讀寫都先訪問MemStore，StoreFile是MemStore的磁盤溢寫文件，在HDFS中被稱為HFile

為什么要進(jìn)行Region Split和StoreFile Compaction?

StoreFile Compaction
? 含義:將Store中的全部或部分StoreFile合并為一個(gè)StoreFile的過程
? 目的:減少StoreFile數(shù)量，提升數(shù)據(jù)讀取效率

Region Split
? 含義:根據(jù)一定的觸發(fā)條件和分裂策略，將Region劃分為兩個(gè)子Region的過程
? 目的:實(shí)現(xiàn)數(shù)據(jù)訪問的負(fù)載均衡

簡(jiǎn)述HBase BulkLoad的基本過程。

? 抽取:從數(shù)據(jù)源中抽取數(shù)據(jù)
-對(duì)于MySQL，運(yùn)行mysqldump命令導(dǎo)出數(shù)據(jù)
? 轉(zhuǎn)換:利用MapReduce，將數(shù)據(jù)轉(zhuǎn)換為HFile文件
-對(duì)于TSV或CSV文件，使用HBase ImportTsv工具將其轉(zhuǎn)換成HFile文件
-每個(gè)輸出文件夾中的每個(gè)區(qū)域都會(huì)創(chuàng)建一個(gè)HFile文件
-HDFS中的可用磁盤空間至少為原始輸入文件的兩倍。例如:對(duì)于100GB的mysqldump導(dǎo)出文件，HDFS中至少預(yù)留不少于200GB的磁盤空間，可在任務(wù)結(jié)束后刪除原始輸入文件
? 加載:將HFile文件加載到HBase
-利用HBase CompleteBulkLoad工具，將HFile文件移動(dòng)到HBase表的相應(yīng)目錄中，完成加載