底層數據存儲系統

『壹』 ibm gpfs 容量

ibm gpfs容量3-4份。

IBM GPFS可以替代HDFS作為Hadoop架構的底層文件系統/數據存儲。Hadoop主要是能夠做DAS直連存儲，（位於各個節點上的）硬碟是分布式的，數據會拷貝3-4份進行保護。Hadoop不需要高端的產品，不用共享存儲，而是用分布式存儲，它的成本相比共享存儲（比如DS8000）要低。

集群存儲提供了SAN和NAS結構的優點。在大多數使用集群存儲的案例中，隨著存儲系統的擴容，性能也隨之提升。一個大的集群存儲的性能往往勝過一個SAN系統，但是價格也會更高。集群存儲系統像NAS系統一樣易於構建、操作和擴容。大多數集群存儲系統沒有傳統NAS系統的固有瓶頸。

功能：

文件的系統是操作系統用於明確磁碟或分區上的文件的方法和數據結構；即在磁碟上組織文件的方法。也指用於存儲文件的磁碟或分區，或文件系統種類。因此，可以說"我有2個文件系統"意思是他有2個分區，一個存文件，或他用 "擴展文件系統"，意思是文件系統的種類。

磁碟或分區和它所包括的文件系統的不同是很重要的。少數程序（包括最有理由的產生文件系統的程序）直接對磁碟或分區的原始扇區進行操作；這可能破壞一個存在的文件系統。大部分程序基於文件系統進行操作，在不同種文件系統上不能工作。

『貳』 以下哪些屬於集中化大數據平台外部採集數據

如何從0到1搭建大數據平台
大數據時代這個詞被提出已有10年了吧，越來越多的企業已經完成了大數據平台的搭建。隨著移動互聯網和物聯網的爆發，大數據價值在越來越多的場景中被挖掘，隨著大家都在使用歐冠大數據，大數據平台的搭建門檻也越來越低。藉助開源的力量，任何有基礎研發能力的組織完全可以搭建自己的大數據平台。但是對於沒有了解過大數據平台、數據倉庫、數據挖掘概念的同學可能還是無法順利完成搭建，因為你去網路查的時候會發現太多的東西，和架構，你不知道如何去選擇。今天給大家分享下大數據平台是怎麼玩的。

00 架構總覽

通常大數據平台的架構如上，從外部採集數據到數據處理，數據顯現，應用等模塊。

01 數據採集

用戶訪問我們的產品會產生大量的行為日誌，因此我們需要特定的日誌採集系統來採集並輸送這些日誌。Flume是目前常用的開源選擇，Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日誌採集、聚合和傳輸的系統，Flume支持在日誌系統中定製各類數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方的能力。

02 數據存儲

無論上層採用何種的大規模數據計算引擎，底層的數據存儲系統基本還是以HDFS為主。HDFS（Hadoop Distributed File System）是Hadoop項目的核心子項目，是分布式計算中數據存儲管理的基礎。具備高容錯性、高可靠、高吞吐等特點。

HDFS存儲的是一個個的文本，而我們在做分析統計時，結構化會方便需要。因此，在HDFS的基礎上，會使用Hive來將數據文件映射為結構化的表結構，以便後續對數據進行類SQL的查詢和管理。

03 數據處理

數據處理就是我們常說的ETL。在這部分，我們需要三樣東西：計算引擎、調度系統、元數據管理。

對於大規模的非實時數據計算來講，目前一樣採用Hive和spark引擎。Hive是基於MapRece的架構，穩定可靠，但是計算速度較慢；Spark則是基於內存型的計算，一般認為比MapRece的速度快很多，但是其對內存性能的要求較高，且存在內存溢出的風險。Spark同時兼容hive數據源。從穩定的角度考慮，一般建議以Hive作為日常ETL的主要計算引擎，特別是對於一些實時要求不高的數據。Spark等其他引擎根據場景搭配使用。

實時計算引擎方面，目前大體經過了三代，依次是：storm、spark streaming、Flink。Flink已被阿里收購，大廠一直在推，社區活躍度很好，國內也有很多資源。

調度系統上，建議採用輕量級的Azkaban，Azkaban是由Linkedin開源的一個批量工作流任務調度器。https://azkaban.github.io/

一般需要自己開發一套元數據管理系統，用來規劃數據倉庫和ETL流程中的元數據。元數據分為業務元數據和技術元數據。

業務元數據，主要用於支撐數據服務平台Web UI上面的各種業務條件選項，比如，常用的有如下一些：移動設備機型、品牌、運營商、網路、價格範圍、設備物理特性、應用名稱等。這些元數據，有些來自於基礎數據部門提供的標准庫，比如品牌、價格範圍等，可以從對應的數據表中同步或直接讀取；而有些具有時間含義的元數據，需要每天通過ETL處理生成，比如應用信息。為支撐應用計算使用，被存儲在MySQL資料庫中；而對於填充頁面上對應的條件選擇的數據，則使用Redis存儲，每天/月會根據MySQL中的數據進行加工處理，生成易於快速查詢的鍵值對類數據，存儲到Redis中。
技術元數據，主要包括數據倉庫中的模型說明、血緣關系、變更記錄、需求來源、模型欄位信息等，詳細的可以查看數據分析師應該了解的數據倉庫(3)

04 數據流轉
通過上面一張圖了解數據採集，數據處理，到數據展現的數據流轉。通常我們在實際工作中，從數據源到分析報告或系統應用的過程中，主要包括數據採集同步、數據倉庫存儲、ETL、統計分析、寫入上層應用資料庫進行指標展示。這是最基礎的一條線，現在還有基於數據倉庫進行的數據分析挖掘工作，會基於機器學習和深度學習對已有模型數據進一步挖掘分析，形成更深層的數據應用產品。

05 數據應用
俗話說的好，「酒香也怕巷子深」。數據應用前面我們做了那麼多工作為了什麼，對於企業來說，我們做的每一件事情都需要體現出價值，而此時的數據應用就是大數據的價值體現。數據應用包括輔助經營分析的一些報表指標，商城上基於用戶畫像的個性化推送，還有各種數據分析報告等等。

數據採集系統
01 「大」數據

海量的數據

當你需要搭建大數據平台的時候一定是傳統的關系型資料庫無法滿足業務的存儲計算要求了，所以首先我們面臨的是海量的數據。

