正文

簡述hadoop工作原理（hadoop工作原理圖）

發(fā)布時間：2023-04-21 21:44:59 稿源：創(chuàng)意嶺閱讀： 53

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于簡述hadoop工作原理的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準，寫出的就越詳細，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、hadoop是分布式文件系統(tǒng)嗎
2、Hadoop到底是什么玩意
3、白話解釋hadoop是做什么的
4、Hadoop讀寫文件時內(nèi)部工作機制是怎樣的

簡述hadoop工作原理（hadoop工作原理圖）

一、hadoop是分布式文件系統(tǒng)嗎

是的

Hadoop分布式文件系統(tǒng)(HDFS)是一種被設(shè)計成適合運行在通用硬件上的分布式文件系統(tǒng)。HDFS是一個高度容錯性的系統(tǒng)，適合部署在廉價的機器上。它能提供高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。要理解HDFS的內(nèi)部工作原理，首先要理解什么是分布式文件系統(tǒng)。

1.分布式文件系統(tǒng)

多臺計算機聯(lián)網(wǎng)協(xié)同工作(有時也稱為一個集群)就像單臺系統(tǒng)一樣解決某種問題，這樣的系統(tǒng)我們稱之為分布式系統(tǒng)。

分布式文件系統(tǒng)是分布式系統(tǒng)的一個子集，它們解決的問題就是數(shù)據(jù)存儲。換句話說，它們是橫跨在多臺計算機上的存儲系統(tǒng)。存儲在分布式文件系統(tǒng)上的數(shù)據(jù)自動分布在不同的節(jié)點上。

分布式文件系統(tǒng)在大數(shù)據(jù)時代有著廣泛的應(yīng)用前景，它們?yōu)榇鎯吞幚韥碜跃W(wǎng)絡(luò)和其它地方的超大規(guī)模數(shù)據(jù)提供所需的擴展能力。

2.分離元數(shù)據(jù)和數(shù)據(jù)：NameNode和DataNode

存儲到文件系統(tǒng)中的每個文件都有相關(guān)聯(lián)的元數(shù)據(jù)。元數(shù)據(jù)包括了文件名、i節(jié)點(inode)數(shù)、數(shù)據(jù)塊位置等，而數(shù)據(jù)則是文件的實際內(nèi)容。

在傳統(tǒng)的文件系統(tǒng)里，因為文件系統(tǒng)不會跨越多臺機器，元數(shù)據(jù)和數(shù)據(jù)存儲在同一臺機器上。

為了構(gòu)建一個分布式文件系統(tǒng)，讓客戶端在這種系統(tǒng)中使用簡單，并且不需要知道其他客戶端的活動，那么元數(shù)據(jù)需要在客戶端以外維護。HDFS的設(shè)計理念是拿出一臺或多臺機器來保存元數(shù)據(jù)，并讓剩下的機器來保存文件的內(nèi)容。

NameNode和DataNode是HDFS的兩個主要組件。其中，元數(shù)據(jù)存儲在NameNode上，而數(shù)據(jù)存儲在DataNode的集群上。NameNode不僅要管理存儲在HDFS上內(nèi)容的元數(shù)據(jù)，而且要記錄一些事情，比如哪些節(jié)點是集群的一部分，某個文件有幾份副本等。它還要決定當集群的節(jié)點宕機或者數(shù)據(jù)副本丟失的時候系統(tǒng)需要做什么。

存儲在HDFS上的每份數(shù)據(jù)片有多份副本(replica)保存在不同的服務(wù)器上。在本質(zhì)上，NameNode是HDFS的Master(主服務(wù)器)，DataNode是Slave(從服務(wù)器)。

二、Hadoop到底是什么玩意

Hadoop到底是個啥？

答：Hadoop是基于廉價設(shè)備利用集群的威力對海量數(shù)據(jù)進行安全存儲和高效計算的分布式存儲和分析框架，Hadoop本身是一個龐大的項目家族，其核心家族或者底層是HDFS和MapReduce，HDFS和MapReduce分別用來實現(xiàn)對海量數(shù)據(jù)的存儲和分析，其它的項目，例如Hive、HBase 等都是基于HDFS和MapReduce，是為了解決特定類型的大數(shù)據(jù)處理問題而提出的子項目，使用Hive、HBase等子項目可以在更高的抽象的基礎(chǔ)上更簡單的編寫分布式大數(shù)據(jù)處理程序。Hadoop的其它子項目還包括Common, Avro, Pig, ZooKeeper, Sqoop, Oozie 等，隨著時間的推移一些新的子項目會被加入進來，一些關(guān)注度不高的項目會被移除Hadoop家族，所以Hadoop是一個充滿活力的系統(tǒng)。

