从SDF发展看百度的基础架构技术之路

最近，百度基础架构部高级架构师欧阳剑在“中国计算机学会通讯”期刊中发表了题为“百度基础架构技术发展之路”的问题，从“ASPLOS 2014 SDF论文”、“为什么要发表论文”、“混合研究发展之路“、 “基础结构技术”等四个方面详细阐述了百度近几年在基础架构方面的心得。

据欧阳剑介绍，软件定义闪存 (Software- Defined Flash, SDF),最早是由百度公司前首席架构师林仕鼎在2011年初提出来的。当时百度正在做新一代的存储系统,考虑到传统的固态硬盘 (solid state disk, SSD) 在性能和成本方面的诸多缺陷, 如带宽利用率低、空间利用率低 及性能的不可预测等,需要面向 数据计算中心重新设计SSD。于是,我们开始研制SDF。SDF是一个软硬件协同系统,完全颠覆了SSD的性能。SDF有如下几个特点:

• 底层Flash通道用户态的软件是可见的,让软件来管理数据的布局 (layout),使得硬件的并行性能得到充分发挥。
• 基于层次到竖井的设计理念,实现了扁平的新文件系统和IO stack,提高了可扩展性并降低了延时。
• 与存储系统相结合,读写块的大小尽量与硬件友好。
• 资源全局利用,取消硬件通道间的异或校验,存储系统的三副本本身能保证数据的可靠性。

正如欧阳剑所说，做工程和做研究其实是两条并行的道路,并没有太多的交集。一个感性的想法离发表论文可能不太远,但离实际的规模应用还有十万八千里。两者对做事情的方法要求也很不同,一个公司如果要想把这两者结合在一起,并且出成果,除了需要工程师的不懈努力外,还需要一套可行的研究及工程研发体系作保障。比如：

第一批20台,第二批100台,第三批500台,每次上线都要运行很长一段时间后下一批才会再上线。前 三批稳定运行半年多,一直都非常顺利。可是真的没有问题了吗?我们有些庆幸、甚至有些怀疑,当我们以为这个项目将要顺利完成的时候,问题终于在第四批1000多台的上线中暴露出来。因为在进行硬件设计时的经验不足,对现场可编程门阵列 (FPGA) 的输入/输出 (I/O)没有做足够的约束,导致在数据量大的时候会出现数据不可靠的问题,直接影响了线上的使用。最初我们以为是硬件逻辑问题,一直没办法定位,那段时间我们承受着巨大的压力。如果放弃,不仅仅是一年多的努力前功尽弃,还会给公 司带来巨大的经济损失,例如硬件采购成本。经过两三个月的艰难调试,在无数次尝试之后,发现有可能是I/O约束问题,在修改约束之后,数据的可靠性大大 提高,使得第四批产品也顺利上线,并且性能数据非常好。

对于“百度为什么要发表论文”这个问题，欧阳剑表示，主要目的是建立技术品牌,扩大技术影响力,从而吸引更多优秀人才加盟百度。另一个原因是通过公开自己的技术,回馈社会。

互联网公司拥有大数据和大系统,具有做系统技术研究得天独厚的优势。以百度为例, 有超过1000PB的数据、单个分布式计算集群过万台的服务器。 互联网公司的另一个优势就是有很多真实的问题、挑战和需求, 这些都是与互联网用户直接相关的,基于这些问题、挑战和需求来做研究,成果也会直接反馈到用户体验上,更容易引起大家的兴趣,也更容易让人理解。

文中特别提到了“百度的混合研究发展思路”，比如，百度的基础架构部门到目前为止还没有纯粹的研究人员,工作人员的研究工作都是穿插在日常的工程项目中。这些研究工作的唯一目标就是用更大胆、更超前的想法来把系统或者产品做得更好,这些研究最终都是要应用到实际的系统或者产品中。

无论是SDF、 ARM,还是我们现在正在做的一些工作,都是世界范围内的先例。我们做SDF的时候,需要重新设计软件和硬件,硬件的架构和软硬件之间的接口都与传统的SSD不同,而且我们的用户又是非常关键的“网页库”,可以有很多理由让这个项目不能落地, 例如“新产品不稳定”,“新的架构没经过验证”等等。而且刚开始的时候,SDF确实出现了不稳定的情况。如果一开始我们就被困难吓倒,或者找借口不愿意承担风险,大家就不会看到今天SDF的成果。ARM项目也一样, 2011年初百度开始做ARM 服务器的时候,遇到了很多困难,例如CPU是32位的、大量代码要移植、产业链不成熟、没有参考经验等等。而且业务方是百度云, 承载了一亿多的用户,绝对不能出问题。三年后,百度的ARM服务器已经大规模应用。前不久笔者与脸谱公司数据中心的工程师聊天时了解到,他们在2011年的时候也评估过ARM服务器,但发现CPU是32位的,需要移植大量的代码,最终就放弃了。事实上,从x86-64到ARM-32的移植并没有想象中的那么复杂。百度只靠一个工程师,花了不到半年时间就完成了一百多万行代码的基础库和存储系统的移植和测试。

欧阳剑提到了“全栈式(full stack,从硬件到软件)自主开发”在百度基础技术的盛行：这和国内其他公司喜欢完全使用开源方案形成鲜明的对比。这样设计主要出于几个考虑:

• 首先,百度业务发展很快,基础架构必须能跟上并推动业务发展,开源社区方案往往没办法做到这么快的迭代,例如百度的MapReduce可扩展性优化比开源方案早了两年。
• 其次,如果只在开源方案上修修补补, 时间长了,容易丧失做大系统的能力,毕竟维护一个开源系统并做故障修复 (bug fix) 所需要的工程团队和工程能力,和从头开发一个大系统所要求的能力是不同的。
• 第三,全栈式自主研发能真正做到软硬件协同,从而真正达到系统最优,而开源方案一般只关注某一个领域或系统里面的某一个层次,很难做到系统最优。最明显的是,百度有基于ARM和SDF的存储系统,能做到单位存储成本最低或者单位吞吐成本最优。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。