復雜的數據

復雜數據的概念和理想數據完全相反。所有數據集都有一定的復雜性，但有一些天生更難處理。通常這些復雜數據集沒有定義結構(沒有行列結構)，經常變化，數據質量很差。比如更新的網頁日誌，json數據，xml數據等。

高速的數據

高速數據通常被認為是實時的或是准實時的數據流。數據流本質上是在生成後就發給處理器的數據包，比如物聯網的穿戴設備，製造業的感測器，車聯網的終端晶元等等。處理實時數據流有很多挑戰，包括在採集時不丟失數據、處理數據流中的重復記錄、數據如何實時寫入磁碟存儲、以及如何進行實時分析。

02 採集工具
日誌採集

我們業務平台每天都會有大量用戶訪問，會產生大量的訪問日誌數據，比如電商系統的瀏覽，加入購物車，下訂單，付款等一系列流程我們都可以通過埋點獲取到用戶的訪問路徑以及訪問時長這些數據；再比智能穿戴設備，實時都會採集我們的血壓、脈搏、心率等數據實時上報到雲端。通過分析這些日誌信息，我們可以得到出很多業務價值。通過對這些日誌信息進行日誌採集、收集，然後進行數據分析，挖掘公司業務平台日誌數據中的潛在價值。為公司決策和公司後台伺服器平台性能評估提高可靠的數據保證。系統日誌採集系統做的事情就是收集日誌數據提供離線和在線的實時分析使用。目前常用的開源日誌收集系統有Flume、Logstash、Filebeat。可以根據自己公司的技術棧儲備或者組件的優缺點選擇合適的日誌採集系統，目前了解到的Flume使用的比較多。各個採集工具的對比如下：

具體組件的相關配置可以參考之前的文章《日誌收集組件—Flume、Logstash、Filebeat對比》

資料庫抽取

企業一般都會會使用傳統的關系型資料庫MySQL或Oracle等來存儲業務系統數據。每時每刻產生的業務數據，以資料庫一行記錄的形式被直接寫入到資料庫中保存。

大數據分析一般是基於歷史海量數據，多維度分析，我們不能直接在原始的業務資料庫上直接操作，因為分析的一些復雜SQL查詢會明顯的影響業務資料庫的效率，導致業務系統不可用。所以我們通常通過資料庫採集系統直接與企業業務後台資料庫伺服器結合，在業務不那麼繁忙的凌晨，抽取我們想要的數據到分析資料庫或者到HDFS上，最後有大數據處理系統對這些數據進行清洗、組合進行數據分析。

常用資料庫抽取工具：

阿里開源軟體：DataX
DataX 是一個異構數據源離線同步工具，致力於實現包括關系型資料庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構數據源之間穩定高效的數據同步功能。開源的DataX貌似只能單機部署。

Apache開源軟體：Sqoop
Sqoop(發音:skup)是一款開源的工具，主要用於在HADOOP(Hive)與傳統的資料庫(mysql、postgresql...)間進行數據的傳遞，可以將一個關系型資料庫(例如 : MySQL ,Oracle ,Postgres等)中的數據導進到Hadoop的HDFS中，也可以將HDFS的數據導進到關系型資料庫中。可以集群化部署。

爬蟲爬取

有很多外部數據，比如天氣、IP地址等數據，我們通常會爬取相應的網站數據存儲。目前常用的爬蟲工具是Scrapy，它是一個爬蟲框架，提供給開發人員便利的爬蟲API介面。開發人員只需要關心爬蟲API介面的實現，不需要關心具體框架怎麼爬取數據。Scrapy框架大大降低了開發人員開發速率，開發人員可以很快的完成一個爬蟲系統的開發。

03 數據存儲
HDFS

2003年，Google發布論文GFS，啟發Apache Nutch開發了HDFS。2004年，Google 又發布了論文《MapRece: Simplified Data Processing on Large Clusters》，Doug Cutting等人實現計算框架MapRece ，並與HDFS結合來更好的支持該框架。2006年項目從Butch搜索引擎中獨立出來，成為了現在的Hadoop。

GFS隱藏了底層的負載均衡，切片備份等細節，使復雜性透明化，並提供統一的文件系統介面。其成本低，容錯高，高吞吐，適合超大數據集應用場景。

HDFS原理:橫向擴展，增加「數據節點」就能增加容量。
增加協調部門，「命名節點」維護元數據，負責文件系統的命名空間，控
外部訪問，將數據塊映射到數據節點。還會備份元數據從命名節點，它只與命名節點通信。
數據在多個數據節點備份。
通常關系型資料庫存儲的都是結構化的數據，我們抽取後會直接放到HDFS上作為離線分析的數據源。

HBase

在實際應用中，我們有很多數據可能不需要復雜的分析，只需要我們能存儲，並且提供快速查詢的功能。HBase在HDFS基礎上提供了Bigtable的能力; 並且基於列的模式進行存儲。列存儲設計的優勢是減少不必要的欄位佔用存儲，同時查詢的時候也可以只對查詢的指定列有IO操作。HBase可以存儲海量的數據，並且可以根據rowkey提供快速的查詢性能，是非常好的明細數據存儲方案，比如電商的訂單數據就可以放入HBase提供高效的查詢。

當然還有其他的存儲引擎，比如ES適合文本搜索查詢等。

04 總結
了解了上面的技術棧後，在實際數據接入中，你還會面臨各種問題，比如如何考慮確保數據一致性，保障數據不能丟失，數據採集存儲的效率，不能產生數據積壓等，這些都需要對每個組件進行研究，適配適合你自己業務系統的參數，用最少的資源，達到最好的結果。

調度系統
目前大數據平台經常會用來跑一些批任務，跑批處理當然就離不開定時任務。比如定時抽取業務資料庫的數據，定時跑hive/spark任務，定時推送日報、月報指標數據。任務調度系統已經儼然成為了大數據處理平台不可或缺的一部分，可以說是ETL任務的靈魂。

01 原始任務調度

