主持人歡迎各位還繼承留在我們今天Apache的會場，這次我們很有幸有很多來自于Apache社區的實際的開發者，跟大家能夠有背靠背的機遇，來講講他們在實際項目操作當中所遇到的一些問題，所以下戰書的部分，我們每一場都留點時間讓大家提一些很實際的技術問題。

我們今天有Hadoop項目標，有CloudStack等等團隊的成員，今天第一場比較有趣，是由一個團隊，Apache的一個團隊來講講OpenOffice進入到Apache社區之后不同的情況，以及在中國的發展，首先有請Peter Junge。

劉順風謝謝Peter先生介紹了Apache的歷史以及將來的瞻望，我是IBM中國開發中心的經理，我的團隊成員也參與Apache OpenOffice開發的過程中。

今天我用很短的時間，介紹一下在這樣大的開源社區里面，我們來自北京的志愿者們都做了出了哪些貢獻，這是非常有趣的話題，開源離我們非常近，因為我們的志愿者們就在身邊。

首先問大家有多少人用過OpenOffice這個產品？很興奮看到這么多人都舉手，有多少人去社區轉過？看看有什么問題能夠得到解答，或者有什么事情能夠幫下忙。看來這個人就少了很多。我其實今天的目的就是生機能夠吸引更多的人來參與我們社區開發，成為我們社區的一員，一起來推動這個開源項目標發展。

大家可以看到，其實異常近的，就在我們身邊，就在這個軟件園里面，其實我粗略算了一下，大概有三十多個來自北京的意愿者，在這個社區里面工作，而且他們起了十分要害的作用，他們有來自于良多公司或者個人的供給者，比方Peter，他也在北京，我也把他算了進去。

這些來自北京的自愿者，在Apache OpenOffice發展過程中，尤其是當它去年從一個Oracle脫離加入Apache這個過程起的非常中心的作用，他們的工作從開發測試到后面的用戶界面的設計，到翻譯等等，很多的工作，甚至是產品推廣都起了很大的作用。

從OpenOffice加入Apache社區以來，我們現在正在做4.0.1，這是很大品質的用戶休會的晉升。北京的意愿者都在這里施展著極其重要的作用。

參與了簡直所有版本的開發，而且在里面起到的作用很要害，有些性能的提升，有些對微軟文檔的兼容性的提升，我們都做出了很多的貢獻，而且還有一些癥結問題的修復。包括值得兩個說的貢獻，IBM這邊把所有開發了五年的英文貢獻出來，里面包含了很多的IBM自己開發的功能，包括一些重大的性能晉升，還有像對于殘疾人士所謂無阻礙的功能。下一步在4.0里面我們要把這些東西進一步的合在Apache OpenOffice里面，給寬大用戶帶來真正的利益。另一個，中標的他們貢獻他們了UOF的格式，對我們國內的用戶是一個非常好的福音。這是開發這邊。

測試這邊，我們有許多的人介入到測試的過程中，完全是從頭來樹立這樣一個產品的測試架構，大家曉得其實Apache社區里面，大部門的產品，大家有沒有留神過，它針對的是一些什么樣的用戶。其實大局部產品針對的是開發職員，好比說我們的HTPServer，等等這樣一些工具，像是一個開發包。OpenOffice不一樣在于它是一個在這個社區里面比較少見針對終極用戶的產品，它的代碼量級以及產品的龐雜度，都比良多開源社區產品要高許多，這時候顯得非常的重要，我們測試工程師花了很大的精神，簡直從頭樹立測試的流程，籠罩了產品開產生命周期全過程。還開發了主動測試的腳本，這都是他們在社區里面經由大家探討而使用的一些，同樣也是開源的測試治理工具，發生了讓大家很可以清楚懂得這個產品德量的測試講演按期宣布，這是測試方面的貢獻。

另一方面，我們還有一些非常可貴的資源，我們的用戶休會，我們的界面設計，美工的工作者，他們不僅在為Apache下一個版本的新的界面正在盡力工作，而且也有很多的介紹，比如說我們大家如果用了Apache OpenOffice會留神到，我們有很豐盛的模板庫，這個模板，如果你在一個美麗模塊的基本上工作，做出來的文檔非常英俊，而且不必費太大的工夫，我們設計者也貢獻了很多的模板在這里，今天我們使用的這個模板就起源于我們北京的設計者，這里列出來第一個模板被歐洲Apache大會所使用，有著很好的反應。

最后翻譯，作為這么一個直接面對終極用戶的產品，翻譯長短常異常主要的。我們Apache OpenOffice已經有完全翻譯的中文版，在下一步的開發中跟著我們新功效的開發要進一步完美我們的翻譯工作，作為我們產品推廣，網站翻譯其實這里面有很大的差距，如果大家到OpenOffice的網站上看一看，其實中文網頁無比少，這是需要大家每個人去貢獻的，一起來參加這個翻譯的工作。

我很快過了一些主要的我們來自北京的志愿者做出來的這些貢獻，我的目的是什么呢？非常簡單，我號令大家來加入我們。三十多個來自北京的志愿者，其中大部分已經是存在直接提交代碼的權利，這是非常不容易的事情，在國內參與Apache社區里面來說，這是一個很大的量。大家可以看到，我吶喊大家來加入社區，加入我們，好處很顯然，尤其在國外，大家甚至能看到有些公司在招人的時候，都很重視是不是有開發的閱歷，如果大家以后希望去國外留學或者找工作的話，如果你說我在Apache OpenOffice社區里面做過開發，那是一個非常非常好的，在你簡歷里面的一個亮點。

我愿望大家能夠多使用下載最新版本的Apache OpenOffice，并且接下來贊助我們一起宣揚這個產品，其實Apache OpenOffice它的主要用戶群下來集中在歐洲和北美是最多的，那么國內我感到我們其實還有很多的宣揚空間在里面，當大家被迫交錢買Office，沒有措施的時候，其實很多人并不知道有其他的方法，讓大家知道我們其實有更多的抉擇在里面。

接下來，我知道在座有很多技術職員，技術蠢才，愿望能加入我們，來做開發、測試這樣的工作，還有其他的一些工作可以做，比如參加我們網站的翻譯和保護，或者輔助我們完美一些人，甚至我在社區里面，根據我的使用教訓，來給我們其他新來的OpenOffice的用戶來提供一些反饋，比如說他們提出的問題，就我的教訓我可以答復，這都是從點點滴滴做起的，為我們社區做貢獻很好的例子。

其實作為一個開源社區，其實我不是一個參與時間非常久的，我是從去年開始的，我覺得在這中間，領會到一種國際化交換的，開源社區里的一種氣氛，這是我感到到非常有樂趣的事情。在Apache社區里面是人人同等的，每個人作為獨立的個體必須做出自己的貢獻，每說一件事情的時候你并不沒有權利逼迫別人批準你，你來提議沒人反對我就可以自己開始著手去做了，甚至如果我的提議非凡人，會有人加入我，這是開源社區最樂意看到的一個結果。

我這里列出來的這些開始的點，到哪下載我們的產品，到哪加入我們的郵件列表，甚至我想做一個開發，我應該從哪學起，先從Apache準則做起，我應該怎么搭環境，怎么考慮問題等等，列出來的這樣一些鏈接，會后這個我們會發出來，大家都會看到，大家去谷歌、百度一下OpenOffice大家就可以找到我們的站點，直接去找有用的信息，有什么問題都可以直接在列表里面找。這是我一個簡單的介紹。不知道大家有什么問題嗎？如果沒有什么問題的話，下面請劉濤幫我們介紹UOF，以及我們公司在OpenOffice上做的一些工作。

劉濤大家，我是來自于中標軟件有限公司的，負責公司Opensource這塊，包括我們公司的操作系統，還有云安全操作系統，Office也是一塊，今天主要是講Office。

在今年Apache的年會上，把我們給OpenOffice做的一些貢獻，今年在德國舉辦的Apache年會，把我們做的工作已經講了一部分，UOF這塊還有后面，我所說的企業和政府的辦公主動化這塊是沒有講的，所以拿到這邊做一下分享。剛才Peter已經把OpenOffice前生今世還有它的幾個孩子說得很明白了。我今天講一下UOF在中國的應用，UOF簡單的介紹，還有就是它的兼容性問題的解決計劃，以及一些功能。

