【51CTO独家专访】目前，Facebook在全球已经有5亿用户。用户们更新状态、发站内信、聊天、玩游戏，积累了巨量的数据。单单用户的基数就是Facebook的工程师们面临的大挑战。这样一个数据库应该怎样设计、部署和维护？Facebook放弃MySQL和Cassandra而采用了HBase是为了什么？在2011年QCon大会北京会场上，51CTO编辑对Facebook信息服务团队存储工程师Nicolas Spiegelberg进行了专访，就Facebook的业务需求、数据库迁移的实现和难点、大规模集群的监控、以及产品的技术选型方面进行了探讨。
左为Facebook信息服务团队存储工程师Nicolas Spiegelberg，右为51CTO编辑
51CTO：首先，能否谈谈你加入Facebook之前的工作？
Nicolas：我在2009年下半年的时候加入的Facebook，到现在也一年半多了。那个时候我加入了HBase项目——这个项目当时刚刚开始。我们做了很多早期的工作，包括编写启动脚本。
在这之前，我是一位嵌入式C++开发者，针对ADTRAN设备写代码（ADTRAN算是思科的一个竞争者）。嵌入式开发我做了5年，主要是网络层的技术：TCP/IP，PPP，SPF等等。有一点很有趣的是，我们HBase开发者当中，可能有一半都是以前做过嵌入式开发的。
51CTO：是因为嵌入式开发和HBase有什么相通的地方吗？
Nicolas：两者之间的共同之处在于有大量的通信层下的传输，有分布式环境，做协议，减少网络延时等。那时候做很多这方面的工作，只是不太需要优化自己的代码。
51CTO：那么在Facebook中，你负责了HBase的设计和部署，从MySQL的迁移。这之前是怎样一个情况？是你们预见到未来的变化，还是因为一些已经存在的问题需要解决才做出了这个决定？
Nicolas：事实上，我到Facebook的时候，他们已经做好了决定。我于是成为了HBase项目最初的开发者之一。当时我自己迫切需要理解的问题之一就是为什么我们要做出这样的选择，比如为什么我们不用Cassandra等等。
我们的用户基数一直在增长，所以当时的首要问题在于分片（sharding）。好比我们的信息系统，用户们越来越多的使用聊天功能。用户需要保留他们的聊天记录，随时回去查阅它们，而不会容忍几年前的聊天记录被丢掉。种种此类需求都造成我们的数据量极快的上升，那么分片就成为很痛苦的事情，尤其是如果你要手动做分片的情况。而且我们需要让分片变得自动化，这样万一我们遭遇了一些运维事故，即时有十分之一的服务器都宕机了，也能够应付的过来。
所以我们需要这样一个数据库系统尽快上线，能够完成我们需要的功能，而且不会丢失数据。这就牵扯到一个时间预算的问题。MySQL，Cassandra和HBase都是设计优良的数据库，但问题是我们是要在现有的系统上自己打一些简陋的补丁将就着用一阵子，还是迁移到一个已经具备了此种功能的系统之上来满足长期的需求。在权衡之后，我们决定从MySQL转移出来。
51CTO：数据库迁移一般都是挺烦人的事情吧。你们在迁移的时候有没有什么有趣的事情？
Nicolas：在Facebook这样规模的企业工作的乐趣之一就在于，有些工作在中小企业里只有痛苦，但是在Facebook当中则是一种挑战。比如这个数据迁移，在Facebook里就有非常多的挑战。一个是性能优化。对于一般规模的迁移，优化并不在考虑当中；但是我们现在有5亿用户，做数据迁移的话，如果我们一周做1千万个，做完5亿则需要一年！这个速度是不可以接受的，是非常慢的。所以就需要做大量的优化。
那么这其中一个有趣的事情就是，你做优化，首先要检查一下，别人是不是已经做过相应的功能，你是不是已经进行了最合适的配置。不要花半天功夫写了个2000行代码的功能，结果却发现前人已经做过相关的工作。很多时候，我们的问题并非是没有某个功能，而是你不知道已经有了哪些功能！
51CTO：然后他们就不知道可以用现成的功能。
Nicolas：所以我们说，做任何事情之前，应该先多花一些功夫来真正了解这个系统。
51CTO：很有意思。那么接下来我们聊一些有关优化之前的一些工作。一个网站遇到性能问题，原因可能有无数种——我这么说没问题吧？
Nicolas：当然！那是一定的。
51CTO：那么在Facebook，我们是如何快速定位性能问题的根源呢？
Nicolas：首先，我们会用Ganglia等软件做度量计算——整个Facebook其实用到很多度量。那么我们有40个左右的图表来监控集群的健康状况。当我们监测到PUT Latency的值变得很高的时候，我们首先去检查所有牵涉到PUT的主要进程，分析这些进程的度量，深入进去。我们进行日志分析，用正则表达式来挖掘数据日志。对于大部分数据，其实我们并不需要一个调试器，你需要的是和一些非常熟悉这个系统的人坐在一起，反复探讨可能出现的问题。
所以，我们在Facebook遇到的问题，一般都是这样解决的：先去看图表，再看日志，尝试去理解发生了什么事，尝试在理论上找出系统的修复方法。接下来就是在后端的集群中用不同的流量去测试它，从而验证我们是不是真的修复了这个问题。
51CTO：所以相当于是在一个测试环境中调试？
Nicolas：是的，但不是那种单元测试环境，而是一个真实的测试环境。由用户产生的流量永远比那种基准测试要好得多，因为用户的流量和用户的性能体现才是你所关注的。
51CTO：好的，十分感谢。这些就是Facebook一般进行系统检查的流程了吧。
Nicolas：是的。话说我想有一点我想要强调一下，就是作为HBase的工程师，你看到我们有那么多度量，有那么多图表。这些其实是因为在我们为HBase设计任何新功能之前，我们会先考虑清楚需要为日后的分析工作放入哪些度量进去。我认为这是非常重要的。有很多开发者总是先加了功能上去，然后回头发现要修改这个、添加那个，***就会很烦。所以***一开始就把它们设计进去。
51CTO：所以说，就是要从一开始就把事情做对喽。那么***谈谈一个比较开放的问题吧。对于创业者，你会建议他们使用NoSQL吗？
Nicolas：我觉得毋庸置疑的一点是，你必须要从你的系统本身入手。NoSQL对于很多Web创业网站是非常合适的，尤其是当你的用户数量面临快速增长的情况。而对于小量数据而言——当然这个小量是相对的，好比GB级的数据量在我们这个TB级的世界里就是小量的——则无所谓用不用NoSQL了。
那么有关NoSQL***的一点就是高可扩展性，动态可扩展性。无需为分片发愁，无需频繁的替换查询表（Query Tables）。
51CTO：我听说NoSQL在做实时迁移方面也相对简单一些，是这样么？
Nicolas：我们用HBase做实时迁移，那么就如同之前所说，它能够处理大量的负载。假如说我们有个集群为2000万用户提供服务，然后我们要再迁1000万进来，那么它是可以处理这个扩展的。但是就算它扩展性再好，也不是说你能盲目的去做这个事儿，搞个不好，你迁移1000万进来，结果所有的用户都崩溃了。除非你事先做好分析，做好配置文件的修正，在后端做好大量的测试，这样在上线的时候才能按照预期的状态进展。
音频播放：
【编辑推荐】
