1、Zookeeper用于集群主備切換。

2、YARN讓集群具備更好的擴展性。

3、Spark沒有存儲能力。

4、Spark的Master負責集群的資源管理，Slave用于執行計算任務。

5、Hadoop從2.x開始，把存儲和計算分離開來，形成兩個相對獨立的子集群：HDFS和YARN，MapReduce依附于YARN來運行。

6、YARN可以為符合YARN編程接口需求的集群提供調度服務。

7、YARN：

ResourceManager 一主多備
NodeManager ? ?一般與DataNode部署在一起。

8、單機硬件配置會嚴重影響集群的性能。

9、初始化集群機器環境：創建賬號、安裝JDK、設置時間同步。

10、Zookeeper的部署最簡單，其節點數必為奇數。

11、ZK兩個端口，前者是鏈接Leader后者是用于競選。

12、部署Spark StandLone集群：

1、SSH無密碼登錄

2、復制解壓Spark

3、編寫配置文件分發到所有節點

13、Hadoop2.x以上支持雙機熱備。

14、Standlone模式只支持簡單的固定資源分配策略。

15、YARN統一為集群上的所有計算負載分配資源，可以避免資源分配的混亂無序。

16、Spark程序由Master還是YARN來調度執行，是由Spark程序在提交時決定的。

17、YARN兩種調度模式：

Yarn-cluster 模式，用于生產
Yarn-client ?模式，用于交互

18、Spark計算都是圍繞RDD進行的。

19、Spark在運行時，一般RDD操作會為每個RDD分區運行一個job。

20、Job最簡單的理解，它對應一個java線程。

21、Spark所有基于文件的生產RDD方法，都支持目錄、壓縮文件和通配符。

22、RDD是Spark的核心抽象，所有計算都圍繞RDD進行。

23、RDD操作分為兩類：

Transformation 轉換
Action ? ? ? ?動作

24、所有Transformation都是Lazy模式，先記錄計算方式，Driver返回結果時開始計算。

25、RDD的Transformation實際計算只在Action返回結果時才進行，或者持久化。

26、Spark嚴重依賴傳遞函數類型的參數。

27、從Driver分發各個節點過程：

Job執行：
1、在Driver節點上序列化代碼
2、傳送至各個計算節點
3、在計算節點上反序列化
4、執行

28、Scala function支持序列化。

29、Spark的核心是RDD，而RDD是分布式計算的。

30、Spark會將Job運行所有依賴的變量、方法、（閉包）全部打包在一起序列化。

31、RDD操作的禁忌，不能嵌套調用。

32、Action操作輸出不再是RDD，返回值Driver程序。

33、Spark集群上的資源主要是CPU core數量和物理內存。

34、在程序運行時，每個core對應一個線程。

35、Standlone模式下由Spark集群中的master節點進行資源調度。

36、Spark調度兩類：

1、spark程序見的調度（主）

2、spark程序內部的調度

37、用戶編寫的spark程序稱為Driver程序。

38、每個驅動程序都有一個SparkContext對象，擔負著與集群溝通的職責。

39、集群管理器負責集群的資源調度。

40、執行器，每個spark程序在每個節點上啟動的一個進程。

41、一次RDD Action對應一次job。

42、Stage，job在執行過程中被分為多個階段。

43、Task，在執行器上執行的最小單位。

44、Spark程序間的調度：

靜態分配 （主）
動態分配

45、所有集群管理器都支持靜態資源分配。

46、當spark為多用戶服務時，需要配置spark程序內部的調度。

47、不同線程提交的job可以并行執行。

48、默認spark的調度器以FIFO方式運行Job。

49、公平調度還支持對多個Job進行分組，分組稱為調度池。

50、Spark性能優勢，很大一部分原因是內存和緩存。

51、RDD持久化可以多次利用，性能提高10倍以上。

52、Spark提供兩類共享變量——廣播變量和計數器。

53、廣播變量是一個只讀變量，在所有節點上都是一份緩存。

54、計數器只能增加，用于技術和求和。

55、容錯機制是分布式系統的一個重要能力。

56、DAG：有向無環圖的計算任務集合。

57、分布式系統經常需要做檢查點。

58、RDD也是一個DAG，每一個RDD都會記住創建該數據需要哪些操作——血統。

59、RDD依賴：

窄依賴 —— 父分區對應一個子分區
寬依賴 —— 父分區對應多個子分區

60、Spark提供了預寫日志（journal），先將數據寫入支持容錯的文件系統中。

61、Spark master容錯：

Standalone ——Zookeeper
單點 ? ? ?——本地重啟

62、Slave節點失效：

1、Work異常停止
2、執行器異常停止
3、Driver異常退出

63、監控管理：

1、Web界面
2、Metrics
3、外部系統

64、Web界面：

1、調度器stage，Task列表
2、RDD大小和內存文件統計情況
3、環境信息
4、正在執行的執行器信息

65、Standlone模式的集群管理器有自己的web界面。

66、Web界面表格的頭部都支持點擊排序。

67、Spark程序一般都是由腳本bin/spark-submit來提交的。

68、RDD特點：

1、RDD是只讀的

2、RDD可指定緩存在內存中

3、RDD可以通過重新計算得到

69、RDD核心屬性：

1、一個分區列表

2、一個依賴列表

3、一個名為compute的計算函數

4、分區器

5、計算各分區是優先的位置列表

70、Action不可以在RDD Tranformation內部調用。

71、Transformation只是建立在計算關系，而action才是實際的執行者——觸發者

72、Spark.local.dir用于shuffle。

73、SparkContext是spark程序最主要的入口。

74、每個jvm只允許啟動一個sparkContext。

75、DAG是最高層級的調度，每個job對應一個DAG。

76、RunJob，提交RDD Action 操作，是所有調度執行的入口。

77、sparkContext在初始化時，創建了DAG調度與task調度來負責RDD Action操作的調度執行。

78、任務提交時，不是按Job的先后順序提交的，而是倒序的。

79、僅對依賴類型是shuffle Dependency的RDD操作創建Stage。

80、DAG在調度室，對于在相同節點上進行的Task計算會合并為一個Stage。

81、各stage之間以shuffle為分界線。

82、Spark SQL是spark的一個子模塊，專門用于處理結構化數據。

83、Spark SQL的最大優勢是性能非常高。

84、Spark SQL與Apache Hive基本完全兼容。

85、Spark SQL提供領域API，并且提供專門的數據結構抽象DataFrame。

86、Spark SQL支持非常多的數據源：Hive、Avro、Jdbc、Json等，而且統一訪問。

87、Spark SQL兩種使用：

1、SQL引擎

2、API 操作

88、分布式SQL引擎，兩種運行方式：

1、JDBC/ODBC Server

2、Spark SQL 命令行

89、Spark SQL相關的所有函數，都在SqlContext或它子類中。

90、DataFrame創建：

1、使用反射的方法從RDD創建DataFrame

2、使用程序動態從RDD創建DataFrame

3、從其他數據源生產DataFrame

91、DataFrame支持許多特殊的操作，稱為領域編程語言或領域API。

92、DataFrame注冊成表，然后使用純SQL來訪問。

93、Parquet是一種大數據計算中最常用的列式存儲格式。

94、數據源類型的名稱一般是全稱。

95、優化是非常重要的環節，需要不斷積累經驗。

96、Catalyst（催化劑）是Spark SQL執行有限優化器的代號，最核心部分。

97、Catalyst最主要的數據結構是樹。

98、所有優化都是基于規則的。

99、Catalyst優化：

1、分析階段

2、邏輯優化階段

3、物理優化階段

4、代碼優化階段

100、Spark的性能基本上與數量大小保持線性關系。

101、Spark Streaming接收實時數據，按日期將數據劃分為成多批次（Batch），按批次提交個核心計算。

102、Spark Streaming使用的數據抽象是DStream。

103、DStream內部是連續的RDD序列。

104、Sprak Streaming 3種輸入DStream：

1、基本型

2、高級型

3、自定義

105、高級類型的輸入DStream并不是由Spark提供。

106、使用數據源時，要注意可靠性。

107、DStream操作：

1、Transformation操作

2、Output操作類似RDD Action

108、Transform提供直接操作DStream內部RDD的方法。

109、Spark Streaming提供專門的狀態更新方法。

110、設置數據的滑動窗口，將數個原始DStream合并成一個窗口DStream。

111、窗口（Window）通過連個參數確定：1）窗口長度、2）滑動區間。

112、Output操作將DStream結果輸出到外部系統。

113、DStream可以序列化到內存。

114、窗口函數和updateStateBykey默認會自動持久化。

115、網絡按收數據，默認持久化兩個節點上，保證容錯。

116、DStream基礎屬性：

1、依賴的在DStream列表
2、生產RDD的時間
3、Complete計算函數

117、RDD是只讀的，可重復計算的分布式數據集。

118、SparkStreaming大部分數據來自網絡。

119、流式計算過程：

輸入數據流>>數據接收>>數據計算>>結果輸出。

120、結果輸出操作本身提供至少一次級別的容錯性能。