在海內有這么幾家公司都去做了UOF文檔格式，首先是中標軟件在做，有金山，還有微軟，還有IBM。UOF我們叫國家文檔格式尺度，最早的發布是一個1.0版本，是在2007年發布的。在07年到09年之間，始終在完善，從1.1、1.2，始終到1.3，09年提了一個草案，這個草案結束之后，后期會做一個發布，現在還沒有發布2.0版本。

UOF這個文檔，2.0版本里面它把原來UOF這個文檔格式變成了三種格式，對于文字處理用了UOT格式，電子表用了UOS格式，演示文稿用了UOP的格式，由多過XMAL文件組成的，2.0絕對于以前1.0的版本，了解UOF的比較少，如果有了解的話，2.0版本做的一些改進，去掉了一些LOGO和ID，屬性列表，增加了內部ID和多元的符號，解決了一些單一檔次和繼續檔次的元素關系等等，這是它對于國家文檔格式標準的一個圖。

UOF文檔格式的標準，它支持什么，支持國家的這樣一個政府的公文，和政府公文都要求的排版、結構都是比較緊的，當你要修正一個字體或者字號的時候這個格式就不會被通過。大家可以看一下這有一個截圖，在做政府辦公的時候，比如說上面的這個份號，密級，保密期限等等，這個模板是今年國家制訂了一個新的國標的模板，這個模板就是你必需要遵照它的這個排版格式，比如說我的一個稿件里面的一頁是多少行，每一行有多少個字這都是有嚴厲要求的。

那么真正做到政府的辦公文檔格局和一般通用的文檔格局之間的轉換呢？這里面就波及到文檔尺度轉換的問題，用XSLT，相稱于是款式單，來把一個文檔轉化成XMAL文檔，這是它的Import process，在一個文檔當中把他的數據，當然這個數據分兩個部門，我們把以及視頻這樣的數據轉化成一個64倍的，然后把它變成，合并成一個FLATS這樣一個文件，之后再把它輸出成一個ODF。

時間關聯，也說得比較快，可能大家只有一個理性上的意識。現在我們正在做的工作也就是要解決一些在這個過程之中呈現的一些問題，然后把2.0的UOF代碼進行保護。非常歡送大家能夠加入我們去做這件事情。這是UOF貢獻的這一塊。

下面我會講一下ApacheOpenOffice在企業和政府的辦公自動化領域中的應用，相當是我們基于ApacheOpenOffice做的一個解決方案。

可能我會分幾個方面，一個是技術的解決方案，還有會主要從細節上說一下，Firefox，遠程文檔的操作，最后就是有幾個例子，政府的，軍隊的，還有醫療行業的，最后做一個小節。

技術解決方案之中，首先我會給大家展現一個Firefox的圖。然后是監聽反饋機制，最后是文檔的機制。這張圖就是Firefox工作的流程圖，紅色背景的可以理解成一個瀏覽器，plugins就是一個插件，他對Office的啟動，第二就是跟英文橋做通訊，第三就是部分監聽機制，最后一個就是遠程文檔的操作。上面對于插件和閱讀器之間用什么樣的方式進行轉換。這是一個英文橋的介紹，我不細講，目的就是轉換Firefox插件，讓JS和Firefox插件之間建立一種聯系。

對于監聽和反饋機制，我在閱讀器里面會有鼠標、鍵盤的動作，當然這些動作都不是針對與Office本身做操作的，是在Office外面進行操作，比如右鍵這些動作，這些動作怎么讓Office知道，就是有一個監聽的機制，實現從外部接口去解決Office內部的東西，當然它確定也是基于剛才講的UNO的實踐，這是整個Liscens架構圖，可以看一下。

之后就是遠程文檔操作，我們提供兩種，一種是對于遠程的文件情勢的這樣一種操作，我的JS代碼都是寫在服務真個，Office的插件里面我基本是不會存在這些可以與外界進行溝通的一些代碼的，這樣做的目的是保障平安，因為服務端操作的話，安全性是需要保障的。

在前端用JS包裝這個接口的好處有很多，本來我們的接口是這樣的，我們用JS包裝之后，他就會把這些接口轉化成，你可以給任何團體商或者開發商去做，不用給他開放Office這塊接口，只要給他一個JS的接口，他就可以做他想要做的任何事情。這是它的一些好處，比如說比較穩定，開發速度快，可以對自己的系統做定制，比較容易使用。這是我們的一些案例，我剛才說的只是在Firefox中的插件，當然我們這個插件有很多種，比如在Windows機器上也有一些控件，這是政府辦公的應用，部隊是Firefox控件的應用。這個是在醫療行業的應用，我就說這么多，小結一下，有很多種控件可以運用于很多個行業。我先講這么多。

劉鼎力大家好，接下來的時間交給我，我是來自于IBM的劉鼎力，接下來這個主題恰好跟我們今天這個云，看一下我們Office產品怎么跟云平臺，怎么跟我們一些主要的Social的社交軟件集成在一起，看一看我們文檔處理并不是簡單的文檔處理，在今天的環境中我們有更多的挑選工作方式。

現在大家都知道，大數據、云還有Social都是比較主流的概念，如果我們的一個軟件還有包括我們的解決方案，不包含這些點，你都不好心思說你是做軟件的。

我們看一看云是有私有云，有公有云，我們OpenOffice都是可以引入進去的，他并不是獨破的桌面應用軟件。我們可以思考一下，在現今信息爆炸的時期，我們怎么樣在云時期，在Social時代處置我們的文檔呢，國度的正版化是無比倡導的，桌面云客戶端去拜訪的時候都要斟酌Listens的本錢問題。

在國內很多人多不知道，在文檔處理這一塊，我們有另外一個取舍，就是我們的OpenOffice。我們講一下現在無處不在，都帶Social，我們每一個人手上都有一個挪動中止，包括我們無處不在的無線網絡，包括新浪微博，騰訊微博,云計算實施，Facebook這些都是我們Social的一些信息分享渠道，那我們如何在我們做文檔處理的時候，去引入這些信息呢，怎么樣去把我們自己寫的一些文章，分享給其他人，在我們做OpenOffice的時候，我們有一種擴展機制，可以讓我們方便的去跟我們后盾這些SocialServer做一些集成，其實這種模式不止應用于OpenOffice，其實大家也可以看一看，我們有一些自己的應用，其實也完全可以采用這樣的架構去做一些擴展，跟我們的服務連接起來。現在有很多公司肯定也是這樣去做的。

這里面提到的Social Cnnectors這個概念，怎么跟后盾聯系起來，今天是偏技術的會議，可以看到，在我們中間是應用了一系列的Social這些接口，我們用這些接口就可以從服務商那里拿到我們想要的數據。在前端在我們的客戶機上，或者是我們的桌面云上，我們通過這樣一系列插件，能夠把我們的數據整合在文檔里面，反過來也是一樣，我們可以把我們做的文檔分享給其別人，這個可以是一個全文檔的分享，也可以是一些信息片斷的分享。

這個里面大家可以看到，剛才講到的是Social的應用，這里面是一種桌面云的應用，桌面云很簡單，你能夠在任何地方去訪問這個桌面，這個桌面現在正常用虛擬技術。在國內也是越來越看重的，所有在桌面上的軟件，其實都有一個LI成本考慮的問題，如果云的服務商，提供一個沒有LI的軟件其實是一個很大的法律問題的，這里面OpenOffice提供了一種取舍，能夠讓我們用戶釋懷勇敢地去使用正版的文檔處理的工具，而且前面我們也講到，我們的OpenOffice，大家是可以拿到它的原代碼，隨便去從新發布，從新做自己的定義。改個名字，打個包，換個外殼，加入自己一些自有的功能就可以去做我們商業軟件上的應用。

這個是我們在云上面去用我們的OpenOffice。

我們可以看一個我們的演示，我們OpenOffice是如何從我們社交環境中去做一些信息的收集。這個演示是一個很簡單的場景，我在做一個報告稿，我希望從我的社交網絡里面收集一些意見，在以前，這些方案可能我把這個文件文檔通過郵件發送給其他人，讓其別人通過郵件反饋回來，現在在我們這種模式下，我們可以看一看，我們是如何工作的。比如就這一頁的頁面，我想去收集大家的反饋，我可以通過我們右側工具插件，疾速把這個頁面，直接發布到我的社交網站上去，當我發布好以后在我的網站中相關的關注我的人，就可以看到，他們就可以倏地的給我一個回復，這里面我用的是IBM的一個產品，其實這種機制我們完全可以應用發到Facebook，新浪微博上去。在這里面我的共事，或者是我的經理們看到了我發布的這個頁面，大家給我一些修改看法，他直接就在這個網頁中去操作，把他的意見寫好，寫好以后，我是不需要再登陸我的網站中來，我直接就在文檔編譯器里面直接可以看到別人給我的意見，這個時候我根據這個意見就可以做出快捷修改。

