雲端運算平台Google App Engine簡介

An Introduction to Cloud Computing Service Platform - Google

App Engine
張銘峰 許閔雄 陳桂慧
Ming-Feng Chang, Min-Hsiung Hsu, Kuei-Hui Chen

中文摘要
Google 在 2004 年 收 購 Picasa 以 擴 充 Blogger 的 功 能 ， 更 在 2006 年 以 16.5 億 美 元 的 天 價 併 購
YouTube ， 與 其 花 大 錢 併 購 市 場 上 熱 門 的 網 路 服 務 ， 不 如 開 放 自 家 的 雲 端 運 算 服 務 平 台 吸 引 各 家
好 手 前 來 開 發 下 一 個 熱 門 的 網 路 服 務，在 這 樣 的 前 提 之 下， Google 開 發 並 開 放 了 Google App Engine
平 台。在 這 篇 文 章 中，我 們 將 對 Google App Engine 所 提 供 的 功 能 與 支 援 的 開 發 工 具 做 簡 單 的 介 紹 。
文 中 並 將 對 搭 建 Google App Engine 背 後 的 雲 端 運 算 服 務 平 台 所 包 含 的 技 術 做 進 一 步 的 說 明 。

Abstract
Google bought Picasa to extend the function of Google Blogger in 2004. And then it spent 1.65 billion
dollars to buy YouTube in 2006. Google now would rather release their own cloud computing service platform
to appeal to developers to build the next popular network service, than spend huge money to buy popular
network services on the market. That’s the reason why Google App Engine is released. This paper presents a
brief introduction to the function and supported development tools of Google App Engine. In addition, the key
technologies of the cloud computing service platform of Google App Engine are also introduced in this paper.

關鍵詞 (Key Words)

Google 雲 端 運 算 服 務 平 台 GAE (Google App Engine)
雲 端 運 算 (Cloud Computing)
Google 檔 案 系 統 (Google File System)

１．前言
今 年 Google 2008 台 北 程 式 開 發 日 的 重 頭
戲 之 一 ， 就 是 Google 來 台 推 廣 他 們 的 雲 端 運 算
服 務 平 台 GAE(Google App Engine) 。 藉 由 這 個
平台所提供的免費服務，開發者不用再去管理
龐 大 的 伺 服 器 群、電 力、網 路 頻 寬 等 等 的 問 題，
只 要 專 心 發 展 網 站 並 上 傳 至 GAE 即 可 ； 換 句 話
說 ， Google 就 是 打 算 提 供 一 個 強 大 的 免 費 虛 擬
主機，這對網站開發者來說是個福音，但對虛
擬 主 機 商 來 說 卻 是 個 惡 耗 。 對 Google 來 說 也 有
它 的 利 益 考 量 ， 一 旦 開 發 者 成 功 的 在 GAE 平 台
上建立了熱門的服務網站，吸引龐大網路流量
之 後 ， Google 就 可 以 坐 收 超 過 流 量 的 費 用 以 及
廣告費。但對開發者來說，服務網站無法離開
這 個 平 台 ， 因 為 帳 號 管 理 都 是 使 用 Google
Account，雖 然 軟 體 可 以 複 製，但 是 卻 無 法 帶 走
龐大的使用者。

24 ICL TECHNICAL JOURNAL 12.25.2008 第126期 電腦與通訊

 Google 為 了 推 廣 雲 端 運 算 服 務 平 台 GAE ， Google 所 提 供 的 雲 端 運 算 服 務 資 源 ， 並 提 供 直
