2009年7月9日 星期四

飛上雲端賞趨勢

最近這週是趨勢雲端程式設計比賽的初賽,標題是我們這隊的隊名,很有意境對吧!現在想想,那賞完趨勢怎麼下來呢?@@



感謝國川、憲哥、麒文三個大三學弟邀約,也感謝老師跟SCREAM Lab給我的時間跟空間,讓我有這個機會感受一下這久違的爆肝寫程式經驗,跟以前專題或期末不同的是,這次的題目訂得很鬆,不太明確,所使用的平台 Hadoop DFS 跟 HBase 又都還是開發中的東西,版本問題一堆,所以比賽過程中我們花許多時間在溝通跟找資料。另一個不 同點是,我練習到 oral programming 的技巧了,前幾天我幾乎都沒寫到太多程式,都在找資料然後改API,然後請隊友去試試看這樣。XD

時間來到中段,變成討論最後要呈現什麼功能跟效果,因為題目沒訂,導致一直到最後一天還是在修改。最後一天沒睡,決定捨棄題目建議的網頁呈現方式,用java swing來實作。雖然畫面趕工的痕跡處處可見,不過程式的分工我還滿滿意的,學弟那邊的程式出Exception我畫面也不會當掉,要加功能也不會動到別人的code。

這次比賽的心得是,有準備的就是贏家!我們賽前只有架好 HDFS Clusters,比賽後發現 Hbase 不用不行,當然更不用說趨勢提供的Cygwin or vmware solutions,一定不可能跑得動的。而這期間我們還發現許多 API 因版本不同而支援度不同的問題,有些只是換了目錄,有些是寫法跟名稱都換,google 上的 solution 多半是舊版的,只能從 hadoop package 中找 source code 。如果之前就有接觸過這方面的隊伍就可以跟往年的比賽一樣,專心去想問題的解決方案。

murmur分隔線

這好像是我第一次熬夜中完全沒小睡的,4285的冷氣很涼溫度也很穩定,眼睛盯著x200的畫面讓我不知不覺就聽到的早晨的鳥叫聲,我今天才知道成大早鳥叫的真的非。常。的。大聲!

中午結束後,我回家吃完飯洗個澡,一路睡到五點半,七點下樓去吃老媽煮的飯,她當時騎車出去不在家。當我吃下第一口菜時,不知為何我的鼻頭超酸,想想,我確實很久沒有吃到家裡的飯了,在經歷一番硬仗後,能在家裡吃到一頓充滿關愛的晚餐是最幸福的了,女人的廚藝果然是用來綁住男人的利器啊!

12 則留言:

Royce Lu 提到...

好羨慕啊^^Y 聽起來超讚的經驗

87showmin 提到...

怎麼會羨慕呢?你們在職場不就也常做嗎?X :p

紅苺跳跳糖 提到...

哈哈 學長才是提供意見最多的阿 要跟三個小毛頭一起比賽 應該沒有提出太過天馬行空的想法讓你大笑一下吧 我隊長好像都沒有用處 Java又不行 Linux都要問憲哥 連jar檔我都壓了半天還壓壞 這也是我第一次在系館待到跨夜都沒回家 第一次的LAB位置初體驗是在豪華的IPS面板冷氣風頭下的舒適座位耶 突然想轉LAB 謝謝學長這幾天抽空跟小毛頭們做事拉 有晉級與否都要吃個八卦慶功宴吧

87showmin 提到...

哈哈,那就定在放榜那天吧~話說是幾號放榜啊?

centcent 提到...

很棒的經驗
這經驗應該對你以後很有幫助吧
不過
小murmur一下
以後用別人的位置記得要恢復原狀 哈

金*3 提到...

hello,你好,我們也有參加這次的比賽,
不知道你們有沒有入決賽呢

不知道有沒有興趣可以分享經驗呢

87showmin 提到...

hello 帥哥你好,我們有收到"很遺憾您未能晋級前十強"的通知信了,你們應該有晉級吧?我們很樂於分享這七天的經驗的,歡迎你提出疑問囉。

金*3 提到...

恩,我們沒有入選…雖然去台北聽課時大概有猜到題目出的內容,及用 hbase 大概也是必需的,但還是沒用,我們沒有具體的解決方案,我們這組只有針對可能需要的"效率"做出來,想說如果有入選再慢慢想其他的。

想請教的是,有看到你們也是使用 hbase
能否問一下 hbase 設計方面的問題嗎?
很好奇別組是如何設計 hbase 的

87showmin 提到...

這是個好問題。

因為我們事前也沒特別去做有關HBase的功課,直到拿到題目那天,我們發現光用一個200MB的測試檔,將它put到HDFS下再跑wordcount例子就要花很多時間,而且題目又有欄位上作分類的需求。

我們HBase的設計還滿粗略的,一開始我們先將所有資料建至一個mother table,row key是counter(連續且唯一),column就是ip, port, rating這些資訊。

之後,就看需要什麼資料,就從這個table找,例如,如果要對rating做sort or grep,就用TableMap/ TableReduce去找就好了。

找到的資料我們會再另存成一個小table,方便之後如果還有執行同樣的需求時就可以直接讀小table就好。

美中不足的是,我們最後送交的HBase似乎只能在某台電腦上作用,而且其實HBase 0.19.3 問題還是很多,速度也超慢,0.20 alpha 在比賽時已經放出來了,有文件說速度快了20倍。 =_=a

我們沒有特別想在HBase的效率上花功夫,一方面是傾向於先將功能做完整,另一方面是HBase本身還有很大的進步空間,花太多時間在它身上不太划算啦。@@a

金*3 提到...

我想 hbase 在 0.20 好像改變比較多關於 regionserver 的 code, 也許是這樣才會讓整體速度像 scan get 等的功能變快好幾倍。

我們也是有個記錄所有資料的 mother table
也是將每次的查詢存入小 table
本來想說 map, reduce class 獨立開來以後比較好寫程式(想說有入選再想)
(上傳到趨勢時 map reduce class 完全只有 output.collect 的動作)

嚴格來說剛提到的"效率"只是將所有 filter 的功能都整理出來方便使用,因為有針對 row filter 及 cell value filter 的數種內建的類別能用

至於 column 則是用 table.getScanner 裡面所提的加些像 regex 來做過濾,
可很惜 0.19.3 裡使用 bloomfilter 會造成 crash, 不過在 0.20 又似乎是正常

我們 table 的 rowkey 是將 hostname reverse 來用
想說 hbase 會作 sort , com.facebook.xxxx 排在一起應該會比較有效率,而為什麼使用 hostname 則只是想將 rowkey 的數量減少,而且比較有意義

其他做的就是自動更新資料到 hbase 的程式及簡單的網頁 UI 而已

金*3 提到...

好像有點晚了,但謝謝你的分享
雖然目前還是有很多問題,但也許是我還在學校讀書的目的

希望有機會還能討論討論
畢竟能同時遇到在研究相同東西的人機率不多

87showmin 提到...

謝謝你的分享,我想你們在找資料時應該也有發現到,無論是HBase或Hadoop API,它們的改變都很快,現階段要玩這東西還是需要不少時間的survey,網路資源也都是舊版的居多。相信之後他們會將常用的功能都寫成最有效率的API供programmer使用,也不會留bug在裡面。