聚會時間公告: 因應COSCUP 2011, Kalug 8月份休會一次

四月 28, 2010
» [雲端計算] NOSQL 背後的共通原則

同樣的這篇文章, 也是老魚從簡體中文譯者那“借來”的, 除了加工再潤詞成正體中文(當然也用紅筆自行畫了重點~呵), 在文中作者提到了 Google 檔案系統論文中最初的設計基礎, 建立在“硬體與網路的失效(Failure)是必定會發生的!”, 這才是一個真正的世界, 大多的 NOSQL 實作可分為二大觀點, 重視使用硬碟, 抑或盡可能的利用 RAM做為一級存儲, 作者也進行了比較說明, 本文中對於想進入 NOSQL 技術領域者, 可以視為一篇入門文選, 所以老魚在此分享本文給各位. Wikipedia - NOSQL, http://en.wikipedia.org/wiki/NoSQLNOSQL Database ORG, http://nosql-database.org/原文: http://natishalom.typepad.com/nati_shaloms_blog/2009/12/the-common-principles-behind-the-nosql-alternatives.html Posted by Nati Shalom at 12:01 PM Dec 15, 2009 譯文: 王旭(http://wangxu.me , @gnawux)2009年12月 16/19日 簡體轉正體中文及校潤詞句:郭朝益(http://wisdomfish.org, @master) 幾個星期之前,我寫了一篇文章描述了經常被稱作 NOSQL 這一類新型資料庫的背後需求動機。幾個星期之前,我在 Qcon 上發表了一個演講,其中,我介紹了一個 可伸縮性(scalable)的 Twitter 應用的構建模式,在我們的議論中,一個顯而易見的難題就是資料庫的 規模可伸縮性(scalability)。要解答這個問題,我試圖尋找隱藏在各種 NOSQL 背後的共通模式,並展示他們是如何解決資料庫規模可伸縮性問題的。在本文中,我將盡力勾勒出這些共通的原則。 實作者們的共通原則 假設失效是必然發生的 Assume that Failure is Inevitable 與我們在此之前認知通過昂貴硬體之類的手段,盡力去避免失效的手段不同,NOSQL 實作都建立在硬碟、機器和網路都會失效(Failure)這些假設之上。我們有需要承認,我們不能徹底阻止這些失效,相反,我們需要讓我們的系統能夠在假使非常極端的條件下也能應付這些失效。Amazon S3 就是這種設計的一個好例子。你可以在我最近的文章 Why Existing Databases (RAC) are So Breakable! 中找到進一步描述。在那裡,我介紹了一些來自 Jason McHugh 所講演的以"失效"為導向的架構設計內容(Jason 是在 Amazon 做 S3 相關工作的高階工程師)。 對資料進行分區 Partition the Data 通過對資料進行分區(分割),我們最小化了失效帶來的服務失效影響,也將讀寫操作的負載分佈到了不同的機器上。如果一個節點(Node)失效了,只有該節點上存儲的資料受到影響,而不是全部的資料。 對同一資料保持多個副本 Keep Multiple Replicas of the Same Data 大部分 NOSQL 實作都基於資料副本的熱備份(hot-backup)來保證連續的高可用性(high availability)。某些實作產品提供了 API,可以控制副本的複製,也就是說,當你存儲一個物件的時候,你可以在物件級別指定你希望保存的副本數量。在 GigaSpaces,我們還可以立即複製一個新的副本到其他節點,甚至在必要時啟動一台新機器。這讓我們不必在每個節點上保存太多的資料副本,從而降低總存儲量以節約成本。 你還可以控制副本複製是同步(synchronous)還是異步(非同步, asynchronous)的,或者兩者兼俱。這決定了你的叢集(Cluster)的一致性、可用性與性能[consistency, reliability and performance]三者。對於同步複製,可以犧牲性能保障一致性和可用性(進行寫入作業之後的任意讀取作業都可以保證得到相同版本的資料,即使是發生失效也會如此)。而最為常見的 GigaSpaces 的配置是同步副本到被分界點,異步存儲到後端存儲。 動態伸縮 Dynamic Scaling 要掌控不斷呈線性增長的資料量,大部分 NOSQL 實作提供了不停機或完全重建分區的擴展叢集的方法。一個已知的處理這個問題的演算法稱為一致性雜湊法(consistent hashing)。有很多種不同演算法可以實作一致性雜湊演算。 演算法會在節點加入或失效時 通知某一分區的鄰近節點。僅有這些節點受到這一變化的影響,而不是整個叢集。有一個協議用於掌控需要在原有叢集和新節點之間重新分佈的資料的變換區間。另一個(簡單很多)的演算法使用邏輯分區。在邏輯分區中,分區的數量是固定的,但分區在機器上的分佈式動態的。於是,例如有兩台機器和 1000 個邏輯分區,那麼每 500 個邏輯分區會放在一台機器上。當我們加入了第三台機器的時候,就成了每 333 個分區放在一台機器上了。因為邏輯分區是輕量級的(基於在記憶體中的雜湊表[hash table]),分散這些邏輯分區非常容易。 第二種方法的優勢在於它是可預測並且一致的,而使用一致性雜湊演算方法,分區之間的重新分佈可能並不平穩,當一個新節點加入網路時可能會消耗更長時間。一個使用 者在這時尋找正在轉移的資料會得到一個異常。邏輯分區方法的缺點是可伸縮性受限於邏輯分區的數量。 更進一步的關於這一問題的討論,建議閱讀 Ricky Ho 的文章 NOSQL Patterns 。 對查詢式的支持 Query Support 在這個方面,不同的實作有著本質上相當的區別。不同實作的一個共通性在於雜湊表中的 key/value 匹配。有些實作提供了更高階的查詢式支持,例如文檔導向(document-oriented)的方 法,其中資料以 blob 的方式存儲,關聯一個鍵值對屬性列表(List)。這種模型是一種無預定義結構的(schema-less)存儲,對一個文檔增加或刪除屬性是非常容易 地,無需考慮文檔結構的演變。而 GigaSpaces 支持很多 SQL 操作。假如 SQL 查詢沒有指出特定的鍵值(key),那麼這個查詢就會被平行地(parallel query) map 到所有的節點去,由客戶端完成結果的聚合(aggregated)。所有這些都是發生在系統後端的,使用者程式碼無需關注這些。 使用 Map/Reduce 處理聚合 Use Map/Reduce to Handle Aggregation Map/Reduce 是一個經常被用來進行複雜分析的模型,經常會和 Hadoop 聯繫在一起。 map/reduce 常常被看作是平行聚合查詢(parallel aggregated queries)的一種模式。大部分 NOSQL 實作並不提供 map/reduce 的內建支持,需要一個外部的框架來處理這些查詢。對於 GigaSpaces 來說,我們在 SQL 查詢中隱含了對 map/reduce 的支持,同時也顯式地提供了一個稱為 executors 的 API 來支持 map/reduce。在這模型中,你可以將程式碼發送到資料所在地地方,並在該節點上直接運行複雜的查詢。這方面的更多細節,建議閱讀 Ricky Ho 的文章 Query Processing for NOSQL DB 。 磁碟基礎 vs. 內部記憶體的實作 Disk-Based vs. In-Memory Implementation NOSQL 實作分為基於檔案的方法和在記憶體(RAM)中的方法。有些實作提供了混合模型,將RAM和磁碟結合使用。兩類方法的最主要區別在於每 GB 成本和讀寫(R/W)性能。最近,Stanford University 斯坦福的一項稱為「The Case for RAMCloud」的調查,對磁碟和 RAM 兩種方法給出了一些性能和成本方面的有趣比較。總體上說,成本也是性能的一個函數。對於較低性能的實作,磁碟方案的成本遠低於基於 RAM 的方法,而對於高性能需求的場合,RAM 方案則更加廉價。 記憶體型態雲端系統 (RAMClouds)最顯而易見的缺點就是單位容量的高成本和高電能耗損。對於這些指標,RAMClouds 會比純粹的磁碟系統差 50到 100倍,比使用快閃記憶體(flash memory)的系統差5-10倍(典型配置情況和指標參見參考文獻[1])。RAMClouds 同時還比基於磁碟和快閃記憶體的系統需要更多的機房面積。這樣,如果一個應用需要存儲大量的廉價資料,不需要高速存取,那麼,快閃記憶體將不是最佳選擇。 然而,對於要求高吞吐量需求的應用,RAMClouds 將更有競爭力。當使用每次操作的 成本和電能耗損作為衡量因素的時候,RAMClouds 的效率是傳統硬碟系統的 100 到 1000 倍,是快閃憶記體系統的 5-10 倍。因此,對於高吞吐量需求的系統來說,RAMClouds不僅提供了高性能,也提供了更高的效率。同時,如果使用 DRAM 動態記憶體晶片組提供的低功耗模式,也可以降低 RAMClouds 的電能功耗,特別是在系統閒置的時候。此外,RAMClouds 還有一些缺點,一些 RAMClouds 無法支持需要將資料在多個資料中心之間進行資料複製。對於這些環境,更新的時間延遲將主要取決於資料中心間資料傳輸的時間消耗

