2010年4月21日

何謂雲端運算 & HDFS 補充 (雲端運算核心技術 Hadoop & MapReduce 概念班上課心得)

前陣子整理了之前上課的筆記:以運算就資料(在地運算) vs. 以資料就運算 (雲端運算核心技術 Hadoop & MapReduce 概念班上課心得),那次課程的內容包括:

  • 雲端運算簡介
  • Hadoop簡介
  • Hadoop 安裝與設定解析
  • Hadoop Distributed File System 簡介 (HDFS)
  • MapReduce 介紹
  • 快速佈建 Hadoop 叢集 (Cluster)

接下來再補充一些心得。

何謂雲端運算?

這是個最近很熱門的話題,講義裡面(P.3)濃縮成一句話是「能夠隨時隨地使用任何裝置存取各種服務」(但我覺得這講得太模糊了,甚至跟 Web 1.0 or U 化都無法區別)。講義中比較精確的定義是參考 NIST (word 檔,重點就是 543, 講義 P.4, 5大基礎特徵,4個佈署模型,3個服務模式)。另外也看到 Gartner 的定義,以及Twenty-One experts defining Cloud Computing等等。

如果講得更技術一點:雲端運算是一種新的運算方式,可讓任何連網裝置透過網路(基本上是 Internet),使用者根據(可能會劇烈變動的)需求存取所需的運算資源(CPU Power / Storage),最後根據使用量付費 (pay-as-you-go)。我覺得使用者能夠 on-demand 的、基本上無上限的(只要付的出錢來)、在短時間內(數十秒到幾分鐘)擴充所需的運算資源,是雲端運算最重要的特性,因為這是以往的架構所做不到的。這個定義的重點除了 on-demand 的動態擴充能力之外,還包括:運算資源透過網路存取、根據使用量付費。假如像某些專家所說,只要把資料/服務放到網路上遠端的電腦,從此可以讓任何連網裝置透過網路存取,就叫做雲端的話,那所有的 Web-based 系統都可以叫做雲端運算囉?這根本就是鬼扯。難道有人可以在 5 分鐘內把 SVN 系統從 1 台變成 50 台嗎?保證辦不到的嘛!而且現在所有的系統都必須透過網路溝通(例如三層式架構),就算不開放公開的 Internet 存取,企業內部也會建構 Intranet,所以透過網路存取這點就沒什麼好稀奇的了。

至於根據使用量付費,從技術的觀點來看,我覺得也不是雲端運算最重要的特性(雖然說這也不太容易做,系統必須在盡可能不干擾使用者使用服務的狀況下,詳盡的記錄使用情形,並且提供一個 web-based 的 dashboard 讓使用者隨時隨地掌握服務的運作/使用狀況),不過上課的時候老師有提到,未來如果這種依使用量付費的商業模式越來越成熟,可能會出現一種新的專業(顧問):雲端精算師,主要工作是要幫客戶規劃如何使用雲端服務,能夠以最少的成本滿足運算的需求 (例如要用怎樣的 OS/AP 組合來執行運算任務,不是透過網路把精算工作丟給遠端的精算人員唷揪咪^.<)。

要提供 on-demand 動態擴充的運算能力,除了需要靠虛擬化技術以外,也必須建構在分散式運算 (Hadoop) 以及分散式檔案系統 (HDFS) 之上。如果僅能透過虛擬化技術作到快速的新增虛擬機器(VM),並且設定好相關的網路組態(我覺得這樣已經很厲害了),但是資料無法有效的存放到分散式的檔案系統中,以提昇存取效率,對於超大量資料 (PB等級) 的運算是沒有幫助的。而若只是將資料由集中改為分散存放,程式是不會自動變成以分散式的方式去執行的,程式架構必須重新設計(也就是利用 MapReduce 演算法改寫),這就和單執行緒程式如果不經過調整,只是把 CPU 從單核換成多核,程式也不會自動變成多執行緒,是一樣的道理。