121、Spark提供了檢查點功能，用戶定期記錄中間狀態。

122、檢查點是有代價的，需要存儲數據至存儲系統。

123、Spark性能調優兩個方向:

1、每個批次的處理時間盡可能短

2、收到數據后，盡可能快地處理

124、Storm是開源免費的分布式實時計算系統。

125、Storm的核心數據抽象是tuple，是命名的值列表。

126、Spark Streaming粗粒度，storm更細粒度些。

127、核心數據抽象的不同導致計算模式上的本質卻別。

128、Weblog分析的典型的流式實時應用場景。

129、ZK以Fast Paxos算法為基礎。

130、ZK在分布式系統中協作多任務。

131、Hbase是一個通常與Hadoop一起使用的數據庫。

132、Kafka是一個基于發布-訂閱模型的消息系統。

133、Solr是一個企業級的搜索平臺。

134、ZK不適合用作海量數據存儲。

135、分布式系統中的進程通信有兩種選擇：直接通過網絡進行信息交換，或讀寫某些共享存儲。

136、ZK使用共享存儲模型來實現應用間的協作和同步原語。

137、網絡通信是分布式系統中并發設計的基礎。

138、分布式系統需注意：

1、消息延遲 ?——傳輸
2、處理器性能——計算
3、時鐘偏移 ?——時鐘

139、數據中心通常使用大量統一的硬件。

140、主-從架構：主節點負責跟蹤從節點狀態和任務的有效性，并分配任務到節點。

141、主-從模式必解決三個關鍵問題：

1、主節點崩潰
2、從節點崩潰
3、通信故障

142、ZK因故障出現連個及以上主節點稱為腦裂（split-brain）。

143、主-從架構的需求：

1、主節點選舉
2、崩潰檢測
3、組成員關系管理
4、元數據管理

144、ZK：Paxos算法和虛擬同步技術。

145、Znode Zookeeper 操作和維護一個小型的數據節點。

146、Znode類型決定了znode節點的行為方式。

147、Znode節點分持久節點和臨時節點。

148、Znode4中類型：

1、持久化（persist）
2、臨時的
3、持久有序的
4、臨時有序的

149、通知機制是單次觸發的操作。

150、每一個znode都有一個版本號，它隨著每次數據變化而自增。

151、ZK服務器端兩種模式：1）獨立模式、2）仲裁模式。

152、對ZK集合執行請求需要建立會話。

153、會話請求以FIFO順序執行。

154、會話狀態：

1、Connecting
2、Connected
3、Closed
4、Not connected

155、Server兩個端口，第一個用作通訊，第二個用于選舉。

156、ZK的API圍繞ZK的句柄（handle）而構建。

157、為了從ZK接收通知，我們需要實現監視點（watcher）。

158、監視點和通知形成了一個通用機制。

159、當一個監視點被一個事件觸發時，就會產生一個通知。

160、Redis是一個內存數據庫，基于鍵值對存儲。

161、Redis是REmoteDictionaryServer（遠程字典服務器）簡寫。

162、 Redis支持鍵值數據類型：

1、字符串類型
2、散列類型
3、列表類型
4、集合類型
5、有序集合類型

163、數據在Redis和程序中存儲類似。

164、Redis數據庫中的所有數據都存儲在內存中。

165、Redis可以在一秒中讀寫上十萬個鍵值（普通自己本）。

166、Redis提供數據持久化到硬盤。

167、Redis可用做緩存、隊列系統。

168、Redis可以為每個鍵設置生存時間，過時自動刪除。

169、Redis可以限定數據占用的最大內存空間。

170、Redis還支持“發布/訂閱”的消息模式。

171、Redis支持阻塞式讀取。

172、Kill Redis 進程的PID也可正常退出，Redis有處理。

173、每個數據類型Redis-cli的展現結果都不同。

174、Redis默認支持16個數據庫，以數字命令。

175、Redis不支持自定義數據庫的名字，每個數據庫以編號命名。

176、Redis密碼只有一個。

177、FLUSH ALL 命令清空Redis所有數據。

178、一個Redis最好對應一個程序。

179、Redis 0號數據庫用于生產，1號數據庫用于測試。

180、Select n 切換數據庫。

181、Keys命令需要遍歷Redis中的所有鍵，不建議生產用。

182、Exict key 返回 1/0。

183、Del key返回鍵值個數，不支持通配符。

184、Type命名用來獲取鍵值的數據類型。

185、LPOSH命令的作用是指定列表型鍵中增加一個元素。

186、Redis能存儲任何形式的字符串。

187、Redis INCR命令讓當前鍵值遞增。

188、原子操作取“原子”的“不可拆分”的意思，最下執行單元。

189、Redis數據類型不支持數據類型嵌套。

190、散列類型適合存儲：使用對象類別和ID構成鍵名，使用字段表示對象屬性。

191、Redis不要求每個鍵都依據此結構存儲。

192、Hset命令用來賦值，Hget用于取值。

193、Hset插入返回1，更新返回0。

194、Hset命令用于散列類型，set用于字符串類型。

195、Hmset處理多個字段。

196、HgetAll所有字段和字段值。

197、Hexists用于判斷一字段是否存在。

198、HsetNX key field value 當字段不存在時賦值。

199、Hinrby key field increment 增加數字。

200、Hdel key field 刪除字段。

201、列表類型（List）可以存儲一個有序的字符串列表。

202、列表類型內部是使用雙向鏈表實現的。

203、借助列表類型，Redis還可以作為隊列使用。

204、向列表兩端增加元素：

LPUSH?KEY?VALUE?[、、.] PPUSH?KEY?VALUE[、、.]返回長度

205、從列表兩端彈出元素：

LPOP?KEY RPOP?KEY

206、獲取列表中元素的個數 llen key。

207、獲取列表中指定值：LREM KEY count value。

208、Redis集合類型內部使用散列表實現的。

209、增加和刪除元素：

Sadd?key?member?[、、.]] Srem?key?member?[、、.]]

210、Smembers命令返回集合中所有元素。

211、集合間運算：

1、Sdiff key [key 、、.] ——差集
2、Sinter key [、、、] ?——交集
3、Sunion 、、、 ? ? ——并集

212、有序集合是Redis最高級的類型。

213、Redis中的事務是一組命令的集合。

214、事務：要么全執行，要么全不執行。

215、Redis不支持回滾功能。

216、Watch命令可以監控一個或多個鍵。

217、Redis可以用expire命令設置一個鍵的過期時間。

218、TTL命令查看剩余時間-2刪除，-1永久。

219、Persist取消過期。

220、Redis可限制最大內存。

221、LRU算法即“最近最少使用”。

222、有序集合常見的使用場景是大數據排序。

223、對有序集合類型排序是會忽略元素的分類。

224、Sort默認按照從下到大排序，用desc逆序。

225、Sort通過alpha參數實現按照字典，順序排序非數字元素。

226、Sort支持limit返回指定參數。

227、參考鍵值相同時，Redis會按照元素本身大小排序。

228、有個N個Get參數，每個元素返回的結果就有N行。

229、Get會返回元素本身的值。

230、Store參數常用來結合expire緩存排序結果。

231、Sort是Redis中最強大最復雜的命令之一。

232、通知的過程可以借助任務隊列來實現。

233、任務隊列好處：1）松耦合，2）易于擴展。

234、當列表中沒有元素BRPOP會一直阻塞住連接。

235、BRPOP命令按收兩個參數鍵名，超時時間，單位秒。

236、如果多個鍵都有元素則從左向右順序取實現優先。

237、發布者發布消息的命令是PUBLISH。

238、訂閱頻道的命令是SUBSCRIBE，可用的多個訂閱。

239、進入訂閱狀態后客戶端可能收到了3種類型的恢復。

240、PUSH SCRIBE命令訂閱指定的規則。

241、客戶端和Redis使用TCP協議連接。

242、Redis的底層通信協議對管道提供了支持。

243、精簡鍵名和鍵值是最直觀的減少內存暫用的方式。

244、允許開發者使用LUA語言編寫腳本傳到Redis中執行。

245、LUA腳本好處：1）減少網絡開銷、2）原子操作、3）復用。

246、——eval參數是告訴Redis-clli讀取并運行后面的LUA腳本。

247、LUA號稱性能最高的腳本。

248、LUA腳本很容易和C/C++交互。

249、LUA是一個動態類型語言。

250、表類型是LUA語言中唯一的數據結構。

251、函數在LUA中是一等值。

252、全局變量只有Nil和非Nil的區別。

253、在Redis腳本中不能使用全局變量。

254、聲明局部變量的方法為local變量。

255、多行注釋：——[[ ]]。

256、LUA支持多重賦值。

257、LUA有5類操作符：

1、數學操作符
2、比較操作符
3、邏輯操作符
4、鏈接操作符
5、取長度操作符

258、LUA if 語句 if .、then .、elseif ..then..else..end。

259、LUA支持while，repeat和for循環語句。

260、For語句中的循環變量是局部變量。

261、LUA約定數組的索引從1開始。

262、Paris是LUA內置的函數，實現類似迭代器的功能。