記得第一次參與大數據平台從無到有的搭建，最開始任務調度就是用的Crontab，分時日月周，各種任務腳本配置在一台主機上。Crontab 使用非常方便，配置也很簡單。剛開始任務很少，用著還可以，每天起床巡檢一下日誌。隨著任務越來越多，出現了任務不能在原來計劃的時間完成，出現了上級任務跑完前，後面依賴的任務已經起來了，這時候沒有數據，任務就會報錯，或者兩個任務並行跑了，出現了錯誤的結果。排查任務錯誤原因越來麻煩，各種任務的依賴關系越來越復雜，最後排查任務問題就行從一團亂麻中，一根一根梳理出每天麻繩。crontab雖然簡單，穩定，但是隨著任務的增加和依賴關系越來越復雜，已經完全不能滿足我們的需求了，這時候就需要建設自己的調度系統了。

02 調度系統
調度系統，關注的首要重點是在正確的時間點啟動正確的作業，確保作業按照正確的依賴關系及時准確的執行。資源的利用率通常不是第一關注要點，業務流程的正確性才是最重要的。（但是到隨著業務的發展，ETL任務越來越多，你會發現經常有任務因為資源問題沒有按時啟動！）

實際調度中，多個任務單元之間往往有著強依賴關系，上游任務執行並成功，下游任務才可以執行。比如上游任務1結束後拿到結果，下游任務2、任務3需結合任務1的結果才能執行，因此下游任務的開始一定是在上游任務成功運行拿到結果之後才可以開始。而為了保證數據處理結果的准確性，就必須要求這些任務按照上下游依賴關系有序、高效的執行，最終確保能按時正常生成業務指標。

一款成熟易用，便於管理和維護的作業調度系統，需要和大量的周邊組件對接，要處理或使用到包括：血緣管理，許可權控制，負載流控，監控報警，質量分析等各種服務或事務。

03 調度系統分類
調度系統一般分為兩類：定時分片類作業調度系統和DAG工作流類作業調度系統

定時分片類作業調度系統

這種功能定位的作業調度系統，其最早的需要來源和出發點往往是做一個分布式的Crontab。

核心：

將一個大的任務拆成多個小任務分配到不同的伺服器上執行， 難點在於要做到不漏，不重，保證負載平衡，節點崩潰時自動進行任務遷移等。
保證任務觸發的強實時和可靠性
所以，負載均衡，彈性擴容，狀態同步和失效轉移通常是這類調度系統在架構設計時重點考慮的特性。

DGA工作流調度系統

這一類系統的方向，重點定位於任務的調度依賴關系的正確處理，分片執行的邏輯通常不是系統關注的核心，或者不是系統核心流程的關鍵組成部分。

核心：

足夠豐富和靈活的依賴觸發機制：比如時間觸發任務，依賴觸發任務，混合觸發任務
作業的計劃，變更和執行流水的管理和同步
任務的優先順序管理，業務隔離，許可權管理等
各種特殊流程的處理，比如暫停任務，重刷歷史數據，人工標註失敗／成功，臨時任務和周期任務的協同等
完備的監控報警通知機制
04 幾個調度系統
Airflow

Apache Airflow是一種功能強大的工具，可作為任務的有向無環圖（DAG）編排、任務調度和任務監控的工作流工具。Airflow在DAG中管理作業之間的執行依賴，並可以處理作業失敗，重試和警報。開發人員可以編寫Python代碼以將數據轉換為工作流中的操作。

主要有如下幾種組件構成：

web server: 主要包括工作流配置，監控，管理等操作
scheler: 工作流調度進程，觸發工作流執行，狀態更新等操作
消息隊列：存放任務執行命令和任務執行狀態報告
worker: 執行任務和匯報狀態
mysql: 存放工作流，任務元數據信息
具體執行流程：

scheler掃描dag文件存入資料庫，判斷是否觸發執行
到達觸發執行時間的dag,生成dag_run，task_instance 存入資料庫
發送執行任務命令到消息隊列
worker從隊列獲取任務執行命令執行任務
worker匯報任務執行狀態到消息隊列
schler獲取任務執行狀態，並做下一步操作
schler根據狀態更新資料庫
Kettle

將各個任務操作組件拖放到工作區，kettle支持各種常見的數據轉換。此外，用戶可以將Python，java，JavaScript和SQL中的自定義腳本拖放到畫布上。kettle可以接受許多文件類型作為輸入，還可以通過JDBC，ODBC連接到40多個資料庫，作為源或目標。社區版本是免費的，但提供的功能比付費版本少。

XXL-JOB

XXL-JOB是一個分布式任務調度平台，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。將調度行為抽象形成「調度中心」公共平台，而平台自身並不承擔業務邏輯，「調度中心」負責發起調度請求；將任務抽象成分散的JobHandler，交由「執行器」統一管理，「執行器」負責接收調度請求並執行對應的JobHandler中業務邏輯；因此，「調度」和「任務」兩部分可以相互解耦，提高系統整體穩定性和擴展性。（後來才知道XXL是作者名字拼音首字母縮寫）

調度系統開源工具有很多，可以結合自己公司人員的熟悉程度和需求選擇合適的進行改進。

海豚調度

Apache DolphinScheler是一個分布式去中心化，易擴展的可視化DAG工作流任務調度平台。致力於解決數據處理流程中錯綜復雜的依賴關系，使調度系統在數據處理流程中開箱即用。

高可靠性
去中心化的多Master和多Worker服務對等架構, 避免單Master壓力過大，另外採用任務緩沖隊列來避免過載
簡單易用
DAG監控界面，所有流程定義都是可視化，通過拖拽任務完成定製DAG，通過API方式與第三方系統集成, 一鍵部署
豐富的使用場景
支持多租戶，支持暫停恢復操作. 緊密貼合大數據生態，提供Spark, Hive, M/R, Python, Sub_process, Shell等近20種任務類型
高擴展性
支持自定義任務類型，調度器使用分布式調度，調度能力隨集群線性增長，Master和Worker支持動態上下線
05 如何自己開發一個調度系統
調度平台其實需要解決三個問題：任務編排、任務執行和任務監控。

