免费亚洲欧美精品电影_国内精品偷拍福利视频_美女黄网站色视免费国产_国产不卡福利片在线观看

【杭州網站建設】 數據可視化之美——《紐約時報》的一天

你是否曾經想過《紐約時報》網站的讀者會涵蓋什么類型的人？我們想過。我們還在想他們傾向于在一天之中的什么時候來訪問網站，使用什么工具訪問以及他們都來自哪里？從他們是誰到在什么時候、以什么方式以及為什么等，所有這些問題都在我們的思考范圍之內。

本文將要介紹的這個可視化項目源于在《紐約時報》研發(fā)試驗室一次午餐時就這個話題開展的一次簡單討論。正如你將看到的，從非常簡單的基于地理的數據集合開始，很快就深入到海量數據和潛在可視化。最終，我們創(chuàng)建了一個可視化用于顯示每天《紐約時報》Web站點和手機站點在世界和美國的流量。

收集一些數據

為了對Web站點和手機站點24小時的流量進行可視化，我們需要創(chuàng)建一個可以從《紐約時報》的訪問日志中抽取和清洗數據的程序?？紤]到我們想要創(chuàng)建一個可以顯示在一天內網站的訪問次數的可視化并且是一個基于地理信息進行展示的可視化，我們需要的數據包括：

在24小時內，用戶每次訪問Web站點或手機站點的時間戳。每個用戶每次訪問時所處位置的經度和緯度。

原始的訪問日志包含了人們訪問Web站點和手機站點的很多有用的信息（比如每個訪問者使用什么瀏覽器）；但其中有很多信息對我們而言是沒有用的，因此需要把它們從日志信息中過濾掉。此外，日志中并不包括每個用戶每次訪問時的經緯度信息，因此這是我們在日志“清洗”過程中需要添加的信息。

《紐約時報》Web站點月獨立訪問讀者約2000萬。這意味著，在任何一天Web站點和手機站點上都有幾百萬次的頁面瀏覽（或點擊）；這是我們準備為可視化收集的基礎數據。

數據清洗

對于可視化以及其他日志數據的分析，我們只對來自人們的在Web站點和手機站點的點擊數感興趣——而不是來自網絡爬蟲、機器人或抓取程序。為了過濾這些不必要的數據，我們實現了一段Java代碼用于識別出非人工的訪問日志并將其從日志中刪除。

每天Web站點原始的日志數據訪問量大約有500MB～700MB（壓縮格式），手機站點的訪問量約80MB～100MB（壓縮格式）。在數據清洗過程中，我們執(zhí)行了IP到經緯度的轉換，從而得到每個訪問用戶的精確位置。原始訪問日志中已經包含了用戶的IP地址，然后我們使用商業(yè)數據庫把IP轉換成地理位置信息。有很多公司提供GeoIP（地理位置IP）數據庫，用于實現該轉換。

一旦數據被清洗完畢并準確地進行了地理位置編碼，只需要對數據再做最后一輪處理。由于原始的訪問日志的收集、存儲和清理方式，新清洗完的數據是存放在多個文件中的，需要對它們排序之后合并到一個結果文件中去，該文件將包含可視化所需的數據，即一天訪問數據。

每天“清洗”后的網站日志數據被存儲到360個文件中，每個文件大小約30MB～40MB（壓縮格式）。由于每行中增加了一些額外的字段，如GeoIP 信息，“清洗”后的日志文件要大于原始文件。手機站點數據集小得多，因此清洗后的數據存儲在一個文件中，大約70MB（壓縮格式）。我們每天需要整理當天的每個清洗后的日志文件，并創(chuàng)建按照對Web站點和手機站點的訪問時間戳以及訪問者所在的經緯度排序的單個文件（Web站點和手機站點分別生成一個文件）。

Python、Map/Reduce和Hadoop