263、Pairs用來遍歷非數組的表。

264、函數的定義為：function(參數列表) 函數體 end。

265、…實現可變參數。

266、LUA中return和break用于跳出循環。

267、編寫Redis腳本的目的就是讀寫Redis的數據。

268、LUA腳本使用Redis，call函數調用Redis命令。

269、EVALHA命令允許開發者通過腳本。

270、Script kill命令可以終止當前腳本的運行。

271、Redis支持兩種方式的持久化，一種是RDB方式，另一種是AOF方式。

272、Redis提供了復制（replication）功能，自動同步數據庫。

273、在復制概念中，數據庫分為兩類：master/slave。

274、Slave of 參數指向主數據庫，進行同步數據。

275、通過復制可以實現讀寫分離，以提高服務器的負載能力。

276、Master用于寫，slave用于讀，適合讀多寫收的場景。

277、哨兵的作用就是監控Redis系統的運行狀態：

1、監控主/從是否正常
2、當出現故障時，從升為主

278、哨兵是一個獨立的進程。

279、哨兵從獨立進程的方式對一個主從系統進行監控。

280、Redis 3.0版本支持集群。

281、生產環境運行時不能運行外界直連Redis。

282、Bing 127.0.0.1只運行本機訪問。

283、Redis支持在配置文件中獎命令重命名。

284、如果希望直接禁用某個命令可以將命令重命名成XXX。

285、Redis通信協議是Redis客戶端與Redis間交流的語言。

286、Redis兩種通信協議：

1、二進制安全的統一請求協議
2、telnet程序中輸入的簡單協議

287、哨兵提供了命令可以通過主數據庫的名字獲取當前系統的主數據庫的地址和端口號。

288、一個哨兵可以同時監控多個Redis主從系統。

289、多個哨兵也可以同時監控同一個Redis主從系統。

290、MapReduce兩階段：Map階段和Reduce階段。

291、每個階段都以鍵值對作為輸入和輸出。

292、Map階段的輸入時NCDN原始數據。

293、鍵是相對穩健起始位置的偏移量。

294、Mapper類是一個泛型，四個參數：

1、輸入鍵
2、輸入值
3、輸出鍵
4、輸出值

295、Hadoop本身提供了一套可優化網絡序列化傳輸的基本類型：

LongWritable 相對于 Java 的Long
Text 相對于String
IntWritable相對于Integer

296、Map()方法提供了context實例用于輸出內容的寫入。

297、Job對象指定作業執行規范。

298、構造Job對象后，需要指定輸入和輸出數據的路徑。

299、在調試MapReduce作業時，知道作業ID和任務ID是非常有用的。

300、虛類相對接口更有利于擴展。

301、MapReduce作業（Job）是客戶端要執行的一個工作單元：它包括輸入數據，MapReduce程序和配置信息。

302、Hadoop將作業分成若干個小任務（Task）來執行，器中包括兩類任務：Map和Reduce。

303、作業（Job）由一個Jobtracker及一系列tasktracker控制執行過程。

304、Hadoop將MapReduce的輸入數據劃分成等長的小數據塊稱為“切片”。

305、Hadoop為每一個切片構建一個map任務。

306、切片越細，負載平衡越好。

307、HDFS的塊大小默認是64MB。

308、數據本地化優化——輸入數據在本地節點運行map。

309、數據通過網絡傳輸到map任務節點，效率明顯降低。

310、Map任務將其輸出寫入本地硬盤，而非HDFS，因為map的輸出是中間結果，Job完成自動刪除。

311、單個reduce任務的輸入通常來自于所有map的輸出。

312、每個reduce任務的輸入來自多個mao任務，所以中間過程稱為shuffle（混洗）。

313、Shuffle對總執行時間的影響非常大。

314、集群上的可用帶寬限制了MapReduce作業的數量。

315、Hadoop允許用戶針對map任務的輸出指定一個combiner。

316、Combiner的規則制約值可用的函數類型。

317、Combiner是通過Reducer類來定義的。

318、Hadoop Streaming 使用Unix標準流作為Hadoop和應用程序之間的接口。

319、Streaming天生適合用于文件處理。

320、HDFS以流式數據訪問模式來存儲超大文件。

321、一次寫入，多次讀取是高效的訪問模式。

322、HDFS中的文件可能只有一個writer。

323、HDFS的塊大，目的為最小化尋址開銷。

324、HDFS集群有兩類節點：管理者-工作者模式運行。

325、Namenode管理文件系統的命名空間。

326、客戶端代表用戶通過與namenode和datanode交互。

327、Datanode是文件系統的工作節點。

328、在聯邦環境下每個namenode維護一個命名空間卷。

329、HDFS的權限模式與POSIX非常相似。

330、用戶空間文件系統允許整合式一個Unix系統。

331、從Hadoop文件系統讀取文件，最簡單使用Java.net.url。

332、Filesystem是一個通用的文件系統API。

333、Seek()方法是一個相對高開銷的操作，需要慎重使用。

334、Filestatus封裝了文件系統中文件和目錄的元數據。

335、Hadoop通配符與Unix bach的相同。

336、Hadoop無法自行定義網絡拓撲結構。

337、文件系統的一致模型描述了文件讀/寫的數據可見性。

338、HDFS提供了一個方法來使所有緩存與數據節點強行同步。

339、HDFS中關閉文件其實還隱含執行syn（）方法。

340、Flume是一個將大規模數據導入HDFS的工具——典型應用從另外一個系統收集日志數據。

341、Flume提供了不同數據級別的數據投遞可靠性。

342、Sqoop是將數據從結構化存儲批量導入HDFS。——數據庫。

343、Distcp是作為一個MapReduce作業來實現的。

344、每個文件均按塊方式存儲，每個塊的元數據存儲在namenode的內存中。

345、Hadoop存儲小文件效率非常低。

346、Hadoop存檔文件可以使用MapReduce的輸入。

347、Hadoop自帶一套原子操作用于數據I/O操作。

348、HDFS會對寫入的存儲數據計算校驗和，并在讀取數據時驗證校驗和。

349、Datanode負責在收到數據后存儲該數據及其驗證校驗和。

350、客戶端成功驗證一個數據塊后，datanode更新日志。

351、Datanode定期驗證所有數據塊。

352、Hadoop的LocalFile Systen執行客戶端的校驗和驗證。

353、校驗的計算代價是相當低的。

354、LocalFileSystem通過checksumFileSystem來完成自己的任務。

355、文件壓縮兩大好處：存儲和傳輸。

356、序列化兩大領域常見：進程間通信和存儲。

357、Writable兩個方法：dataoutput/datainput。

358、RawComParator允許其實現直接比較數據流中的記錄。

359、Writable類對java基本類型提供封裝。

360、Text是針對URT-8序列的writable類。

361、Text類的find()方法返回字節偏移量。

362、多數情況下需要將Text對象換成String對象。

363、BytesWritable是對二進制數據數組的封裝。

364、NullWritable是writable的特殊類型，序列化長度為0.

365、Nulwritable不讀也不寫，只當占位符。

366、NullWritable可以用作在SequenceFile中的鍵。

367、ObjectWritable是對Java基本類型的一個通用封裝。

368、由于writable是MapReduce數據路徑的核心，所有調整二進制表示對性能產生顯著效果。

369、適當重寫一個類，會更加適應我們的需求。

370、IDL——接口定義語言。

371、Avro是一個獨立于編程語言的數據序列化系統。

372、Avro模式通常用于Json來寫，數據通常采用二進制格式來編碼。

373、Avro為序列化和反序列化提供了API。

374、Avro數據文件時可切分的，適合MapReduce快速處理。

375、Avro語言互相操作性。

376、Avro定義了對象的排列順序。

377、Hadoop配置后添加的資源文件屬性會覆蓋之前定義的屬性。

378、MRUnit是一個測試庫。

379、測試驅動程序：

1、使用本地作業運行器
2、使用一個mini集群來運行它

380、Mini集群廣泛應用于Hadoop自帶的自動測試包中。

381、Hadoop_CLASSPATH是一項客戶端的設置。

382、為了啟動作業，我們需要運行驅動程序。

383、Job上的waitforCompletion()方法啟動作業并檢查進展情況。

384、作業ID的格式包含兩部分：

1、Jobtracker開始時間
2、唯一標識增量計數器

385、任務屬于作業，任務ID通過替換作業ID的作業前綴為任務前綴，然后加上一個后綴表示哪個作業類的任務。

386、Hadoop的web界面用來瀏覽作業信息。

387、作業歷史包括已完成作業的時間和配置信息。

388、每個reducer產生一個輸出文件。

389、最經典的調試方法，打印語句來調試程序。

390、任務頁面包括一些看作業總任務細節的鏈接。

391、針對不同用戶，Hadoop在不同的地方生產日志。

392、Hadoop允許分析作業中的一部分任務。

393、Jobcontrol的實例表示一個作業的運行圖。

394、Ooize中，工作流是一個有動作節點和控制節點組成的DAG。

395、每個工作都必須有一個start節點和一個end節點。

