英语原文共 14 页，剩余内容已隐藏，支付完成后下载完整资料
Python，Map / Reduce和Hadoop
对于最后一步，我们用Python创建了一个简单的map / reduce脚本，该脚本从清除的日志文件中过滤掉了所有不需要的数据，以逗号分隔的格式输出我们想要保留的数据，然后为我们排序数据。（在R＆D小组中，我们通常使用Python进行数据收集，处理和解析。当可视化大型数据集时，我们会在Python中进行所有繁重的工作，并创建易于在可视化应用程序中读取和解析的文件。）我们使用Amazon的Elastic MapReduce Web服务运行了map / reduce代码，该服务允许我们使用Hadoop在多个EC2实例上运行Python map / reduce作业。Amazon EC2实例具有不同的“大小”（例如，小型，中型和大型），它们提供不同数量的RAM，CPU核心和内存，因此，我们尝试在各种EC2实例上运行map / reduce代码，以找到处理时间与成本的“最佳点”。处理过程大约需要10-20分钟（花费几美元），具体取决于机器的数量（我们尝试了4到10个）和EC2实例的大小（我们尝试了中小型）。
映射/归约（Hadoop）作业的结果输出进入了多个分类文件，这些文件已保存到Amazon S3存储桶中。要获得的数据转化为在可视化使用一个单独的文件（同样，一个文件的网络，一个用于移动电话），我们下载了S3的文件输出到本地机器，做了老式的排序-m 上的文件合并它们。现在，我们已经以所需的形式获得了数据，现在可以开始研究可视化了。
可视化的第一遍
同样，该项目的目标是可视化nytimes.com 和mobile.nytimes.com一天的流量，以了解一天中对我们网站的访问如何进行。我们想看看在特定地理区域甚至全球范围内是否存在任何有趣的模式。白天，美国的移动流量在何时何地激增？我们会在中国和印度这样的国家/地区看到更多访问我们移动网站的信息吗？这些国家的移动普及率比美国高？在一天中的某些时段（例如清晨，通勤时间，午餐时间和通勤回家），访问我们的网站和移动网站的感觉如何？其中一些问题可以通过基本的网站访问量报告来回答，但是我们希望在常规报告上添加新的视觉效果，让人们了解网站在一天中的访问情况如何。
在可视化的第一个步骤中，我们创建了一个简单的全局地图，并为nytimes.com的每次点击绘制了一个黄色的小圆圈，为每次访问移动设备绘制了一个蓝色的小圆圈。nytimes.com一整天都在不断地发生。但是，除了全局视图外，我们还希望创建一个专注于（或放大）美国的视图。
我们将详细介绍的可视化的第一版是我们的主要学习经验-试图可视化和理解如此大的数据集涉及很多挑战，我们是第一手发现的。在确定当前版本之前，我们对代码进行了几次重做，并且随着时间的推移，我们仍在完善数据收集和可视化过程。
处理中
由于多种原因，处理（一种面向设计的开源编程语言和IDE）是首选的可视化工具。首先，我们在纽约时报（NYTimes）研发小组中的一些人已经有使用Processing处理小型数据可视化项目的经验，并且已经探索使用带传感器的设备作为数据收集设备的经验。此外，我们是Ben Fry和Casey Reas （Processing的创建者）和Aaron Koblin所做的工作的忠实拥护者，因此我们认为这对于可视化我们的大型数据集非常理想。
进行可视化处理的第一件事是一些代码，该代码使我们能够将表示访问过我们网站的用户的纬度/经度对映射到Processing中的2D地图可视化。亚伦· 科布林（Aaron Koblin）很友善地向我们提供了他在先前项目中使用的一些代码来完成此任务—一个不错的紧凑型Java类，它将纬度/经度对转换为x，y 坐标。我们所要做的就是通过LAT在我们的数据文件中/长对在图书馆，它会给我们的X，yuml; 坐标。然后，我们可以通过Processing的绘图API来提供这些内容，以在地图上绘制指示每个nytimes.com和mobile.nytimes.com 访问者。
参考图
创建参考地图（仅绘制世界地图）所花费的时间比您预期的要多。首先，我们必须找到美国和世界的准确代表。众多数据探索之后，我们结束了使用从加州大学洛杉矶分校的CENS组数据集地块 纬度每一个城市的/经度坐标遍布世界各地。
应用程序启动时，使用此数据集进行的最初实验直接将其呈现在Processing中，但这花费的时间比我们想要的底衬要多。由于我们知道这些数据不会更改，因此我们最终创建了地图的JPEG并将非常小的文件加载到后台（请参见图16-1和16-2）。这为我们节省了几分钟的渲染时间（在解析大型数据集时可能会加总）和处理能力，并成为所有后续数据输出和视频的背景。
现在，我们刚刚在哪里处理了这些数据？
既然有了纬度/经度投影代码和地图轮廓，我们就可以开始在地图上绘制交通数据了。对于可视化的首次尝试，我们使用了随机日期（2009年2月15日）中的数据，该数据没有特别的突发新闻内容。该天在网站和移动网站上的平均访问量/访问量。
还记得我们经过清理，分类和地理编码的数据文件，其中包含给定日期的Web和移动网站上每次观看/匹配时的时间戳和纬度/经度对吗？现在的想法是创建一个处理应用程序，该应用程序将翻录Web和移动日志文件，并针对每个视图/点击在地图上绘制一个点，以指示用户在该访问期间所基于的位置。
场景1，拍摄1
处理应用程序大部分由两部分组成：设置和绘制循环。在Processing应用程序的setup（）函数中，您可以执行应用程序需要的任何类型的设置工作，例如初始化变量，打开输入文件，加载字体等。draw循环是Processing代码的源泉。 。处理应用程序中的draw（）函数通常每秒被调用30至60次（这是帧速率）。
我们的第一次尝试是这样的（用粗伪代码说明）：
无效setup（）
- 打开移动和网络日志文件
- 加载世界mapvoid draw（）的数据
- 绘制世界地图
- 从网络和移动日志文件中读取一秒钟的日志数据
- 对nytimes移动网站的每次访问/点击都绘制一个黄点（在日志文件中的第二秒内）
- 为nytimes.com网站的每次访问/点击绘制一个蓝点（在日志文件中的第二秒内）
该代码虽然有问题，但给了我们一些在屏幕上看的东西。随着一天中Web和移动站点流量的增加，我们能够运行该应用程序并查看随时间推移在地图上绘制的点。观察交通模式随时间推移而出现的情况真是令人难以置信-地图看起来好像已经变得生动起来，闪烁的灯光散布在全球各地。
这是迈出的重要一步，但是我们在代码和方法中都需要进行一些修复。以下各节描述了我们需要研究的三个主要领域。
一．没有规模
首先，可视化没有显示出源自每个用户位置的Web和移动站点流量的规模感。在一天中的任何时候，可能会有多个用户从同一位置访问网站和移动网站（例如，纽约的流量非常高）。有时，我们的网站上可能有成千上万的人，全部来自同一位置。再次，想想纽约！
在应用程序的初始版本中，我们在地图上为输入日志文件中找到的每个位置（纬度 / 经度对）绘制了相同的大小点。为了说明规模，我们需要根据从该位置连接的用户数量来调整来自每个位置（我们在地图上的蓝色和黄色点）的流量的视觉表示。
其次，由于黄色（网络）点和蓝色（移动）点的大小相同，并且我们在移动点之前绘制了网络点（在绘制循环中），所以当两种命中类型来自同一位置时，蓝色移动点遮盖了黄色的网点。
这不利于可视化。
二．没有时间感
在可视化的第一阶段中，我们没有考虑人们每次访问或浏览页面在网站或移动网站上花费的时间；我们只是在每次现场访问时在地图上画了一个点，并在整个可视化期间将其留在那里。现在，对于世界上交通流量不断的一些大城市，没人会注意到这一点，但是对于一些偏远的小地方，我们每天只能看到很少的景色，这给人的印象是全天都有来自这些地点的交通。
我们需要结合规模问题来解决此问题，也就是说，我们需要提出一种方法来准确描绘从任何一个位置访问该站点的人数以及他们在一篇特定文章上停留的时间，或整个网站。
最重要的是，必须每天第二天执行一次！
三．延时摄影
最后，我们想为全天的流量创建一个延时录像，以便我们可以轻松地共享纽约时报公司周围的可视化效果。为了解决此问题，我们决定使用内置的视频库进行处理，该库将绘制循环中的帧保存到视频文件中，并创建干净的输出影片。
场景1，拍摄2
从项目的第一个版本开始处理代码，我们添加了通过处理MovieMaker库将可视化内容捕获到文件中的功能。
我们还增加了对该应用程序的支持，以使访问网站或移动网站的每次点击都可以根据访问该网站的生命周期得到正确体现。平均而言，访问这两个站点的时间持续三到四分钟。因此，在此迭代中，我们没有在地图上绘制点并在整个24小时的时间内都留在那里，而是尝试在三分钟的过程中逐渐使每个点逐渐消失。当然，并非每次访问网站或移动网站的点击都是来自唯一的用户进行三分钟的访问-我们日志文件中的许多点击来自重复用户或浏览网站较长页面的用户。时间。但是为了避免可视化的初始版本变得过于复杂，我们做出了明确的声明，即每次点击都将是 对该网站的“三分钟访问”。
对于这种稍微简化的表示形式，我们需要跟踪一天中的每次观看/匹配，并在三分钟的时间内淡出每个视图/点击。这意味着在内存中存储很多对象。对于每秒发生的对网站和移动网站的每次点击，我们在“处理”应用中创建了一个对象，该对象的任务是跟踪该点击的“生命周期”，即该点应该在屏幕上停留多长时间（三分钟） -并且我们使用这些对象帮助淡化了整个生命周期中的点。
因此，回到我们的“处理”绘制循环。我们仍然从网络和移动日志文件中每秒读取数据，但是现在对于发生的每次点击，我们创建了一个Hit 对象，其初始生命周期值为3分钟，初始不透明度为100％（这些值在每个绘制循环中都会降低）迭代）。读取日志数据后，我们遍历内存中的Hit 对象集合。对于每个匹配，我们会根据匹配剩余的生命周期以不透明度重新绘制匹配点，并在三分钟的生命周期内逐渐消失。当每个Hit 到达其使用寿命的尽头时，我们将其从内存中删除，并从地图中删除了相应的点（即未重绘）。
由于我们可以看到大约400-500个匹配/秒，因此这种方法意味着可以随时将许多对象存储在内存中，以跟踪所有匹配（或用户）。我们知道这是有问题的，并且我们有一些优化想法，但是我们想迈出第一步，决定首先看看这种方法是否行得通。
让我们运行这件事，看看会发生什么！
在三分钟的时间内增加了对每次点击失败的支持，使我们更直观地表示网站流量，但是还需要做更多的工作。一方面，在这一点上，对于从可视化工作的每个位置发出的流量，我们仍然没有任何规模感。速度是另一个问题-运行此版本，我们只能在25分钟内制作约45秒的延时视频！这只猪是内存和处理器猪，跑起来和渲染都很慢。我们尝试在实验室中的其他几台计算机上运行它（具有1 GB RAM的Mac Mini，具有4 GB RAM的MacBook Pro和Mac Pro），但是在每台计算机上渲染该应用的速度都很慢。可视化距离我们正在寻找的目标更近了一步，但是它需要新一轮的优化-我们需要产生一天的价值游戏中时光倒流视频，在这一点上，我们获得的最好成绩约为一个小时！
可视化的第一个版本可以在http://nytlabs.com/dataviz上查看。
可视化第二遍
现在我们已经对可视化有了一定的了解，我们需要使其完全正常运行。除了增加支持以了解来自每个位置的流量的规模之外，我们还需要优化应用程序，这需要重新考虑我们如何收集数据。
回到那个规模问题
没有任何规模感，每秒显示每个命中是行不通的。在该应用程序的第一个版本中，少数来自加拿大农村的热门歌曲的视觉分量与来自纽约的数千个歌曲相同。此外，就呈现可视化效果所需的内存和处理能力而言，每秒显示每个命中项也太昂贵了。
经过仔细考虑后，我们认为答案是可视化每分钟而不是每秒来自每个位置的点击数。对于访问日志文件中每分钟的数据，我们将总计每个位置的点击总数。这将使我们了解每个位置的流量规模，并会大大减少输入到“处理”应用程序中的原始数据量。但是，这种方法意味着要更改我们的数据处理和地图/减少工作。
进一步海量数据
我们的Python map / reduce脚本最初需要从原始访问日志中解析出我们所需的数据，然后根据时间对数据进行排序，因此需要进行一些更新。现在，该脚本需要每分钟对每个位置（纬度/经度对）的每次点击进行计数，然后输出该数据（按访问时间排序）。
如果您不熟悉map / reduce的工作原理，建议您阅读一些在线提供的基础教程。基本上，map / reduce是一个编程模型，可让您处理大量数据。该处理分为两个任务：映射和归约。映射器通常会接受一些输入（在我们的例子中是日志文件），对数据进行一些次要处理，然后以键/值对的形式输出数据。Reducer的工作是获取Mapper的数据输出，并将数据合并或缩减为通常较小的数据集。
我们的Mapper脚本读取原始访问日志文件，并针对每一行以以下格式输出键/值对：
访问的时间戳（HH：MM格式），纬度，经度 1
在这种情况下，“键”是一个逗号分隔的字符串，其中包含日志文件中每个匹配项的时间戳，纬度和经度，“值”为1（单个匹配项计数）。
然后，我们的Reducer从Mapper中读取每一行，并跟踪每分钟每位置的命中数。为此，它将来自Mapper的每个“键”输出存储在Python字典中，并在每次在Mapper输出中看到相同的“键”时增加一个计数器。这是Python字典的示例：
{
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[239878]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