我們用Python語言創(chuàng)建了一個簡單的map/reduce腳本，可以從清洗后的日志文件中過濾掉所有不需要的數據，并輸出以逗號作為分隔符的數據，最后還會對數據進行排序。我們使用Amazon的彈性MapReduce Web服務，它允許我們在很多基于Hadoop的EC2的運行實例中運行Python實現的map/reduce。Amazon的EC2運行實例的“配置”不同（低配、中配和高配），不同的配置會提供不同的RAM、CPU核數和內存，因此我們在很多EC2實例中試驗運行map/reduce代碼，從而找到性價比最好的配置。數據處理需要約10～20分鐘（價值幾美元），具體所耗時間會依賴于機器的數量（我們從4～10臺都嘗試了一遍）和EC2實例的配置（我們嘗試了低配和中配）。

map/reduce（Hadoop）Job的輸出結果是很多有序的文件，這些文件保存在Amazon的S3桶（buckets）中。為了在可視化中把數據放到一個文件中（與前述方式相同，Web站點和手機站點分別存儲，各自有一個獨立文件），我們從S3下載結果文件到本地，然后按照傳統(tǒng)的方法進行排序和歸并。現在，數據已經按照期望的方式保存在一個文件中了，可視化的準備工作已經完成。

可視化的第一步

我們在可視化上做的第一個嘗試是創(chuàng)建了一個簡單的世界地圖，將一天之中對《紐約時報》Web站點的每次訪問用一個小的黃色圓圈表示，對移動站點的每次訪問用一個小的藍色圓圈表示。除了全球范圍的視圖，我們還希望創(chuàng)建一個聚焦（或縮放）于美國的視圖。

Processing

Processing（面向設計的開源編程語言和集成開發(fā)環(huán)境）被選作可視化工具，有幾個原因。首先，《紐約時報》研發(fā)小組中有些人已經有使用Processing完成小的數據可視化的項目經驗，他們還擁有使用傳感器作為數據收集設備進行探索的經驗。此外，我們都是Casey Reas（Processing創(chuàng)始人）、Ben Fry和Aaron Koblin使用該工具所創(chuàng)造的作品的超級粉絲，我們認為Processing將會成為對海量數據進行可視化的理想工具。

對于該可視化，我們需要做的第一件事是將網站的訪問用戶的經緯度信息映射到Processing中的二維可視化圖形中。Aaron Koblin友情提供了一些他在前一個項目中實現該功能的代碼——很不錯的、緊湊的Java類，可以把經緯度組轉換成x、y坐標。我們需要做的就是向Java庫傳遞數據文件中的經緯度元組，Java庫就會返回x、y坐標。然后，我們把這些坐標值傳給Processing的繪圖API來定位《紐約時報》Web站點和手機站點的每個用戶的位置。

基礎層地圖

創(chuàng)建基礎層地圖所需的時間會遠遠超過你的想象。首先，我們需要對美國和世界做出準確的表示。經過大量的數據探索后，我們最終使用加州大學洛杉磯分校的CENS組數據集，它描繪了世界上每座城市的經緯度坐標。

在使用該數據集的初始階段，每當程序啟動時，直接在Processing集成環(huán)境中進行渲染，但這個渲染花費的時間比我們期望的要多很多；因為知道該數據不會變，最后，我們創(chuàng)建了一個JPEG地圖，向背景地圖中加載一個非常小的文件。這種方式給我們節(jié)省了好幾分鐘的渲染時間（當解析大數據集時，這部分工作所需的時間會更長）和處理能力，并且成為所有后續(xù)的數據輸出和視頻的背景。

剛剛處理的數據哪去了

有了緯經度投影代碼和地圖輪廓，我們開始在地圖上描繪交通數據圖。在可視化初期，我們使用不包含重大新聞的任意一天的數據（2009年2月15日）。這一天的Web站點和手機站點的流量/訪問次數和平均值一致。

