近年來，存儲設備的價格有所下降，到2012年底，甚至一GB的SSD存儲設備也有望跌破一美元。擁有數(shù)千臺機器的集群不再僅僅是大公司的標準。有了apachehadoop和HBase這樣的技術，“一無所獲的文化”已經(jīng)變得很普遍。數(shù)據(jù)科學家們正在愉快地篩選所有這些原始數(shù)據(jù)，以發(fā)現(xiàn)更有價值的信息，并提取與業(yè)務相關的部分，從而提供競爭優(yōu)勢。機器學習有助于解決幾年前似乎難以解決的問題。數(shù)據(jù)革命已經(jīng)開始。還是有？

今天閱讀有關大數(shù)據(jù)的出版物給人的印象是，必須重塑開發(fā)過程：必須存儲越來越多的數(shù)據(jù)才能保持競爭力。處理存儲、分析和可視化數(shù)據(jù)的項目到處都在炒作。當仔細觀察當今生產(chǎn)中的單個解決方案時，這種觀點就不那么一致了——通常解決方案是由不同成熟度的幾個不同部分構建的。對于開發(fā)人員來說，使用一個體系結(jié)構所花費的時間比最初估計的要長是很正常的。

本文試圖將數(shù)據(jù)驅(qū)動的開發(fā)放在上下文中—將其與已經(jīng)在實踐中完成的工作進行比較和對比。它展示了大數(shù)據(jù)技術是如何結(jié)合在一起的，以及黃象和適應它們的機器是如何結(jié)合在一起的。

讓我們從一個假設的例子開始建立一個網(wǎng)上商店。頭腦風暴時，腦海中浮現(xiàn)的需求是存儲產(chǎn)品、用戶數(shù)據(jù)、用戶事務（那些活動的，例如“Mary購買了新耳機，產(chǎn)品ID為9887876，正在發(fā)貨”，最好是過去的，以便以后能夠為Mary提供更好的產(chǎn)品建議）。一旦商店就位，我們就可以猜測用戶可能會發(fā)現(xiàn)哪些變化和改進是有用的。我們可以明確地征求瑪麗的意見。然而，普通用戶非常懶惰：他們很少提供反饋。

更容易的是在線觀察用戶：觀察他們看什么產(chǎn)品，最終購買什么產(chǎn)品，調(diào)查哪些頁面的用戶離開網(wǎng)站的比率最高，哪些頁面是典型的入口頁面。沿著這條路走下去，發(fā)展就變成了四個步驟的循環(huán)：

發(fā)展的四個步驟：

1. 觀察用戶與應用程序的交互方式–這將導致發(fā)現(xiàn)多個缺陷，修復后會帶來不同的好處：產(chǎn)品搜索可能并不理想，因為用戶經(jīng)常搜索特定顏色的耳機，但顏色可能尚未被索引。用戶可能正在搜索“購買”按鈕，因為它不在頁面頂部。

2. 通過定義應用程序應該改進的方向來確定方向-決定在下一次迭代中修復哪些缺陷，并定義衡量修復成功程度的標準：使耳機的顏色可導航，并期望在一個月內(nèi)使耳機銷量翻番。

3. 決定要實現(xiàn)什么–實現(xiàn)細節(jié)可能會有所不同，在我們的玩具示例中，選項可能是將耳機的顏色作為索引的一部分，這樣用戶就可以搜索它們，或者將它們包含在刻面用戶界面中。

4. 行動–實施修復

最后，通過觀察用戶對修復的反應，這個周期又開始了。最后一步是可以對當前和未來的執(zhí)行情況作出哪些反饋。周期越緊，反饋就越快地反饋到開發(fā)中，項目就越有可能超越競爭對手（圖1）。

圖1：開發(fā)的四個步驟

這種發(fā)展周期并不奇怪，也不應該是特別新的。相反，它是為任何成功的實現(xiàn)所隱含的。但是，這種顯式形式表明，有些步驟可以從收集定義良好的附加數(shù)據(jù)集或使用已有的數(shù)據(jù)集中獲益匪淺。

