中翻英，線上翻譯測試 － Google Strikes Back！

( 這篇寫於 2008-10-26，不知為啥從 Blog 裡消失了，所幸 Google Reader 裡有備份。 )

剛才無聊看看 Google Analytics ，發現本站最熱門的文章還是那篇《中翻英，線上翻譯測試》，我不知該說什麼，這不是件令人高興的事啊。總之，一時興起又來測看看。

最近 Google 翻譯似乎變強了，果然有在學習啊！輸入問題如下：

我要代替月亮來懲罰你

兩年前 Google 的回報令我很失望：

I want to punish you replace Moon

沒想到現在 Google 幾乎翻對了！

I want to punish you in place of the moon

google 一下會發現有不少人提到類似的句子，附帶一提，個人心目中最完美的翻譯是：

In the name of the moon, I will punish you!

其它家翻譯結果沒什麼變，就不再貼了。

另外再測了之前亂測的中文詩詞，有些變化，不過說不上是變好變壞，都很糟就是了。看來博大精測的中文仍是機器翻譯無法跨越的高牆，也是國高中生們無法跨越的牆啦。

Gmail 裡好用的 Quick link 和 Right-side labels

之前因為 label 太多，而找了 Folders4Gmail 把一些 label 合成一個資料夾，剛才發現 Gmail labs 裡的 Right-side labels 可以把 label 放到右邊，這樣就更完美啦！這年頭螢幕都很寬很大，反而讓文章變得不好讀，多放些東西在右邊，少捲動一下螢幕，用起來方便多了！Gmail labs 裡還有很多有趣的東西，像 Quick link 可以把 search 的輸入存成 link，比方《[tip] 善用 Gmail 新功能 化身超強 ToDo List》裡提到可以用 has:attachment (*.pdf || *.doc) 來找附加檔。

備註

Gmail labs 位於 Settings -> Labs。

Google File System

最近 Google 在推 MapReduce 這個平行計算 framework，讀完 paper 後，覺得滿有意思的，若有些 network programming 和 functional language 的基礎，讀起來應該滿輕鬆的。除了好奇之外，一方面也是想讀點技術性的論文，看看和平常讀的 data mining、information retrieval 論文有什麼差，又找了 GFS 的 paper 來讀，結果還滿有趣的。

先提個技術無關的事，這篇的 Acknowledgments 最後一句寫著：

Many of our colleagues at Google bravely trusted their data to a new file system and gave us useful feedback.

令人會心一笑。

這篇論文一開始先說明作者的需求。依他們的使用環境，提了些使用上的假設，像是硬碟常壞掉、設備不可靠，可是 file system 的可靠度是首要目標；random write 少、append 多；還有 small random read、large sequential read。接著依這些操作特性，自訂需要的 file system，對我這類看重實務面的人來說，這種開頭很合我的喜好，有些學術性論文討論的是尚未存在的需求，較難接受作者的假設。描述整篇論文太累了，這裡摘要一些我認為有趣的設計：