Gartner 的文章裡面有一段講得很好,過去講 Client/Server 架構的精髓就是:使用者要的是一種「不是放在 mainframe 上面跑」的系統;而雲端運算的精髓則是:使用者付費想要買的是服務以及服務所產生的結果,而不是運算的基礎設施(也就是不要再自己買機器、建機房了)。我認為這是從 PaaS Provider / SaaS Provider / SaaS Provider 的客戶等人的角度來看的,也就是把建構、維運基礎設施的成本轉嫁到 IaaS Provider 身上,而對 IaaS Provider 來講,則可以提高機器的利用率(multi-tenant),並且可收割位於長尾末端的客戶的運算需求(也就是無力自建機房,或者需要面對劇烈變動的需求的小型企業)。(但我一直在想,雲端運算真的有完全解決 IaaS Provider 所面臨的效能不足<under-utilization> 和效能過剩<over-utilization>問題嗎?感覺為了避免效能不足的問題,很容易就會造成效能過剩的現象。)

下一段補充 HDFS 分散式檔案系統的觀念。

以機率的觀點出發,將資料平均分散儲存在HDFS的成員(Datanode)中,以提高存取效率

前情提要:存入 HDFS 中的資料至少都會有3 份副本 (Replication),存放於(理想上位於不同機架<rack>)的機器上

把一個檔案存入 HDFS 時,HDFS (更精確的說是 Namenode) 會把檔案切割成固定大小的 block,而後將各 block 分散儲存到不同的 Datanodes 上,由於每個檔案的儲存都是跨實體機器的,因此 HDFS 可視為一個虛擬的分散式檔案系統 (傳統的檔案系統一樣會將檔案切割為 block,但都儲存到同一台實體機器的硬碟上),或者說是一個 Logical File System,而 Namenode 就負責扮演 Linux file system 中 inode 的角色,要知道組成某個檔案的所有 block 被儲存在哪些 Datanodes? 問 Namenode 就對了。

為了盡可能的提昇 HDFS 的存取效能(特別是讀取速度),HDFS 在儲存資料時必須將資料根據機率平均的分佈在組成 Hadoop cluster 的成員硬碟上(balancer的工作)。由於資料是平均分佈的,因此存取時就可以多管齊下,如下圖:


(資料來源:Apache.org - HDFS 架構設計)

當 Client 需要讀取 data 時,可以同時分別從五台 Server 各讀取一個 block,讀到以後再組合成完整的檔案即可,如此一來存取效率會比循序的從單一 Server 上依序讀取 block 1~5 來的快速許多,也可以降低每一台 Server 的 read lock 時間。

HDFS 其他的好處:

  • 資料存取時間可以控制在一定的範圍內,硬碟的損耗也更平均,進一步減少檢修硬體的成本。
  • 儲存於 HDFS 中的檔案大小可超過一顆實體硬碟的容量。由於 HDFS 是一個虛擬的分散式檔案系統,每個檔案的 block 本身就會跨實體機器儲存,因此自然不會受限於單一機器的硬碟大小了。例如雖然一個 Hadoop cluster 中的每台主機的硬碟都只有 500G,但這個 cluster 還是可以用來儲存 1TB/1PB 甚至更大的單一檔案,只要 cluster 內硬碟的總容量夠大就好。
  • 整個HDFS系統是可以熱插拔的,當某一台 Server 的硬體壞掉時,HDFS 仍可正常運作(因為資料至少還會有另外 2 份副本),並且由於資料的副本數低於 Policy 所規範的量,HDFS 會立即開始找尋另外正常運做的 Server 來維持副本的數量。接下來的維修只要直接把那台 Server 關機,換一台新的 Server 上去加入服務就好。因此機房管理人員就不需要利用三更半夜進行硬體的修復了。
  • 由於分散式架構可大幅提昇檔案的讀取速度,因此有雲端運算需求的企業(如 Google) 就不用再耗費鉅資購買高階的 Server,只要以一般的消費型機種就可以架構出高效能的運算平台 (以1台高階伺服器的價格可以輕易的買到10台以上的消費型機種,但1台高階伺服器的效能不會比10台消費型機種的總和來的強),如此可進一步降低 Data Center 的成本。

量少質精的資料不如超大量、品質還OK的資料