任務編排，採用調用外部編排服務的方式，主要考慮的是編排需要根據業務的一些屬性進行實現，所以將易變的業務部分從作業調度平台分離出去。如果後續有對編排邏輯進行調整和修改，都無需操作業務作業調度平台。
任務排隊，支持多隊列排隊配置，後期根據不同類型的開發人員可以配置不同的隊列和資源，比如面向不同的開發人員需要有不同的服務隊列，面向不同的任務也需要有不同的隊列優先順序支持。通過隊列來隔離調度，能夠更好地滿足具有不同需求的用戶。不同隊列的資源不同，合理的利用資源，達到業務價值最大化。
任務調度，是對任務、以及屬於該任務的一組子任務進行調度，為了簡單可控起見，每個任務經過編排後會得到一組有序的任務列表，然後對每個任務進行調度。這裡面，稍有點復雜的是，任務里還有子任務，子任務是一些處理組件，比如欄位轉換、數據抽取，子任務需要在上層任務中引用實現調度。任務是調度運行的基本單位。被調度運行的任務會發送到消息隊列中，然後等待任務協調計算平台消費並運行任務，這時調度平台只需要等待任務運行完成的結果消息到達，然後對作業和任務的狀態進行更新，根據實際狀態確定下一次調度的任務。
調度平台設計中還需要注意以下幾項：

調度運行的任務需要進行超時處理，比如某個任務由於開發人員設計不合理導致運行時間過長，可以設置任務最大的執行時長，超過最大時長的任務需要及時kill掉，以免佔用大量資源，影響正常的任務運行。
控制同時能夠被調度的作業的數量，集群資源是有限的，我們需要控制任務的並發量，後期任務上千上萬後我們要及時調整任務的啟動時間，避免同時啟動大量的任務，減少調度資源和計算資源壓力；
作業優先順序控制，每個業務都有一定的重要級別，我們要有限保障最重要的業務優先執行，優先給與調度資源分配。在任務積壓時候，先執行優先順序高的任務，保障業務影響最小化。
06 總結與展望
ETL 開發是數據工程師必備的技能之一，在數據倉庫、BI等場景中起到重要的作用。但很多從業者連 ETL 對應的英文是什麼都不了解，更不要談對 ETL 的深入解析，這無疑是非常不稱職的。做ETL 你可以用任何的編程語言來完成開發，無論是 shell、python、java 甚至資料庫的存儲過程，只要它最終是讓數據完成抽取（E）、轉化（T）、載入（L）的效果即可。由於ETL是極為復雜的過程，而手寫程序不易管理，所以越來越多的可視化調度編排工具出現了。

調度系統作為大數據平台的核心部分之一，牽扯的業務邏輯比較復雜，場景不同，也許需求就會差別很多，所以，有自研能力的公司都會選擇市面上開源系統二次開發或者完全自研一套調度系統，已滿足自身ETL任務調度需求。

不管是哪種工具，只要具備高效運行、穩定可靠、易於維護特點，都是一款好工具

『叄』 我對於底層 的文件數據 存儲有些理解，但是操作系統 是如何 純數學 的數據01 存儲 圖形化呢

圖形存儲的是描繪演算法，系統可以根據演算法重現；點陣圖存儲的是每個像素的顏色/灰度值。有一種東西叫顯卡。。。

『肆』 Hadoop生態系統-新手快速入門（含HDFS、HBase系統架構）

Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。

用戶可以在不了解分布式底層細節的情況下，開發分布式程序。充分利用集群的威力進行高速運算和存儲。

Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上；而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。

Hadoop的框架最核心的設計就是：HDFS和MapRece。HDFS為海量的數據提供了存儲，而MapRece則為海量的數據提供了計算。

廣義的Hadoop，一般稱為Hadoop生態系統，如下所示。

Hadoop生態系統中這些軟體的作用：

HDFS 採用了主從（Master/Slave）結構模型，一個HDFS集群包括一個名稱節點（NameNode）和若干個數據節點（DataNode）。

HDFS採用Java語言開發，因此任何支持JVM的機器都可以部署名稱節點和數據節點。

在配置好Hadoop 集群之後，可以通過瀏覽器訪問 http://[NameNodeIP]:9870，查詢HDFS文件系統。通過該Web界面，可以查看當前文件系統中各個節點的分布信息。

HBase系統架構如下所示，包括客戶端、Zookeeper伺服器、Master主伺服器、Region伺服器。一般而言，HBase會採用HDFS作為底層數據存儲。

在HBase伺服器集群中，包含了一個Master和多個Region伺服器，Master是HBase集群的「總管」，它必須知道Region伺服器的狀態。

HBase中可以啟動多個Master，但是Zookeeper 可以幫助選舉出一個Master 作為集群的總管，並保證在任何時刻總有唯一一個Master在運行，這樣可以避免Master單點失效的問題。

Region伺服器是HBase中最核心的模塊，負責維護分配給自己的Region，並響應用戶的讀寫請求。

Store是Region伺服器的核心。每個Store對應了表中的一個列族的存儲。每一個Store包含了一個MemStore緩存和若干個StoreFile文件。

HBase採用HLog來保證系統發生故障時，能夠恢復到正確的狀態。HLog是磁碟上面的記錄文件，它記錄著所有的更新操作。

HBase系統為每個Region伺服器配置了一個HLog文件，它是一種預寫式日誌（Write Ahead Log），也就是說，用戶更新數據必須首先被記入日誌後，才能寫入MemStore緩存。

此外，Pig和Hive還為HBase提供了高層語言支持，使得在HBase上進行數據統計處理變的非常簡單。 Sqoop則為HBase提供了方便的RDBMS數據導入功能，使得傳統資料庫數據向HBase中遷移變的非常方便。

注意：Hadoop 安裝完成之後，只包含HDFS和MapRece，並不含HBase，因此需要在Hadoop 之上繼續安裝HBase。

『伍』 資料庫的底層存儲機制

資料庫被放入底層庫，什麼是底層庫
低層庫只是一個相對的概念，
比如你寫了一個函數，傳入a,b返回他們相加的值
function
f(a,b){
return
a+b;
}
然後把這個函數放到一個文件裡面

『陸』 雲存儲架構分哪些層次,各自實現了什麼功能