與 IBM 進 行 一 項 研 究 計 畫 ， 將 投 資 建 立 兩 個 大 譯 式 語言 、 資 料 庫 與 開 發 測試輔助 工 具 等 ， 讓
型 的 資 料 中 心，配 置 在 6 個 大 學 中，包 括 卡 內 基 開 發 者 更方便 的 建 立 與 維護 網 站 ， 同 時 隨著 網
美 隆 大 學 、 麻 省 理 工 學 院 (Massachusetts 站 流 量 的 成 長 ， 硬 體 效能 與 頻 寬 的 問 題 也 可 透
Institute of Technology) 、 史 丹 佛 大 學 (Stanford 過 付 費 的 方 式 取 得 GAE 平 台 上 額外 的 資 源 而 不
University) 、 華 盛 頓 大 學 (University of 需要變動原來的網站設計。本章將依序說明
Washington) 、 馬 里 蘭 大 學 (University of GAE 平 台 的 開 發 與 執 行 環境 ， 以 及 目前 所 提 供
Maryland) 與 加 州 大 學 柏 克 萊 分 校 (University of 的 功 能 與 限制 [1] 。
California at Berkeley) 。 同 時 ， Google 也 和 台 2.1 GAE開發與執行環境
大 、 交 大 和 北 京 清 華 合 作 推 動 雲 端 運 算 (Cloud
computing) 課 程 ， 教 授 下 列 課 程 ： (1) 可 開 發 雲
目前 GAE 只 支援 使 用 Python 語言 開 發 ， 此
平 台 所 提 供 的 執 行 環境 包 含特別版 的 Python 直
端 運 算 應 用 的 開 原 碼 Java 軟 體 框 架 Hadoop ； (2)
由 Google 提 供 ， 可 在 平 行 運 算 系 統 上 進 行
譯 器 、 標準 的 Python 函 式 庫 、 GAE 特 有 的 函 式
100TB 以 上 巨 資 料 處 理 的 軟 體 框 架
庫 與 APIs 以 及 為 網 頁 伺 服 器 層 所 提 供 的 標準介
面 。 其 中 有 六 項 標準函 式 庫 中 的 功 能 因 安 全 性
MapReduce ； 以 及 (3) 其 專 屬 的 檔 案 系 統 Google
的 問 題 被關閉 ， 分 別 為 (1)networking 模組 ； (2)
File System 等 技 術 。
Google 提 供 全 球 大 量 的 服 務 與 儲 存 空 間 ，
寫入 檔 案 系 統 功 能 ； (3) 將 cPickle 模組更 換 為
pickle 模組 ； (4)marshal 模組 ； (5)imp 、 ftplib 、
而 且 持 續 不 斷 成 長 中 ， 在 GAE 推 出 後 ， 勢 必 加
select 、 socket 等 模組 ； 以 及 (6)tempfile 模組 。
速 這 成 長 。 是 什 麼 樣 的 架 構 使 得 Google 可 以 提
Google 提 供 GAE 軟 體 開 發 工 具 (SDK) 供 開
供 這 麼 大 量 而 穩 定 的 服 務 與 空 間 ， Google
發 者 下 載 ， 用 以 開 發 GAE 上 的 應 用 程 式 ， 其 中
Fellow Jeff Dean 在 2008 年 4 月 Yahoo 所 舉 辦 的
包 含安裝 在 本 機 端 電 腦 上 的 web server，以 模 擬
Data-Intensive Computing Symposium 中 揭 開
所 有 GAE 平 台 上 的 服 務 ， 並 支援 所 有 GAE 上 提
Google 的 神 秘 面 紗 ， 解 釋 如 何 用 Google File
供 的 API 和 libraries ， 讓 開 發 者 在 本 機 端 電 腦 上
System 、 Bigtable ， 與 MapReduce 三 大 核 心 技 術
進 行 模 擬 與 測試 。 並 可 透 過 SDK 所 附 的 上 傳 工
來 處 理 大 量 的 資 訊 ， 使 得 Google 即 使 只 是 用 大
記憶 具 程 式 ， 將 程 式 與 檔 案 上 傳 至 GAE 平 台 上 。 本
機 端 的 模 擬 Web Server 提 供 以 下 的 功 能 ： 檢查
量的平價伺服器、處理器、硬碟、 體等，
仍能 穩定提供服務。
import 的 模組 是 否 合 乎 GAE 的 要 求 、 模 擬 App
亦 透
GAE 是 過 這 三 大 核 心 技 術 ， 來 提 供 使
caching 的 行 為、模 擬 datastore 功 能、模 擬 Google
用者大量而穩定的服務， 本文 第二章 介 在 中將
Accounts 登入登 出 的 動 作 、 模 擬 URL fetch 、 以
紹 GAE 目前 能 方 接著
所提供的功 與開發 式， 在
及 模 擬 mail service 等 ， 但 不 模 擬 GAE 有 關 儲 存
後續的 章節 介紹 背
中 GAE 後 的 雲 端 運 算 服 務 平
容 量 與 timeout 時 間 的 檢查 。 GAE 並 提 供 五種 等
台所包 含 第 章 介紹
的這三大技術，在 三 中
級 的 日 誌 功 能方便除錯 ， 分 別 為 debug 、 info 、
能 設 第四
Google File System 的 功 與 計 架 構 ， 在
章 明 第五章則簡介
中 將 說 MapReduce 架 構 ，
warning 、 error 和 critical ， 並 可 使 用 admin
console 或 是 以 指令 下 載 日 誌 資 料 。
設 最 章 結論
BigTable 的 計 ， 後 一 為 。
GAE 會選擇 將 某些 程 式 碼 長 時 間 的 放 在 記
憶體裡，以避免浪費時間重複載入這些程式
２． GAE平台所提供的功能與限制 碼，這 些 程 式 碼 分 別 為 imported modules 與 含 有

GAE 平 台 讓 Web 應 用 程 式 開 發 者 用 簡單 的 main() 函 式 的 handler scripts，其 中 handler script

是 由 使 用 者 定 義 ， 用 來 處 理 特 定 web request 的
方式部署其所開發的網路應用程式，以使用

ICL TECHNICAL JOURNAL 12.25.2008 第126 電腦與通訊 25

