分享

［编者注：这是一篇来自周伦   EMC中国研究院云基础构架实验室高级研究员的文章。］

A revolution has started to free data center networks fromthe tyranny of inflexibility, complexity, vendor stranglehold, and high costs.

It’s time to decouple network services from the underlyingphysical hardware.

It’s time to never have to think about the network again.

It’s time to virtualize the network.

摘自nicira主页

引子

接触网络虚拟化纯属偶然。作为研究院微博五毛小分队的成员，撰出一条微博是每天的任务。那天无意中抓取了一条新闻：Xsigo公司推出了业界第一个数据中心网络全虚拟化解决方案。巧的是Xsigo公司的方案是基于Infiniband技术的，而我最近的项目使我对Infiniband略懂，所以就重点关注了一下。这一关注不要紧，才发现里面水很深。不管是传统IT豪强还是网络巨人都对这一领域虎视眈眈，谋篇定局，更有无数的创业者们在此展开深耕。 抱着对技术要略懂的心态，我入水一探究竟。这篇博文算是对我这次涉水的总结，网络虚拟化发展到现在牵涉的技术非常多，每种技术都可以单独写一篇文章来介绍，限于我的精力和知识水平只能给大家做个整体的简单介绍，不足之处还请各位批评指正。如果读者对某种技术感兴趣可以搜索相关资料做更详细的了解。

什么是网络虚拟化

首先我们需要明确一个问题，什么是网络虚拟化，网络虚拟化简单来讲是指把逻辑网络从底层的物理网络分离开来。这个概念产生的比较久了，VLAN，VPN， VPLS等 都可以归为网络虚拟化的技术。近年来，云计算的浪潮席卷IT界。几乎所有的IT基础构架都在朝着云的方向发展。在云计算的发展中，虚拟化技术一直是重要的推动因素。作为基础构架，服务器和存储的虚拟化已经发展的有声有色，而同作为基础构架的网络却还是一直沿用老的套路。在这种环境下，网络确实期待一次变革，使之更加符合云计算和互联网发展的需求。云计算的大环境下，网络虚拟化的定义没有变，但是其包含的内容却大大增加了。

云计算环境下的网络虚拟化需要解决端到端的问题，笔者将其归纳为三个部分：

（一）第一部分是服务器内部。随着越来越多的服务器被虚拟化，网络已经延伸到Hypervisor内部，网络通信的端已经从以前的服务器变成了运行在服务器中的虚拟机，数据包从虚拟机的虚拟网卡流出，通过Hypervisor内部的虚拟交换机，在经过服务器的物理网卡流出到上联交换机。在整个过程中，虚拟交换机，网卡的I/O问题以及虚拟机的网络接入都是研究的重点。

（二）第二部分是服务器到网络的连接。10Gb以太网 和Infiniband等技术的发展使一根连接线上承载的带宽越来越高。为了简化，通过一种连接技术聚合互联网络和存储网络成为了一个趋势。

（三）第三部分是网络交换，需要将物理网络和逻辑网络有效的分离，满足云计算多租户，按需服务的特性，同时具有高度的扩展性。

下面我就围绕这三个方面来讲述网络虚拟化中的一些主要技术和标准。

服务器内部

I/O虚拟化

多个虚拟机共享服务器中的物理网卡，需要一种机制既能保证I/O的效率，又要保证多个虚拟机对用物理网卡共享使用。I/O虚拟化的出现就是为了解决这类问题。I/O虚拟化包括了从CPU到设备的一揽子解决方案。

从CPU的角度看，要解决虚拟机访问物理网卡等I/O设备的性能问题，能做的就是直接支持虚拟机内存到物理网卡的DMA操作。Intel的 VT-d技术及 AMD 的IOMMU技术通过DMARemapping 机制来解决这个问题。DMARemapping机制主要解决了两个问题，一方面为每个VM创建了一个DMA保护域并实现了安全的隔离，另一方面提供一种机制是将虚拟机的GuestPhysical Address翻译为物理机的HostPhysical Address。

从虚拟机对网卡等设备访问角度看，传统虚拟化的方案是虚拟机通过Hypervisor来共享的访问一个物理网卡，Hypervisor需要处理多虚拟机对设备的并发访问和隔离等。这样Hypervisor容易行成一个性能瓶颈。为了提高性能，一种 做法是虚拟机绕过Hypervisor直接操作物理网卡，这种做法通常称作PCIpass through，VMware，Xen和KVM都支持这种技术。但这种做法的问题是虚拟机通常需要独占一个PCI插槽，不是一个完整的解决方案，成本较高且扩展性不足。 另一种做法是设备如网卡直接对上层操作系统或Hypervisor提供虚拟化的功能，一个以太网卡可以对上层软件提供多个独立的虚拟的PCIe设备并提供虚拟通道来实现并发的访问。这种方法也是业界主流的做法和发展方向，目前已经形成了标准，主要包括SR-IOV(SingleRoot IO Virtualization)和MR-IOV(Multi-RootIO Virtualization)。这方面的技术在网上已有很好的文章来做介绍，推荐想进一步了解的同学读一读：http://t.cn/aK72XS

阅读全文»

分享

分享

十个初创公司里面，只有一个成功的。从这个角度来说，山石已经算是成功的。产品做出来了，也有销售业绩，无论投资人是否已经看到曙光，这已经走在大多数初创公司前列。相对于PANW来说，山石就逊色一些。为什么呢？

