主持人欢迎各位还继承留在我们今天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座三楼。我们的活动到此结束，谢谢各位！