无码乱肉视频免费大全合集,亚洲第一A在线观看网站,黄网站色视频免费无风险,免费国产黄网在线观看

【杭州網(wǎng)站建設(shè)】 數(shù)據(jù)可視化之美——《紐約時報》的一天

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

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

收集一些數(shù)據(jù)

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

在24小時內(nèi)，用戶每次訪問Web站點或手機站點的時間戳。每個用戶每次訪問時所處位置的經(jīng)度和緯度。

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

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

數(shù)據(jù)清洗

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

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

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

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

Python、Map/Reduce和Hadoop

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

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

可視化的第一步

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

Processing

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

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

基礎(chǔ)層地圖

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

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

剛剛處理的數(shù)據(jù)哪去了

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

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

場景1，步驟1

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

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

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

 

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

 

沒有具體比例

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

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

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

沒有考慮時間

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

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

定時拍攝

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

場景1，步驟2

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

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

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

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

可視化的第二步

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

重新回到比例問題

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

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

進一步處理數(shù)據(jù)

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

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

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

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

然后，Reducer逐行讀取Mapper的輸出，保存每分鐘每個地理位置的點擊計數(shù)值。因此，它把Mapper輸出的每個“key”存儲到一個Python字典中，每次遇到Mapper的輸出有相同的“key”，就把其在字典中的計數(shù)值增加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的所有的數(shù)據(jù)輸入，它對數(shù)據(jù)進行排序（基于key），然后輸出排序的結(jié)果。

新的數(shù)據(jù)格式

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

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)化

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

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

現(xiàn)在，需要更新Processing應(yīng)用程序，從而可以實時保存每個位置在任一時刻的點擊數(shù)，而且圓圈大小比例可以根據(jù)點擊數(shù)調(diào)整。

使定時拍攝能夠正常工作

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

 

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

 

 

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

 

 

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

 

 

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

 

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

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

半自動化

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

世界地圖的Web站點和手機站點的數(shù)據(jù)。美國地圖的Web站點和手機站點的數(shù)據(jù)。世界地圖和美國地圖的Web站點的數(shù)據(jù)。世界地圖和美國地圖的手機站點數(shù)據(jù)。

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

渲染定時拍攝視頻的數(shù)據(jù)計算

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

生成的視頻有什么用

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

結(jié)束語

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

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

 

數(shù)據(jù)可視化之美

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

標(biāo)簽：杭州網(wǎng)站建設(shè) ‍杭州網(wǎng)站制作 ‍杭州網(wǎng)站設(shè)計 杭州網(wǎng)站建設(shè)公司 杭州網(wǎng)站制作公司‍ 杭州網(wǎng)站設(shè)計公司 杭州精品網(wǎng)站建設(shè) 杭州精品網(wǎng)站設(shè)計 杭州精品網(wǎng)站設(shè)計公司 杭州精典網(wǎng)站設(shè)計 杭州精典網(wǎng)站建設(shè) 杭州精典網(wǎng)站設(shè)計公司 杭州精典網(wǎng)站制作 杭州精品網(wǎng)站制作