• GFS 是架在 Linux file system 之上的 file system，這樣做的好處是善用Linux既有開發，簡省開發時間。雖然作者也提到因為Linux kernel bug，使得系統有些不穩，逼迫他們自行改 Linux kernel，整體來說，作者認為這個決定是正確的。我原本還以為GFS會自己重弄一個file system。
• GFS的主要目的是穩定和處理大量資料，所以分散式系統是理所當然的設計。但有趣的是，GFS 採用 single master server，理由是設計簡單。
• GFS由 one master、many chunkservers、many GFS clients組成。
• 為了達到single master，整體設計做了許多對應措施，如盡可能減少master的負擔，GFS client直接和chukserver拿資料；要寫入資料時，也是chunkserver之間互傳，master只記meta data。
• 為了讓 meta data能全塞入memory，metadata格式很簡單，並有做 file path 的 prefix compression。實驗部份指出上百TB的data，meta data只占數十MB。
• 沒有「目錄」的存在，所有檔案的是用絕對路徑表示，這樣做的好處有：省下目錄的資料結構；可以同時多個client新增同一目錄下的檔案，沒有目錄，自然不需要對目錄要write lock（但「目錄」仍然有 read/write lock，用在別的場合）。
• 整體採用duplicate data確保availability，chunkserver有存各個data block的checksum，送出資料時有先確認沒有損毀，確保reliability。
• 不同檔案可以有不同的replication factor，預設值為3；常被使用的執行檔可以設為上百，避免同時多個application client用到而造成bottleneck。
• 寫入檔案時，為確保各個replication一致，做起來不簡單；master會指派一個chunkserver負責資料更新。值得注意的是，由於寫入動作的複雜度，有時會先等一會，再批次處理對同一檔案的不同寫入。
• 更新資料分兩部份：資料流會依chunkserver相對位置傳，並把資料切成數小塊，行成一直線的pipeline傳資料，減少傳輸的lantency。
• 接著由master指派的chunkserver指示所有有關的chunkserver用同一順序寫入資料，確保即使同時有多種寫入同一資料的操作，寫入完後同一份資料在不同chunkserver上仍然一致。
• replicate data時，不止要考慮放在不同chunkserver，還要放在不同rack，使得swtich壞了或某機房停電時，仍能保證資料的存取。
• master待load較輕時，會在background簡查metadata的正確性、data replication是否有達到正確的數量，並依確少的程度補救，比方只剩一份replication的優先性比剩兩份大很多。
• master若掛了，外部的monitor會發現，重新開一個master (一分鐘內即能完成）。
• 為了確保master掛了也沒問題，所有master的操作都是先將log寫入disk後，才正式執行。加上log很精簡，master重新啟動載入log不需多少時間。
• 事實上，不管是master還是chunkserver，都沒有「停止」的指令，直接kill即可。它們都是設計成可以隨時掛掉，隨時快速複活。
• 刪除檔案即在master內將檔名改為特殊名稱並隱藏起來，仍可讀取和復原；待一段時間（三天）後，master會在background執行的garbage collection中正式清掉標記為刪除的檔案，好處是減少master短時間的high load，還有避免使用者犯錯，壞處是disk space可能實際上夠卻無法拿來使用。
• chunkserver若發現檔案無法在master內查到meta data，即表示檔案已被砍了，減少master和chunkserver互相sync meta data的問題。master則是在新啟動時，向所有chunkserver要資料，減少master記錄的負擔。
• 雖然GFS沒實作POSIX，卻有另外提供特殊功能：append record和snapshot
• append record常用在 many-to-one producer-consumer queues。append可以同時對同一檔案操作，write則需要指定offset，不能同時執行。
• snapshot指複製某個namespace下的所有檔案 (e.g. /home/www )，snapshot採用類似 copy-on-write 的設計，沒被寫入的data chunk不會被複製。
• chunk有reference count，當chunkserver發現reference count > 1又被寫入時，就會先複製一個新chunk，再把reference拆開，並更新各自的reference count。透過reference count達成copy-on-write的設計很漂亮，為了避免snapshot途中檔案有變（e.g. 多了新檔案)，執行snapshot時會要求該namespace下的write lock。
• shadow master以慢一點點的時間達到和master一樣的狀態，當作 read-only master，減輕master負擔。

整體來說，這篇論文相當有意思，許多設計都是簡單易懂，概念看來也很實用。唯一奇怪的是，實驗部份的表現看來不太好，還有我看不懂部份實驗說明，概念和設計細節都懂，反而是實驗看不懂，這到是很少碰到的情況，怪哉。

Google Image Search相關雜記

綜合摘要近來看到和Google Image Search相關的舊消息，三個消息合起來滿有趣的，Image Search已是第二主打，又不斷有新動作，像是加新功能或是用Human Computation增加dataset的量以提高準度。

Google Image Search是Google第二紅的服務

Google Image Search占Google所有服務使用率將近10%，是Google主頁外最多人用的Google服務。

資料來源：Hitwise在2006年5月公佈的資料，主頁占了將近80%，Image Search將近10%，GMail才5.5%。統計方法寫在該頁留言裡，節錄如下：

Hitwise uses the IAB definition of a visit (considered the standard by most) which is defined as: “a series of page requests with a gap of no more than 30 minutes between each one.” All data on my blog (unless otherwise specified) is coming from our U.S. sample of 10 Million internet users (all residing within the U.S., we also have samples for the UK, Australia, New Zealand, Hong Kong and Singapore.

Google Image Search加上臉部篩選功能

從這裡看到的，在URL最後加上 “&imgtype=face” 就會專搜臉部特寫，用認識的人試也滿準的，不過搜ACG人物有些不太準（像搜綾波零會看到碇司令，這是精神汙染啊），稍微看一下後，應該是Image Search本來就不夠準的原因，不是臉部篩選的問題。

Google Image Labeler

之前有提過這個收集image tag data的遊戲，收集來的資料可以用來加強Image Search。

Google Image Labeler

官網：Google Image Labeler

系統會幫你找另一個想玩的人，兩人一組看同一張圖，各自給 label, 雙方的label一樣時各+100。

這是幫圖片加semantic tag的好方法啊，高招！至少可以防止含最多semantic tag的都是正妹圖 。下一步就是用圖上的tag強化image search吧。

2007-04-08 Updated

Mr./Ms. Days的Blog有一篇詳細介紹：《玩遊戲，做研究》，說明Google Image Labeler的idea來源和相關發展。