模 組 。 運 用 這 個 App cache 的 特 性 搭 配 使 用
global variable 將可加快應用程式的執行速度。
開發者開發完成後，經模擬與測試，上傳
至 GAE 網站上後，即可對外提供服務。為提高
開發者上傳程式與檔案的效率， GAE 平台利用
版本控制機制，未經修改的檔案將不會重複上
傳，而本機刪除的檔案則在伺服器上先給予刪
除的標籤，而不是真正進行刪除，讓開發者得
以有效率的更新網站。
GAE 是由許多個 web servers 所組成，在收
到 web request 後， GAE 會根據當前系統狀況，
分配一個 web server 並根據設定檔找到相對應
的 handler script 處理該 request。但由於 GAE 只有
在 handler script 結 束 時 才 將 資 料 送 出 ， 在
handler 結 束 前 ， 無 法 傳 送 資 料 至 使 用 者 瀏 覽
器 ， 因 此 Streaming 相 關 的 功 能 無 法 支 援 。 另
外， GAE 支援 Accept-Encoding 與 User-Agent 兩
個參數，可傳送壓縮的 response 給使用者端。
2.2 GAE的功能
作為一個 web 應用程式平台， GAE 除了提
供強大的硬體效能，與龐大的網路頻寬資源之
外，亦提供各種功能介面，讓開發者可整合目
前 Google 的其他技術與服務，以進行開發。簡
介如下：
Datastore 的功能
GAE 提 供 強 大 的 分 散 式 儲 存 機 制
datastore ， 具 搜 尋 引 擎 與 transactions 的 特
色，如同分散式的 web server 可以隨著網站
流量成長而增加，使得網站的儲存空間，隨
著應用程式的資料增多而成長。讓開發者可
專心致力於網站的程式開發，無須再受硬體
與頻寬的限制。
為了資料庫的擴充性， datastore 並非採
用關連式資料庫架構。Datastore 以 entity 為單
位進行儲存與查詢操作，同時提供
transaction 為單位的操作，若 transaction 中有
其中一個操作失敗，則整個 transaction 都回
溯 ， 並 提 供 兩 種 查 詢 介 面 Query Object
Interface 和 GQL interface ， 其 中 GQL 為
26 ICL TECHNICAL JOURNAL 12.25.2008
Google 定義的 SQL-like language 。
Datastore 的 Query 功能所提供的可描述
查詢條件為 entity 的種類、 entity property 值
的比較條件，和查詢結果的排序條件。每一
個曾被執行過的 query 都會產生一個 index 放
在 index.yaml 中。datastore 執行查詢的步驟如
下，首先使用 entity 的種類、filter properties、
filter operators 和 sort orders 這四個條件來進
行 query，接著在 index.yaml 中從第一個 index
開始逐條比對直到檔尾或是下一條已不符
合 filter 的條件。
Images 的功能
這 部 分 功 能 取 自 Python Image
Library ，支援檔案格式包含 JPEG 、 PNG 、
GIF( 包含靜態與動態 ) 、 BMP 、 TIFF 、 ICO ；
共有六種功能，包含維持原比例放大縮小、
旋轉、水平對調、垂直對調、裁剪、顏色與
對比度最佳化。
Mail 的功能
GAE 上 的 應 用 程 式 可利 用 GAE 所 提 供
之郵件服務，送出電子郵件，並支援傳送夾
檔，但不提供收信的功能。郵件傳送服務只
有系統管理者和一般使用者登入後，才允許
提供服務。郵件應用程式介面 (mail API) 提供
兩種方式來使用郵件傳送服務，呼叫
mail.send_mail() 函式與使用 EmailMessage 類
別。
Memcache 的功能
Cache 功 能 採 用 key-value cache 的 形
式，用來儲存暫時的資料或是將 datastore 中
的 資 料 搬 到 cache 中 以 取 得 較 快 的 存 取 速
度，並提供 cache 資料 expire time 的設定。
URL Fetch 的功能
支援使用 HTTP 與 HTTPS 存取網路上的
主機，但有以下的限制：(1) 只能存取 ports 80
(HTTP) 與 port 443(HTTPS)；(2)urlfetch.fetch()
函式為同步運作，即此函式會被凍結，直到
收 到 遠 端 伺 服 器 傳 回 的 結 果 ； (3) 在 使 用
HTTPS 時 ， 目 前 版 本 無 法 認 證 遠 端 的 伺 服
器； (4) 最多只允許 HTTP redirect 5 次，也可
第126期 電腦與通訊
 以使用參數取消 redirect 。 多，也將更增加程式開發者的使用意願。
