數據分析≠Hadoop+NoSQL，不妨先看完善現有技術的10條捷徑(分享)
Hadoop讓大數據分析走向了大眾化，然而它的部署仍需耗費大量的人力和物力。在直奔Hadoop之前，是否已經將現有技術推向極限？這里總結了對Hadoop投資前可以嘗試的10個替代方案，省時、省錢、省力，何樂而不為？
讓業務搭乘大數據技術確實是件非常有吸引力的事情，而Apache Hadoop讓這個誘惑來的更加的猛烈。Hadoop是個大規模可擴展數據存儲平臺，構成了大多數大數據項目基礎。Hadoop是強大的，然而卻需要公司投入大量的學習精力及其它的資源。
如果得到正確的應用，Hadoop確實能從根本上提升你公司的業務，然而這條Hadoop的應用之路卻充滿了荊棘。另一個方面，許多企業（當然不是 Google、非死book或者推ter）的數據體積并沒有大到需要巨型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
讓業務搭乘大數據技術確實是件非常有吸引力的事情，而Apache Hadoop讓這個誘惑來的更加的猛烈。Hadoop是個大規模可擴展數據存儲平臺，構成了大多數大數據項目基礎。Hadoop是強大的，然而卻需要公司投入大量的學習精力及其它的資源。
如果得到正確的應用，Hadoop確實能從根本上提升你公司的業務，然而這條Hadoop的應用之路卻充滿了荊棘。另一個方面，許多企業（當然不是 Google、非死book或者推ter）的數據體積并沒有大到需要巨型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