(1)存儲層
雲存儲系統對外提供多種不同的存儲服務，各種服務的數據統一存放在雲存儲系統中，形成一個海量數據池。從大多數網路服務後台數據組織方式來看，傳統基於單伺服器的數據組織難以滿足廣域網多用戶條件下的吞吐性能和存儲容量需求；基於P2P架構的數據組織需要龐大的節點數量和復雜編碼演算法保證數據可靠性。相比而言，基於多存儲伺服器的數據組織方法能夠更好滿足在線存儲服務的應用需求，在用戶規模較大時，構建分布式數據中心能夠為不同地理區域的用戶提供更好的服務質量。
雲存儲的存儲層將不同類型的存儲設備互連起來，實現海量數據的統一管理，同時實現對存儲設備的集中管理、狀態監控以及容量的動態擴展，實質是一種面向服務的分布式存儲系統。
(2)基礎管理層
雲存儲系統架構中的基礎管理層為上層提供不同服務間公共管理的統一視圖。通過設計統一的用戶管理、安全管理、副本管理及策略管理等公共數據管理功能，將底層存儲與上層應用無縫銜接起來，實現多存儲設備之間的協同工作，以更好的性能對外提供多種服務。
(3)應用介面層
應用介面層是雲存儲平台中可以靈活擴展的、直接面向用戶的部分。根據用戶需求，可以開發出不同的應用介面，提供相應的服務。比如數據存儲服務、空間租賃服務、公共資源服務、多用戶數據共享服務、數據備份服務等。
(4)訪問層
通過訪問層，任何一個授權用戶都可以在任何地方，使用一台聯網的終端設備，按照標準的公用應用介面來登錄雲存儲平台，享受雲存儲服務。
2雲存儲技術的優勢
作為新興的存儲技術，與傳統的購買存儲設備和部署存儲軟體相比，雲存儲方式存在以下優點：
(1)成本低、見效快
傳統的購買存儲設備或軟體定製方式下，企業根據信息化管理的需求，一次性投入大量資金購置硬體設備、搭建平台。軟體開發則經過漫長的可行性分析、需求調研、軟體設計、編碼、測試這一過程。往往在軟體開發完成以後，業務需求發生變化，不得不對軟體進行返工，不僅影響質量，提高成本，更是延誤了企業信息化進程，同時造成了企業之間的低水平重復投資以及企業內部周期性、高成本的技術升級。在雲存儲方式下，企業除了配置必要的終端設備接收存儲服務外，不需要投入額外的資金來搭建平台。企業只需按用戶數分期租用服務，規避了一次性投資的風險，降低了使用成本，而且對於選定的服務，可以立即投入使用，既方便又快捷。
(2)易於管理
傳統方式下，企業需要配備專業的IT人員進行系統的維護，由此帶來技術和資金成本。雲存儲模式下，維護工作以及系統的更新升級都由雲存儲服務提供商完成，企業能夠以最低的成本享受到最新最專業的服務。
(3)方式靈活
傳統的購買和定製模式下，一旦完成資金的一次性投入，系統無法在後續使用中動態調整。隨著設備的更新換代，落後的硬體平台難以處置；隨著業務需求的不斷變化，軟體需要不斷地更新升級甚至重構來與之相適應，導致維護成本高昂，很容易發展到不可控的程度。而雲存儲方式一般按照客戶數、使用時間、服務項目進行收費。企業可以根據業務需求變化、人員增減、資金承受能力，隨時調整其租用服務方式，真正做到「按需使用」。
3雲存儲技術趨勢
隨著寬頻網路的發展，集群技術、網格技術和分布式文件系統的拓展，CDN內容分發、P2P、數據壓縮技術的廣泛運用，以及存儲虛擬化技術的完善，雲存儲在技術上已經趨於成熟，以「用戶創造內容」和「分享」為精神的Web2.0推動了全網域用戶對在線服務的認知

『柒』 hbase底層依賴什麼提供強大的計算能力

hbase依靠「HDFS」存儲底層數據。
HBase是Google Bigtable的開源實現，類似Google Bigtable利用GFS作為其文件存儲系統，HBase利用Hadoop HDFS作為其文件存儲系統；Google運行MapRece來處理Bigtable中的海量數據，HBase同樣利用Hadoop MapRece來處理HBase中的海量數據；Google Bigtable利用 Chubby作為協同服務，HBase利用Zookeeper作為對應。

『捌』 信息以文件形式存儲,文件用什麼分類分層存放

文件、塊和對象是三種以不同的方式來保存、整理和呈現數據的存儲格式。這些格式各有各的功能和限制。文件存儲會以文件和文件夾的層次結構來整理和呈現數據；塊存儲會將數據拆分到任意劃分且大小相同的卷中; 對象存儲會管理數據並將其鏈接至關聯的元數據。

塊存儲
塊存儲會將數據拆分成塊，並單獨存儲各個塊。每個數據塊都有一個唯一標識符，所以存儲系統能將較小的數據存放在最方便的位置。這意味著有些數據可以存儲在 linux 環境中，有些則可以存儲在 Windows 單元中。

塊存儲通常會被配置為將數據與用戶環境分離，並會將數據分布到可以更好地為其提供服務的多個環境中。然後，當用戶請求數據時，底層存儲軟體會重新組裝來自這些環境的數據塊，並將它們呈現給用戶。它通常會部署在存儲區域網路 (SAN) 環境中，而且必須綁定到正常運行的伺服器。

由於塊存儲不依賴於單條數據路徑（和文件存儲一樣），因此可以實現快速檢索。每個塊都獨立存在，且可進行分區，因此可以通過不同的操作系統進行訪問，這使得用戶可以完全自由地配置數據。它是一種高效可靠的數據存儲方式，且易於使用和管理。它適用於要執行大型事務的企業和部署了大型資料庫的企業。這意味著，需要存儲的數據越多，就越適合使用塊存儲。

塊存儲有一些缺點。塊存儲的成本高昂。它處理元數據的能力有限。

操作對象：磁碟

存儲協議：SCSI、iSCSI、FC

介面命令：以SCSI為例，主要有Read/Write/Read Capacity

存儲架構：DAS、SAN

文件存儲
文件存儲也稱為文件級存儲或基於文件的存儲，數據會以單條信息的形式存儲在文件夾中。當需要訪問該數據時，計算機需要知道相應的查找路徑。存儲在文件中的數據會根據元數據來進行整理和檢索，這些元數據會告訴計算機文件所在的確切位置。