396、Oozie提供了一組與工作流交互的函數。

397、工作流應用由工作流定義和所有運行所需的資源。

398、運行MapReduce作業：

1、Job對象上的submit（）
2、Waitforcompletion（）

399、客戶端，提交MapReduce作業。

400、Jobtracker，運行作業劃分后的任務。

401、Jobsummiter作業提交過程：

1、箱Jobtracker請求一個新的作業ID
2、檢查作業的輸出說明
3、計算作業的輸入分片
4、將運行作業所需的資源復制到Jobtracker文件系統中。
5、告知Jobtracker作業，準備執行。

402、心跳 向Jobtracker表明tasktracker是否還存活。

403、MapReduce 1 ：

1、作業的提交
2、作業的初始化
3、任務的分配
4、任務的執行
5、進度和狀態的更新
6、作業完成

404、YARN (Yet Another Resource Negotiator)。

405、YARN將Jobtracker的職能劃分為多個獨立的實體。

406、YARN將兩種角色劃分為兩個獨立的守護進程：

1、資源管理器
2、應用管理器

407、YARN設計的精妙之處在于不同的YARN應用可以在同一個集群共存。

408、MapReduce確保每個reducer的輸入都是按鍵排序的。

409、系統執行排序的過程稱為shuffle。

410、Shuffle屬于不斷被優化和改進的代碼的一部分。

411、Shuffle是MapReduce的“心臟”是奇跡發生的地方。

412、每個map任務都有一個環形內存緩沖區用于存儲任務的輸出。

413、Hadoop設置作業配置參數作為streaming程序的環境變量。

414、MapReduce模型將作業分解成任務，然而并行地運行任務。

415、Hadoop MapReduce 使用一個提交協議來確保作業和任務都完成功或失敗。

416、Hadoop在他們自己的Java虛擬機上運行任務，以區別其他正在運行的任務。

417、計數器是收集作業統計信息的有效手段之一。

418、Hadoop為每個作業維護若干內置計數器，以描述多項指標。

419、任務計數器由其任務維護，并定期發送給tasktracker再有tasktracker發送給Jobtracker。

420、作業計數器由Jobtracker維護。

421、計數器由一個java枚舉（enum）類型來定義。

422、計數器是全局的。

423、排序是MapReduce的核心技術。

424、MapReduce能夠執行大型數據集鍵的“鏈接”操作。

425、“邊數據”是作業所需的額外的只讀數據。

426、RAID —— 磁盤陣列

427、HDFS無需使用RAID的冗余機制。

428、Hadoop部分代碼需在Unix環境下執行。

429、Namenode和Jobtracker最好分別放在不同機器中。

430、Hadoop集群架構通常包含兩級網絡拓撲。

431、為了達到Hadoop的最佳性能，配置Hadoop系統以讓其了解網絡拓撲狀況舊極為關鍵。

432、HDFS和MapReduce可安裝同一系統的不同位置。

433、Hadoop控制腳本依賴SSH來執行針對整個集群的操作。

434、集群的每個Hadoop節點都各自保存一系列配置文件。

435、Hadoop也支持為所有master和worker機器采用同一套配置文件。

436、為每一機器類維護單獨的配置文件。

437、同步所有機器上的配置文件極具挑戰性。

438、Hadoop內置一些腳本來運行指令，在集群內啟動和終止守護進程。

439、MapReduce控制腳本不使用masters文件。

440、Namenode在內存中保存整個命名空間中的所有文件元數據和塊元數據。

441、Hadoop為各個守護進程分配1GB內存。

442、在一個tasktracker上能夠同時運行的任務數取決于一臺機器有多少個處理器。

443、Hadoop守護進程一般同時運行RPC和HTTP兩個服務器。

444、各個datanode運行TCP/IP服務器以支持塊傳輸。

445、YARN是運行MapReduce的下一代架構。

446、YARN有一個作業歷史服務器和一個web應用程序代理服務器。

447、YARN更加精細化管理內存。

448、YARN守護進程運行一個或多個RPC和HTTP服務。

449、Kerberos獲取服務：

1、認證
2、授權
3、服務請求

450、Hadoop使用委托令牌來支持后續認證訪問。

451、Whirr使用SSH與云端的機器通信。

452、Pig為大型數據集的處理提供了更高層的抽象。

453、Pig提供了一套更強大的數據變換操作。

454、Pig Latin程序由一系列的操作式變換組成。

455、Pig是一種探索大規模數據集的腳本語言。

456、MapReduce的一個缺點是開發周期太長。

457、Pig提供了多個命令來檢查和處理程序中已有的數據結構。

458、Pig被設計為可擴展的，處理路徑中幾乎每個部分都可以定制。

459、Pig是作為一個客戶端應用程序運行的。

460、Pig兩種模式：本地和MapReduce。

461、Grunt是與Pig進行交互的外殼程序（shell）。

462、在MapReduce模式下，Pig翻譯成MapReduce作業。

463、Pig發布版本只和特定的Hadoop版本對應。

464、三種執行Pig程序方法：

1、腳本
2、Grunt
3、嵌入式方法

465、創建一個精簡的數據集是一門藝術。

466、Pig Latin是一種數據流編程語言，而SQL是一種聲明式編程語言。

467、一個Pig Latin程序由一組語句構成。

468、Pig Latin并美歐正式的語言定義。

469、在Pig Latin程序執行時，每個命令按次序進行解析。

470、Hive是一個構建在Hadoop上的數據倉庫框架。

471、Hive一般在工作站上運行。

472、Hive把數據組織為表。

473、元數據（如表模式）存儲在metastore數據庫中。

474、Hive外殼環境是我們交互的主要方式。

475、HiveQL是Hive的查詢語言。

476、Hive操作表而Pig直接操作數據集。

477、HiveQL大小寫不敏感。

478、用-e選項在行嵌入命令，不用加分號。

479、在Hive的倉庫目錄中，表存儲為目錄。

480、Metastore包含兩部分：服務和后臺數據的存儲。

481、對于獨立的metastore，mysql是一種很受歡迎的選擇。

482、Hive把表組織成“分區”。

483、桶為表加上了額外的結構。

484、每個桶就是表（分式）目錄里的一個文件。

485、Hive從兩個維度對表的存儲進行管理：行格式和文件格式。

486、視圖是一種用select語句定義的“虛表”。

487、Hbase是一個在HDFS上開發的面向列的分布式數據庫。

488、數據模型：

1、應用把數據存放在帶標簽的表中
2、表中行的鍵也是字節數組
3、行中的列被分成“列族”
4、一個表的列族必須預先給出
5、所有列族成員都一起存放在文件系統中。

489、HBase自動把表水平分成“區域”，每個區域由表中行的子集構成。

490、HBase依賴于Zookeeper。

491、HBase通過Hadoop文件系統API來持久化存儲數據。

492、HBase有Java開發。

493、Hbase是一個分布式的，面向列的數據存儲系統。

494、HBase有一個高效的批量加載工具。

495、Sqoop將結構化存儲器抽取到Hadoop中。

496、Sqoop有java開發。

497、Hive不支持事務。

498、Hive是最適合數據倉庫應用程序的。

499、Hive和Mysql提供的SQL方言最接近。

500、Map操作會將集合中的元素從一種形式轉換成另一種形式。

501、MapReduce計算框架中的輸入和輸出的基本數據結構是鍵-值對。

502、Hadoop神奇的一部分在于sort和shuffle過程。

503、Hive驅動計算的“語言”是一XML形式編碼的。

504、Hive通過和Jobtracker通信來初始化MapReduce任務（Job）。

505、Metastore（元數據存儲）是一個獨立的關系型數據庫。

506、Pig常用于ETL（數據抽取、數據轉換、數據裝載）。

507、Hadoop團隊通常會將Hive和Pig結合使用。

508、Hive無法提供數據庫特性（如行級別更新，快速查詢響應和支持事務）。

509、HBase的設計靈感來自goole的bigTable。

510、HBase面向列存儲，列組成列族。

511、HBase對每個列保留多個版本。

512、HBase使用HDFS來持久化存儲數據。

513、將程序設計成驅動，比較方便移植。

514、HBase沒有提供SQL語言。

515、Hadoop面向批處理系統。

516、CLI是我們使用Hive的最常用方式。

517、Jobtracker管理著Job，而HDFS則由namenode管理。

518、元數據存儲中存儲了表的模式和分區信息等元數據。

519、Hive會將輸出寫到標準輸出中。

520、–e執行字符串包含的命令。

521、–s去掉ok。

522、–f執行文件。

523、如果查詢中的表名和這個例子并不相關，我們有時候會使用src。

524、用戶可以使用上下鍵來滾動查詢歷史命令。

525、用！執行bash shell命令。

526、Hive Cli 可執行Hadoop的dfs命令。

527、Hive本身提供了不同時區互相轉換的內置函數。

528、Hive中的列支持使用strct、map和arry集合數據類型。

529、Hive中并沒有鍵的概念。

530、Hive不會再數據加載時進行驗證，而是在查詢時進行。