Apache Hadoop: 是Apache開源組織的一個分布式計算開源框架，提供了一個分布式文件系統(tǒng)子項目(HDFS)和支持MapReduce分布式計算的軟件架構(gòu)。

Apache Hive: 是基于Hadoop的一個數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，通過類SQL語句快速實現(xiàn)簡單的MapReduce統(tǒng)計，不必開發(fā)專門的MapReduce應(yīng)用，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。

ApachePig: 是一個基于Hadoop的大規(guī)模數(shù)據(jù)分析工具，它提供的SQL-LIKE語言叫Pig Latin，該語言的編譯器會把類SQL的數(shù)據(jù)分析請求轉(zhuǎn)換為一系列經(jīng)過優(yōu)化處理的MapReduce運算。

ApacheHBase: 是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術(shù)可在廉價PC Server上搭建起大規(guī)模結(jié)構(gòu)化存儲集群。

Apache Sqoop: 是一個用來將Hadoop和關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)相互轉(zhuǎn)移的工具，可以將一個關(guān)系型數(shù)據(jù)庫（MySQL ,Oracle ,Postgres等）中的數(shù)據(jù)導(dǎo)進到Hadoop的HDFS中，也可以將HDFS的數(shù)據(jù)導(dǎo)進到關(guān)系型數(shù)據(jù)庫中。

Apache Zookeeper: 是一個為分布式應(yīng)用所設(shè)計的分布的、開源的協(xié)調(diào)服務(wù)，它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，簡化分布式應(yīng)用協(xié)調(diào)及其管理的難度，提供高性能的分布式服務(wù) ApacheMahout:是基于Hadoop的機器學(xué)習和數(shù)據(jù)挖掘的一個分布式框架。Mahout用MapReduce實現(xiàn)了部分數(shù)據(jù)挖掘算法，解決了并行挖掘的問題。

ApacheCassandra:是一套開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)。它最初由Facebook開發(fā)，用于儲存簡單格式數(shù)據(jù)，集Google BigTable的數(shù)據(jù)模型與AmazonDynamo的完全分布式的架構(gòu)于一身 Apache Avro: 是一個數(shù)據(jù)序列化系統(tǒng)，設(shè)計用于支持數(shù)據(jù)密集型，大批量數(shù)據(jù)交換的應(yīng)用。Avro是新的數(shù)據(jù)序列化格式與傳輸工具，將逐步取代Hadoop原有的IPC機制 ApacheAmbari: 是一種基于Web的工具，支持Hadoop集群的供應(yīng)、管理和監(jiān)控。

ApacheChukwa: 是一個開源的用于監(jiān)控大型分布式系統(tǒng)的數(shù)據(jù)收集系統(tǒng)，它可以將各種各樣類型的數(shù)據(jù)收集成適合 Hadoop 處理的文件保存在 HDFS 中供Hadoop 進行各種 MapReduce 操作。

ApacheHama: 是一個基于HDFS的BSP（Bulk Synchronous Parallel)并行計算框架, Hama可用于包括圖、矩陣和網(wǎng)絡(luò)算法在內(nèi)的大規(guī)模、大數(shù)據(jù)計算。

ApacheFlume: 是一個分布的、可靠的、高可用的海量日志聚合的系統(tǒng)，可用于日志數(shù)據(jù)收集，日志數(shù)據(jù)處理，日志數(shù)據(jù)傳輸。

ApacheGiraph: 是一個可伸縮的分布式迭代圖處理系統(tǒng)，基于Hadoop平臺，靈感來自 BSP (bulk synchronous parallel) 和Google 的 Pregel。

ApacheOozie: 是一個工作流引擎服務(wù)器, 用于管理和協(xié)調(diào)運行在Hadoop平臺上（HDFS、Pig和MapReduce）的任務(wù)。

ApacheCrunch: 是基于Google的FlumeJava庫編寫的Java庫，用于創(chuàng)建MapReduce程序。與Hive，Pig類似，Crunch提供了用于實現(xiàn)如連接數(shù)據(jù)、執(zhí)行聚合和排序記錄等常見任務(wù)的模式庫 ApacheWhirr: 是一套運行于云服務(wù)的類庫（包括Hadoop），可提供高度的互補性。Whirr學(xué)支持Amazon EC2和Rackspace的服務(wù)。