通過跟蹤任何用戶行為（常見和不常見、成功和不成功）可以極大地支持觀察。每次用戶成功地與網(wǎng)店進行交互時，都會顯示哪些功能特別有效。不成功的互動揭示了不足和改進的空間。一個度量是由一個新特征的成功定義的，然后需要在方向上進行評估。使這一步驟明確和可衡量，就可以得到明確的數(shù)字，可以將變化與之進行比較。它還明確了變革的目標，并有助于確定是否以及何時達到該目標。

收集交互數(shù)據(jù)的第二個目標是利用這些數(shù)據(jù)為個人用戶提供更好的服務：用戶Mary很可能不想再尋找另一副她評價不好的耳機。所以她應該得到不同的搜索結(jié)果。此外，她可能對一種非常特殊的音樂類型感興趣，當她收到自己喜歡的音樂集時，她可能會非常高興。

最后，兩種類型的使用交互數(shù)據(jù)的結(jié)果都顯示在圖2中的流程圖中。

圖2：兩種類型的交互數(shù)據(jù)

關于數(shù)據(jù)收集的任何一種方法都是新的嗎？不是真的。自互聯(lián)網(wǎng)出現(xiàn)之初，人們就開始收集互動數(shù)據(jù)。用戶傾向于在所提供的基礎設施中做各種有趣的事情。因此，服務提供商很早就開始記錄用戶交互——可能只是為了在效果之后診斷是什么導致了問題。

該級別上更常見的需求工程類型包括基于過去流量模式的機器大小調(diào)整，針對可見的入侵嘗試強化設置。基于用戶數(shù)據(jù)的典型功能包括僅向在線雜志的讀者顯示新內(nèi)容或根據(jù)用戶請求的來源顯示不同的內(nèi)容。

使用的數(shù)據(jù)源通常包括web服務器訪問日志、運行狀況檢查結(jié)果和響應時間日志。所有這些都有不同的格式，但通常都是基于文本的格式，可以通過sed、awk或python腳本等工具進行處理。結(jié)果隨后會顯示在定制的儀表板、gnuplot圖表甚至日志分析的半標準工具中——AWStats是web服務器日志的一個著名例子。

應用程序特定數(shù)據(jù)

讓我們更進一步，看看特定于應用程序的數(shù)據(jù)：這些數(shù)據(jù)包括客戶數(shù)據(jù)庫、事務日志等。從中可以學到什么？

根據(jù)新的要求，我們可能會發(fā)現(xiàn)所有的客戶都來自歐洲，所以營銷應該擴展到不同的國家。根據(jù)用戶的統(tǒng)計數(shù)據(jù)，網(wǎng)站本身可能需要不同的功能——一般精通技術的客戶對信息的需求不同于那些幾乎無法訪問網(wǎng)站并通過支付流程的客戶。在用戶特性方面，人們可能希望根據(jù)用戶過去的個人行為向用戶推薦產(chǎn)品。

這里使用的工具是標準關系數(shù)據(jù)庫。對于分析，有一種標準的查詢語言，根據(jù)數(shù)據(jù)庫系統(tǒng)提供程序，有一些自定義擴展。對于可視化，開發(fā)人員可以使用自定義報告或使用tableau之類的工具。

現(xiàn)在，如果日志大小超出了一臺計算機的存儲或計算容量，該怎么辦？如果客戶數(shù)據(jù)庫的分析在一臺機器上花費的時間太長，或者成本太高，無法通過擴展這臺機器來加快速度，該怎么辦？有一個非常簡單的答案：以apachehadoop為例。

答案不那么簡單，但可能更正確：您將無法繞過分布式系統(tǒng)進行數(shù)據(jù)分析。當選擇商品硬件時，最好的選擇是使用apachehadoop作為系統(tǒng)的基礎。你需要什么取決于你的具體情況。

輸入Hadoop

Hadoop本身有兩個組件：HDFS和MapReduce。HDFS在GNU/Linux文件系統(tǒng)之上提供了一個分布式文件系統(tǒng)（Windows還沒有得到官方支持）。它是建立在假設系統(tǒng)在商品硬件上運行的基礎上的，因此故障確實會發(fā)生。為了應對這種情況，它提供了自動故障切換和內(nèi)置復制。它還假設您正在操作硬件；磁盤掃描比磁盤查找便宜—這種假設即使對于SSD也是成立的。第三個假設是，您的系統(tǒng)將處理大量數(shù)據(jù)—由于移動數(shù)據(jù)比移動計算更昂貴，Hadoop將嘗試盡可能靠近數(shù)據(jù)運行處理，理想情況下是在存儲數(shù)據(jù)的同一臺機器上。MapReduce然后提供了編程庫來有效地利用HDFS的特性。

