作者：(美)埃利斯(Ellis,B.)
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
实时分析：流数据的分析与可视化技术试读：
前言
概述及组织结构流数据处理涉及软件开发和工程领域的许多不同问题。一方面，它需要一个灵活的基础架构，能够迅速便捷地移动数据；另一方面，处理速度要“跟得上”数据采集的速度，还要能扩展，以适应源源不断的数据流，由于这个限制，流数据处理很青睐从其他领域借鉴而来的数据结构。最后，一旦数据采集和处理完毕，应该利用数据做些什么？对于这一点，有一批可以直接在流数据上运行的应用，这些应用已经在大多数相关企业中发挥作用，还有更多的应用一直处于企业的考虑之中。本书将流数据的所有这些方面糅合在一起，既可以充当大众读者的入门书籍，又对更专业的技术人员有参考价值。我们希望，通过阅读本书，你能够建立足够的自信，在企业中从头到尾实施一个流数据的概念验证项目，并尝试将其应用到生产环境。为了实现以上目标，不仅需要建立基础架构，还需要实现相关算法，为此我们将本书划分为两个独立的部分。
第一部分介绍流数据系统本身的基础架构，以及系统的运营问题。如果数据是流式的，但是仍然以批量的方式处理，那就不再是流数据，这些只是碰巧连续采集得到的批量数据，这样的数据对许多用例完全够用。但是，本书的假设是，人们已经认识到，如果数据生成后不久就可以由最终用户使用，这样会大有裨益。鉴于此，本书涵盖了完成这种任务所需要的工具和技术。
我们首先介绍流框架底层的概念和特性，包括流处理系统的各种组件。并不是所有项目在起始阶段都会用到这些组件，但所有成熟的流基础架构最终都会用到它们。然后我们在流基础架构的关键特性，即可用性、可扩展性和延迟的背景下讨论这些组件。
第一部分剩下的内容聚焦于实现或配置每个组件的具体细节。由于组件框架的广泛应用，多半已经不需要编写多少代码来实现组件。取而代之的是安装、配置，或者定制工作。
第3章和第4章介绍构建和协调数据移动系统所需要的工具。根据所处环境的不同，可能需要开发软件来直接与该系统集成，或者修改已有软件使之适应该系统。我们将讨论这两种途径的利弊。
数据一旦被移动，就必须得到处理，并最终存储起来。这是第5章和第6章的内容。这两章介绍主流的流处理软件，以及对数据存储系统的选择。
第二部分用流基础架构解决各种问题。仪表板与预警系统是流数据采集最早的应用，也是第二部分介绍的第一个应用。
第7章讨论从流环境向最终用户的数据交付问题。这是构建仪表板以及其他监控应用所使用的核心机制。一旦交付，数据就必须呈现给用户，因此，该章还包括一节内容，专门讨论如何在基于Web的环境中建立仪表板可视化。
当然，所交付的数据经常要由处理系统进行聚集计算。第8章涵盖流环境下的数据聚集计算问题，特别是对多分辨率时间序列数据的聚集计算问题，该结果数据最终会被交付给第7章讨论的仪表板应用。
对数据进行聚集计算之后，数据中有什么样的模式这个问题就浮出了水面。是否有随时间变化的趋势？某个行为是否与先前观察到的行为有明显不同？要回答这些问题，需要一些统计学和随机过程方面的知识（一般来讲，这两方面的知识可以解答关于大规模数据采集的任何问题）。第9章对统计学和概率论的基础知识进行了简要介绍。其中还介绍了统计抽样的概念，它可以用来计算比简单的聚集更加复杂的度量。
抽样是对复杂度量进行近似的传统机制，但我们还可以通过其他机制更好地计算某些度量，略图（sketch）概率数据结构就是这样的一种机制。第10章将讨论略图，这需要大量使用第9章的概率论知识。略图通常具有更快的更新速度并占用更少的内存，因此特别适合流环境。
最后，第11章讨论聚集计算之外能够应用于流数据的一些更深入的话题。篇幅所限，这一章仅对所涉及的众多话题作简要介绍，实际上每个都可以单独成书。第一个话题是来自统计学和机器学习领域的流数据模型。这些模型是预测等许多应用的基础，用来估计未来的数据值。由于数据是流式的，可以将这些预测值与实际值相比较，据此再对模型进行修正。预测的应用很广泛，其中包括第11章中讨论的异常检测。
第11章还简要介绍优化和A/B测试。如果你可以预测用户对两个不同网站设计的反应，就可以利用这些信息，向用户展示具有较好预期反应的网站设计。当然，预测并不是完美的，也有可能对各个网站的设计效果给出糟糕的估计。要改进对特定网站设计的预测，唯一途径是收集更多的数据。这样，你就需要确定各网站设计要多久展示一次，从而保证在改进预测的同时，不会由于展示了非主流的设计，而牺牲展示效果。第11章给出一种常用于解决这类问题的简单机制，称为多臂赌博机（multi-armed bandit）。利用这种机制，你可以站在一个比较高的起点上对优化问题进行更深入探索。本书面向的读者
我们曾在开篇提到过，本书意在吸引从事软件行业的广大读者，针对的是有兴趣开始涉足流数据及其管理的技术人员。正因如此，我们希望读者按顺序阅读，最终可以全面掌握流数据分析的基础知识。
即便如此，对于只熟悉这个领域的一部分内容，而对其他部分不甚了解的专家来说，本书也是值得一看的。例如，数据分析师或数据科学家可能在第9章和第11章的统计学方法方面有很强的专业背景，也可能对第7章的仪表板应用以及第8章的聚集计算技术有一定的经验，但对第10章的概率数据结构可能没有太多了解。如果不是要实际实现基础架构，而是想理解对设计的权衡是怎样影响所分析的数据的交付的，他们也可能会对前六章感兴趣。
与之类似，关注运营和基础架构方面的读者可能对第1~6章所讨论的话题颇有了解。他们可能没有接触过特定的软件，但肯定处理过许多类似的问题。本书第二部分，即第7~11章可能对他们更有吸引力。系统监控是流数据的首批应用之一。异常检测这样的工具可以在诸如健壮的错误检测机制这样的开发中派上用场。需要的工具
不管你喜欢与否，数据基础架构领域大多以Java虚拟机为基础。这里的原因比较复杂，但不管怎样，它始终是本书所需要的工具。本书中使用的软件和示例是基于Java 7开发的，通常也可以支持Java 6或Java 8。读者应确保操作系统安装了合适的Java开发工具包。
由于要使用Java，有必要安装一个编辑器。本书中的软件是用Eclipse编写的，项目也是用Maven构建系统来组织的。安装这两个软件将帮助你构建本书包含的示例。
本书也使用了其他软件包，具体安装方法会在相应的章节中讲到。
书中使用了一些基础的数学术语和公式。如果你的数学知识有些生疏，觉得这些概念有点难，Sheldon Ross的《A First Course in Probability》会对你有所帮助。配套网站
本书配套的网站中包含了每一章所有例子的代码包。每章的代码都划分成独立的模块。
有的代码在多章中共用。这种情况下，代码被复制到每个模块，以保证这些模块是自包含的。
网站还包含Samza源代码的拷贝。Samza是一个新兴的项目，其代码库更新很快，这导致在编写和编辑相关章节的时候，本书中的示例可能已经难以运行。为了避免对读者造成困扰，我们在网上放了一个能与本书中代码良好兼容的项目版本。请参考http://www.wiley.com/go/realtimeanalyticsstreamingdata。扬帆起航
闲话少说，是时候踏上实际构建流数据系统的精彩旅程了。本书所讲的技术虽不是流数据处理的独门秘籍，但却都是我付出多年心血摸索出来的经验。我个人认为这些技术都非常好用，虽然在这个激动人心的时代，新事物始终会层出不穷。不管怎样，我希望，通过阅读这本书，你至少能少走弯路。
去找一些数据，让我们扬帆起航。致谢
在写这本书之前，每当在致谢部分看到“有太多要感谢的人”这句话，我都觉得是陈词滥调。现在我才明白，这样的话真的是发自肺腑。对于这本书，我确实有太多需要感谢的人，实在难以在这里对他们一一列举。
不过，我还是要为其中一些人的贡献专门致谢，尽管他们有的人未必知道这本书。第一个当然是Wiley出版社的Robert Elliot，他欣赏我的演讲并认为可以写成一本近400页的书。没有他，就没有本书的面世。我还要感谢Justin Langseth，他是我那次演讲的合作者，很遗憾他没有能与我合作编写本书。希望我们还有机会再次合作。还应该感谢由Kelly Talbot领导的编辑，Charlotte、Rick、Jose、Luke和Ben，是他们帮助我找到和纠正了许多错误，使项目始终按计划推进。如果书中还有什么错误，那绝对是我的问题。
我要感谢DDG所有的常客，本书中的软件至少有一半，甚至可能超过80%，都是我端着啤酒杯聊天得来的。对于一个非正式的松散聚会，这真的很值得。感谢Mike第一个邀请我一同前往，感谢Matt和Zack这些年来举办这么多活动。
最后，我要感谢我这些年来的同事们。应该为你们忍受我各种轻率计划和笨拙补救颁发奖牌。特别感谢adBrite的全体成员，我们一起做出了许多很酷的东西，这些东西仍然处于领域的前沿。感谢Caroline Moon，允许分析人员使用新奇的“Hadoop”，以及收集更多的服务器。特别感谢Daniel Issen和Vadim Geshel。我们并不是经常看法一致（可能仍然无法做到），但本书的内容很多都来源于我与他们两人的争论。作者简介
Byron Ellis是Spongecell公司的CTO，该公司是一个总部位于纽约的广告技术公司，在旧金山、芝加哥和伦敦设有办事处。他负责公司的研发和计算基础设施的维护工作，在加盟Spongecell之前，他是在线交互技术“领头羊”企业Liveperson公司的首席数据科学家。他还在当时世界最大的广告交换公司之一adBrite担任过多项职务。他拥有哈佛大学统计学博士学位，攻读博士学位期间主要研究高吞吐量生物学实验数据中网络结构的学习方法。技术编辑简介
Jose Quinteiro有20年技术经验，参与过许多终端用户、企业、Web软件系统和应用的设计与开发工作。他对于包括前后端的设计和实现在内的全套Web技术有着丰富经验。Jose在威廉玛丽学院获得化学学士学位。
Luke Hornof拥有计算机科学博士学位，曾参与创建了多个成功的高科技初创企业。他在编程语言方面发表了十多篇同行评审的论文，曾为微处理器、广告和音乐行业开发过商用软件。他目前的兴趣之一是使用数据分析技术来改善Web和移动应用。
Ben Peirce在Spongecell广告技术公司负责研究工作和基础设施的管理。加盟Spongecell之前，他在医疗健康技术初创企业担任过多项职务，他还是SET Media公司的联合创始人之一，该公司是一个视频广告技术公司。他在哈佛大学工程与应用科学学院获得博士学位，研究方向是控制系统和机器人。第1章流数据简介
当今世界每天都在以更快的速度发展。人和地区之间的联系越来越紧密，人员和企业的反应速度也越来越快。这越来越接近于人类反应能力的极限，因此人们创建了一些工具处理决策者面临的海量数据，分析、展现这些数据，并在事件发生的时候及时做出反应。
这些数据的采集和处理有许多应用领域，其中某些领域将在下一节介绍。我们将在本章后面讨论这些应用。这些应用需要一个专门针对流数据的基础架构和分析方法。幸运的是，与以前的批处理类似，流基础架构的最新技术关注于使用商用硬件和软件来构建系统，而不是像互联网时代之前那样使用专用的实时分析系统。这样的系统与基于云的灵活环境结合在一起，使得实时系统的实现对几乎所有企业都变得触手可及。利用这些商用系统，企业能够实时分析数据，并且能随着时间的推移对基础架构加以扩展，以满足企业未来发展和变革的需求。
本书面向广泛的大众读者以及企业的技术实现人员，目的是使他们能够轻松应对全栈应用。当实时项目进入某个阶段时，它们应该成为易于修改的、敏捷且自适应的系统，这需要用户除了了解所关注的领域，还要对全栈应用有清晰的整体理解。“实时”不仅针对数据本身，对于新的分析任务的开发也同样适用。许多原来规划良好的项目之所以失败了，是因为项目的实现耗时太久，导致项目发起人转而从事其他项目，或者干脆忘记了当初为什么需要这些数据。通过让项目变得敏捷和可递增，就可以尽可能地避免这种情况。
本章划分为三小节，分别对应三部分内容。第一节介绍一些常见的流数据来源和应用。这部分内容基本上按照时间先后排序，并对流数据基础架构的起源给出了一些背景介绍。这个介绍不仅具有历史意义，更重要的是，其中介绍了当初开发的许多工具和框架，用来解决这些领域中的问题，其设计反映了它们当时所处领域的一些独特挑战。例如，第4章中介绍的数据移动工具Kafka就被开发作为Web应用工具，而第5章中涉及的处理框架Storm，起初就是由Twitter开发，用于处理社交媒体数据的。
第二节涵盖流数据三个重要特性：持续数据交付、松散结构数据和高基数（high-cardinality）数据集。第一个特性当然是将系统定义为实时流数据环境的首要特性。其他两个特性尽管并不是流数据所特有的，却为流数据应用的设计者带来了独特的挑战。这三者一起构成了本质意义上的流数据环境。
第三节简要介绍对流数据使用基础架构和算法的重要性。1.1 流数据的来源
流数据的来源多种多样，这一节只介绍一些主要的数据类别。尽管出现了越来越多的数据来源，也会有许多专用的数据来源，本节还是只讨论令流数据受到关注的应用领域中的数据类别。我们主要按照时间先后对这些应用领域排序。对书中讨论的软件追根溯源，它们中很多都是在解决这些特定应用领域中的问题时产生的。
书中给出的数据移动系统，刚开始是为LinkedIn、Yahoo！和Facebook的网站分析与在线广告处理数据。设计这样的处理系统是为了应对Twitter和LinkedIn这样的社交网络所带来的社交媒体数据处理的挑战。
Google公司的商业帝国与在线广告息息相关，它们大量使用的高级算法与第11章中的算法异曲同工。Google对一项名为深度学习的技术特别感兴趣，该技术利用超大规模神经网络来学习复杂模式。
通过使物联网以及其他高度分布式的数据采集手段经济可行，这些系统甚至正在开辟数据采集和分析的全新领域。我们希望，通过对以往应用领域的勾勒，能够对这些技术尚未预见的应用有所启示。1.1.1 运行监控
实体系统的运行监控是流数据最初的应用。刚开始是用专用硬件和软件来实现的（在计算机时代之前，甚至是用模拟和机械系统）。当今最常见的运行监控的用例就是对为互联网提供动力的实体系统进行性能监视。
这些数据中心有几千个甚至数万个独立的计算机系统。这些系统持续不断地记录自己的物理状态数据，包括处理器温度、散热风扇的转速，以及消耗的电量。它们还记录磁盘驱动器状态信息和基础的运维度量，如处理器负载、网络活动，以及存储访问时间。
为了对所有这些实体系统进行监控，并及时发现问题，数据通过各种机制实时采集和聚集。刚开始的系统往往是专门的特殊机制，但是当这类技术开始应用于其他领域时，这些系统就开始使用与其他数据采集机制相同的采集系统了。1.1.2 Web分析
通过电子商务和在线广告引入的商用化Web，引发了对网站行为的监控需求。与报纸的发行量类似，一天之中某个网站的不同访问者数量是重要的信息。对电子商务网站而言，与网站访问的人数相比，更重要的数据是人们浏览的各种商品以及这些商品之间的相互关系。
为了分析这些数据，许多专门的日志处理工具被研发出来，并推向市场。随着大数据以及Hadoop等工具的兴起，许多Web分析的基础架构转变为这类大规模批处理系统，用来实现推荐系统以及其他分析任务。显而易见，还可以通过对网站的结构进行实验，来看它们如何影响我们感兴趣的各种度量。这称为A/B测试，因为它采用与验光师确定最好搭配方案时相同的方法，即让两个选择相互对比来确定哪一个最好。这些测试多数是顺序进行的，但这存在许多问题，其中最重要的问题是进行对比研究所需要的时间量。
随着越来越多的企业挖掘其网站数据，对缩减反馈环节的时间，以及以持续不断的方式采集数据的需求愈发重要。使用系统监控领域的工具，使得实时采集数据和执行A/B测试这样的任务得以并行，而不再需要顺序执行。随着度量维数以及对适当审计的需求（缘于用于计费的度量）的增加，数据分析领域开发了本书提到的许多流基础架构，将数据从分散在世界各地的网站服务器安全地移动到处理和计费系统中。
尽管这类数据通常位于企业内部而不公开，它们仍然是广泛的海量信息来源。其应用范围从用于计费的简单聚集，到用于根据当前浏览历史（在Netflix公司则是影片观看历史）对产品推荐的实时优化。1.1.3 在线广告
实时数据的主要用户和主要来源之一就是在线广告。在线广告的最初形式与对应的印刷广告类似，都是提前几个月“购买”。随着广告交换和实时竞价基础架构的兴起，广告市场中很大一部分流量更具流动性，并且这部分流量始终在不断增长。
对于这些应用来说，在不同环境和不同网站上所花费的资金是以按分钟计费的方式管理的，这与股票市场几无二致。另外，这些广告购买需求经常以某种度量进行管理，例如购买数量（称为转化（conversion））甚至是某个广告的点击率这样更简单的度量。当访问者通过现代的广告交换进入网站，就会有许多竞价代理（每次可能有30或40个）被调用，它们实时地对页面点击量进行竞价。竞拍过程结束后，竞价获胜一方的广告就会被显示出来。这通常在加载页面其他部分的时候发生，所花费的时间一般不超过100毫秒。如果页面包含多个广告（这很常见），经常会对所有这些广告进行竞拍，有时会涉及多个不同的广告交换。
这个过程中所有的参与方，包括广告交换、竞价代理、广告客户和广告发行商，都会为了各自不同的目的实时采集数据。对于广告交换来说，数据是竞价过程的关键部分，同时对于实时反馈机制也很重要，这种机制用途广泛。例如对欺诈流量交易的监控，以及限制对各参与方广告显示的访问等其他风险管理活动。
广告交换双方的广告客户、广告发行商和竞价代理也都实时采集数据。他们的目标是管理和优化当前运行的竞价活动。从竞价的选择（如果是广告客户）或者“保留”价格（广告发行商），到决定对某个特定类型的流量哪个广告交换的价格最好，数据都是以分秒必争的方式管理的。
一个大型的广告活动或大规模网站可以轻松拥有几千万甚至几亿的页面点击量。如果将点击和转化等其他事件包括在内，事件的数量可以轻易翻番。一个竞价代理通常一次性代表许多不同的广告客户或广告发行商，因此每天采集到几亿到几十亿量级事件的情况很常见。即使是中等规模的广告交换，中间方每天也可以有几十亿的事件。所有这些数据一旦生成，都会被采集、移动、分析和存储。1.1.4 社交媒体
另一种新近的海量数据来源是社交媒体，特别是像Twitter这样的开放数据来源。截至2013年年中，Twitter声称每天能采集到50亿条推文，每秒15万条左右。这个数字当然还会不断上升。
这些数据被实时采集和传播，成为新闻媒体和全世界其他用户的重要信息来源。在2011年，纽约的Twitter用户收到华盛顿特区传出的发生地震的消息，大约30秒后地震才波及纽约。
加上Facebook、Foursquare，以及不断涌现的各种通信平台等其他数据来源，社交媒体数据就显得极度庞大和多样。来自Web分析和在线广告这类应用的数据尽管具有很高的维度，但一般具有良好的结构，每一维上的数据（例如投资金额或地理位置）都是很好理解的定量数值。
然而，社交媒体数据通常是高度非结构化的，至少数据分析人员是这样理解的。这类数据通常是“自然语言”形式，必须由自动化的系统来解析、处理并以某种方式理解。这使得社交媒体数据尽管极为丰富，同时作为实时数据来源，其处理又极具挑战性。1.1.5 移动数据和物联网
2007年苹果公司发布了iPhone，一个最激动人心的新数据来源也随之横空出世。虽然可以存储蜂窝数据的便携式计算机已经存在至少十年之久，类似于黑莓手机这样的设备也使商业用户可以在手掌上处理数据，但是这些设备本质上仍然是专门工具，其管理也是专门化的。
IPhone、Android手机以及其后的其他智能手机，使得蜂窝数据成为消费技术，用户数量激增所带来的规模经济也就随之而来。智能手机还使得我们口袋里都装上了一个通用计算机。智能手机不仅能够向在线服务反馈数据，还能使用低功耗蓝牙这样的技术与附近的设备通信。
得益于这种新的基础架构，类似于“可穿戴计算机”这样的技术，使得我们可以用与以往二十年间测量虚拟世界同样的方式测量现实世界。这类技术的应用有的荒唐可笑，有的则很有用，有的甚至有点吓人。试想一下，当用户晚上睡眠不好，第二天需要提神时，测量睡眠活动的手环可以触发自动咖啡壶。冲泡咖啡的味道甚至可以用作起床闹钟。这些系统间的通信不必像过去50年间各种“智能家居”演示项目所设想的那样直接或专门化。今天，使用If This Then That（IFTTF）这样的工具，以及建立在与本书相似的基础架构之上的公开可得的系统就可以实现这些工具。
言归正传，我们可以通过远程设备实时测量重要的生物特征数据。以前这只有使用高度专门化的昂贵设备才做得到，因此限制了这类数据只能在太空探索这样高度紧张的环境中应用。现在可以长时间采集个人的生物特征数据（在统计学里这称为纵向数据（longitudinal data）），然后将其与其他用户的数据合并在一起，从而得到人类生物特征识别标准的更加完整的图谱。我们不再需要每年一次，让病人在冰冷的房间穿着纸质衣服测量血压，而是可以在一段时间内持续跟踪他的血压，从而做到防患于未然。
除了医疗卫生领域，“智能微尘”的概念也由来已久，“智能微尘”是指通过对散布在世界的某个区域的数量众多的廉价传感器进行远程查询，来采集有意义的数据。这些设备的局限性主要是，制造这些相对专门的设备所耗费的成本。随着数据采集硬件和软件（如智能手机）的商业化，这个问题得到了解决，物联网也就应运而生。使用这类技术，不仅人们可以对自己进行持续监控，物体也可以对自身进行持续监控。这有着各种各样的潜在应用，例如城市交通管理，以及通过更好地监控土壤条件来提高农业生产效率。
上述讨论的重点在于，现在信息可以通过商业化系统来流动，而不是像以前那样通过专门的数据采集硬件和软件。这些商业化系统都是可以买到的，分析数据所需要的软件也是现成的。需要开发的只有采集数据的新型应用而已。1.2 流数据的特别之处
流数据与其他类型的数据区别包括多个方面。本节涵盖了最重要的三个方面，分别是数据的“始终在线”属性、松散且不断变化的数据结构和高基数带来的挑战。在对本书中给出的各种流框架设计和实现的决策中，所有这三方面都起到重要作用。流数据的这些特性尤其会影响第5章中介绍的数据处理框架，在数据移动工具的设计决策上也会有所体现，即对于经过它们的系统的信息，有意不强加数据格式，从而使灵活性最大化。本节剩下的内容会对这三个方面做更深入的介绍，为你进入第2章（介绍流架构的组件和需求）提供一些背景知识。1.2.1 始终在线，持续流动
第一个方面有些显而易见：数据流是流式的。数据始终可得，新数据不断生成。这对于任何采集和分析系统的设计都有些许影响。首先，采集系统本身要有非常好的健壮性。主要的采集系统一旦宕机，就意味着数据永久丢失。在设计边缘采集器时，这一条非常重要，你应该牢记于心。第2章会对此做更详细的讨论。
其次，数据是持续流动的这一事实意味着系统的处理要能够跟得上数据的流动速度。如果需要2分钟才能处理1分钟的数据，系统就无法长时间保持实时。最终情况会糟糕到不得不丢弃一些数据让系统的处理跟上来。在实际情况中，系统仅仅能实时地“跟上”数据是不够的。因为无论是按计划停机这样的人为原因，还是网络中断这样的灾难性故障，系统都会因此全部或者部分宕机。
如果没有为这种无法避免的情况提前计划，导致系统的处理速度只能与事件产生速度相同，这就意味着系统宕机时，采集器存储的数据会导致系统产生延迟。换句话说，能够在1分钟内处理1小时数据的系统，不需要太多干预就能够很快跟上。一个有着很好的水平可扩展性的成熟环境（第2章中也会讨论这个概念）甚至能够实现自动扩展。在这种情形下，随着延迟的增加，会临时加入更多的处理能力，从而使延迟回到可以接受的限度之内。
从算法的角度来看，流数据的持续流动特性是一把双刃剑。好的一面是，很少会出现数据不足的情况。如果我们的分析需要更多数据，等待足够的数据到来就可以了。可能需要长时间的等待，但同时可以进行其他的分析任务，从而提前预知如何继续进行后续分析。
不好的一面是，过去80年间所开发的统计工具多数集中于离散实验。许多标准的分析方法并不一定很适合流式数据。例如，在流环境下使用时，“统计显著性”这个概念就变得有点奇怪。许多人将其视为数据采集的某种“停止规则”，但实际上并非如此。用来做显著性检验的p-value本身是随机值，可能低于临界值（通常是0.05），然而观察到的下一个值有可能导致p-value超过0.05。
这并不意味着无法使用和不应使用统计技术。恰恰相反，它们仍然是分析有噪声数据的最好工具的代表。只是因为现在的主流还是离散实验，所以分析时应该多加小心。1.2.2 松散结构
与其他许多数据集相比，流数据经常显得结构松散。这有多方面的原因。尽管松散结构并不是流数据独有的，但在流环境下似乎比在其他情况下更加普遍。
部分原因似乎在于流环境下所感兴趣的数据类型。流数据的来源多种多样。有些数据来源有严格的结构，然而还有许多数据来源包含了任意的数据载荷。特别是，社交媒体数据流会包含从世界各地发生的事件到周日晚上布鲁克林最好的比萨这样五花八门的数据。更难以应付的是，这些数据是自然语言形式的。
另一个原因是流数据项目的“厨房水槽”心态。多数项目非常年轻，探索的是未知的领域，因此将尽可能多的不同维度加入数据中是有意义的。随着时间的推移，这会有所改变，也开始使用容易修改的格式，例如JavaScript对象表示法（JavaScript Object Notation，JSON）。普遍的模式就是对实际感兴趣的事件尽可能多地采集数据。
最后，数据采集的实时属性还意味着每个维度都可能在任何给定时刻存在或消失。例如，将IP地址转换为地理位置的服务可能临时中断。对于批处理系统，这不会带来什么问题，服务再次上线时就可以重新进行分析。流处理系统则不然，它必须能够处理每一维上的变化，并尽力做到最好。1.2.3 高基数的存储
基数指的是一部分数据可能的不同取值个数。形式上，基数指的是集合的大小，它可以用于数据集的各个维度以及整个数据集本身。高基数数据经常具有“长尾”特征：对于一个给定的维度（或维度组合），存在一个包含不同数据状态的小集合，这个小集合十分常见，通常占据所观察数据的绝大部分，其他数据状态只占很小的比例，从而形成一个“长尾”。
高基数特性在流系统和批处理系统中都很常见，但在流环境下对高基数的处理要困难得多。批处理环境下通常可以对数据集进行多遍处理。第一遍常用来确定数据的高基数维度，并计算构成大部分数据的状态。这些常见状态可以单独处理。剩下的状态则合并到一个名为“其他”的状态中，这个状态通常会被忽略掉。
流环境下，数据通常是单遍处理的。如果事先知晓常见的案例，就可以将这些案例放到处理步骤中。长尾部分也可以合并到“其他”状态中，分析就可以像批处理那样进行。如果已经对先前的数据集进行过批处理的考察，那就可以用来帮助流分析。然而，当前数据的常见状态是否也是未来数据的常见状态？这往往是未知的。实际上，混合状态的变化可能恰恰就是我们感兴趣的指标。更常见的情况是，没有以前的数据可以用来进行分析。这种情况下，流系统必须试图以数据本来的基数进行处理。
这对于处理和存储都是巨大挑战。对大规模集合做任何事情，必然要花时间处理涉及大量不同状态的种种问题，还需要线性大小的空间来存储各个不同状态的信息。流处理环境下对存储空间的要求要比批处理环境下更加严格，因为与批处理环境不同，流处理通常必须使用快速的主存储器，而不是速度缓慢的硬盘这样的第三级存储器。随着高性能固态硬盘（SSD）的出现，这种情况有所缓解，但SSD仍然要比主存储器慢好几个数量级。
因此，对高基数数据的处理是流数据研究的一个主要课题。本书讨论了其中一些方法。这是一个活跃的研究领域，每天都会开发和改进很多解决方案。1.3 基础架构和算法
本书旨在使读者具备从头到尾实现一个流数据项目的能力。没有基础架构的算法可能成为一篇有意思的研究论文，但无法造就一个成熟的系统。没有应用的基础架构多半只是浪费资源。
一心只关注算法或基础架构，指望着“建好了就自然有人来用”，这是行不通的。实际的系统必须同时实现用来支持系统的算法和基础架构。有了一个例子，其他人就能够看到各模块是怎么组合在一起的，然后将他们自己感兴趣的领域加入基础架构中。构建基础架构时要记住重要的一点（这值得反复重申），那就是我们的目的应当是使基础架构和算法可以被企业内（或者全世界）的各种用户所访问。只有当我们的项目能让人们使用、改进和扩展，这样的项目才算得上成功。1.4 总结
总之，互联网规模的数据采集的兴起将实时处理框架与“传感器平台”连接起来。最初，这些传感器平台是完全虚拟的，例如系统监控代理，或是网站和以广告为目的的处理框架之间的连接。随着互联网的广泛普及，这转移到了实体世界，从而使得覆盖广大工业界的海量数据采集得以实现。
一旦数据可以实时获得，数据的处理必然也要是实时的。否则，既然从单次的角度看，批量采集很可能仍然要更便宜一些，实时采集又有什么价值呢？这就带来了一系列严峻挑战。使用本书中的基础架构解决方案与计算方法的组合，可以在很大程度上克服这些挑战，从而能够实时处理当今乃至未来系统采集的日益增多的数据。第一部分流分析架构
这一部分内容包括：
第2章 实时流架构设计
第3章 服务配置和协调
第4章 流分析中的数据流程管理
第5章 流数据的处理
第6章 流数据的存储第2章实时流架构设计
实时架构本质上是分层系统，该系统依赖于若干松散耦合的系统来达到目标。使用这种结构的原因有很多，例如保持系统在不可靠环境下的高可用性，对服务的需求，以及对架构本身成本结构的管理等。
本书第一部分介绍这类架构的各组件涉及的软件、框架和方法。作为该架构的蓝图和基础，本章首先介绍架构的各个组件，这些组件通常（但不总是）对应了物理或虚拟的独立机器实例；随后，我们以实时架构的主要特性（高可用性、低延迟、水平可扩展性）为背景对它们进行讨论。
本章还花了一些时间讨论建立实时架构的程序语言。我们假设读者已经在一定程度上熟悉本书示例所使用的Java和JavaScript语言。书中的许多软件包都是用Java虚拟机实现的，不过并非一定要用Java。作为Web的通用语言，JavaScript会在后面几节频繁使用，用于实现数据接口。
最后，本章为规划流架构试点项目的读者提供了一些建议。书中许多软件包可以在任何环境中发挥作用，在这个意义上说，可以将其视为是可互换的，但是，它们也都是优点与缺点并存。基于我们的实践经验，这自然就意味着在一些环境下，某些软件包要比其他软件包更好用。本章最后一节给出了以前成功的解决方案带来的一些启示，你可以将这些启示作为未来工作的起点。2.1 实时架构的组件
本节介绍现代实时架构中常见组件。并不是所有系统都会有所有这些组件，在系统建设初期更是如此。合理目标应该是，建立适合初始应用的系统，使其具备可扩展能力，将来再加入缺少的组件。
第一个应用完成后，流基础架构的其他应用必然会致力于满足各自的需求。实际上，某些组件很可能会有多个实现。这种情况最常出现在存储组件中，因为各种存储组件产品的性能特征范围很宽广。
本节涵盖了各个组件，以及关于每个组件的开发和未来发展的一些问题。各个组件的详细内容可以在第一部分末尾的相关章节中找到。2.1.1 数据采集
本书讨论的实时应用的最常见环境都基于TCP/IP网络。因此，数据采集通过建立在TCP/IP网络上的连接来进行，通常使用HTTP这样的通用协议。这种形式的数据采集最明显例子就是对延迟敏感的大型网站，它们通过接地域分布服务器（即边缘服务器）来缩短终端用户的延迟。
由于网站是大规模数据采集的最早用例，因此Web服务器所使用的日志格式成为日志文件格式的主流也就不足为奇。遗憾的是，多数Web服务器遵循美国国家超级计算应用中心（National Center for Supercomputing Applications，NCSA）公共日志格式（Common Log Format）和后来的万维网联盟（World Wide Web Consortium，W3C）扩展日志文件（Extended Log File Format）格式，这两种格式从未打算支持丰富的数据载荷（因此在这方面表现很差）。
新式系统支持的日志格式更加丰富，其中JavaScript对象表示法（JavaScript Object Notation，JSON）是其中最流行的格式。JSON之所以流行，是因为它容易通过扩展来表示丰富的数据结构。JSON还比较易于解析，同时它的库也是广泛可用的。JSON一般用于在客户端Web应用与服务器端之间传送数据。
JSON的灵活性也带来了弊端：处理时的验证问题。缺少模式（schema）定义，以及不同的包容易产生结构不同但语义相同的结构，这都意味着处理JSON的应用往往包含大量的验证代码，以确保输入的合理性。JSON实质上是将消息和模式一起发送，这导致数据流需要较高的带宽。数据流压缩能够改善这种情况，经常能够达到80%以上的压缩率，但这也说明还有进一步提高的空间。
如果数据结构良好，对问题理解得又很到位，那就可以尝试使用结构化有线格式（structured wire format）。其中最流行的两个是Thrift和Protocol Buffers（通常简称Protobuf）。前者由Facebook开发，后者则由Google开发，两者的设计非常相似（它们还共享某些开发人员，知道这一点你就不会感到奇怪了）。它们使用一种接口定义语言（Interface Definition Language，IDL）来描述数据结构，IDL会被翻译成各种输出语言能用的代码，该代码被用来对有线传输的消息进行编码和解码。这两种格式都提供了一种机制来扩展原始消息，从而能够添加新的信息。
另一个相对小众的选择是Apache Avro格式。从概念上讲，它与Protocol Buffer或Thrift非常相似。它也是用IDL来定义模式，其模式正好也是JSON格式，这与Thrift或Protocol Buffer很像。Avro倾向于使用动态编码器和解码器，而不是代码生成的方式，但其二进制格式却与Thrift非常类似。两者的重要区别在于，除了二进制格式之外，Avro还可以对其模式的JSON格式表示进行读写。JASON的非正式模式往往会被显式地声明为Avro模式，这样，我们就可以在已有的JASON表示和更简洁、定义更良好的二进制表示之间自由转换。
对大部分应用来说，数据采集过程是直接集成在边缘服务器中的。对于新服务器来说，所集成的数据采集机制很可能可以与下一节会讲到的数据流程机制直接通信。旧服务器是否能直接集成数据流程机制则很难说，可以根据具体情况进行选择。这些服务器通常是针对特定应用的，因此本书对此没有花费太多篇幅，只是讨论了数据流程组件的直接写入机制。2.1.2 数据流程
企业内部的数据采集、分析和报告系统通常以不同的速率不断膨胀。例如，如果输入流量保持稳定，但分析的深度有所加强，那么尽管所采集的数据没有变化，分析基础架构还是需要更多的资源。为了应对这种状况，就要将基础架构分成采集、处理等多个层次。许多时候，这些层之间以专有（ad hoc）方式通信，这种环境中的每个应用都使用自己的通信方法来与其他层集成。
实时架构的一个目标就是将这种环境统一起来，至少在一定程度上使得应用的构建和分析更加模块化。数据流程系统（本书中也称为数据移动系统）就是这其中的一个关键部分。
这些系统用单个统一的软件系统替代专有的、针对特定应用的通信框架。用来替换的软件系统通常是分布式的，从而易于扩展，并可以处理像多数据中心部署这样的复杂情况，同时，对数据的生产者和消费者也开放了通用接口。
本书讨论的系统主要是业界所称的第3代系统。“第0代”系统是紧耦合的专用通信系统，用来将应用分解为特定应用层。
第1代系统解除了这种耦合，通常使用某种日志文件系统来采集特定应用的数据，将其放入文件中。随后，这些文件一般会被收集到一个中央处理地点。接着，定制的处理器会使用这些文件来实现其他层。目前为止，这是最流行的系统，因为通过实现“至少一次”的交付语义保证了可靠性，同时对批处理应用又足够快。最初的Hadoop环境实质上就是针对这种用例进行优化的。
基于日志的系统主要的缺点在于速度太慢。日志文件一旦“展开”就要全部处理，因此数据必须以批量的形式采集。第2代数据流程系统认识到可靠传输并不总是优先目标，因此开始为系统间的数据移动实现远程过程调用（RPC）系统。Scribe和Avro这样的第2代系统，尽管可能为改善可靠性预留了一定的空间，但总的来说都倾向于牺牲可靠性以换取更快的速度。对许多应用来说，这种取舍是完全可以接受的，类似的模型已经在像Syslog这样的系统监控软件中应用了几十年。
第3代系统兼顾了第1代日志模型的可靠性和第2代PRC模型的高速度。这类系统中，用于数据的生产者和消费者的数据层都有一个实时接口，数据以分散的消息进行交付，而不是像第1代日志系统那样批量进行。实际情况下，为了提高性能，这通常以包含上千条消息的“迷你批量”形式交付。
不过，为了保证与基于日志的交付系统相同的“至少一次”交付，这类环境会实现一个中间存储层。为了维持必要的性能，这种存储层会水平扩展到多个不同的物理系统，由系统的数据生产者和消费者方的客户端软件负责协调（coordination）工作。
这类系统中最早的就是用来处理大量数据负载的队列系统，ActiveMQ就是其中之一。队列系统通过队列机制形成了消息“总线”，将架构的不同组件解耦，使得开发人员不需要再关心通信任务。队列系统的缺点是需要保持队列语义，即数据消费者收到消息的顺序要与消息提交的顺序一致。一般来说，在分布式环境下这种语义并不是必要的，如果需要，由客户端软件来处理通常比较好。
鉴于多数情况下并不需要队列语义，第3代数据流程系统的最新成员Kafka和Flume应运而生。它们在很大程度上摒弃了排序语义，同时仍然保留了分布式系统和可靠性保证的概念。这使得它们几乎可以提高几乎所有应用的性能。Kafka还有一点值得注意，它是明确针对大规模多数据中心中的数据流程处理而设计的。2.1.3 数据处理
Map-Reduced的（Hadoop是其最流行的开源版本）大行其道，并不是因为它是改变游戏规则的技术。实际上，1890年人口普查使用的霍列瑞斯穿孔制表机（Hollerith tabulation machines）就使用了与Hadoop及其他系统所实现的Map-Reduce过程相似的机制。
注意 霍列瑞斯后来创立了一个公司，这个公司就是IBM的前身之一。
引入分布式计算思想以及在数据本地进行计算以提高性能的重要性，也与Map-Reduce无关。高性能计算及大规模计算领域早就知道，将软件尽可能靠近数据往往效率更高，该领域的分布式计算软件也是应有尽有。
真正由Map-Reduce做的事情是，只要应用开发人员能够用这种独特的模式表述问题，计算的高效组织就由Map-Reduce负责，开发人员不需要参与。我们早就有表格形式的大量数据，但是一直以来，都是由特定的应用来决定怎样将数据划分到处理单元，以及怎样在其中移动数据。第1代日志采集系统实现了以通用方式采集大量数据。而Map-Reduce，特别是Hadoop，使得处理的分布化更加容易，从而不再需要针对特定应用的代码，或者昂贵的软硬件解决方案。
随着第2代数据流程框架的引入，类似的事情也发生在实时领域。以往封存在日志文件中的数据，现在能以低延迟的方式获得。与最初的批处理系统类似，第一批系统往往是针对特定任务实现的。例如，Twitter的Rainbird项目就是用Cassandra数据库实现的层次式流统计系统。
目前的第2代系统已经超越了针对特定任务的实现，开始为流计算的组织提供通用服务。这些系统，例如Storm（也是Twitter的项目，但最初是由BackType公司开发的），通常提供一个有向无环图（Directed Acyclic Graph，DAG）机制，用于对计算进行组织，以及在计算的不同部分之间传送消息。
这些框架还处于比较初级的软件项目阶段，仍然经常要进行大量开发工作。它们也缺少容易理解的计算模式的指导，这就意味着只能随着项目的进展进行探索。随着开发工作的不断深入，批处理系统与流系统之间的区别很可能会变得模糊。Map-Reduce模型已经逐渐具备了实现更复杂计算的能力，从而能够支持项目中的交互查询要求，如Cloudera公司的Impala项目和Hortonworks公司负责的Stinger项目。2.1.4 数据存储
实时处理和分析可以选择的数据库十分丰富，甚至达到了令人应接不暇的地步。尽管传统的关系数据库能够并且已经在流系统中使用，但通常我们还是选择所谓的“NoSQL”数据库。这种选择有许多原因，最主要的原因是性能优先，而不是传统关系数据库所要求的ACID特性（原子性、一致性、隔离性、持久性）优先。尽管ACID特性往往也会在某种程度上得到满足，但很少得到“NoSQL”数据库的完全支持。
与关系数据库相比，“NoSQL”数据库通常还缺少丰富的模式和查询语言。NoSQL得名于这样的事实：这类数据库的查询语言通常要比SQL（标准查询语言，Standard Query Language）标准严格得多。一旦有任何形式化的模式机制存在，这种简化的、更严格的查询语言通常伴随着更严格的模式。
NoSQL数据库最常见的形式是各种键-值对（key-value）的持久存储，其范围从单机的主-从数据存储（例如Redis），到完全分布式的、满足最终一致性的存储（例如Cassandra）。其基本的数据结构是键，键值为任意长度的字节数组，但多数在核心实体上还建立了某种层次的抽象。其中某些（例如Cassandra）甚至对抽象进行扩展来提供类SQL语言，以包含模式和类似的语句，不过SQL语言的许多特性它们还是不支持。
NoSQL数据库还包括各种混合数据存储，例如MongoDB。与键-值对存储不同，MongoDB是一种索引文档存储。从许多方面来说，它更接近于Google这样的搜索引擎，而不是关系数据库。与键-值对存储相似，它的查询语言很有限。它没有模式，对具有丰富结构的文档则使用优化的JSON表示法。与多数键-值对存储不同，它还对文档之间的引用进行抽象。
伴随着查询语言和模式维护的简化，NoSQL放松了对前文提到的ACID特性的要求。在这些数据存储中，原子性和一致性尤其是经常被牺牲的对象。通过将一致性约束松弛为“最终一致性”，这些存储减少了簿记（bookkeeping）指令，并用更为简单的模型将存储分布到物理上相距很远的大量机器中，来换取性能的提高。在实际情况中，对于流应用，一般来说，不必保证每个客户端同时具有相同的数据视图。主要问题发生在两个物理上分离的数据库副本试着修改相同的状态时。这是个棘手的问题，但还是可以解决的，第3章会对此做详细介绍。
放松原子性要求通常也会带来数据存储的性能提升，而性能最大化就是所有这些数据存储的最终目标。它们多数以某种轻量级的方式，通常是计数器（counter）类型的特例，来保持原子性。维持原子操作的计数器并不难，其用例也很常见，因此多数NoSQL数据存储都实现了某种形式的计数器。
本书讨论的各种存储都有优缺点。传统关系数据库甚至也在实时应用中占有一席之地。在哪个数据存储上应用运行得更好，取决于要实现的目标，用一种数据存储来满足所有目的是不现实的。本书的目的是讨论这样一种基础架构，它用实时存储作为记录系统（system of record）的良好近似，而记录系统可能是基于批处理系统和关系数据库的。然后，基于它们在各自问题上的性能特性，对数据存储进行选择。我们希望该基础架构能够确保这些存储都能持有实质上相同的数据，并针对各自的用例进行了优化。
接受了数据需要存储于不同的数据存储中这个现实之后，与批处理系统的集成也就是自然而然的事情了。流架构非常适合可以接受结果有一定误差的任务。取决于所需要的计算，这样的误差甚至可能是蓄意而为，这会在第9章和第10章中讨论。但是，往往最终必须对数据的计算进行解析和审计，这样的任务更适合批量计算。理想情况是，流架构负责快速获取数据，一旦批处理系统可以产生数据，就改由批处理系统负责。Storm的主要创始人Nathan Marz将这个命名为Lambda架构。在Lambda架构的系统中，中间件的用户界面或其他部分负责从相应的存储中获取需要的数据。随着批处理和实时系统的持续融合，通过Apache YARN项目这样的基础架构方面的改善，这种理想情况应该会越来越常见。2.1.5 数据交付
多数实时应用的交付机制是基于Web界面的。这有很多好处。它们易于实现，并且由于是轻量级的，因而便于原地部署。在交付过程中，有许多框架可资利用。
最初这些仪表板就是带有META刷新（refresh）标记的网站，每几分钟重新加载交付过程的静态表示。许多系统监控工具，如Graphite，仍然使用这种方式。在应用数据的变化通常很迟缓时，这种方式的效果足够好。在需要支持多种环境时效果也不错，因为这项技术差不多与Web一样古老。
2.1.5.1 Web通信方法
对于将数据交付给Web浏览器来显示，现代应用有许多其他选择。更新Web页面的一个略快版本是使用多数Web浏览器带有的XMLHttpRequest（XHR）属性，将数据而不是数据镜像加载到浏览器。这类技术也称为AJAX，即“异步JavaScript与XML”。AJAX分离了数据层和表示层，相比旧模型有所进步。它使得应用可以根据环境对数据的渲染进行裁剪，并且往往能减少需要传输的数据量。
通过XMLHttpRequest传输数据，与页面刷新类似，本质是建立在轮询之上的。数据更新不会快过轮询的频率，这限制了新信息交付给前端的速度。如果事件相对较少，例如通知系统，大量调用浪费在确保“没有新闻就是好新闻”之上。随着对更加实时的通信需求的增
试读结束[说明：试读内容隐藏了图片]