主持人：欢迎各位还继续留在我们今天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重新命名CloudStack.com，2.0版本也发布了，紧接着去年7月份，这时候发生一件事情，就是思杰把CloudStack.com收购了，开发了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月份到现在，包括我们下周要去上海进行一次沙龙活动，我们规模每次也不大，50-80人，大多数来的人都是开发者或者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座三楼。我们的活动到此结束，谢谢各位！
（结束）