⑴ Hadoop分布式存儲
為了降低整體的帶寬消耗和讀取延時，HDFS會盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個機架上有一個副本，那麼就讀取該副本。如果一個HDFS集群跨越多個數據中心，那麼客戶端也將首先讀本地數據中心的副本
Namenode啟動後會進入一個稱為安全模式的特殊狀態。處於安全模式的Namenode是不會進行數據塊的復制的。Namenode從所有的 Datanode接收心跳信號和塊狀態報告。塊狀態報告包括了某個Datanode所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當Namenode檢測確認某個數據塊的副本數目達到這個最小值，那麼該數據塊就會被認為是副本安全(safely replicated)的；在一定百分比（這個參數可配置）的數據塊被Namenode檢測確認是安全之後（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒有達到指定數目，並將這些數據塊復制到其他Datanode上
所有的HDFS通訊協議都是建立在TCP/IP協議之上。客戶端通過一個可配置的TCP埠連接到Namenode，通過ClientProtocol協議與Namenode交互。而Datanode使用DatanodeProtocol協議與Namenode交互。一個遠程過程調用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協議。在設計上，Namenode不會主動發起RPC，而是響應來自客戶端或 Datanode 的RPC請求
⑵ 基於mogileFS搭建分布式文件系統--海量小文件的存儲利器
1.簡介
分布式文件系統（Distributed File System）是指文件系統管理的物理存儲資源不一定直接連接在本地節點上，而是通過計算機網路與節點相連。分布式文件系統的設計基於客戶機/伺服器模式。一個典型的網路可能包括多個供多用戶訪問的伺服器。另外，對等特性允許一些系統扮演客戶機和伺服器的雙重角色。例如，用戶可以「發表」一個允許其他客戶機訪問的目錄，一旦被訪問，這個目錄對客戶機來說就像使用本地驅動器一樣。
當下我們處在一個互聯網飛速發展的信息 社會 ，在海量並發連接的驅動下每天所產生的數據量必然以幾何方式增長，隨著信息連接方式日益多樣化，數據存儲的結構也隨著發生了變化。在這樣的壓力下使得人們不得不重新審視大量數據的存儲所帶來的挑戰，例如：數據採集、數據存儲、數據搜索、數據共享、數據傳輸、數據分析、數據可視化等一系列問題。
傳統存儲在面對海量數據存儲表現出的力不從心已經是不爭的事實，例如：縱向擴展受陣列空間限制、橫向擴展受交換設備限制、節點受文件系統限制。
然而分布式存儲的出現在一定程度上有效的緩解了這一問題，之所以稱之為緩解是因為分布式存儲在面對海量數據存儲時也並非十全十美毫無壓力，依然存在的難點與挑戰例如：節點間通信、數據存儲、數據空間平衡、容錯、文件系統支持等一系列問題仍處在不斷摸索和完善中。
2.分布式文件系統的一些解決方案
Google Filesystem適合存儲海量大個文件，元數據存儲與內存中
HDFS（Hadoop Filesystem）GFS的山寨版，適合存儲大量大個文件
TFS（Taobao Filesystem）淘寶的文件系統，在名稱節點上將元數據存儲與關系資料庫中，文件數量不在受限於名稱節點的內容空間，可以存儲海量小文件LustreOracle開發的企業級分布式系統，較重量級MooseFS基於FUSE的格式，可以進行掛載使用MogileFS
擅長存儲海量的小數據，元數據存儲與關系型資料庫中
1.簡介
MogileFS是一個開源的分布式文件系統，用於組建分布式文件集群，由LiveJournal旗下DangaInteractive公司開發，Danga團隊開發了包括 Memcached、MogileFS、Perlbal等不錯的開源項目：(註：Perlbal是一個強大的Perl寫的反向代理伺服器)。MogileFS是一個開源的分布式文件系統。
目前使用 MogileFS 的公司非常多,比如國外的一些公司,日本前幾名的公司基本都在使用這個.
國內所知道的使用 MogileFS 的公司有圖片託管網站 yupoo又拍,digg, 土豆, 豆瓣,1 號店, 大眾點評,搜狗,安居客等等網站.基本很多網站容量，圖片都超過 30T 以上。
2.MogileFS特性
1) 應用層提供服務，不需要使用核心組件
2）無單點失敗，主要有三個組件組成，分為tracker（跟蹤節點）、mogstore（存儲節點）、database（資料庫節點）
3）自動復制文件，復制文件的最小單位不是文件，而是class
4）傳輸中立，無特殊協議，可以通過NFS或HTTP實現通信
5）簡單的命名空間：沒有目錄，直接存在與存儲空間上，通過域來實現
6）不用共享任何數據
3.MogileFS的組成
1）Tracker--跟蹤器，調度器
MogileFS的核心，是一個調度器，mogilefsd進程就是trackers進程程序,trackers的主要職責有：刪除數據、復制數據、監控、查詢等等.這個是基於事件的( event-based ) 父進程/消息匯流排來管理所有來之於客戶端應用的交互(requesting operations to be performed), 包括將請求負載平衡到多個"query workers"中,然後讓 mogilefs的子進程去處理.
mogadm,mogtool的所有操作都要跟trackers打交道,Client的一些操作也需要定義好trackers,因此最好同時運行多個trackers來做負載均衡.trackers也可以只運行在一台機器上，使用負載均衡時可以使用搞一些簡單的負載均衡解決方案，如haproxy，lvs，nginx等，
tarcker的配置文件為/etc/mogilefs/mogilefsd.conf，監聽在TCP的7001埠
2）Database--資料庫部分
主要用來存儲mogilefs的元數據，所有的元數據都存儲在資料庫中，因此，這個數據相當重要，如果資料庫掛掉，所有的數據都不能用於訪問，因此，建議應該對資料庫做高可用
3）mogstored--存儲節點
數據存儲的位置，通常是一個HTTP（webDAV）伺服器，用來做數據的創建、刪除、獲取，任何 WebDAV 伺服器都可以, 不過推薦使用 mogstored . mogilefsd可以配置到兩個機器上使用不同埠… mogstored 來進行所有的 DAV 操作和流量,IO監測, 並且你自己選擇的HTTP伺服器(默認為 perlbal)用來做 GET 操作給客戶端提供文件.
典型的應用是一個掛載點有一個大容量的SATA磁碟. 只要配置完配置文件後mogstored程序的啟動將會使本機成為一個存儲節點.當然還需要mogadm這個工具增加這台機器到Cluster中.
配置文件為/etc/mogilefs/mogstored.conf，監聽在TCP的7500埠
4.基本工作流程
應用程序請求打開一個文件 (通過RPC 通知到 tracker, 找到一個可用的機器). 做一個 「create_open」 請求.
tracker 做一些負載均衡(load balancing)處理，決定應該去哪兒，然後給應用程序一些可能用的位置。
應用程序寫到其中的一個位置去 (如果寫失敗，他會重新嘗試並寫到另外一個位置去）.
應用程序 (client) 通過」create_close」 告訴tracker文件寫到哪裡去了.
tracker 將該名稱和域命的名空間關聯 (通過資料庫來做的)
tracker, 在後台, 開始復制文件，知道他滿足該文件類別設定的復制規則
然後,應用程序通過 「get_paths」 請求 domain+key (key == 「filename」) 文件, tracker基於每一位置的I/O繁忙情況回復(在內部經過 database/memcache/etc 等的一些抉擇處理), 該文件可用的完整 URLs地址列表.
應用程序然後按順序嘗試這些URL地址. (tracker』持續監測主機和設備的狀態，因此不會返回死連接,默認情況下他對返回列表中的第一個元素做雙重檢查，除非你不要他這么做..)
1.拓撲圖
說明：1.用戶通過URL訪問前端的nginx
2.nginx根據特定的挑選演算法，挑選出後端一台tracker來響應nginx請求
3.tracker通過查找database資料庫，獲取到要訪問的URL的值，並返回給nginx
4.nginx通過返回的值及某種挑選演算法挑選一台mogstored發起請求
5.mogstored將結果返回給nginx
6.nginx構建響應報文返回給客戶端
2.ip規劃
角色運行軟體ip地址反向代理nginx192.168.1.201存儲節點與調度節點1
mogilefs192.168.1.202存儲節點與調度節點2
mogilefs192.168.1.203資料庫節點
MariaDB192.168.1.204
3.資料庫的安裝操作並為授權
關於資料庫的編譯安裝，請參照本人相關博文http://wangfeng7399.blog.51cto.com/3518031/1393146，本處將不再累贅，本處使用的為yum源的安裝方式安裝mysql
4.安裝mogilefs. 安裝mogilefs，可以使用yum安裝，也可以使用編譯安裝，本處通過yum安裝
5.初始化資料庫
可以看到在資料庫中創建了一些表
6.修改配置文件，啟動服務
7.配置mogilefs
添加存儲主機
添加存儲設備
添加域
添加class
8.配置192.168.1.203的mogilefs 。切記不要初始化資料庫，配置應該與192.168.1.202一樣
9.嘗試上傳數據，獲取數據，客戶端讀取數據
上傳數據，在任何一個節點上傳都可以
獲取數據
客戶端查看數據
我們可以通過任何一個節點查看到數據
要想nginx能夠實現對後端trucker的反向代理，必須結合第三方模塊來實現
1.編譯安裝nginx
2.准備啟動腳本
3.nginx與mofilefs互聯
查看效果
5.配置後端truckers的集群
查看效果
大功告成了，後續思路，前段的nginx和資料庫都存在單點故障，可以實現高可用集群
⑶ 華為突破分布式資料庫和存儲技術，打通數字化轉型「雄關漫道」
2019年，我們將進入數字化轉型的攻關期。所謂「攻關期」即數字化轉型2.0階段，需要攻堅企業關鍵業務上雲和數字化轉型改造的課題。在一份市場調查公司IDC的報告中指出：IDC自2014年提出數字化轉型以來，看到企業在數字化轉型層面已經投入了大量人力物力，但是效果並不理想，有一些企業已經成功屹立在潮頭，有一些企業在向上游進發，還有一些企業只能在浪潮的挾裹中被動前行。
對於企業來說，數字化轉型是「雄關漫道」。IDC認為，目前階段來看，企業亟待解決的是數字化能力提升，包括：與業務的深入結合能力；數據處理和挖掘能力；以及IT技術運營和管理能力。特別是數據處理和挖掘能力，因為數字化轉型推進企業從以流程為核心向以數據為核心轉型，對海量、異構、多類型的數據處理和挖掘能力是釋放數據價值的前提，對數據全生命周期的管控治理是釋放數據價值的保障。而隨著數字化轉型引入大量新技術而導致IT復雜度變高，企業IT技術運營和管理能力是提升企業「IT生產力」的關鍵。
攻關數字化轉型的「雄關漫道」，需要一個具備融合、智能、可傳承三大特性的數字平台。這是2019年3月華為與IDC聯合推出的《擁抱變化，智勝未來—數字平台破局企業數字化轉型》白皮書所提出的觀點。融合主要指把傳統技術和創新技術相結合；智能主要指平台智能化和智能化能力輸出；可傳承主要指解耦、功能復用、可配置等理念打造的架構。而承載這三大觀點的，就是新一代分布式企業級技術。
2019年5月15日，華為發布了業界首款支持ARM架構的新一代智能分布式資料庫GaussDB以及分布式存儲FusionStorage 8.0，作為新一代數據基礎設施，詮釋了具備融合、智能、可傳承三大特性的數字平台。華為常務董事、ICT戰略與Marketing總裁汪濤在發布會上表示，千行百業正在加速智能化進程，越來越多的企業已經意識到數據基礎設施是智能化成功的關鍵。華為圍繞計算、存儲和數據處理三個領域重定義數據基礎設施，加速邁向智能時代。
今天所討論雲和工業互聯網等概念的背後是一個新時代的到來，這就是體系架構大遷徙。傳統企業級技術是在單體應用和單機環境中，保證數據存儲、調用等操作的高可靠、高可用、高穩定，特別是滿足金融級事物處理的ACID（原子性、一致性、隔離性和耐久性）要求，為企業關鍵業務提供數據管理支撐。隨著企業技術向雲架構遷移，資料庫技術也面臨轉型。
2018年，基於雲計算技術的分布式資料庫成為了業界的熱點。簡單理解，雲計算技術就是把「單機」環境替換為由X86伺服器機群所組成的分布式計算環境。原先由幾台小型機完成的計算任務，要分散到上百甚至上千台X86伺服器上，而且還可能跨數據中心操作，挑戰可想而之。特別是在線支付等金融級業務，不能在斷網或網路連接有問題時出錯，也不能因響應速度慢而影響用戶體驗。
2018年8月，中國支付清算協會與中國信息通信研究院聯合舉辦了「金融分布式事務資料庫研討會」，與業界廠商和用戶共商核心資料庫分布式轉型之路，同時發布了《金融分布式事務資料庫》白皮書。金融分布式事務資料庫的工作推進，為分布式資料庫進入企業關鍵業務系統，提供了產業化支撐。而華為作為企業ICT解決方案供應商，早在2012年就開始研發面向大數據分析的數據倉庫，在基於傳統關系型資料庫SQL引擎和事務強一致性等基礎上，進行了分布式、並行計算的改造，歷時6年打造了面向PB級海量數據分析的分布式資料庫。
在OLAP數據倉庫之外，華為與行業用戶合作了面向OLTP的分布式事務型資料庫研發。2017年，華為與招商銀行合作成立了分布式資料庫聯合創新實驗室，研發具有高性能企業級內核、完整支持分布式事物、滿足金融行業對數據強一致要求、單機事物處理能力要達到每分鍾百萬級別等的OLTP分布式資料庫。
本次發布的GaussDB資料庫新品包括：聯機事務處理OLTP資料庫、聯機分析處理OLAP資料庫、事務和分析混合處理HTAP資料庫。而華為GaussDB資料庫將AI技術融入資料庫設計、開發、驗證、調優、運維等環節，可實現基於AI的自調優、自診斷自愈、自運維，讓資料庫更高效、更智能，引領資料庫架構的發展。
更進一步，本次發布的GaussDB系列資料庫是業界首款支持ARM晶元的分布式資料庫。華為推動計算架構從以X86+GPU為主的單一計算架構到以X86+GPU+ARM64+NPU為主的異構計算架構快速發展。基於X86架構，華為引入AI管理和智能加速能力，率先推出了智能伺服器FusionServer Pro；基於ARM64打造了業界性能最強的TaiShan伺服器；基於Ascend晶元的Atlas智能計算，實現了業界首個端邊雲協同的人工智慧平台。而GaussDB可充分利用並融合ARM、X86、GPU、NPU等多種異構算力組合，大幅提升資料庫性能。
汪濤強調，作為全球首款AI-Native資料庫，GaussDB有兩大革命性突破：第一，首次將人工智慧技術引入資料庫的全生命周期流程，實現自運維、自管理、自調優和故障自診斷。在交易、分析和混合負載場景下，基於最優化理論，首創深度強化學習自調優演算法，把業界平均性能提升60%。第二，支持異構計算，充分發揮X86/ARM/GPU/NPU多樣性算力優勢，最大化資料庫性能，在權威標准測試集TPC-DS上，華為GaussDB排名第一。GaussDB還支持本地部署、私有雲、公有雲等多種場景。
在以雲計算為代表的分布式計算環境中，數據管理解決方案除了需要分布式資料庫外，為了更好的擴縮容以及滿足多樣化數據存儲需求，計算與存儲分離已經成為分布式資料庫設計的主要架構。分布式雲化架構，就是要支持計算、存儲分離和多租戶等架構設計要求。
GaussDB已經從資料庫層面實現了高可用、高可靠、高穩定的分布式資料庫，本次發布的FusionStorage 8.0則是分布式存儲架構，創新地實現一套系統同時支持塊、文件、對象、HDFS協議，1套存儲支持4類存儲能力，適用於全業務場景混合負載，最終讓「一個數據中心一套存儲」成為可能。
IDC發布的《中國軟體定義存儲（SDS）及超融合存儲（HCI）系統市場季度跟蹤報告，2018年第四季度》顯示，2018年，軟體定義存儲市場達到了54.9%的同比增長。軟體定義存儲在中國整體存儲市場的佔有率穩步上升，分別達到了22.1%的市場佔有率。華為憑借文件解決方案在政府、廣電和電信等行業得到認可，在2018年中國軟體定義存儲市場排名第一。
FusionStorage 8.0採用華為ARM-based處理器鯤鵬920加速，使IOPS提升 20%，結合華為AI Fabric無損網路，時延進一步降低15%。基於華為在計算、網路和存儲領域多年的晶元和演算法積累，FusionStorage 8.0在SPC-1的性能測試中，單節點性能達到了16.8萬IOPS以及1ms以內時延，成為承載企業關鍵應用的新選擇。
此外，通過華為雲的雲上訓練及本地AI晶元，FusionStorage 8.0將智能管理貫穿業務使用的全生命周期，如業務上線前對存儲資源的規劃，使用過程中的風險預判及故障定位，大幅提升存儲效率，幫助行業客戶應對智能時代的數據新挑戰。
汪濤在發布會上強調，新一代智能分布式存儲FusionStorage 8.0通過重定義存儲架構，從「Storage for AI」和「AI in Storage」兩個維度實現效率大幅提升，引領存儲智能化。首先，「Storage for AI」通過融合共享，讓AI分析更高效。其次，「AI in Storage」率先將AI融入存儲全生命周期管理，從資源規劃、業務發放、系統調優、風險預測、故障定位等方面實現智能運維。
遼寧移動就採用了華為FusionStorage。作為遼寧省內最大的移動通信運營商，遼寧移動一直在 探索 先進的存儲方案在自身IT系統的應用。由於5G的快速發展，遼寧移動關鍵資料庫的應用也向雲化方向發展，分布式存儲也要滿足其可靠性和高性能要求。華為在深入分析遼寧移動需求後，首先在邊緣開發測試業務小規模試點分布式存儲，進行了大量的實驗和測試後性能和可靠性都達到了預期，最終決定將全部業務遷移至FusionStorage。該方案通過採用雙活、可寫快照、端到端DIF等特性，順利完成Billing、經營分析、B2B等系統從老舊存儲至FusionStorage的搬遷工作，助力遼寧移動的存儲架構邁入新的 歷史 階段。
值得一提的是，華為分布式資料庫與華為分布式存儲深度結合，把資料庫的操作下沉到存儲節點，極大提升了分布式資料庫的性能。利用新的網路技術和人工智慧技術，華為幫助用戶提升數據中心的吞吐量，提升網路應用的可伸縮性，並且能自動調優。
除了推出新一代突破性的分布式資料庫和存儲技術外，華為也積極與客戶、夥伴在資料庫與存儲領域，從行業應用、平台工具、標准組織和社區等多個層面共建開放、合作、共贏的產業生態。在行業應用層面，華為與軟通智慧、神州信息、東華軟體、易華錄、用友政務、亞信國際等獨立軟體開發商長期合作；在平台和工具層面，華為與Tableau、帆軟、ARM、Veritas等合作夥伴聯合創新；在標准組織和社區層面，華為深度參與OpenSDS、中國人工智慧產業聯盟、OCP、OpenStack、CNCF基金會等組織和社區的建設。
總結來說，華為全線分布式資料庫和分布式存儲產品的發布，是華為具備融合、智能、可傳承三大特性數字平台的最新成果。華為分布式資料庫與分布式存儲結合，能消除企業各業務系統數據孤島，構建面向行業場景的數據建模、分析和價值挖掘能力，對多源異構的數據進行匯聚、整合和分析，形成統一的全量數據和數據底座，實現數據價值挖掘和共享。而基於AI的智能化，可對基礎設施進行高效的管理，為行業應用開發和迭代賦能，全面幫助企業突破關鍵應用上雲的「雄關漫道」。（文/寧川）
⑷ 分布式存儲是什麼東西
關於分布式存儲實際上並沒有一個明確的定義，甚至名稱上也沒有一個統一的說法，大多數情況下稱作 Distributed Data Store 或者 Distributed Storage System。
其中維基網路中給 Distributed data store 的定義是：分布式存儲是一種計算機網路，它通常以數據復制的方式將信息存儲在多個節點中。
在網路中給出的定義是：分布式存儲系統，是將數據分散存儲在多台獨立的設備上。分布式網路存儲系統採用可擴展的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲信息，它不但提高了系統的可靠性、可用性和存取效率，還易於擴展。
盡管各方對分布式存儲的定義並不完全相同，但有一點是統一的，就是分布式存儲將數據分散放置在多個節點中，節點通過網路互連提供存儲服務。這一點與傳統集中式存儲將數據集中放置的方式有著明顯的區分。
⑸ 如何實現企業數據 大數據平台 分布式存放
Hadoop在可伸縮性、健壯性、計算性能和成本上具有無可替代的優勢，事實上已成為當前互聯網企業主流的大數據分析平台。本文主要介紹一種基於Hadoop平台的多維分析和數據挖掘平台架構。作為一家互聯網數據分析公司，我們在海量數據的分析領域那真是被「逼上樑山」。多年來在嚴苛的業務需求和數據壓力下，我們幾乎嘗試了所有可能的大數據分析方法，最終落地於Hadoop平台之上。
1. 大數據分析大分類
Hadoop平台對業務的針對性較強，為了讓你明確它是否符合你的業務，現粗略地從幾個角度將大數據分析的業務需求分類，針對不同的具體需求，應採用不同的數據分析架構。
按照數據分析的實時性，分為實時數據分析和離線數據分析兩種。
實時數據分析一般用於金融、移動和互聯網B2C等產品，往往要求在數秒內返回上億行數據的分析，從而達到不影響用戶體驗的目的。要滿足這樣的需求，可以採用精心設計的傳統關系型資料庫組成並行處理集群，或者採用一些內存計算平台，或者採用HDD的架構，這些無疑都需要比較高的軟硬體成本。目前比較新的海量數據實時分析工具有EMC的Greenplum、SAP的HANA等。
對於大多數反饋時間要求不是那麼嚴苛的應用，比如離線統計分析、機器學習、搜索引擎的反向索引計算、推薦引擎的計算等，應採用離線分析的方式，通過數據採集工具將日誌數據導入專用的分析平台。但面對海量數據，傳統的ETL工具往往徹底失效，主要原因是數據格式轉換的開銷太大，在性能上無法滿足海量數據的採集需求。互聯網企業的海量數據採集工具，有Facebook開源的Scribe、LinkedIn開源的Kafka、淘寶開源的Timetunnel、Hadoop的Chukwa等，均可以滿足每秒數百MB的日誌數據採集和傳輸需求，並將這些數據上載到Hadoop中央系統上。
按照大數據的數據量，分為內存級別、BI級別、海量級別三種。
這里的內存級別指的是數據量不超過集群的內存最大值。不要小看今天內存的容量，Facebook緩存在內存的Memcached中的數據高達320TB，而目前的PC伺服器，內存也可以超過百GB。因此可以採用一些內存資料庫，將熱點數據常駐內存之中，從而取得非常快速的分析能力，非常適合實時分析業務。圖1是一種實際可行的MongoDB分析架構。
圖1 用於實時分析的MongoDB架構
MongoDB大集群目前存在一些穩定性問題，會發生周期性的寫堵塞和主從同步失效，但仍不失為一種潛力十足的可以用於高速數據分析的NoSQL。
此外，目前大多數服務廠商都已經推出了帶4GB以上SSD的解決方案，利用內存+SSD，也可以輕易達到內存分析的性能。隨著SSD的發展，內存數據分析必然能得到更加廣泛的應用。
BI級別指的是那些對於內存來說太大的數據量，但一般可以將其放入傳統的BI產品和專門設計的BI資料庫之中進行分析。目前主流的BI產品都有支持TB級以上的數據分析方案。種類繁多，就不具體列舉了。
海量級別指的是對於資料庫和BI產品已經完全失效或者成本過高的數據量。海量數據級別的優秀企業級產品也有很多，但基於軟硬體的成本原因，目前大多數互聯網企業採用Hadoop的HDFS分布式文件系統來存儲數據，並使用MapRece進行分析。本文稍後將主要介紹Hadoop上基於MapRece的一個多維數據分析平台。
數據分析的演算法復雜度
根據不同的業務需求，數據分析的演算法也差異巨大，而數據分析的演算法復雜度和架構是緊密關聯的。舉個例子，Redis是一個性能非常高的內存Key-Value NoSQL，它支持List和Set、SortedSet等簡單集合，如果你的數據分析需求簡單地通過排序，鏈表就可以解決，同時總的數據量不大於內存（准確地說是內存加上虛擬內存再除以2），那麼無疑使用Redis會達到非常驚人的分析性能。
還有很多易並行問題（Embarrassingly Parallel），計算可以分解成完全獨立的部分，或者很簡單地就能改造出分布式演算法，比如大規模臉部識別、圖形渲染等，這樣的問題自然是使用並行處理集群比較適合。
而大多數統計分析，機器學習問題可以用MapRece演算法改寫。MapRece目前最擅長的計算領域有流量統計、推薦引擎、趨勢分析、用戶行為分析、數據挖掘分類器、分布式索引等。
2. 面對大數據OLAP大一些問題
OLAP分析需要進行大量的數據分組和表間關聯，而這些顯然不是NoSQL和傳統資料庫的強項，往往必須使用特定的針對BI優化的資料庫。比如絕大多數針對BI優化的資料庫採用了列存儲或混合存儲、壓縮、延遲載入、對存儲數據塊的預統計、分片索引等技術。
Hadoop平台上的OLAP分析，同樣存在這個問題，Facebook針對Hive開發的RCFile數據格式，就是採用了上述的一些優化技術，從而達到了較好的數據分析性能。如圖2所示。
然而，對於Hadoop平台來說，單單通過使用Hive模仿出SQL，對於數據分析來說遠遠不夠，首先Hive雖然將HiveQL翻譯MapRece的時候進行了優化，但依然效率低下。多維分析時依然要做事實表和維度表的關聯，維度一多性能必然大幅下降。其次，RCFile的行列混合存儲模式，事實上限制死了數據格式，也就是說數據格式是針對特定分析預先設計好的，一旦分析的業務模型有所改動，海量數據轉換格式的代價是極其巨大的。最後，HiveQL對OLAP業務分析人員依然是非常不友善的，維度和度量才是直接針對業務人員的分析語言。
而且目前OLAP存在的最大問題是：業務靈活多變，必然導致業務模型隨之經常發生變化，而業務維度和度量一旦發生變化，技術人員需要把整個Cube（多維立方體）重新定義並重新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系統成為死板的日常報表系統。
使用Hadoop進行多維分析，首先能解決上述維度難以改變的問題，利用Hadoop中數據非結構化的特徵，採集來的數據本身就是包含大量冗餘信息的。同時也可以將大量冗餘的維度信息整合到事實表中，這樣可以在冗餘維度下靈活地改變問題分析的角度。其次利用Hadoop MapRece強大的並行化處理能力，無論OLAP分析中的維度增加多少，開銷並不顯著增長。換言之，Hadoop可以支持一個巨大無比的Cube，包含了無數你想到或者想不到的維度，而且每次多維分析，都可以支持成千上百個維度，並不會顯著影響分析的性能。
而且目前OLAP存在的最大問題是：業務靈活多變，必然導致業務模型隨之經常發生變化，而業務維度和度量一旦發生變化，技術人員需要把整個Cube（多維立方體）重新定義並重新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系統成為死板的日常報表系統。
3. 一種Hadoop多維分析平台的架構
整個架構由四大部分組成：數據採集模塊、數據冗餘模塊、維度定義模塊、並行分 析模塊。
數據採集模塊採用了Cloudera的Flume，將海量的小日誌文件進行高速傳輸和合並，並能夠確保數據的傳輸安全性。單個collector宕機之後，數據也不會丟失，並能將agent數據自動轉移到其他的colllecter處理，不會影響整個採集系統的運行。如圖5所示。
數據冗餘模塊不是必須的，但如果日誌數據中沒有足夠的維度信息，或者需要比較頻繁地增加維度，則需要定義數據冗餘模塊。通過冗餘維度定義器定義需要冗餘的維度信息和來源（資料庫、文件、內存等），並指定擴展方式，將信息寫入數據日誌中。在海量數據下，數據冗餘模塊往往成為整個系統的瓶頸，建議使用一些比較快的內存NoSQL來冗餘原始數據，並採用盡可能多的節點進行並行冗餘；或者也完全可以在Hadoop中執行批量Map，進行數據格式的轉化。
維度定義模塊是面向業務用戶的前端模塊，用戶通過可視化的定義器從數據日誌中定義維度和度量，並能自動生成一種多維分析語言，同時可以使用可視化的分析器通過GUI執行剛剛定義好的多維分析命令。
並行分析模塊接受用戶提交的多維分析命令，並將通過核心模塊將該命令解析為Map-Rece，提交給Hadoop集群之後，生成報表供報表中心展示。
核心模塊是將多維分析語言轉化為MapRece的解析器，讀取用戶定義的維度和度量，將用戶的多維分析命令翻譯成MapRece程序。核心模塊的具體邏輯如圖6所示。
圖6中根據JobConf參數進行Map和Rece類的拼裝並不復雜，難點是很多實際問題很難通過一個MapRece Job解決，必須通過多個MapRece Job組成工作流（WorkFlow），這里是最需要根據業務進行定製的部分。圖7是一個簡單的MapRece工作流的例子。
MapRece的輸出一般是統計分析的結果，數據量相較於輸入的海量數據會小很多，這樣就可以導入傳統的數據報表產品中進行展現。
⑹ Bigtable---分布式的結構化數據存儲系統
sina
Bigtable 是一個分布式的結構化數據存儲系統，它被設計用來處理海量數據：通常是分布在數千台普通伺服器上的PB 級的數據。Google 的很多項目使用Bigtable 存儲數據，包括Web 索引、GoogleEarth、Google Finance。這些應用對Bigtable 提出的要求差異非常大，無論是在數據量上（從URL到網頁到衛星圖像）還是在響應速度上（從後端的批量處理到實時數據服務）。
Bigtable 已經實現了下面的幾個目標：適用性廣泛、可擴展、高性能和高可用性,Bigtable 是一個稀疏的、分布式的、持久化存儲的多維度排序Map。
圖一：一個存儲Web 網頁的例子的表的片斷。行名是一個反向URL。contents 列族存放的是網頁的內容，anchor 列族存放引用該網頁的錨鏈接文本（alex 註：如果不知道HTML 的Anchor，請Google一把）。CNN 的主頁被Sports Illustrater和MY-look 的主頁引用，因此該行包含了名為「anchor:cnnsi.com」和「anchhor:my.look.ca」的列。每個錨鏈接只有一個版本（alex 註：注意時間戳標識了列的版本，t9 和t8 分別標識了兩個錨鏈接的版本）；而contents 列則有三個版本，分別由時間戳t3，t5，和t6 標識。
行
Bigtable 通過行關鍵字的字典順序來組織數據。表中的每個行都可以動態分區。每個分區叫做一個」Tablet」，Tablet 是數據分布和負載均衡調整的最小單位。
列族
Webtable 有個列族language，language 列族用來存放撰寫網頁的語言。
我們在language 列族中只使用一個列關鍵字，用來存放每個網頁的語言標識ID。Webtable 中另一個有用的列族是anchor；這個列族的每一個列關鍵字代表一個錨鏈接，如圖一所示。Anchor 列族的限定詞是引用該網頁的站點名；Anchor 列族每列的數據項存放的是鏈接文本。訪問控制、磁碟和內存的使用統計都是在列族層面進行的。
時間戳
不同版本的數據通過時間戳來索引。Bigtable 時間戳的類型是64 位整型。
Bigtable 可以給時間戳賦值，用來表示精確到毫秒的「實時」時間；用戶程序也可以給時間戳賦值。如果應用程序需要避免數據版本沖突，那麼它必須自己生成具有唯一性的時間戳。數據項中，不同版本的數據按照時間戳倒序排序，即最新的數據排在最前面。為了減輕多個版本數據的管理負擔，我們對每一個列族配有兩個設置參數， Bigtable 通過這兩個參數可以對廢棄版本的數據自動進行垃圾收集。用戶可以指定只保存最後n 個版本的數據，或者只保存「足夠新」的版本的數據（比如，只保存最近7 天的內容寫入的數據）。
Bigtable支持的其他特性
1、Bigtable 支持單行上的事務處理，利用這個功能，用戶可以對存儲在一個行關鍵字下的數據進行原子性的讀-更新-寫操作。
2、Bigtable 允許把數據項用做整數計數器。
3、Bigtable 允許用戶在伺服器的地址空間內執行腳本程序
4、Bigtable 可以和MapRece一起使用，MapRece 是Google 開發的大規模並行計算框架。我們已經開發了一些Wrapper 類，通過使用這些Wrapper 類，Bigtable 可以作為MapRece 框架的輸入和輸出。
Bigtable依賴於google的幾項技術。用GFS來存儲日誌和數據文件；按SSTable文件格式存儲數據；用Chubby管理元數據：
Bigtable是建立在其它的幾個Google基礎構件上的。BigTable 使用Google 的分布式文件系統(GFS)存儲日誌文件和數據文件。BigTable 集群通常運行在一個共享的機器池中，池中的機器還會運行其它的各種各樣的分布式應用程序，BigTable 的進程經常要和其它應用的進程共享機器。BigTable 依賴集群管理系統來調度任務、管理共享的機器上的資源、處理機器的故障、以及監視機器的狀態。
BigTable 內部存儲數據的文件是Google SSTable 格式的。SSTable 是一個持久化的、排序的、不可更改的Map 結構，而Map 是一個key-value 映射的數據結構，key 和value 的值都是任意的Byte串，從內部看，SSTable 是一系列的數據塊（通常每個塊的大小是64KB，這個大小是可以配置的）。。SSTable 使用塊索引（通常存儲在SSTable 的最後）來定位數據塊；在打開SSTable的時候，索引被載入到內存。每次查找都可以通過一次磁碟搜索完成：首先使用二分查找法在內存中的索引里找到數據塊的位置，然後再從硬碟讀取相應的數據塊。也可以選擇把整個SSTable 都放在內存中，這樣就不必訪問硬碟了。
BigTable 還依賴一個高可用的、序列化的分布式鎖服務組件，叫做Chubby。Chubby有五個活躍副本，同時只有一個主副本提供服務，副本之間用Paxos演算法維持一致性，Chubby提供了一個命名空間（包括一些目錄和文件），每個目錄和文件就是一個鎖，Chubby的客戶端必須和Chubby保持會話，客戶端的會話若過期則會丟失所有的鎖。
Bigtable 包括了三個主要的組件：鏈接到客戶程序中的庫、一個Master主伺服器和多個Tablet片 伺服器。
Bigtable會將表（table）進行分片，片（tablet）的大小維持在100-200MB范圍，一旦超出范圍就將分裂成更小的片，或者合並成更大的片。每個片伺服器負責一定量的片，處理對其片的讀寫請求，以及片的分裂或合並。片伺服器可以根據負載隨時添加和刪除。這里片伺服器並不真實存儲數據，而相當於一個連接Bigtable和GFS的代理，客戶端的一些數據操作都通過片伺服器代理間接訪問GFS。主伺服器負責將片分配給片伺服器，監控片伺服器的添加和刪除，平衡片伺服器的負載，處理表和列族的創建等。注意，主伺服器不存儲任何片，不提供任何數據服務，也不提供片的定位信息。
客戶端需要讀寫數據時，直接與片伺服器聯系。因為客戶端並不需要從主伺服器獲取片的位置信息，所以大多數客戶端從來不需要訪問主伺服器，主伺服器的負載一般很輕。
Master 伺服器主要負責以下工作：為Tablet 伺服器分配Tablets、檢測新加入的或者過期失效的Table 伺服器、對Tablet 伺服器進行負載均衡、以及對保存在GFS 上的文件進行垃圾收集。除此之外，它還處理對模式的相關修改操作，例如建立表和列族。
我們使用一個三層的、類似B+樹的結構存儲Tablet 的位置信息。
第一層是一個存儲在Chubby 中的文件，它包含了Root Tablet 的位置信息。這個Chubby文件屬於Chubby服務的一部分，一旦Chubby不可用，就意味著丟失了root tablet的位置，整個Bigtable也就不可用了。
第二層是root tablet。root tablet其實是元數據表（METADATA table）的第一個分片，它保存著元數據表其它片的位置。root tablet很特別，為了保證樹的深度不變，root tablet從不分裂。
第三層是其它的元數據片，它們和root tablet一起組成完整的元數據表。每個元數據片都包含了許多用戶片的位置信息。
片的數據最終還是寫到GFS里的，片在GFS里的物理形態就是若干個SSTable文件。下圖展示了讀寫操作基本情況。
BigTable和GFS的關系
集群包括主伺服器和片伺服器，主伺服器負責將片分配給片伺服器，而具體的數據服務則全權由片伺服器負責。但是不要誤以為片伺服器真的存儲了數據（除了內存中memtable的數據），數據的真實位置只有GFS才知道，主伺服器將片分配給片伺服器的意思應該是，片伺服器獲取了片的所有SSTable文件名，片伺服器通過一些索引機制可以知道所需要的數據在哪個SSTable文件，然後從GFS中讀取SSTable文件的數據，這個SSTable文件可能分布在好幾台chunkserver上。
一個簡化的Bigtable結構圖：
結構圖以Webtable表為例，表中存儲了網易、網路和豆瓣的幾個網頁。當我們想查找網路貼吧昨天的網頁內容，可以向Bigtable發出查詢Webtable表的(com..tieba, contents:, yesterday)。
假設客戶端沒有該緩存，那麼Bigtable訪問root tablet的片伺服器，希望得到該網頁所屬的片的位置信息在哪個元數據片中。使用 METADATA.Webtable.com..tieba 為行鍵在root tablet中查找，定位到最後一個比它大的是 METADATA.Webtable.com..www ，於是確定需要的就是元數據表的片A。訪問片A的片伺服器，繼續查找 Webtable.com..tieba ，定位到 Webtable.com..www 是比它大的，確定需要的是Webtable表的片B。訪問片B的片伺服器，獲得數據。
這里需要注意的是，每個片實際都由若干SSTable文件和memtable組成，而且這些SSTable和memtable都是已排序的。這就導致查找片B時，可能需要將所有SSTable和memtable都查找一遍；另外客戶端應該不會直接從元數據表獲得SSTable的文件名，而只是獲得片屬於片伺服器的信息，通過片伺服器為代理訪問SSTable。
⑺ 什麼是分布式數據存儲
什麼是分布式存儲
分布式存儲是一種數據存儲技術，它通過網路使用企業中每台機器上的磁碟空間，這些分散的存儲資源構成了虛擬存儲設備，數據分布存儲在企業的各個角落。
分布式存儲系統，可在多個獨立設備上分發數據。傳統的網路存儲系統使用集中存儲伺服器來存儲所有數據。存儲伺服器成為系統性能的瓶頸，也是可靠性和安全性的焦點，無法滿足大規模存儲應用的需求。分布式網路存儲系統採用可擴展的系統結構，使用多個存儲伺服器共享存儲負載，利用位置伺服器定位存儲信息，不僅提高了系統的可靠性，可用性和訪問效率，而且易於擴展。
⑻ 分布式存儲和傳統存儲比較在哪些應用場景比較有優勢
1、分布式存儲優勢
分布式存儲可以使生產系統在線運行的情況下進行縱向擴展（Scale-Up）或橫向擴展（Scale-Out），且存儲系統在擴展後可以達到容量與性能均線性擴展的效果。其具有以下特性：
高性能
分布式存儲系統能夠將所有存儲節點的處理器資源、硬碟資源、網路資源進行整合，將任務切分給多台存儲節點，進行並發數據處理，避免了單個硬碟或設備造成的瓶頸，提升整個集群的處理能力。分布式存儲系統具有良好的性能擴展能力，可以滿足應用程序對存儲性能不斷增長的要求。
高擴展性
分布式存儲系統通過擴展集群存儲節點規模從而提高系統存儲容量、計算和性能的能力，通過增加和升級伺服器硬體，或者指通過增加存儲節點數量來提升服務能力。分布式存儲系統支持在線增加存儲節點，對前端業務透明，系統整體性能與存儲節點數量呈線性關系。
高可用性
分布式存儲系統同時基於硬體及軟體設計了高可用機制，在面對多種異常時（如存儲節點宕機、網路中斷、硬碟故障、數據損壞等）仍可提供正常服務，提高分布式存儲系統硬體的可用性可以通過增加存儲節點數量或者採用多種硬體冗餘機制保證。分布式存儲系統多採用副本機制或糾刪碼機制保證數據的高可用性，副本機制可以提供較高的數據冗餘度，但會降低存儲系統有效空間的利用率，糾刪碼機制可以在保證一定數據冗餘度的情況下，大幅提高存儲系統的有效空間利用率。
高安全性
分布式存儲系統支持可靠的許可權控制及互信確認機制，同時採用私有的數據切片及數據編碼機制，可以從多重角度保證集群系統不受惡意訪問和攻擊，保護存儲數據不被竊取。
2、分布式存儲應用場景
分布式的「四高」特性，使得其在高性能計算、大數據視頻雲及大數據分析等應用場景中有著廣泛的應用。
高性能計算場景
在如氣象氣候、地質勘探、航空航天、工程計算、材料工程等領域，基於集群的高性能計算，已成為必需的輔助工具。集群系統有極強的伸縮性，可通過在集群中增加或刪減節點的方式，在不影響原有應用與計算任務的情況下，隨時增加和降低系統的處理能力。根據不同的計算模式與規模，構成集群系統的節點數可以從幾個到成千上萬個。這些業務對後端的存儲系統提出了新的需求，包括統一的存儲空間、高效率的文件檢索、高帶寬的吞吐性能，高可靠的數據安全保障等。
大數據視頻雲應用場景
隨著視頻高清技術及超高清技術的普及，視頻大數據應用場景，如雪亮工程、平安城市、廣電媒資、影視製作、視頻網站等領域，對存儲設備提出了大容量、高讀寫性能、高可靠性、低延時及可擴展性等需求。針對這樣大規模視頻數據應用場景，就需要一個技術先進、性能優越的存儲系統作為後端數據存儲的支撐者。
大數據分析應用場景
伴隨著互聯網技術及人工智慧的發展，各種基於海量用戶/數據/終端的大數據分析及人工智慧業務模式不斷涌現，同樣需要充分考慮存儲功能集成度、數據安全性、數據穩定性，系統可擴展性、性能及成本各方面因素。
在數據爆發增長的「數字時代」，軟體定義的分布式存儲是存儲技術高速發展的結晶，並具有著很大的成長空間，必將應用於更廣泛的大數據業務場景。
⑼ 在大數量級的數據存儲上，比較靠譜的分布式文件存儲有哪些
一、 Ceph
Ceph最早起源於Sage就讀博士期間的工作、成果於2004年發表，並隨後貢獻給開源社區。經過多年的發展之後，已得到眾多雲計算和存儲廠商的支持，成為應用最廣泛的開源分布式存儲平台。
二、 GFS
GFS是google的分布式文件存儲系統，是專為存儲海量搜索數據而設計的，2003年提出，是閉源的分布式文件系統。適用於大量的順序讀取和順序追加，如大文件的讀寫。注重大文件的持續穩定帶寬，而不是單次讀寫的延遲。
三、 HDFS
HDFS(Hadoop Distributed File System)，是一個適合運行在通用硬體(commodity hardware)上的分布式文件系統，是Hadoop的核心子項目，是基於流數據模式訪問和處理超大文件的需求而開發的。該系統仿效了谷歌文件系統(GFS)，是GFS的一個簡化和開源版本。