四月 24, 2010
» [雲端計算]HBase vs Cassandra: 我們遷移系統的原因

首先要跟各位聲明的, 這篇文章內容主要是老魚去申請轉載而來, 而我僅是用長年閱讀簡體中文詞彙的經驗加以正體中文和稍加校詞潤飾, 特別選這篇文, 有幾個目的: 老魚為一個新的SNS開發專案, 進行研究評估幾個雲端(分散式)儲存系統, 過程中也是棄了 HBase, MongoDB 選 Cassandra, 而當我這二天看到這篇文中的不少技術選型的出發點, 讓我閱讀後有不少處有所同感(在文章中標紅色的段落).籍由這篇文選, 希望同是身為電腦科學工程與甚至任職企業資訊採購決策管理者一份子的您, 能從這篇文中, 去思考當我們在企業中扮演一個對資訊科技採購時, 不應只是表面名牌價格與廠商行銷手法, 龐大複雜且難以駕馭系統規劃被廠商合理化之, 反造成企業長期的營運維護成本上升, 企業逐漸受外在資訊廠商所“挾持”, 從而失去企業自我資訊自主的競爭本能.這篇文中如果扣除作者在評論其二家產品, 各位看官也可以獲得不少目前電腦科學領域中當前最競爭的幾點新知, 尤其作者是以該領域的專家評論, 在出發點上就不會有太多被一般新聞過度炒作“雲端計算Cloud Computing”名詞上的疑慮.文中作者也對 CAP, CA, AP 等理論給予突破性的實證觀點.原文: http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ 原作者:Dominic Williams 原文發佈日期:February 24, 2010 at 7:27 pm 譯者:王旭(http://wangxu.me/blog/ , @gnawux) 翻譯時間:2010年3月21-25日 簡體轉正體中文及校潤詞句:郭朝益(http://wisdomfish.org, @master) 我的團隊近來正在忙於一個全新的產品——即將發佈的網絡遊戲 www.FightMyMonster.com。 這讓我們得以奢侈地去構建一個全新的 NoSQL 資料存儲庫系統,也就是說,我們可以把恐怖的 MySQL sharding 和昂貴的可伸縮性拋在腦後了。最近有很多人一直在問,為什麼我們要把注意力再從 HBase 上轉移到 Cassandra 上去。我確認,確實有這樣的變化,實際上我們在基礎上已經把程式碼移植到了 Cassandra 上了,這裡我將作出解釋。 為了那些不熟悉 NOSQL 的讀者,在往後的其他文章中,我會介紹為什麼我們將會在未來幾年中看到如地震般的從 SQL 到 NoSQL 的遷移,這正和向雲計算的遷移一樣重要。往後的文章還會嘗試解釋為什麼我認為 NoSQL 可能會是貴公司的正確選擇。不過本文我只是解釋我們選擇 Cassandra 作為我們的 NoSQL 解決方案的選擇。 免責聲明——如果你正在尋找一個捷徑來決定你的系統選擇,你必須要明白,這可不是一個詳盡而嚴格的比較,它只是概述了另一個初創團 隊在有限時間和資 源的情況下的邏輯。Cassandra 的血統是否預言了它的未來 我最喜歡的一個電腦工程師們用來找 bug 的謁語是「廣度優先於深度」。 這也許可能對那些解決技術細節的人來說很惱人,因為它暗示著如果他們只是看看的話,解決方法就會簡單很多(忠告:只對那些能夠原諒你的同事說這個)。我之所以給出這個謁語的原因在於,我發現,軟體工程問題中,如果我們強迫自己在進入某行程式碼的細節層面之前,先去看看那些較高層次的考慮的話,可以節省大量時間。 所以,在談論技術之前,我在做 HBase 和 Cassandra 之間的選擇問題上先應用一下我的箴言。我們選擇切換的技術結論可能已經可以預測了:Hbase 和 Cassandra 有著迥異的血統和基因,而我認為這會影響到他們對我們的商業適用性。 嚴格來說,Hbase 和它的支持系統源於著名的 Google BigTable 和 Google 檔案系統設計(GFS 的論文期刊被發佈於 2003 年,BigTable 的論文發於 2006 年)。而 Cassandra 則是最近 Facebook 資料存儲庫系統的開放源始碼分支專案,它在實作了 BigTable 的資料模型的同時,使用了基於 Amazon 的 Dynamo 系統架構來存儲資料(實際上,Cassandra 的最初開發工作就是由兩位從 Amazon 跳槽到 Facebook 的 Dynamo 電腦工程師完成的)。 在我看來,這些不同的歷史也導致 Hbase 更加適合於資料倉儲、大型資料的處理和分析(如進行 Web 頁面的索引等等),而 Cassandra 則更適合於實時(Real-Time, RT)事務交易處理和提供交互型資料。要進行系統研究來證明這個觀點超出了本文的範疇,但我相信你在考慮資料庫的時候總能發現這個差異的存在。 注意:如果你正在尋找一個簡單的證明,你可以通過主要 Committer(對參與專案程式撰寫並提交貢獻者之稱) 的關注點來進行驗證:大部分 HBase 的 committer 都為 Bing 工作(M$[Microsoft] 在去年09收購了他們的搜尋公司,並允許他們在數月之後繼續提交開放專案的程式碼)。與之對應,Cassandra 的主要 committer 來自 Rackspace,用來可以自由授權獲取, 支持先進且通用的 NoSQL 的解決方案,用以與 Google, Yahoo, Amazon EC2 等所提供的鎖定在專有授權的 NoSQL 系統解決方案的相互抗衡。Malcolm Gladwell 會說只是根據這些背景的不同就可以簡單地選擇了 Cassandra。不過這是小馬過河的問題。但當然,閉著眼睛就進行一個商業選擇是相當困難的…… 哪個 NoSQL資料儲存庫風頭更勁? 另一個說服我們轉向 Cassandra 的原因是我們社群中的大風潮。如你所知,在電腦科學平台行業裡,始終有著大者恆大的慣性——那些被普遍前景看好的系統平台,會有更多人群聚在這個平台周圍,於是,從長遠來看,你可以得到更好的生態系統的支援(也就是說,大部分支援的軟體工程可以從該社群中獲取,並且也會有更多的開發者可以因此被僱傭)。 如果從 HBase 開始時,我的印象就是它後面有巨大的社群力量,但我現在相信,Cassandra 更加強大。最初的印象部分來源於 StumpleUpon 和 Streamy 的兩位 CTO 兩位非常有說服力的出色的演講者,他們是 Web 行業中兩個在 Cassandra 成為一個可選系統之前的 HBase 的兩個重要的貢獻者,同時也部分來源於閱讀一篇名為「HBase vs Cassandra: NoSQL 戰役!」的文章(大部分內容都己被廣泛證實了)。 勢力是很難被確證的,你不得不自己進行研究,不過我可以找到的一個重要的標誌是 IRC 上的開發者動向。如果你在 freenode.org 上比較 #hbase 和 #cassandra 的開發這頻道,你會發現 Cassandra 差不多在任何時候都有達兩倍的開發者在線上。 如果你用考慮 HBase 一般的時間來考察 Cassandra,你就能發現 Cassandra 的背後確實有非常明顯的加速勢力。你可能還會發現那些逐漸出現的鼎鼎大名,如 Twitter,他們也計劃廣泛使用 Cassandra(這裡)。 註:Cassandra 的網站看起來比 HBase 的好看多了,但認真的說,這可能不僅是市場的趨勢。繼續吧。 深入到技術部分: CAP 和 CA 與 AP 的神話 對於分散式系統,有個非常重要的理論(這裡我們在討論分散式資料庫,我相信你 注意到了)。這個理論被稱為 CAP 理論,由 Inktomi 的 聯合創始人兼首席科學家 Eric Brewer 博士提出。 這個理論說明,分散式(或共享資料)系統的設計中, 至多只能夠提供三個重要特性中的兩個——一致性(C)、可用性(A)和容忍網路分區(P)[Consistency, Availability and tolerance to network Partitions.]。簡單的說,一致性指如果一個人向資料庫寫了一個值,那麼其他使用者能夠立刻讀取這個值,可用性意味著如果一些節點(Node)失效了,叢集(Cluster)中的分散式系統仍然能繼續工作,而容忍分區意味著, 如果節點被分割成兩組無法互相通信的節點,系統仍然能夠繼續工作。 Brewer 教授是一個傑出的人物,許多開發者,包括 HBase 社區的很多人,都把此理論牢記在心,並用於他們的軟體系統設計當中。事實上,如果你搜尋網路上攸關於 HBase 和 Cassandra 比較的文章,你通常會發現,HBase 社群解釋他們選擇了 CP,而 Cassandra 選擇了 AP ——毫無疑問,大多數開發者需要某種程度的一致性 (C)。 不過,我需要請你注意,事實上這些生命基於一個不完全的推論。 CAP 理論僅僅適用於一個分散式演算法(我希望 Brewer 教授可以統一)。但沒有說明你不能設計一個超出理論的系統,並在其中各種操作的底層演算法選擇上進行特性切換。所以,在一個系統中,確實一個操作職能提供這些特性中的兩個,但被忽視的問題是在系統設計(SD)中,實際是可以允許調用者來選擇他們的某個操作時需要哪些特性的。不僅如此, 現實世界也非簡單的劃分為黑白兩色,所有這些特性都可以以某種程度來提供。這就是 Cassandra。 這點非常重要,我重申:Cassandra 的優點在於你可以根據具體情況來選擇一個最佳的折衷,來滿足特定操作的需求。Cassandra 證明,你可以超越通常的 CAP 理論的解讀

十一月 8, 2009
» [雲端計算]台灣區Hadoop使用者社群會議

老魚後天 11/10要北上新竹竹科的國家高速網路中心, 做為一位小主題的分享講者 - 台灣區 Hadoop 使用者社群會議, 在這廣邀大家一同到場分享您的心得, 與結交在場的愛好者. 雲端運算於海洋資訊之前瞻應用研習暨 第一屆台灣區 Hadoop 使用者社群會議 Cloud Computing for Advanced Ocean Research and Hadoop Taiwan User Group Meeting 2009 會議時間:九十八年十一月十日(週二) 會議地點:國家高速網路與計算中心 國際會議廳      (新竹市研發六路七號) 主辦單位:國家高速網路與計算中心 協辦單位:台灣海洋科技研究中心 報名網址:http://registrano.com/events/hadoop-tw 聯絡電話:王耀聰 (04)2462-0202 # 834    繼格網運算之後,雲端運算被視為下一代資訊架構的主流。雲端運算平台 Hadoop 及雲端資料庫平台 HBase 與 Hive 均是目前諸多雲端運算服務的基礎架構。Cloudera 是目前全球首先提供自由軟體 Hadoop 技術支援的商業公司,本次使用者會議特別邀請來自 Cloudera 的 Christophe Bisciglia 來跟我們分享如何運用 Hadoop 打造雲端應用程式與軟體服務,並分享自由軟體的可行商業模式:教育訓練與認證機制。此外,也邀請了國內推動 Hadoop 教學、軟體開發、社群建立的幾位同好來進行知識分享,包括:台灣雅虎、老魚研究室、國立台灣大學資訊工程學系通訊與多媒體實驗室與國家高速網路與計算中心雲端運算研究小組。希望透過此次會議,讓更多有興趣瞭解 Hadoop 的夥伴相互交流,進行凝聚出台灣區的 Hadoop 社群。     本會議不收取任何報名費用,歡迎各界踴躍參加。礙於此次會議場地座位有限,請速上網報名(http://registrano.com/events/hadoop-tw),額滿為止。也請大家代為宣傳(議程PDF版)。

八月 27, 2009
» 感謝NCHC二位講師的指導(Hadoop Project Architecture)

首先仍要再提一次

因為老魚一直都不是"一個人", 而是一整個不同的社群團隊的力量所驅策,
到今天, 老魚最高興的就是收到來自全球華人希望加入團隊的mail,
算算大約一個月能有三位合適的新朋友加入,
老魚一直深信, "主動"學習者的動力會促使並加速分享與學習研究成果,
而這力量的轉化, 是遠勝過任何研究機構與學術單位的.

雲端計算(Cloud Computing)在此時被"熱炒"著,
老魚和十多位(參與人數半年來的成長) 社群團隊成員們,
我們歷經從零到今的實作, 子主題的分工研究,
定期的討論, 協作(Wiki)平台的知識累積 ...,
直接與間接參加不同單位舉辦的 Cloud 研討會, 實作課程 ...
(但仍有不少“文不對題“/是懂非懂的Speaker, 這不良的風氣, 台灣需要加油!!!)

一位“聽者“不懂, 只影響他自己,
但為他人演說者的裝懂與根基不厚實的影響力,
卻遠超乎您個人和對大眾帶來的蝴蝶效應.

在這老魚要推崇二位教學態度認真詳細與實力厚實的NCHC講師, 

講師:
國家高速網路與計算中心 王耀聰 先生
國家高速網路與計算中心 陳威宇 先生

老魚雖未實際參與現場, 但各位教者請勿忽視“學生“口耳相傳的影響力,
老魚團有三位隊友, 參加了前二天的 NCHC 課程,
對這二位講師讚譽評價極高!!!
(這三位學生可是參加不少其它雲端計算的大小課程戰績,
老魚還是第一回聽到從他們口中有高評價出現.)

在這老魚要感謝上述二位講師對老魚團隊提出的問題熱忱地回答,
讓我們社群團隊能順利前進著, 他們帶回了二位講師的二天全程錄音, 教材, 心得...,
更重要的是帶回了可能的新隊友,
我們將在接下來的日子消化二位講師的寶貴研究成果,
最後仍謝謝您們, 台灣需要更多像二位教學態度與實力相俱的教育兼研究者.

Hadoop 專案架構圖(Hadoop Project Architecture)


老魚一直持續以“太公釣魚“之姿,
期待更多與老魚分享有關社群主題有熱血學習甚至研究的“您“加入,
不管是虛擬的meeting或是直接參與老魚不同的實體讀書會,
老魚和團友們都會熱忱的歡迎您!!!


老魚相關

五月 7, 2009
» [分享製圖] 雲端計算中的資料儲存系統 HBase (已補圖)

既以為人,己愈有。既以與人,己愈多。
- 道德經 第八十一章

上面的經句在說明:
當您以己之所能為他人服務或協助時,而您己亦愈相對收獲得更有。
當您以己之所擁有物給與或幫助他人時,而您亦己獲得更多與進步。
這也是老魚在能力範圍奉行的“分享即所得“,
也是經常叮嚀小沙瀰們要互相拉提學習的精神.

老魚與同好在高雄市的第三次定期實體聚會成果概述記載如下:
該記錄的時間應於 2009-04-30, 參與人數: 5.
但老魚總是要消化當天的分享後, 才能寫下本篇內容, 下面是前二次的成果:

本次聚會, 我們的團進度除了對上周所留下的問題部份疑慮有了新的解釋,
也修正了部份不太適當的建構分散式運算系統架構的部署問題討論;
在本次的討論與實作的 Demo 我們的主題擺在 HBase,
HBase 是 Google Bigtable 的 Java RI 實作,
在過程中, 負責研究HBase團友為我們講解了Bigtable論文中的基本概念,

另一位負責研究Hadoop系統工程之一的團友,
為我們現場展示與講解:實作由 5部主機組成的分散式叢集系統與HBase的部署,
並展示了上次meeting中團隊間所存在的疑慮點,
在這展示的環境中, 實際了解了 HBase 的組成架構,
也透過討論和當場的實作對HBase有了初步的操作與系統運作模式,
並為下週 meeting 的新議題再次進行分工.

老魚把這研究團的相關內容整理置於本Blog的右上的連結清單中:
下圖為老魚製作並分享對HBase的基礎概念關係圖(點圖放大再存檔)

四月 24, 2009
» [分享製圖] Hadoop 基礎安裝與簡要架構

Cloud Computing - "烏雲" - 高雄實體聚會心得

繼上週在高雄進行第一次雲端計算的實體聚會後, 照表操課 ...

昨晚我們在同一地點, 再次進行討論與實作 Hadoop 的安裝與設定問題上的討論,
過程當中, 老魚要感謝參與研習的戰友們, 經過了一週持續的各自分工,
得以讓我們能在不到二小時內, 從實作到產生新的看法與得到下週分工議題.

下圖是本次聚會與實作後的心得概要圖, 給需要的您參考用:
Cloud Computing - Hadoop / HBase - Base Installation & Arachitecture


我們會持續的將過程記載到一個協作平台(目前處於未公開階段),
但老魚仍會適時的將過程分享給各位.

附帶宣傳:
如果您是同好中人, 或是曾經是老魚的學生, 請與老魚連繫 !
老魚需要更多 Linux or Java 的熱情研究者, 高雄者佳(只是方便讀書會~呵)

support:

biggo.com.tw

A Django site.