ApacheBigtop: 是一個對Hadoop及其周邊生態(tài)進行打包，分發(fā)和測試的工具。

ApacheHCatalog: 是基于Hadoop的數(shù)據(jù)表和存儲管理，實現(xiàn)中央的元數(shù)據(jù)和模式管理，跨越Hadoop和RDBMS，利用Pig和Hive提供關(guān)系視圖。

ClouderaHue: 是一個基于WEB的監(jiān)控和管理系統(tǒng)，實現(xiàn)對HDFS，MapReduce/YARN, HBase, Hive, Pig的web化操作和管理。

三、白話解釋hadoop是做什么的

白話解釋hadoop是做什么的

hadoop通常跟大資料幾個字聯(lián)絡(luò)在一起，他是apache下面的一個頂級專案，咱們解釋一下什么是大資料，大資料是相對于小資料、傳統(tǒng)資料來說的，大資料要解決的是大規(guī)模資料儲存、大規(guī)模資料計算、大規(guī)模資料處理工具的一個東東，而hadoop生態(tài)系統(tǒng)就有這樣的功能，也是目前比較火的一個東東

求解釋，白金會是做什么的啊

岱宗夫如何？齊魯青未了。

代理是做什么的？專業(yè)一點的解釋是做什么的？

代理這么籠統(tǒng)的詞，是問法律名詞還是問實際產(chǎn)品運作？回答就多了，只能舉例說下：比如常州鴻爾太陽能招代理商，分一級代理和二級代理，區(qū)域代理；還有不同的產(chǎn)品代理，比如太陽能熱水器地區(qū)代理與太陽能熱水工程的合作代理。各公司的營銷模式不一樣，總體上就是你作為某個產(chǎn)品的某個區(qū)域的代理商，負責按照公司的營銷思路運營，自負盈虧。但你的一些與產(chǎn)品品牌有關(guān)的行為代表著公司及形象。

he prove to be a man with a strong will. will是做什么的？怎么解釋？

堅強的意志。意志的意思。

誰解釋下 LOOKIT 商標含義，是做什么的?

那些噴的華為的 *** ，注冊了商標而已，就在這里噴，華為mate 注冊了幾百個商標了。出不出手機還兩說。

Arch Linux是做什么的？求大神解釋啊~~

一個linux核心的作業(yè)系統(tǒng)

跟windows差不多的一個東西，裝什么軟體就能做什么事情，但是系統(tǒng)本身只是一個平臺，什么都不干

IT專員是做什么的？解釋一下

IT即電子營銷。IT人員是從事相關(guān)工作的開發(fā)，設(shè)計，銷售的專業(yè)人員專業(yè)的定義很廣，依企業(yè)給的許可權(quán)來設(shè)定一般從事銷售工作都會掛一個專員的頭銜，即可以單獨處理客戶訂單的指定營銷人員。謝謝采納！

用英文解釋secretary(秘書）是做什么的

is a person whose work consists of supporting management, including executives, using a variety of project management, munication & anizational skills.

求解釋！律伴平臺是做什么的嗎？

是一個公益性的法律平臺，上面有各地區(qū)的律師，有什么不懂的法律問題，可以去免費咨詢。

試客聯(lián)盟是做什么的呢？求解釋

是全球企業(yè)在中國首選的體驗營銷網(wǎng)站。試客聯(lián)盟是基于新一代網(wǎng)際網(wǎng)路技術(shù)應(yīng)用平臺和專業(yè)的精準營銷網(wǎng)站，專注于體驗時代新營銷模式的運營和開拓，是一家專業(yè)以試用為媒介而進行的網(wǎng)路精準營銷和口碑營銷的專業(yè)入口網(wǎng)站。

四、Hadoop讀寫文件時內(nèi)部工作機制是怎樣的

客戶端通過調(diào)用FileSystem對象（對應(yīng)于HDFS文件系統(tǒng)，調(diào)用DistributedFileSystem對象）的open()方法來打開文件（也即圖中的第一步），DistributedFileSystem通過RPC（Remote Procedure Call）調(diào)用詢問NameNode來得到此文件最開始幾個block的文件位置（第二步）。對每一個block來說，namenode返回擁有此block備份的所有namenode的地址信息（按集群的拓撲網(wǎng)絡(luò)中與客戶端距離的遠近排序，關(guān)于在Hadoop集群中如何進行網(wǎng)絡(luò)拓撲請看下面介紹）。如果客戶端本身就是一個datanode（如客戶端是一個mapreduce任務(wù)）并且此datanode本身就有所需文件block的話，客戶端便從本地讀取文件。

以上步驟完成后，DistributedFileSystem會返回一個FSDataInputStream（支持文件seek），客戶端可以從FSDataInputStream中讀取數(shù)據(jù)。FSDataInputStream包裝了一個DFSInputSteam類，用來處理namenode和datanode的I/O操作。

客戶端然后執(zhí)行read()方法（第三步），DFSInputStream（已經(jīng)存儲了欲讀取文件的開始幾個block的位置信息）連接到第一個datanode（也即最近的datanode）來獲取數(shù)據(jù)。通過重復(fù)調(diào)用read()方法（第四、第五步），文件內(nèi)的數(shù)據(jù)就被流式的送到了客戶端。當讀到該block的末尾時，DFSInputStream就會關(guān)閉指向該block的流，轉(zhuǎn)而找到下一個block的位置信息然后重復(fù)調(diào)用read()方法繼續(xù)對該block的流式讀取。這些過程對于用戶來說都是透明的，在用戶看來這就是不間斷的流式讀取整個文件。

當真?zhèn)€文件讀取完畢時，客戶端調(diào)用FSDataInputSteam中的close（）方法關(guān)閉文件輸入流（第六步）。