我們之前已經對數據進行過清洗、排序和添加地理位置編碼，包含了時間戳、Web站點和手機站點上給定一天的用戶每次查看/點擊時所處的緯度/經度值?，F在到了創(chuàng)建一個Processing應用程序的時刻了，它可以掃描Web站點和手機站點的日志文件，對于用戶的每次查看/點擊，會在地圖上描繪一個基于用戶點擊時所在位置而生成的點。

場景1，步驟1

Processing應用在絕大多數情況下由兩部分組成：啟動（setup）和循環(huán)繪制（draw）。在Processing應用的setup()函數中，你可以執(zhí)行應用需要的任何工作，比如變量初始化、打開輸入文件、字體加載等。循環(huán)繪制是Processing代碼的根本。Processing應用中的draw()函數通常每秒鐘會被調用30～60次（這是時間幀速率）。

我們第一次嘗試的代碼盡管存在一些問題，但能夠生成一些可以在屏幕上觀看的畫面?？梢远啻芜\行該應用程序，查看圖片中描繪的點，這些點表示《紐約時報》Web站點和手機站點一天的流量。隨時間變化的流量的模式讓人難以置信——畫面看起來似乎是活生生的，閃爍的燈光散布在整個地球上，如圖1所示。

這是偉大的第一步，但我們的代碼和方法都需要做些修改。以下是需要改進的三個方面。

 

圖1  原始可視化顯示了《紐約時報》Web站點和手機站點在全世界的流量——黃色圓圈表示Web站點的流量，藍色圓圈表示手機站點的流量

 

沒有具體比例

首先，該可視化沒有顯示來自每個用戶位置的Web站點和手機站點的流量的比例。比如，在一天的某個時刻，可能有很多Web站點和手機站點的用戶是來自相同的地方，比如紐約，可以看到有非常高的流量。有時，可能有成千上萬用戶來自同一個地理位置。同樣，假如是紐約！

在該應用程序的最初版本中，日志文件中出現的每個地理位置（一組經緯度值）在地圖上都使用相同大小的點表示。為了能夠表示比例，需要基于與某個位置關聯(lián)的用戶量來調整每個位置的可視化表示（地圖上的藍色和黃色點）。

其次，因為黃色（表示Web站點流量）和藍色（表示手機站點流量）點大小相同，而我們（在繪制循環(huán)中）先畫表示Web站點的點，再畫表示手機站點的點，當兩種點擊類型位于同一個地理位置時，藍色點會覆蓋黃色點。這對可視化而言不是一個好的選擇。

沒有考慮時間

在可視化的第一階段，我們沒有考慮人們在Web站點或手機站點上每次訪問或頁面查看所花費的時間，只是簡單地在地圖上為每次訪問畫了一個點，在可視化的整個過程中都不再管它了。這樣，就沒有人會注意到在某些大城市《紐約時報》有持續(xù)較大的流量，而在一些小的偏遠地區(qū)我們可能一天只有幾次查看，這種表示方式會使我們錯誤地認為這些地區(qū)整天都有流量。

我們需要解決這個問題，并結合比例表示問題，也就是說，我們需要提出一種新的方法，可以精確地表示從任何一個位置有多少人訪問該網站，以及他們在某篇文章上停留了多長時間，或者在整個網站上停留的時間。

定時拍攝

最后，我們選擇將整天的數據流量創(chuàng)建成為一個定時拍攝視頻，從而使我們能夠在整個《紐約時報》公司內共享該可視化。為了解決這個問題，我們決定使用Processing的一個內置的視頻庫，它能夠將循環(huán)繪制生成的時間幀保存到視頻文件中，進而創(chuàng)建出很清晰的電影形式的輸出。

場景1，步驟2

