1.5.4　大数据处理模型

按照数据的三状态定义，水库里一平如镜（非活跃）的水是“静止数据（data at rest）”，水处理系统中上下翻动的水是“正使用数据（data in use）”，汹涌而来的新水流就是“动态数据（data in motion）”。 “快”说的是两个层面：

（1）“动态数据”来得快。动态数据有不同的产生模式。有的是“爆发（burst）”模式，极端的例子如欧洲核子研究中心（CERN）的大型强子对撞机（Large Hadron Collider，LHC），此机不撞则已，一撞惊人，工作状态下每秒产生PB级的数据。也有的动态数据是涓涓细流的模式，典型的如clickstream、日志、RFID数据、GPS位置信息和Twitter的firehose流数据等。

（2）对“正使用数据”处理得快。水处理系统可以从水库调出水来进行处理（“静止数据”转变为“正使用数据”），也可以直接对涌进来的新水流处理（“动态数据”转变为“正使用数据”）。这对应着两种大相迥异的处理范式：批处理和流处理。如图1-5所示，左半部是批处理：以“静止数据”为出发点，数据是任尔东西南北风、我自岿然不动，处理逻辑进来，算完后价值出去。Hadoop就是典型的批处理范式：HDFS存放已经沉淀下来的数据，MapReduce的作业调度系统把处理逻辑送到每个节点进行计算。这非常合理，因为搬动数据比发送代码更昂贵。右半部则是流数据处理范式。这次不动的是逻辑，“动态数据”进来，计算完后价值留下，原始数据加入“静止数据”，或索性丢弃。流处理品类繁多，包括传统的消息队列（绝大多数的名字以MQ结尾）、事件流处理（Event Stream Processing）、复杂事件处理（Complex Event Processing，CEP）（如Tibco的BusinessEvents和IBM的InfoStreams）、分布式发布/订阅系统（如Kafka）、专注于日志处理（如Scribe和Flume）、通用流处理系统（如Storm和S4）等。

这两种范式与人们日常生活中的两种信息处理习惯相似：有些人习惯先把信息存下来（如书签、To Do列表、邮箱里的未读邮件），稍后一次性地处理掉（也有可能越积越多，旧的信息可能永远不会处理了）；有些人喜欢任务来一件做一件，信息来一点处理一点，有的直接过滤掉，有的存起来。没有定规说哪种范式更好，对于批量数据，多数是先进入存储系统，然后再来处理，因此以批处理范式为主；而对于流数据，多采用流范式。传统上认为流处理的方式更快，但流范式能处理的数据常常局限于最近的一个数据窗口，只能获得实时智能（Real-time Intelligence），不能实现全时智能（All-time Intelligence）。批处理擅长全时智能，但处理大数据肯定慢，所以需要批处理加速。两种范式常常组合使用，而且形成了一些定式：

（1）流处理作为批处理的前端：比如大型强子对撞机，每秒PB级的数据先经过流处理范式进行过滤，只有那些科学家感兴趣的撞击数据保留下来进入存储系统，留待批处理范式处理。这样，欧洲核子研究中心每年的新增存储量可以减到25PB。

（2）流处理与批处理肩并肩：流处理负责动态数据和实时智能，批处理负责静止数据和历史智能，实时智能和历史智能合并成为全时智能。

那么，如何实现“快”的数据处理？首先，“快”是个相对的概念，可以是实时，也可以秒级、分级、时级、天级甚至更长的延迟。实现不同级别的“快”采用的架构和付出的代价也不一样。所以，对于每一个面临“快”问题的决策者和架构师来说，第一件事情就是要搞清楚究竟要多“快”。“快”无止境，找到足够“快”的那个点，那就够了。其次，考虑目前的架构是不是有潜力改造到足够“快”。很多企业传统的关系型数据库中数据量到达TB级别，就慢如蜗牛了。在转向新的架构（如NoSQL数据库）之前，可以先考虑分库分表（Sharding）和内存缓存服务器（如Memcached）等方式延长现有架构的生命。如果预测未来数据的增长必将超出现有架构的上限，那就要规划新的架构了。这里不可避免要做出选择，或者选择流处理结构，或者选择批处理结构，当然也可以选择两者兼具。Intel有一位咨询师说：any big data platform needs to be architected for particular problems（任何一个大数据平台都需要为特定的问题量身定做）。这是非常有道理的。为什么呢？比如说大方向决定了要用流处理架构，落实到具体产品少说有上百种，所以要选择最适合的流处理产品。再看批处理架构，MapReduce也不能包打天下，碰到多迭代、交互式计算就无能为力了；NoSQL更是枝繁叶茂，有名称的NoSQL数据库好几十种。这时候请一个好的大数据咨询师很重要，让他帮助企业选择一个量身定制的大数据解决方案。总体上讲，还是有一些通用的技术思路来实现“快”。

如果数据流入量太大，在前端就地采用流处理进行即时处理、过滤掉非重要数据。把数据预处理成适于快速分析的格式。预处理常常比较耗时，但对不常改动的惰性数据，预处理的代价在长期的使用中可以被分摊到很小，甚至可以忽略不计。谷歌的Dremel就是把只读的嵌套数据转成类似于列式数据库的形式，实现了PB级数据的秒级查询。