如果在讀某個block是DFSInputStream檢測到錯誤，DFSInputSteam就會連接下一個datanode以獲取此block的其他備份，同時他會記錄下以前檢測到的壞掉的datanode以免以后再無用的重復(fù)讀取該datanode。DFSInputSteam也會檢查從datanode讀取來的數(shù)據(jù)的校驗和，如果發(fā)現(xiàn)有數(shù)據(jù)損壞，它會把壞掉的block報告給namenode同時重新讀取其他datanode上的其他block備份。

這種設(shè)計模式的一個好處是，文件讀取是遍布這個集群的datanode的，namenode只是提供文件block的位置信息，這些信息所需的帶寬是很少的，這樣便有效的避免了單點瓶頸問題從而可以更大的擴充集群的規(guī)模。

Hadoop中的網(wǎng)絡(luò)拓撲

在Hadoop集群中如何衡量兩個節(jié)點的遠近呢？要知道，在高速處理數(shù)據(jù)時，數(shù)據(jù)處理速率的唯一限制因素就是數(shù)據(jù)在不同節(jié)點間的傳輸速度：這是由帶寬的可怕匱乏引起的。所以我們把帶寬作為衡量兩個節(jié)點距離大小的標準。

但是計算兩個節(jié)點之間的帶寬是比較復(fù)雜的，而且它需要在一個靜態(tài)的集群下才能衡量，但Hadoop集群一般是隨著數(shù)據(jù)處理的規(guī)模動態(tài)變化的（且兩兩節(jié)點直接相連的連接數(shù)是節(jié)點數(shù)的平方）。于是Hadoop使用了一個簡單的方法來衡量距離，它把集群內(nèi)的網(wǎng)絡(luò)表示成一個樹結(jié)構(gòu)，兩個節(jié)點之間的距離就是他們離共同祖先節(jié)點的距離之和。樹一般按數(shù)據(jù)中心(datacenter)，機架(rack)，計算節(jié)點(datanode)的結(jié)構(gòu)組織。計算節(jié)點上的本地運算速度最快，跨數(shù)據(jù)中心的計算速度最慢（現(xiàn)在跨數(shù)據(jù)中心的Hadoop集群用的還很少，一般都是在一個數(shù)據(jù)中心內(nèi)做運算的）。

假如有個計算節(jié)點n1處在數(shù)據(jù)中心c1的機架r1上，它可以表示為/c1/r1/n1，下面是不同情況下兩個節(jié)點的距離：

• distance(/d1/r1/n1, /d1/r1/n1) = 0 (processes on the same node)

• distance(/d1/r1/n1, /d1/r1/n2) = 2 (different nodes on the same rack)

• distance(/d1/r1/n1, /d1/r2/n3) = 4 (nodes on different racks in the same data center)

• distance(/d1/r1/n1, /d2/r3/n4) = 6 (nodes in different data centers)

如下圖所示：

Hadoop

寫文件

現(xiàn)在我們來看一下Hadoop中的寫文件機制解析，通過寫文件機制我們可以更好的了解一下Hadoop中的一致性模型。

Hadoop