User accounts 管理功能
此 功 能 讓 GAE 與 Google Accounts 作 整 ３．Google File System-GFS的介紹
合，讓使用者登入 Google accounts 並讓應用
程式可查詢目前使用者的資料，像是使用者 GFS(Google File System) 是一個高可擴充
的 email address ， nickname 以及此使用者是 性的分散式檔案系統，具有高容錯率可以讓廉
否具有管理者的權限。 價的消費性硬體達到高累加的效能以應付為數
2.3 GAE的限制 眾多的使用者，目前最大的叢集 (cluster) 是由超
過一千台機器搭載數千顆硬碟所組成，提供超
GAE 免費提供系統開發者應用程式執行環 過 300TB 的儲存空間，並且容許數百個使用者
境，每個免費帳號的限制有：可註冊三個應用 連續存取 [2] 。
程式、最多使用 500MB 的儲存空間、每天 10GB GFS 與一般的分散式檔案系統具有相同的
的頻寬、每天 200M CPU cycles、每月五百萬次 特性，目的是要達成效能、擴充性、可靠度和
以內的瀏覽次數。雖然超過限制需要付費才能 可實作性四個特性的最佳化，除此之外 GFS 採
使用，但依據其收費標準每多增加 1GB 的儲存 用了以下的四個有別於一般的分散式系統的觀
空間，每月只需額外再付出 0.15 到 0.18 美金，每 點來設計這個檔案系統：
多增加 1GB 對外頻寬，每月額外再付出 0.11 到 (1) GFS 由廉價並且容易損壞的消費性元件所
0.13 美金等，相較於一般硬體成本，開發者所 組成，必須能定期的自我檢視、偵測、容錯，
需負擔的成本仍是非常低。
雖然在資料庫儲存空間與瀏覽次數上限制 (2) 並從錯誤中恢復原狀態。 相較於傳統的標準， GFS 處理的檔案非常巨
很寬，但程式上傳的限制，無形中也限制了可 大，通常在 100MB 或者更大，數 GB 的檔案
開發的應用程式類型。開發好的程式碼與檔案 很常見，必須為數 GB 以上的大型檔案作系
透 過 GAE 軟 體 開 發 工 具 程 式 上 傳 至 Google 的 統最佳化。
Server 時，有限制單一檔案不得超過 1MB ，檔 (3) Google 大部分的文件修改都是採用循序寫
案 數 量 不 得 超 過 1000 個 ， 同 時 又 不 支 援 入資料到檔尾的方式，而非使用覆蓋的方
Streaming ，網站若欲提供影音服務或炫麗的畫 式，這種寫入方式通常寫入檔案後就很少作
面等將受到限制。 更動。因此必須支援大量資料連續寫入，當
除了儲存空間與頻寬的限制之外，為了確 然小量隨機寫入資料到檔案也必須支援，但
保應用程式在安全的環境下執行， GAE 安全的 是不必最佳化。
sandbox 環境限制平台上應用程式不可以寫入 (4) 讓 使 用 者 可 以 同 時 附 加 資 料 到 同 一 個 檔
資 料 到 檔 案 系 統 ， 不 可 以 直 接 使 用 socket 服 案，而不會出現因為同步進行操作造成需要
務，必須透過 port 80 使用 HTTP 或是 port 443 使 等待的問題。
用 HTTPS 方式存取，也不可以建立 subprocess Google 應用程式通常需要快速處理巨量的
或是 thread ，所有的程式碼必須在單一 process 資料，或是有嚴格的回應時間限制，因此 GFS
中，且在數秒內完成。
此外目前只支援以 python 程式語言開發， 的高容量頻寬處理效能遠比低延遲效能來得重
這 讓 不 熟 悉 python 的 系 統 開 發 者 卻 步 ， 幸 而 要的多。
2008 年 10 月 在 印 度 Bangalore 所 進 行 的 Google 3.1 系統架構
Developers Day 中主講者 Prasad Ram 表示，未來 一個 GFS 系統包含了一個 GFS master 以及
GAE 將支援 Java ，未來 GAE 支援的程式語言越 多個 GFS chunkservers 所組成，可以讓多個 GFS
clients 同時進行存取，其讀取檔案的架構圖如

ICL TECHNICAL JOURNAL 12.25.2008 第126 電腦與通訊 27

 圖 3.1-1 Google File System的架構(讀取檔案)[2]