在第一個版本代碼基礎之上，我們增加了通過Processing的MovieMaker庫將可視化捕獲并保存到一個文件中的功能。我們還增加了應用支持，能夠使一對Web站點或手機站點的每次點擊的可視化都能夠體現該次訪問的生命周期。平均來說，Web站點和手機站點這兩個站點的一次訪問時間是歷時3～4分鐘。因此，在迭代過程中，不再是在地圖上畫一個點并在后面整整24小時都不管它，我們嘗試慢慢地每3分鐘淡出消減一個點。當然，一個獨立用戶不是每3分鐘對Web站點或手機站點執(zhí)行一次點擊——日志文件中顯示的很多點擊都是來自同一批用戶，或者是用了更長的時間瀏覽了網站的很多頁面的用戶。但是為了避免可視化的最初版本過于復雜，我們就籠統(tǒng)地認為每次對網站的訪問都是“3分鐘訪問”。

對于這種簡化的表示，我們需要保存一天內的每次查看/點擊淡出3分鐘以上的點。這意味著需要在內存中存儲很多對象。對于每秒鐘內Web站點和手機站點上的每次點擊，我們都會在Processing應用程序中創(chuàng)建一個對象，它的任務是保存該點擊的“生命周期”，也就是說，這個點需要在屏幕上停留多長時間（3分鐘），使用這些對象來幫助我們在可視化的整個周期內對點實現淡出效果。

因此，再回過來看Processing的繪制循環(huán)。我們還是每秒鐘從Web和手機站點的日志文件中讀取數據，但對于每次單擊，創(chuàng)建一個Hit（單擊）對象，其初始生命周期設置為3分鐘，初始不透明度是100％（這些值在迭代循環(huán)的每次繪制中不斷減少）。讀完日志數據后，遍歷內存中Hit對象集合。對于每個Hit對象，重新描繪表示該單擊的點，其透明度是基于該單擊剩余的生命周期，在3分鐘時間內把它淡出。當每個Hit對象達到生命周期時，把它從內存中刪除，并從地圖上刪除相應點（即不再重新描繪它）。

因為每秒鐘大約需要對400～500次點擊進行可視化，這種方法意味著任何時刻都需要在內存中存儲很多對象，來保存所有點擊軌跡。

可視化的第二步

為了實現想要的可視化，除增加支持能夠顯示每個地理位置的流量比例，需要對應用程序進行優(yōu)化，還需要重新思考如何收集數據。

重新回到比例問題

每秒鐘顯示每次點擊并不能顯示任何比例。在第一版的應用程序中，來自加拿大農村地區(qū)的少量的點擊和來自紐約的成千上萬的點擊，其可視化權重是一樣的。此外，從內存和處理器對可視化進行渲染的處理能力而言，每秒鐘顯示所有的點擊代價太高。

想清楚后，我們認為答案是對每分鐘每個地理位置的點擊次數進行可視化，而不是每秒鐘進行可視化。對于訪問日志文件中的每分鐘的數據，我們會累加每個地理位置的點擊總數。這種方式使得可視化結果可以顯示每個地理位置的流量比例，而且會極大地減少Processing應用程序的原始數據輸入。但是，這種方式意味著我們需要改變數據處理和map/reduce作業(yè)。

進一步處理數據

之前用Python實現的map/reduce腳本，其目的是從原始訪問日志中解析出我們需要的數據，并基于時間對數據進行排序，因此，需要做些修改。現在，該腳本需要對每分鐘、每個地理位置（一組緯度/經度值）的所有點擊進行計數，輸出結果數據并根據訪問時間進行排序。

從根本上說，map/reduce是一個編程模型，支持海量數據處理。其處理過程分成兩個任務：mapping（映射）和reducing（規(guī)約）。Mapper通常是接收一些輸入（在我們的例子中是日志文件），對數據做一些較小的處理，然后以鍵/值（key/value）對的方式輸出數據。Reducer的任務是接收Mapper的輸出結果數據，對數據進行歸并或規(guī)約，通常生成較小的數據集。在我們的應用程序中，Mapper腳本讀入原始的訪問日志文件，對于每一行，以如下格式輸出鍵/值對：

Timestamp of the access (in HH:MM format),latitude,longitude 1

