领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
姜迅谈阿里巴巴数据架构设计经验与挑战
受访人 姜迅 采访人 霍泰稳 发布于 2011年6月20日 长度 00:27:43 下载 MP3
概要
阿里巴巴数据架构专家、数据仓库架构师姜迅，在阿里巴巴负责了数据建模、技术架构、数据展示三个团队，在本次采访中举例说明了数据的商业价值，分享了大数据量的架构设计难点，选择水平扩展方案做数据分析架构，系统的可伸缩性，资源切片分给不同部门，以及如何能够在数据开放时保证系统的稳定性与资源共享，介绍了阿里巴巴现在的数据架构设计、调优、未来设计计划，也分享了设计过程中遇到的挑战，多任务多指标且相互依赖，数据仓库之间的人物关系非常负责，提出了蒲公英模型，指标服务化，可插拔的设计灵活结构。同时，他也分享了对于NoSQL的看法，对NoSQL技术的优缺点进行了点评，分享了NoSQL选型时的考量点，主要是健壮性和稳定性。
个人简介
姜迅，阿里巴巴数据仓库架构师，之前是Oracle的DBA，08年加入阿里巴巴，目前负责阿里巴巴数据分析工作，负责数据建模、技术架构、数据展现三个团队。
关于会议
阿里巴巴数据架构专家、数据仓库架构师姜迅，在阿里巴巴负责了数据建模、技术架构、数据展示三个团队，在本次采访中举例说明了数据的商业价值，分享了大数据量的架构设计难点，选择水平扩展方案做数据分析架构，系统的可伸缩性，资源切片分给不同部门，以及如何能够在数据开放时保证系统的稳定性与资源共享，介绍了阿里巴巴现在的数据架构设计、调优、未来设计计划，也分享了设计过程中遇到的挑战，多任务多指标且相互依赖，数据仓库之间的人物关系非常负责，提出了蒲公英模型，指标服务化，可插拔的设计灵活结构。同时，他也分享了对于NoSQL的看法，对NoSQL技术的优缺点进行了点评，分享了NoSQL选型时的考量点，主要是健壮性和稳定性。
个人简介
姜迅，阿里巴巴数据仓库架构师，之前是Oracle的DBA，08年加入阿里巴巴，目前负责阿里巴巴数据分析工作，负责数据建模、技术架构、数据展现三个团队。
关于会议
您好，我是阿里巴巴数据仓库架构师，我叫姜迅。08年加入阿里巴巴，之前一直是Oracle的DBA。加入阿里巴巴之后，一个很偶然的机会，从DBA转到了数据分析。现在想起来确实是个非常正确的选择，因为在这两年多时间里，我越来越感受到不同部门乃至整个社会对数字的迫切需求，随着需求量的增长，我们会发现很多原来的架构已经无法支撑现在数据分析的需求，这就迫使我们去利用其它方法来满足这样的分析。目前我在阿里巴巴负责三个团队，第一个团队负责数据模型，把业务抽象为实体。另外一个部门负责技术架构，主要负责搭建一个能够支撑海量数据的分析平台。那么第三个部门负责把数据推销出去，负责数据的展现，也就是把数据分析的结果让用户看到，这也是数据分析的价值。
我觉得其实可以举个简单的例子，就拿阿里巴巴来说，可能大家都知道去年温总理来我们这里访问，当时做了一个汇报，汇报里提到很重要的一项，就是我们有一个很重要的指标是反映国家的出口趋势指标。比如中国出口在2010年Q3会有上升或是下降，为什么阿里巴巴能够知道，那是因为，在阿里巴巴我们能够拿到12%左右的询盘，或者说交易是从阿里巴巴平台完成的，以服装行业为例，如果说2010年Q2大概有20%的服装的询盘，可能在英国地区，我们大概能够推测经过AQ的生产，出口一定会上升，因为在三个月前，他已向我下了定单，经过三个月的生产，这个生产好的服装就一定会出口，那么我们只要通过2010年Q2询盘量，就能够去推测到我们出口上升，所以我们实际上是能够在整个国家的宏观经济上去做一下分析。
另外一个淘宝的淘宝魔方，也叫数据魔方，这个东西实际上我们现在可以做很多的分析，举一个简单例子，假设，上次我们还没有做这个事情，比如说通过你对衣服的尺码的分析，我们可以分析出中国人现在是偏瘦还是偏胖。因为我可以通过多少人买均码，多少人买中码，多少人买大码，包括你鞋的尺码是能够分析出来的，我们越来越觉得数据是能够来对整个社会，甚至企业本身运营都是能够起到支撑作用的，所以在宏观经济上我们都觉得是有很大帮助，因为我们现在感觉很多社会行为是被数据所领导的，不管你做什么事情，上网买机票、买衣服、在银行里刷卡、打一个电话，很多信息是被记录的，记录的数据能够得到善用，而非去做恶，拿到这些数据之后能够把它所隐含的这种规律挖掘出来之后，能够指导整个企业运营也好，预测国家经济趋势也好，我们都希望能够拿到，因为对阿里巴巴来说，很重要的一点是我们的数据是非常非常有洞知力的，因为它是一个商业数据，不像是QQ、盛大这些公司，他们可能以娱乐数据为主，那么他们可能信息噪音会比较多，但是在阿里巴巴平台和淘宝平台上，因为就是在做生意，就是要去买东西，所以用户的行为很单纯，而且这种行为跟钱是相关的，所以这些数据的商业价值是非常高的。
另外一个淘宝的淘宝魔方，也叫数据魔方，这个东西实际上我们现在可以做很多的分析，举一个简单例子，假设，上次我们还没有做这个事情，比如说通过你对衣服的尺码的分析，我们可以分析出中国人现在是偏瘦还是偏胖。因为我可以通过多少人买均码，多少人买中码，多少人买大码，包括你鞋的尺码是能够分析出来的，我们越来越觉得数据是能够来对整个社会，甚至企业本身运营都是能够起到支撑作用的，所以在宏观经济上我们都觉得是有很大帮助，因为我们现在感觉很多社会行为是被数据所领导的，不管你做什么事情，上网买机票、买衣服、在银行里刷卡、打一个电话，很多信息是被记录的，记录的数据能够得到善用，而非去做恶，拿到这些数据之后能够把它所隐含的这种规律挖掘出来之后，能够指导整个企业运营也好，预测国家经济趋势也好，我们都希望能够拿到，因为对阿里巴巴来说，很重要的一点是我们的数据是非常非常有洞知力的，因为它是一个商业数据，不像是QQ、盛大这些公司，他们可能以娱乐数据为主，那么他们可能信息噪音会比较多，但是在阿里巴巴平台和淘宝平台上，因为就是在做生意，就是要去买东西，所以用户的行为很单纯，而且这种行为跟钱是相关的，所以这些数据的商业价值是非常高的。
我们对数据量感受很深，因为我08年刚来时，当时数据量大概在20个TB左右，到了09年，已经达到了100个TB。到了2010年底，就达到了300个TB，现在应该已经到了500个TB。所以这种膨胀速度是非常快的。我们最早用的是一台IBM 570，当时是09年，后来觉得不够，我们用了六个节点Oracle Rac去支持它。到了09年中就发现已经不够用了，所以在09年中我们引入了Green Plum做数据分析，再后来引入了Hadoop。 这样我们能够用比较少机器就能够满足我们现在需求。但对数据开放存储，我们把它放到Hadoop上，这是我们做的一个变化。总的来说，就是从一个单机到多机的Rac，然后再到分布式系统，这个分布系统不管是Green Plum还是Hadoop，一定越来越趋向分布式。因为单个PC的能力现在越来越强，但无论是小型机还是大型机，始终这种SCSI扩展方案总会有瓶颈，所以一定是批量做水平扩展，不管是用那种技术，我们一定会选择水平扩展方案做数据分析架构。
最主要的难点还是在系统的可伸缩性，就是怎样能够让一个系统很快速地随需增加计算能力或存储能力，之后有另外一个难点就是怎么能够把资源切片，然后分给不同部门，这是另外一个比较难的地方，因为现在我们发现，越来越多的部门都需要数据分析，它并不只是我们数据仓储一个部门的事情。如果有多个部门都需要来访问这些数据，那我们应该怎样把数据开放出去，这个是整个架构里面最难的部分。如果仅仅只是仓储一个部门使用，那我是比较容易做一些控制的，因为大家都知道，现在做数据分析绝大多数都是用SQL做分析，一个好的SQL，完全相同的功能，执行的性能有可能相差一万倍，这点我们最近感受很深。我们做了很多优化，经过简单优化尽量把一个任务从五个小时或十个小时变成五分钟，这种执行效率带给系统非常大的压力，如果这种随意分析任务能够上线，那么整个系统即使有再多资源也不够用，特别是分布式系统之后很多单机优化方式就更不适用了，而且每个查询就是一个简单的SELECT COUNT查询，可能涉及几个TB的数据。比如网络访问日志，一张表就有几个T或者十几个T，单表查询就可以把整个系统搞得非常忙。
我们非常关注的一个难点，就是如何能够在数据开放时，既能够保证系统的稳定性，又能为每个部门提供一部分系统资源，同时还不会导致系统独占，每个人都能做分析。这种任务可以有优先级，这也是我们现在比较关注的一个部分。我们现在也还在做的比如自动任务解析，因为现在任务都是用SQL或HQL写的，通过解析SQL提取原数据，再通过分析对象与对象之间的关系，就可以自动建立依赖，换句话说就是把SQL本身解析出来，FROM什么，WHERE是什么，属性从哪里来。其实业界有数源血缘分析的说法，即通过分析一个指标的变化从哪些任务里来，如果原系统发生了变化会影响哪些指标。这是很难的一个部分。确实，我们现在将近有一万个任务在系统中运行，有几千个指标，原系统在不断的变化，当原系统发生变化后就一定会影响到指标，如果这些指标变了，我希望能很快知道原系统某个资源变了，或者它的值变了，还有哪些指标会受到影响，我必须能够快速识别，再做代码修正。举个简单的例子，MEMBER，一个用户名字段，原来可能是4个长度，现在变成48个长度，我需要知道有哪些表要把这个长度变到48个长度，因为很多字段并不是说名称一定相同，名字可能是会变的。这个时候我需要解析比如我知道INSERT的COLUMN是从哪个FROM的COLUMN中来，这么一层一层地解析，最后把整条链都打通。
我们非常关注的一个难点，就是如何能够在数据开放时，既能够保证系统的稳定性，又能为每个部门提供一部分系统资源，同时还不会导致系统独占，每个人都能做分析。这种任务可以有优先级，这也是我们现在比较关注的一个部分。我们现在也还在做的比如自动任务解析，因为现在任务都是用SQL或HQL写的，通过解析SQL提取原数据，再通过分析对象与对象之间的关系，就可以自动建立依赖，换句话说就是把SQL本身解析出来，FROM什么，WHERE是什么，属性从哪里来。其实业界有数源血缘分析的说法，即通过分析一个指标的变化从哪些任务里来，如果原系统发生了变化会影响哪些指标。这是很难的一个部分。确实，我们现在将近有一万个任务在系统中运行，有几千个指标，原系统在不断的变化，当原系统发生变化后就一定会影响到指标，如果这些指标变了，我希望能很快知道原系统某个资源变了，或者它的值变了，还有哪些指标会受到影响，我必须能够快速识别，再做代码修正。举个简单的例子，MEMBER，一个用户名字段，原来可能是4个长度，现在变成48个长度，我需要知道有哪些表要把这个长度变到48个长度，因为很多字段并不是说名称一定相同，名字可能是会变的。这个时候我需要解析比如我知道INSERT的COLUMN是从哪个FROM的COLUMN中来，这么一层一层地解析，最后把整条链都打通。
我们现在整个系统结构基本是分成三层，最下面的数据层依赖于Hadoop解析存储，用Hadoop集成，中间的计算没有完全在Hadoop做，因为我们觉得这是我们实测的结果，也发现Green Plum的计算能力跟Hadoop的计算能力基本是1：4左右，如果同样的计算任务就需要四倍的Hadoop来支撑，因此计算是在Green Plum完成，然后再把它写回Hadoop去。这就是我们数据分析框架，更进一层，我们希望数据分析往前走，这是值得做的事情，原来说分析数据趋势与波动，这些数据一般都是给老板做一些专业决策支持或预测，如果真是这样，如果公司哪天不景气，有可能先砍掉的就是你这个部门，因为你确实只是作为辅助部门。所以我们现在想往前走，于是我们在结构上做了大的调整，我们把数据提供给千百万用户直接使用。这样系统就成为整个网站中不可或缺的环节，所以我们要把整个系统推着往前走，做推荐也好，做数据分析也好，把数据直接卖出去。
例如阿里巴巴中文站首页和国际站首页，有几个按钮是来自数据仓库中数据分析的结果，这种数据需要直接向数据仓库请求，因为，如果数据仓库服务器down掉，整个中文站首页就不能用了，这样的话，跟网站是基本上同样一个水平，我们是把对数据认知直接让最终客户感受到，所以我们会有往前走的目标，我们用分布式数据库来支持这种海量并发数据访问，我们能把对数据认知做成数据服务提供给最终用户，能够使他们直接看到我们对数据的理解，这也是我们想做的变化，我们会一直不断往前走。
例如阿里巴巴中文站首页和国际站首页，有几个按钮是来自数据仓库中数据分析的结果，这种数据需要直接向数据仓库请求，因为，如果数据仓库服务器down掉，整个中文站首页就不能用了，这样的话，跟网站是基本上同样一个水平，我们是把对数据认知直接让最终客户感受到，所以我们会有往前走的目标，我们用分布式数据库来支持这种海量并发数据访问，我们能把对数据认知做成数据服务提供给最终用户，能够使他们直接看到我们对数据的理解，这也是我们想做的变化，我们会一直不断往前走。
我刚也提到我们有一万多个任务，有几千个指标，这么多任务他们之间是相互依赖的，这种依赖关系非常复杂，我们尝试画过整个数据仓库之间的任务关系，结果是一张蜘蛛网，可读性非常差，所以我们想把每个指标做成服务，先对整个阿里巴巴的数据进行抽象，因为有一些实体是不会变化的。比如会员这个实体是不会变化的，不管这个公司今天举办什么狂风行动，明天发起什么春雷行动，但在五年内，我们总是基于会员做营销，这是整个阿里巴巴的根本，所以会员这个中心点是不变的，但这个中心点的很多属性是变化的，所以可能今天要分析旺铺的PV，明天可能要分析支付宝的支出情况，它的每个属性是不断变化的，我们希望找到变化的一个中心点。找到中心点之后，它的每个属性就跟蒲公英一样，做成插拔式的，即能够插入进来又能够拔掉这个指标，它不会影响到整个任务，这就是指标服务化，这点是我们非常想去做的事情。
如何做到蒲公英模型呢？我们有一个概念叫列交换。因为这种指标化如果之间见不能相互解耦，最终目的还是无法实现，所以在某个指标过时的时候这个指标能够快速下线而不影响其他指标，这种功能在基于SQL的架构中是无法实现的，因为你必须把这个指标有关所有代码全都改一遍才能把它下线。我们希望做到的是每个指标都是一个独立服务，这个服务能够快速加入也能快速下线，这是我们想做的。这与我们目前基于关系型数据库设计有关，因为现绝大部分的数据分析都是基于关系型数据库模型，所以我们现在这个模型实际上是基于KV这种结构去设计的，我们认为所有数据都是基于key/value/description这么一个三元组，这个三元组足够描述一个对象的属性。你可以按照不同的方式组合这个三元组，假设这个数据你要去使用的时候，你是想按照对外提供访问的，那么你就可以把这个三元组，这个KV对应的三元组能。比如把一个Key的数据能够放在一起，那么这样的话，你就能够支撑，对这个人，你想要知道这个人他的所有数据，就能很快的拿到，那如果说，我是要把他做分析的，那么实际上你就可以把这个三元组，把某一个Description16：29放到一起，那这样的话，我就可以知道说，对某一个属性，它的有多少个不同的值，这个是说，我们可以，当你把所有的这个指标，把它都拆解，抽象化后，你都会得到这么一个KV对，这也是其实我现在理解，为什么由此以后他会变得这么热的一个原因。
你可以把所有这种对象描述做成一个KV描述，这样你能够很方便地组合，我能够很方便地添加。例如我能够set一个对象，这个对象可以是没有这个架构的，这不像关系型数据库，它必须有一个列，如果女性增加一个属性比如服装的颜色，你就必须有一个字段颜色来支持，如果没有就必须增加一列。但如果是KV结构就不需要了，只要set属性就可以了，而且不需要预先定制。因为每个对象属性会越来越多，特别是现在，我们做用户分析的时候，实际上每个人对用户的理解都不一样，例如我们会分析，你是杭州人吗？你是个高价值的人吗？是男人吗？会给每个人打上各种不同的属性，每个人的属性都会不一样，因为每个人不一样。如果说一个对象要打这么多属性，可能那张表有几千几万个字段，数据库也能够支持，如果我们的模型能够把每个人不同的属性不断插进来，把出去，这个就变得很方便。我想看这个人的信息，我就可以把这个人所有值都拿出来，我想按照区域来看，就可以只把区域这个东西放在他一起，我就可以把杭州关于这个人的信息全部筛选出来，而且这个根据每个人的想法不同可以不停地增加，它不需要DB给你增加字段，要求做性能测试。一个做PI分析的人，或者一个业务发展人，他只有有想法就可以把值加进去，然后这个属性马上会回到系统里去，它能够被另外一个人筛选，这样整个数据统计就变成一个回环，前面系统收集到这个人的属性，紧接着这个数据就能被BI分析，而且整个过程不需要人工干预，系统自动支持。
如何做到蒲公英模型呢？我们有一个概念叫列交换。因为这种指标化如果之间见不能相互解耦，最终目的还是无法实现，所以在某个指标过时的时候这个指标能够快速下线而不影响其他指标，这种功能在基于SQL的架构中是无法实现的，因为你必须把这个指标有关所有代码全都改一遍才能把它下线。我们希望做到的是每个指标都是一个独立服务，这个服务能够快速加入也能快速下线，这是我们想做的。这与我们目前基于关系型数据库设计有关，因为现绝大部分的数据分析都是基于关系型数据库模型，所以我们现在这个模型实际上是基于KV这种结构去设计的，我们认为所有数据都是基于key/value/description这么一个三元组，这个三元组足够描述一个对象的属性。你可以按照不同的方式组合这个三元组，假设这个数据你要去使用的时候，你是想按照对外提供访问的，那么你就可以把这个三元组，这个KV对应的三元组能。比如把一个Key的数据能够放在一起，那么这样的话，你就能够支撑，对这个人，你想要知道这个人他的所有数据，就能很快的拿到，那如果说，我是要把他做分析的，那么实际上你就可以把这个三元组，把某一个Description16：29放到一起，那这样的话，我就可以知道说，对某一个属性，它的有多少个不同的值，这个是说，我们可以，当你把所有的这个指标，把它都拆解，抽象化后，你都会得到这么一个KV对，这也是其实我现在理解，为什么由此以后他会变得这么热的一个原因。
你可以把所有这种对象描述做成一个KV描述，这样你能够很方便地组合，我能够很方便地添加。例如我能够set一个对象，这个对象可以是没有这个架构的，这不像关系型数据库，它必须有一个列，如果女性增加一个属性比如服装的颜色，你就必须有一个字段颜色来支持，如果没有就必须增加一列。但如果是KV结构就不需要了，只要set属性就可以了，而且不需要预先定制。因为每个对象属性会越来越多，特别是现在，我们做用户分析的时候，实际上每个人对用户的理解都不一样，例如我们会分析，你是杭州人吗？你是个高价值的人吗？是男人吗？会给每个人打上各种不同的属性，每个人的属性都会不一样，因为每个人不一样。如果说一个对象要打这么多属性，可能那张表有几千几万个字段，数据库也能够支持，如果我们的模型能够把每个人不同的属性不断插进来，把出去，这个就变得很方便。我想看这个人的信息，我就可以把这个人所有值都拿出来，我想按照区域来看，就可以只把区域这个东西放在他一起，我就可以把杭州关于这个人的信息全部筛选出来，而且这个根据每个人的想法不同可以不停地增加，它不需要DB给你增加字段，要求做性能测试。一个做PI分析的人，或者一个业务发展人，他只有有想法就可以把值加进去，然后这个属性马上会回到系统里去，它能够被另外一个人筛选，这样整个数据统计就变成一个回环，前面系统收集到这个人的属性，紧接着这个数据就能被BI分析，而且整个过程不需要人工干预，系统自动支持。
对，我们希望达到这样的效果，只有这样我们才能把人解放出来，我们不需要每天去应对字段变化而做变更，这样太痛苦，如果能够做到这点，我们会比较有弹性，所有的组织结构能够做到可插拔。
根据我的理解，NoSQL还是一个存储，是基于关系型数据库的设计，与我们现在的一些关系数据库Oracle/DB2/PostgreSQL不同，就像现在我们说的Java对象，其实这种对象设计都是基于一个Key，它有一些属性，NoSQL更自然贴近Java，因为它不需要做序列化和反序列化，它自身就有Key/Value。我觉得首先是关系模型支持越来越方便描述，这是它比较大的特点，例如你要描述一个人有多少件衣服，你必须有一张叫做人的表，另外有一张叫做衣服的表，那张表可能是一张素表，可能有很多不同的衣服，NoSQL就不需要，他还是一个人一个Key，你可以有三个Key，第一个Key是他有件黄色的衣服，第二个Key是他有件蓝色的T恤衫，第三个Key是他可能有件红色的马甲，你可以把这些Key都放到同一张表里去，而不需要多张表就维护，你只需要有这样一个Key传进来，你就可以找到它了，它能更自然地描述。我觉得这是一个特点，并不是最关键的点，最关键的是把对象都插到KV之后，NoSQL的伸缩性做得非常好，而且简单，因为伸缩性对我们来说非常重要，特别是我们刚才提到的增长，每个这个数在不断地增长，基本上你根本没办法在今年预计到明年会怎样。
我们的数据库原来打算用IBM小机，从590升级，后来我们发现，590已经插满了，你怎么升？没办法升级，往上扩展也不足以支持应用，所以只能水平扩展，这必然要求有一个健壮的分布式机制，我们现在来看NoSQL，不管是Hbase、Cassandra，还是MongoDB，它们都是利用这种廉价PC来支撑整个系统，都是基于对象描述建立不那么复杂的关系模型，它对对象进行抽象、简单化，让整个系统获得非常好的扩展性。尤其对网站而言，我们愿意为了扩展性去牺牲比如一致性等，因为如果不能扩展，就不能支持业务增长。前段时间，Facebook上有一家公司Zynga，它号称一个星期要增加一千台服务器，这种增长真的是每天一个PB，一个星期就一千台服务器，这种增长，它里面更多的是视频这种信息，但确实，我们会越来越多看到这种PB级的数据中心或者说数据量，雅虎已经有60PB的数据，像这种你没有办法，你只有用这种KV分布式支持，我并不是说完全是NoSQL，我觉得我们现在谈NoSQL都是说它不仅仅是SQL，如果说是SQL，对我们分析而言或者对网站而言，SQL是一个非常简单易用的工具，我觉得没有一个语言比SQL更简单更易懂了，比如我要做一个聚类，用Group By就行了，要做去重，用Distinct就行了，这整个语言都是非常简单的。90%的数据需求通过SQL都能快速支持，包括Facebook的，他们也提到说整个Facebook数据开放，把HQL开放给整个部门，90%用Java没有用MapReduce，就是用HQL去写。因为这个任务非常简单，每个人都能理解它，只有被更多人使用，这个数据才能发挥它的价值。
但是SQL确实有很多场景支持得不好，这个时候我们需要有一些不同的方式来支持。我对NoSQL的理解是这样的，首先它不仅仅是一个SQL，它并不是说排斥SQL。另外，我觉得NoSQL有几个核心点或者说核心概念，它是一个可扩展的系统，我们要求系统的扩展性非常高。另外一点是它的架构，它是一个自由架构的结构，它不像关系模型一定要把架构制定得非常严格，这是我的理解。第三点是它基于大量PC结构来支持，因为现在PC很便宜，单机性能很高，它能够通过机柜堆叠来扩展以达到比一个小型机更高的性能。我理解NoSQL是一个过程，或者说，NoSQL对我们来说是对现有架构的补充，并不是说它一定要把谁干掉。
我们的数据库原来打算用IBM小机，从590升级，后来我们发现，590已经插满了，你怎么升？没办法升级，往上扩展也不足以支持应用，所以只能水平扩展，这必然要求有一个健壮的分布式机制，我们现在来看NoSQL，不管是Hbase、Cassandra，还是MongoDB，它们都是利用这种廉价PC来支撑整个系统，都是基于对象描述建立不那么复杂的关系模型，它对对象进行抽象、简单化，让整个系统获得非常好的扩展性。尤其对网站而言，我们愿意为了扩展性去牺牲比如一致性等，因为如果不能扩展，就不能支持业务增长。前段时间，Facebook上有一家公司Zynga，它号称一个星期要增加一千台服务器，这种增长真的是每天一个PB，一个星期就一千台服务器，这种增长，它里面更多的是视频这种信息，但确实，我们会越来越多看到这种PB级的数据中心或者说数据量，雅虎已经有60PB的数据，像这种你没有办法，你只有用这种KV分布式支持，我并不是说完全是NoSQL，我觉得我们现在谈NoSQL都是说它不仅仅是SQL，如果说是SQL，对我们分析而言或者对网站而言，SQL是一个非常简单易用的工具，我觉得没有一个语言比SQL更简单更易懂了，比如我要做一个聚类，用Group By就行了，要做去重，用Distinct就行了，这整个语言都是非常简单的。90%的数据需求通过SQL都能快速支持，包括Facebook的，他们也提到说整个Facebook数据开放，把HQL开放给整个部门，90%用Java没有用MapReduce，就是用HQL去写。因为这个任务非常简单，每个人都能理解它，只有被更多人使用，这个数据才能发挥它的价值。
但是SQL确实有很多场景支持得不好，这个时候我们需要有一些不同的方式来支持。我对NoSQL的理解是这样的，首先它不仅仅是一个SQL，它并不是说排斥SQL。另外，我觉得NoSQL有几个核心点或者说核心概念，它是一个可扩展的系统，我们要求系统的扩展性非常高。另外一点是它的架构，它是一个自由架构的结构，它不像关系模型一定要把架构制定得非常严格，这是我的理解。第三点是它基于大量PC结构来支持，因为现在PC很便宜，单机性能很高，它能够通过机柜堆叠来扩展以达到比一个小型机更高的性能。我理解NoSQL是一个过程，或者说，NoSQL对我们来说是对现有架构的补充，并不是说它一定要把谁干掉。
其实我们现在最关心的还是它是不是够健壮，够稳定，特别是我们线上系统。健壮和稳定性是我们最关心的一个部分，另外一个就是性能。实际上，前段时间我们用过Cassandra，也用过MongoDB，也尝试用Hbase做一些业务支持，根据评测，包括我们自己还有开放的阿里云，我们KV引擎从单个性能来看，它一定比关系型数据库能力要弱，就单机相比，或者同样这种以前的机器跟PC分布式比，会发现它比这种数据库要弱。因为毕竟数据库发展这么多年，它有成熟的索引机制，但NoSQL的可扩展性我觉得是非常重要的一点。另外现在绝大多数NoSQL都是开源的，这样我们有很多想法可以在上面实现。第三是我们希望这个系统像Facebook或雅虎这样的公司是不是在使用，因为要找到好案例，跟着大趋势走，而不是说自己找一个前沿的东西研究，对企业而言，要尽可能低成本支持更大的应用，这也是我们考量的一点。我们不愿意做第一个吃螃蟹的人，因为毕竟系统稳定性是比较重要的一点。
采访人 霍泰稳 霍泰稳是InfoQ中文站的联合创始人兼CEO，有多年的软件开发经验和媒体从业经历。
这视频是啥时候拍的啊？
发表人
张 宝华
发表于
数据存储结构的语义化
发表人
张 宝华
发表于
视频太慢了！严重影响心情！
发表人
Bi Benny
发表于
视频速度也忒差了吧
发表人
qu zubin
发表于
为什么 这么咔咔咔咔咔
发表人
liang yang
发表于
这哥们一开始的造型有点装呀。
发表人
fei liu
发表于
6 条回复
关注此讨论 回复