由于HDFS只提供原始文件存儲，因此有多個庫提供數(shù)據(jù)的結(jié)構化存儲—以壓縮二進制格式提供可升級的數(shù)據(jù)結(jié)構。例如Avro、Thrift和protocolbuffers。

HDFS本身非常適合后臺處理，但不太適合在線使用。如果您有如此多的用戶，以至于標準數(shù)據(jù)庫無法再處理流量，并且希望您的系統(tǒng)能夠與Hadoop（尤其是MapReduce作業(yè)）很好地集成，那么Apache HBase（以及Hypertable）就是需要考慮的存儲系統(tǒng)。兩者都提供了良好的在線訪問性能。

MapReduce

在分析方面，開發(fā)人員需要編寫MapReduce作業(yè)。有一個java（包括一個單獨的庫，使單元測試更容易），以及C++的API可用。不過，Hadoop還提供了一個流接口，它可以使用STDIN和STDOUT進行處理，從而支持任何腳本語言。

然而，有時開發(fā)人員不需要接觸任何一種低級編程語言。相反，查詢語言（如Pig、Latin或Hive的語言）非常接近SQL，對于大多數(shù)任務來說已經(jīng)足夠了。在語法不夠的地方，開發(fā)人員可以選擇使用自己的操作符來擴展語言。

級聯(lián)試圖在低級javamapreduce和高級Pig之間提供一個中間地帶。apachegiraph專注于處理圖形數(shù)據(jù)，包括在分析圖形時特別重要的操作符。

在編寫作業(yè)時，需要快速鏈接多個MapReduce階段?？赡苄枰獙⒂肑ava編寫的階段和用Pig編寫的階段進行混合和匹配?；谟嫊r器或基于數(shù)據(jù)可用性的觸發(fā)處理。這些任務可以由Oozie——Hadoop的工作流管理器來解決。

如果我們的目標不是提供簡單的統(tǒng)計數(shù)據(jù)，而是根據(jù)用戶購買的產(chǎn)品類型自動對用戶進行分組呢？如果目標是根據(jù)用戶偏好某種產(chǎn)品的可能性來對用戶進行分類呢？如果目標是預測用戶下一步最有可能鍵入什么查詢呢？大多數(shù)更復雜的問題都可以用某種方式來表達，使它們更容易用自動化方法來解決。apachemahout有助于解決大規(guī)模的問題，并在必要時提供Hadoop綁定。

在可視化方面，仍然需要做的是創(chuàng)建自定義報告，然后生成自定義儀表板。此外，還可以將數(shù)據(jù)導出到首選的文件格式，然后在通用工具（如gephi）中可視化結(jié)果以進行圖形可視化，或者將數(shù)據(jù)導入常規(guī)關系數(shù)據(jù)庫并使用它們的工具進行可視化。

在現(xiàn)實世界中從來沒有這么簡單過

到目前為止，我們看到的是一個完全基于apachehadoop的強大、一致的基礎設施。然而，現(xiàn)實世界中的基礎設施從來就不是那么簡單。會有一些關系數(shù)據(jù)庫繼續(xù)運行，但遷移成本太高。如果沒有與Hadoop設置很好地集成，那么這些將仍然是孤立的數(shù)據(jù)倉庫，除了最初的開發(fā)人員之外，沒有人能從中受益。直接針對數(shù)據(jù)庫運行的MapReduce作業(yè)將很快導致系統(tǒng)癱瘓。Hadoop對于生成針對現(xiàn)有系統(tǒng)的DOS攻擊非常有效。通常的做法是定期將數(shù)據(jù)庫內(nèi)容導入HDFS。使用Sqoop，有一個工具已經(jīng)被證明是可靠的。

現(xiàn)在只剩下一個可行的解決方案，將分布式系統(tǒng)中的日志文件恢復到HDFS中。對于Flume、Scribe和Chukwa，有三種系統(tǒng)可供選擇，它們有助于分布式日志記錄并提供Hadoop綁定。

