Hadoop學習資料整理收集----阿冬專欄
hadoop安裝成功後,對hadoop的很多概念還是一知半解,通過線上文件及《hadoop權威指南》可以有個初步的瞭解。
1. hadoop解決了什麼問題?
對大量的資料進行儲存與分析。
方案:hdfs進行儲存,而mapreduce進行分析,輔以其他的功能。
設計中需要考慮的問題:
大資料的讀寫問題,磁碟的IO的能力限制,促成了並行處理方式。
硬體故障的可能性,也需要多個硬體的備份,需要保證可靠性。
資料傳輸,也需要保證可靠性。
並形成即時查詢或處理ad hoc的能力。
2. 與關係資料庫的比較
關係型資料庫: 善於處理結構化資料;其一般使用B樹的結構,利於小部分資料的更新,或持續性的更新,但對大量資料更新時,效率比mapreduce低,原因:“排序/合併”來重建資料庫;利於點查詢,提供低延遲的索引和少量資料的更新。
mapreduce:善於處理半結構化、非結構化資料,大量資料分析,強調資料的大量獲取能力及批處理的方式分析整個資料集,而不是低延遲的資料訪問。一次寫入,多次查詢的特徵(簡單連續的模型)。橫向線性擴充套件的方式
關係型資料庫一次性無法讀入PB級的資料時,源於磁碟速度的限制:
磁碟的定址能力,取決於硬體磁頭對磁碟的定位能力;
傳輸的速率,取決於磁碟的頻寬。
並且定址能力的發展,是遠遠慢於傳輸速率。
結構化資料:擁有既定格式的實體資料
半結構化資料:類似表格,但每個表格可以有自己的格式
非結構化資料:文字或影象
關係資料庫,更利於處理結構化資料,完整,且無冗餘
mapreduce,更利於處理半結構化和非結構化資料
3. map/reduce相關術語
鍵/值對:一般鍵是 偏移量,而值是文字。
CLASS_PATH: 環境變數:新增的應用程式的路徑。
map函式:map任務的實現
reduce函式:reduce任務的實現
main函式:程式入口
jobtracker:排程tasktracker上執行的任務,來協調所有執行在系統上的作業。
tasktracker:執行任務的同時,將執行的結果和狀態傳送給jobtracker
分片input split:將資料劃分為等長的資料塊,然後每個分片構建一個map任務
資料本地化優化:在hdfs的本地節點的資料上執行map任務,可以獲取最優效能
分割槽partition:多個reduce任務,每個reduce任務需建立一個分割槽
混洗shuffle:map與reduce任務之間的資料流相互混雜,多對多的關係
combiner 合併函式:其輸出作為reduce的輸入, 節省頻寬,減少輸出的資料量
4. 一次寫入,多次讀取的含義?
每個磁碟或機器從資料來源複製資料到本地,即一次寫入,然後,長時間地,只須分析時讀取本地資料,即多次讀取。
5. HDFS不適用的場景是什麼?
1)低延遲的場景
HDFS具有很高的資料吞吐量的效能,代價是可能有較高的時間延遲。
而當要求,只有幾十毫秒的延遲時,HBase表現會更好些。
2)大量的小檔案
hdfs適用較大的資料塊。當有大量小檔案時,如過億的小檔案,namenode的管理能力就不夠了。
3)多使用者寫入,任意修改檔案
當有多個使用者進行修改檔案時,或者任意修改檔案時,容易造成衝突,而比較低效。
6. 普通NFS與HDFS各自的特點有哪些?
1. 優點:透明性, 程式設計方便、容易,只須open,close,fread一些庫的操作。
2. 缺點:無資料冗餘性,所有資料在一臺機器上,資料複製時,可能有頻寬限制。
HDFS就是為克服NFS的缺點,進行設計。 儲存可靠,讀取方便,且與mapreduce整合到一起。可伸縮性強。高度可配置(一堆的配置檔案)。支援web介面: http://namenode-name:50070/ 流量檔案系統。支援shell介面操作。
資料塊: 預設64MB。有哪些優點?最小化定址開銷,簡化系統設計
namenode: 管理者
datanode:工作者
client: 與namenode、datanode相互動。對使用者而言,隱藏namenode、datanode的運作。
namenode的容錯機制有哪些? 永久寫入磁碟,或映象namenode(輔助的namenode)
HDFS 架構
命令列介面如何運作的?
HDFS守護程序 根據“fs.default.name” (hdfs URI) 來確定 namenode的主機及埠,這樣client端就能得知namenode在哪裡執行,並連結到它
shell介面操作:
詳細介紹:http://hadoop.apache.org/docs/r1.0.4/file_system_shell.html
舉例
hadoop fs -command parameterlist
command:
-ls
-copyFromLocal
-mkdir
r, w, x三種許可權。
Hadoop檔案系統的分類:
File, hdfs, hftp, hsftp, har, hfs(雲端儲存), ftp s3, s3
--------------
7. checkpoint node
從namenode上週期性備份namespace的checkpoint: fsimage, 和edit(checkpoint之後的log)。
其介面由 dfs.backup.address 和 dfs.backup.http.address 來配置。
另外,可以配置備份週期和資料塊大小:
fs.checkpoint.period, set to 1 hour by default
fs.checkpoint.size,
set to 64MB by default,edit log的最大值,當達到這個時,即使period時間未定,仍需checkpoint備份
checkpoint node的checkpoint路徑一直是與 namenode的checkpoint路徑相同。
8. Backup node
與checkpoint node相同的功能,只不過,無需下載fsimage和edit。因為其記憶體的內容與namenode相同(同步)。
匯入checkpoint有專門的命令,流程。
9. 負載平衡器rebalancer
http://hadoop.apache.org/docs/r1.0.4/commands_manual.html#balancer
--------------
hdfs提供了一系列的介面來支援以下功能:
資料的讀取、寫入、查詢、刪除、存檔,並保證一致性
如何保持hadoop的叢集的均衡?
利用均衡器balancer來改善叢集中塊的均勻分佈程度。
10. Hadoop I / O
資料完整性: 資料校驗和 checksum,採用CRC-32,即4個位元組,開銷低於1%。datanode在複製時,檢測資料的完整性。並具備修復能力,即從新複製資料。
壓縮:減少檔案儲存空間,加速資料在網路和磁碟上的傳輸。壓縮的工具有bzip2 gzip LZO ,bzip2在空間上有優勢,而LZO在時間上有優勢,gzip居中
空間 bzip2 gzip LZO 時間
序列化: 將結構化物件轉換為 位元組流,便於網路傳輸或磁碟永久儲存。
反序列化:將位元組流轉換為 結構化物件的逆過程。
RPC: remote procedure call 遠端過程呼叫,hadoop上多節點間的通訊方式。採用序列化和反序列化的方式進行。
11. avro
是一個獨立於程式語言的資料序列化系統。avro.apache.org中有詳盡的描述。旨在解決hadoop中語言可移植性的缺乏。
avro有豐富的資料模式解析data schema resolution.
HDFS是什麼?
HADOOP DISTRIBUTED FILE SYSTEM,簡稱HDFS,是一個分散式檔案系統。它是谷歌的GFS提出之後出現的另外一種檔案系統。它有一定高度的容錯性,而且提供了高吞吐量的資料訪問,非常適合大規模資料集上的應用。HDFS 提供了一個高度容錯性和高吞吐量的海量資料儲存解決方案。
在最初,HADOOP是作為Apache Nutch搜尋引擎專案的基礎架構而開發的,後來由於它獨有的特性,讓它成為HADOOP CORE專案的一部分。
HDFS的設計思路?
是什麼提供它高吞吐量的資料訪問和適合大規模資料集的應用的特性呢,這就要說一下它的設計思路。
首先HDFS的設計之初就是針對超大檔案的儲存的,小檔案不會提高訪問和儲存速度,反而會降低;其次它採用了最高效的訪問模式,也就是經常所說的流式資料訪問,特點就是一次寫入多次讀取;再有就是它執行在普通的硬體之上的,即使硬體故障,也就通過容錯來保證資料的高可用。
HDFS的一些概念:
Block:大檔案的儲存會被分割為多個block進行儲存。預設為64MB,每一個blok會在多個datanode上儲存多份副本,預設為3份。[這些設定都能夠通過配置檔案進行更改]
Namenode:主要負責儲存一些metadata資訊,主要包括檔案目錄、block和檔案對應關係,以及block和datanote的對應關係
Datanode:負責儲存資料,上面我們所說的高度的容錯性大部分在datanode上實現的[還有一部分容錯性是體現在namenode和secondname,還有jobtracker的容錯等]。
HDFS的基礎架構圖:
解析HDFS帶來的好處:
高吞吐量訪問:HDFS的每個block分佈在不同的rack上,在使用者訪問時,HDFS會計算使用最近和訪問量最小的伺服器給使用者提供。由於block在不同的rack上都有備份,所以不再是單資料訪問,所以速度和效率是非常快的。另外HDFS可以並行從伺服器叢集中讀寫,增加了檔案讀寫的訪問頻寬。
高容錯性:上面簡單的介紹了一下高度容錯。系統故障是不可避免的,如何做到故障之後的資料恢復和容錯處理是至關重要的。HDFS通過多方面保證資料的可靠性,多分複製並且分佈到物理位置的不同伺服器上,資料校驗功能、後臺的連續自檢資料一致性功能,都為高容錯提供了可能。
容量擴充:因為HDFS的block資訊存放到namenode上,檔案的block分佈到datanode上,當擴充的時候,僅僅新增datanode數量,系統可以在不停止服務的情況下做擴充,不需要人工干預。
引申閱讀:
雖然SQL資料庫是非常有用的工具,但經歷了15年的一支獨秀之後壟斷即將被打破。這只是時間問題:被迫使用關係資料庫,但最終發現不能適應需求的情況不勝列舉。
但是NoSQL資料庫之間的不同,遠超過兩 SQL資料庫之間的差別。這意味著軟體架構師更應該在專案開始時就選擇好一個適合的 NoSQL資料庫。針對這種情況,這裡對 Cassandra、 Mongodb、CouchDB、Redis、Riak、 Membase、Neo4j和HBase進行了比較:
(編注1:NoSQL:是一項全新的資料庫革命性運動,NoSQL的擁護者們提倡運用非關係型的資料儲存。現今的計算機體系結構在資料儲存方面要求具 備龐大的水平擴 展性,而NoSQL致力於改變這一現狀。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型資料庫。 參見NoSQL詞條。)
1. CouchDB
- 所用語言: Erlang
- 特點:DB一致性,易於使用
- 使用許可: Apache
- 協議: HTTP/REST
- 雙向資料複製,
- 持續進行或臨時處理,
- 處理時帶衝突檢查,
- 因此,採用的是master-master複製(見編注2)
- MVCC – 寫操作不阻塞讀操作
- 可儲存檔案之前的版本
- Crash-only(可靠的)設計
- 需要不時地進行資料壓縮
- 檢視:嵌入式 對映/減少
- 格式化檢視:列表顯示
- 支援進行伺服器端文件驗證
- 支援認證
- 根據變化實時更新
- 支援附件處理
- 因此, CouchApps(獨立的 js應用程式)
- 需要 jQuery程式庫
最佳應用場景:適用於資料變化較少,執行預定義查詢,進行資料統計的應用程式。適用於需要提供資料版本支援的應用程式。
例如: CRM、CMS系統。 master-master複製對於多站點部署是非常有用的。
(編注2:master-master複製:是一種資料庫同步方法,允許資料在一組計算機之間共享資料,並且可以通過小組中任意成員在組內進行資料更新。)
2. Redis
- 所用語言:C/C++
- 特點:執行異常快
- 使用許可: BSD
- 協議:類 Telnet
- 有硬碟儲存支援的記憶體資料庫,
- 但自2.0版本以後可以將資料交換到硬碟(注意, 2.4以後版本不支援該特性!)
- Master-slave複製(見編注3)
- 雖然採用簡單資料或以鍵值索引的雜湊表,但也支援複雜操作,例如 ZREVRANGEBYSCORE。
- INCR & co (適合計算極限值或統計資料)
- 支援 sets(同時也支援 union/diff/inter)
- 支援列表(同時也支援佇列;阻塞式 pop操作)
- 支援雜湊表(帶有多個域的物件)
- 支援排序 sets(高得分表,適用於範圍查詢)
- Redis支援事務
- 支援將資料設定成過期資料(類似快速緩衝區設計)
- Pub/Sub允許使用者實現訊息機制
最佳應用場景:適用於資料變化快且資料庫大小可遇見(適合記憶體容量)的應用程式。
例如:股票價格、資料分析、實時資料蒐集、實時通訊。
(編注3:Master-slave複製:如果同一時刻只有一臺伺服器處理所有的複製請求,這被稱為 Master-slave複製,通常應用在需要提供高可用性的伺服器叢集。)
3. MongoDB
- 所用語言:C++
- 特點:保留了SQL一些友好的特性(查詢,索引)。
- 使用許可: AGPL(發起者: Apache)
- 協議: Custom, binary( BSON)
- Master/slave複製(支援自動錯誤恢復,使用 sets 複製)
- 內建分片機制
- 支援 javascript表示式查詢
- 可在伺服器端執行任意的 javascript函式
- update-in-place支援比CouchDB更好
- 在資料儲存時採用記憶體到檔案對映
- 對效能的關注超過對功能的要求
- 建議最好開啟日誌功能(引數 –journal)
- 在32位作業系統上,資料庫大小限制在約2.5Gb
- 空資料庫大約佔 192Mb
- 採用 GridFS儲存大資料或元資料(不是真正的檔案系統)
最佳應用場景:適用於需要動態查詢支援;需要使用索引而不是 map/reduce功能;需要對大資料庫有效能要求;需要使用 CouchDB但因為資料改變太頻繁而佔滿記憶體的應用程式。
例如:你本打算採用 MySQL或 PostgreSQL,但因為它們本身自帶的預定義欄讓你望而卻步。
4. Riak
- 所用語言:Erlang和C,以及一些Javascript
- 特點:具備容錯能力
- 使用許可: Apache
- 協議: HTTP/REST或者 custom binary
- 可調節的分發及複製(N, R, W)
- 用 JavaScript or Erlang在操作前或操作後進行驗證和安全支援。
- 使用JavaScript或Erlang進行 Map/reduce
- 連線及連線遍歷:可作為圖形資料庫使用
- 索引:輸入元資料進行搜尋(1.0版本即將支援)
- 大資料物件支援( Luwak)
- 提供“開源”和“企業”兩個版本
- 全文字搜尋,索引,通過 Riak搜尋伺服器查詢( beta版)
- 支援Masterless多站點複製及商業許可的 SNMP監控
最佳應用場景:適用於想使用類似 Cassandra(類似Dynamo)資料庫但無法處理 bloat及複雜性的情況。適用於你打算做多站點複製,但又需要對單個站點的擴充套件性,可用性及出錯處理有要求的情況。
例如:銷售資料蒐集,工廠控制系統;對宕機時間有嚴格要求;可以作為易於更新的 web伺服器使用。
5. Membase
- 所用語言: Erlang和C
- 特點:相容 Memcache,但同時兼具持久化和支援叢集
- 使用許可: Apache 2.0
- 協議:分散式快取及擴充套件
- 非常快速(200k+/秒),通過鍵值索引資料
- 可持久化儲存到硬碟
- 所有節點都是唯一的( master-master複製)
- 在記憶體中同樣支援類似分散式快取的快取單元
- 寫資料時通過去除重複資料來減少 IO
- 提供非常好的叢集管理 web介面
- 更新軟體時軟無需停止資料庫服務
- 支援連線池和多路複用的連線代理
最佳應用場景:適用於需要低延遲資料訪問,高併發支援以及高可用性的應用程式
例如:低延遲資料訪問比如以廣告為目標的應用,高併發的 web 應用比如網路遊戲(例如 Zynga)
6. Neo4j
- 所用語言: Java
- 特點:基於關係的圖形資料庫
- 使用許可: GPL,其中一些特性使用 AGPL/商業許可
- 協議: HTTP/REST(或嵌入在 Java中)
- 可獨立使用或嵌入到 Java應用程式
- 圖形的節點和邊都可以帶有元資料
- 很好的自帶web管理功能
- 使用多種演算法支援路徑搜尋
- 使用鍵值和關係進行索引
- 為讀操作進行優化
- 支援事務(用 Java api)
- 使用 Gremlin圖形遍歷語言
- 支援 Groovy指令碼
- 支援線上備份,高階監控及高可靠性支援使用 AGPL/商業許可
最佳應用場景:適用於圖形一類資料。這是 Neo4j與其他nosql資料庫的最顯著區別
例如:社會關係,公共交通網路,地圖及網路拓譜
7. Cassandra
- 所用語言: Java
- 特點:對大型表格和 Dynamo支援得最好
- 使用許可: Apache
- 協議: Custom, binary (節約型)
- 可調節的分發及複製(N, R, W)
- 支援以某個範圍的鍵值通過列查詢
- 類似大表格的功能:列,某個特性的列集合
- 寫操作比讀操作更快
- 基於 Apache分散式平臺儘可能地 Map/reduce
- 我承認對 Cassandra有偏見,一部分是因為它本身的臃腫和複雜性,也因為 Java的問題(配置,出現異常,等等)
最佳應用場景:當使用寫操作多過讀操作(記錄日誌)如果每個系統組建都必須用 Java編寫(沒有人因為選用 Apache的軟體被解僱)
例如:銀行業,金融業(雖然對於金融交易不是必須的,但這些產業對資料庫的要求會比它們更大)寫比讀更快,所以一個自然的特性就是實時資料分析
8. HBase
(配合 ghshephard使用)
- 所用語言: Java
- 特點:支援數十億行X上百萬列
- 使用許可: Apache
- 協議:HTTP/REST (支援 Thrift,見編注4)
- 在 BigTable之後建模
- 採用分散式架構 Map/reduce
- 對實時查詢進行優化
- 高效能 Thrift閘道器
- 通過在server端掃描及過濾實現對查詢操作預判
- 支援 XML, Protobuf, 和binary的HTTP
- Cascading, hive, and pig source and sink modules
- 基於 Jruby( JIRB)的shell
- 對配置改變和較小的升級都會重新回滾
- 不會出現單點故障
- 堪比MySQL的隨機訪問效能
最佳應用場景:適用於偏好BigTable:)並且需要對大資料進行隨機、實時訪問的場合。
例如: Facebook訊息資料庫(更多通用的用例即將出現)
編注4:Thrift 是一種介面定義語言,為多種其他語言提供定義和建立服務,由Facebook開發並開源。
當然,所有的系統都不只具有上面列出的這些特性。這裡我僅僅根據自己的觀點列出一些我認為的重要特性。與此同時,技術進步是飛速的,所以上述的內容肯定需要不斷更新。我會盡我所能地更新這個列表。