第一个问题是TAM，total addressable market。简单比较中美重量级科技公司，比如谷歌和百度，是5:1的关系。这两个公司都是该行业在地区的领头羊。百度在国内的市场占有率还更高。所以如果市场占有率类似，这个比例可能要达到10:1比较合理。现在PANW在美国的位置也类似与山石在中国的位置，都非市场第一，都有一定的知名度，都有一定的创新。

第二个问题，客户。PANW的主要定位是企业用户。而这部分用户在国内几乎是不存在的。国际大公司通常有比较统一的采购模式，也就是说总部决定怎么选购产品。除了极少数大型民营企业，民企几乎没有类似的安全需求。那就剩下来大、中型国企和政府机关。这样的客户群，采购方法和使用需求非常的，个性化。销售的个人关系基本直接决定了采购对象。而对于销售来说，公司能提供的提成要远高于初创公司潜在股份的收益。所以，这样的刺激机制的结果就是市场分割严重。

第三个问题是产品。如果产品好，山石不是也能卖到国外来吗？其实这也非常困难。因为，客户定义了山石的产品。所以产品好不好，是相对的感念。举一个简单的例子，国内对于QoS的需求很高，而这种功能对于大企业来说并没有多大意义。如果企业里有p2p，IT不但把它禁用，而且还会查找源头，和用它的人聊聊。相反地，企业需要功能，比如用户识别，却是非常重要的。而且，对于NGFW安全产品来说，用户识别实际上是第六TUPLE。反过来看看山石的产品，企业用的功能都还基本处在端口防火墙的时代。而这部分是CHKP，思科和Juniper的惯有市场，怎么竞争呢？

最后简单总结一下，按照目前这个市场情况。山石做的已经不错了。当然，这么看起来，山石的前途也比较有限。也许对于国内这种市场状态，一些比较小资金小规模的游击队更能轻装上阵，更能适应市场需求。

分享

分享

从网络虚拟化说起
云计算的发展，是以虚拟化技术为基础的。云计算服务商以按需分配为原则，为客户提供具有高可用性、高扩展性的计算、存储和网络等IT资源。虚拟化技术将各种物理资源抽象为逻辑上的资源，隐藏了各种物理上的限制，为在更细粒度上对其进行管理和应用提供了可能性。近些年，计算的虚拟化技术（主要指x86平台的虚拟化）取得了长足的发展；相比较而言，尽管存储和网络的虚拟化也得到了诸多发展，但是还有很多问题亟需解决，在云计算环境中尤其如此。

OpenFlow和SDN尽管不是专门为网络虚拟化而生，但是它们带来的标准化和灵活性却给网络虚拟化的发展带来无限可能。笔者希望通过本文对OpenFlow/SDN做一个初步介绍，以期帮助大家能够进一步深入了解和学习OpenFlow/SDN。限于笔者能力有限，文中难免纰漏错误之处，欢迎批评和指正。

起源与发展
OpenFlow起源于斯坦福大学的Clean Slate项目组 [1] 。CleanSlate项目的最终目的是要重新发明英特网，旨在改变设计已略显不合时宜，且难以进化发展的现有网络基础架构。在2006年，斯坦福的学生Martin Casado领导了一个关于网络安全与管理的项目Ethane[2]，该项目试图通过一个集中式的控制器，让网络管理员可以方便地定义基于网络流的安全控制策略，并将这些安全策略应用到各种网络设备中，从而实现对整个网络通讯的安全控制。受此项目（及Ethane的前续项目Sane[3]）启发，Martin和他的导师Nick McKeown教授（时任Clean Slate项目的Faculty Director）发现，如果将Ethane的设计更一般化，将传统网络设备的数据转发（data plane）和路由控制（control plane）两个功能模块相分离，通过集中式的控制器（Controller）以标准化的接口对各种网络设备进行管理和配置，那么这将为网络资源的设计、管理和使用提供更多的可能性，从而更容易推动网络的革新与发展。于是，他们便提出了OpenFlow的概念，并且Nick McKeown等人于2008年在ACM SIGCOMM发表了题为OpenFlow: Enabling Innovation in Campus Networks[4]的论文，首次详细地介绍了OpenFlow的概念。该篇论文除了阐述OpenFlow的工作原理外，还列举了OpenFlow几大应用场景，包括：1）校园网络中对实验性通讯协议的支持（如其标题所示）；2) 网络管理和访问控制；3）网络隔离和VLAN；4）基于WiFi的移动网络；5）非IP网络；6）基于网络包的处理。当然，目前关于OpenFlow的研究已经远远超出了这些领域。

基于OpenFlow为网络带来的可编程的特性，Nick和他的团队（包括加州大学伯克利分校的Scott Shenker教授）进一步提出了SDN（Software Defined Network, 目前国内多直译为“软件定义网络”）的概念–其实，SDN的概念据说最早是由KateGreene于2009年在TechnologyReview网站上评选年度十大前沿技术时提出[5]。如果将网络中所有的网络设备视为被管理的资源，那么参考操作系统的原理，可以抽象出一个网络操作系统（Network OS）的概念—这个网络操作系统一方面抽象了底层网络设备的具体细节，同时还为上层应用提供了统一的管理视图和编程接口。这样，基于网络操作系统这个平台，用户可以开发各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无需关心底层网络的物理拓扑结构。关于SDN的概念和原理，可以参考开放网络基金会（Open NetworkingFoundation）于今年4月份发表的SDN白皮书Software Defined Networking：The New Norm forNetworks [6] 。