531、Hive中數據庫的概念本質上僅僅是表的一個目錄式命名空間。

532、Hive會為每個數據接庫創建一個目錄。

533、數據庫的文件目錄名是以.db結尾。

534、Hive中并沒有嵌套數據庫的概念。

535、Hive不允許用戶刪除一個包含有表的數據庫。

536、Hive會自動增加兩個表屬性：last_modified_by|last_modified_time。

537、Hive總是將創建的表的目錄放置在這個所屬的數據庫目錄之后。

538、Show tables命令可以列舉出所有的表。

539、管理表（內布表）不方便和其他工作共享數據。

540、Exte Nal告訴Hive這個表示外部表。

541、Location 告訴Hive數據位于哪個路徑下。

542、因為表示外部的，所以Hive并非人為其完全擁有這份數據。

543、有些Hive QL并不使用外部表。

544、分區字段，表現得舊和普通的字段一樣。

545、對數據進行分區，也許最重要的原因是為了更快地查詢。

546、通過show partitions命令查看表中存在的所有分區。

547、Hive沒有行級操作。

548、Hive通常指定的路徑應該是一個目錄，而不是單獨的文件。

549、Hive要求源文件和目標文件以及目錄應該在同一個文件系統中。

550、指定overwrite關鍵字，目標文件之前存在的會被刪除。

551、Hive并不會驗證用戶裝載的數據和表的模式是否匹配。

552、Hive會驗證文件格式是否和表結構定義的一致。

553、INSERT語句允許用戶通過查詢語句向目標表中插入數據。

554、靜態分區鍵必須出現在動態分區鍵之前。

555、Hive中沒有臨時表的概念。

556、Select是sql中的射影算子。

557、可用正則來選舉我們想要的列。

558、Float和double相比較會出現問題。

559、RLike可用正則指定匹配條件。

560、Hive目前不支持on中的or。

561、視圖可以允許保存一個查詢并像對待表一樣對這查詢進行操作。

562、Hive值有有限的索引功能。

563、Bitmap索引普遍應用于排重后值較少的列。

564、Hive中分區的功能是非常有用的。

565、每個task都是一個新的Jvm實例，都需要開啟和銷毀的開銷。

566、分區提供一個隔離數據和優化查詢的便遍歷的方式。

567、分桶是將數據集分解或更容易管理的若干部分的另一種技術。

568、Hive提供了serde抽象，其用于從輸入中提取數據。

569、一個serDe通常是從左向右進行解析的。

570、Hive提供了一個列式SerDe來以混合列式格式存儲信息。

571、Hive中通常使用“UDF”來表示任意的函數（用戶自定義函數）。

572、Streaming提供了另一種處理數據的方式。

573、Hive中文件格式間具有明顯的差異。

574、Hive文本文件格式選擇和記錄格式是對應的。

575、SequenceFile可以在塊級別和記錄級別進行壓縮。

576、對于列式存儲而言，進行壓縮通常會非常高效。

577、Hive功能強大的一個方面體現在不同的存儲格式間轉換數據非常地簡單。

578、SerD是序列化/反序列化的簡寫形式。

579、Hive引擎使用定義的InputFormat來讀取一行數據記錄。

580、Thrift是一個軟件框架，其用于跨語言的服務開發。

581、HiveServer使用Thrift提供服務。

582、存儲處理程序是一個結合InputFormat、OutPutFormat、SerDe和Hive需要使用的特定的代碼。

583、存儲處理程序負責從底層存儲系統中讀取或寫入數據。

584、Hadoop起源于Apache Nutch的子項目。

585、HBase彌補了Hadoop只能離線批處理的不足。

586、HBase能夠存儲小文件，提供海量數據的隨機檢查。

587、大數據強調3v特征：即Volume（量級）、Varity（種類）和Velocity（速度）。

588、結構優化，質量提高，是一種實現實質性的跨越式的進程。

589、NoSQL是Not only SQL，泛指非關系型數據庫。

590、NoSQL的實現具有兩個特征：使用硬盤和把隨機存儲器作存儲載體。

591、NoSQL的Cache是記錄級的，是一種粗粒度的Cache。

592、NoSQL無須事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。

593、HBase是一個高可靠、高性能、面向列、可伸縮的分布式數據庫。

594、HBase是NoSQL數據庫。

595、HBase可以通過行健（RowKey）檢索數據，僅支持單行事務，主要用于存儲非結構化和半結構化的松散數據。

596、HBase的單表可以有百億行，百萬列。

597、HBase是面向列的存儲和權限控制，并支持列獨立檢索。

598、HBase嚴重依賴Hadoop的HDFS組件。

599、MapReduce可以直接訪問HBase。

600、HBase中最重要的訪問方式是原生Java API。

601、客戶端Client是整個HBase系統的入口。

602、HMaster主要負責Table和Region的管理工作。

603、HRegionServer主要負責響應用戶I/O請求。

604、HStore存儲是HBase存儲的核心。

605、HStore兩部分：Memstore和StoreFile。

606、當StoreFile文件增長到一定閥值，會觸發CompCut。

607、HBase的同一個表的記錄可以有不一樣的列。

608、HBase中最基本的單元是列。

609、每一個行的行健是唯一的。

610、HBase中的表有若干行，每行有很多列，列中的值有多個版本，每個版本的值稱為一個單元格，單元格存不同的列值。

611、HBase稱為無模式數據庫的原因是HBase的表沒有列定義，沒有類型。

612、創建連接是一項非常消耗資源的工作。

613、HBase為我們提供了一個連接池。

614、行鍵是按字段排序由低到高存儲在表中。

615、HBase中行鍵是唯一的索引。

616、HBase中的列族是一些列的集合。

617、一個列族中所有列成員有著相同的前綴。

618、一個列族的成員在文件系統上都是存儲在一起的。

619、在創建表的時候至少指定一個列族。

620、修改列族要先停用表。

621、HBase中的單元格由行鍵、列族、列、時間戳唯一確定。

622、單元格的內容是不可分別的字節數組。

623、每個單元格都保存著同一份數據的多個版本。

624、時間戳是64位的整數。

625、HBase對數據模型4個操作包括：Get、Put、Scan和Delete。

626、多用戶多線程對統一行的讀寫操作都不會影響該行數據的原子性。

627、Get方法獲取數據時，HBase返回的結果包含所有匹配的單元格數據。

628、Result實例中包含列族、列限定符和時間戳等。

629、Put操作要么向表增加新行，要么更新行。

630、Put操作每次都會發起一次到服務器的RPC操作。

631、HBase客戶端有一個緩沖區，大大提高寫入性能。

632、HBase提供compare-and-set先檢查，再執行。

633、HBase沒有update操作。

634、Scan操作允許多行特定屬性迭代。

635、HBase的Delete操作可以指定刪除某個列族或者某個列，或某時間更早的數據。

636、HBase的Delete操作并不是真正地從磁盤刪除數據。

637、RowKey、Column、Version組合在一起稱為HBase的一個單元格。

638、Version用一個長整型表示（時間）。

639、Get是在Scan的基礎上實現的。

640、一個put操作會為一個Cell創建一個版本，默認使用當前時間戳。

641、刪除操作的實現是創建一個墓碑標記。

642、Get和Scan操作返回的是經過排序的數據。

643、返回的數據首選按行字典序排序，其次是列族、然后是列修飾符，最后的時間戳逆序。

644、獲取列族的完整列名的唯一方法是處理所有行。

645、HBase不支持連接查詢，即Join查詢。

646、ICV（HBase計數器）操作發送在RegionServer上。

647、事務特性ACID，如HBase這種NoSQL數據庫僅提供對行級別的原子性。

648、HBase不是一個具備完整ACID特性的數據庫。

649、HBase中一個表的數據會被劃分成很多的Region。

650、剛剛穿件的表只有一個Region。

651、每一個Region由一個RegionServer管理。

652、每個Region包含起始RowKey的記錄，不包含結束RowKey的記錄。

653、Region的拆分與轉移是由HBase自動完成。

654、CAP原理是數據庫軟件的理論基礎。

655、HBase為了擴展性和性能考慮，弱化了事務性。

656、RowKey是不可分割的字節數，按字典排序由低到高存儲在表中。

657、RowKey決定了訪問HBase表時可以得到的性能。

658、Region基于Rowkey為一個區間的行提供服務。

659、Hfile在硬盤上存儲有序的行。

660、HBase只能在RowKey上建立索引。

661、RowKey優化：

1、字典排序
2、進行散列
3、盡量短

662、列族是一些列的集合。

663、一個列族的所有列成員有著相同的前綴。

664、列族的前綴必須是可輸出的字符。

665、列族必須在表建立的時候聲明，列在用戶隨時可以創建。

666、在物理上，一個列族的成員在文件系統上都存儲在一起。

667、Flush和Compaction操作式針對一個Region的。

668、考慮Flush性能，列族數量越少越好。

669、HFile數據塊大小可以在列族層次設置。

670、數據塊索引存儲每個HFile數據塊的起始鍵。

671、布隆過濾器（Bloom Filter）允許對存儲在每個數據塊的數據做一個反向測驗。