大家看看這種工作方式，我們可以看到看法，改好當前可以持續做其他的事情。同樣的場景，在當今Server這種環境中，通過我們擴展的方式很快就到達了，如果我沒有這樣的Social的集成，我們會發現我們要走一段很長的路，而且等候的時間也是沒有那么有效力。

所以說大家看到，我們OpenOffice并不僅是文檔編譯器，也是一個擴大應用平臺，那么這個平臺可能給我們提供各種的擴展才能，這里我演示的是跟Social做的一個集成。其實我們可以做其余的跟文檔存儲，包含我們百度的文庫，還有跟其他云上數據的存儲都可以以這種去關系起來。

我們是用了我們的開發工具，這個開發據也就是一個開源的工具，大家都可以在社區網站中獲取到，我們運用了一個開發接口，這個接口也是大家可以隨便獲取到的，UNO的接口，社區這邊有很好的開發手冊，我們開發人員很愿意幫助大家回答一些問題。

總體來說這個就是我們剛才講到的，如何在我們的社區里面，用OpenOffice做一些云跟Social上的一些集成，這里面我再一次號令大家來加入我們OpenOffice這個大家庭，你在里面可以去貢獻自己的力氣，也可以基于OpenOffice這個平臺去構建你自己的應用和自己的解決方案，甚至你可以拿到OpenOffice的代碼，然后做出自己的修改。大家如果感興趣的話，所有的事情都可以通過我們的郵件列表獲取到，可能我們的技術人員這塊，從我們的網站開始是一個比較好的地方，謝謝大家！

主持人十分感激Apache的OpenOffice，OpenOffice從以前的SUN緩緩走向社區之后，后來又從Oracle轉到獨破的Apache社區，也是閱歷了長期而艱難的進程，一個產品如果要讓它有更強的性命力，可能這種NGO的模式合作方法，可能會讓它更長期，這是長期大家奉獻社區的一個常識的產品，如果只是貿易行動的操作，把它廢掉的話，實際上是很惋惜的事件。我們請Raymie談一談Hadoop新的Resource Manager的產品。

Raymie英文

主持人非常感謝Raymie今天下晝給我們帶來出色的報告。接下來有請來自VMware杜君平來講講Hadoop的Virtuallzation。

我們今天大會主題也是云計算大會，云也是屬于今天最時興的一個詞，上到國度總理，下到布衣庶民，大家多多少少對云計算都有一些懂得，這里面有一些泡沫的成分在里面。首先我們以為云計算能夠簡化企業的IT運維本錢，第二因為它減少了很多企業對硬件的需求，通過虛擬化可以減少很多硬件的支出，治理的支出，包括能源的支出。它可以非常迅速為企業提供IT服務，所以我們現在生涯在一個比較好的云計算的時代。

那么對于大數據或者說企業的數據分析而言，企業有不同對數據的需求，有些是傳統的數據的需求，還有需要Hadoop這樣的大數據平臺，我們眼中的IT不盼望它是一個一個孤島，企業有不同的人在經營不同的系統，可能他們在下面會是一個統一的，上面有不同的有Hadoop的等等，他們可以做很好的共享。

對大數據而言，咱們盼望通過虛構化來更好的做全部大數據平臺。我們目的有多少點，首先我們在同一的云平臺上面更好的，依據你的需要，來供給數據處置的平臺跟盤算才能的集群。而后我們興許你在統一的云平臺之上，把不同的運用進行混雜，由于有些運用是CPU的，有一些利用是內存的，不同的應用對資源有不同的需要，我們假如可能在同一的平臺上把這些利用很好的混雜起來，那么咱們能夠進步全部資源的應用率。

后面對于大數據平臺而言，放到一個云平臺，或者一個虛擬化平臺上，會不會呈現任何的水土不服呢，因為它在云上面有很多很靈巧的這種部署的方式，這種部署方式，包括你的數據避免策略，可能都需要調整，我們需要一些額定去處理這些事情。

總體而言有了云計算，有了虛擬化，我們可以讓Hadoop能夠做到彈性的伸縮，能夠做到比較容易的達到高可用性。有更好的管理和隔離，對于云計算也好，企業的不同數據中心，或者數據應用是非常重要的。

所以我們要做最好的虛擬化的平臺，我們都做了哪些事？首先去年我們發了一個白皮書，是Hadoop在虛擬化平臺上性能的剖析，可能大家也會比較關懷這個問題，待會我會簡單介紹一下。另外我們踴躍參加到Apache的Hadoop社區里面，為這個社區做一些貢獻,私有云，讓Hadoop在虛擬化和云計算的平臺上去經營得更好。也就是我今天主要要介紹的內容。我們還有一些項目，我們簡化程序的開發，主要是這三部分的內容。

這是一個數據，我們在Virtuallzation5上面經由很好的調試之后，我們發明跟其他的應用一樣，基礎上在虛擬化或者云計算平臺上運行Hadoop，大數據這樣的平臺，根本上他的機能后果也是蠻好的，大略在5%到10%的性能喪失率。我們在處理的過程中，我們想了好幾個計劃，首先我們或許是在十幾個Server里面，把虛擬化之前和虛構化之后做了比較，每個結點有幾個破綻，我們做了各種各樣的對照。

下面介紹一下我們的Hadoop Virtuallzation，Hadoop在虛擬化的平臺上面做的一些擴展和優化。我們這個項目主要是做一些改良的工作。我們這個項目最后的產出提交到Hadoop，被用戶所接收，然后達到更好的優化的效果。同時會跟社區里面的人做一些配合,虛擬化安全。這個HVE主要是幾項工作，我們要支持code base，第二在云的環境下，這些資源，操作系統里看到的資源并不是你實際可以取得的資源，這也是我們需要考慮的。我們現在想做的事情是，我們在同樣的物理裝備上，我們把虛擬結點，計算結點和數據結點離開。我今天主要會討論多層的網絡結構，以及數據和計算結點分別。

剛才說到Hadoop，Hadoop是三層，一個是data center，一個是rack，一個是host，在云計算或者說在虛擬化的平臺里面有更多的不同的部署方式，如果你考慮很多應用共享的時候，你可能會把這樣的機器虛擬化之后分成多個機器，或者說你的企業里面需要多個Hadoop的結點，但是這多個結點你不知道什么時候這些結點到波峰，什么時候到低谷，你想把他們放在同樣一個比較大的集群里面，但是這些集群可以隨著你應用的需要，可以擴展或者壓縮，根據需求不同，你的部署方式確定也不一樣。

第一種就是最基礎的，就是一個VM，這是跟物理環境沒什么差別，第二個可能會有多個結點，現在手頭里四個，但是你可能做一些測試，其他的工作，可能出來十二個，十六個甚至更多的結點。第三個就是我說到數據的分別。第四個你可能還會有多個data note，來滿意你的需要。這種情況下，昨天的Hadoop就不能滿意你的需求了，現在我們引入了這個node group這一層。現在我們把所有數據相關的部分我們都做了一個處理，加上了這些我們的，Hadoop還是在物理環境中狀態很好，放到云平臺或者虛擬化平臺之中就可以做一個不同的英文。

做一個簡單的介紹，設備這是在副本的放置策略上，2和3落在統一個VM上，現在就不會把兩個放在同一個node上。這個是對于副本挑選的策略的拓展，他會去選統一個英文。

對于均衡器而言，希望副本的放置仍舊是牢靠的，依然要知足之前的這些規矩，還要保證這些副本是完全達到牢靠性要求的，所以我們也設計了很多這方面的邏輯。

對于這個義務的放置也是同樣的情理，我們抉擇，尤其是對于數據和計算分離結點的情況下，這一層顯得更加重要，因為如果在之前的用戶來說，當他發現這個結點沒有被數據node看到的時候，他會認為這個數據是不被認識的，我們的工作讓這個計算更加貼近數據。讓Hadoop的資源更有彈性，包括對Hadoop本身，可能會在今后陸陸續續增加到社區里面。