圖 3.1-1 所示。
GFS chunkserver 負 責 儲 存 所 有 的 檔 案 資
料， GFS 上檔案儲存的方式是將每一個檔案切
割為固定大小的 chunks，每一個 chunk 都會被指
定一個唯一的 chunk handle 然後由 chunkserver
將 每 個 chunk 當 作 一 個 Linux 檔 案 儲 存 在
chunkserver 的硬碟上。為了資料的可靠度，每
一 個 chunk 都 會 被 複 製 三 份 存 在 不 同 的
chunkserver 上。
GFS master 負 責 管 理 GFS 系 統 中 所 有 的
metadata ，包含檔案 namespace( 檔案路徑 ) 、檔
案的對應 (mapping) 以及檔案的位置資訊。除了
管理 metadata 外，GFS master 需要做 chunks 的使
用 管 理 、 回 收 不 再 使 用 的 chunks ， 同 時 以
heartbeat 的 方 式 定 期 與 chunkservers 更 新 狀 態
資訊。
GFS client 內嵌在應用程式裡，實作了 GFS
的 API ， 負 責 與 GFS master 互 動 取 得 最 新 的
metadata 資 訊 ， 並 且 協 助 應 用 程 式 直 接 跟
chunkserver 提取 chunks 資料。
為 了 避 免 GFS master 成 為 整 個 系 統 的 瓶
頸，必須減少對 GFS master 做讀寫的動作，所
以 GFS master 只負責讓 GFS client 查詢 chunks 所
在的 chunkservers 的位置， GFS client 端不透過
GFS master 存取資料。
GFS 系統運作流程如下：首先，由於 chunk
的大小是固定為 64MB ， GFS client 根據應用程
式所要讀取的檔案名稱與檔案中的位置，算出
chunk 的 索 引 ， 將 檔 案 名 與 索 引 送 給 GFS
master ， GFS master 收到後將 chunk handle 與放
28 ICL TECHNICAL JOURNAL 12.25.2008
置此 chunk 的所有 GFS chunkservers 位置資訊傳
給 GFS client ，最後 GFS client 根據 GFS master
所回覆的訊息，以及想要在 chunk 中取得的資料
範 圍 (byte range) ， 直 接 向 最 近 的 GFS
chunkserver 提取檔案資料直到結束。
這個分散式檔案系統總共提供 8 種檔案操
作，包含 create 、 delete 、 open 、 close 、 read 、
write 、 snapshot 、 record append ，其中 snapshot
與 record append 是 GFS 獨 有 的 操 作 方 式 ，
snapshot 是以極少的運算複製檔案或建立一個
目錄樹，record append 則是在不使用 lock 的前提
下，同時讓多個 GFS client 附加資料到同一個檔
案的檔尾。
資料的收集與使用
3.2 Metadata
GFS master 會將三種 metadata 儲存在記憶
體中： (1) 檔案和 chunk 的 namespace； (2) 檔案和
chunk 之間的對應；(3)chunks 所放置的位置。其
中為了預防 GFS master 當機造成資料的損失，
前兩種資料會另外使用紀錄檔 (log) 的方式存在
硬碟以及遠端備份硬碟中。 GFS master 並不會
將 chunks 所放置的位置存在磁碟中，而是在啟
動的時候向 GFS chunkserver 要求這些訊息，然
後用 heartbeat 的方式監控 chunkserver 的狀態，
並控制所有 chunks 的放置位置。
對 於 存 在 GFS 中 檔 案 資 料 的 維 護 ， GFS
master 會周期性的執行以下的三個動作：
(1) 針對沒有使用的 chunk 做回收
(2) 當 chunkserver 有 錯 誤 發 生 時 ， 重 新 複 製
chunks
(3) 在 chunkservers 之間移動 chunk 資料，以均勻
第126期 電腦與通訊
 分 配 chunkservers 之 間 的 負 載 和 硬 碟 使 用