672、HFile可以被壓縮并存放在HDFS上。

673、HBase的每個單元格只維護三個時間版本。

674、CRUD操作式HTable最基本的功能，其中的每類方法都包含多種實現。

675、Java客戶端有兩種查詢數據的方式：單行讀和掃描讀。

676、每類操作的不同實現方法應用在不同的場景下。

677、HBaseAdmin類是HBase數據庫的管理入口類。

678、Scan類中的主要實現方法可以劃分成三類：

1、添加列或列族
2、設置查詢屬性
3、查看屬性信息

679、整個刪除過程分為三步：

1、初始化Table實例
2、構造實體類Delete，Delete封裝行鍵、列族或列名
3、執行刪除

680、HBase提供了若干封裝類用于“無縫”連接MapReduce。

681、從HBase表匯總讀取數據，使用MapReduce計算完成之后，將數據存儲到其他介質中。

682、NoSQL不使用SQL作為查詢語言。

683、創建外部表適用于某表HBase已經存在，但在Hive中沒有相關信息。

684、字符串類型是Redis中最基本的數據類型。

685、所有Redis命令都是原子操作。

686、Redis提供了4個命令可以直接對二進制位進行操作。

687、Redis是采用字典結構以鍵值對的形式存儲數據的。

688、一個散列類型鍵可以包含至多2的32次方減去1個字段。

689、散列類型適合存儲對象。

690、大數據所面對的問題是：一是存儲，二是計算。

691、大數據的定義是發現潛在規律和趨勢。

692、谷歌三大論文：1）GFS、2）MapReduce、3）BigTable。

693、Hadoop是一個批處理系統，不擅長實時計算。

694、YARN是通用的資源管理系統。

695、機器學習算法通常需要對同一個數據集合進行多次迭代計算。

696、RDD彈性分布式數據集（Resillient Distributed DataSet）。

697、Spark支持檢查點（checkpoint）的容錯機制。

698、RDD支持的方法：

1、轉換（Traansformation） ——生產新的RDD
2、動作（Action） ? ? ? ? ——返回一個非RDD

699、Spark沒有存儲能力，僅做數據倉庫。

700、MapReduce依附于Yarn來運行。

701、Zookeeper的節點必須是奇數個。

702、Standalone模式下，集群可以容許某一個或多個工作節點失效。

703、Hadoop：HDFS、MapReduce、YARN。

704、Spark可以單獨使用HDFS或YARN。

705、由YARN統一負載分配資源科避免分配混亂。

706、Spark程序由master還是YARN來調度執行，是由spark程序在提交時決定的。

707、只有在交互需求是才使用yarn-client方式。

708、切片，本地模式默認去CPU的核算。

709、每個Job的執行，都會經歷序列化，網絡傳輸，反序列化和運行的過程。

710、在序列化是，spark會將Job運行所依賴的變量、方法（稱為閉包）全部打包在一起。

711、如果RDD多次迭代，可將其持久化。

712、在Zookeeper模式下，恢復期間新任務無法提交。

713、RDD特點：1）只讀、2）可緩存、3）可以通過重新計算得到。

714、Kafk是一個分布式、分區、重復提交的日志服務。

715、Kafka掌管的類別消息叫做主題（topics）。

716、生產者發布消息到kafka主題中。

717、消費者訂閱主題以及處理發布的消息。

718、Kafka每個服務器叫做broker。

719、主題是一個類別或者被發布消息的名稱。

720、Kafka集群根據時間保留消息，而不是是否被消費。

721、消費者可以隨時添加和移除。

722、生產者發布數據到他們選定的主題上。

723、消費者、消息處理通常有兩種模式。：隊列和發布-訂閱。

724、在隊列模式中，一組消費者可能從服務器讀取消息，每個消息被其中一個消費者消費。

725、在發布-訂閱模式中：消費者是廣播到全部的消費者中。

726、消費者用一個消費組名稱來標識自己。

727、Kafka能夠提供順序保證并在一組消費者處理過程中均衡負載。

728、Kafka可以替換傳統的消息代理。

729、Kafka可以媲美傳統的消息系統例如：ActiveMQ和RabitMQ。

730、Kafka通常用于操作監測數據的處理。

731、Kafka作為日志聚合的一種解決方案。

732、Zookeeper典型應用場景：配置文件的管理，集群管理，分布式隊列，同步鎖leader選舉，隊列管理等。

733、Zookeeper是分布式服務框架。

734、dataMonitor類是本程序Zookeeper邏輯的核心。

735、Zookeeper是一個基于觀察者模式設計的分布式服務管理框架。

736、分布式應用中通常需要有一套完整的命名規則。

737、Netty高性能的NIO框架。

738、Netty快速開發高性能，高可靠性的網絡服務器和客戶端程序。

739、Netty是一個網絡通信框架。

740、NIO是一個面向塊的I/O系統。

741、NIO核心對象：緩沖區（Buffer），通道（Channel），選擇器（Selecter）。

742、在NIO庫中，所有數據都是用緩沖處理的。

743、Netty是事件驅動的。

744、Git是一個開源的分布式版本控制系統。

745、Kafka系統的角色：

1、Borker：一臺kafka服務器就是一個broker。
2、Topic：可以理解為一個MQ消息隊列的名字。

746、Java程序設計語言、虛擬機、API類庫統稱JDK。

747、Jdk是用于支持Java程序開發的最小環境。

748、JRE是支持Java程序運行的標準環境。

749、Java技術體系可分為4個平臺：Java Card、Me、Se、EE。

750、Hadoop每個切片構建一個map任務。

751、Map輸出是中間結果，reduce產出最終輸出結果。

752、集群上的帶寬限制了MapReduce的作業的數量。

753、HDFS中fsck指令可以顯示塊信息。

754、Namenode之間需要通過高可用的共享存儲實現編輯日志的共享。

755、Datanode需要同時向連個namenode發送數據塊處理報告。

756、超級用戶是namenode進程的標識。

757、Seek（）方法是一個相對高開銷的操作。

758、FileSystem是一個通用的文件系統Api。

759、HDFS只允許對一個打開的文件順序寫入，或者在現有文件的末尾追加數據。

760、FileStatus封裝了文件系統中問價和目錄的元數據。

761、過濾器有path表示，只能作用域文件名。

762、Hadoop無法自行第一網絡拓撲結構。

763、DFSoutputstream將寫入分成一個個的數據包，并寫入內部隊列，稱為“數據隊列”。

764、文件系統的一致模型描述了文件讀/寫的數據可見性。

765、HDFS為性能犧牲了一些Posix要求（可移植操作系統接口）。

766、HDFS提供一個方法來使所有緩存與數據節點強行同步。

767、Flume是一個將大規模流數據導入HDFS的工具。

768、Flume節點允許以任何拓撲方式進行組織。

769、當一個字段中包含多個類型時，ObjectWritable非常有用。

770、Avro是一個獨立于編程語言的數據序列化系統。

771、Avro模式通常用Json來寫，數據通常采用二進制格式來編碼。

772、Avro數據文件時可切分的，適合MapReduce快速處理。

773、SeQuenceFile是可以看做小文件的容器。

774、MapFile是已經排序過的SequenceFile，它有索引，所以可以按鍵查找。

775、Hadoop提供了鉤子（hook）來輔助分析過程。

776、Mini集群廣泛應用于Hadoop自帶的自動測試包中。

777、作業歷史包括已完成作業的時間和配置信息。

778、MapReduce任務日志可以從web界面訪問。

779、復雜的作業通常是增加更多的作業，而不是增加作業的復雜度。

780、Jobcontrol的實例表示一個作業的運行圖。

781、在Ooize中，工作流是一個由動作（action）節點和控制流節點組成的DAG。

782、Ooize提供了一組與工作流交互的函數。

783、TaskRunner啟動了一個新的Jvm里運行每個任務。

784、YARN將Jobtracker的職能劃分多個獨立的實體。

785、YARN集群上可以運行不同版本的MapReduce。

786、每個map任務都有一個環形內存緩存區用于存儲任務的輸出。

787、在本地作業運行器上運行時，只支持0個或1個reduce。

788、一個輸入切片（split）就是一個由單個map操作來處理的輸入塊。

789、切片并不包含數據本身，而是指向數據的引用。

790、Jobtracker使用其存儲位置信息來調度map任務從而在tasktracker上處理這些切片數據。

791、Reduce輸入的鍵一定是有序的。

792、Hadoop為每個作業維護若干內置計數器，以描述多項指標。

793、任務計數器由其關聯任務維護，并定期發送給tasktracker，再有tasktracker發送給Jobtracker。

794、“邊數據”是作業所需的額外的只讀數據。

795、Hadoop還為mapper和reduce提供了一個包含了常用函數的庫。

796、Hadoop使用dfs。Mapred，rpc和jvm四個上下文根。

797、FileContext將度量寫到一個本地文件中。

798、Ganglia是一個針對超大規模的開源的分布式監控系統。

799、Hadoop包括多個托管bean（MBean），可以將hadoop度量發布給支持JMX的應用。

