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



心得:

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



2013年6月16日 星期日

[書摘] 大數據 - 第二章- 更多的資料

圖片來源:博客來

前一陣子寫了一篇關於BigData的基本問題 - 到底要多大?要多快? 原本嘗試著要用物理性質的角度來思考到底多大才算是大數據,何時才需要使用不同於傳統的技術?

但是看了這本書才看了第二章馬上就給我不同的思考角度,首先他先說明巨量資料是關於三種思維的改變:
  1. 是要針對特定主題分析龐大資歷料整理的能力,而不是退而求其次分析較小的資料集
  2. 願意接受真實資料會雜亂不清的事實,而不是一味追求精確
  3. 要更看重相關性,而不是追求難以捉摸的因果關係

針對第一點, 他不是用一般傳統的4V去解釋Big Data,他是用如何處理資料的角度來解釋何謂Big Data。

在這章節給Big Data (巨量資料) 下了一個定義:
巨量資料的"巨量"不是絕對、而是相對的概念,指的是要有完整的資料集。 

在過去因為受到收集與計算技術的限制,難以全面性的收集資料,所以統計學才因此誕生,而其中最核心的方法就是在抽樣,不過統計學家也證實要提高抽樣的準確度,最好的方式並非增加樣本術,而是要做到隨機抽樣 (不過要如何設計一個好的隨機抽樣永遠都是一個難題,而且會有局限性)

因此真正得巨量資料判斷標準,在於是否使用隨機抽樣*, 也就是說就算全部的資料(樣本=母體)資料量不一定很龐大,但是不再使用抽樣的方法去操作資料就是所謂的巨量資料。


不過第三點就很值得玩味,作者舉了Google 流感,與Jobs DNA定序的例子,指出很多時候我們只要能透過全面資料運算,看到有這樣的模式/現象,其實就足夠了,不一定要去追求為什麼會有這樣的現象/模式或是嘗試去了解它們交互關係原理是什麼。

(謎之音:找到能賺錢的價值就夠了,至於原因上帝知道就夠了~)

圖片來源:Only God knows

(謎之音:看樣子這大數據這本書比雲端時代的殺手級應用:Big Data海量資料分析 有內容多了,也多了一份哲理在~:P  就讓我們繼續看下去....)

延伸閱讀:
[1] 抽樣方法
[2] 抽樣與代表性 (Sampling and representativeness)



[筆記] Spring Annotation 的意義



在很多網路上的範例程式,常常都會看許多相同的場景卻用到到各種不同的寫法,最常見的就是Spring的Annotation,到底什麼時候該用什麼樣的annotation呢?

參考stackoverflow這篇文章 What is the most appropriate way of injecting daos in services, services in controllers in Spring? 的解釋:

@Service and @Repository are just "sub-annotations" for @Component to specify the bean a bit more (to separete Services from Repositories for more sophisticated stuff). From the point of injection this three are equal.
For injection, there are 3:
也就是說@Autowire是spring原本在使用的Annotaion,而@Resource和@Inject 是後來定的業界標準,新版的Spring也都可以相容,如果沒有打算使用其他Ioc的framework如Google-guice,那還是仍然可以使用Spring原生的annotation。

詳細的比較可以參考Spring 3.1 - beans-standard-annotations-limitations

Table 4.6. Spring annotations vs. standard annotations
Springjavax.inject.*javax.inject restrictions / comments
@Autowired@Inject@Inject has no 'required' attribute
@Component@Named
@Scope("singleton")@Singleton The JSR-330 default scope is like Spring's prototype. However, in order to keep it consistent with Spring's general defaults, a JSR-330 bean declared in the Spring container is a singleton by default. In order to use a scope other than singleton, you should use Spring's @Scope annotation.
javax.inject also provides a @Scope annotation. Nevertheless, this one is only intended to be used for creating your own annotations.
@Qualifier@Named
@Valueno equivalent
@Requiredno equivalent
@Lazyno equivalent



Reference:
[1] Spring 3 and JSR-330 @Inject and @Named example


2013年6月9日 星期日

關於BigData的基本問題 - 到底要多大?要多快?

圖片來源:technode

關於BigData的基本問題 - 到底要多大?要多快? 才需要從RDB 換到Hadoop?我們常常可以看到下面這種再說明全世界一直再快速的產生資料:



但是這些東西都離我們太遠了,畢竟我們不是Facebook,我們也不是youtube,那對於一般企業來說怎樣的資料算是大?怎樣的資料量需要轉移使用Hadoop的技術呢?

首先要思考的問題是傳統資料庫在怎樣的資料量下,擁有怎樣的效能是合理的?當資料量超過多少以後,則效能才會有顯著的差異,此時才比較適合換成NoSQL Solution? 不過這個問題可能還是得分成兩種狀況來討論:
  • 資源足夠的大企業(大多以Oracle為首選標準配備)
  • 一般網路公司中小企業 (可能就是用MySQL / PostgreSQL...等選擇)


那先來看看Oracle,剛好我Google到一篇文章-What is The Maximum Datafile Size Limit In Oracle Database 10gR2 ,這篇文章參考Oracle 11g 提供的文件 Physical Database Limits,主要是再描述Oracle可以儲存多少的資料,一般來說Oracle有兩種 Database Block Size:
  • Small File Tablespace (Normal Tablespace)       : 4194303    (2^22 -1) 
  • Big File Tablespace   (New in 10gR2)                : 4294967295 (2^32 -1) 
Database Block Size
Maximum Datafile File Size
2k
4194303 * 2k    = 8 GB
4k
4194303 * 4k    = 16 GB
8k
4194303 * 8k    = 32 GB
16k
4194303 * 16k  = 64 GB
32k
4194303 * 32k  = 128 GB

Max datafile size for BIG FILE TABLESPACE would be:

Database Block Size
Maximum Datafile Size
2k
4294967295 * 2k   = 8 TB
4k
4294967295 * 4k   = 16 TB
8k
4294967295 * 8k   = 32 TB
16k
4294967295 * 16k = 64 TB
32k
4294967295 * 32k = 128 TB

如果block size 是32KB,則單表空間(DataFile Size)最大可以長到128TB,而一個數據庫最多有64K表空間,則可以計算出理論上的極限值是128TB *64 K= 8192 PB= 8EB 這是能儲存的理論極限值,但是實務上不可能會這樣使用,更何況還要考慮其他因素,比如說做系統的的FileSystem,實際硬體的儲存媒介...等。

不過知道可以存多少有意義嘛?資料庫之所以有意義,重點不是在於能儲存多少,而是這麼多資料能在多少時間內Query出來,因為資料越多Performance 一定會越糟,而傳統DB又只能用Scale Up的方式去擴增,不像Hadoop是用Scale Out的方式,關於這點我們可以參考Oracle的這篇文章,Sizing for data volume or performance or both?,近幾年來Oracle也提出不少與Hadoop借接混搭的Solution & Architecture,以及Big Data Appliance ,那他怎麼看待這個基準線呢?直接節錄結論:
You will need to worry about the processing requirements and you will need to understand the characteristics of the machine and the data. You should not size a system, or discard something as too big right away by just thinking about your raw data size. You should really, really consider Hadoop to be a system that scales processing and data storage together and use the benefits of the scale-out to balance data size with runtimes.

雖然Hadoop的硬碟花費可能會是傳統DB的 三倍以上,但是他可以透過增加機器來維持甚至增加運算的效能,所以我好奇的是Break Even point 在哪裡?怎樣的資料才需要使用這些技術? 不然這些"為了未來Scale out 做準備 "的 slogan 就只是一般商業行銷用的話術, 很多網站和企業說實在資料根本不會成長到那麼大....)


基於這個問題我開始上網找一些資料,首先先來看看業界的實際案例,到底在怎樣的資料大小下,傳統的RDB會出現無法接受的效能呢?

案例一:Hadoop World 2011: Replacing RDB/DW with Hadoop and Hive for Telco Big Data

這是國外一家電信商在做CDR分析的案例,每個月將近15TB的資料, 一年可以達到254TB


案例二:Case Study - How Rackspace Query Terabytes Of Data
  • Rackspace has more than 50K device
  • System store 800 million object (an object=email or log) within Solr
  • 9.6 billion records within Hadoop = 6.3TB compressed
  • Several hundred gigabytes of email log data

案例三:Hadoop Use Cases and Case Studies

在這裡面有列出各個產業的案例以及資料量,最低標準至少是 1TB of data / month


其實沒有一個定論,只能引用Agile與Lean的名言:No Big Design Up Front (BDUF),不要預先想太多太早最佳化,可能我們應該就像這家遊戲廠商一樣,真的遇到大量資料的問題了在想辦法轉移就好~:P