下面請我的共事給大家介紹一下Serengeti，這是一個獨立的，開源的一個項目。

嘉賓我們的Serengeti是一個完全Opensource的，我們這個項目每三個月會發布一個小的結果。這里可以看到有幾個特點,數據存儲，很方便去部署，很方便去管理Hadoop Project。

我們畸形的物理機上面，直接搬到虛擬機上去運行就好了，沒有什么特殊的地方，所以在虛擬化的平臺上有一個特色，就是VM這些東西非常的機動。這是我們大概一個從Hadoop的運行模式上，可能會做到這么一種模式。

英文。

這里面我們提到擴展性，比如一個很簡單的…，特定的…，我們在一個…里面描寫了我們的…長什么樣子，我們很輕易去…其中一個我們稱為…，比如我們…有五個，我們的…有五個，我可以說我們變成十個，另外五個VMware就是…，然后…到…里面。

比如我們要運行Hadoop我們天然會想到，我們怎么保證關鍵的應用不會對集群有影響。在某一個特定的時候，可以動態的去英文，做到真正的癥結的應用不會被Hadoop占用。

這里其實更多的就是到了英文，主要從三個方面來考慮，幫助我們去部署Hadoop的時候，我們要去…變得非常簡單，包括開始怎么去部署一個新的集群，在運行過程里面怎么…。我們讓Hadoop運行在…上的時候，這邊可以看到確切有很多實際的利益在里面。我們知道在正常Hadoop集群里面，單點故障，我們可以在Vsphere，一旦有問題可以敏捷在另外一個。恰是我們從這三個主要方面能夠來開發我們的產品，我們會嚴密的應用Vsphere的功能，我們會跟它有更嚴密的聯合，來幫助在云里面怎么樣去應用。

這是我們HVE的工作，包括Project Serengeti，如果你有Vsphere的環境，可以直接部署，創建Hadoop的集群，歡迎大家使用。大家如果有針對，針對HVE，或者針對Vsphere。

提問…

嘉賓這是一個很好的問題，我們知道其切實虛擬化環境里面主要包含兩部分工作，一個是把node預備好，另一部分是把Source建起來，在阿帕奇已經在做，我們更多重點在我們的Vsphere這個平臺上去部署集群。

提問…

嘉賓文件以64兆為單位，你有多少個副本。

提問其實我對開源是剛接觸不是很清晰，然而我不知道剛介紹的時候你沒有提到保險性這局部，你是怎么做的？

嘉賓Hadoop引入了一套保險人人系統，這個文件系統有不同的用戶，還是有一些其他的問題，比如英文，比較復雜，尤其是數據中央內部，可能不會去開啟所有認證的工作。

提問既然他是一個開放的東西，是不是表示它里面如果有歹意的軟件，開發者就可以放一些問題的東西在里頭？

嘉賓你提交代碼的時候會有嚴厲的審查程序，尤其是對Hadoop來說，他的數目是很有限的，我們會發現我們中國現在工作在正八時區的還沒有一個，你需要告知所有社區里很多的人，這個是創意是友善的，是給人帶來好處的，不是你任意寫代碼就可以提交的。

提問…

嘉賓Vsphere上面有這個動作做…，我們會讓它去…的功能，我們不知道這個VMware是不是讓它做遷移，剩下的這些資源還是Vsphere起作用的。謝謝大家！

孫振南我今天帶來的標題是CloudStack，今天我帶來的是阿帕奇另外一個Opensource IaaS的CloudStack。我是趨勢科技，同時也是阿帕奇的，推事也推進CloudStack在中國的發展。

今天我主要講兩部分，第一代著大家把CloudStack略微整體說一下，另外我會介紹一下現在CloudStack在中國社區的發展。

在開始之前，在講什么是CloudStack之前，首先我認為有必要把CloudStack整個的情況給大家交代一下。

CloudStack這個東西是在2008年由VMOPS這家公司開發的，它就是開發CloudStack。然后在2010年5月份，VMOPS重新命名CloudStackc769686b2e81f1c70bec1eddef8c，2.0版本也發布了，緊接著去年7月份，這時候產生一件事情，就是思杰把CloudStack收購了，開發了3.0版本，思杰一直開發自己的CloudStack版本，今年4月份，思杰把CloudStack開源募捐給阿帕奇社區。10月份的時候有一件值得記憶的事情，CloudStack以社區的身份發布了自己的第一個版本，就是CloudStack4.0。然后在差未幾半個月前，拉斯維加斯第一次CloudStack大會，在那邊舉行，這是整個的情況。

什么是CloudStack，因為我們今天這個是云世界大會，今天的主題也是開源云，CloudStack是什么？可以說它就是一個云平臺。這邊有一些簡單CloudStack的特點。他支持多租戶，有平滑的伸縮性，當然他也是開源的，現在是阿帕奇的許可CloudStack是低成本資源監控的云平臺，這里頭提兩個，一個是資源，另外一個是云，對于云來說，我們都知道現在有公有云，私有云，混合云，還有其他的像社區云其他的東西。資源無非就是一些物理資源或者是一些虛擬資源，都逃不了CPU、內存以及網絡這些資源。

大家可以看右邊的這個圖，CloudStack是把你的物理資源進行形象虛擬化，并且去管控，他自己自身提供了一個綜合管理的引擎。在上面它有完全的API的系統，再上面就是對外提供一些UI，或者你自己整合你的資源。

我們看一下這三種云，我們平時都在公有云、私有云、混合云，這三種云自己都有自己明顯的特點。我們先看一下公有云，大家都知道的，就是亞馬遜就是典范的公有云，是很勝利的，我們國內也有一些，但是目前來說都是起步的，作為公有云有一些特點需要滿意，他要支持多租戶，要有自服務，要平行的擴展，并且是一種按需付費，你用多少掏多少錢，絕對來說成本需要把持到很低。

我們再看最右邊的這個是私有云，私有云跟公有云有很明顯的差異，簡單說私有云普通是在企業或者是IT自己里面用的，他的資源也是自己專屬的。個別一個公司如果自己的IT要上私有云的話，當然他會有自己專屬的資源，有自己專屬的IT部分，完全隔離的網絡，安全性這些都是需要考慮的。

混合云實際上介于這兩種云之間，混合云最主要的就是像一些企業，把自己的IT托管出來，托管也有一定的要求，最主要的就是可能需要專屬的為企業籌備的服務器，要簽署一定的SOA，到底到達幾個9，這個他會比較重視，這三種云如果自己要看一個云的話，哪種云比較適合，你可以參照這個特色，你自己感到要用哪些方面。這是給大家一個參照。

今天CloudStack我或許會講這些內容，首先這是比擬high level的圖。有多少個數據簡略跟大家交代一下，這個圖最上面寫了一個Zone，可以理解成為數據中央，當然這個不是完全等同的，下面會有一層pods可以懂得成機架這個概念，最下面是集群，CloudStack對集群有必定的請求，他請求集群內部必需是一致的物理機，便利在集群內做一些遷徙，集群這一級應當是邏輯構造里面比擬主要的一級，然后集群下面就是詳細的主機。可以看到集群這一級，還有就是你的主存儲，也是以集群為邊界的，每一個集群實際上是需要共用他的主存儲，如果已經共享存儲的話。Secvondary，在整個資源域是共享的。

這幾種資源都是很容易自在去組合，你可以在上面hypervison，VMWARE也可以用Server，或者Opensource，也可以用SUN，也可以用nfs。右邊是二級存儲，目前來說支持兩個，一個是傳統的nfs，CloudStack是相稱成熟了，它在國外，很多家公司用他，他有很多非常好的一些功能。

我們再來看一下CloudStack最初的設計，CloudStack剛開始并不是憑空出來了，他的設計起源于事實，我們這邊做一個簡單的比較，左邊是一個數據中心的架構，外面是你的門戶，通過三層核心，連到你的WELL，再下面是機架的意思，POD，橫向擴開展來，這是典范的數據中心。我們有一個運營門戶，跟這邊OSS實際上是類比相同的。現在不同的地方在機架這一層又做了一層邏輯劃分，在機架下面，一個機架可以包含多個集群，集群下面才是你的主機，這樣劃分出來以后，一個zone就可以針對數據中心，可以是很大范疇的擴展。還有一點不一樣，那邊的Secondary storyge，他要求盤比較大，CloudStack最初的研發也是認識到這一點，把它對存儲的需求設計成主存儲跟二級存儲。

