2013年6月29日 星期六

Hadoop Distributed Cache - 如何讓Map Reduce Job 認得 3rd-aprty Libraries



在撰寫Map Reduce Job時,我想 java.lang.ClassNotFoundException 這個問題一定排名前幾名,會發生這個問題的主要原因就是我們在寫Map Reduce Job時,可能會引用到外部 Jar 檔(3rd party Libraries),而運行Map Reduce Job的那一台機器的class path 找不到那個Jar檔而發生的問題。

當遇到這個問題大家一定馬上就會去Goolge找解決方法,而且很容易就會在網路上找到各種解法,但是很多解法你一看就會覺得很骯髒很暴力,下面是排名最常見的解法:

1. 把需要用到的Jar 檔 copy到每一台機器去,並且設定Class Path
其實這些建議都是正確的,但是只適合在開發階段和單機環境,一旦到了真正的叢集運行環境就不能這樣搞了,試想想100台以上的Cluster那不是要Copy到死!?而且一但Jar檔如果要升級和更新,那更是一場災難

2. 透過Hack的招數,寫程式把會用到的外部Jar檔Class Path找出來
太暴力了,直接跳過~:P

3. 最建議的方法是使用Hadoop Distributed Cache

作法如下:

1. 把所需要的Jar檔Copy到Hdfs路徑下
 
# bin/hadoop fs -copyFromLocal mylib.jar /lib/mylib.jar
or
# bin/hadoop fs -put myjar.jar /lib/.

2. 在你的程式裡面設定Distributed Cache 設定
JobConf job = new JobConf();
DistributedCache.addCacheFile(new URI("/lib/mylib.jar#mylib.jar"), job);
DistributedCache.addCacheArchive(new URI("/lib/mylib.jar#mylib2.jar", job);


嗯看起來這樣就可以解決問題了!不過還是不夠方便,因為這時候已經把Lib 的名稱和路徑以及數量 Hard Code在程式裡面了,如果要改路徑怎麼辦?如果Lib要升級該怎麼辦?所以這時候就有請Spring Hadoop 出場~~

真的非常簡單,只要在Spring 的設定裡面加入下面內容,這樣甚至都不用寫在程式裡面,因為透過Spring Hadoop的設定,直接就把這些值寫入Hadoop Configuration 裡面了。


<hdp:cache create-symlink="true">
   <hdp:classpath value="/lib/mylib.jar#mylib.jar" />
   <hdp:classpath value="/lib/mylib.jar#mylib2.jar" />
</hdp:cache>



雖然看起來很簡單的幾行,卻花了好多時間才找到正確的用法,與最方便得設定方式....

深深覺得網路上關於Hadoop的教學資源大多只是極度簡化的範例程式(最常見的就是word count) 但是離開發真實商業應用系統還非常的遠,而且相關的文章更是少的可憐...Orz..


Reference:
[1] Hadoop Distributed Cache tutorial


2013年6月23日 星期日

ApacheCon2013 - Hadoop and HBase on the Cloud: A Case Study on Performance and Isolation

圖片來源:改編自網路圖片

(這篇真的壓了好久喔....Orz...沒時間好好研究和收集這方面的資料...)

還記得之前我之前曾經寫過兩篇文章:到底功夫熊貓(Xen)踢不踢的動大象(Hadoop)呢和"要使用大象,真的得養頭大象嗎?為何不使用AWS EMR,剛好這次ApacheCon2013就有談到這個題目:
Hadoop and HBase on the Cloud: A Case Study on Performance and Isolation.
by Konstantin Shvachko, Jagane Sundar

這個talk討論的正是如何用虛擬化提高Hadoop的使用效能!? 一般來說談到虛擬化,第一直覺反應通常是使用後往往會拉低使用效能,怎麼反而還可以提高呢?所以這個題目讓我特別感興趣,讓我們來看看他的論點。

首先他的假設前提是 "Low average CPU utilization on Hadoop Clusters",因為他認為Disk I/O和Network 都是可以透過設計和規劃提高一定的效能,但是CPU utilization is bad,他列兩點原因:
  • IO bound workloads preclude form using more cpu time
  • Cluster provisioning:
    • peak-local performance vs average utilization trade-off

不過他下面show的圖只能說使用Virtualization 會更有效率的使用CPU,就把它操的很忙....




所以結論是...?




不過其實上面的這些假設與如何實現不是重點,重點是聽到下面幾個不錯的Benchmark提供參考,因為當你安裝好Hadoop後,你要怎麼知道你的Hadoop設定的對不對,Performance是好不好?是否有達到一定的水平?



Reference:
[1] How to Benchmark a Hadoop Cluster
[2] How can I run a DFSIO test on MapR?
[3] Benchmarking - DFSIO, Terasort
[4] Benchmarking Hadoop & HBase on Violin
[5] Apache hadoop performance-tuning methodologies and best practices
[6] AMD Hadoop Performance Tuning Guide
[7] Benchmarking and Stress Testing an Hadoop Cluster With TeraSort, TestDFSIO & Co.

2013年6月22日 星期六

[書摘] 大數據 - 第三章- 雜亂


圖片來源:博客來


知名物理學家課耳文勛爵(Lord Kelvin)主張測量就是瞭解,這也變成科學的依據:要能夠量化,記錄,還得呈現出可重複的驗證。不過到了1920年量子力學 - 測不準原理的出現推翻了全面完整測量事物的夢想,

所以面對資料我們要改變的第二種心態就是 - 開始容忍種種不精確

很多時候"越多",會比"品質越好"更重要 ,由於我們收集技術精確性會受到物理性質限制,與技術限制,所以我們必須改以透過增加取樣頻率,增加收集資料量來克服這些問題。

也就是說,巨量資料的概念,就讓數據的重點從精確走向可能性。 (阿~又是機率和統計~)

案例連結:

1. 自然語言處理 - 在這個領域已經證明資料的量比品質還重要

對於所有的Machine Learning 的研究來說,都會遇到一個問題,是要把資源投給改善更好的演算法,還是要收集更多的資料?這結果也由Googel 證實,Google 人工智慧專家諾威格等人,在一篇名為"資料的非理性效果"文中提到:簡單的模型,加上大量的資料,就會打敗很複雜,但是資料較少的模型。


2. 拋棄昂貴費時的精確資料收集方式 - PriceStats  

MIT教授創業的公司,透過網路抓取全美超過50項產品價格,現在更是蒐集超過70個國家,數百名零售商銷售的產品價格,來分析消費者物價指數(CPI),雖然充滿了混亂和不乾淨的資料,但是即時性與準確度已經超越官方公布的數據。


圖片來源:PriceStats 





3. 資料庫設計的改變 - NoSQL崛起

在這個章節罩慣例有提到 Hadoop 的技術(但是描述怪怪的 --> 與過去的關聯式資料庫相比,Hadoop輸出的結果比較不準確....=_=?)


應用案例 - ZestFinance

這間由前Google 資訊長所成立的公司,透過許多過去信用評分公司認為相對不重要的指標來判斷是否要提供小額短期貸款。

圖片來源:ZestFinance



心得:

心態與觀念改變的確很重要,但是前提是要有相對應的技術能量(數學與分析能力)去處理,否則縱使擁有越多的資料,還是無法挖掘出有價值的東西...