800、Didtcp是一個理想的備份工具。

801、HDFS能夠容忍datanode故障，但這并不意味著允許隨意終止datanode。

802、Shell for（（i0;i<n；i++））。

803、Break n跳出幾層循環。

804、For I in {1 .、4}。

805、Unset 刪除一個元素。

806、Nohup 保持后臺允許。

807、>覆蓋，>>追加。

808、0、1、2標準輸入正確，錯誤輸出。

809、Ls >/de/null 深淵。

810、Linux默認無回收站。

811、–e執行轉義字符。

812、Fsimage：元數據鏡像文件。

813、目前HDFS不支持斷點續傳。

814、最后塊不足夠，則按實際打下存儲。

815、HAR是一個目錄結構。

816、Namenode兩種狀態：Active和standly。

817、Namenode同步數據通過Journanodes集群。

818、Namenode切換，自動和手工切換。

819、MapReduce是分布式并行計算模型，用于解決海量數據問題。

820、Hive操作流程：

1、提交SQL 交給驅動
2、驅動編譯解析相關字段
3、去metastore查詢相關信息
4、編譯返回信息，發給驅動
5、驅動發一個執行計劃
6、DDLS對數據庫表操作
7、吧Job交給Jobtracker讓tasktracker執行
8、完成Job返回數據信息，找namenode查數據
9、Dfs ops直接和namenode交互

821、Hive dfs ls 查看hadoop系統。

822、Hive無刪除語句，用replace實現。

823、Replace很危險，不建議使用。

824、Hive刪字段，大多數情況重建表。

825、桶表時對數據進行哈希取值，然后放到不同文件中存儲。

826、桶表應用于抽樣查詢，加載文件分文件存儲。

827、使用視圖可以降低查詢復雜度。

828、索引是對數記錄偏移量。

829、分區字段字段建索引。

830、建索引會引發MapReduce計算。

831、裝載數據：1）本地文件加載方式，2）查詢裝載。

832、動態分區加載方式。

833、Hive是讀模式。

834、RDBMS是寫模式。

835、Hive不支持對單行操作，只支持覆蓋和追加。

836、每個HStore對應了Table中的一個列族的存儲。

837、HStore是HBase存儲的核心：HFile、memstore。

838、HLog用于數據還原。

839、HFile是不定長的。

840、CSV是逗號分隔符的文件。

841、Hive分析HBase，只要表映射即可。

842、列族優化：

1、隨機查詢：數據塊越少，索引越大，占用內存也越大
2、順序查詢：更好的順序掃描需要更大的數據塊

843、布隆：有問題反饋，無問題不反饋。

844、HBase刪除數據時先標記合并刪除。

845、HBase熱點優化，創建分區。

846、Solr可以實現全文搜索。

847、Solr可以方便實現站內搜索功能。

848、Solr是通過http協議處理搜索和查詢請求。

849、Solr是一個索引庫。

850、線性的訪問磁盤，很多時候比隨機訪問內存塊。

851、Kafka將數據分段，為每個段建立索引。

852、索引分兩部分：offset和position。

853、Storm處理高頻數據和大規模數據。

854、Storm由用戶自定義處流程。

855、Stream ——一列火車。

856、Tuple ?——一節車廂。

857、數據 ?——乘客。

858、Bolt ? ——對tuple中數據進行處理 中間站。

859、Spout ?——源頭，相當于火車的始發站。

860、Toplogy ——軌道。

861、Storm 主-從結構。

862、主節點：nimbus，負責分發代碼，分配任務。

863、從節點：supervisor，負責產生worker，執行任務。

864、Storm集群的運行依賴于Zookeeper。

865、Executor是一個被worker進程啟動的單獨線程。

866、Task是最終運行spout或bolt中代碼的執行單元。

867、Slots就是work進程。

868、將數據按類型分組。

869、Storm流分組：1）隨機 負載均衡，2）字段 類型分組。

870、Work掛掉，storm會重新啟動一個進程，數據不會丟失。

871、Storm不支持HA（目前）。

872、每個work都有一個ack/fail確認機制。

873、Trident是對storm進行封裝的一個框架。

874、ES也是對Luncene的封裝，天生為分布式而生。

875、ES基于Restful接口。

876、Hadoop RPC調用是基于Probobuf實現的。

877、Client protocol定義了所有由客戶端發起的，由namenode響應的操作：

1、HDFS文件讀相關的操作
2、HDFS文件寫以及追加寫的相關操作
3、管理HDFS命名空間（namenode）的相關操作
4、系統問題與管理相關的操作
5、快照相關操作
6、緩存相關操作
7、其他

878、FileSystem：

1、HDFS文件讀操作
2、HDFS文件寫與追加操作
3、命名空間的管理操作

879、DFSAdmin：對系統問題管理相關操作。

880、處于安全模式（safemode）中的namenode不接受客戶端對命名空間的修改操作，只讀。

881、剛剛啟動的namenode直接自動進入安全模式。

882、必須在安全模式的兩個操作：

1、‘-savenamespace’用于將整個命名空間保存到新的fsimage文件中
2、‘-rolledits’則會觸發重置editlog文件

883、Refreshnodes()方法會觸發namenode刷新數據節點列表。

884、Findizeupgrade()和rollingupgrade()操作都是與namenode升級相關。

885、快照保存了一個實踐點上HDFS摸個路徑中所有數據的拷貝。

886、快照可以將失效的集群回滾到之前一個正常的時間點上。

887、創建快照之前，先開啟目錄的快照功能。

888、HDFS 2.3版本添加了集中式緩存管理功能：

1、Cache directive：表示要被緩存到內存的文件或目錄
2、Cache pool：用于管理一系列的cache directive類似于命名空間

889、Datanode使用DatanodeProtocol接口與namenode握手注冊，發送心跳進行全量以及增量的數據匯報。

890、DatanodeProtocol三種方法類型：

1、Datanode啟動相關
2、心跳相關
3、數據塊讀寫相關

891、Datnode啟動操作會與namenode進行四次交互：

1、與namenode握手
2、注冊上的datanode
3、匯報數據塊
4、緩存所有數據塊

892、分布式系統的節點之間大多采用心跳維護節點的健康狀態。

893、InterDatanodeProtocol（DN與DN之間接口），主要用于租約恢復操作。

894、客戶端打開一個文件進行寫操作是，首先獲取租約，并定期更新租約。

895、NamenodeProtocol定義了第二namenode與namenode之間的接口。

896、HDFS除了RPC調用還定義了流式接口（TCP/HTTP）。

897、Hadoop RPC不足以支持大文件讀寫。

898、HDFS客戶端讀取一個HDFS文件流程 ：

1、打開HDFS文件
2、從namenode獲取datanode地址
3、連接到datanode讀取數據塊
4、關閉輸入流

899、數據塊的應答包中不僅包含了數據，還包含了校驗值。

900、HDFS客戶端寫入一個HDFS文件的流程：

1、創建文件
2、建立數據流管道
3、通過數據流管道寫入數據
4、關閉輸入流并提交文件

901、HDFS追加文件流程：

1、打開已有的HDFS文件
2、建立數據流管道
3、通過數據流管道寫入數據
4、關閉輸入流并提交文件

902、對于命名空間的一致性，兩個namenode都需要與一組獨立運行的節點（Journalnode，JNS）通信。

903、ZKFailovercontroller負責維護HA。

904、RPC（Remote Procedure Call protocol），遠程過程調用協議。

905、Hadoop RPC框架底層采用Java NIO，Java動態代理以及protobuf等。

906、RPC框架：

1、通信模塊
2、客戶端stub程序
3、服務器端stub程序
4、請求程序
5、服務程序

907、客戶端的stub可以看作是一個代理對象。

908、Hadoop RPC 框架的使用抽象：

1、定義RPC協議
2、實現RPC協議
3、客戶端獲取代理對象
4、服務端啟動并構造RPC servers

909、Namenode：

1、文件系統目錄樹管理
2、數據塊以及數據節點管理
3、租約管理：namenode給予租約持有者在規定時間內擁有文件權限的合同
4、緩存管理
5、Fsnamesystem
Namenode的啟動和停止

910、HDFS文件系統的命名空間是以/為根的整個目錄樹，是通過FSDirectory類來管理的。

911、HDFS中文件與目錄都被當做系統目錄樹的一個INode節點。

912、HDFS會將命名空間保存到namenode的本地系統上一個叫fsimage的文件匯總。

913、FSDirectory維護者文件系統目錄樹的節點。

914、INode get方法：

1、Username
2、Groupnode
3、Fspermission
4、Allfeature：安全相關
5、Modification
6、Accesstime
7、Sattrfeature：擴展屬性

915、HDFS的檢查點機制會定時將editlog文件與fsimage文件合并以產生新的fsimage文件。

916、非HA，檢查點操作由secondary namenode來執行。

917、Namenode維護著HDFS中連個最重要的關系：

1、HDFS文件系統的目錄樹以及文件的數據塊索引
2、數據塊和數據節點的對應關系

