資料完整性
hadoop本身自帶原始的資料io操作，包括資料處理的完整，壓縮等等。但是面對大資料集，還是需要特殊考慮，還包含hadoop tools中的一些元件，例如序列化框架，硬碟資料儲存結構等。
因為資料要在hdfs中分散多處，那麼，資料其實不應該有丟失或者損壞。但是，每個磁碟或者網路io都有可能對讀寫操作引入錯誤，但資料變得更大。疊加起來的概率就會更加高。磁碟讀寫錯誤率與磁碟本身的狀態有關，網路延遲或者故障等也會導致網路io錯誤。
如果很難感受io錯誤概率的影響，我們可以做乙個簡單的計算：
假設我們每一次的io流量是1mb，每一次出現的概率是很低很低的，假設為1/10^7 對於普通磁碟和網路io大概可以達到這個概率，平常使用者單一操作並不會產生什麼影響。當時大資料集處理500gb的時候，出現錯誤的概率：
r=1-(1-107)500*1024=5%
由此可見，在我們傳輸500gb的時候，有5%的概率產生io錯誤。
因此大資料處理的時候就應該仔細考慮這個問題。我們面臨的不只是500gb，可能是500tb或者更多海量的資料。io操作中對資料的校驗操作是解決這個問題的乙個不可或缺的方法。
常用的做法是在第一次進入系統的時候計算資料校驗和。校驗和（checksum）是冗餘校驗的一種形式。 它是通過錯誤檢測方法，對經過空間（如通訊）或者時間（如計算機儲存）傳送的資料的完整性進行檢查的一種簡單方法。計算機領域常見的校驗和的方法有迴圈冗餘校驗（crc）、md5、sha家族等。當傳輸結束時，接收者可以根據這個數值判斷是否接到了所有的資料。如果數值匹配，那麼說明傳送已經完成。
例如上圖，節點1和節點2之間進行檔案傳輸，node1寫檔案到node2,node2收到資料的時候就會進行校驗，如果node1中的checksum和node2中的不一樣，就說明檔案傳輸中被損壞，就會馬上丟擲checksum exception.這個checksum excepion屬於ioexception的乙個子類。
每一校驗的檔案的大小預設是512位元組，這是由系統預設設定的，也可以人工設定為其他的值（io.bytes.per.checksum）.
以上的例子是節點之間或者客服端可節點之間的網路傳輸的校驗。另外乙個校驗的地點發生在資料節點上面，也就是節點本地系統。資料節點data node維護乙個連續的校驗和驗證日誌，他知道每個資料塊最後的驗證時間，出了與client進行驗證，每個節點還會在後台執行datablockscanner，這個程式用來檢驗存在節點上的所有的資料塊，防止bit rot的產生。
bit rot在這裡指的是，儲存在磁碟中的 資料的 效能和完整性的緩慢變化。
由於hdfs存在至少三個副本，在client進行資料操作，發現資料塊校驗失敗之後，丟擲checksu exception，就會報告這個資料塊以及他的這個資料節點，名稱節點會標記這個 節點上的這個資料塊為損壞，組織進行修復。
在本地檔案系統裡面的校驗和是怎麼體現出來的呢？校驗和儲存在**？校驗和對應的資料塊大小改變了怎麼辦？
其實在hdfs中，在同乙個資料夾下面包含每乙個檔案的校驗和，譬如：
檔案的名字是filename,
那麼校驗檔案就是.filename.crc
校驗檔案包含校驗值以及校驗檔案的大小等資訊。因此即使系統中的檔案塊大小改變，還是可以通過校驗檔案，讀取到校驗碼對應的檔案塊大小以及檔案塊。
當然，除了校驗檔案保證檔案沒有出現錯誤之外，我們還要考慮另外乙個問題，大量的資料導致大量的儲存需求，因此我們面臨著壓縮和解壓縮，編碼和解碼的需求壓力。
STP特性詳解
stp特性詳解 我們平時應用到的stp，雖然可以保證2層網路的無環路，但是他本身也存在一些缺點。比如stp機構收斂速度慢，根交換機的身份很容易遭受威脅，不安全，沒有一種措施來鞏固他們的根交換機的身份。如果要是這樣的話，那麼在乙個網路中，有可能這個網路的stp結構就會頻繁的變化，導致網路中的資料報大量...
C 詳解特性
在過去，以一種語言編寫的軟體元件 exe 或 dll 不能方便地使用以另一種語言編寫的軟體元件。在這個問題的解決上，com 向前邁進了一步。net framework 允許編譯器向所有的模組和程式集發出附加的說明性資訊，從而使元件互用更加簡單。這種叫做 元資料 的資訊有助於元件無縫互動。元資料是一種...
C 特性詳解
特性提供功能強大的方法，用以將元資料或宣告資訊與 程式集 型別 方法 屬性等 相關聯。reflection.data guid 716c0768f610f38427afe934e71f1d47 特性與程式實體關聯後，即可在執行時使用名為 反射 的技術查詢特性。這篇文章絕大部分是按照msdn來學習的，...