這個就是更貼近事實的，就是為這個場景設計的，可以在地區性有很大的跨度，一個云環境，可能有些公司好幾個地方都有辦事地點，可以在云環境下部署。比如我在北京有我的數據中心，我會把一個資源域放在這，我的Server都在這里放著，我在有兩個ZONE，在有一個，這是很彈性的地區擴展，CloudStack是完全支持的。

這邊是一些簡單的數據，就是CloudStack目前擴展性到底是什么狀況，我剛才提到management Server，一個管理服務器結點，目前可以支持到一萬個左右的資源，當然這的資源不光是你的物理主機，也包括其他的主存儲，二級存儲，以及你的交流機，這些都是你的資源，它可以一個管理服務器結點可以支持到一萬個，對于大家部署自己私有云是足夠用的，并且有些公有云差未幾沒達到這個規模。

它可以很彈性的拓展，它在管理服務器結點前面，如果訪問量很大，你可以加多臺管理服務器，前面加負載平衡就可以完全做到。如果大家能關注一下的話，在阿帕奇CloudStack這邊有一個測試，大概用四個管理服務器加負載平衡，可以支持三萬個物理的資源，三萬個虛機的規模。當然因為這是一種模仿。目前這塊還有很大的改進空間。比如要完整的scalesout，可能你要解決一些他的POST的機制，通過Scalesout的計算一個管理服務器可以支持到兩萬個resources。

在云的時代，假設任何東西都不可靠，CloudStack在這種可靠性方面到底有哪些自己的特點呢？首先就是CloudStack它有很多主動或者是被動的方式，自動的方式就是，比如我做動態的遷徙，比如我把主機進行人為維護，在可預知的時候，比如我的硬盤破壞了，我的內存需要增長一些，在這種情況下實際上是主動的行動，把系統某一個resources進行維護，還有一個是被動，這種情況下都是不可預知的，大多數都是這種情況，在這種情況下我們需要做哪些事情，就是CloudStack提供了叫HA的機制，高可靠性的機制，你只有把虛機啟動之前讓他用這個服務把HA給勾上，這個主機壞掉了，或者這個虛機Server有問題，可以自動把它接起來。

CloudStack4.0宣布當前加了一個新的功效，有一個主機專門針對HA，畸形上面是空的，假如有些虛機做HA的話，做HA的虛機都會移到這個上面，從自動跟被動方面都供給了對HA方面的支撐。

我們接下來看一下，為了完全性，我會把所有的技術都會提一下。KVM在中國比較火，固然官方沒有說要支持12.0，但實際上也是支持的。

大家可以看一下他們自己分辨的虛機格式都不太一樣，對是否支持超配這種概念可以看一下，像存儲的超配，這并不是說所有的Hypervison對于所有的存儲都支持的。

Storage，一個是主存儲，一個是二級存儲，主存儲對于他的LPS要求都很高，二級存儲就是剛才講的，它是一種一次寫屢次讀的存儲，對于這種來說實際上它的LPS不需要那么高，但是他的存儲容量比較大，模板、SO、快招都需要占用大批的存儲，意識到這個特點，所以CloudStack把存儲分成了這兩種不同的情況，有不同的用處。

下面簡單介紹一下Network，我把CloudStack支持的兩種資源域簡單提一下，第一種就是基本網絡，基本網絡可以以為在CloudStack的根本資源域，建立一個基礎資源域的時候用的這種網絡。兩種不同色彩是指兩個不同用戶或者兩個不同帳戶下面的用戶虛機，他們自己調配自己的IP，通過網絡里的三層交流進行互聯互通，或者設置一些規矩。前面加一個防火墻，通過平安組的方式進行隔離的，這種是比較簡單的。

還有一種是高等資源域里，這就比較復雜了，這里對于虛擬路由器，每個帳戶都有自己單獨虛擬路由器，它負責很多的網絡功能，它的隔離是二層的隔離，也就是基于VLAN進行隔離。兩個不同的客戶，它的虛擬機，他的IP都是可以反復的，這是它的高等網絡。這是整個的，這里面有很多種不同的角色，不同的權限，最終用戶可能權限小一點，另外也支持EC2的API，在4.0里面，3.0也支持，但4.0里面更進一步了。我們跟管理服務器下面用的是My SQL你可以自己加這個My SQL的集群，對于Oracle的話是用…，沒有開源之前，這些客戶都不是開源的，現在這部分客戶都是開源的，并且希望更多的廠家進來，把自己支持的設備增添進來。下面就是一些它的系統虛擬機。

因為我現在主要在中國推進CloudStack中國社區，我下面花點時間給大家介紹一下阿帕奇CloudStack這個社區，以及現在在中國的狀態，跟大家分享一下。

首先阿帕奇CloudStack，現在仍是一個孵化器的項目，它不是一個正式的項目，一旦成為正式項目，一定能成為TOP1。他里頭有四種角色，你怎么參加到這個阿帕奇CloudStack社區，可以以四種身份加進來，可以作為用戶，可以是一個英文，或者…進來，作為用戶的話，你是應用可以提一些應用倡議，都算是對社區做貢獻，如果是做一個開發者不是狹義的寫代碼，你在上面贊助答復問題，輔助做一些文檔工作，這些事件都是做奉獻。

你要是想成為committer首先必須去做貢獻，讓大家看到你在這上面有自己的貢獻才行。另外一個是叫mentor，這個角色對阿帕奇整個流程是非常了解的，可以帶到這個項目上面，盡快的按照阿帕奇的流程來做事情。如果大家想知道這個項目，有一些門路，第一個就是阿帕奇的網站，有一些東西在里面，大家可以看。

這個就是阿帕奇的Mailing Lists，這里我想強調的是這個郵件組，像CloudStack這邊對中國還是蠻器重的，有專門的郵件組在這里，大家可以訂閱一下，現在在里面討論也長短常熱鬧的。很多人用CloudStack提問題，在上面提的總能很快被解決，郵件組是個好東西。

下面看一下CloudStack在中國社區的發展過程，這邊我提的就是我們最近的線下活動，從今年5月份到現在，包括我們下周要去進行一次沙龍活動，我們規模每次也不大，5080人，大多數來的人都是開發者或者USER。上面是一些資源，下面是我們中國區的用戶對CloudStack做的一些貢獻。首先我們這邊有一些committer在里面，負責文檔，會做committer會做一些翻譯，翻譯是中國區的用戶在做。

下面有幾頁很快給大家過一下，就是INDEX，這是我們CloudStack網站訪問的情況，我們用谷歌簡單剖析一下，當然我們是以技巧文章為主，然后會發一些運動的信息，技巧文章現在沒有多少，大概四五十篇，現在也帶來了一些正面的反饋，我們可以簡單看一下，目前集中在北京、等處所拜訪人數比較集中，我們前面提到，我們做的沙龍運動，目前主要集中在北京、。

這是我們的考察問卷收集上來的情況，對于CloudStack來說目前還是屬于比較新的階段，各個方面大家都想去了解，市場的裝置部署，開發，系統運維方面占的比例差不多，大家都想了解。

這是大家用的虛擬化平臺，或者叫虛擬化軟件的一些狀態，前三甲基本上就是VMware、Server，跟KM。現在材料比較疏散，可能需要更好的唱工作。我們激勵更多人加入這個社區，實現雙贏。我們現在接下來還是會做CloudStack相干的一些分享，不論是技術方面，還是安排，錄一些VIDEO都是很歡送的，我們現在著手做一個演示的工作，大家可以上去玩一下,虛擬桌面，當然需要一定的資源和時間。現在CloudStack也需要更多的VENDOR加入進來。

提問有人說CloudStack適合中小型的部署，而Openstack適合比較大型的部署結構，你對這個有什么評估嗎？

嘉賓舉個簡單的例子，Openstack我跟他們有過交換，他們目前最大的部署范圍，應該是…有數千臺的規模，但現在CloudStack目前范圍有四萬臺，這個基本不是問題，CloudStack是合適你做公有云，也合適做私有云，在海內可能私有云會占絕大多數。CloudStack自己自身它現在成熟度跟它的擴展性足以支持現在我們遇到的云平臺。

提問CloudStack是用JAVA云開發的嗎？

嘉賓對，主要就是JAVA。