量。
紀錄檔是 metadata 唯一永久儲存的資料，
一旦 GFS master 發生錯誤，需要復原 metadata
的時候， GFS master 會用重新播放紀錄 (replay
log) 的方式來復原資料。但是為了減少啟動的
時間， GFS 必須控制紀錄檔不能太大，當紀錄
檔的大小超過一定時， GFS master 就會建立一
個 查 核 點 (checkpoint) ， 在 查 核 點 建 立 完 成 之
後，就將之前的紀錄資料刪除，這個查核點是
以一個 compact B-tree 的方式儲存，可以快速的
被載入記憶體。當 GFS master 啟動的時候，會
先載入最新的查核點，再重新播放剩餘的紀錄。
3.3 檔案資料一致性的維護
GFS 最重要的目標是為高度分散的應用程
式建立一個一致的檔案系統。在系統中，檔案
有兩種資料需要維護其一致性：namespace 與檔
案區域 ( 實際儲存資料的區域 ) 。
GFS 系 統 中 只 有 GFS master 能 進 行 檔 案
namespace 的改變，並且使用到 lock 的機制確保
正確無誤。
檔案區域資料的改變可以是寫 (write) 或是
紀錄附加 (record append) 兩種方式。寫的方式是
由 GFS client 指定寫入的檔案位置 (offset)。紀錄
附加的方式是在 GFS 所指定的檔案位置不被中
斷地將資料全部寫入。多個 GFS clients 同時附
加資料到同一個檔案的方法如下： (1) 預留每個
GFS client 附加資料的空間，亦即 GFS 指定給每
個 GFS client 的檔尾位置會不一樣。(2) 每個 GFS
client 各自寫入資料到各自的預留空間中，寫入
順序則是先寫入原本要寫入的資料，然後寫入
資料的 checksum，最後多餘的預留空間補 0。(3)
在讀取檔案的時候將整個預留空間一次讀出
來，根據 checksum 捨棄補 0 的部分即可。
當經過一連串成功的操作後， GFS 會對所
有 的 備 份 資 料 進 行 相 同 步 驟 的 操 作 ， 且 GFS
master 和 GFS chunkservers 之間會有 heartbeat 檢
查資料的正確性，一旦發現錯誤的 chunks ，則
立刻由備份的 chunks 將資料恢復。
ICL TECHNICAL JOURNAL 12.25.2008
GFS 使 用 以 下 的 原 則 執 行 所 謂 的 relaxed
consistency model ，其作法是： (1) 在每隔一些
資料變動之後執行查核點紀錄。 (2) 大量使用附
加 (append) 取代覆寫 (overwrite)。例如要做覆寫
動 作 時 ， 就 將 它 拆 解 為 讀 取 (read) 和 附 加
(append) ，先讀取檔案沒有變動的部份，然後
附加需要覆寫的部份以產生此檔案。附加操作
擁有可以讓多個 GFS clients 同時對同一檔案操
作的特性，用此方法比隨機寫入 (random write)
有彈性的多。
４． 的介紹
MapReduce
MapReduce 是一種 Prgramming Model[3] ，
用於大規模資料的平行運算。在解決複雜的問
題時，我們常常使用 Divide and Conquer 的方式
來 簡 化 問 題 的 難 度 ， 而 MapReduce 就 是
Divide/Conquer 的過程，找出問題或資料可以平
行化處理的部份，再針對平行處理的部份寫成
Map 程式，而後將 Map 後的結果根據每個鍵值進
行 Reduce ，得到最終運算結果。
4.1 MapReduce Programming Model
MapReduce 主 要 的 架 構 是 由 Map 以 及
Reduce 兩個函數所組成，使用者指定一個 Map
函數來處理一組輸入的 key/value 來生成多組的
intermediate key/value，然後指定的 Reduce 函數
將相同的 intermediate key 合併成最終的結果。
例如要統計一個文字檔集合中每個單字出
現的次數， Map 函數的工作是將輸入的文字檔
中所出現的每一個單字作為輸出的
intermediate key ，並賦予 value “1” ，將這樣的
intermediate key/value 寫入中間文件裏。例如輸
入 “I love travel, you love travel too” 的文字
檔，經過 Map 運算後輸出的結果是：
(I, 1), (love, 1), (travel, 1), (you, 1), (love, 1),
(travel, 1), (too, 1)
Reduce 函 數 的 工 作 是 將 有 相 同 的
intermediate key 的值匯總起來，在進行 Reduce
運 算 前 ， MapReduce 函 式 庫 會 將 有 相 同 的
intermediate key 的 value 彙 整 成 一 個 串 列 輸 入
第126 電腦與通訊 29
Reduce 函數，例如前面 Map 所產生的結果，經
過 MapRedure 函式庫處理後，輸入 Reduce 函數
將會是： (“I”, [1]), ( “love”, [1,1]), (“travel”,
[1,1]), (“you”,[1]), (“too”, [1]) ，經過 Reduce 函
數運作後輸出的結果會是：(“I”, 1), (“love”, 2),
(“travel”, 2), (“you”, 1), (“too”, 1) 。
4.2 MapReduce 運作流程
首 先 MapReduce Library 把 要 處 理 的 資 料
分成數份，放到 GFS 上，分配給不同的機器執
行 Map 函數，執行 Map 函數的機器將執行後的中
間文件存在本地端，然後執行 Reduce 函數的機
器 將 存 在 Map 機 器 上 的 中 間 文 件 取 回 進 行 運
算，得到最後結果，詳細流程如圖 4.2-1 ：
1. MapReduce Library 將要處理的資料分割成
多份，寫到 GFS 上
2. 將使用者程式複製到多台機器上，其中一
台機器為 Master ，其他的機器為 worker
3. Master 挑 出 所 有 閒 置 的 worker ， 指 定 每 個
worker 處理 Map 工作，或處理 Reduce 工作
4. 執行 Map 的 worker 從 GFS 中讀取分割資料，
進行 Map 運算，將結果暫存在記憶體上
5. 執 行 Map 的 worker 定期將暫存的結果寫到
本地端檔案系統上
6. 資料儲存到本地端檔案系統後，worker 將寫
入的位置傳回給 Master
7. Master 通 知 執 行 Reduce 的 worker 資 料 暫 存
的位置
圖 4.2-1 MapReduce運作流程
30 ICL TECHNICAL JOURNAL 12.25.2008
8. 執 行 Reduce 的 worker 用 RPC 讀 取 暫 存 的 資
料，進行 Reduce 運算
9. Reduce worker 將 Reduce 運 算 的 結 果 存 入
GFS 中，通知 Master 儲存的位置
10. 全部的 Map/Reduce 執行完畢後，Master 喚醒
使用者程式，傳回結果
4.3 容錯處理與效能
MapReduce 的設計是使用多台機器平行處
理大量資料的運算，在運算過程中發生機器錯
誤時，如何降低因為機器錯誤造成的效能影響
是一個很重要的課題，在 MapReduce 架構中可
能發生兩種錯誤：
1. Worker 錯誤
Master 節點會定時對 worker 作 ping 的動作，
一 旦 沒 有 收 到 worker 的 回 覆 ， Master 認 定
worker 失效。如果失敗的節點是執行 Map 的
worker ，所有該 worker 已經完成的工作必須
重新執行 ( 因為 Map 執行的結果是存在本地
端檔案系統 ) ，此時 master 會指定另一個 Map
worker 來執行，同時通知所有執行 Reduce 的
worker ，讓 Reduce worker 從取代失敗的 Map
worker 讀取資料。如果失敗的節點是 Reduce
worker ，那麼已經完成的 reduce 工作不需要
重 新 執 行 ， 因 為 Reduce 執 行 的 結 果 是 存 在
GFS 中。
2. Master 錯誤
Master 會 定 期 寫 入 查 核 點 (checkpoint) 紀 錄
第126期 電腦與通訊
 執 行 狀 態 ， 一 旦 Master 發 生 錯 誤 ， 取 代 的
