使用Apache Spark和MySQL开创强大的数据分析
作者:课课家更新于： 2015-11-02 13:37:53
ApacheSpark是一个类似Apache Hadoop的集群计算框架，在Wikipedia上有大量描述：Apache Spark是一个开源集群计算框架，出自加州大学伯克利分校的AMPLab，后被捐赠给了Apache软件基金会。
相对于Hadoop基于磁盘的两段式MapReduce规范，Spark基于内存的多段式基元在特定应用上表现要优出100倍。Spark允许用户程序将数据加载到集群内存中反复查询，非常适合机器学习算法。
与流行的看法相反，Spark不需要将所有数据存入内存，但会使用缓存来加速操作（就像MySQL那样）。Spark也能独立运行而无需Hadoop，并可以运行在单独一台服务器上（甚至笔记本或台式机上），并充分利用所有CPU内核。开启它并使用分布式模式真的很简单。先打开master，在同一个节点上运行slave：
然后在任何额外的节点上运行Spark worker（确定向/etc/hosts 添加了hostname或者使用DNS）：
oracle视频教程
在很多任务中MySQL（开箱即用的）表现并不太好。MySQL的限制之一在于：1次查询=1个CPU内核。也就是说，即便你有48个速度飞快的内核，外加一个大型数据集可用，也无法充分利用所有的计算能力，相反Spark却能充分使用CPU内核。
MySQL与Spark的另一差异在于：
l MySQL使用所谓的“写时模式（schema on write）”——需要将数据转化到MySQL中，如果未包含在MySQL里，就无法使用sql来查询。
l Spark（还有Hadoop/Hive）使用“读时模式（schema on read）”——比如在一个压缩txt文件顶部使用表格结构（或者其他支持的输入格式），将其看作表格；然后我们可以用SQL来查询这个“表格”。
也就是说，MySQL负责存储+处理，而Spark只负责处理，并可直接贯通数据与外部数据集（Hadoop、Amazon S3，本地文件、JDBC MySQL或其他数据集）的通道。Spark支持txt文件（压缩的）、SequenceFile、其他Hadoop输入格式和Parquet列式存储。相对Hadoop来说，Spark在这方面更为灵活：例如Spark可以直接从MySQL中读取数据。
向MySQL加载外部数据的典型管道（pipeline）是：
1、 解压缩（尤其是压缩成txt文件的外部数据）；
2、用“LOAD DATA INFILE”命令将其加载到MySQL的存储表格中；
3、只有这样，我们才能筛选/进行分组，并将结果保存到另一张表格中。
这会导致额外的开销；在很多情况下，我们不需要“原始”数据，但仍需将其载入MySQL中。
相反，我们的分析结果（比如聚合数据）应当存在MySQL中。将分析结果存在MySQL中并非必要，不过更为方便。假设你想要分析一个大数据集（即每年的销售额对比），需要使用表格或图表的形式展现出来。由于会进行聚合，结果集将会小很多，将其存在MySQL中与很多标准程序一同协作处理将会容易许多。
一个有趣的免费数据集是Wikipedia的页数（从2008年启用后到现在，压缩后大于1TB）。这个数据可以下载（压缩空间确定txt文件），在AWS上也是可用的（有限数据集）。数据以小时聚合，包括以下字段：
l项目（比如en，fr等，通常是一种语言）
l页头（uri），采用urlencode编码
l请求数
l返回内容的大小
（数据字段编译到了文件名中，每小时1个文件）
我们的目标是：找出英文版wiki中每日请求数位居前10的页面，不过还要支持对任意词的搜索，方便阐释分析原理。例如，将2008到2015年间关于“Myspace”和“Facebook”的文章请求数进行对比。使用MySQL的话，需要将其原封不动的载入MySQL。所有文件按内置的日期编码分布。解压的总大小大于10TB。下面是可选的步骤方案（典型的MySQL方式）：
1、解压文件并运行“LOAD DATA INFILE”命令，将其录入临时表格：
2、“插入到”最终的表格，进行聚合：
3、通过url解码标题（可能用到UDF）。
开销很大：解压并将数据转化为MySQL格式，绝大部分都会被丢弃，作为损耗。
根据我的统计，整理6年来的数据需耗时超过1个月，还不包括解压时间，随着表格逐渐变大、索引需要更新所带来的加载时间折损。当然，有很多办法可以加速这一过程，比如载入不同的MySQL实例、首先载入内存表格再集合成InnoDB等。
不过最简单的办法是使用Apache Spark和Python脚本（pyspark）。Pyspark可以读出原始的压缩txt文件，用SQL进行查询，使用筛选、类似urldecode函数等，按日期分组，然后将结果集保存到MySQL中。
下面是执行操作的Python脚本：
在脚本中用到了Spark来读取原始压缩文件（每次一天）。我们可以使用目录作为“输入”或者文件列表。然后用弹性分布式数据集（RDD）转化格式；Python包含lambda函数映射和筛选，允许我们将“输入文件”分离并进行筛选。
下一步是应用模式（declare fields）；我们还能使用其他函数，比如用urllib.unquote来解码标题（urldecode）。最终，我们可以注册临时表格，然后使用熟悉的SQL来完成分组。
该脚本可以充分利用CPU内核。此外，即便不使用Hadoop，在分布式环境中运行也非常简易：只要将文件复制到SparkNFS/外部存储。
该脚本花了1个小时，使用了三个box，来处理一个月的数据，并将聚合数据加载到MySQL上（单一实例）。我们可以估出：加载全部6年的（聚合）数据到MySQL上需要大约3天左右。
你可能会问，为什么现在要快得多（而且实现了同样的实例）。答案是：管道不同了，而且更为有效。在我们起初的MySQL管道中，载入的是原始数据，需要大约数月时间完成。而在本案例中，我们在读取时筛选、分组，然后只将需要的内容写入MySQL。
这里还有一个问题：我们真的需要整个“管道”吗？是否可以简单地在“原始”数据之上运行分析查询？答案是：确实有可能，但是也许会需要1000个节点的Spark集群才能奏效，因为需要扫描的数据量高达5TB（参见下文中的“补充”）。
通过使用group_res.write.jdbc(url=mysql_url, table=”wikistats.wikistats_by_day_spark”, mode=”append”) ，Spark会启动多线程插入。
oracle视频教程
Spark提供了web接口，方便对工作进行监控管理。样例如下：运行wikistats.py application：
结果：使用Parquet分列格式与MySQL InnoDB表格
Spark支持Apache Parquet分列格式，因此我们可以将RDD存储为parquet文件（存入HDFS时可以保存到目录中）：
我们将管道结果（聚合数据）存入Spark。这次使用了按天分区（“mydate=20080101”），Spark可以在这种格式中自动发现分区。得到结果后要进行查询。假设我们想要找到2018年1月查询最频繁的10大wiki页面。可以用MySQL进行查询（需要去掉主页和搜索页）：
请注意，我们已经使用了聚合（数据汇总）表格，而不是“原始”数据。我们可以看到，查询花了1小时22分钟。由于将同样的结果存入了Parquet（见脚本）中，现在可以在Spark-SQL中使用它了：
这将用到spark-sql的本地版本，而且只用到1个主机。
耗时大约20分钟，比之前更快。
有人把数据比喻为蕴藏能量的煤矿。煤炭按照性质有焦煤、无烟煤、肥煤、贫煤等分类，而露天煤矿、深山煤矿的挖掘成本又不一样。与此类似，大数据并不在“大”，而在于“有用”。价值含量、挖掘成本比数量更为重要。对于很多行业而言，如何利用这些大规模数据是成为赢得竞争的关键。
大数据的价值体现在以下几个方面：1)对大量消费者提供产品或服务的企业可以利用大数据进行精准营销;2) 做小而美模式的中长尾企业可以利用大数据做服务转型;3) 面临互联网压力之下必须转型的传统企业需要与时俱进充分利用大数据的价值。
不过，“大数据”在经济发展中的巨大意义并不代表其能取代一切对于社会问题的理性思考，科学发展的逻辑不能被湮没在海量数据中。著名经济学家路德维希·冯·米塞斯曾提醒过：“就今日言，有很多人忙碌于资料之无益累积，以致对问题之说明与解决，丧失了其对特殊的经济意义的了解。”[5] 这确实是需要警惕的。
Apache Spark是分析和聚合数据的好办法，而且非常简便。我喜欢Spark与其他大数据还有分析框架的原因在于：
l开源与积极开发
l不依赖工具，例如输入数据与输出数据不一定非要借助Hadoop
l独立模式，启动迅速，易于部署
l大规模并行，易于添加节点
l支持多种输入与输出格式；比如可以读取/写入MySQL（Java数据库连接驱动）与Parquet分列格式
但是，也有很多缺点：
l技术太新，会有一些bug和非法行为。很多错误难以解释。
l需要Java；Spark 1.5仅支持Java 7及以上版本。这也意味着需要额外内存——合情合理。
l你需要通过“spark-submit”来运行任务。
我认为作为工具，Apache Spark十分不错，补足了MySQL在数据分析与商业智能方面的短板。
更多视频课程文章的课程，可到课课家官网查看。我在等你哟！！！
￥699.00
￥280.00
￥680.00
