第 1 章 大数据分析

第 1 章 大数据分析

作者:桑迪 • 里扎

 

(数据应用)就像香肠,最好别看见它们是怎么做出来的。

——Otto von Bismarck

  • 用数千个特征和数十亿个交易来构建信用卡欺诈检测模型
  • 向数百万用户智能地推荐数百万产品
  • 通过模拟包含数百万金融工具的投资组合来评估金融风险
  • 轻松地操作成千上万个人类基因的相关数据以发现致病基因

5~10 年前想要完成上述任务几乎是不可能的。我们说生活在大数据时代,意思是指我们拥有收集、存储、处理大量信息的工具,而这些信息的规模以前我们闻所未闻。这些能力的背后是许多开源软件组成的生态系统,它们能利用大量普通计算机处理大规模数据。Apache Hadoop 之类的分布式系统已经进入主流,并被广泛部署在几乎各个领域的组织里。

但就像锉刀和石头本身并不构成雕塑一样,有了工具和数据并不等于就可以做有用的事情。这时我们就需要数据科学了。雕刻是利用工具将原始石材变成普通人都能看懂的雕塑,数据科学则是利用工具将原始数据变成对不懂数据科学的普通人有价值的东西。

通常,“做有用的事情”指给数据加上模式并用 SQL 来回答问题,比如:“注册过程中许多用户进入到第三个页面,其中有多少用户年龄超过 25 岁?”如何架构一个数据仓库,并组织信息来回答此类问题,涉及的面很广,本书不对其细节过多赘述。

有时候“产生价值”需要多付出一些努力。SQL 可能仍扮演重要角色,但为了处理数据的特质或进行复杂分析,人们需要一个更灵活、更易用的,且在机器学习和统计方面功能更丰富的编程模式。本书将重点讨论此类型的分析。

长久以来,人们利用 R、PyData 和 Octave 等开源框架可以在小数据集上进行快速分析和建模。只需不到 10 行代码,就可以利用数据集的一部分数据构建出机器学习模型,再利用该模型预测其余数据的分类。如果多写几行代码,我们还能处理缺失数据,尝试多个模型并从中找出最佳模型,或者用一个模型的结果作为输入来拟合另一个模型。但如果数据集巨大,必须利用大量计算机来达到相同效果,我们该怎样做呢?

一个可能正确的方法是简单扩展这些框架,使之能运行在多台机器上,保留框架的编程模型,同时重写其内核,使之在分布式环境下能顺利运行。但是,分布式计算难度大,我们必须重新思考在单机系统中的许多基本假设,在分布式环境下是否依然成立。比如,由于集群环境下数据需要在多个节点间切分,网络传输速度比内存访问慢几个数量级,如果算法涉及宽数据依赖,情况就很糟糕。随着机器数量的增加,发生故障的概率也相应增大。这些实际情况要求编程模式适配底层系统:编程模式要防止不当选项,并简化高度并行代码的编写。

当然,除了像 PyData 和 R 这样在软件社区里表现优异的单机工具,数据分析还用到其他工具。在科学领域,比如常常涉及大规模数据的基因学,人们使用并行计算框架已经有几十年的历史了。今天,在这些领域处理数据的人大多数都熟悉 HPC(high-performance computing,高性能计算)集群计算环境。然而,PyData 和 R 的问题在于它们很难扩展。同样,HPC 的问题在于它的抽象层次较低,难于使用。比如要并行处理一个大 DNA 测序文件,人们需要手工将该文件拆成许多小文件,并为每个小文件向集群调度器提交一个作业。如果某些作业失败,用户需要检查失败并手工重新提交。如果操作涉及整个数据集,比如对整个数据集排序,庞大的数据集必须流入单个节点,否则科学家就要用 MPI 这样底层的分布式框架。这些底层框架使用难度大,用户必须精通 C 语言和分布式 / 网络系统。