从上面的描述中，可以看出OpenFlow/SDN的原理其实并不复杂，从严格意义上讲也很难算是具有革命性的创新。然而OpenFlow/SDN却引来了业界越来越多的关注，成为近年来名副其实的热门技术。目前，包括HP、IBM、Cisco、NEC以及国内的华为和中兴等传统网络设备制造商都已纷纷加入到OpenFlow的阵营，同时有一些支持OpenFlow的网络硬件设备已经面世。2011年，开放网络基金会（Open Networking Foundation）在Nick等人的推动下成立，专门负责OpenFlow标准和规范的维护和发展；同年，第一届开放网络峰会（OpenNetworking Summit）召开，为OpenFlow和SDN在学术界和工业界都做了很好的介绍和推广。今年年初召开的第二届峰会上，来自Google的Urs Hölzle在以OpenFlow@Google[7]为题的Keynote演讲中宣布Google已经在其全球各地的数据中心骨干网络中大规模地使用OpenFlow/SDN，从而证明了OpenFlow不再仅仅是停留在学术界的一个研究模型，而是已经完全具备了可以在产品环境中应用的技术成熟度。最近，Facebook也宣布其数据中心中使用了OpenFlow/SDN的技术。
阅读全文»

分享

分享

本文是最新的拙作，希望能大家能提点意见^_^

任何一个时代或者模式的兴起，都离不开与之相关的Killer App，比如，C/S时代的SAP ERP，互联网 1.0 时代的门户，以及互联网 2.0时代的搜索和SNS等，那么在当今云计算这个时代有那些Killer App呢？当然首当其冲的肯定是以VMware 和Amazon EC2为代表的虚拟化和相关IaaS服务，除此之外，新近崛起的大数据绝对也是云计算的Killer App之一，并且不仅类似百度、阿里以及腾讯这样的互联网巨头有相关的应用需求，而且根据我个人平时与客户接触，发现有很多普通中小企业，特别是中型的互联网和物联网企业，在这方面的场景也有很多。本文将首先给大家介绍一下在我眼中的大数据，以及大数据的意义和特点，再给大家聊聊大数据的常见处理流程，之后将会和大家分享一下我是如何帮助一些中小企业实施大数据相关的解决方案，也就是大数据如何从“小”做起。

什么是大数据？

过去计算机产生的数据，较简单，基本上都是一笔笔事务，总量虽大，但是都是整体增长幅度都还是可控的，比如传统的金融企业，经常使用几台大型机就管理其所有的业务数据，而最近几年，由于以平板、智能手机和传感器为代表的智能设备越来越多，同时这些设备的生成的数据更是远远地超过我们的想象。据美国著名咨询公司IDC的统计，全球数字信息在未来几年将呈现惊人增长，预计到2020年总量将是现在的44倍。据另外一份数据显示，全球 90% 的数据都是在过去两年中生成的，并且每年以50%的速度进行增长，每天，遍布世界各个角落的传感器、移动设备、在线交易和社交网络产生上PB级别的数据；每个月，全球网友发布了 10多 亿条 Twitter 信息和300多 亿条 Facebook 信息。那么这些大数据的存在有什么价值和意义呢？

大数据的意义

我个人和一些朋友一直觉得大数据就好比一口油井，因为里面蕴含着非常丰富的价值，如果企业能有效利用其内部存储的海量数据，那么将会改善其自身的产品和服务，从而提升客户和受众的体验，从而在大数据时代获取竞争优势，并且随着本身分析和挖掘技术不断地提升，可以在之前的基础上提供新的决策模式，从而支持管理者进行快速和精确地决策，这样能够超越对手，抢占市场先机，独领风骚。

下面通过几个行业来和大家举例讲解一下大数据有那些意义和作用？

互联网企业

我们有一些客户，他们主要是做网络舆情或者网络广告，他们明天都会处理和收集TB级别日志或者网页，结构化和非结构化都有，他们就是通过分析这些数据来给其客户提供价值，比如分析一下一个男性护肤品广告是在世界杯期间投放好，还是在亚洲杯那段时间播出好？还有，在电子商务方面，国外eBay的分析平台每天处理的数据量高达100PB，超过了纳斯达克交易所每天的数据处理量。为了准确分析用户的购物行为，eBay定义了超过500种类型的数据，对顾客的行为进行跟踪分析，并且通过这些分析促进eBay自身的业务创新和利润增长。

智能电网

我们有一个合作伙伴，他们是做智能电网相关的解决方案。对那些电网而言，如果无法准确预估实际电力的使用情况，将会使电网要求电厂发出过量的电力，虽然这些过量电力可以通过某种模式进行保存，但是大量的电力浪费已不可避免。而通过他们智能电网的解决方案，每隔一刻钟会采集一个省几千万用户的用电数据，之后他们会根据这些数据来精确分析用户的用电模型，最后通过这个用电模型来优化电力生产，从而有效地减少电力资源的浪费。

车联网

在车联网方面，我们也有一个客户，他们在一个城市有几十万台基于Android的终端，而这些终端会每隔一段时间会发送具体位置的GPS消息给后端的数据集群，接着这些集群会分析一下这些海量的GPS信息，分析出那些路段在什么时候比较堵，之后将这些非常有价值的信息不断地推送给客户，从而帮助用户减少在路上所消耗的时间。

医疗行业

在这个方面，大数据的用例有很多。首先，通过分析大量的病例信息，将有效地帮助医生治病；其次，假设在一个病人身体的多个节点加入探针设备，而且每个探针每天会采集GB级别关于人体细胞和血液运行状态的数据，之后计算集群可以根据这些数据来来进行分析，这样能更精确地判断病因，从而让医生对病人进行更具针对性地治疗。

机器学习