在這個例子中，key是以逗號作為分隔符，包含了日志文件中每次點擊的時間戳、緯度、經度，而value是1（表示一次點擊計數值）。

然后，Reducer逐行讀取Mapper的輸出，保存每分鐘每個地理位置的點擊計數值。因此，它把Mapper輸出的每個“key”存儲到一個Python字典中，每次遇到Mapper的輸出有相同的“key”，就把其在字典中的計數值增加1。Python字典看起來大概如下：

{

“12:00,40.7308,-73.9970″: 128,

“12:00,37.7791,-122.4200″: 33,

“12:00,32.7781, -96.7954″: 17,

# cut off for brevity…

“12:01,40.7308,-73.9970″: 119,

“12:01,37.7791,-122.4200″: 45,

“12:01,32.7781, -96.7954″: 27,

# …

}

一旦Reducer讀取了Mapper的所有的數據輸入，它對數據進行排序（基于key），然后輸出排序的結果。

新的數據格式

在原始訪問數據上運行完新的map/reduce腳本后，我們得到了一組更準確的數據集。這個過程不僅減少了總的數據量（Web站點的訪問數據，從3000萬行左右減少到300萬行），而且為我們生成了每個地理位置的計數值?，F在，我們需要確定比例因子。以下是新的結果數據的樣本——注意時間戳、緯度、經度和（每分鐘的）點擊計數值。

12:00,039.948,-074.905,128

12:00,039.949,-082.057,1

12:00,039.951,-105.045,3

12:00,039.952,-074.995,1

12:00,039.952,-075.164,398

12:00,039.960,-075.270,1

12:00,039.963,-076.728,4

12:00,039.970,-075.832,2

12:00,039.970,-086.160,4

12:00,039.975,-075.048,23

可視化比例和其他可視化優(yōu)化

有了新形式的數據，我們不再是每秒鐘為每次點擊畫一個點，而是可以每分鐘為每個地理位置的點擊數值畫一個圓圈，并根據點擊數計算圓圈大小。這種方式可以生成期望的比例顯示，使得可視化的讀者可以輕松地區(qū)分來自加拿大農村和紐約市的不同的流量差別。

這種方式也極大地減少了應用程序需要的內存量。我們還是需要在內存中保存Web站點和手機站點的所有點擊（這樣我們才能消隱去時間超過3分鐘的點擊），但是因為我們現在保存的是每分鐘每個地理位置的點擊數，極大地減少了需要的Hit對象數量。對于任一分鐘，來自全世界的流量通常包含2000～3500個不同的地理位置。每個位置的Hit對象必須存儲在內存中；每個Hit對象生命期是3分鐘，因此對于任一時刻，內存中可能有6000～12 000個對象——數量還是很多，但是已經遠遠小于前一版本的對象數量。

現在，需要更新Processing應用程序，從而可以實時保存每個位置在任一時刻的點擊數，而且圓圈大小比例可以根據點擊數調整。

使定時拍攝能夠正常工作

對Processing應用程序進行升級使其能夠處理新的數據格式和方法，在此之后，我們創(chuàng)建了一個完整的歷時24小時的定時拍攝視頻。我們新的代碼每次能夠正常運行幾個小時，不存在之前遇到的內存和整體機器延時，現在是生成完整的定時拍攝視頻的時候了。不再像第一次那樣嘗試在地圖上為歷時24小時定時拍攝渲染Web站點和手機站點數據，我們只使用手機站點的數據（其數據量大約是Web站點數據量的10％）。這樣，我們就可以比同時渲染Web站點和手機站點數據更快地查看到結果或者發(fā)現可能存在的問題。

 

圖2 《紐約時報》手機站點在2009年6月25日這一天在美國的流量

 

 

圖3 《紐約時報》手機站點在2009年6月25日這一天在全球的流量

 

 

圖4 《紐約時報》Web站點在2009年6月25日這一天在美國的流量

 

 

圖5 《紐約時報》Web站點在2009年6月25日這一天在全球的流量

 

