資料分析≠Hadoop+NoSQL

標籤：

 資料分析≠Hadoop+NoSQL 

目錄(?)[+]

         Hadoop讓大資料分析走向了福士化，然而它的部署仍需耗費大量的人力和物力。在直奔Hadoop之前，是否已經將現有技術推向極限？這裡總結了對Hadoop投資前可以嘗試的10個替代方案，省時、省錢、省力，何樂而不為？

       讓業務搭乘大資料技術確實是件非常有吸引力的事情，而Apache Hadoop讓這個誘惑來的更加的猛烈。Hadoop是個大規模可擴充資料存放區平台，構成了大多數大資料項目基礎。Hadoop是強大的，然而卻需要公司投入大量的學習精力及其它的資源。

如果得到正確的應用，Hadoop確實能從根本上提升你公司的業務，然而這條Hadoop的應用之路卻充滿了荊棘。另一個方面，許多企業（當然不是Google、Facebook或者Twitter）的資料體積並沒有大到需要巨型Hadoop叢集去做分析，他們純粹是被“大資料”這個熱門的詞語給吸引的。

就像Dabid Wheeler所說“電腦科學的所有問題都有另一個層次間接的解決方案”，而Hadoop正是類似間接解決方案；當你的上司被一些流行詞彙所吸引時，做正確的軟體架構決策將變的非常艱難。

下文將給出一些對Hadoop進行投資前需要嘗試的替代方案：

 

 

1.  瞭解你的資料

1、資料的總體積

 

Hadoop是為大型資料集所建立的有效解決方案。

 

• GB級以上的檔案系統HDFS。因此如果你的檔案只是MB級的，你最好對數個檔案進行整合（zip或者tar），讓其達到數百兆或者是幾GB。
• HDFS會將檔案分割，並以64MB、128M或者更大的塊進行儲存。

 

如果你的資料集非常的小，那麼使用這個巨型生態系統將不會很適合。這需要對自己的資料有足夠的瞭解，並且分析需要什麼類型的查詢以及你的資料是否真的夠大。

另一方面，鑒於你的計算指令可能很大，只通過資料庫去測量資料的體積可能會存在誤差。有時候數學計算或者分析小型資料集的排列可能會讓得出的結果遠大於實際資料體積，所以關鍵在於你對資料有切實的瞭解。

2） 資料的增長速度

你可能在資料倉儲或者其它的資料來源中存有數TB資料，然而在建立Hadoop叢集前有一個必須考慮的因素就是資料的增長速度。

對你的分析師提出幾個簡單的問題，比如：

 

• 資料增速究竟有多快？這些資料是否以非常快的速度增長？
• 幾月或者幾年後資料的體積究竟會有多大？

 

許多公司的資料增長都是按年算的。這種情況下，你的資料增長速度其實並不快；所以這裡建議考慮歸檔和清除選項，而不是直接的奔往Hadoop。

 

2.  如何減少需處理的資料

 

如果你確實有非常大體積的資料，你可以考慮通過以下的途徑將資料縮減到非常適合管理的體積，以下的幾個選項已經過產業幾十年考驗。

  1) 考慮歸檔

資料存檔是對到期的資料進行分開儲存，當然儲存的時間根據實際需求制定。這需要對資料以及應用程式對資料的使用方式，有非常充分的瞭解。比如電子商務公司的大資料處理只將3個月內的資料存入活躍資料庫，而舊訂單則被存入單獨的儲存。

這個途徑同樣可以運用於你的資料倉儲。當然你可以儲存更多的近期資料用於報告和查詢，使用頻度少的資料可以被存入單獨的存放裝置。

  2) 考慮清除資料

有時候我們一直忙於收集資料而不清楚究竟需要儲存多少資料，如果你儲存了非常多用不到的資料，那麼這將毫無疑問的降低你有效資料的處理速度。弄清你的業務需求並且審查資料是否可以被刪除，從中分析出你需要儲存資料的類型，這不僅會節省你的儲存空間，同樣會提升有效資料的分析速度。

一個經常用到的最佳實務就是給資料倉儲建立附加列，比如created_date、created_by、update_date及updated_by。通過這些附加列可以對資料進行階段性的訪問統計，這樣就可以清楚資料的有效周期。這裡需要著重對待的是資料清除的邏輯，切記先思考再實現。如果你使用了一個歸檔工具，那麼資料的清除將會變得非常容易。

    3) 不是所有的資料都很重要

你可能受不了儲存所有業務相關資料的誘惑，你可能有很多的資料來源，比如：記錄檔、營銷活動資料、ETL作業等。你需要明白不是所有資料都對業務起關鍵作用，而且在資料倉儲中儲存所有的資料並不是有益的。在資料來源過濾掉不需要的資料，甚至是在儲存到資料倉儲之前。不要對所有的資料進行儲存，只分析你所需的資料。

    3）注意哪些資料是你想要收集的

拿線上視頻編輯業務來說，你會需要儲存你使用者做出的所有操作嗎？這樣的話可能會產生非常大的資料體積，如果你發現你的資料倉儲不足以應對這些資料，你可能會考慮只儲存中繼資料。雖然視頻編輯是個非常極端的例子，然而並不妨礙我們在其它用例中考慮這些資訊。

總而言之，根據業務的需求只收集所需要的資料。

 

 

3.  智能分析

 

 1）聘請瞭解業務的分析師

到目前為止，你應該已經清楚理解資料的重要性；所以在你做了上面所有步驟後並決定使用Hadoop時，聘請1個瞭解業務的分析師將會對你業務產生巨大協助。

如果資料分析師不懂如何從中擷取價值，那麼Hadoop將不會產生任何作用，不要吝嗇對業務有深刻認識的僱員投資。鼓勵他們多做實驗，並且使用新的方式去分析同一個資料，找出使用現有基礎設施獲利的途徑。

  2）為決策制定使用統計抽樣

統計抽樣可以說是非常古老的技術，研究者及數學家運用它在大體積資料上推斷合理的結論。通過這個步驟，我們可以大幅度的縮減資料體積。取代追蹤數十億或者數百萬的資料點，只需要跟蹤其中數千或者數百的資料點就可以了。這個手段雖然不會給我們提供精準的結果，但是卻可以對大型的資料集有一個高等級的理解。

 

 

4.  提升技術

 

 

你真的已經達到關係型資料庫處理的極限了嗎？

在探索其它領域之前，你更應該審視關聯式資料庫是否可以繼續處理問題。傳統的關係型資料庫已經被使用了很長一段時間，而很多機構已經可以使用它管理TB級的資料倉儲。所以在遷往Hadoop之前，不妨考慮以下的方法。

1）分割資料

資料切分是從邏輯上或物理上將資料分割成數個更好維護或訪問的部分，同時很多流行的開源關係型資料庫都支援分區（比如MySQL Partitioning及Postgres Partitionging）。

2）在傳統資料庫上考慮資料庫分區

資料庫分區是提升傳統關係型資料庫效能極限的最後一招，適用於資料可以邏輯分區在不同節點上並且很少做跨節點join分享的情況。在網路應用程式中，基於使用者分區，並將使用者相關資訊儲存在同一個節點上是提升效能的常見途徑。

分區有很多限制條件，所以並不是適合所有情境，同樣在用例中存在太多的跨節點jion，分區將發揮不了任何作用。

總結

Hadoop的部署將耗費公司巨量的人力和物力，如果能通過提升現有基礎設施來達到目標也不失為一良策。

原文：http://www.csdn.net/article/2013-07-19/2816277-hadoop-when-to-use

資料分析≠Hadoop+NoSQL