請試想一下塞滿文件櫃的儲藏室。每個文檔都會按照某種類型的邏輯層次結構來排放 ——按文件櫃、抽屜、文件夾，然後再是紙張。「分層存儲」這個術語就是這么來的，而這就是文件存儲。它是適用於直接和網路附加存儲（NAS）系統的最古老且運用最為廣泛的一種數據存儲系統；當訪問保存在個人計算機上的文件中的文檔，就是在使用文件存儲。文件存儲具有豐富多樣的功能，幾乎可以存儲任何內容。它非常適合用來存儲一系列復雜文件，並且有助於用戶快速導航。

問題是基於文件的存儲系統必須通過添置更多系統來進行橫向擴展，而不是通過增添更多容量來進行縱向擴展。

操作對象：文件和文件夾

存儲協議：NFS、SAMBA（SMB）、POSIX

介面命令：以NFS為例，文件相關的介面命令包括：READ/WRITE/CREATE/REMOVE/RENAME/LOOKUP/ACCESS 等；文件夾相關的介面命令包括：MKDIR/RMDIR/READDIR 等

存儲架構：NAS （【Linux】NAS存儲_Jacky_Feng的博客-CSDN博客）
對象存儲
對象存儲，也稱為基於對象的存儲，是一種扁平結構，其中的文件被拆分成多個部分並散布在多個硬體間。在對象存儲中，數據會被分解為稱為「對象」的離散單元，並保存在單個存儲庫中，而不是作為文件夾中的文件或伺服器上的塊來保存。

對象存儲卷會作為模塊化單元來工作：每個卷都是一個自包含式存儲庫，均含有數據、允許在分布式系統上找到對象的唯一標識符以及描述數據的元數據。元數據包括年齡、隱私/安全信息和訪問突發事件等詳細信息。為了檢索數據，存儲操作系統會使用元數據和標識符，這樣可以更好地分配負載，並允許管理員應用策略來執行更強大的搜索。

對象存儲需要一個簡單的 HTTP 應用編程介面 (API)，以供大多數客戶端（各種語言）使用。對象存儲經濟高效：您只需為已用的內容付費。它可以輕松擴展，因而是公共雲存儲的理想之選。它是一個非常適用於靜態數據的存儲系統，其靈活性和扁平性意味著它可以通過擴展來存儲極大量的數據。對象具有足夠的信息供應用快速查找數據，並且擅長存儲非結構化數據。
它的缺點是無法修改對象 ，即必須一次性完整地寫入對象。對象存儲也不能很好地與傳統資料庫搭配使用，因為編寫對象是一個緩慢的過程，編寫應用以使用對象存儲 API 並不像使用文件存儲那麼簡單。

操作對象：對象（Object）

存儲協議：S3、Swift

介面命令：主要有PUT/GET/DELETE等

存儲架構：去中心化框架

對象存儲概念
對象存儲的數據組成

存儲桶（Bucket）：存放對象的「容器」，且該「容器」無容量上限。對象以扁平化結構存放在存儲桶中，無文件夾和目錄的概念，用戶可選擇將對象存放到單個或多個存儲桶中。存儲桶的容量大小需要通過累加各個對象的大小得到。

每個存儲桶可容納任意數量的對象，但同一個主賬號下存儲桶數量最多僅能夠創建200個。（？？？）

對於存儲桶，應當以用途為粒度進行劃分，確保每個存儲桶的用途盡可能單一。例如，針對存放個人文件、發布靜態網站、存儲備份等用途都應該創建不同的存儲桶。此外，不同項目的數據、不同的網站，或者完全私人的文件與工作性質、需要分享的文件，也應該劃分不同的存儲桶。

對象存儲中也沒有「文件夾」的概念。對象存儲的管理平台為了模仿本地存儲的使用習慣，並與本地存儲系統互相兼容而模擬了目錄結構，背後的原理也僅僅是根據 / 這個字元對 key 進行分隔。為了表示空目錄，部分雲平台也提供「文件夾」對象，實際上只是 key 以 / 結尾的空存儲對象。

存儲桶所在地域（Regin）

指對象存儲的數據中心所在地域。對象存儲允許用戶在不同地域創建存儲桶，可以選擇在離業務最近的地域上創建存儲桶，以滿足低延遲、低成本以及合規性要求。

Bucket讀寫許可權

Bucket讀寫許可權包括：私有讀寫、公有讀私有寫和公有讀寫。

私有讀寫
只有該存儲桶的創建者及有授權的賬號才對該存儲桶中的對象有讀寫許可權，其他任何人對該存儲桶中的對象都沒有讀寫許可權。存儲桶訪問許可權默認為私有讀寫，推薦使用。
公有讀私有寫
任何人（包括匿名訪問者）都對該存儲桶中的對象有讀許可權，但只有存儲桶創建者及有授權的賬號才對該存儲桶中的對象有寫許可權。
公有讀寫
任何人（包括匿名訪問者）都對該存儲桶中的對象有讀許可權和寫許可權，不推薦使用。
對象（Object）：對象存儲的基本單元，可理解為任何格式類型的數據，例如圖片、文檔和音視頻文件等。

每個對象都由對象鍵（Key）、對象值（Data）、和對象元數據（Metadata）組成。

對象鍵（Key）：對象鍵是對象在存儲桶中的全局唯一標識（UID），可以理解為文件（名）路徑。
key用於檢索對象，文件對象的 key 與實際存儲路徑無關，伺服器和用戶不需要知道數據的物理地址，通過key就能找到對象。

對象值（Data）：即存儲對象內容數據，可以理解為文件內容（Object Content）。
對象元數據（Metadata）：是一組鍵值對，可以通俗的理解為文件的屬性，例如文件的修改時間、存儲類型等。（傳統的文件存儲，元數據屬於文件本身，和文件一起封裝存儲。而對象存儲，元數據獨立出來，並不在數據內部封裝。）
對象訪問地址

對象的訪問地址由存儲桶訪問地址和對象鍵組成，其結構形式為<存儲桶域名>/<對象鍵> 。

例如：上傳對象exampleobject.txt到廣州（華南）的存儲桶examplebucket-1250000000中，那麼exampleobject.txt的訪問地址是：examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com/exampleobject.txt。其中examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com為存儲桶域名，exampleobject.txt為對象鍵。

目錄和文件夾

對象存儲中本身是沒有文件夾和目錄的概念的，對象存儲不會因為上傳對象project/a.txt而創建一個project文件夾。為了滿足用戶使用習慣，對象存儲在控制台、COS browser 等圖形化工具中模擬了「文件夾」或「目錄」的展示方式，具體實現是通過創建一個鍵值為project/，內容為空的對象，展示方式上模擬了傳統文件夾。