Master 可以從最後一次查核點的狀態開始執
行。
另一個對效能影響很大的問題是掉隊者
(straggler)：某一台機器可能因為資源競爭 (CPU,
記憶體等 ) 或緩慢的 I/O 使得該機器負責的工作
比其他機器慢，影響到整體執行效能。 Google
在這邊提出一個簡單的方法：每一份
Map/Reduce 都同時由兩個 workers 來執行 ( 兩個
workers 同時做相同的工作 ) ，當其中一份完成
後就可以傳回結果， master 再將另一份未完成
的刪除，這樣的運作管理少量增加了所花費的
資源，但是可以縮短整體執行的時間。
５． 的介紹
BigTable
Google 提 供 全 球 使 用 者 大 量 的 服 務 ，
BigTable 是設計用來處理與儲存這大量結構性
資料的分散式資料庫系統，這項技術目前應用
在包括 Google Reader 、 Google Maps 、 Google
Book Search 、 Google Earth 、 Blogger 、 Google
Code hosting 、 Orkut 和 YouTube 等， BigTable
提供這些 Google 服務一個靈活、高效能資料庫
的解決方案，用以儲存管理橫跨數千台主機、
約 6 PT(petabytes) 的資料。
5.1 Data Model
BigTable 的 資 料 索 引 可 使 用 row key 、 families 名 稱 ， 例 如 以 contents 和 anchor 作 為
column key 以 及 timestamp ， 除 了 timestamp 以 column families 名 稱 。 anchor:cnnsi.com 和
int64 格式儲存外， row key、 colum key 以及 data anchor:my.look.ca. 屬於相同 column family 下的
均以 string 方式儲存。每筆資料都是以下列格 不同 column key 。
式儲存：
(row:string, column:string, time:int64) data:string
BigTable 中 每 個 table 都 是 一 個 多 維 的
sparse map ， table 由 row 與 column 組成，與一般
常見的 row-oriented 資料庫不同。
Rows
在 table 中的 row key 都是任意的字串，對於
每 個 唯 一 的 row 做 讀 寫 都 是 不 可 中 斷 的 。
BigTable 使用 row key 依據字典編纂的方式做排
ICL TECHNICAL JOURNAL 12.25.2008
序，相似字串的 row key 資料就會排序在鄰近，
以動態方式切割 row range 。為了管理巨大的
table ，把 table 依據 row range 做分割，分割後的
每個 row range 被稱為一個 tablet，分散式與負載
平 衡 (load balancing) 分 散 式 與 負 載 平 衡 (load
balancing) 為的最小單位。每個 tablet 大概有 100
到 200 MB ， 每 個 機 器 儲 存 一 百 個 左 右 的
tablets 。 BigTable 底層的架構是 GFS ，由於 GFS
是分散式檔案系統，加上 tablet 的機制，可以做
到很好的負載平衡。比如說可以把經常被查詢
的 table 移動到其他空閒機器上，然後快速重建。
以圖 5.1-1 中以儲存網頁資料為範例 [4] 為例，網
址 maps.google.com/index.html 的資料，儲存在
com.google.maps/index.html 的 row key 之下，相
同 domain 的資料便會隸屬於相同的 row range ，
以提高資料存取之效率。
Column Families
可以將具有相同性質的 Column keys 歸類
在一起，稱為 Column family ，是存取控制的最
小單位。 Column family 必須在資料被儲存之前
產生，有了 column family 後， column key 才得
以 被 使 用 。 Column key 的 命 名 方 式 依 據
family:qualifier 語法，column family 的名稱必須
為 printable，而 qualifier 可為任意的字串。於圖
5.1-1 中以儲存網頁資料為範例 [4]，以 URL 作為
row key ， 以 網 頁 的 各 項 性 質 作 為 column
圖 5.1-1 BigTable中以儲存網頁資料為範例[4]
Timestamps
BigTable 裡 的 每 個 儲 存 單 元 cell 都 有
timestamp ，可儲存有多個版本的相同資料，這
第126 電腦與通訊 31
些版本以 timestamp 作為區分。以 int64 格式儲存 Google Adwords 廣告全球化銷售與曝光度。而
的 timestamp 可 以 讓 版 本 控 制 準 確 至 百 萬 分 之 網路應用程式開發者或其他企業也可以在製作
一秒。而應該保留最新的幾份版本資料，可由 和發佈應用軟體上有更多的選擇，可避免設立
Bigtable 或客戶端應用程式所設定，於圖 5-1 中 和維護基本設施的麻煩和昂貴成本。
以儲存網頁資料為範例 [4] ，每個 anchor cell 可 但在 2008 年 6 月 26 日的雲端運算 Structure
以有一個版本的資料，而 contents: column 則可 會 議 [5] 中 ， Joyent 創 辦 人 兼 技 術 長 Jason
有三個最新版本資料，如範例中有 t3 、 t5 、 t6 Hoffman 提出質疑，使用雲端運算不應像是出賣
三個 timestamp 的資料。 靈魂，若使用者採用 GAE 平台執行應用程式，
5.2 APIs 其資料持續累積儲存在 BigTable 中， BigTable
BigTable 的 API 提供以下功能：
提供高效能與高可靠度的方式來存取分散式資
(1) 建立、刪除 table 與 column family
料庫中的資料。一段時日之後，若有其他雲端
(2) 修改 table 和 column family 的存取控制權限
運算平台推出，恐因儲存在資料庫中的資料無
(3) 支援讓客戶端可以撰寫 script 放到伺服器上
法取出移轉至其他平台，而迫使使用者放棄使
執行，以便在 BigTable 中寫入或刪除資料。 用 新 的 平 台 ， 繼 續 使 用 GAE 的 平 台 。 雖 然
Hoffman 對 GAE 的質疑，其實是在推廣 Joyent 的
此 script 僅支援由 Sawzall 語言撰寫，該語言 雲端運算平台 Cloud 9，但也無疑提出了各家雲
是由 Google 為了處理資料所發展。 端運算平台之間，目前並沒有標準存在的問
(4) MapReduce 可以使用其 APIs
題，恐影響使用者來去自由的權益。
5.3 BigTable的基礎架構 此外， GAE 平台因侷限於安全性問題，且
BigTable 是建立在 Google 所發展的其他幾 目前只限於以 Python 程式語言發展，箝制了程
個基礎架構之下。 式開發者可運用的資源，使用者必須在開發自
(1) 使用 GFS，用以儲存記錄及資料，是一個高 由度與應用程式網站維護成本之間有所抉擇。
可擴充性的分散式檔案系統，每個儲存的基 計畫相關資訊
本單位 chunk 為 64MB 。 本文為工研院資通所執行經濟部 97 年度寬
(2) 以 Google SSTable 檔案格式儲存 BigTable 的 頻 無 線 通 訊 關 鍵 技 術 發 展 計 畫 「 IMS
資 料 ， SSTable 提 供 持 續 性 且 不 變 的 映 射 Technology 」，計畫代號為 7352B41200 之部分
(key->value)，其中 key 和 value 可以是任意字 計畫成果。
串的格式，可有效率地在特定的 key 範圍中
反覆查詢其 key/value pairs 。 參考文獻
(3) Chubby 提供高可靠度且穩固的分散式資料 [1] Google App Engine Documentation,
鎖定服務，負責分配 tablets 與管理其鎖定機 http://code.google.com/appengine/
制 ， 並 保 證 同 一 時 間 內 只 能 有 一 個 [2] Sanjay Ghemawat, Howard Gobioff, and
TabletServer 可以對應存取使用 tablet ，達到 Shun-Tak Leung, “The Google File System.”
同步的作用以提高 BigTable 之可靠度。 [3] MapReduce: Simpli_ed Data Processing on
Large Clusters, Jeffrey Dean and Sanjay
６．結論 Ghemawat, Google, Inc.
[4] Fay Chang, Jeffrey Dean, Sanjay Ghemawat,
Google 雲 端 運 算 平 台 GAE 推 出 後 ， 結 合 Wilson C. Hsieh, Deborah A. Wallach Mike
Google 背後強大技術支持，預估 3 年內將可網羅 Burrows, Tushar Chandra, Andrew Fikes,
全球近 88.252% 的企業與個人網站，進一步擴大 Robert E. Gruber “Bigtable: A Distributed

32 ICL TECHNICAL JOURNAL 12.25.2008 第126期 電腦與通訊

 Storage System for Structured Data”, OSDI,
2006.
[5] Structure 08,
http://events.gigaom.com/structure/08/
作者簡介
張銘峰
現 任 職 於 工 研 院資通所網路技術
組核心網路系統部軟體工程師，交
通大學資訊科學研究所碩士，從事
無 線 通 訊 網 路 (3G GPRS Core
Network) 、 多 媒 體 訊 息 服 務
(MMS)、號碼可攜服務相關研究。
E-mail: changmingfeng@itri.org.tw

許閔雄
現 任 職 於 工 研 院 資通所網路技術
組核心網路系統部工程師，畢業於
交通大學資訊科學研究所，專長為
無線通訊網路技術。
E-mail: LucienHsu@itri.org.tw

陳桂慧
現 任 職 於 工 研 院資通所網路技術
組核心網路系統部工程師，畢業於
元智大學資訊科學研究所，專長為
無線通訊網路技術、 TTCN-3 測試
平台技術等相關研究。
E-mail: chloe@itri.org.tw

ICL TECHNICAL JOURNAL 12.25.2008 第126 電腦與通訊 33