在这方面，最出名的例子莫过于最近很火的Siri，它后台有一个庞大的HBase集群来对类似语言这样的文本数据进行分析和管理，从而使Siri变成一位越来越老练的个人助手，为iPhone 4S的用户提供了日期提醒、天气预报和饭店建议等服务。除此之外，还有IBM的Watson，它通过一个基于Hadoop UIMA框架的集群来挖掘海量的文本信息来实现一定程度的人工智能，并在美国著名知识问答节目Jeopardy中战胜多位出色的人类选手。

国家安全

这方面最出名的例子，莫过于美国的联邦情报局（CIA）。在过去10年中，他们通过无人侦察机收集了大量阿富汗那边地理相关的视频资料，之后通过分析这些海量视频资料，来对极具危害性的恐怖组织团伙进行定位。

大数据的特点

大数据，不仅有“大”这个特点，除此之外，它还有很多其他特色，在这方面，业界各个厂商都有自己独特的见解，但是总体而言，我觉得可以用“4V+1C”来概括，“4V+1C分别代表了Variety（多样化）、Volume（海量）、Velocity（快速）、Vitality（灵活）以及Complexity（复杂）这五个单词。

Variety（多样化）

大数据一般包括以事务为代表的结构化数据、以网页为代表的半结构化数据和以视频和语音信息为代表的非结构化等多类数据，并且它们处理和分析方式区别很大。

Volume（海量）

通过各种智能设备产生了大量的数据，PB级别可谓是常态，我接触的一些客户每天量都在几十GB，几百GB左右，我估计国内大型互联网企业的每天数据量已经接近TB级别。

Velocity（快速）

要求快速处理，因为有些数据存在时效性，比如电商的数据，假如今天数据的分析结果要等到明天才能得到，那么将会使电商很难做类似补货这样的决策，从而导致这些数据失去了分析的意义。

Vitality（灵活）

因为在互联网时代，和以往相比，企业的业务需求更新的频率加快了很多，那么相关大数据的分析和处理模型必须快速地适应。

Complexity（复杂）

虽然传统的BI已经很复杂了，但是由于前面4个V的存在，使得针对大数据的处理和分析更艰巨，并且过去那套基于关系型数据库的BI开始有点不合时宜了，同时也需要根据不同的业务场景，采取不同处理方式和工具。

大数据的常见处理流程

前面已经跟大家讲了处理大数据的必要性和特点，那么接着将谈到如何处理大数据，特别是常见的流程。具体的大数据处理方法其实有很多，但是根据长时间的实践，我总结了一个基本的大数据处理流程（图1），并且这个流程应该能够对大家理顺大数据的处理有所帮助。

图1. 大数据的常见处理流程

整个处理流程可以概括为四步，分别是采集、导入和预处理、统计和分析以及挖掘

采集

利用多个的数据库来接收发自客户端（Web、App或者传感器形式等）的数据，并且用户可以通过这些数据库来进行简单的查询和处理工作，比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。

在采集部分，主要特点和挑战方面是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作，比如著名用于购买火车票的12306站点和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑，并且如何在这些数据库之间进行负载均衡和分片的确是需要深入地思考和设计。

导入/预处理

虽然有采集端本身会有很多数据库，但是如果要对这些海量数据进行有效地分析，还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作，也有一些用户会在导入时候使用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。

在特点和挑战方面，主要是导入数据量大，每秒导入量经常达到百兆，甚至GB级别。

统计/分析

统计与分析主要利用分布式数据库或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC 的GreenPlum、Oracle的Exadata以及基于MySQL的列式存储Infobright等，而一些批处理或者基于半结构化的需求可以使用Hadoop。

统计与分析这部分，主要特点和挑战方面是分析涉及的数据量大，其对系统资源，特别是I/O会有极大地占用。

挖掘

与前面统计和分析不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，这样实现一些高级别数据分析的需求，比较典型算法有用于聚类的K-Means、用于统计学习的SVM和用于分类的Naive Bayes，主要使用的工具有Hadoop的Mahout等。

在特点和挑战方面，主要是挖掘的算法复杂，并且计算涉及的数据量和计算量都很大，还有，常用数据挖掘算法库以单线程为主。

如何从“小”做起？

由于我平时与中小企业的接触非常频繁，虽然技术方案与实际的问题相关，很难在一篇文章当中详尽地道来。除了上面那个基本处理流程之外，我下面会将一些基本的从“小”做起的思路给大家阐述一下：

1. 认识自己的不足，主要是在技术、人力和财力等方面是不仅无法与Google和Amazon这样国外巨头比肩，而且与国内三大互联网BAT（百度、阿里巴巴和腾讯）也是无法比肩的，所以需要深刻认识；
2. 明确分析自己的需求，下面是几个常见的需求选项：
   1. 数据类型，是结构化，半结构化，还是非结构化为主；
   2. 数据大小，内部数据级别是TB级别、PB级别或者PB以上级别；
   3. 读写量级，比如每小时写入的数据达到GB级别，或者每天写入达到TB级别等；
   4. 读写比例，是写为主，还是以读为主；
   5. 并发数，大致的每秒并发数；
   6. 一致性，只接受强一致性，或者可以接受最终一致性和弱一致性；
   7. 延迟度，最高能容忍的延迟度是多少，是10毫秒，100毫秒，还是可以1秒
   8. 分析的复杂度，需不需要引入较复杂的数据挖掘算法等。