這是 Google 奉行不渝的原則,從以下兩篇文章可以略知一二:

  • [The Official Google Blog] Helping computers understand language

    We use many techniques to extract synonyms, that we've blogged about before. Our systems analyze petabytes of web documents and historical search data to build an intricate understanding of what words can mean in different contexts.
  • [Google Public Policy Blog] Making search better in Catalonia, Estonia, and everywhere else

    In the past, language models were built from dictionaries by hand. But such systems are incomplete and don't reflect how people actually use language.

    When building our models, we use billions of web documents and as much historical search data as we can, in order to have the most comprehensive understanding of language possible.

其他類似的例子還有很多很多。以 Google Translate 的作法為例,與其依靠極少數的專家來進行高品質的精確翻譯(成本很高),Google 選擇去蒐集大量的各種語文的對照文件(當然要有相當的品質,例如聯合國的文件),在有足夠大量文件的前提下,就可以提供很不錯的翻譯品質(隨著收集到的資料越來越多,自動翻譯的品質可以持續提昇),如此也才可以很迅速的根據使用者的需求,即時的將某個網頁從 A 語言翻譯為 B 語言。那麼要如何有效綠的儲存超大量的資料呢?當然是靠 HDFS 啦!超大量的資料蒐集完畢以後如何進行快速的分析呢?那就靠 MapReduce 囉!

其他感想

要打造一個包含軟硬體的完整架構真的很不容易,一旦架構建立以後,透過適當的講授就可以讓人在短短地幾小時內掌握此架構的重點,進而啟發出更廣泛的應用,如此可以快速的促成技術的進步,這是Google很大的貢獻。而Google把這個完整的架構以論文的形式發布,讓有心的人能夠很快的實作出來,真的是佛心來著呀!

關於雲端運算課程的心得,除了這兩篇文章以外,還有 key-value store 這個重要的軟體架構沒講到,希望在閱讀更多資料以後可以整理出一篇比較完整的心得。

另外還有從傳統的 IT 運算架構轉移到雲端運算的架構會遇到的困難,也是很值得深入討論的~

參考資料:

2010年4月14日

以運算就資料(在地運算) vs. 以資料就運算 (雲端運算核心技術 Hadoop & MapReduce 概念班上課心得)

前陣子上了一堂課:雲端運算核心技術 Hadoop 與 MapReduce 概念班,講師是國家高速網路與計算中心(國網中心)副研究員-王耀聰老師,一整天充實的課程讓我獲益良多,內容包括:
  • 雲端運算簡介
  • Hadoop簡介
  • Hadoop 安裝與設定解析
  • Hadoop Distributed File System 簡介 (HDFS)
  • MapReduce 介紹
  • 快速佈建 Hadoop 叢集 (Cluster)
由於課程內容太多,把上課筆記寫成流水帳也沒有意思,因此以下就 focus 在觀念的探討,希望讓沒有研讀過相關資料的人也能看得懂。(這些觀念都是 Google 提出來的,也是 Google 的產品設計哲學的精髓)
在進行以下的討論之前,先來確定一些基本假設:
  • Hadoop 架構的設計目標是要能夠以低成本且有效率的方式處理 PB 等級的資料量
  • HDFS 是一個可動態擴充的分散式檔案系統,在 Hadoop 架構中一份資料預設會有 3 份副本(Replication)
以運算就資料(在地運算) vs. 以資料就運算
這是整天的課程中我最感興趣的,因為這代表一種思維的轉變。傳統在設計系統時,最常使用的就是三層式架構 (Three-tier architecture),如下圖:

(資料來源:Wikipedia - Multitier architecture)
就算在佈署時把 Presentation 和 Logic Tier 放在同一台 Server (在小型的 site 也許可以),Data Tier 一定會放到另一台 Server 上面去。在 Logic tier 執行系統核心的運算前,必須將待運算的資料從 Data Tier (DB Server) 搬運到 Logic Tier (AP Server) 進行運算,也就是以資料就運算,負責執行運算的程式檔案本身是不移動的(固定佈署在 Logic Tier 上),執行運算所需的資料則從其他的機器(或者 cluster) 搬運到程式所在的機器上。
在這樣的傳統架構中,資料的傳輸情況如下:
  • 在網路上傳輸待運算的資料(大量):Data Tier –> Logic Tier
  • 程式要執行時,從 Disk 複製到記憶體中(少量):Logic Tier Disk –> Logic Tier Memory