上圖為我們展示了一個創(chuàng)建一個新文件并向其中寫數(shù)據(jù)的例子。

首先客戶端通過DistributedFileSystem上的create()方法指明一個欲創(chuàng)建的文件的文件名（第一步），DistributedFileSystem再通過RPC調(diào)用向NameNode申請創(chuàng)建一個新文件（第二步，這時該文件還沒有分配相應(yīng)的block）。namenode檢查是否有同名文件存在以及用戶是否有相應(yīng)的創(chuàng)建權(quán)限，如果檢查通過，namenode會為該文件創(chuàng)建一個新的記錄，否則的話文件創(chuàng)建失敗，客戶端得到一個IOException異常。DistributedFileSystem返回一個FSDataOutputStream以供客戶端寫入數(shù)據(jù)，與FSDataInputStream類似，F(xiàn)SDataOutputStream封裝了一個DFSOutputStream用于處理namenode與datanode之間的通信。

當客戶端開始寫數(shù)據(jù)時（第三步），DFSOutputStream把寫入的數(shù)據(jù)分成包（packet）, 放入一個中間隊列——數(shù)據(jù)隊列（data queue）中去。DataStreamer從數(shù)據(jù)隊列中取數(shù)據(jù)，同時向namenode申請一個新的block來存放它已經(jīng)取得的數(shù)據(jù)。namenode選擇一系列合適的datanode（個數(shù)由文件的replica數(shù)決定）構(gòu)成一個管道線（pipeline），這里我們假設(shè)replica為3，所以管道線中就有三個datanode。DataSteamer把數(shù)據(jù)流式的寫入到管道線中的第一個datanode中（第四步），第一個datanode再把接收到的數(shù)據(jù)轉(zhuǎn)到第二個datanode中（第四步），以此類推。

DFSOutputStream同時也維護著另一個中間隊列——確認隊列（ack queue），確認隊列中的包只有在得到管道線中所有的datanode的確認以后才會被移出確認隊列（第五步）。

如果某個datanode在寫數(shù)據(jù)的時候當?shù)袅耍旅孢@些對用戶透明的步驟會被執(zhí)行：

1）管道線關(guān)閉，所有確認隊列上的數(shù)據(jù)會被挪到數(shù)據(jù)隊列的首部重新發(fā)送，這樣可以確保管道線中當?shù)舻膁atanode下流的datanode不會因為當?shù)舻膁atanode而丟失數(shù)據(jù)包。

2）在還在正常運行的datanode上的當前block上做一個標志，這樣當當?shù)舻膁atanode重新啟動以后namenode就會知道該datanode上哪個block是剛才當機時殘留下的局部損壞block，從而可以把它刪掉。

3）已經(jīng)當?shù)舻膁atanode從管道線中被移除，未寫完的block的其他數(shù)據(jù)繼續(xù)被寫入到其他兩個還在正常運行的datanode中去，namenode知道這個block還處在under-replicated狀態(tài)（也即備份數(shù)不足的狀態(tài)）下，然后他會安排一個新的replica從而達到要求的備份數(shù)，后續(xù)的block寫入方法同前面正常時候一樣。

有可能管道線中的多個datanode當?shù)簦m然不太經(jīng)常發(fā)生），但只要dfs.replication.min（默認為1）個replica被創(chuàng)建，我們就認為該創(chuàng)建成功了。剩余的replica會在以后異步創(chuàng)建以達到指定的replica數(shù)。

當客戶端完成寫數(shù)據(jù)后，它會調(diào)用close()方法（第六步）。這個操作會沖洗（flush）所有剩下的package到pipeline中，等待這些package確認成功，然后通知namenode寫入文件成功（第七步）。這時候namenode就知道該文件由哪些block組成（因為DataStreamer向namenode請求分配新block，namenode當然會知道它分配過哪些blcok給給定文件），它會等待最少的replica數(shù)被創(chuàng)建，然后成功返回。

replica是如何分布的