3. 要灵活使用现有的工具，首先，推荐使用一些开源或者是可以承受的商业软件，虽然个人并不排斥自建，但是一定要有具体的商业价值，并且最好是在现有工具上的画龙点睛，而不是从头开始构建；其次，工具方面应与具体的场景相关，在不同的场景要使用不同的工具。
4. 尽量不要走平台思路，应以具体的应用和场景为主，因为建一个平台有很多附加的成本和设计，比如，Amazon的云平台是通过至少五年时间构建而成。特别是项目的初期，不建议走平台这个方向，而是应脚踏实地以具体的商业场景为主。
5. 找准切入点，最好是找到一个技术难度小，并且有一定的商业价值的场景来做大数据技术落地的试点，并不断地进行测试和迭代来验证，而不是一味求复杂，求大，这样比较容易说服企业管理层来进行长期地投入和支持；

最后，想和大家说一下，“罗马不是一天建成的”，无论是Google的用于大数据处理的基础设施，还是我们国内淘宝的“云梯”都是一步步通过不断积累和实践而成，所以我们这些中小企业应该贯彻“大处着眼、小处着手”的方针来持续地验证和推进。还有，我们人云科技将于今年上半年发布用于海量结构化数据处理的YunTable，由于其性能指标非常出色，并且已经有正式运行的大型集群，所以请各位朋友敬请期待。

分享

分享

经过最近一年的努力，我们YunTable已经从一个过去基于BigTable的小玩具发展成新一代的分布式数据库，并且能在秒级对十亿行的大表进行快速地分析，现在版本号也从0.9进化为1.0beta, 具体内容可以看一下下文，并且将于本周正式对外提供下载和教学文档，最后感谢大家长期的支持^_^

据美国著名咨询公司IDC的统计，全球数字信息在未来几年将呈现惊人增长，预计到2020年总量将是现在的44倍。据另外一份数据显示，全球 90% 的数据都是在过去两年中生成的，并且每年以50%的速度进行增长，每天，遍布世界各个角落的传感器、移动设备、在线交易和社交网络产生上PB级别的数据，所以说“大数据”时代已不可避免地到来了，并且这些大数据里面蕴含着丰富的价值，而我们人云科技团队从2010年起开发了针对海量结构化数据分析的名为“YunTable”的分布式数据库，最新的版本号为1.0beta，现正处于公开测试阶段，并将于2012年6月正式对外发布1.0正式版，而本文档将会给大家逐步介绍YunTable，包括它的基本功能、核心技术、分布式架构和路线图等。

大数据的处理流程

虽然具体的大数据处理方法其实有很多，并且也有各种不同的场景，但是为了帮助大家理顺大数据的处理，在对YunTable进行介绍之前，在这里给大家总结一下大数据处理的基本流程。

图1. 大数据的处理流程

如图1所示，整个处理流程可以概括为四步，分别是采集、导入和预处理、统计和分析以及挖掘，下面将分别详细地介绍：

采集

利用多个的数据库来接收发自客户端（Web、App或者传感器形式等）的数据，并且用户可以通过这些数据库来进行简单的查询和处理工作，比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。在采集部分，主要特点和挑战方面是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作。

导入/预处理

虽然有采集端本身会有很多数据库，但是如果要对这些海量数据进行有效地分析，还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作，也有一些用户会在导入时候使用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。在特点和挑战方面，主要是导入数据量大，每秒导入量经常达到百兆，甚至GB级别。

统计/分析

统计与分析主要利用分布式数据库或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC 的GreenPlum、Oracle的Exadata以及基于MySQL的列式存储Infobright等，而一些批处理或者基于半结构化的需求可以使用Hadoop。统计与分析这部分，主要特点和挑战方面是分析涉及的数据量大，其对系统资源，特别是I/O会有极大地占用。

挖掘

与前面统计和分析不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，这样实现一些高级别数据分析的需求，比较典型算法有用于聚类的K-Means、用于统计学习的SVM和用于分类的Naive Bayes，主要使用的工具有Hadoop的Mahout等。在特点和挑战方面，主要是挖掘的算法复杂，并且计算涉及的数据量和计算量都很大。

产品简介

YunTable是在传统的分布式数据库的基础上发展而来的新一代分布式数据库，并吸纳了一些来自NoSQL的新技术，其核心技术与著名的Oracle Exadata和SAP HANA类似。通过它能构建一个百台服务器级别的分布式集群来管理PB级别的海量结构化数据。 YunTable最大的特色就是快，它能极快地导入海量的数据，并极快地进行相关的查询、统计和分析；其次是TCO低，整体成本和类似性能的Oracle Exadata和SAP HANA相比低很多。

在大数据的处理流程方面，如图2所示，现阶段，YunTable专注于数据导入、统计和分析这两部分。

图2. YunTable与大数据的处理流程

设计目标

在设计方面，主要是找准专注的点，具体有下面这四点：

1. 主要针对海量结构化数据，并为其做非常彻底的优化；

2. 优化导入数据的性能，以满足非常极限的数据导入要求，比如，每秒整个集群需要导入50多万行数据；

3. 对数据分析相关的SQL语句进行支持和优化，比如支持去重、求和，以及分类汇总等命令；

4. 利用好现有的硬件，无论是CPU、内存、SSD，还是硬盘，都根据它们的特性，发挥它们的性能优势，比如利用多核的优势，以及硬盘顺序读写性能优等特点。

功能特性

在功能特性方面，主要有下面这八点；

l 支持核心的SQL命令：包括Group By、Distinct和Count等；

l 支持百台级别服务器集群：构建耗时短；

l 提供PB级别的数据存储：压缩比平均在1/10左右；

l 提供秒级海量数据处理能力：能在几秒中对海量数据完成大多数SQL指令的执行；