为 HPC 环境编写的工具往往很难将内存数据模型和底层存储模型独立开来。比如很多工具只能从单个流读取 POSIX 文件系统数据,很难自然并行化,不能用于读取数据库等其他后台存储。最近,Hadoop 生态系统提供了抽象,让用户使用计算机集群就像使用单台计算机一样。该抽象自动拆分文件并在多台计算机上分布式存储,自动将工作拆分成若干粒度更小的任务并分布式执行,出错时自动恢复。Hadoop 生态系统将大数据集处理涉及的许多琐碎工作自动化,并且启动开销比 HPC 小得多。

1.1 数据科学面临的挑战

数据科学界有几个硬道理是不能违背的,Cloudera 数据科学团队的一项重要职责就是宣扬这些硬道理。一个系统要想在海量数据的复杂数据分析方面取得成功,必须明白这些硬道理,至少不能违背。

第一,成功的分析中,绝大部分工作是数据预处理。数据是混乱的,在让数据产生价值之前,必须对数据进行清洗、处理、融合、挖掘和许多其他操作。特别是大数据集,由于人们很难直接检查,为了知道需要哪些预处理步骤,甚至需要采用计算方法。一般情况下,即使在模型调优阶段,在整个数据处理管道的各个作业中,花在特征提取和选择上的时间比选择和实现算法的时间还要多。

比如,在构建网站欺诈交易检测模型时,数据科学家需要从许多可能的特征中进行选择。这些特征包括必填项、IP 地址信息、登录次数、用户浏览网站时的点击日志等。在将特征转换成适用于机器学习算法的向量时,每个特征可能都会有不同的问题。系统需要支持更灵活的转换,远远不止是将二维双精度数组转换成一个数学模型那么简单。

第二,迭代是数据科学的基础之一。建模和分析经常需要对一个数据集进行多次遍历。这其中一方面是由机器学习算法和统计过程本身造成的。常用的优化过程,比如随机梯度下降和最大似然估计,在收敛前都需要多次扫描输入数据。数据科学家自身的工作流程也涉及迭代。在初步调查和理解数据集时,一个查询的结果往往给下一个查询带来启示。在构建模型时,数据科学家往往很难在第一次就得到理想的结果。选择正确的特征,挑选合适的算法,运行恰当的显著性测试,找到合适的超参数,所有这些工作都需要反复试验。框架每次访问数据都要读磁盘,这样会增加时延,降低探索数据的速度,限制了数据科学家进行试验的次数。

第三,构建完表现卓越的模型不等于大功告成。数据科学的目标在于让数据对不懂数据科学的人有用。把模型以许多回归权值的形式存成文本文件,放在数据科学家的计算机里,这样做根本没有实现数据科学的目标。数据推荐引擎和实时欺诈检测系统是最常见的数据应用。这些应用中,模型作为生产服务的一部分,需要定期甚至是实时重建。

在这些场景中,有必要区别是试验环境下的分析还是生产环境下的分析。在试验环境下,数据科学家进行探索性分析。他们想理解工作数据集的本质。他们将数据图形化并用各种理论来测试。他们用各种特征做试验,用辅助数据源来增强数据。他们试验各种算法,希望从中找到一两个有效算法。在生产环境下,构建数据应用时,数据科学家进行操作式分析。他们把模型打包成服务,这些服务可以作为现实世界的决策依据。他们跟踪模型随时间的表现,哪怕是为了将模型准确率提高一个百分点,他们都会精心调整模型并且乐此不疲。他们关心服务 SLA 和在线时间。由于历史原因,探索性分析经常使用 R 之类的语言,但在构建生产应用时,数据处理过程则完全用 Java 或 C++ 重写。

当然,如果用于建模的原始代码也可用于生产应用,那就能节省每个人的时间。但像 R 之类的语言运行缓慢,很难将其与生产基础设施的技术平台进行集成,而 Java 和 C++ 之类的语言又很难用于探索性分析。它们缺乏交互式数据操作所需的 REPL(read-evaluate-print-loop,读取 - 计算 - 打印 - 循环)环境,即使是简单的转换,也需要写大量代码。人们迫切需要一个既能轻松建模又适合生产系统的框架。