退一步來看，結(jié)果看起來已經(jīng)相當清晰：數(shù)據(jù)存儲、分析和可視化都可用，現(xiàn)有系統(tǒng)集成良好。然而，現(xiàn)在我們有了軟件，可以將系統(tǒng)擴展到幾十臺、幾百臺甚至幾千臺機器。這些數(shù)字不再由任何運營團隊手動管理。相反，自動化配置管理和受控回滾選項變得越來越重要。像Chef和Puppet這樣的系統(tǒng)，以及Zookeeper這樣的配置管理系統(tǒng)，突然間成為了擴展的關鍵（圖3）。

圖3：一個復雜但連貫的拼圖

最后的畫面看起來不再那么簡單了。除了許多不同的部分和最佳實踐之外，如果要避免混合和匹配所有解決非常常見的問題但在重要細節(jié)上不同的各種系統(tǒng)，還有許多步驟涉及到有意識地對一個系統(tǒng)和另一個系統(tǒng)做出決策。

這樣的設置有什么好處？最重要的優(yōu)點是數(shù)據(jù)存儲的集成。如果數(shù)據(jù)不再在數(shù)據(jù)筒倉中分離，那么所有類型的應用程序都將成為可能，而且構建成本也會降低，因為數(shù)據(jù)不再需要從一個團隊復制到另一個團隊，而是可以供所有人使用和處理。此外，通過以一致的方式集成所有必要的數(shù)據(jù)源，業(yè)務報告變得非常簡單。

然而，可處理意味著數(shù)據(jù)格式是已知的、文檔化的或至少是自描述的。突然之間，日志記錄不再是可選的，并且在出現(xiàn)問題時需要進行調(diào)試和事后分析。突然之間，如果日志文件包含正確的信息、足夠的數(shù)據(jù)和有效的條目，那么日志文件本身就是一種資產(chǎn)。

一般來說，Hadoop的用例在引入之后很容易識別。然而，我們不應該對這樣一個系統(tǒng)的引入掉以輕心——開發(fā)人員的學習曲線仍然相當陡峭。

系統(tǒng)仍然需要在DevOps級別上考慮，這意味著開發(fā)和操作必須緊密地結(jié)合在一起才能工作。集成還沒有完全優(yōu)化，并且沒有像其他更常見的系統(tǒng)那樣做得很好。最有希望的途徑是確定一個現(xiàn)有的用例，它將從使用Hadoop中獲益匪淺。引入apachehadoop，以及支持它所需的一切，將提供足夠的經(jīng)驗來簡化和適應越來越多的用例。擁有一個驅(qū)動項目有助于關注真實的業(yè)務需求，并找出重要的特性。它還有助于決定使用什么項目來解決實際的技術問題。

Hadoop結(jié)論

總的來說，Hadoop及其生態(tài)系統(tǒng)提供了獨特的特性，允許以合理的成本擴展到商品硬件上的大型分布式系統(tǒng)。該系統(tǒng)已在生產(chǎn)中使用的兩個較大的（雅虎！，F(xiàn)acebook，Twitter）和更小的（Neofonie GmbH，nurago，nuxeo）公司來解決他們的分析需求。作為一個Apache項目，可以在合理的時間內(nèi)參與并解決問題。盡管發(fā)布周期在過去一直在增長，但項目本身發(fā)布了更快的版本，以便在更短的時間間隔內(nèi)獲得特性和bug修復。此外，項目本身將來自不同背景的開發(fā)人員團結(jié)在一起，并將來自世界各地具有大量分布式處理經(jīng)驗的團隊的知識匯集在一起，這不僅有助于強化實現(xiàn)，而且為開發(fā)新功能提供了廣泛的基礎。

幾年后發(fā)布了1.0版本，它顯示了開發(fā)人員對代碼庫成熟度的信任。在即將發(fā)布的版本中，將資源管理與計算庫分離的體系結(jié)構將變得更加靈活。這將使開發(fā)人員能夠?qū)apReduce視為一個簡單的編程庫，并獨立于集群版本開發(fā)mapreduceapi。2012年將給該項目帶來許多改進。通過加入用戶和開發(fā)人員的郵件列表，確保成為流程的一部分。您可以通過提供有價值的補丁程序來解決仍然存在的問題，從而將您的知識和工作投入到流程中來。