Hadoop
成都創(chuàng)新互聯(lián)公司自2013年創(chuàng)立以來，是專業(yè)互聯(lián)網技術服務公司，擁有項目成都網站設計、成都做網站、外貿網站建設網站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元府谷做網站,已為上家服務,為府谷各地企業(yè)和個人服務,聯(lián)系電話:18980820575
文件系統(tǒng)：文件系統(tǒng)是用來存儲和管理文件，并且提供文件的查詢、增加、刪除等操作。
直觀上的體驗：在shell窗口輸入 ls 命令，就可以看到當前目錄下的文件夾、文件。
文件存儲在哪里？硬盤
一臺只有250G硬盤的電腦，如果需要存儲500G的文件可以怎么辦？先將電腦硬盤擴容至少250G，再將文件分割成多塊，放到多塊硬盤上儲存。
通過 hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實現(xiàn)將分布在多臺機器上的文件系統(tǒng)進行統(tǒng)一的管理。
在分布式文件系統(tǒng)中，一個大文件會被切分成塊，分別存儲到幾臺機器上。結合上文中提到的那個存儲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ù)據，成千上萬臺機器組成的集群是很常見的，所以說分布式系統(tǒng)比單機系統(tǒng)要復雜得多呀。
這是一張HDFS的架構簡圖：
client通過nameNode了解數(shù)據在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教NameNode，看看應該往哪個DateNode中去寫。
為了某一份數(shù)據只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗余備份的方式來進行容錯處理。因此，HDFS在寫入一個數(shù)據塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其余的DataNode中拿到數(shù)據，保證了數(shù)據不丟失。
實際上，每個數(shù)據塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。
接下來我們來看一下完整的文件寫入的流程：
大文件要寫入HDFS，client端根據配置將大文件分成固定大小的塊，然后再上傳到HDFS。
讀取文件的流程：
1、client詢問NameNode，我要讀取某個路徑下的文件，麻煩告訴我這個文件都在哪些DataNode上？
2、NameNode回復client，這個路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3個文件塊，通過stream讀取并且整合起來
文件寫入的流程：
1、client先將文件分塊，然后詢問NameNode，我要寫入一個文件到某個路徑下，文件有3塊，應該怎么寫？
2、NameNode回復client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個塊重復寫3份，總共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數(shù)據寫到他們上面
出于容錯的考慮，每個數(shù)據塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當然也可以借鑒這個思想，數(shù)據其實只需要寫入到一個datanode上，然后由datanode之間相互進行備份同步，減少了client端的寫入壓力，那么至于是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當然這個設置會影響到數(shù)據寫入的吞吐率，我們可以看到可靠性和效率永遠是“魚和熊掌不可兼得”的。
潛在問題
NameNode確實會回放editlog，但是不是每次都從頭回放，它會先加載一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數(shù)據的內存快照，然后再在這個基礎上回放editlog，完成后，會清空editlog，再把當前文件元數(shù)據的內存狀態(tài)寫入fsimage，方便下一次加載。
這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復的時間依然比較長，這個問題怎么解呢？
SecondNameNode是一個NameNode內的定時任務線程，它會定期地將editlog寫入fsimage，然后情況原來的editlog，從而保證editlog的文件大小維持在一定大小。
NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個NameNode，它掛了，整個系統(tǒng)就掛了。hadoop2.x之前，整個集群只能有一個NameNode，是有可能發(fā)生單點故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統(tǒng)就更加復雜了。
俗話說“一山不容二虎”，兩個NameNode只能有一個是活躍狀態(tài)active，另一個是備份狀態(tài)standby，我們看一下兩個NameNode的架構圖。
兩個NameNode通過JournalNode實現(xiàn)同步editlog，保持狀態(tài)一致可以相互替換。
因為active的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數(shù)據要時刻保持一致，在寫入數(shù)據的時候，兩個NameNode內存中都要記錄數(shù)據的元信息，并保持一致。這個JournalNode就是用來在兩個NameNode中同步數(shù)據的，并且standby NameNode實現(xiàn)了SecondNameNode的功能。
進行數(shù)據同步操作的過程如下：
active NameNode有操作之后，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化并進行同步，同時standby NameNode會監(jiān)聽記錄的變化。這樣做的話就是實時同步了，并且standby NameNode就實現(xiàn)了SecondNameNode的功能。
優(yōu)點：
缺點：
現(xiàn)在的互聯(lián)網+，不過是練了個吸星大法，但吸進來的內力，如果不消化好，就很快會反噬，您說呢，令狐少俠
據株洲日報報道，近年來，株洲水電氣、公交等公用事業(yè)單位紛紛推出自己的App應用。盡管在報道中亦提到，部分此類App仍不支持移動支付功能，或僅支持銀行卡額，不支持微信或支付寶之類的第三方支付，距離老百姓還有“最后一公里”的問題。
但即使解決移動支付這個便捷性問題，就算是解決了最后一公里嗎？愚以為不然，這恰恰是包括公用事業(yè)在內的許多消費類App們的認知上的瓶頸所在，即在他們看來，互聯(lián)網+的核心要義，就是解決一個排隊難的問題。
當然，不得不承認，這樣的互聯(lián)網思維，已經比只是簡單地讓自己的產品、服務展示在網絡上，把互聯(lián)網+看做是聯(lián)網要強上許多。而且低段位的互聯(lián)網+確實也是用這種方式來撈取第一波用戶的。
畢竟排隊在中國一直都是個難題，這里面涉及到一個時間成本的問題，通過互聯(lián)網，讓用戶不用到線下的窗口，直接可以網上支付了“門票”，然后按照約定的時間來吃飯、看電影、逛景點，或者如水電煤氣之類的服務，足不出戶就把事情給辦了，自然是皆大歡喜。
但這其實只是互聯(lián)網+的起手式，只是通過互聯(lián)網，拉近了和用戶之間的交易距離，說白了，就是繳費方便了，但心與心的距離，還是很遙遠。
接下來的事情更重要，通過網絡能夠減少雙方的時間成本和各種空耗沒了，但互聯(lián)網+最后的落實之處還是在線下，而不是僅僅一個網上快捷繳費。線下比拼的是什么？服務二字而已。
對于那些做獨家生意的App來說，或許這樣的感覺還不明顯。但對于其他競爭壓力頗大的互聯(lián)網+項目來說，比如外賣、電影、美容美發(fā)之類，則頗為鮮明，客人最終決定是否長期光顧，還是要在線下體驗了你的服務確實不錯之后，才會形成黏性。線上付費也好、各種折扣也罷，不過是一個最初用來招攬客人入口罷了，何況同樣的入口還有很多。為何選擇你，用戶體驗好、服務有特色，依然是不二法門。
尤其是在同行們都互聯(lián)網+之后，其實比拼又回到了服務這個原始起點之上。再多問一句然后呢？其實互聯(lián)網+的另一層深意也就在此體現(xiàn)，比如早前在網約車和出租車的比拼中，出租車為何頻頻落于下風？除了網約車多了個更精準的網上攬客手段，在服務上也頗為個性化之外。網約車平臺也在憋大招，比如通過大數(shù)據，根據地圖和約車熱度對用戶群體進行畫像，然后給網約車們更多的攬客建議；又如百度外賣，甚至整出了個智能物流調度系統(tǒng)，用人工智能為平臺里的商戶們送餐，合理規(guī)劃最佳路線，而且還是根據路況來實時制定的……
網上繳費沒變、基礎服務也未必立刻得到了升級，比如菜的口味總不是一朝一夕改變的，但互聯(lián)網+里面其實還可以納入更多技術元素，來讓服務變得“不一樣”起來。
或許，對于苦于找不到風口的眾創(chuàng)企業(yè)們來說，為App們提供支付之外的技術服務，也是個商機。
隨著 MySQL 被 Oracle 收購，MySQL 的用戶和開發(fā)者開始質疑開源數(shù)據庫的命運，與此同時他們開始尋找替代品。
有文章寫到了放棄 MySQL 的五大理由： MySQL 不如其它關系型數(shù)據庫管理系統(tǒng)那樣成熟； MySQL 是開源的...但只有近似而已； MySQL 的性能無法與競爭對手相提并論； MySQL 是 Oracle 所有的，而不是社區(qū)驅動的； 越來越多的強勁對手。 從 MySQL 轉向 MariaDB的代表廠家：谷歌（2013年9月）、RedHat（2013年6月）、維基百科（2013年4月）
MySQL 在 2008 年被Sun以10億美金所收購，MySQL 創(chuàng)始人 Michael Widenius 則不滿 Sun 開發(fā)團隊腳步過慢，憤而離職成立開源數(shù)據庫聯(lián)盟，另外從現(xiàn)有 MySQL 程序代碼中，開發(fā)出另一個延伸分支版本，也就是名為瑪莉亞數(shù)據庫的企業(yè)級開源數(shù)據庫 。
瑪莉亞數(shù)據庫如同 MySQL 的影子版本，瑪莉亞數(shù)據庫是 MySQL 的一個分支版本（branch），而不是衍生版本（folk），提供的功能可和 MySQL 完全兼容。 從 MySQL 轉向 PostgreSQL的代表廠家：蘋果（2011年）
PostgreSQL是一個自由的對象-關系數(shù)據庫服務器(數(shù)據庫管理系統(tǒng))。PostgreSQL支持大部分 SQL標準并且提供了許多其他現(xiàn)代特性：復雜查詢、外鍵、觸發(fā)器、視圖、事務完整性、MVCC。同樣，PostgreSQL 可以用許多方法擴展，比如， 通過增加新的數(shù)據類型、函數(shù)、操作符、聚集函數(shù)、索引方法、過程語言。并且，因為許可證的靈活，任何人都可以以任何目的免費使用、修改、和分發(fā) PostgreSQL，不管是私用、商用、還是學術研究使用。
PostgreSQL 也受 NoSQL 思想的啟發(fā)，希望能夠在今后可以給使用者更多可定制可調節(jié)的功能（不是說這個成熟的關系性數(shù)據庫系統(tǒng)要向 NoSQL 轉變）。 NoSQL(NoSQL = Not Only SQL)，意即“不僅僅是 SQL”，是一項全新的數(shù)據庫革命性運動。NoSQL指的是非關系型的數(shù)據庫。隨著互聯(lián)網 web2.0網站的興起，傳統(tǒng)的關系數(shù)據庫在應付 web2.0 網站，特別是超大規(guī)模和高并發(fā)的 SNS 類型的 web2.0 純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數(shù)據庫則由于其本身的特點得到了非常迅速的發(fā)展。
其代表的開源軟件如：Membase、MongoDB、Hypertable、Apache Cassandra、CouchDB等。 Oracle自 Oracle 10g 后推出對應的免費版。
關系是客觀存在的自然規(guī)律，擺脫就是在修改事實模型。
用NOSQL，我覺得可以理解成關系模型的變化，而不是另起爐灶。
Lambda架構的核心理念是“流批一體化”，因為隨著機器性能和數(shù)據框架的不斷完善，用戶其實不關心底層是如何運行的，批處理也好，流式處理也罷，能按照統(tǒng)一的模型返回結果就可以了，這就是Lambda架構誕生的原因?，F(xiàn)在很多應用，例如Spark和Flink，都支持這種結構，也就是數(shù)據進入平臺后，可以選擇批處理運行，也可以選擇流式處理運行，但不管怎樣，一致性都是相同的。
Kylin
Kylin的主要特點是預計算，提前計算好各個cube，這樣的優(yōu)點是查詢快速，秒級延遲；缺點也非常明顯，靈活性不足，無法做一些 探索 式的，關聯(lián)性的數(shù)據分析。
適合的場景也是比較固定的，場景清晰的地方。
ClickHouse
Clickhouse由俄羅斯yandex公司開發(fā)。專為在線數(shù)據分析而設計。
Clickhouse最大的特點首先是快 ，為了快采用了列式儲存，列式儲存更好的支持壓縮，壓縮后的數(shù)據傳輸量變小，所以更快；同時支持分片，支持分布式執(zhí)行，支持SQL。
ClickHouse很輕量級，支持數(shù)據壓縮和最終數(shù)據一致性，其數(shù)據量級在PB級別。
另外Clickhouse不是為關聯(lián)分析而生，所以多表關聯(lián)支持的不太好。
同樣Clickhouse不能修改或者刪除數(shù)據，僅能用于批量刪除或修改。沒有完整的事務支持，不支持二級索引等等，缺點也非常明顯。
與Kylin相比ClickHouse更加的靈活，sql支持的更好，但是相比Kylin，ClickHouse不支持大并發(fā)，也就是不能很多訪問同時在線。
總之ClickHouse用于在線數(shù)據分析，支持功能簡單。CPU 利用率高，速度極快。最好的場景用于行為統(tǒng)計分析。
Hive
Hive這個工具，大家一定很熟悉，大數(shù)據倉庫的首選工具?？梢詫⒔Y構化的數(shù)據文件映射為一張數(shù)據庫表，并提供完整的sql查詢功能。
主要功能是可以將sql語句轉換為相對應的MapReduce任務進行運行，這樣可能處理海量的數(shù)據批量，
Hive與HDFS結合緊密，在大數(shù)據開始初期，提供一種直接使用sql就能訪問HDFS的方案，擺脫了寫MapReduce任務的方式，極大的降低了大數(shù)據的門檻。
當然Hive的缺點非常明顯，定義的是分鐘級別的查詢延遲，估計都是在比較理想的情況。 但是作為數(shù)據倉庫的每日批量工具，的確是一個穩(wěn)定合格的產品。
Presto
Presto極大的改進了Hive的查詢速度，而且Presto 本身并不存儲數(shù)據，但是可以接入多種數(shù)據源，并且支持跨數(shù)據源的級聯(lián)查詢，支持包括復雜查詢、聚合、連接等等。
Presto沒有使用MapReduce，它是通過一個定制的查詢和執(zhí)行引擎來完成的。它的所有的查詢處理是在內存中，這也是它的性能很高的一個主要原因。
Presto由于是基于內存的，缺點可能是多張大表關聯(lián)操作時易引起內存溢出錯誤。
另外Presto不支持OLTP的場景，所以不要把Presto當做數(shù)據庫來使用。
Presto相比ClickHouse優(yōu)點主要是多表join效果好。相比ClickHouse的支持功能簡單，場景支持單一，Presto支持復雜的查詢，應用范圍更廣。
Impala
Impala是Cloudera 公司推出，提供對 HDFS、Hbase 數(shù)據的高性能、低延遲的交互式 SQL 查詢功能。
Impala 使用 Hive的元數(shù)據, 完全在內存中計算。是CDH 平臺首選的 PB 級大數(shù)據實時查詢分析引擎。
Impala 的缺點也很明顯，首先嚴重依賴Hive，而且穩(wěn)定性也稍差，元數(shù)據需要單獨的mysql/pgsql來存儲，對數(shù)據源的支持比較少，很多nosql是不支持的。但是，估計是cloudera的國內市場推廣做的不錯，Impala在國內的市場不錯。
SparkSQL
SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成，可以將結構化數(shù)據作為 Spark 的 RDD 進行查詢。
SparkSQL后續(xù)不再受限于Hive，只是兼容Hive。
SparkSQL提供了sql訪問和API訪問的接口。
支持訪問各式各樣的數(shù)據源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像國內使用的很少，根據定義，Drill是一個低延遲的分布式海量數(shù)據交互式查詢引擎，支持多種數(shù)據源，包括hadoop，NoSQL存儲等等。
除了支持多種的數(shù)據源，Drill跟BI工具集成比較好。
Druid
Druid是專為海量數(shù)據集上的做高性能 OLAP而設計的數(shù)據存儲和分析系統(tǒng)。
Druid 的架構是 Lambda 架構，分成實時層和批處理層。
Druid的核心設計結合了數(shù)據倉庫，時間序列數(shù)據庫和搜索系統(tǒng)的思想，以創(chuàng)建一個統(tǒng)一的系統(tǒng)，用于針對各種用例的實時分析。Druid將這三個系統(tǒng)中每個系統(tǒng)的關鍵特征合并到其接收層，存儲格式，查詢層和核心體系結構中。
目前 Druid 的去重都是非精確的，Druid 適合處理星型模型的數(shù)據，不支持關聯(lián)操作。也不支持數(shù)據的更新。
Druid最大的優(yōu)點還是支持實時與查詢功能，解約了很多開發(fā)工作。
Kudu
kudu是一套完全獨立的分布式存儲引擎，很多設計概念上借鑒了HBase，但是又跟HBase不同，不需要HDFS，通過raft做數(shù)據復制；分片策略支持keyrange和hash等多種。
數(shù)據格式在parquet基礎上做了些修改，支持二級索引，更像一個列式存儲，而不是HBase schema-free的kv方式。
kudu也是cloudera主導的項目，跟Impala結合比較好，通過impala可以支持update操作。
kudu相對于原有parquet和ORC格式主要還是做增量更新的。
Hbase
Hbase使用的很廣,更多的是作為一個KV數(shù)據庫來使用，查詢的速度很快。
Hawq
Hawq是一個Hadoop原生大規(guī)模并行SQL分析引擎，Hawq采用 MPP 架構，改進了針對 Hadoop 的基于成本的查詢優(yōu)化器。
除了能高效處理本身的內部數(shù)據，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數(shù)據源。HAWQ全面兼容 SQL 標準，還可用 SQL 完成簡單的數(shù)據挖掘和機器學習。無論是功能特性，還是性能表現(xiàn)，HAWQ 都比較適用于構建 Hadoop 分析型數(shù)據倉庫應用。
數(shù)據庫一體機與大數(shù)據技術區(qū)別何在
作為近期信息管理領域最為熱門的兩項技術，數(shù)據庫一體機與大數(shù)據技術的硬件架構基本相同，但軟件體系有著本質的區(qū)別，這也導致了兩者擁有不同的特征表現(xiàn)。
隨著企業(yè)數(shù)據量的快速增長，以及用戶對服務水平要求的不斷提高，相當長的一段時間以來，傳統(tǒng)關系數(shù)據庫技術在生產實踐中表現(xiàn)出明顯的能力不足。如何以合理的成本獲得海量數(shù)據的高可用性已經成為現(xiàn)代IT領域的重大挑戰(zhàn)。為了應對這一挑戰(zhàn)，近年來，IT市場中相繼出現(xiàn)了許多新的技術手段，其中最為引人注目的便是由主流數(shù)據庫廠商主導的數(shù)據庫一體機（例如Oracle ExaData以及IBM Netezza等），以及以開源力量為主的大數(shù)據技術。
不過，雖然數(shù)據庫一體機與大數(shù)據技術都是當今的熱門話題，并都已經被廣泛應用，但卻有相當一部分用戶仍然無法深入了解兩者之間的本質區(qū)別與關系。同時，很多用戶也在為如何在企業(yè)內部對這兩者進行正確定位而感到困惑。為此，本文特別對數(shù)據庫一體機（也可稱新一代主流關系型數(shù)據庫）和大數(shù)據技術（例如Hadoop，主要指MapReduce與NoSQL）的相關技術特點進行對比。
硬件與軟件
從本質上來講，數(shù)據庫一體機與大數(shù)據技術的硬件架構基本相同，同樣是采用x86服務器集群的分布式并行模式，以應對大規(guī)模的數(shù)據與計算。但是，數(shù)據庫一體機的賣家們通常會對其產品的硬件體系進行面向產品化的、系統(tǒng)性的整體調優(yōu)，同時也會有各自的特色手段。比方說Oracle ExaData的Infiniband、Flash Cache，IBM Nettezza的FPGA（現(xiàn)場可編程邏輯門陣）等。[page] 數(shù)據庫一體機與大數(shù)據技術最為核心的區(qū)別是在軟件體系上。數(shù)據庫一體機的核心是SQL體系，這不只是指SQL解析，更重要的是指包括SQL優(yōu)化引擎、索引、鎖、事務、日志、安全以及管理等在內的完整而龐大的技術體系。這一體系是成熟的、面向產品的。
大數(shù)據技術軟件體系中的MapReduce則提供了一個面向海量數(shù)據處理的分布式編程框架，使用者需要自行編制所需要的計算邏輯。MapReduce對數(shù)據的讀寫是批量連續(xù)的，而不是隨機的。而大數(shù)據技術的另一體系NoSQL則大都只是提供了海量數(shù)據的分布式存儲，以及基于索引的快速讀取機制，為使用者提供的大多是編程API（雖然也有類SQL的語言，但其本質并不是完整的SQL體系）。
由于SQL體系的復雜性與處理邏輯的整體關聯(lián)性，導致數(shù)據庫一體機在擴展性上遠不及大數(shù)據技術體系，雖然前者已經在很大程度上改善了傳統(tǒng)關系數(shù)據庫垂直擴展的瓶頸。MapReduce與NoSQL的單個集群往往可以擴展到數(shù)千個節(jié)點，而數(shù)據庫一體機如果在硬件上擴展到這個規(guī)模，從軟件上來講，已經是沒有意義的了。
特征與本質
基于軟件體系的不同，導致了數(shù)據庫一體機和大數(shù)據技術有著不同的特征表現(xiàn)。數(shù)據庫一體機往往適合于存儲關系復雜的數(shù)據模型（例如企業(yè)核心業(yè)務數(shù)據），并且需要限制為基于二維表的關系模型。同時，數(shù)據庫一體機適合進行一致性與事務性要求高的計算，以及復雜的BI計算。
大數(shù)據技術則更適合于存儲較簡單的數(shù)據模型，并且可以不受模式的約束。因而其可存儲管理的數(shù)據類型更加豐富。大數(shù)據技術還適合進行一致性與事務性要求不高的計算（主要是指NoSQL的查詢操作），以及對超大規(guī)模海量數(shù)據的、批量的分布式并行計算（基于MapReduce）。
需要注意的是，NoSQL數(shù)據庫由于擺脫了繁瑣的SQL體系約束，其查詢與插入的效率比數(shù)據庫一體機更高。大數(shù)據技術比數(shù)據庫一體機所能處理的數(shù)據量也相對大些，這主要是因為其集群可以擴展得更大。
從本質上講，MapReduce是對海量數(shù)據分布式計算領域的一個重要創(chuàng)新，但也只是在適合于并行處理的大規(guī)模批量處理問題上更占優(yōu)勢，而對一些復雜操作，則不一定具有優(yōu)勢。NoSQL則可以看作是對傳統(tǒng)關系數(shù)據庫進行簡化的結果。由于NoSQL數(shù)據庫的設計思想只是提取出關系型數(shù)據庫的索引機制，并加了上分布式存儲，把SQL體系中那些對“某些特殊問題”而言并不需要的東西統(tǒng)統(tǒng)刪去，由此實現(xiàn)了更優(yōu)秀的效率、擴展性與靈活性。[page] 因此，我們可以明顯地看到，在實踐中，有很多問題（特別是流行的大數(shù)據問題），關系數(shù)據庫中的許多設計并不需要，這才是NoSQL發(fā)展壯大的根本立足點。
關系與協(xié)作
通過前面的分析，我們不難得出這樣的結論：大數(shù)據技術與數(shù)據庫一體機應該是相輔相成，并非互相替代的。它們針對不同的應用場景設計，并相互補充與合作。具體來說，大數(shù)據技術可以實現(xiàn)：
■處理企業(yè)內海量的、模型簡單、類型多樣的非結構化與半結構化數(shù)據（例如社會化數(shù)據、各種日志甚至圖片、視頻等），其處理結果可以被直接使用；
■以上處理結果也同時可以被當成是新的輸入存儲到企業(yè)級數(shù)據倉庫中，這時大數(shù)據機相當于是面向大數(shù)據源的、新的ETL（提取-轉換-加載）手段；
■面向海量數(shù)據的、不太適合SQL的存儲或計算。
而數(shù)據庫一體機則應該還是作為企業(yè)數(shù)據倉庫的主流技術，至少在很長一段時間內應該是這樣。它負責存儲與計算最主要的、有重大價值的企業(yè)關鍵業(yè)務數(shù)據。
現(xiàn)存的誤區(qū)
有些人認為，雖然大數(shù)據技術的原始開源狀態(tài)還不適合充當企業(yè)級數(shù)據倉庫主平臺的要求，但經過開發(fā)、補充，應該是可以的。其實這個觀點沒有錯。但實際上，對開源的大數(shù)據技術進行補充開發(fā)，所要補充的正是大數(shù)據技術在原始設計上就去除了的、那些本屬于關系型數(shù)據庫體系的東西。
如果進行這樣的補充開發(fā)，企業(yè)不僅會面臨龐大的、難于估計的開發(fā)工作量，同時也難以像專業(yè)數(shù)據庫廠商那樣實現(xiàn)這些工作的理論化、產品化與體系化。雖然從純技術的角度上講，開發(fā)什么都有可能。但是如果企業(yè)真的準備這樣做，是要開發(fā)另一個商業(yè)化的關系數(shù)據庫嗎？很明顯，這違背了大數(shù)據技術的設計初衷。
重慶分公司
重慶分公司
