Hadoop

我們注重客戶提出的每個要求,我們充分考慮每一個細節(jié),我們積極的做好成都網(wǎng)站設(shè)計、成都做網(wǎng)站服務(wù),我們努力開拓更好的視野,通過不懈的努力,創(chuàng)新互聯(lián)公司贏得了業(yè)內(nèi)的良好聲譽,這一切,也不斷的激勵著我們更好的服務(wù)客戶。 主要業(yè)務(wù):網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)站設(shè)計,微信小程序定制開發(fā),網(wǎng)站開發(fā),技術(shù)開發(fā)實力,DIV+CSS,PHP及ASP,ASP.Net,SQL數(shù)據(jù)庫的技術(shù)開發(fā)工程師。
文件系統(tǒng):文件系統(tǒng)是用來存儲和管理文件,并且提供文件的查詢、增加、刪除等操作。
直觀上的體驗:在shell窗口輸入 ls 命令,就可以看到當(dāng)前目錄下的文件夾、文件。
文件存儲在哪里?硬盤
一臺只有250G硬盤的電腦,如果需要存儲500G的文件可以怎么辦?先將電腦硬盤擴容至少250G,再將文件分割成多塊,放到多塊硬盤上儲存。
通過 hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件,就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令,可以實現(xiàn)將分布在多臺機器上的文件系統(tǒng)進行統(tǒng)一的管理。
在分布式文件系統(tǒng)中,一個大文件會被切分成塊,分別存儲到幾臺機器上。結(jié)合上文中提到的那個存儲500G大文件的那個例子,這500G的文件會按照一定的大小被切分成若干塊,然后分別存儲在若干臺機器上,然后提供統(tǒng)一的操作接口。
看到這里,不少人可能會覺得,分布式文件系統(tǒng)不過如此,很簡單嘛。事實真的是這樣的么?
潛在問題
假如我有一個1000臺機器組成的分布式系統(tǒng),一臺機器每天出現(xiàn)故障的概率是0.1%,那么整個系統(tǒng)每天出現(xiàn)故障的概率是多大呢?答案是(1-0.1%)^1000=63%,因此需要提供一個容錯機制來保證發(fā)生差錯時文件依然可以讀出,這里暫時先不展開介紹。
如果要存儲PB級或者EB級的數(shù)據(jù),成千上萬臺機器組成的集群是很常見的,所以說分布式系統(tǒng)比單機系統(tǒng)要復(fù)雜得多呀。
這是一張HDFS的架構(gòu)簡圖:
client通過nameNode了解數(shù)據(jù)在哪些DataNode上,從而發(fā)起查詢。此外,不僅是查詢文件,寫入文件的時候也是先去請教NameNode,看看應(yīng)該往哪個DateNode中去寫。
為了某一份數(shù)據(jù)只寫入到一個Datanode中,而這個Datanode因為某些原因出錯無法讀取的問題,需要通過冗余備份的方式來進行容錯處理。因此,HDFS在寫入一個數(shù)據(jù)塊的時候,不會僅僅寫入一個DataNode,而是會寫入到多個DataNode中,這樣,如果其中一個DataNode壞了,還可以從其余的DataNode中拿到數(shù)據(jù),保證了數(shù)據(jù)不丟失。
實際上,每個數(shù)據(jù)塊在HDFS上都會保存多份,保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。
接下來我們來看一下完整的文件寫入的流程:
大文件要寫入HDFS,client端根據(jù)配置將大文件分成固定大小的塊,然后再上傳到HDFS。
讀取文件的流程:
1、client詢問NameNode,我要讀取某個路徑下的文件,麻煩告訴我這個文件都在哪些DataNode上?
2、NameNode回復(fù)client,這個路徑下的文件被切成了3塊,分別在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4,拿到3個文件塊,通過stream讀取并且整合起來
文件寫入的流程:
1、client先將文件分塊,然后詢問NameNode,我要寫入一個文件到某個路徑下,文件有3塊,應(yīng)該怎么寫?
2、NameNode回復(fù)client,可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上,記住,每個塊重復(fù)寫3份,總共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4,把數(shù)據(jù)寫到他們上面
出于容錯的考慮,每個數(shù)據(jù)塊有3個備份,但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力,這個點是否有更好的解決方案呢?回憶一下mysql主備之間是通過binlog文件進行同步的,HDFS當(dāng)然也可以借鑒這個思想,數(shù)據(jù)其實只需要寫入到一個datanode上,然后由datanode之間相互進行備份同步,減少了client端的寫入壓力,那么至于是一個datanode寫入成功即成功,還是需要所有的參與備份的datanode返回寫入成功才算成功,是可靠性配置的策略,當(dāng)然這個設(shè)置會影響到數(shù)據(jù)寫入的吞吐率,我們可以看到可靠性和效率永遠是“魚和熊掌不可兼得”的。
潛在問題
NameNode確實會回放editlog,但是不是每次都從頭回放,它會先加載一個fsimage,這個文件是之前某一個時刻整個NameNode的文件元數(shù)據(jù)的內(nèi)存快照,然后再在這個基礎(chǔ)上回放editlog,完成后,會清空editlog,再把當(dāng)前文件元數(shù)據(jù)的內(nèi)存狀態(tài)寫入fsimage,方便下一次加載。
這樣,全量回放就變成了增量回放,但是如果NameNode長時間未重啟過,editlog依然會比較大,恢復(fù)的時間依然比較長,這個問題怎么解呢?
SecondNameNode是一個NameNode內(nèi)的定時任務(wù)線程,它會定期地將editlog寫入fsimage,然后情況原來的editlog,從而保證editlog的文件大小維持在一定大小。
NameNode掛了, SecondNameNode并不能替代NameNode,所以如果集群中只有一個NameNode,它掛了,整個系統(tǒng)就掛了。hadoop2.x之前,整個集群只能有一個NameNode,是有可能發(fā)生單點故障的,所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后,我們可以在集群中配置多個NameNode,就不會有這個問題了,但是配置多個NameNode,需要注意的地方就更多了,系統(tǒng)就更加復(fù)雜了。
俗話說“一山不容二虎”,兩個NameNode只能有一個是活躍狀態(tài)active,另一個是備份狀態(tài)standby,我們看一下兩個NameNode的架構(gòu)圖。
兩個NameNode通過JournalNode實現(xiàn)同步editlog,保持狀態(tài)一致可以相互替換。
因為active的NameNode掛了之后,standby的NameNode要馬上接替它,所以它們的數(shù)據(jù)要時刻保持一致,在寫入數(shù)據(jù)的時候,兩個NameNode內(nèi)存中都要記錄數(shù)據(jù)的元信息,并保持一致。這個JournalNode就是用來在兩個NameNode中同步數(shù)據(jù)的,并且standby NameNode實現(xiàn)了SecondNameNode的功能。
進行數(shù)據(jù)同步操作的過程如下:
active NameNode有操作之后,它的editlog會被記錄到JournalNode中,standby NameNode會從JournalNode中讀取到變化并進行同步,同時standby NameNode會監(jiān)聽記錄的變化。這樣做的話就是實時同步了,并且standby NameNode就實現(xiàn)了SecondNameNode的功能。
優(yōu)點:
缺點:
2. 什么是NoSQL?
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,
泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題,包括超大規(guī)模數(shù)據(jù)的存儲。
(例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù))。這些類型的數(shù)據(jù)存儲不需要固定的模式,無需多余操作就可以橫向擴展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫與NoSQL的區(qū)別?
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語言(SQL)
數(shù)據(jù)和關(guān)系都存儲在單獨的表中。
數(shù)據(jù)操縱語言,數(shù)據(jù)定義語言
嚴格的一致性
基礎(chǔ)事務(wù)
ACID
關(guān)系型數(shù)據(jù)庫遵循ACID規(guī)則
事務(wù)在英文中是transaction,和現(xiàn)實世界中的交易很類似,它有如下四個特性:
A (Atomicity) 原子性
原子性很容易理解,也就是說事務(wù)里的所有操作要么全部做完,要么都不做,事務(wù)成功的條件是事務(wù)里的所有操作都成功,只要有一個操作失敗,整個事務(wù)就失敗,需要回滾。比如銀行轉(zhuǎn)賬,從A賬戶轉(zhuǎn)100元至B賬戶,分為兩個步驟:1)從A賬戶取100元;2)存入100元至B賬戶。這兩步要么一起完成,要么一起不完成,如果只完成第一步,第二步失敗,錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解,也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài),事務(wù)的運行不會改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指并發(fā)的事務(wù)之間不會互相影響,如果一個事務(wù)要訪問的數(shù)據(jù)正在被另外一個事務(wù)修改,只要另外一個事務(wù)未提交,它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶,在這個交易還未完成的情況下,如果此時B查詢自己的賬戶,是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務(wù)提交后,它所做的修改將會永久的保存在數(shù)據(jù)庫上,即使出現(xiàn)宕機也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預(yù)定義的模式
鍵 - 值對存儲,列存儲,文檔存儲,圖形數(shù)據(jù)庫
最終一致性,而非ACID屬性
非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
CAP定理
高性能,高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理:
Consistency(一致性), 數(shù)據(jù)一致更新,所有數(shù)據(jù)變動都是同步的
Availability(可用性), 好的響應(yīng)性能
Partition tolerance(分區(qū)容錯性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
定理:任何分布式系統(tǒng)只可同時滿足二點,沒法三者兼顧。
CAP理論的核心是:一個分布式系統(tǒng)不可能同時很好的滿足一致性,可用性和分區(qū)容錯性這三個需求,
因此,根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:
CA - 單點集群,滿足一致性,可用性的系統(tǒng),通常在可擴展性上不太強大。
CP - 滿足一致性,分區(qū)容忍性的系統(tǒng),通常性能不是特別高。
AP - 滿足可用性,分區(qū)容忍性的系統(tǒng),通常可能對一致性要求低一些。
CAP理論就是說在分布式存儲系統(tǒng)中,最多只能實現(xiàn)上面的兩點。
而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會出現(xiàn)延遲丟包等問題,所以分區(qū)容忍性是我們必須需要實現(xiàn)的。
所以我們只能在一致性和可用性之間進行權(quán)衡,沒有NoSQL系統(tǒng)能同時保證這三點。
說明:C:強一致性 A:高可用性 P:分布式容忍性
舉例:
CA:傳統(tǒng)Oracle數(shù)據(jù)庫
AP:大多數(shù)網(wǎng)站架構(gòu)的選擇
CP:Redis、Mongodb
注意:分布式架構(gòu)的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數(shù)web應(yīng)用,其實并不需要強一致性。
因此犧牲C換取P,這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。
4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用
當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。
代表項目:阿里巴巴商品信息的存放。
去 IOE 化。
ps:I 是指 IBM 的小型機,很貴的,好像好幾萬一臺;O 是指 Oracle 數(shù)據(jù)庫,也很貴的,好幾萬呢;M 是指 EMC 的存儲設(shè)備,也很貴的。
難點:
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務(wù)平臺不需要大面積重構(gòu)。
特點:
它們可以處理超大量的數(shù)據(jù)。
它們運行在便宜的PC服務(wù)器集群上。
PC集群擴充起來非常方便并且成本很低,避免了“sharding”操作的復(fù)雜性和成本。
它們擊碎了性能瓶頸。
NoSQL的支持者稱,通過NoSQL架構(gòu)可以省去將Web或Java應(yīng)用和數(shù)據(jù)轉(zhuǎn)換成SQL友好格式的時間,執(zhí)行速度變得更快。
“SQL并非適用于所有的程序代碼,” 對于那些繁重的重復(fù)操作的數(shù)據(jù),SQL值得花錢。但是當(dāng)數(shù)據(jù)庫結(jié)構(gòu)非常簡單時,SQL可能沒有太大用處。
沒有過多的操作。
雖然NoSQL的支持者也承認關(guān)系數(shù)據(jù)庫提供了無可比擬的功能集合,而且在數(shù)據(jù)完整性上也發(fā)揮絕對穩(wěn)定,他們同時也表示,企業(yè)的具體需求可能沒有那么多。
Bootstrap支持
因為NoSQL項目都是開源的,因此它們?nèi)狈?yīng)商提供的正式支持。這一點它們與大多數(shù)開源項目一樣,不得不從社區(qū)中尋求支持。
優(yōu)點:
易擴展
NoSQL數(shù)據(jù)庫種類繁多,但是一個共同的特點都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系,這樣就非常容易擴展。也無形之間,在架構(gòu)的層面上帶來了可擴展的能力。
大數(shù)據(jù)量,高性能
NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能,尤其在大數(shù)據(jù)量下,同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性,數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用 Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對web2.0的交互頻繁的應(yīng)用,Cache性能不高。而NoSQL的 Cache是記錄級的,是一種細粒度的Cache,所以NoSQL在這個層面上來說就要性能高很多了。
靈活的數(shù)據(jù)模型
NoSQL無需事先為要存儲的數(shù)據(jù)建立字段,隨時可以存儲自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里,增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表,增加字段簡直就是一個噩夢。這點在大數(shù)據(jù)量的web2.0時代尤其明顯。
高可用
NoSQL在不太影響性能的情況,就可以方便的實現(xiàn)高可用的架構(gòu)。比如Cassandra,HBase模型,通過復(fù)制模型也能實現(xiàn)高可用。
主要應(yīng)用:
Apache HBase
這個大數(shù)據(jù)管理平臺建立在谷歌強大的BigTable管理引擎基礎(chǔ)上。作為具有開源、Java編碼、分布式多個優(yōu)勢的數(shù)據(jù)庫,Hbase最初被設(shè)計應(yīng)用于Hadoop平臺,而這一強大的數(shù)據(jù)管理工具,也被Facebook采用,用于管理消息平臺的龐大數(shù)據(jù)。
Apache Storm
用于處理高速、大型數(shù)據(jù)流的分布式實時計算系統(tǒng)。Storm為Apache Hadoop添加了可靠的實時數(shù)據(jù)處理功能,同時還增加了低延遲的儀表板、安全警報,改進了原有的操作方式,幫助企業(yè)更有效率地捕獲商業(yè)機會、發(fā)展新業(yè)務(wù)。
Apache Spark
該技術(shù)采用內(nèi)存計算,從多迭代批量處理出發(fā),允許將數(shù)據(jù)載入內(nèi)存做反復(fù)查詢,此外還融合數(shù)據(jù)倉庫、流處理和圖計算等多種計算范式,Spark用Scala語言實現(xiàn),構(gòu)建在HDFS上,能與Hadoop很好的結(jié)合,而且運行速度比MapReduce快100倍。
Apache Hadoop
該技術(shù)迅速成為了大數(shù)據(jù)管理標(biāo)準(zhǔn)之一。當(dāng)它被用來管理大型數(shù)據(jù)集時,對于復(fù)雜的分布式應(yīng)用,Hadoop體現(xiàn)出了非常好的性能,平臺的靈活性使它可以運行在商用硬件系統(tǒng),它還可以輕松地集成結(jié)構(gòu)化、半結(jié)構(gòu)化和甚至非結(jié)構(gòu)化數(shù)據(jù)集。
Apache Drill
你有多大的數(shù)據(jù)集?其實無論你有多大的數(shù)據(jù)集,Drill都能輕松應(yīng)對。通過支持HBase、Cassandra和MongoDB,Drill建立了交互式分析平臺,允許大規(guī)模數(shù)據(jù)吞吐,而且能很快得出結(jié)果。
Apache Sqoop
也許你的數(shù)據(jù)現(xiàn)在還被鎖定于舊系統(tǒng)中,Sqoop可以幫你解決這個問題。這一平臺采用并發(fā)連接,可以將數(shù)據(jù)從關(guān)系數(shù)據(jù)庫系統(tǒng)方便地轉(zhuǎn)移到Hadoop中,可以自定義數(shù)據(jù)類型以及元數(shù)據(jù)傳播的映射。事實上,你還可以將數(shù)據(jù)(如新的數(shù)據(jù))導(dǎo)入到HDFS、Hive和Hbase中。
Apache Giraph
這是功能強大的圖形處理平臺,具有很好可擴展性和可用性。該技術(shù)已經(jīng)被Facebook采用,Giraph可以運行在Hadoop環(huán)境中,可以將它直接部署到現(xiàn)有的Hadoop系統(tǒng)中。通過這種方式,你可以得到強大的分布式作圖能力,同時還能利用上現(xiàn)有的大數(shù)據(jù)處理引擎。
Cloudera Impala
Impala模型也可以部署在你現(xiàn)有的Hadoop群集上,監(jiān)視所有的查詢。該技術(shù)和MapReduce一樣,具有強大的批處理能力,而且Impala對于實時的SQL查詢也有很好的效果,通過高效的SQL查詢,你可以很快的了解到大數(shù)據(jù)平臺上的數(shù)據(jù)。
Gephi
它可以用來對信息進行關(guān)聯(lián)和量化處理,通過為數(shù)據(jù)創(chuàng)建功能強大的可視化效果,你可以從數(shù)據(jù)中得到不一樣的洞察力。Gephi已經(jīng)支持多個圖表類型,而且可以在具有上百萬個節(jié)點的大型網(wǎng)絡(luò)上運行。Gephi具有活躍的用戶社區(qū),Gephi還提供了大量的插件,可以和現(xiàn)有系統(tǒng)完美的集成到一起,它還可以對復(fù)雜的IT連接、分布式系統(tǒng)中各個節(jié)點、數(shù)據(jù)流等信息進行可視化分析。
MongoDB
這個堅實的平臺一直被很多組織推崇,它在大數(shù)據(jù)管理上有極好的性能。MongoDB最初是由DoubleClick公司的員工創(chuàng)建,現(xiàn)在該技術(shù)已經(jīng)被廣泛的應(yīng)用于大數(shù)據(jù)管理。MongoDB是一個應(yīng)用開源技術(shù)開發(fā)的NoSQL數(shù)據(jù)庫,可以用于在JSON這樣的平臺上存儲和處理數(shù)據(jù)。目前,紐約時報、Craigslist以及眾多企業(yè)都采用了MongoDB,幫助他們管理大型數(shù)據(jù)集。(Couchbase服務(wù)器也作為一個參考)。
十大頂尖公司:
Amazon Web Services
Forrester將AWS稱為“云霸主”,談到云計算領(lǐng)域的大數(shù)據(jù),那就不得不提到亞馬遜。該公司的Hadoop產(chǎn)品被稱為EMR(Elastic Map Reduce),AWS解釋這款產(chǎn)品采用了Hadoop技術(shù)來提供大數(shù)據(jù)管理服務(wù),但它不是純開源Hadoop,經(jīng)過修改后現(xiàn)在被專門用在AWS云上。
Forrester稱EMR有很好的市場前景。很多公司基于EMR為客戶提供服務(wù),有一些公司將EMR應(yīng)用于數(shù)據(jù)查詢、建模、集成和管理。而且AWS還在創(chuàng)新,F(xiàn)orrester稱未來EMR可以基于工作量的需要自動縮放調(diào)整大小。亞馬遜計劃為其產(chǎn)品和服務(wù)提供更強大的EMR支持,包括它的RedShift數(shù)據(jù)倉庫、新公布的Kenesis實時處理引擎以及計劃中的NoSQL數(shù)據(jù)庫和商業(yè)智能工具。不過AWS還沒有自己的Hadoop發(fā)行版。
Cloudera
Cloudera有開源Hadoop的發(fā)行版,這個發(fā)行版采用了Apache Hadoop開源項目的很多技術(shù),不過基于這些技術(shù)的發(fā)行版也有很大的進步。Cloudera為它的Hadoop發(fā)行版開發(fā)了很多功能,包括Cloudera管理器,用于管理和監(jiān)控,以及名為Impala的SQL引擎等。Cloudera的Hadoop發(fā)行版基于開源Hadoop,但也不是純開源的產(chǎn)品。當(dāng)Cloudera的客戶需要Hadoop不具備的某些功能時,Cloudera的工程師們就會實現(xiàn)這些功能,或者找一個擁有這項技術(shù)的合作伙伴。Forrester表示:“Cloudera的創(chuàng)新方法忠于核心Hadoop,但因為其可實現(xiàn)快速創(chuàng)新并積極滿足客戶需求,這一點使它不同于其他那些供應(yīng)商。”目前,Cloudera的平臺已經(jīng)擁有200多個付費客戶,一些客戶在Cloudera的技術(shù)支持下已經(jīng)可以跨1000多個節(jié)點實現(xiàn)對PB級數(shù)據(jù)的有效管理。
Hortonworks
和Cloudera一樣,Hortonworks是一個純粹的Hadoop技術(shù)公司。與Cloudera不同的是,Hortonworks堅信開源Hadoop比任何其他供應(yīng)商的Hadoop發(fā)行版都要強大。Hortonworks的目標(biāo)是建立Hadoop生態(tài)圈和Hadoop用戶社區(qū),推進開源項目的發(fā)展。Hortonworks平臺和開源Hadoop聯(lián)系緊密,公司管理人員表示這會給用戶帶來好處,因為它可以防止被供應(yīng)商套牢(如果Hortonworks的客戶想要離開這個平臺,他們可以輕松轉(zhuǎn)向其他開源平臺)。這并不是說Hortonworks完全依賴開源Hadoop技術(shù),而是因為該公司將其所有開發(fā)的成果回報給了開源社區(qū),比如Ambari,這個工具就是由Hortonworks開發(fā)而成,用來填充集群管理項目漏洞。Hortonworks的方案已經(jīng)得到了Teradata、Microsoft、Red Hat和SAP這些供應(yīng)商的支持。
IBM
當(dāng)企業(yè)考慮一些大的IT項目時,很多人首先會想到IBM。IBM是Hadoop項目的主要參與者之一,F(xiàn)orrester稱IBM已有100多個Hadoop部署,它的很多客戶都有PB級的數(shù)據(jù)。IBM在網(wǎng)格計算、全球數(shù)據(jù)中心和企業(yè)大數(shù)據(jù)項目實施等眾多領(lǐng)域有著豐富的經(jīng)驗。“IBM計劃繼續(xù)整合SPSS分析、高性能計算、BI工具、數(shù)據(jù)管理和建模、應(yīng)對高性能計算的工作負載管理等眾多技術(shù)。”
Intel
和AWS類似,英特爾不斷改進和優(yōu)化Hadoop使其運行在自己的硬件上,具體來說,就是讓Hadoop運行在其至強芯片上,幫助用戶打破Hadoop系統(tǒng)的一些限制,使軟件和硬件結(jié)合的更好,英特爾的Hadoop發(fā)行版在上述方面做得比較好。Forrester指出英特爾在最近才推出這個產(chǎn)品,所以公司在未來還有很多改進的可能,英特爾和微軟都被認為是Hadoop市場上的潛力股。
MapR Technologies
MapR的Hadoop發(fā)行版目前為止也許是最好的了,不過很多人可能都沒有聽說過。Forrester對Hadoop用戶的調(diào)查顯示,MapR的評級最高,其發(fā)行版在架構(gòu)和數(shù)據(jù)處理能力上都獲得了最高分。MapR已將一套特殊功能融入其Hadoop發(fā)行版中。例如網(wǎng)絡(luò)文件系統(tǒng)(NFS)、災(zāi)難恢復(fù)以及高可用性功能。Forrester說MapR在Hadoop市場上沒有Cloudera和Hortonworks那樣的知名度,MapR要成為一個真正的大企業(yè),還需要加強伙伴關(guān)系和市場營銷。
Microsoft
微軟在開源軟件問題上一直很低調(diào),但在大數(shù)據(jù)形勢下,它不得不考慮讓W(xué)indows也兼容Hadoop,它還積極投入到開源項目中,以更廣泛地推動Hadoop生態(tài)圈的發(fā)展。我們可以在微軟的公共云Windows Azure HDInsight產(chǎn)品中看到其成果。微軟的Hadoop服務(wù)基于Hortonworks的發(fā)行版,而且是為Azure量身定制的。
微軟也有一些其他的項目,包括名為Polybase的項目,讓Hadoop查詢實現(xiàn)了SQLServer查詢的一些功能。Forrester說:“微軟在數(shù)據(jù)庫、數(shù)據(jù)倉庫、云、OLAP、BI、電子表格(包括PowerPivot)、協(xié)作和開發(fā)工具市場上有很大優(yōu)勢,而且微軟擁有龐大的用戶群,但要在Hadoop這個領(lǐng)域成為行業(yè)領(lǐng)導(dǎo)者還有很遠的路要走。”
Pivotal Software
EMC和Vmware部分大數(shù)據(jù)業(yè)務(wù)分拆組合產(chǎn)生了Pivotal。Pivotal一直努力構(gòu)建一個性能優(yōu)越的Hadoop發(fā)行版,為此,Pivotal在開源Hadoop的基礎(chǔ)上又添加了一些新的工具,包括一個名為HAWQ的SQL引擎以及一個專門解決大數(shù)據(jù)問題的Hadoop應(yīng)用。Forrester稱Pivotal Hadoop平臺的優(yōu)勢在于它整合了Pivotal、EMC、Vmware的眾多技術(shù),Pivotal的真正優(yōu)勢實際上等于EMC和Vmware兩大公司為其撐腰。到目前為止,Pivotal的用戶還不到100個,而且大多是中小型客戶。
Teradata
對于Teradata來說,Hadoop既是一種威脅也是一種機遇。數(shù)據(jù)管理,特別是關(guān)于SQL和關(guān)系數(shù)據(jù)庫這一領(lǐng)域是Teradata的專長。所以像Hadoop這樣的NoSQL平臺崛起可能會威脅到Teradata。相反,Teradata接受了Hadoop,通過與Hortonworks合作,Teradata在Hadoop平臺集成了SQL技術(shù),這使Teradata的客戶可以在Hadoop平臺上方便地使用存儲在Teradata數(shù)據(jù)倉庫中的數(shù)據(jù)。
AMPLab
通過將數(shù)據(jù)轉(zhuǎn)變?yōu)樾畔ⅲ覀儾趴梢岳斫馐澜纾@也正是AMPLab所做的。AMPLab致力于機器學(xué)習(xí)、數(shù)據(jù)挖掘、數(shù)據(jù)庫、信息檢索、自然語言處理和語音識別等多個領(lǐng)域,努力改進對信息包括不透明數(shù)據(jù)集內(nèi)信息的甄別技術(shù)。除了Spark,開源分布式SQL查詢引擎Shark也源于AMPLab,Shark具有極高的查詢效率,具有良好的兼容性和可擴展性。近幾年的發(fā)展使計算機科學(xué)進入到全新的時代,而AMPLab為我們設(shè)想一個運用大數(shù)據(jù)、云計算、通信等各種資源和技術(shù)靈活解決難題的方案,以應(yīng)對越來越復(fù)雜的各種難題。
1 理解ACID與BASE的區(qū)別(ACID是關(guān)系型數(shù)據(jù)庫強一致性的四個要求,而BASE是NoSQL數(shù)據(jù)庫通常對可用性及一致性的弱要求原則,它們的意思分別是,ACID:atomicity, consistency, isolation, durability;BASE:Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語里意為酸,BASE意思為堿)
2 理解持久化與非持久化的區(qū)別。這么說是因為有的NoSQL系統(tǒng)是純內(nèi)存存儲的。
3 你必須意識到傳統(tǒng)有關(guān)系型數(shù)據(jù)庫與NoSQL系統(tǒng)在數(shù)據(jù)結(jié)構(gòu)上的本質(zhì)區(qū)別。傳統(tǒng)關(guān)系型數(shù)據(jù)庫通常是基于行的表格型存儲,而NoSQL系統(tǒng)包括了列式存儲(Cassandra)、key/value存儲(Memcached)、文檔型存儲(CouchDB)以及圖結(jié)構(gòu)存儲(Neo4j)
4與傳統(tǒng)關(guān)系數(shù)據(jù)庫有統(tǒng)一的SQL語言操作接口不同,NoSQL系統(tǒng)通常有自己特有的API接口。
5 在架構(gòu)上,你必須搞清楚,NoSQL系統(tǒng)是被設(shè)計用于成百上千臺機器的集群中的,而非共享型數(shù)據(jù)庫系統(tǒng)的架構(gòu)。
6在NoSQL系統(tǒng)中,可能你得習(xí)慣一下不知道你的數(shù)據(jù)具體存在何處的情況。
7 在NoSQL系統(tǒng)中,你最好習(xí)慣它的弱一致性。”eventually consistent”(最終一致性)正是BASE原則中的重要一項。比如在Twitter,你在Followers列表中經(jīng)常會感受到數(shù)據(jù)的延遲。
8 在NoSQL系統(tǒng)中,你要理解,很多時候數(shù)據(jù)并不總是可用的。
9 你得理解,有的方案是擁有分區(qū)容忍性的,有的方案不一定有。
架構(gòu)圖如下圖所示。這張圖基本涵蓋了互聯(lián)網(wǎng)技術(shù)公司的大部分技術(shù)點,不同公司只是在具體的技術(shù)實現(xiàn)上稍有差異,但不會跳出這個框架的范疇。
SQL: 常用的有mysql,用于存儲業(yè)務(wù)數(shù)據(jù)。互聯(lián)網(wǎng)發(fā)展初期,各個業(yè)務(wù)一般都會獨立運營mysql集群,但隨著業(yè)務(wù)越來越多,mysql集群規(guī)模越來越大,那就有必要做成SQL平臺。
NoSQL: 翻譯為Not Only SQL,作為mysql的一種補充。Nosql一般本身就提供集群,且使用起來很方便,公司業(yè)務(wù)發(fā)展初期沒有必要。一般Nosql集群的數(shù)量越來越多,那就有必要做成Nosql平臺。
小文件: 互聯(lián)網(wǎng)中有很多小文件,比如商品圖片,F(xiàn)acebook的圖片。這類小文件具有數(shù)據(jù)小、數(shù)量巨大、訪問大的特點。如果每個業(yè)務(wù)都去考慮小文件存儲的話,就會出現(xiàn)重復(fù)造輪子現(xiàn)象,那就有必要做成小文件平臺了。
大文件: 互聯(lián)網(wǎng)的大文件主要分為兩類:一類是業(yè)務(wù)上的大數(shù)據(jù),例如Youtube的視頻、電影網(wǎng)站的電影;另一類是海量的日志數(shù)據(jù),例如各種訪問日志。實力雄厚的一些大公司會基于開源方案做成大數(shù)據(jù)平臺。
開發(fā)框架: 比如常見的Spring框架。
Web服務(wù)器: 常見的有tomcat、jetty等。
容器: Docker可以極大降低運維成本,以及在實現(xiàn)動態(tài)擴容上非常方便。
配置中心: 故名思義,配置中心就是集中管理各個系統(tǒng)的配置。
服務(wù)中心: 解決跨系統(tǒng)依賴的配置和調(diào)度問題。比如有10個系統(tǒng)依賴A系統(tǒng)的x接口,此時A系統(tǒng)實現(xiàn)了一個y接口可以更好地支持x接口,那么如果直接更新10個系統(tǒng)依賴的配置將會很麻煩。
消息隊列: 支持系統(tǒng)解耦。
負載均衡: 充當(dāng)任務(wù)分配器的職責(zé)。
CDN: 可以對一些常用文件進行就近緩存,來提高訪問速度。
多機房: 多機房的主要目的是備災(zāi),當(dāng)機房故障時可以快速地將業(yè)務(wù)切換到另外一個機房,這種切換操作允許一定時間的中斷,比如10分鐘,1個小時。
多中心: 多中心的要求就更高了,要求同時對外提供服務(wù),且業(yè)務(wù)能夠自動在多中心之間切換,故障后不需人工干預(yù)或者很少的人工干預(yù)就能自動恢復(fù)。
用戶管理: 對各個系統(tǒng)的用戶進行統(tǒng)一管理。
消息推送: 根據(jù)不同途徑分為短信、郵件、站內(nèi)信、App推送。
存儲云: 實現(xiàn)是CDN+小文件存儲。
圖片云: 實現(xiàn)也是CDN+小文件存儲。為何不與存儲云統(tǒng)一一套系統(tǒng)呢?這是因為圖片業(yè)務(wù)的復(fù)雜性導(dǎo)致的。圖片涉及的業(yè)務(wù)會更多,包括裁剪、壓縮、美化、審核、水印等。
業(yè)務(wù)千差萬別,各個互聯(lián)網(wǎng)業(yè)務(wù)面對的主要問題是復(fù)雜度越來越高。此時就要用到拆和合的技術(shù)。拆即將一個大系統(tǒng)拆分為多個子系統(tǒng),降低復(fù)雜度。當(dāng)子系統(tǒng)越來越多,有可能就需要采用合的技術(shù)。
測試平臺的核心目的是提升測試效率。
運維平臺的核心職責(zé)分為四大塊:配置、部署、監(jiān)控、應(yīng)急。
數(shù)據(jù)平臺的核心職責(zé)主要包含三部分:數(shù)據(jù)管理、數(shù)據(jù)分析和數(shù)據(jù)應(yīng)用。
管理平臺的核心職責(zé)就是權(quán)限管理。
網(wǎng)頁標(biāo)題:nosql架構(gòu)圖,nosql介紹
網(wǎng)頁鏈接:http://chinadenli.net/article16/dsgddgg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、動態(tài)網(wǎng)站、電子商務(wù)、網(wǎng)站改版、做網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)