l 每秒百万行级别的数据加载能力：能快速导入海量数据，并支持CSV格式的数据文件；

l 线性扩展：每添加一个节点能提供接近线性的性能提升；

l 数据安全性：采用多备份机制来确保数据的安全；

l 整体成本低：采用普通的X86服务器，无需昂贵的硬件技术；

三大核心技术

图3. 三大核心技术

在上面大数据的处理流程那部分已经提到，对于统计和分析，最大挑战莫过于I/O方面。为了让YunTable更好地提升统计和分析相关的I/O性能，如图3所示，YunTable提供并行处理、行列混合存储和压缩这三个针对海量结构化数据处理和分析的必备利器，因为这样对分析命令而言，I/O处理会实现最优化，而且Oracle Exadata和SAP HANA的优秀性能都基于类似技术的，并能对热数据提供接近内存计算的性能，下面将分别介绍这三个技术：

1. 并行处理：就是将一个来自客户端的查询或请求分配到多个节点上进行并行处理，之后在客户端来接受来自多个节点的返回，并进行合并来产生最终的结果，在导入方面，也可以利用并行机制来加快数据的导入；

2. 行列混合存储：与常见的列式存储不同的是，YunTable会先以行为单位进行分组，之后再进行列式存储，这样做的好处是，在保持传统列式存储分析性能的同时，对部分涉及到行的命令也有一定的支持；

3. 压缩：虽然YunTable本身采用比较经典的压缩算法，但是在具体数据组织方面有一定的设计，使得整体压缩率达到1/10，甚至更高，并且压缩和解压缩的效率也很高。

整体架构

图4. 分布式架构

首先，如图4所示，从分布式架构角度而言，YunTable主要有Client端、Master节点和Region节点这三个组件组成：

l Client端，主要是用于发送命令，现在主要使用基于C的驱动，并将在4月提供基于Python的驱动；

l Master节点，主要用于管理这个集群，并且负责集群中异常事件的处理；

l Region节点，主要用于储存数据，并接受来自Client端的请求来对存储于其内数据的进行查询和分析。

接着，以一个Table为例来进一步介绍YunTable的分布式架构，当Client端向Master节点申请创建一个Table的时候，Master节点会为这个Table创建多个Tablet Group，一个Table的数据会按照一定的分片策略均匀分布到每个Tablet Group中，常用的分片策略为Hash算法。每个Tablet Group会包含多个数据完全一致的Tablet以用于备份，并且它们运行在不同的Region节点上，Tablet具体的数目和其设定的备份策略相关，一般备份数为3。在一个Tablet Group中，Tablet之间有主备份和副备份之分，也就是说，数据会首先写入到主备份，接着主备份会将数据异步发给第一个副备份，之后依次类推。

图5. Region节点的架构

最后，分析一下用于存储和分析数据的Region节点，如图5所示，每个Region会运行和存储多个Tablet，当数据写入的时候，数据会首先写到这个Tablet的WAL日志上，接着会写入至一个位于内存的数据结构Memstore中，WAL全称为“Write-Ahead Log”，主要用于暂存那些最新的数据更新请求，以避免当Tablet中的Memstore被意外关闭时所造成的数据丢失。接着，当Memstore存储的数据达到一定的阀值时，它会将数据整理一下，之后批量写入硬盘，写入格式为YFile。因为YFile本身是不可修改（Immutable）的，所以这样能有效地利用硬盘顺序读性能好的特性。最后，系统会清空WAL日志中那些已经写入的数据。

实际案例

表1. 测试结果

产品比较

表2. 与竞争对手的比较（根据用户的反馈）

路线图

在今后一两年时间中，我们人云科技团队的主要目标还是在于不断地提升YunTable对海量结构化数据的分析能力，下面是今后两年初步的规划：

1. 2012-6 ：推出1.0版，对基于单表的SQL命令提供完整的支持，并提供Python驱动；
2. 2012-7至2012-12：推出2.0版，主要是根据用户的需求，加入更复杂的数据分析和统计功能，并提升与Hadoop的整合或者内置对MapReduce的支持；
3. 2013：推出2.1版，目标是增加用于数据挖掘的功能模块。

服务策略

现阶段的对客户的服务策略是“使用免费，服务收费”，用户现阶段可以免费下载和使用YunTable，同时为了帮助用户部署、使用和维护YunTable，我们人云科技团队提供了基于收费的各项服务和技术支持。

分享

分享

         这是一本描述如何使用硬件描述语言Verilog进行FPGA设计的参考书。按照本书的指导，读者可以设计一个32位的RISC架构处理器—兼容市面上流行的ARM9微处理器。读者在完成RTL编程后，可以在购买的FPGA开发板上运行ARM9兼容的嵌入式程序。
