最近這週是趨勢雲端程式設計比賽的初賽，標題是我們這隊的隊名，很有意境對吧！現在想想，那賞完趨勢怎麼下來呢？@@
感謝國川、憲哥、麒文三個大三學弟邀約，也感謝老師跟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 則留言:
好羨慕啊^^Y 聽起來超讚的經驗
怎麼會羨慕呢？你們在職場不就也常做嗎？X :p
哈哈 學長才是提供意見最多的阿 要跟三個小毛頭一起比賽 應該沒有提出太過天馬行空的想法讓你大笑一下吧 我隊長好像都沒有用處 Java又不行 Linux都要問憲哥 連jar檔我都壓了半天還壓壞 這也是我第一次在系館待到跨夜都沒回家 第一次的LAB位置初體驗是在豪華的IPS面板冷氣風頭下的舒適座位耶 突然想轉LAB 謝謝學長這幾天抽空跟小毛頭們做事拉 有晉級與否都要吃個八卦慶功宴吧
哈哈，那就定在放榜那天吧～話說是幾號放榜啊？
很棒的經驗
這經驗應該對你以後很有幫助吧
不過
小murmur一下
以後用別人的位置記得要恢復原狀 哈
hello，你好，我們也有參加這次的比賽，
不知道你們有沒有入決賽呢
不知道有沒有興趣可以分享經驗呢
hello 帥哥你好，我們有收到"很遺憾您未能晋級前十強"的通知信了，你們應該有晉級吧？我們很樂於分享這七天的經驗的，歡迎你提出疑問囉。
恩，我們沒有入選…雖然去台北聽課時大概有猜到題目出的內容，及用 hbase 大概也是必需的，但還是沒用，我們沒有具體的解決方案，我們這組只有針對可能需要的"效率"做出來，想說如果有入選再慢慢想其他的。
想請教的是，有看到你們也是使用 hbase
能否問一下 hbase 設計方面的問題嗎？
很好奇別組是如何設計 hbase 的
這是個好問題。
因為我們事前也沒特別去做有關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
我想 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 而已
好像有點晚了，但謝謝你的分享
雖然目前還是有很多問題，但也許是我還在學校讀書的目的
希望有機會還能討論討論
畢竟能同時遇到在研究相同東西的人機率不多
謝謝你的分享，我想你們在找資料時應該也有發現到，無論是HBase或Hadoop API，它們的改變都很快，現階段要玩這東西還是需要不少時間的survey，網路資源也都是舊版的居多。相信之後他們會將常用的功能都寫成最有效率的API供programmer使用，也不會留bug在裡面。
張貼留言