發問有付費版和免費版嗎？

嘉賓你可以完全用阿帕奇CloudStack版本，不用考慮任何付費，因為阿帕奇LI…決議了，你不需要出任何用度可以拿下來部署，你碰到問題去反饋只能是通過社區渠道，但是你可以用其他基于阿帕奇CloudStack，有很多商業公司有自己的版本，你要是想后續的支持就要找詳細的基于CloudStack開發的商業版本去做。

提問它對Web…支持的配置方面，如果只是修正文件參數可以實現嗎？

嘉賓因為今天沒有帶來那個演示，如果要支持VM集群的，你必須建一個數據中央，下面再有…，這個數據核心的名字，以及你的用戶名密碼組合起來，可以把這些信息提供應CloudStack，整個在CloudStack管理平臺上面體現出來，很便利的。

提問CloudStack，實際上它支持的硬件，還有剛才講的數據庫，DATA…有什么制約。

嘉賓這邊的限度主要體現在hypervison，你想看看這個硬件是不是支持你就要翻開…Server他們的硬件兼容列表去看一下，hypervison只能在哪幾個平臺上做測試，My SQL也可以用，詳細怎么用，是數據庫方面的事情。

發問當初好比說Oracle，My SQL可以嗎？

嘉賓這個貨色現在需求沒有那么顯明，現在我們只是支持My SQL，由于它就是傳統的是可以實現的，要支撐其余的數據庫也是很輕易的，只是現在My SQL不論從效力以及穩固性都足夠，并且My SQL，沒有默認在這個里面，需要本人獨自去實現。

我今天講了這么多，所有的代碼都是在阿帕奇CloudStack容許的情況下。現在VMware不是阿帕奇的許可，如果你這邊要用的話得你自己加進去。

提問有一塊存儲嗎？

嘉賓他的主存儲或者二級存儲支持不支持…，他下面用的LVM都是…的支持，實際上是這個存儲本身支不支持這種協定或者怎么樣。

提問…

嘉賓你提到的是它里面的幾個系統虛擬機，幾個系統虛擬機，目前有一些是有點問題了，比如說它的虛擬路由器，用的過程中，發明它無奈進行關機相似的操作，現在社區里面有一種聲音探討，接下來可能會考慮centerOS，依附于一個是OS，另外一個是安排給你整個的硬件環境，實際上是你的整個架構和網絡環境上的問題。

提問現在比如我的APServer跟我的數據中央要離開，有一個在北京，有一個在，APServer在北京，數據中心在，有這樣的部署嗎？

嘉賓因為你們要斟酌…是不是足夠，個別情形下，異地的這種情形都是以ZONE為邊界。

提問中國現在有哪些支持開源的版本，還有哪些商業公司支持這種商業版？

嘉賓開源的這個版本大家是都能用，但是商業版本…，昨天那個會也發布了5.0的版本，解決了穩固性。在國內主要虛擬VDI的這個方案。

提問CloudStack有什么毛病或者技術難點？沒有解決的問題能不能說一下。

嘉賓目前來講CloudStack在幾個云平臺上算是比較成熟的，有一些社區里去看有兩百多個過錯要解決，如果你其他模塊要支持的話，最大問題就是允許的兼容性，有的時候還不能滿意，這是開發實際過程中的一些問題。詳細你說它目前實際上使用的過程中，CloudStack也好，可能商用的時候，直接用CloudStack版本，你得到的技術支持沒有那么強。但碰到問題你可能很難解決，你可能要追求一些貿易版本的支持。

提問各個模塊有沒有什么缺點，比如剛才網絡模塊，存儲模塊？

嘉賓現在比較大的問題在4.1里可能會做，因為現在CloudStack它的模式是一種緊偶合的模式，每一層之間都是緊巧合，對于已經熟習的人開發是很容易的，但是對于新的人進來開發沒有那么容易，4.0已經發布了，4.1的時候會做比較大的動作，會把他的緊偶合拆一下，可能各個模塊之間會更加的API化，模塊化去操作，很方便，要加一個模塊會更加方便。

提問現在市場上的各種模塊之間是比較緊巧合的。

嘉賓對，偶合還是比較高的。

余慶大家下戰書好，大家還保持到現在辛勞了。我來自阿里巴巴，我現在做的工作也是阿帕奇的開源項目，叫xen Server，就是一個類似于英文，從它的性能上來講，包含價錢上來講，應當比S…更進步一些，性能這方面會比S…更好一些。

今天下晝的主題，主要都是云計算，和云平臺，接下來我給大家介紹這塊，可以往云存儲這塊去靠，但是其實我這個可能沒這么大，和云存儲應該沾邊。感謝組委會，感謝陳先生給我這樣一個機遇，跟大家一起做交流和分享。

DFS是我們做的一個開源的散布式文件系統，是業余時光做的，其實這個開源系統，當初還不是阿帕奇的開源名目，想爭奪，后面讓它成為一個阿帕奇的開源名目。簡略先容一下DFS是什么，它是一款開源的，輕量級的散布式文件系統，其實這個文件系統不是特殊精深，不是通用的文件系統，是一個專有的文件系統，是相似于谷歌FS的文件系統，已經提供了C，JAVA和PHPAPI的這些都有。

說他是類谷歌FS，其實照搬FS，FS的定位主要仍是針對分布式盤算來做的，我這個DFS定位主要是為互聯網應用來定制的。其實就是大家看到的最后一條，DFS是為互聯網應用量身訂作，重要是解決大容量存儲的問題，尋求高機能和高擴大性。UNIX系統都是支持的。

DFS不是通用文件系統，把它看成是一個基于文件系統的Key value pair系統更適合，更貼切一些。大家有一個印象，他是一個類似于谷歌的DFS系統，他提供的API很簡單就是upload，download，APPENDER文件，還有就是SLAVE文件，一般的文件上傳之后是不能修改的，只能刪除，APP…文件才可以做修改操作。

SLAVE文件重要是針對這種應用處景，有一個主文件，有多個重文件場景的設計，舉個例子，比方說像用戶的頭像，上傳的原圖可以叫主文件，互聯網應用里面會做縮略圖，可能有多個，而后實在都是從原文上轉換過來的，縮略圖就叫重文件，在文件的ID上面有接洽，然后別的就不接洽了。

最后一個是文件附加屬性，后面不太提議用了，提一下就好了，文件附加屬性比如像的寬度、高度，有什么作者之類的屬性，DFS是支持的，他把這些文件的屬性再單個保留的做法，其實這個不太推舉用，就存在KV系統里面，甚至存在存儲里面就好了，不用用DFS的特性。

DFS是從08年開始做的，做這個項目，當時我還在中國雅虎，做這個項目其實是受公司項目的啟示，做了這個項目，當時雅虎的相冊，存儲方案是用確當時雅虎有一套系統，這個系統是基于集中式的存儲設備，當時一臺設備差不多二百G的樣子，容量很高，但是相應的成本也很高，一個是成本高，另外一個，擴容話就要加200T，這個平臺的成本太高了，雅虎自己做一個分布式文件系統。DFS的架構從第一個版本定下來之后，后面就沒有變過，整體的架構都是基于最早的設計來做的。

我們再看一下這幾個大的版本之間，他們的特點，V1的版本，其實就是因為最早我會比較傳統的，一個懇求，一個線程的服務模式，支持的并發銜接是有限的。像這種模型普通能支持的銜接數是1K左右。

V2對V1做了改良，采取libevent庫，磁盤讀寫這塊也是專門的線程，工作模式比V1更進步和高效，這個模型支持連接數可以達到10K，很輕松的。

V3其實就是一個特征，能夠把很多小文件合并存儲在一個大文件里面去，其實主要就是解決海量小文件的存儲問題，因為錯誤小文件存儲做優化的話，檢索會非常慢的。

V410月份發布，V4的特征并不是太多，他就是很簡單的一條，支持自定義的storage Server ID。如果你的Server ID地址改了之后，可能會引起你集群狀況上做一些調劑之類的，固然以前也做了一些工作，支持你的ID改了之后能夠自動調劑，但是這個功能不是特別穩定，你個集群里面同時改ID的時候，可能會涌現一些凌亂的情況。