918、當namenode發生錯誤并今夕了Active與standly切換時，多余的副本不能直接刪除，先匯報再從隊列中移除。

919、數據塊副本狀態：

1、正常副本
2、損壞副本
3、多余副本
4、等待刪除副本
5、等待刪除副本
6、等待復制副本
7、正在復制副本
8、推遲操作副本

920、數據副本的刪除情況：

1、數據塊所屬的HDFS文件被刪除
2、數據塊的副本數量多于配置表
3、副本被namenode標記損壞副本

921、在HDFS中，客戶端寫文件時需要先從租約管理器中申請一個租約。

922、Namenode啟動時會首先加載命名空間鏡像并合并編輯日志。

923、預防腦裂，HDFS提供三個級別的隔離機制：

1、共享存儲隔離
2、客戶端隔離
3、Datanode隔離

924、HA管理命令的執行是由HAAdmin為負責的。

925、Namenode三個類：

1、Namenode類
2、nameNode Rpcserver
3、FSNamesystem類

926、塊池：一個塊池由屬于同一個命名空間的所有數據塊組成。

927、命名空間卷：一個namenode管理的命名空間以及它對應的塊池一起被稱為命名空間卷。

928、每個塊池都是一個獨立的數據塊集合。

929、Datanode從邏輯上可切分幾個模塊：

1、數據層
2、邏輯層：向NN匯報，心跳，掃描損壞數據塊
3、服務器

930、Datanode升級需要考慮：

1、版本兼容性問題
2、升級消耗的硬盤空間問題
3、回滾要求

931、Datanode兩個管理功能：

1、管理與組織磁盤存儲目錄
2、管理與組織數據塊及其元數據文件

932、Storedirectory：

1、獲取文件夾相關
2、加鎖/解鎖
3、存儲狀態恢復

933、集中式緩存由分布在datanode上的對外內存組成，同時被namenode統一管理。

934、數據包：

1、數據包頭
2、校驗數據
3、實際數據

935、Java NIO零拷貝模式。

936、Datanode掃描器同期驗證datanode上存儲的數據塊正確性。

937、HDFS目前提供三個客戶端接口：

1、distributedFileSystem
2、FSShell
3、DFSAdmin

938、DFSClient是用戶使用HDFS各項功能的起點。

939、HDFS管理員通過DFSAdmin工具管理與配置HDFS。

940、HDFS目前實現的讀操作有三個層次：

1、網絡讀：socket
2、短路讀：同一節點
3、零拷貝讀：緩存轉換

941、Shuffle和sort階段負責執行兩個主要動作：

1、決定哪個reducer接收map輸出的鍵值對（切片）
2、并確定傳輸給reducer的鍵值對是進行排序的

942、MapReduce是基于批處理的框架，不適合實時訪問數據。

943、Hadoop配置文件：

1、Hadoop-env.sh ——設置環境變量
2、Core-site.xml ?——系統級的Hadoop配置項
3、Hdfs-site.xml ?——HDFS配置
4、Mapred-site.xml ——HDFS設置
5、Master ——Hadoop的master主機列表
6、Slaves ——Hadoop的slave主機地址列表

944、Flume四個組件：

1、Nodes ——flume數據路徑
2、Agents ——從本地主機上收集流數據
3、Collectors ——匯總來自代理的數據
4、Master——執行配置管理任務

945、Flume以Avro Json格式寫數據。

946、Agent數據接收器是Agent數據源的目的地。

947、Flume數據源：

1、Text ——處理一次的文本文件，每次處理一行
2、Tail ——為加入文件的每行生產一個事件
3、Multitail ——tail工具支持多文件處理
4、Syslogudp ——處理syslogUDP消息
5、syslogTcp ——處理sysLogTcp消息
6、execperiodic ——任意命令定期執行，整個輸出是一個事件
7、execstream ——執行任意指令，每行是一個獨立事件
8、exec ——定期執行任意指令并確定整個輸出的每行事件
9、scribe ——處理scrive collection 系統生產的數據

948、Collector數據接收器支持多種事件輸入格式：

1、Syslog ——輸出類似syslog格式的事件
2、Log4j ——輸出類似Hadoop log4j 格式的事件
3、avroJson——輸出進過Avro編碼的json格式的數據
4、avrodata ——輸出經過avro二進制編碼的數據
5、debug ——僅在調試時使用
6、raw——只輸出事件本身，不包含元數據

949、spark編程模型是彈性分布式數據集，他是MapReduce模型的擴展和延伸。

950、RDD記錄血統，而不是真正數據。

951、Spark四類操作：

1、創建操作：用于RDD創建工作
2、轉換操作：RDD變換成新的RDD
3、控制操作：RDD持久化
4、行為操作：能夠觸發spark運行的操作

952、調度器安裝DAG進行計算，并最終得到目標RDD。

953、RDD模型將計算分解為多個相互獨立的細粒度任務。

954、Spark中提供了通用接口來抽象每個RDD

1、分區信息：它們是數據集的最小分片
2、依賴關系：指向其父RDD
3、函數：基于RDD計算方法
4、劃分策略和數據位置的元數據

955、RDD操作中用戶可以使用Partition方法獲取RDD劃分的分區數。

956、Spark中RDD計算是以分區為單位的。

957、Spark默認連個劃分器：哈希分區和范圍分區。

958、Hadoop中的每一個HDFS數據塊都稱為一個RDD分區。

959、Map/mapPartitions作用每個元素，每個分區。

960、Checkpoint將切斷與該RDD之前的依賴關系。

961、Spark基本概念：

1、Application ——用戶編寫的spark應用程序
2、Driver ——application的main創建sparkContext
3、Cluster manager ——指在集群上獲取資源的外部服務
4、Standlone ——spark原生的資源管理
5、Hadoop YARN
6、Worl ——工作節點
7、Master ——總控進程
8、Executor ——執行進程

962、Spark定義了通信框架接口，這些接口實現中調用netty的具體方法。

963、Shuffle寫有基于哈希和排序兩種方式。

964、Clustermanager提供了資源的分配和管理。

965、資源分配和調度的基本單位是container。

966、在YARN中，每個application實例都有一個application master進程。

967、Application master是application啟動的第一個容器，它負責和resourceManager打交道并請求資源。

968、Spark SQL執行過程：

1、詞法和語法解析
2、綁定
3、優化4、執行

969、Spark 提供了兩種方式將RDD轉換成DataFrame：

1、通過定義 case class ，使用反射推斷schema
2、通過編程接口，定義schema，并應用到RDD上

970、YARN拆分Jobtracker的兩大職責：資源管理，作業調度/監控：

1、全局的resource Manager
2、每個應用對應的Application Master

971、Resource Manager擁有為系統中的所有應用的資源分配的決定權。

972、Container為應用程序授予在特定主機上使用資源全權利。

973、YARN三種調度器：

1、FIFO調度器
2、Capacity調度器
3、Fair調度器

974、Storm一個work進程執行的是一個topplpgy的子集。

975、Executor是一個被work進程啟動的單獨線程。

976、Work之間通信是通過Netty進行通信的。

977、Stream grouping：

1、Shuffle ——隨機分組
2、Fields ——按字段分組
3、All ——廣播發送
4、Non ——隨機分配
5、Diret ——直接分組

978、Task是運行spout或bolt中的線程。

979、Strom的核心：

1、主節點 ——Nimbus
2、工作節點——supervisor
3、協調器——Zookeeper
4、工作進程——worker
5、任務線程——task

980、Storm三大應用：

1、信息流處理
2、持續計算
3、分布式遠程調用

981、提交一個Topology之后，storm創建spout/bolt實例big進行序列化。

982、流是一個分布式并行創建和處理的無界的連續元組。

983、Storm數據傳輸利用的是zmq開源的消息傳遞框架。

984、Topology是由stream grouping鏈接起來的spout和bolt節點網絡。

985、Tupe可以理解成鍵值對，即Fields和values。

986、Tuple的asked，faild都由spout發出并維護的。

987、本地模式：storm用一個進程紅的線程模擬所有spout/bolt。

988、Nimbus和supervisor之間的通信依賴Zookeeper完成。

989、用戶畫像是一個實際用戶的虛擬代表，如年齡，性別等。

990、在機器學習中，對象是指含有一組特征的行變量。

991、行變量的集合最容易構造的結構就是表。

992、Hadoop有三種令牌：

1、委托令牌
2、塊訪問令牌
3、作業令牌

993、對事物運動這種不確定性（隨機性）的度量就是概率論。

994、大數據4V：

1、Volume ——數據體量大
2、Variety ——數據類型繁多
3、Velocity ——處理速度快
4、Value ? ——商業價值高

995、移動互聯網產生了和客戶緊密擁綁的大數據。

996、在互聯網這個產業鏈中，誰掌握了用戶，誰的天下。

997、消費者的注意力和使用習慣去了哪里，錢就會流向哪里。

998、體驗的產生是一個藝術的過程。

999、大數據的目標是定位。

1000、建立一個學習型企業架構。

總結

以上是生活随笔為你收集整理的大数据学习笔记1000条的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。