大資料備份方面最常見誤區

2021-09-03 03:34:54 字數 1707 閱讀 2515

1、資料有多個副本,就不需要單獨的大資料備份/恢復工具。

大資料平台建立資料的多個副本,並將這些副本分布在不同的伺服器或機架上。萬一出現硬體故障,這種型別的資料冗餘機制可保護資料。然而,其他任何情況(比如使用者錯誤、意外刪除或資料損壞等)都會導致資料丟失,因為這些錯誤或損壞會迅速蔓延到所有資料副本。
2、丟失的資料可以通過原始資料快速而輕鬆地重建。

如果你仍擁有重建丟失資料的所有原始資料,這也許切實可行。但在大多數情況下,原始資料被刪除或不容易訪問。就算原始資料可用,重建丟失的大資料可能也需要好幾周,消耗大量的技術資源,而且對大資料使用者來說延長了停機時間。
3、備份pb級大資料是不經濟或不實際的。

pb級資料的定期完整備份需要數週時間,還需要高額的基礎設施投入。然而,你可以採取幾個辦法來緩解這些問題。你可以找出對貴企業來說很寶貴的一小部分資料,然後只備份這部分資料。採用重複資料刪除等較新的備份技術來高效地儲存備份內容,永久增量備份以傳輸變化的內容,使用商用伺服器,這些同樣有助於降低成本、縮短備份時間。
4、遠端災難恢復副本可以充當備份副本。

謹慎的做法是,將資料副本放在遠端資料中心,防止火災和**之類的大規模災害。這通常通過定期將資料從生產資料中心複製到災難恢復資料中心來實現。然而,對生產資料中心所作的所有變化會蔓延到災難恢復站點,包括意外刪除、資料庫損壞、應用程式損壞等。因此,災難恢復副本不能充當備份副本,因為它沒有你可以用來回滾的時間點副本。
5、編寫大資料的備份/恢復指令碼很容易。

如果你擁有技術資源,資料量不大,又只有一種大資料平台,那麼編寫指令碼切實可行。大多數企業組織通常有數十tb、乃至數百tb的大資料散布在多個大資料平台上。針對這種型別的環境編寫、測試和維護指令碼並非易事。需要為得到支援的每種平台編寫指令碼。指令碼必須大規模進行測試;平台版本變化後,還得重新測試。在某些情況下,指令碼可能需要定期更新,以便支援平台的新功能、新api、新的資料型別等。

大多數企業組織沒有認識到,針對大資料平台編寫好的備份指令碼面臨大筆的隱性成本,還需要相應專長。恢復過程難得多,而且容易出錯,因為它涉及諸多環節:找到合適的備份副本,將資料拷回到相應節點,運用針對特定平台的恢復程式以恢復資料。

6、大資料備份/恢復操作成本很低。

除了定期維護和測試指令碼外,還有與備份和恢復有關的額外成本。額外成本包括如下:

人員成本:有人得負責執行指令碼,確保備份成功,需要時進行除錯,執行臨時恢復等。

儲存成本:儲存備份內容需要花錢。

停機成本:在這段時間內,管理員要找到備份副本,並將資料恢復到理想狀態。

尤其是在大資料環境變得更龐大、更複雜後,這些成本可能會大幅增加。

7、快照是大資料的一種有效的備份機制。

快照(在特定時間點凍結的資料狀態)有時用作備份副本,以防止使用者錯誤或應用程式損壞。

快照可以用來使備份過程實現自動化。然而,使用儲存快照時,需要額外的手動步驟,確保備份資料和元資料的一致性。

其次,資料不快速變化時,快照才有效。就大資料平台而言,資料變化速度很快,而壓縮等技術只會加快資料變化速度。因而,快照需要龐大的儲存開銷(高達50%)來保留幾個時間點拷貝。最後,通過快照恢復資料將是非常繁瑣的手動過程。管理員或資料庫管理員不得不找出與需要恢復的資料(比如金鑰空間或表)相對應的快照檔案,然後通過快照恢復到集群中的相應節點。恢復過程中一旦出現錯誤,就會導致資料永久丟失。

SEO中最常見的十大誤區

許多都試圖自己動手優化他們的 以下十點是優化過程中比較常見的錯誤。3.重複或不好的網頁內容。成功的seo運動中,確保 上不存在重複的網頁內容也很關鍵。許多 往往只是拷貝或抄襲其他 上的內容,據我了解,這類 的搜尋引擎排名通常都不會很高,自己動手構思一些像樣的獨特的文章,或花錢僱傭專業人士幫你抒寫好的...

程式設計師最常見的技術性誤區

1 程式設計只是為了錢 如果你不是很喜歡程式設計,你的 一定會雜亂無章。結果不僅影響你的職業生涯,你的團隊成員也會跟著遭殃。2 沒有基本的能力 那些不擅長程式設計概念,比如抽象 多型性 介面的使用 異常處理的最佳做法等,寫出的 在設計上會很差 很難閱讀 也很難維護。3 過分追求智慧型 一些開發者過分...

程式設計師最常見的技術性誤區

1.程式設計只是為了錢 如果你不是很喜歡程式設計,你的 一定會雜亂無章。結果不僅影響你的職業生涯,你的團隊成員也會跟著遭殃。2.沒有基本的能力 那些不擅長程式設計概念,比如抽象 多型性 介面的使用 異常處理的最佳做法等,寫出的 在設計上會很差 很難閱讀 也很難維護。3.過分追求智慧型 一些開發者過分...