記下來我們看一下DFS的架構，實在DFS只有兩個角色，大家可以看一下，右邊是存儲服務器，右上面是核心服務器，相稱于整個集群的中心，整個集群的腦筋。文件存儲是存儲在旁邊這塊的，我是列出來一列一列的，一列是一個組，文件在一個組里面是冗余的，完整是RADI1，完整是鏡像的關聯，然后每個組的文件不會重疊的，文件上傳上來只能放在一個組里面，如果這個組里面有三個服務器，這個文件就會被復制三份。這個圖大略有是這樣。

DFS集群里面的所有服務器都是平等關系，存儲服務器是分組的方式，不同組的存儲服務器之間他們是完全獨立的，不會有任何聯系，不會有任何的通訊。再看一下這個圖，剛才講了這個右上面這個圖集群的樞紐，他怎么知道這些集群的狀況，是由這個存儲服務器主要向它匯報的。

接下來我們看一下DFS上傳文件和下載文件是什么樣的流程，其實懂得了這個流程可能對DFS工作機制可能就明白了一大半。

我們看一下上傳文件的流程，首先client會問tracker，我要上傳一個文件我這個文件應該上傳到哪去。下載這個文件是client去問tracker，可以下載指定文件的storage，參數為文件ID。

接下來我們看一下DFS的特點，大家可以看到，DFS是不需要傳統的name Server的，把這個瓶頸給打消了，因為他沒有這個角色。另外它的存儲時候是用分組的方式，這個方式比較簡單，也比較機動。比如說要下載文件就以通過火組的方式。存儲服務器都是對等結構的，不存在單點的問題。我們下載文件的時候，可以和目前主流的Web Server聯合起來用，我們對阿帕奇提供了拓展模塊，也可以在存儲服務器上面直接部署阿帕奇或者部署UNIX，再把擴展模塊裝上去，可以直接支持下載了。另外對中小型文件可以支持得很好，大文件也是可以支持的，但對大文件沒有做特別支持，就是DFS是出于簡單的考慮，它對大文件，目前沒有做分塊這種做法，從V3開始，可以對海量小文件很好的支持，支持多塊磁盤，其實是倡議，為了使你的系統達到更好的效率，其實是推舉你的存儲服務器直接掛單盤，不要做RADI了，這個文件系統保證你數據的可靠性，其實你是沒有必要做硬件RADI的，是比較揮霍的。最后一個特點就是支持雷同文件內容只保留一份，節儉空間。

方才講到DFS不name Server，不須要存儲文件索引，傳統都是必需要用name Server，為什么DFS不須要這個索引服務器，方才我講的進程中已經說到了，DFS里面的文件ID，是由存儲服務器天生，并且反饋給client的，client直接存在本人的體系里面就好了。文件ID包括了組名，還包括了文件名，能夠直接依據該文件名定位到這個體系里面的文件。

下面一個文件ID的示例，最前面是組名，由管理員自己定義的，后面第二部分是磁盤，因為DFS支持多磁盤，第二部分就是磁盤的表示，就是M后面帶一個磁盤的序號，M00就表示第一塊磁盤，M01就表示第二塊磁盤。00和0C就對應文件系統里面的存儲目錄，DFS的文件是直接存在文件系統里面的，然后它在文件系統里面是建了一個兩級目錄來存儲的，最多就是250M，其實這個目錄數足夠了。最后一部分就是文件名，大家可以看到，比較長，文件名里面其實還包含了一些信息，在這里不具體講了。

再講一下，V3你的小文件是合并存儲的，你怎么定位到這個小文件，大家可以看一下，我們在本來的ID基本上又增添了三個字段，總共16個字節，每個字段都是4字節的，它會有一個，我這個文件是存在哪個窗口文件里的，然后我們的窗口文件以IE號作為文件名的，它在這個小文件的ID里面就會記載我存的這個trunk file的ID，根據文件偏移量，直接定位到小文件起始的地位，還有我占用多大空間。

DFS同步機制也講一下，DFS是同步，和買裝備的同步其實有類似的處所，都是采取binlog的做法，就是更新操作，上傳操作，然后同步的時候直接根據binlog來做。有一點要注意的，binlog里面只記載這個文件名和操作的類型，不會實際記載文件內容，因為實際文件內容已經存儲到系統里面去了。同步的時候是用增量的方式，我同步的地位，我會記載在一個標識文件里。剛才也說到，我的一個組里面，存儲服務器是平等的，然后文件上傳、刪除、下載這些操作可以在這個組里面任何一臺服務器上去做。還有一點就是這個文件同步，是先上傳到一臺存儲服務器上面去，然后再由這臺服務器把這個文件同步到這個組的其他服務器上面去，他是先上傳上去，上傳停止了再用IF的方式同步從前。

文件同步只在本組內進行，因為他是族內storageServer之間進行，然后是push的方式，即源頭服務器同步給目的服務器。

下面就會引入一個問題，因為我的文件是上傳完之后，我才去做同步的，有一個問題就是我的同步延遲的問題怎么解決。大家如果做過應用開發的話就會遇到一個問題，就是同步延遲的問題，比如你更新一些記錄，或者你查一些記錄之后，你立刻就去訪問這個記錄，如果你立刻去訪問到storage的話，可能數據還沒有同步過來，會導致記錄取不到，也可能導致收到臟數據，我們以前解決同步延遲的問題，我們就用了一個很土，很簡單的做法，我做完操作之后我加一個sdf。

存儲器生成的文件名里面，其實包含了好幾個比較重要的字段，其中最重要的兩個字段一個就是源storageID地址，或者從V4開始它的ID，還有另外一個字段就是文件的創建時間。根據文件名可以把這這些字段翻譯出來，另外一點存儲服務器會定時向storage Server講演同步的情況，包括向目標服務器同步到文件的時間戳，tracker收到報告之后就會做一個計算，因為每個存儲器都向他定時的呈文，然后他收到這個呈文之后就會計算，這個組里面每一臺存儲服務器被同步時間戳的最小值。它會找這個最小值，把它給記錄下來。

tracker Server怎么知道我這個服務器上面一定能獲得這個文件，有四個條件，第一個條件我們會設置一個同步的延遲閥值，當前時間，文件創立時間戳，如果大于同步實現一個文件所需要的最大時間的話，表現這個文件肯定通不外去，這個文件肯定是延遲的。

第二個條件如果文件創立時間戳，比被同步的時間戳小的話，是表現這個文件已經同步到當前存儲服務器上去了。

第三個前提，單個文件的同步需要最大時間是多少，比如5分鐘我就會比一下這個時間戳，是不是已經大于同步的最大時間，如果大于這個時間同步不外去了。

第四個條件文件上傳到源頭storage，只要知足一條就可以下載到這個問題的。

下載文件的時候，我通過比較兩個時間戳，就知道你這個文件是不是可以下載。

最后我們看一下DFS使用的現狀。目前已經知道在用的公司有二十多家，用的最大的一家是做網站的公司，他們存儲group數量有四百個，它的存儲的機器數已經超過800臺了，存儲容量達到6PB，存儲文件數超過1億，它的網站業務增加很快，數目增加也很快。我2010年的PPT里面寫的時候，group數和容量還是現在的一半，前幾天問它，它現在已經又翻一倍了，也就一年多的時間。

我們再看一下DFS的使用案例，支付寶、飛信、京東、58同城、趕集網之類的，其實主要還是互聯網的公司，包括有支付行業的，有做電子商務行業的，也包括搜尋這個行業的。我的介紹就到這，下面是一些網址，大家感興趣的話可以去看一下，包括DFS的論壇，上面有一些提問的解答，這是我的微博，大家感興致的話可以關注一下，另外還有QQ群。也生機大家能夠參與到這個項目里面來，不管你是用還是貢獻代碼，反正能介入進來就是很開心的一件事情。謝謝大家！

提問…

余慶其實DFS就是一個分布式的非常成熟的一個系統，然后它的特點，其實前面講到了，第一點就是他只有兩個角色，沒有傳統的name Server，不需要承當文件索引，這是很大的亮點和特點。

目前DFS的做法比較簡單，像文件的一致性這塊，做的是弱一致性，不是強一致性，如果要做強一致性的話，你要付出的代價會很高。比如你要做強一致性，有一個做法，我要保障一個文件起碼存三份，我于是把這個文件三份都傳上去，這樣應用真個響應時間會很長，并且應用端會很難做，萬一我只有兩臺機器可以用，那這個時候你怎么處理，很麻煩的。如果弱一致性的話就好一些，只有有一臺機器是活著的，就可以上傳上去，等別的機器恢復之后再同步給它就好了。