對象操作

用戶通過控制台、工具、API、SDK等多種方式管理對象。

對象存儲架構
對象存儲設備（OSD）
OSD由存儲介質、處理器、內存以及網路系統等組成，負責管理本地的對象，是對象存儲系統的核心。和塊設備相比，它們的差異在於提供的訪問介面。OSD的主要功能是數據存儲和安全訪問。

數據存儲：OSD管理對象數據，並將它們放置在標準的磁碟系統上，OSD不提供塊介面訪問方式，Client請求數據時用對象ID、偏移進行數據讀寫。

智能分布：OSD用其自身的CPU和內存優化數據分布，並支持數據的預取。由於OSD可以智能地支持對象的預取，從而可以優化磁碟的性能。

對象元數據管理：OSD管理存儲的對象元數據與傳統的inode元數據相似，通常包括對象的數據塊和對象的長度。而在傳統的NAS系統中，這些元數據是由文件伺服器維護的，對象存儲架構將系統中主要的元數據管理工作由OSD來完成，降低了Client的開銷。

元數據伺服器（MDS）
MDS控制Client與OSD對象的交互，為客戶端提供元數據，主要是文件的邏輯視圖（文件與目錄的組織關系、每個文件所對應的OSD等）。主要功能如下：

對象存儲訪問：MDS構造和管理描述每個文件分布的邏輯視圖，允許Client直接訪問對象。MDS為Client提供訪問該文件所含對象的能力，OSD在接收到每個請求時將先驗證該能力，然後才可以訪問。

文件和目錄訪問管理：MDS在存儲系統上構建一個文件結構，包括限額控制、目錄和文件的創建和刪除、訪問控制等。

Client Cache一致性：為了提高Client性能，在對象存儲系統設計時通常支持Client方的Cache。由於引入Client方的Cache，帶來了Cache一致性問題，MDS支持基於Client的文件Cache，當Cache的文件發生改變時，將通知Client刷新Cache，從而防止Cache不一致引發的問題。

客戶端（Client）
對象存儲系統提供給用戶的也是標準的POSIX文件訪問介面。介面具有和通用文件系統相同的訪問方式，同時為了提高性能，也具有對數據的Cache功能和文件的條帶功能。同時，文件系統必須維護不同客戶端上Cache的一致性，保證文件系統的數據一致。

文件系統讀訪問流程：

① 客戶端應用發出讀請求;

② 文件系統向元數據伺服器發送請求，獲取要讀取的數據所在的OSD;

③ 直接向每個OSD發送數據讀取請求；

④ OSD得到請求以後，判斷要讀取的Object，並根據此Object要求的認證方式，對客戶端進行認證，如果此客戶端得到授權，則將Object的數據返回給客戶端；

⑤ 文件系統收到OSD返回的數據以後，讀操作完成。

對象存儲的優缺點
（1）優點：

容量大，高擴展性
對象存儲的容量是EB級以上,對象存儲的所有業務、存儲節點採用分布式集群方式工作，各功能節點、集群都可以獨立擴容。從理論上來說，某個對象存儲系統或單個桶（bucket），並沒有總數據容量和對象數量的限制，即服務商就可以不停地往架構里增加資源，這個存儲空間就是無限的，也是支持彈性伸縮的。

高安全性，可靠性
對象存儲採用了分布式架構，對數據進行多設備冗餘存儲（至少三個以上節點），實現異地容災和資源隔離。數據訪問方面，所有的桶和對象都有訪問控制策略，所有連接都支持SSL加密，訪問用戶進行身份許可權鑒定。

高性能，支持海量用戶的並發訪問
（2）缺點：

不支持直接在存儲上修改
對象存儲系統保存的Object不支持修改（追加寫Object需要調用特定的介面，生成的Object也和正常上傳的Object類型上有差別）。用戶哪怕是僅僅需要修改一個位元組也需要重新上傳整個Object。因此，它不適合存儲需要頻繁擦寫的數據。

參考鏈接：

對象存儲，為什麼那麼火？ - 知乎 (hu.com)
對象存儲 存儲桶概述 - 開發者指南 - 文檔中心 - 騰訊雲 (tencent.com)
基本概念 (aliyun.com)
文件存儲、塊存儲還是對象存儲？ (redhat.com)
linux
駐馬店市民請關注領取補貼！
巨魔-抽手機公告
廣告

對比塊存儲、文件存儲、對象存儲
1242閱讀·0評論·3點贊
2019年2月27日
ShapeFile的文件格式設計
90閱讀·0評論·0點贊
2009年3月20日
應用ceph對象存儲(ceph-13.2.10)
72閱讀·0評論·0點贊
2022年11月26日
三種存儲類型比較-文件、塊、對象存儲
4.8W閱讀·0評論·13點贊
2016年7月26日
常見圖片存儲格式文件簡介
4534閱讀·0評論·0點贊
2020年5月4日
s3cmd常用命令
781閱讀·0評論·0點贊
2022年11月17日
駐馬店發布，你有一台5G手機待領取

00:23
巨摩互動
廣告
常見的存儲格式
1083閱讀·0評論·0點贊
2022年2月15日
文件、對象、塊區別
1399閱讀·0評論·0點贊
2020年7月13日
對象存儲、文件存儲、塊存儲的區別和聯系
7330閱讀·2評論·5點贊
2021年10月16日
數據分析中常見的存儲方式
1537閱讀·0評論·0點贊
2021年11月16日
三種存儲類型：塊存儲、文件存儲、對象存儲
1.5W閱讀·3評論·55點贊
2020年11月2日
如何設計二進制文件格式
1940閱讀·0評論·1點贊
2020年3月6日
BMP文件存儲格式
472閱讀·0評論·2點贊
2021年8月2日
hive 的存儲格式
1765閱讀·0評論·1點贊
2022年6月18日
數據存儲格式
446閱讀·0評論·0點贊
2022年12月21日
總結：對象存儲、塊存儲、文件存儲的區別
6606閱讀·0評論·3點贊
2022年4月9日
c語言中文件rw,什麼是「塊文件」？
386閱讀·0評論·0點贊
2021年5月23日
【存儲】塊存儲、文件存儲和對象存儲的區別？
350閱讀·0評論·0點贊
2022年7月22日
塊存儲、文件存儲與對象存儲的區別與應用場景
1846閱讀·1評論·0點贊
2022年6月5日
數據在內存中的存儲方式
272閱讀·0評論·0點贊
2022年8月21日
去首頁
看看更多熱門內容