1.2 认识Apache Spark

该介绍 Apache Spark 了。Spark 是一个开源框架,作为计算引擎,它把程序分发到集群中的许多机器,同时提供了一个优雅的编程模型。Spark 源自加州大学伯克利分校的 AMPLab,现在已被捐献给了 Apache 软件基金会。可以这么说,对于数据科学家而言,真正让分布式编程进入寻常百姓家的开源软件,Spark 是第一个。

了解 Spark 的最好办法莫过于了解相比于它的前辈,即 Apache Hadoop 的 MapReduce,Spark 有哪些进步。MapReduce 革新了海量数据的计算方式,为运行在成百上千台机器上的并行程序提供了简单的编程模型。MapReduce 引擎几乎可以做到线性扩展:随着数据量的增加,可以通过增加更多的计算机来保持作业时间不变。而且 MapReduce 是健壮的。故障虽然在单台机器上很少出现,但在数千个节点的集群上却总是出现。对于这种情况,MapReduce 也能妥善处理。它将工作拆分成多个小任务,能优雅地处理失败的任务,并且不影响任务所属作业的正确执行。

Spark 继承了 MapReduce 的线性扩展性和容错性,同时对它做了一些重量级扩展。首先,Spark 摒弃了 MapReduce 先 map 再 reduce 这样的严格方式,Spark 引擎可以执行更通用的有向无环图(directed acyclic graph,DAG)算子。这就意味着,在 MapReduce 中需要将中间结果写入分布式文件系统时,Spark 能将中间结果直接传到流水作业线的下一步。在这方面,它类似于 Dryad(https://www.microsoft.com/en-us/research/project/dryad/)。Dryad 也是从 MapReduce 衍生出来的,起源于微软研究院。其次,它也完善了这种能力,通过提供许多转换操作,用户可以更自然地表达计算逻辑。Dryad 更加面向开发人员,其流式 API 可以做到用几行代码表示复杂的流水作业。

再次,Spark 扩展了前辈们的内存计算能力。它的 Dataset 和 DataFrame 抽象使开发人员将流水处理线上的任何点物化在跨越集群节点的内存中。这样后续步骤如果需要相同数据集就不必重新计算或从磁盘加载。这个特性使 Spark 可以应用于以前分布式处理引擎无法胜任的应用场景中。Spark 非常适用于涉及大量迭代的算法,这些算法需要多次遍历相同的数据集。Spark 也适用于反应式(reactive)应用,这些应用需要扫描大量内存数据并快速响应用户的查询。

或许最重要的是,Spark 契合了前面提到的数据科学领域的硬道理。它认识到构建数据应用的最大瓶颈不是 CPU、磁盘或者网络,而是分析人员的生产率。通过将预处理到模型评价的整个流水线整合在一个编程环境中,Spark 大大加速了开发过程。这一点尤为值得称赞。Spark 编程模型富有表达力,在 REPL 下包装了一组分析库,省去了多次往返 IDE 的开销。而这些开销对诸如 MapReduce 等框架来说是无法避免的。Spark 还避免了采样和从 Hadoop 分布式文件系统(the Hadoop distributed file system,HDFS) 来回倒腾数据所带来的问题,这些问题是 R 之类的框架经常遇到的。分析人员在数据上做实验的速度越快,他们从数据中挖掘出价值的可能性就越大。

在数据处理和 ETL 方面,Spark 的目标是成为大数据界的 Python 而不是大数据界的 MATLAB。作为一个通用的计算引擎,它的核心 API 为数据转换提供了强大的基础,它独立于统计学、机器学习或矩阵代数的任何功能。它的 Scala 和 Python API 让我们可以用表达力极强的通用编程语言编写程序,还可以访问已有的库。

Spark 的内存缓存使它适用于微观和宏观两个层面的迭代计算。机器学习算法需要多次遍历训练集,可以将训练集缓存在内存里。在对数据集进行探索和初步了解时,数据科学家可以在运行查询的时候将数据集放在内存中,也很容易将转换后的版本缓存起来,这样就节省了访问磁盘的开销。

最后,Spark 在探索型分析系统和操作型分析系统之间搭起一座桥梁。我们经常说,数据科学家比统计学家更懂软件工程,比软件工程师更懂统计学。基本上讲,Spark 比探索型系统更像操作型系统,比操作型系统中常见的技术更善于数据探索。Spark 从根本上是为性能和可靠性而生的。由于构建于 JVM 之上,它可以利用 Java 技术栈里的许多操作和调试工具。

Spark 还紧密集成 Hadoop 生态系统里的许多工具。它能读写 MapReduce 支持的所有数据格式,可以与 Hadoop 上的常用数据格式,如 Apache Avro 和 Apache Parquet(当然也包括古老的 CSV),进行交互。它能读写 NoSQL 数据库,比如 Apache HBase 和 Apache Cassandra。它的流式处理组件 Spark Streaming 能连续从 Apache Flume 和 Apache Kafka 之类的系统读取数据。它的 SQL 库 SparkSQL 能和 Apache Hive Metastore 交互,而且通过 Hive on Spark,Spark 还能替代 MapReduce 作为 Hive 的底层执行引擎。它可以运行在 Hadoop 集群调度和资源管理器 YARN 之上,这样 Spark 可以和 MapReduce 及 Apache Impala 等其他处理引擎动态共享集群资源和管理策略。

1.3 关于本书

本书接下来的部分不会讨论 Spark 的优缺点。还有其他一些话题本书也不会涉及。本书会介绍 Spark 的流式编程模型和 Scala 基础知识,但它不是 Spark 参考书或参考大全,不会讲 Spark 技术细节。它也不是机器学习、统计学、线性代数的参考书,但在讲到这些知识的时候,许多章节会提供一些背景知识。

另一方面,本书将帮助读者建立用 Spark 在大规模数据集上进行复杂分析的感觉。我们会讲述整个处理过程:不但涉及模型的构建和评价,也会讲述数据清洗、数据预处理和数据探索,并会花费笔墨描述怎样将结果变成生产应用。我们认为最好的教学方法是运用实例,所以在快速介绍完 Spark 及其生态系统之后,本书其余各章分别讨论了在不同领域使用 Spark 进行数据分析的实例,每个实例都自成一体。

如果可能的话,我们要做的不只是提供解决方案。我们会描述数据科学的整个工作流程,包括它所有的迭代、无解以及需要重新开始的情况。本书将有助于读者熟悉 Scala、Spark、机器学习和数据分析。但这都是为了一个更大的目标服务,我们希望本书首先教会读者如何完成本章开头部分提到的任务。每一章虽然只有薄薄的 20 来页,但我们会力求把怎样构建一个此类数据应用讲清楚、讲透彻。

1.4 第2版说明

2015 年和 2016 年 Spark 变化很大,2016 年 7 月 Spark 发布了 2.0 版本。其中改变最大的是 Spark 的核心 API。在 Spark 2.0 以前的版本中,Spark 的 API 主要围绕一个可以跨节点分布的、延迟实例化对象集合的弹性分布式数据集(Resilient Distributed Dataset,RDD)而构建。

虽然 RDD 使用了一套强大而富有表达力的 API,但是仍然存在两个主要的问题。第一,RDD 难以高效且稳定地执行任务。由于依赖 Java 和 Python 对象,RDD 对内存的使用效率较低,而且会导致 Spark 程序受长时间垃圾回收的影响。它们还将执行计划(execution plan)与 API 捆绑到了一起,给用户优化应用程序造成了沉重的负担。例如,传统 RDBMS(关系数据库管理系统)可以根据关联表的大小来选择最优的关联策略(join strategy),而 Spark 需要用户自己来做这个选择。第二,Spark 的 API 忽视了一个事实——数据往往能用一个结构化的关系形式来表示;当出现这种情况的时候,API 应该提供一些原语,使数据更加易于操作,比如允许用户使用列的名字来访问数据,而不是通过元组中的序数位置。

Spark 2.0 用 Dataset 和 DataFrame 替换掉 RDD 来解决上述问题。Dataset 与 RDD 十分相似,不同之处在于 Dataset 可以将它们所代表的对象映射到编码器(encoder),从而实现了一种更为高效的内存表示方法。这就意味着 Spark 程序可以执行得更快、使用更少内存,而且执行时间更好预测。Spark 还在数据集和执行计划之间加入了一个优化器,这意味着 Spark 能对如何执行做出更加智能的决策。DataFrame 是 Dataset 的子类,专门用于存储关系型数据(也就是用行和固定列表示的数据)。为了理解列的概念,Spark 提供了一套更干净的、富有表达力的 API,同时也加入了很多性能优化。举个例子,如果 Spark 知道了仅其中一部分列会被用到,它就能避免将用不到的列载入内存中。还有许多转换操作之前需要使用用户定义函数(user-defined function,UDF)来表示,现在可以在 API 中直接调用了。这对于 Python 用户来说十分有用,因为 Spark 在内部执行这些转换操作比 Python 中定义的函数要快得多。DataFrame 还可以与 Spark SQL 互相操作,这意味着用户可以写一个 SQL 查询来获取一个 DataFrame,然后选择一种 Spark 支持的语言对这个 DataFrame 进行编程操作。尽管新 API 与旧 API 看起来十分相似,但是很多细节发生了改变,因此几乎所有的 Spark 程序都要更新。

除了核心 API 的变化以外,Spark 2.0 还见证了机器学习 API 和统计分析 API 的巨大变化。在之前的版本中,每个机器学习算法都有一套自己的 API。如果用户想要准备算法需要的输入数据,或者将一个算法的输出提供给另外一个算法,都需要写一套它们自己的自定义编制代码。Spark 2.0 包含了 Spark ML API,它引入了一个框架,可以将多种机器学习算法和特征转换步骤管道化。这个 API 受 Python 的流行框架 Scikit-Learn API 启发,以评估器(estimator)和转换器(transformer)为中心,转换器从数据中学习参数,然后用这些参数来转换数据。Spark ML API 与 DataFrame API 高度集成,使得在关系型数据上训练机器学习模型变得更容易。例如,用户可以通过名字访问特征,而不用数组下标。

总体来说,Spark 的这些变化导致本书第 1 版中的很多内容都过时了。因此,第 2 版更新了所有的章节,并尽可能地使用最新的 API。此外,我们还删除了一些无关的章节。例如,第 1 版附录介绍了 API 的细节,第 2 版中将其删除了,一定程度上是因为现在 Spark 可以自动处理,无须用户干预。随着 Spark 进入了一个成熟而稳定的新时代,我们希望通过第 2 版的这些更新,本书在今后几年内会保持对 Spark 数据分析的参考价值。

目录

  • 版权声明
  • O'Reilly Media, Inc. 介绍
  • 推荐序
  • 译者序
  • 前言
  • 第 1 章 大数据分析
  • 第 2 章 用 Scala 和 Spark 进行数据分析
  • 第 3 章 音乐推荐和 Audioscrobbler 数据集
  • 第 4 章 用决策树算法预测森林植被
  • 第 5 章 基于 K 均值聚类的网络流量异常检测
  • 第 6 章 基于潜在语义分析算法分析维基百科
  • 第 7 章 用 GraphX 分析伴生网络
  • 第 8 章 纽约出租车轨迹的空间和时间数据分析
  • 第 9 章 基于蒙特卡罗模拟的金融风险评估
  • 第 10 章 基因数据分析和 BDG 项目
  • 第 11 章 基于 PySpark 和 Thunder 的神经图像数据分析
  • 作者介绍
  • 封面介绍