由于不確定應該對24小時的定時拍攝進行多大程度的收縮，我們決定測試一下，采用10分鐘。該項目最激動人心的時刻之一是當我們首次嘗試渲染24小時的手機站點數據時，點擊Processing的運行（Run）按鈕那一刻。把數據在一臺MacBook Pro機上渲染成10分鐘的定時拍攝視頻花了約2個小時。結果生成了！

大家互相擊拳祝賀后，開始觀看視頻?？戳舜蠹s兩分鐘，我們意識到視頻時間太長了——感覺視頻太慢了！開始重新裝載數據，創(chuàng)建一個歷時接近1.5分鐘的視頻。經過幾次嘗試以及對代碼和幀速率的調整，我們生成了新的視頻。對較小規(guī)模的手機站點數據集進行渲染可以正常工作后，我們開始在Web站點和手機站點的混合數據集上嘗試。由于數據量比之前大得多，渲染花費的時間也長很多——之前是2個小時，這次渲染花了24～36個小時，這取決于其所用的機器的性能。

半自動化

最后，我們希望能夠對整個過程實現自動化，這樣程序接收到輸入命令后，可以執(zhí)行任何一天的定時拍攝渲染。該過程現在是半自動化的，我們可以很容易為同一天渲染多個定時拍攝的視頻。舉個例子，我們可以針對以下任何一種情況進行渲染：

世界地圖的Web站點和手機站點的數據。美國地圖的Web站點和手機站點的數據。世界地圖和美國地圖的Web站點的數據。世界地圖和美國地圖的手機站點數據。

每種類型的數據需要花多長時間渲染？這取決于日期以及那一天是否是重大新聞日（即是否有很大流量）。

渲染定時拍攝視頻的數據計算

在Processing應用程序內，我們每秒鐘捕獲15幀的視頻。對于每一幀，在屏幕上繪制了1 分鐘的日志量。對于24小時的數據量，需要捕獲1440分鐘的數據。把每15分鐘的數據渲染成時間長度為一秒的視頻，則1440分鐘的數據會生成96秒鐘的視頻（約1.5分鐘）。

生成的視頻有什么用

在紐約時報大廈28層的走廊上掛著10臺監(jiān)視器，播放著我們所做的一些可視化視頻，包括這些流量圖。其中有6臺監(jiān)視器自動播放本章介紹的定時拍攝視頻；其他4臺屏幕上顯示的是《紐約時報》Web站點和手機站點當天全部流量的快照（美國和全球）。我們開始在公司內分享這些視頻，并且探索更多的可視化來查看一天內可以發(fā)現哪些模式。我們還觀察“重大新聞日”和“平常日”中，用戶使用模式的差異。

結束語

我們從目前創(chuàng)建的可視化中觀察到了一些有趣的模式，絕大多數如圖2~圖5所示。

第一個模式是手機站點的流量在美國約早上5點或6點開始暴漲，該時段人們醒來開始去上班（尤其是在東海岸）。在約8點半或9點人們到達辦公室前，手機站點流量一直很大；而當人們到達辦公室時，Web站點流量開始第一次大增。Web站點的流量在一整天都很大（尤其是午飯時間），下午稍有點下降，很可能是人們在下班路上，而這時手機站點的流量又開始增加。這個觀察和我們開始研究前的預期相同，但是該可視化進一步證實了我們的猜想。

 

數據可視化之美

另一個有趣的模式是Web和手機站點的國際流量都很大，非洲、中國、印度和日本某些地區(qū)的手機站點流量也很大。

標簽：杭州網站建設 ‍杭州網站制作 ‍杭州網站設計 杭州網站建設公司 杭州網站制作公司‍ 杭州網站設計公司 杭州精品網站建設 杭州精品網站設計 杭州精品網站設計公司 杭州精典網站設計 杭州精典網站建設 杭州精典網站設計公司 杭州精典網站制作 杭州精品網站制作