『玖』 對象存儲系統底層基於什麼系統來存取數據

記得在一篇介紹對象存儲的文章開頭這樣寫道「那些沒有為資料庫或文件系統寫過代碼的上了年紀的程序員應該不太可能會讀這篇文章。畢竟，一般商業應用程序訪問其他數據類型的模式已經存在超過 40年了。」 言下之意，對象存儲代表了新時代下的新型數據結構類型，但是對象存儲的出現也與存儲發展的歷史密不可分。在Web2.0、雲和數字內容爆發的時代，類似數字視頻和移動網路之類事物的增長，產生了極大量的非結構化數據。存儲廠商也推出了新的基於對象的存儲系統，從而來提供更加簡單的管理和具有更佳擴展性的元數據格式。相比傳統存儲，對象存儲的關鍵優勢在於其簡單性。由於對象存儲不依賴於LUNs和卷，因此新的存儲容量可以通過簡單配置加入到運行系統中，實現橫向擴展( scale-out)。 對象存儲與Hadoop 雲存儲 目前，對象存儲的規模部署則由雲服務所引領，如亞馬遜 S3、Facebook。現在，無論成熟廠商還是新興廠商的對象存儲解決方案都已達到相當的成熟度，因而IT部門開始考慮如何在自己企業中實現對象存儲。除了面向對象的存儲，還有基於Hadoop的雲存儲。中國惠普雲計算事業部高級產品經理呂洪在近期的視頻訪談中提到：「對於那些要求訪問控制的應用，對象存儲系統是個不錯的選擇，而用雲進行大數據分析的則要考慮Hadoop。」 對象存儲系統可以在一個持久穩固且高度可用的系統中存儲任意的對象，且獨立於虛擬機實例之外。應用和用戶可以在對象存儲中使用簡單的API訪問數據;這些通常都基於REST架構，但是也有面向編程語言的界面。 同時，需要在雲端進行大數據分析的用戶則可以考慮Hadoop雲存儲，比如AWS提供了彈性Map Rece (EMR)。雲存儲選擇適用於廣泛的需求，但是要針對你的需求找到正確的存儲類型，也意味著要找到延遲、易用性、數據完整性和成本之間的合適的平衡點。 對象存儲數據遷移和訪問 企業對存儲的訴求有一定的延續性，但其訪問的介質不外乎是主機、PC、移動端以及應用，針對不同的訪問介質來看，面向對象存儲的解決方案也有所不同。比如微信，我們可以在微信中上傳和訪問照片、視頻等內容，這是一種面向對象數據的訪問和存儲方式;然而如果應用軟體不支持HTTP下REST API的方式，需要以傳統文件伺服器協議的方式訪問，則需要在面向存儲對象前面加一個網關進行協議的轉換。 沒有了文件存儲系統中的NFS或CIFS來給應用提供數據，面向對象的存儲系統需要替換掉位於磁碟上的原始數據塊和應用可以理解的文件之間的這個抽象層。現在的面向對象的系統使用類似REST標準的API或者私有的API來告訴應用如何存儲和讀取對象標識。 總體而言，對於面向對象的存儲的操作的本質並不會改變。呂洪介紹：「比如我們熟悉的開源對象存儲系統OpenStack Swift。基本上就是POST，GET ，PUT和 DELETE操作，如果你需要上傳大量的數據，則需要編寫一個腳本就可以實現。」 惠普的對象存儲創新 OpenStack Swift是一種開源的對象存儲系統，以一種既滿足了存儲數據服務等級要求且經濟的方式實現。從高可用性以及安全穩定的角度上看，目前開源Swift並不如傳統廠商做的好，但是卻可以通過標準的伺服器，集合Swift搭建出一個能用且經濟的方案。 但是傳統廠商有自己的優勢，從對象存儲的設計結構來看分為三層，底層硬體基礎架構用來承載數據，在此之上則是面向對象的管理軟體，也就是系統層，最頂層為介面層，也就是用戶通過何種方式來存取數據。呂洪表示：「在這三個層次上面惠普的解決方案都有涉及。」 眾所周知，惠普一直以來都在基於OpenStack進行持續研發，推出更加符合企業級用戶要求的解決方案。此外，惠普實驗室中也在基於ProLiant x86伺服器，力求為swift尋找到一種更經濟的承載方式。惠普基於OpenStack Swift構建的Helion Content Depot則是第一款集成化的完整對象存儲解決方案，針對橫向擴展的對象存儲，提供當今企業存儲系統所需的高度可擴展性、易管理性、恢復能力和安全性。 呂洪提到：「預期不久的將來，惠普則會正式推出專門針對大數據的面相對象存儲的伺服器阿波羅4510。」據了解，阿波羅4510的一個機櫃中可以提供5.4PB的容量，這是在目前整個行業中，單機櫃容量最大的存儲解決方案。 除此之外，惠普還提供了面相對象存儲的數據加密工作，一部分確保用戶的數據在傳輸過程中是加密的，另一方面也首創硬體的加密，確保對象存儲數據的安全性。

『拾』 Git底層數據結構和原理之三：存儲模型

git 區別與其他 vcs 系統的一個最主要原因之一是：git 對文件版本管理和其他 vcs 系統對文件版本的實現理念完成不一樣。這也就是 git 版本管理為什麼如此強大的最核心的地方。

SVN 等其他的 VCS 對文件版本的理念是以文件為水平維度，記錄每個文件在每個版本下的 delta 改變。
Git 對文件版本的管理理念卻是以每次提交為一次快照，提交時對所有文件做一次全量快照，然後存儲快照引用。

Git 在存儲層，如果文件數據沒有改變的文件，Git 只是存儲指向源文件的一個引用，並不會直接多次存儲文件，這一點可以在 pack 文件中看見。如下圖所示：

存儲隨著需求和功能的不斷復雜，git 版本的不斷更新，但是主要的存儲模型還是大致不變。如下圖所示：