　　使用Verilog HDL进行编程到底属于硬件设计还是软件设计？这是一个很难回答的问题。它处于传统的硬件设计和软件设计的交叉点：描述的对象是硬件，但采用的方法和软件设计类似。市面上充斥着各种介绍Verilog HDL设计的书，但都是以介绍Verilog HDL的语法为主，兼而给出一些简单逻辑的Verilog RTL描述。但没有一本书介绍如何使用这种精简的语言进行成熟作品的设计，本书填补了这方面的空白。
　　一个成功的RTL设计将是价值连城的，譬如ARM公司的系列处理器内核，它们都是采用Verilog等硬件描述语言进行描述设计的，用户如果想使用这些处理器内核，将需要付出昂贵的授权费用。正因为设计出成熟的RTL作品非常难，因此很多书籍对此回避，或者大而化之。好比我们在市面上看到的旅游指南书，都是连篇累牍地介绍该国的地理概貌、风土人情，以及各种介绍数据；但是这样的书籍并不受读者欢迎，而那些由旅游者介绍的各种攻略，由于有旅游者的现身说法，使人读了以后有种身临其境的感觉，受到了读者的热捧。本书尝试做一个Verilog RTL设计攻略的尝试，以流行的RISC处理器为目标，向读者传授编写Verilog程序的第一手的经验和体会。
　　正因为设计出成熟的RTL程序比较难，很多公司的诸位同仁虽然口头上大力宣扬“创新”的重要性，同他交谈简直是口不离“创新”，言不离“变化”，但如果真的要他稍微改改样儿，则反而会认为非常不稳妥。指原因很简单，所谓创新，所谓变化，初期总是不稳定的，总是没有受到时间检验的，能够直接“盈利”的项目是不会稍稍“改样”来做检验创新的实验品的。于是，我们的创新要成长为众人接受的稳态的变化，需要走很长很长的一段路。幸而，在FPGA设计上，可以接受这种创新、这种变化。因为FPGA是可以不断重复可编程的，如同我们练习毛笔字的那种蘸水写的字帖，练完后，等字迹一干，下次再练不受任何影响。也就是说，读者只需要一块FPGA开发板，加上掌握了一定的Verilog RTL设计技巧，你也就和进行最高端的处理器设计的公司，比如ARM、MIPS等公司站在同一条起跑线上，他们能做的，你也能做。
　　处理器设计在我们眼里之所以是那么高不可攀，原因就在于这只是为少数公司所掌握的，并不是为大众所能够掌握的技能。对于RISC处理器，我们都知道三级流水线、五级流水线，但都没有一个生动的例子来显示这三级流水线是如何工作的，是如何协调数据、指令的关系。也许有这样的开源的32位的RISC处理器设计，但都非常复杂，读者要弄懂它们，要花费大量的工夫。而且，市面上最主流的处理器是ARM公司推出的一系列RISC处理器，读者对它们的架构与指令集都有所了解。基于此，作者针对ARM9的指令集与架构，介绍Verilog RTL设计，以便读者了解处理器设计的架构，能够在FPGA上真正运行一个32位的RISC处理器。
　　对于FPGA设计，最重要的是能够在开发板中运行起来。开源的32位RISC处理器开发出来了，它最大的功效是能够帮助FPGA设计者在实际中应用，而不是成为一个展览品，供大家解剖学习。对于本书开发的兼容ARM9微处理器，全部的Verilog RTL描述只有不到1800行代码，存放在一个文件当中。FPGA设计者只需明白设计的I/O接口，即可例化在设计者的设计当中，可以最大化地方便设计者。同时，由于ARM9的开发工具众多，相关的嵌入式软件设计人员也占据了主流，因此，在嵌入式软件资源方面，兼容ARM9处理器的应用会受到这些因素支持。读者在本书中得到了兼容ARM9处理器的Verilog RTL设计后，可以在网络资源以及从事嵌入式软件开发的朋友中得到支持，以在FPGA设计应用中，真正实现完全自我掌握的SoC设计。
　　长久以来，我国的处理器设计水平落后于欧美国家。虽然龙芯在基于MIPS的架构上有所突破，但在更加流行的ARM架构上鲜有建树。众所周知，以Intel为代表的CISC处理器设计所采用的技术高深，设计过程复杂，在后面的追赶者望尘莫及。有些人在看到Intel的高科技设计水平后，自叹弗如，于是对其他人在处理器上的追赶嗤之以鼻。这就好比看见西方人吃西餐礼节繁琐、堂而皇之，于是自惭形秽，觉得还不如不吃饭了。殊不知吃饭不仅有西餐的吃法，而且还有快餐式的KFC、麦当劳式的吃法。ARM和MIPS就好比饮食界的肯德基与麦当劳。他们为业界提供了RISC架构的处理器，这些处理器都是采用硬件可综合语言编写而成的，易于其他芯片设计公司集成。这种设计方式生产简便、灵活快速，深受其他芯片设计公司欢迎。这就好比快餐式的做法，业界一致摒弃了Intel这种西餐式的吃法。读者如果有志于在处理器设计方面进行突破，那么掌握Verilog RTL的设计技巧，对处理器进行钻研，一定会有所拓展。
　　本书以Verilog RTL设计为核心，从第1章建立Verilog RTL设计模型开始，到最后一章能够对Linux操作系统进行仿真。读者通过本书可以切实掌握到基于ARM9的数字电路设计流程，并能够利用成熟的MCU软件设计工具生成BIN文件，通过BIN文件和一个只有1800行代码的兼容ARM9处理器内核，读者能够快速完成FPGA设计。
　　第1章的主要目的是建立Verilog RTL设计的模型。我们知道，进行Verilog RTL设计，必须先具有基本的硬件思维，使得在编写软件式的Verilog代码时，能够时时刻刻警惕自己写的每一行代码都会对应着实体逻辑。这一章会对数字电路的基本模型进行梳理，在这个基础上，我们才能进行复杂逻辑的组织与设计。
　　第2章基于第1章建立的基本模型，采用硬件模型，使用Verilog语言进行基本的电路设计。首先，分析了Verilog这种硬件描述语言的语言特点。它是一种非常类似C的编程语言。针对RTL设计，它只有寥寥的几种格式。正如我们手机上的笔画输入法，正是这三四种格式，经过组合变换，可以写出各种各样复杂的逻辑。在掌握了Verilog RTL的语言特点后，这一章将带领读者进行串口通信的设计。串口通信涉及串行收发数据，是硬件设计中离不开的调试接口。通过该章建立的设计理念，只需寥寥几十行代码就可以设计一个高效的Verilog RTL程序。
　　第3章介绍了Modelsim仿真。Verilog RTL设计第一步的检验是进行仿真。该章建立了仿真的基本流程。读者可以通过编写task函数来定制激励，比如在对UART串口进行仿真时，可以通过一个task函数把并行数据串行发送到RTL设计的输入端口上。
　　第4章介绍了FPGA及FPGA开发板。FPGA是一种奇妙的芯片，它可以模拟各种数字电路的功能—只要我们按照RTL的规则编写了数字电路，FPGA就能很快成为这种功能的芯片。单独的FPGA就如同人的大脑，但如果离开了手臂、腿脚以及眼耳鼻舌等，那再聪明的大脑也不会有所作为。以FPGA为核心的FPGA开发板就如同人脑和人身体结合在一起一样，在我们编写的程序的指导下，FPGA开发板可以实现各种特定的功能。但如果再进一步，把32位的RISC处理器放置于FPGA内部，那么我们指挥“FPGA”的效率就会进一步提高。该章除了对FPGA和FPGA开发板介绍以外，还通过具体的串口通信例子，零实践指导读者对FPGA开发板进行了解。
　　第5章着重介绍了ARM9TDMI这种曾经风靡一时，现在仍发挥着巨大作用的处理器架构。ARM9的嵌入式开发人员应该对ARM9的编程模型了如指掌，特别是系统设计工程师，必须熟悉汇编级的应用，才能对系统进行调试。该章将从设计的角度对微处理器的中断和指令集进行解读。我们看到的介绍ARM9的指令集都是从一条条的汇编指令的角度入手的，但是本书通过指令集的各种指令的结构把它们总结成了20类指令。于是，对第6章提出了一个课题：如何在一个.v文件内实现20条指令和7种中断。
　　第6章是本书的核心，它将结合之前章节讲述的知识点，共同呈现出这只有1800行的ARM9微处理器代码。从RTL的角度看，它是由一条条关于寄存器和组合逻辑的描述组成的；从ARM9的编程模型的角度看，它必须实现ARM9架构的20条指令和7种中断；从处理器流水线的角度来看，它必须在三级执行、五级执行之间进行折中；从FPGA执行的角度来看，它必须适应FPGA的结构，在时序和面积之间折中。可以说，Verilog RTL编程就如同带着镣铐的舞蹈，在受到种种约束的情况下，还要跳出优美的舞蹈。该章将以简为纲，尽量把复杂的东西通过简洁的描述呈现给读者。让读者不仅能够理解它，而且在使用时，也能够很轻易地融入到自己的设计中。
　　第7章介绍了兼容ARM9处理器内核运行的第一个程序—Hello World。在学习C语言时，学习的第一个程序就是输出Hello World。在做好了一个兼容ARM9的处理器设计后，最美妙的事莫过于在开发板中通过串口同样通过C语言描述输出Hello World。现在看看我们具有的元素：FPGA开发板、串口、处理器内核，只要我们通过ARM公司自家流行的RealView MDK以任意一款流行的ARM9 MCU为原型，就可以编写出BIN文件。这些BIN文件在例化入FPGA内的ROM后，它就从死的状态变成活跃的了。我们将看到，这些代码指挥FPGA通过串口输出任何字符串。这一简单的例子将使大家享受到SoC设计带来的乐趣，在以后的FPGA设计中可以尽量使用处理器来简化繁琐的设计流程。
　　第8章介绍了兼容ARM9处理器内核性能测试—Dhrystone Benchmark。我们知道了处理器的功效，但还不知道这款兼容ARM9的微处理器内核的性能如何。本章将延续第7章的SoC设计流程，对这款处理器内核进行体检，以便获得关于它的第一手资料。经过该章的测试后，我们发现，这款兼容处理器内核可以达到1.2 DMIPS/MHz。
　　第9章介绍了uClinux仿真—结合SkyEye，启动不带MMU的操作系统。有了FPGA和处理器内核的结合，本书将具有另外一个主旨，那就是把操作系统引入设计当中。SkyEye作为一款软件模拟处理器的工具，它可以作为我们这款内核的标尺，衡量它运行现代流行操作系统的能力。操作系统虽然复杂，但我们同样可以通过编写一个简单的testbench的方式，结合1800行代码构成的处理器内核，让这款操作系统也能在Modelsim中运行。经过仿真，可以看到，它可以输出同SkyEye同样的log信息。硬件工程师通过该章同样可以了解到MCU的构成。
　　第10章介绍了Linux操作系统—结合mini2440开发板，启动带MMU的嵌入式操作系统。在该章中，读者可以看到开发ARM9兼容处理器内核的优势：它能够得到的帮助实在是太多了。我们不仅有软件模拟器，而且还有市面上极为流行的ARM9开发板。通过开发板，我们可以看到Linux操作系统启动起来，现在，通过编写一个tb文件，我们同样能够在Modelsim中再现ARM9处理器是如何启动Linux操作系统的。本书不同于其他只是介绍性质的书籍，通过实际的仿真步骤，我们能够清晰地理解Linux操作系统是如何与处理器内核结合在一起的。
　　最后，本书附录提供了带有注释的兼容ARM9处理器内核的Verilog RTL描述。读者可以在这1800行的代码中体会Verilog RTL编程的巧妙之处，以便融会贯通，应用在自己的设计当中。如果能够在设计中应用这款处理器内核，那将是笔者最大的欣慰。

分享