hdfs資料塊：
與一般檔案系統一樣，hdfs也有塊（block）的概念，hdfs上的檔案也被劃分為塊大小的多個分塊作為獨立的儲存單元。
與通常的磁碟檔案系統不同的是：
hdfs中小於乙個塊大小的檔案不會佔據整個塊的空間（當乙個1mb的檔案儲存在乙個128mb的塊中時，檔案只使用1mb的磁碟空間，而不是128mb）
設定資料塊的好處：
（1）乙個檔案的大小可以大於集群任意節點磁碟的容量
（2）容易對資料進行備份，提高容錯能力
1、塊大小設定
在hdfs-site.xml中，增加全域性引數dfs.block.size
dfs.block.size
512000
注意：blocksize必須是io.bytes.per.checksum的整數倍，否則會報錯
「put: io.bytes.per.checksum(512) and blocksize(100000) do not match. blocksize should be a multiple of io.bytes.per.checksum」
為什麼不能遠少於64mb？
（1）減少硬碟尋道時間。hdfs設計前提是應對大資料量操作，若資料塊大小設定過小，那需要讀取的資料塊數量就會增多，從而間接增加底層硬碟的尋道時間
（2）減少namenode記憶體消耗。由於namenode記錄著datanode中的資料塊資訊，若資料塊大小設定過小，則資料塊數量增多，需要維護的資料塊資訊就會增多，從而消耗namenode的記憶體。
為什麼不能遠大於64mb？
原因主要從上層的mapreduce框架來尋找。
（2）監管時間問題。主節點監管其他節點的情況，每個節點會週期性的與主節點進行匯報通訊。倘若某乙個節點保持沉默的時間超過乙個預設的時間間隔，主節點會記錄這個節點狀態為死亡，並將該節點的資料**給別的節點。而這個「預設時間間隔」是從資料塊的角度大致估算的。（加入對64mb的資料塊，我可以假設你10分鐘之內無論如何也能解決完了吧，超過10分鐘還沒反應，那我就認為你出故障或已經死了。）64mb大小的資料塊，其時間尚可較為精準地估計，如果我將資料塊大小設為640mb甚至上g，那這個「預設的時間間隔」便不好估算，估長估短對系統都會造成不必要的損失和資源浪費。
（3）問題分解問題。資料量的大小與問題解決的複雜度呈線性關係。對於同乙個演算法，處理的資料量越大，時間複雜度越高。
（4）約束map輸出。在map reduce框架裡，map之後的資料是要經過排序才執行reduce操作的。這通常涉及到歸併排序，而歸併排序的演算法思想便是「對小檔案進行排序，然後將小檔案歸併成大檔案」，因此「小檔案」不宜過大。
hdfs的塊設定的如此之大主要還是為了減小定址開銷的，《hadoop權威指南》中有一段話：
「hdfs的塊比磁碟塊大，其目的是為了最小化定址開銷。如果塊設定得足夠大，從磁碟傳輸資料的時間可以明顯大於定位這個塊開始位置所需的時間。這樣，傳輸乙個由多個塊組成的檔案的時間就取決於磁碟傳輸速率。」
「我們做乙個估計計算，如果定址時間為10ms左右，而傳輸速率為100mb/s，為了使定址時間僅佔傳輸時間的1%，我們需要設定塊大小為100mb左右。而預設的塊大小實際為64mb，但是很多情況下hdfs使用128mb的塊設定。以後隨著新一代磁碟驅動器傳輸速率的提公升，塊的大小將被設定得更大。」
linux swap 交換空間 設定多大合適
無論是windows系統還是linux系統，除了物理記憶體外，都還有乙個虛擬記憶體。在linux上，虛擬記憶體被稱為swap space。過去以來，虛擬記憶體的大小應該是物理記憶體的兩倍，但是最近幾年來，物理記憶體的大小至少都有了好幾個gb，如果16g記憶體用32g的swap豈不是太占用硬碟空間？下...
示波器到底選擇多大的頻寬合適
本文 這是個經常碰到的問題 我想測8gbps的pcie 還有sas sata usb lvds等等 串 行匯流排，16g的示波器行不行？12g的示波器行不行？8g的示波器行不行？對於高速序列匯流排來說，示波器到底多大頻寬夠用呢？最簡單的筧法是，假定匯流排中傳輸 的都是0 1間隔的訊號，就是方波時鐘，...
網頁頁面尺寸一般設定多大才合適
網頁設計在初始要界定出網頁的尺寸大小.就像繪畫給出一塊畫版來.這樣才能方便設計.網頁的尺寸受限於兩個因素 乙個是顯示器螢幕.顯示器現在種類很多,以17寸為主流,正在朝19寸及寬屏的方向發展.但目前也有為數不少的15寸顯示器.另乙個是瀏覽器軟體,就是我們常用的ie,遨遊,friefox等.高度 高度是...