比如我只有兩臺機器，上傳了幾個文件，第一臺服務器上去了，還沒有來得及同步到第二臺服務器的時候，這臺機器掛了，目前DFS架構的特點，無奈恢復的話，這幾個文件可能就喪失了，強一致性的代價會大很多。

提問…

余慶這個tracker Server把兩臺機器的IP地址和端口配上去就好了。

提問…

余慶比如你要是動態的再加機器，目前的做法就是你要動態加tracker Server，你的存儲服務器要重啟，以后在線加了之后就能自動生效之類的就更好了。tracker Server你要裁減的話，這種情況很少。

主持人謝謝余慶，我們希望這個項目成為阿帕奇的項目，因為時間關系，晚上還有活動，所以我們邀請最后一位報告人。

孫振南向堅持到現在的各位表示感謝，我會講得非常快，如果大家有什么問題可以結束以后再聊。

今天跟大家介紹一下最近比較火的項目，叫inpala，因為今天是大數據，云開源，in現在還不是阿帕奇的項目，然而他用的阿帕奇的允許。

第一個問題它為什么，它比較適合復雜的運算，但是它在自己啟動的過程當中，它都有很多問題，也不是問題，比較慢，不適合在這樣的場景下使用，大家也都習慣了，也沒有認為這樣有什么不好，可是最近一些需求，它的響應時間，針對海量數據慢了一點。還有一個問題就是它的接口，Hive提供了接口，可以進行海量數據的查詢。

今天這個inpala完全在功能上跟Hive非常靠近的。講到速度的話，還有一個為什么不能用HBase，他很快，只是你的數據進去這個步驟會花很長時間，我這邊寫的，你有可能有ETL，你有可能沒有ETL，無論怎么你要導數據都會花很長的時光。

我們看一下在大數據處理范疇當先的人，首先看谷歌，谷歌在實時處理海量數據上面有一些貢獻。后面是兩個是技術上的亮點。他用的列存儲，谷歌做得比較厲害的是，基于可現套的數據構造做的列存儲，根據這樣的數據格式做列存儲其實是有一些技能的，在他的論文里面講得比較清晰，這就是他的技術背景和他達到的后果，大家也都很愛慕。

另外還有一家叫亞馬遜，前兩天拉斯維加斯，他們的會議上也先容了他們的Redshift，他沒有公然一些細節，我們曉得就可以了，沒有什么可以學習的。他是依照主機收費的，你付費就很貴，而且你只能用到你的機器，不能用多別人的機器，這個跟谷歌的服務理念不一樣，所以我個人不太看好亞馬遜這個貨色。

我們看一下有了這些論文或者一些當先者的做法，開源界有了什么東西，第一個就是阿帕奇Drill，現在有很多自愿者開端討論這個東西，它沒有任何的本質的進展，現在我們介紹另外兩個，一個是Drill，今年大概十月份比較火起來的，但是到十一月份漸漸冷下來了，。還有一個就是Shark和Spark，它也是這個范疇的新星。最后一個就是我們今天要介紹的inpala。

我們回過火來看，這樣的東西，在整個大數據處理的生態環境里面它的定位到底是什么？第一他其實只是一個衡量，新的像inpala比較重視義務反饋的速度，響應，但它只能做一些簡單的事情，特定的一些查詢。跟傳統的分布式的MPP的數據庫比擬，它也有些長處，它的做法向與上面用了MPP的思路，一些接口，下面我不再用MPP昂貴存儲硬件，或者網絡設備，我就把它換成了鏈家的HDMS，首先他非常的廉價，還有就是他可以提供線性的擴展。這是它在整個大數據處理的環境當中的定位，如果你進行簡單查詢的話它可以很大水平上幫到你。

我們看一下它到底做些什么，它的功能其實很簡單，就是跟Hive做的事情瀕臨的，同時他也有一定水平上的數據天生的能力，Hive不僅是數據查問，他可以做大數據的轉換。所有除此之外的東西，它都是沿用了Hive現有的方法，或者沿用了Hive的組件，他沒有用metadata，他是直接到Hive里面把那些表讀出來，就得到這些信息，同時他需要用Hive的DDL，就是定義語言，同時他的JDBC和ODBC都完全用Hive的，驅動都不必重裝，他已經盡量跟Hive做到了兼容。這邊相稱于以前一個Hive可能要一跑晚上，第二天才干看到成果的，一個中午就跑完了，這是最有價值的一點。

我們舉一個簡單的例子讓大家看一下這個是怎么用的。首先還是要用一下Hive，可以建一張表，你還是要用Hive把數據導進去，完了以后你就可以用impala，可以看到你剛剛用Hive建的表，可以做查詢。這是一個非常簡單的例子，就像大家說的，怎么把它跑起來。

這一頁我們看一下整個inpala的架構，首先inpala是一個沒有瑪斯特概念的。inpala必定要數據本地化。我用紅線畫的，每一個inpala都會被設計的動作，紅線就是每個都要做的。

我們看一下它怎么把這個速度提上去，這是它比較牛的地方。這邊介紹兩個概念，一個SQL其實可以分解成為很多執行的小的單元，大家如果用過一些傳統數據庫的東西都知道，都會給出一個執行的數，其實就是那個東西，里面有一個深度優先的數，下面執行完了執行上一層，每一個結點有數據讀取、排序等等。

這一頁包含了若干個結點可以獨自履行最小履行的單元。舉個例子，我們想查問一下是不是獨身未婚的男青年比較不愛好用打折券。左邊是商品數據，右邊是客戶數據，旁邊是ID連接起來。我們SQL依照城市選出來，包括商品名字，包括標價，標價和它的實際銷售的價錢，男性，獨身，東西比較貴，在北上廣。我們看一下剛那個SQL可以分解成這樣子，最開端還是要去讀數據，讀完數據以后再做Join，這樣子看挺直觀的，數據庫也都能做，在我們分布式的環境下，我們怎么把它加快，怎么把它變得可以分布，把Aggregation分步做。

fragment需要負責讀取一張表，同時讀取的時候按照跟這張表相干的前提進行篩選，這三個在這一步是一相關的，而且數據也是分布的，這一步是完全可以分布來做的，下一步我們把數據小的表傳給數據多的表，比如這個表的數據比較大，我們就應該把商品數據的找出來的結果傳給所有有銷售數據的結點，傳過來以后就不需要再找一臺結點做Join。這個fragment為什么包含了兩個Join，起因是因為如果你作為兩個fragment的話，在運行的時候，無論是線程也好，還是什么也好，一定還有本機的數據傳輸，這就是最公道的調配方式，這就是盡量快去執行的基本原理。

這邊比較頭疼的地方，這兩個的結果都需要傳遞到這臺有數據的結點上，對帶寬要求比較高，所以我用了比較粗的紅線，如果N臺機器銷售數據，M臺機器上有商品數據，這是一個M×N的關系。

除此之外，在性能優化上做了很多事情，大概是四個，第一個完全用C++寫的，fragment在實際散發執行的時候會在本地做編譯。他會繞過HDFS協定。

接下來它有哪些事情要做呢，首先他沒有BDL，他需要完全借助Hive，第二個他沒有Defined Function，第三個他沒有FT，如果這個Join在中間掛掉以后，他提議重跑。然后就是文件類型的支持，Avro，RCFile，LZO等等。inpala和Trevni，性能會提升很多。如果這兩個加在一起，性能上比谷歌論文里面那個不會差太多，開源輕微走帶谷歌前面一點點。

他現在的Join，我們講的數據傳來傳去，最后做合并的時候全體在內存里面做的，這個很有問題，數據大了，很有可能會爆掉，正在做改進。已經可能會寫進磁盤等等。

我們做了一些測試，我們測試用的是速度交易委員會，一些數據也很龐雜，這是測試用的機器，用來做inpala三臺機器，總共只有四塊硬盤。這是我們測試的成果。

下面兩頁沒空講了，這是他內部的架構，這邊我只講半分鐘，BE他里面有一些fragment。

如果有問題的話線下再聊，我新浪微博是這個。

主持人非常感激各位今天保持到現在，也非常愉快大家一起來加入這個阿帕奇亞洲巡講的活動，晚上我們在對面的三樓有活動，如果有興致大家可以去對面C座三樓。我們的活動到此結束，謝謝各位！