Hadoop在創(chuàng)建新文件時是如何選擇block的位置的呢，綜合來說，要考慮以下因素：帶寬（包括寫帶寬和讀帶寬）和數(shù)據(jù)安全性。如果我們把三個備份全部放在一個datanode上，雖然可以避免了寫帶寬的消耗，但幾乎沒有提供數(shù)據(jù)冗余帶來的安全性，因為如果這個datanode當機，那么這個文件的所有數(shù)據(jù)就全部丟失了。另一個極端情況是，如果把三個冗余備份全部放在不同的機架，甚至數(shù)據(jù)中心里面，雖然這樣數(shù)據(jù)會安全，但寫數(shù)據(jù)會消耗很多的帶寬。Hadoop 0.17.0給我們提供了一個默認replica分配策略（Hadoop 1.X以后允許replica策略是可插拔的，也就是你可以自己制定自己需要的replica分配策略）。replica的默認分配策略是把第一個備份放在與客戶端相同的datanode上（如果客戶端在集群外運行，就隨機選取一個datanode來存放第一個replica），第二個replica放在與第一個replica不同機架的一個隨機datanode上，第三個replica放在與第二個replica相同機架的隨機datanode上。如果replica數(shù)大于三，則隨后的replica在集群中隨機存放，Hadoop會盡量避免過多的replica存放在同一個機架上。選取replica的放置位置后，管道線的網(wǎng)絡(luò)拓撲結(jié)構(gòu)如下所示：

Hadoop

總體來說，上述默認的replica分配策略給了我們很好的可用性（blocks放置在兩個rack上，較為安全），寫帶寬優(yōu)化（寫數(shù)據(jù)只需要跨越一個rack），讀帶寬優(yōu)化（你可以從兩個機架中選擇較近的一個讀?。?。

一致性模型

HDFS某些地方為了性能可能會不符合POSIX（是的，你沒有看錯，POSIX不僅僅只適用于linux/unix， Hadoop 使用了POSIX的設(shè)計來實現(xiàn)對文件系統(tǒng)文件流的讀取），所以它看起來可能與你所期望的不同，要注意。

創(chuàng)建了一個文件以后，它是可以在命名空間（namespace）中可以看到的：

Path p = new Path("p");

fs.create(p);

assertThat(fs.exists(p), is(true));

但是任何向此文件中寫入的數(shù)據(jù)并不能保證是可見的，即使你flush了已經(jīng)寫入的數(shù)據(jù)，此文件的長度可能仍然為零：

Path p = new Path("p");

OutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.flush();

assertThat(fs.getFileStatus(p).getLen(), is(0L));

這是因為，在Hadoop中，只有滿一個block數(shù)據(jù)量的數(shù)據(jù)被寫入文件后，此文件中的內(nèi)容才是可見的（即這些數(shù)據(jù)會被寫入到硬盤中去），所以當前正在寫的block中的內(nèi)容總是不可見的。

Hadoop提供了一種強制使buffer中的內(nèi)容沖洗到datanode的方法，那就是FSDataOutputStream的sync()方法。調(diào)用了sync()方法后，Hadoop保證所有已經(jīng)被寫入的數(shù)據(jù)都被沖洗到了管道線中的datanode中，并且對所有讀者都可見了：

Path p = new Path("p");

FSDataOutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.flush();

out.sync();

assertThat(fs.getFileStatus(p).getLen(), is(((long) "content".length())));

這個方法就像POSIX中的fsync系統(tǒng)調(diào)用（它沖洗給定文件描述符中的所有緩沖數(shù)據(jù)到磁盤中）。例如，使用java API寫一個本地文件，我們可以保證在調(diào)用flush()和同步化后可以看到已寫入的內(nèi)容：

FileOutputStream out = new FileOutputStream(localFile);

out.write("content".getBytes("UTF-8"));

out.flush(); // flush to operating system

out.getFD().sync(); // sync to disk （getFD()返回與該流所對應(yīng)的文件描述符）

assertThat(localFile.length(), is(((long) "content".length())));

在HDFS中關(guān)閉一個流隱式的調(diào)用了sync()方法：

Path p = new Path("p");

OutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.close();

assertThat(fs.getFileStatus(p).getLen(), is(((long) "content".length())));

由于Hadoop中的一致性模型限制，如果我們不調(diào)用sync()方法的話，我們很可能會丟失多大一個block的數(shù)據(jù)。這是難以接受的，所以我們應(yīng)該使用sync()方法來確保數(shù)據(jù)已經(jīng)寫入磁盤。但頻繁調(diào)用sync()方法也是不好的，因為會造成很多額外開銷。我們可以再寫入一定量數(shù)據(jù)后調(diào)用sync()方法一次，至于這個具體的數(shù)據(jù)量大小就要根據(jù)你的應(yīng)用程序而定了，在不影響你的應(yīng)用程序的性能的情況下，這個數(shù)據(jù)量應(yīng)越大越好。

簡述hadoop工作原理（hadoop工作原理圖）