這樣的作法有幾個缺點:
  • 以檔案大小而言,要執行的程式檔案是很小的 (e.g., .exe/.dll),但待運算的資料量是非常大的 (Hadoop 的 target 是 PB 等級的資料)。
  • AP Server 必須要先從 DB Server 拿到資料才能開始運算,在這段網路傳輸時間內資料只是單純的被搬運而已,並沒有被計算,因此對運算任務而言,網路傳輸時間是完全的 overhead。
  • 當待運算的資料量越來越大,例如達到 PB 等級時,消耗在網路傳輸的時間會大幅增加,因此需要佈建超高速的網路 (e.g., Fiber Channel, FC),相較於成本較低且技術已經很成熟的 GE 網路來講,又要花費更高的成本。
而 Hadoop 架構則是如下圖:
Hadoop_roles (資料來源:Hadoop簡介 P.21)
以下是 Hadoop 中各角色的簡單說明 (參考 Hadoop簡介 P.19~20)。首先,負責儲存資料的單元可區分為:
  • Namenode: 擔任 master 的角色(只能有一個),管理檔案的讀寫,以及 Replication (副本) 的策略
  • Datanodes: 擔任 slave 的角色(可以有多個),接受 Namenode 的指揮,實際儲存資料的 Replication (副本),並執行檔案的讀/寫,將資料提供給 Tasktracker 進行運算
以上算是一組的,接下來,執行運算的單元可區分為:
  • Jobtracker: 擔任 master 的角色(只能有一個),也就是工頭,接受使用者 (Client,通常是另一個程式,不一定是指真實的人) 發起的工作,並進行工作排程 (Job Scheduling),將工作 (Job) 分派給 Tasktrackers 執行,並彙整 Tasktrackers 的計算結果後,將最終結果回傳給使用者
  • Tasktrackers: 擔任 slave 的角色(可以有多個),也就是工人,接受 Jobtracker 的工作指派,跟 Datanodes 要求待運算的資料,執行實際的運算後,將結果回傳給 Jobtracker 彙整
一個 Hadoop Job 執行的流程如下 (Client Submit Job 到 Job 開始執行):
pub[1]
(資料來源:我自己用 Google Doc 畫滴)
(註:Job 執行完畢以後,每個 TaskTracker 會將計算結果回傳給 JobTracker 彙整,而後再由 JobTracker 回傳給 Client)
(2010-04-20 補充:石頭閒語有篇文章有個類似的圖,參考這裡)
由上圖可以看出,當一個運算任務 (Job) 要被執行時,JobTracker 會將要執行的程式(相較之下檔案很小)傳送到資料所在的位置(Datanodes),而後待執行的運算便就地在 Datanode 上由 Tasktracker 完成,這就是以運算就資料,與其將很大量的資料到程式透過網路搬運到程式所在的機器上,不如先搞清楚資料在哪裡,接下來把小小的程式複製到資料所在的位置去執行。在這樣的架構中,資料的傳輸情況如下:
  • 在(GE)網路上傳輸要執行的程式(少量資料):Client –> Jobtracker –> Datanodes
  • 在 Datanodes 本機上傳輸待運算的資料(大量資料):Datanodes Disks –> Datanodes memory,完全不需要透過網路!速度肯定快很多!
2010-04-20 補充:Hadoop 官網有份文件有講到這一點,HDFS Architecture - Moving Computation is Cheaper than Moving Data,但是內容蠻精簡的。