增量计算即先顾眼前的新数据，再去更新老数据。对传统的批处理外国专家称为reboil the ocean，每次计算都要把所有数据处理一遍，自然快不了。而增量计算把当前重点放在新数据上，先满足“快”；同时抽空把新数据（或新数据里提炼出来的信息）更新到老数据（或历史信息库）中，又能满足“全”。谷歌的Web索引自2010年起从老的MapReduce批量系统升级成新的增量索引系统，能够极大地缩短网页被爬虫爬到和被搜索到之间的延迟。前面说的“流处理和批处理肩并肩”也是一种增量计算。

很多批处理系统慢的根源是磁盘和I/O，把原始数据和中间数据放在内存里，一定能极大地提升速度。这就是内存计算（In-memory Computing）。内存计算最简单的形式是内存缓存，Facebook超过80％的活跃数据就在memcached里。比较复杂的有内存数据库和数据分析平台，如SAP的HANA，NewSQL的代表VoltDB和伯克利的开源内存计算框架Spark（Intel也开始参与）。斯坦福的John Ousterhout（Tcl/Tk以及集群文件系统Lustre的发明者）开发了一个更超前的RAMCloud，号称所有数据只生活在内存里。未来新的非易失性内存（断电数据不会丢失）会是个游戏规则改变者。Facebook在2013年3月宣布了闪存版的Memcached，叫McDipper，比起单节点容量可以提升20倍，而吞吐量仍能达到每秒数万次操作。另一种非易失性内存——相变内存（Phase Change Memory），在几年内会商用，它的每比特成本可以是DRAM的1/10，性能是DRAM的1/10～1/2，比现今的闪存（NAND）快500倍，寿命长100倍。除内存计算外，还有其他的硬件手段来加速计算、存储和数据通信，如FPGA（IBM的Netezza和Convey的Hybrid-Core），SSD和闪存卡（SAP HANA和Fusion IO）、压缩PCIe卡、更快和可配置的互联（Infiniband的RDMA和SeaMicro SM15000的Freedom Fabrics）等。此处不再细讲。

降低对精确性的要求。大体量、精确性和快不可兼得，顶多取其二。如果要在大体量数据上实现“快”，必然要适度地降低精确性。对数据进行采样后再计算就是一种办法，伯克利的BlinkDB通过独特的优化技术实现了比Hive快百倍的速度，同时能把误差控制在2％～10％。

1.流处理

大数据的应用类型很多，主要的处理模式可以分为流处理（Stream Processing）和批处理（Batch Processing）两种。批处理是先存储后处理（Store-then-Process），而流处理则是直接处理（Straight-through Processing）。流处理的基本理念是数据的价值会随着时间的流逝而不断减少。因此，尽可能快地对最新的数据做出分析并给出结果是所有流数据处理模式的共同目标。需要采用流数据处理的大数据应用场景主要有网页点击数的实时统计、传感器网络、金融中的高频交易等。流处理的处理模式将数据视为流，源源不断的数据组成了数据流。当新的数据到来时就立刻处理并返回所需的结果。图1-6所示为流处理中基本的数据流模型。

数据的实时处理是一个很有挑战性的工作，数据流本身具有持续达到、速度快且规模巨大等特点，因此通常不会对所有的数据进行永久化存储，而且数据环境处在不断的变化之中，系统很难准确掌握整个数据的全貌。由于响应时间的要求，流处理的过程基本在内存中完成，其处理方式更多地依赖于在内存中设计巧妙的概要数据结构（Synopsis Data Structure），内存容量是限制流处理模型的瓶颈。以PCM（相变存储器）为代表的SCM（Storage Class Memory，储存级内存）设备的出现或许可以使内存未来不再成为流处理模型的制约。数据流的理论及技术研究已经有十几年的历史，目前仍旧是研究热点。与此同时很多实际系统也已开发和得到广泛应用，比较代表性的开源系统如Twitter的Storm、Yahoo的S4以及Linkedin的Kafka等。

2.批处理

Google公司在2004年提出的MapReduce编程模型是最具代表性的批处理模式。一个完整的MapReduce过程如图1-7所示。

MapReduce模型首先将用户的原始数据源进行分块，然后分别交给不同的Map任务区处理。Map任务从输入中解析出Key-Value对集合，然后对这些集合执行用户自行定义的Map函数得到中间结果，并将该结果写入本地硬盘。Reduce任务从硬盘上读取数据之后，会根据key值进行排序，将具有相同key值的组织在一起。最后用户自定义的Reduce函数会作用于这些排好序的结果并输出最终结果。

从MapReduce的处理过程可以看出，MapReduce的核心设计思想在于：①将问题分而治之；②把计算推到数据而不是把数据推到计算，有效地避免数据传输过程中产生的大量通信开销。MapReduce模型简单，且现实中很多问题都可用MapReduce模型来表示。因此，该模型公开后，立刻受到极大的关注，并在生物信息学、文本挖掘等领域得到广泛应用。

无论是流处理还是批处理，都是大数据处理的可行思路。大数据的应用类型很多，在实际的大数据处理中，常常并不是简单的只使用其中的某一种，而是将二者结合起来。互联网是大数据最重要的来源之一，很多互联网公司根据处理时间的要求将自己的业务划分为在线（Online）、近线（Nearline）和离线（Offline），比如著名的职业社交网站LinkedIn。这种划分方式是按处理所耗时间来划分的。其中在线的处理时间一般在秒级，甚至是毫秒级，因此通常采用上面所说的流处理。离线的处理时间可以以天为基本单位，基本采用批处理方式，这种方式可以最大限度地利用系统I/O。近线的处理时间一般在分级或者时级，对其处理模型并没有特别的要求，可以根据需求灵活选择。但在实际中多采用批处理模式。