通常原本很大量的資料經過運算以後,產生的資料量會比原來的資料小很多很多,因此在 JobTracker 與 TaskTracker 之間的資料傳輸就不會消耗太多的網路頻寬(這和 WCG 的特性是一樣的)。上課時老師也提到,根據估計,目前每年全世界產生的資料量已經大於全世界硬碟的總容量,因此未來如何能夠快速的處理大量原始資料,而僅儲存運算之後所得到的有用資訊,就是各大未來企業競爭的重點(目前已經是 Google、Yahoo 等每天需要分析超大量 web server log 的公司所面對的挑戰),目前看來 Hadoop 這個經過實戰(Yahoo)驗證的架構是很有希望的技術。
以上就是我認為這次課程最重要的觀念啦!
補充
雲端運算核心技術 Hadoop 與 MapReduce 概念班內容包括:
  • 雲端運算簡介:重點在投影片 P.3~P.6<雲端運算的定義及精髓>、P.19 <全球資料爆炸的預估量>、P.22~P.25<大量資料運算的教訓與未來趨勢>、P.40 <What we learn today?>
  • Hadoop簡介:重點在投影片 P.4~P.6<Hadoop基礎概念>、P.14 <Hadoop 與 google 的對應>、P.18<名詞,這一段非常重要!是未來討論的基礎>、P.19~21 <Hadoop 的 4 種身份以及最常見的佈署方式>
  • Hadoop 安裝與設定解析:這個部份等到要實作的時候再看就好
  • Hadoop Distributed File System 簡介 (HDFS):這份投影片每一張都很重要!其中我覺得 P.5 <設計目標(2)> 中的「在地運算」非常有意思,下一段會詳細說明。
  • MapReduce 介紹:again, 這份投影片每一張都很重要!P.2~P.9 是 MapReduce 演算法的介紹,P.10~16 有很多應用 MapReduce 演算法的實例
  • 快速佈建 Hadoop 叢集:當企鵝龍遇上小飛象 DRBL-Hadoop (投影片),這是利用國網中心開發的快速、大量佈署技術(企鵝龍) 來快速佈建 Hadoop cluster 的作法,一樣是等到實作再看就可以了。(不過老師也提到,利用這種技術可以幫助人力吃緊的中小學老師快速有效的管理電腦教室,並且替學校節省很多成本,這也是國網中心的重要任務之一。)
參考資料:

2010年4月9日

利用 Joomla 做資產管理 (Asset Management) -3 : 安裝 Fabrik 擴充套件及其使用方法

在上一篇:利用 Joomla 做資產管理 (Asset Management) -1 : 安裝過程紀要中曾經提到,這次要架站是為了記錄機器設備的基本資料,把以往用 excel 記錄的資料 web 化、集中化,只維護一個版本,可從任何有連網的裝置上存取,同時必須滿足以下六個需求:
  1. 免費!免費!免費!-> 找 Freeware / Open Source Software
  2. 簡單易用的web介面,支援 CRUD operation (增刪改查)
  3. 批次匯入現有資料
  4. 以選單的方式輸入資料
  5. 條件式的查詢、篩選資料
  6. 保留資料異動的 log
其中在權限控管上,要做到以下要求:
  • 利用 Joomla! 內建的角色:管理者/一般使用者 來實作權限控管
  • 管理者:可讀寫所有欄位
  • 一般使用者(有登入):
    • 大部分欄位可讀,不可修改
    • 有某些欄位不可讀(看不見),當然不可修改
    • 在修改的 view 中 (link to detail) 都是唯讀
  • 一般使用者(沒登入):什麼都看不到
安裝好 Joomla 之後,接下來就是要找到合用的套件來完成以上的需求啦!以下補充瀏覽 Joomla 擴充套件的注意事項,以及 Fabrik 套件的下載點。
Joomla 豐富的擴充套件 (extension) 可以在 Joomla Extensions 找到 (全都是英文的),共有 4276 個 extension,分為數十個大類別,其中在 Contacts & Feedback 中有一個 Forms 的類別,在瀏覽的時候要注意,Type 為 Commercial 的是商業軟體,要錢低;Type 為 Non-Commercial 的才是我們要找的免費擴充套件!
Joomla_extensions_types_thumb[1]
點進去這次要使用的套件:Fabrik – as joomla app builder 以後,畫面如下:
Joomla_Fabrik_IntroPage_thumb[1]
Fabrik 這個套件的官網比較複雜些,包括很多 templates、nodules 和 plug-ins,套件主程式反而放在下載頁面的最下面:
Joomla_Fabrik_DownloadPage_thumb[1]
下載好 Fabrik 擴充套件主程式後,安裝方式請參考:利用 Joomla 做資產管理 (Asset Management) -2 : 安裝過程紀要 (Linux)
接下來要介紹 Fabrik 擴充套件的設定。首先登入管理員後台,進入 Fabrik 套件的管理介面:

包括 Forms、Tables、Groups、Elements 都是需要設定的:

步驟一:新增一個 Fabrik Form
在 Forms 管理介面中,按最右邊的「新增」以新增一個 Form:
Fabrik_NewForm
Form 即為使用者在網頁中輸入資料的表單,表單中的每一項資料稱為一個 Element。設定好 Table name 後,Fabrik 會在 Joomla DB 中建立一個同名的 table,同時也會在 Groups 中新增一個同名的 Group,屬於此 Group 的 Elements (欄位)就會出現在接受使用者輸入資料的表單。
image
步驟二:新增一個 Fabrik Table
在 Table 管理介面中,按最右邊的「新增」以新增一個 Table:
Fabrik_NewTable
此時在「Data」的設定中的「Link to table」,要選擇剛剛在新增 Form 時所設定的 Table name:
Fabrik_NewTable_SelectTable
Table 用來呈現儲存於DB中的資料,並提供Advanced search功能,在過濾資料時非常方便。以下是此 Table 的存取權限設定,這裡使用的都是 Joomla 內建的角色 (role),「註冊會員」是指正確登入 Joomla 網站的人,而「管理者」則是擁有 Joomla 網站管理者權限的人。
以下圖的設定為例,必須要先登入網站才能看到 DB 中的資料,而只有管理者有權限可以新增/修改資料。
image
在過濾設定部分,建議採用以下設定:
Fabrik_NewTable_FilterSettings
進階搜尋的畫面如下,操作上很直覺:
image
Search all 的功能則是可以搜尋此 Table 內所有欄位的所有內容 (就是 LIKE 的效果啦):
Fabrik_NewTable_SearchAll
Table 還可進一步設定匯入/匯出資料的權限:
image
步驟三:開始新增 Form 中用來蒐集使用者輸入資料的欄位 - Element
以下的設定都與權限控管有關,要特別注意。以下先以 Element type = text area 為例:
image
以一般使用者身分登入是看不到 VIP 欄位的:
Fabrik_Table_UserNoVIP
一般使用者也無法修改 DB 中的資料:
 Fabrik_Table_User_CANNOT_Update
若以管理者身分登入,則可看到 VIP 欄位:
Fabrik_Table_AdminHasVIP
管理者也可以編輯 VIP 欄位:
Fabrik_Table_Admin_CAN_Update
步驟四:設定每個 Element 的 Table settings
基本上這些設定值都很好了解,若不確定作用為何,可以隨時從管理介面變更設定值,嘗試一下就知道每個設定的意義了,如下圖:
image
步驟五:若需要驗證欄位內容,則進行 Validations 設定(以驗證空白為例)
image
若使用者沒有輸入資料,會看到以下錯誤訊息,非常明確:
Fabrik_ValidationError
Fabrik 內建了很多的 validation rules,一看就知道怎麼用:
Fabrik_Element_Validation
步驟六:根據需要新增各種不同類型的輸入欄位
Field:也就是文字方塊 (textbox)
drop down:下拉式選單
image
text area:文字區域 (適合輸入大量文字)
Fabrik_text area
最後製作出來的 Form 大概就長得像下面這樣:
Fabrik_FormDemo
而呈現使用者在以上的 Form 中輸入的資料的 Table,大概長得像下面這樣:
Fabrik_TableDemo
以上就是 Fabrik 擴充套件的用法介紹,基本上都很簡單,所有的設定都存在 DB,想要深入了解網站運作方式的話可以打開 phpMyAdmin 來查看 DB 中的資料,網站原始碼 (php) 也可以好好研讀 (這就是 open source 的好處呀!)。

下一篇再來談談我對 Joomla & Fabrik 套件做的一些客製化,以及目前遇到的問題和解法。

本系列其他文章:

Google Spreadsheet 裡用規則運算式

最近因為工作關係,遇到要用 Google Form 及 Google Sheet 所以研究了 Google Sheet 裡的一些 function 怎麼用 首先,分享一下如何在 Google Sheet 裡用規則運算 :D