共享單車數據分析的SQL資料庫設計

2021-01-22 52sissi

SQL,發音為「 sequel」(或SQL,如果願意的話),是數據科學家的重要工具。實際上,它可以說是獲取數據工作中最重要的語言。在共享單車數據分析的SQL設計中,我們將從入門者的角度深入研究SQL基礎知識,以使您入門並掌握這一關鍵技能。

讓我們從回答一個簡單的問題開始:

什麼是SQL?

SQL代表結構化查詢語言。查詢語言是一種程式語言,旨在促進從資料庫中檢索特定信息,而這正是SQL所做的。簡而言之,SQL是資料庫的語言。

這很重要,因為大多數公司將其數據存儲在資料庫中。儘管資料庫類型很多(例如MySQL,PostgreSQL,Microsoft SQL Server),但是大多數資料庫都使用SQL,因此一旦掌握了SQL基礎知識,便可以使用其中的任何一個。

即使您打算使用Python之類的另一種語言進行分析,在大多數公司中,您仍可能需要使用SQL從公司的資料庫中檢索所需的數據。在撰寫共享單車數據分析的SQL設計時,僅在美國,Indeed上就列出了80,000多個SQL作業。

因此,讓我們開始學習SQL!

(如果您希望通過瀏覽器進行交互學習,編寫和運行SQL查詢,則應查看我們的SQL基礎課程,該課程免費)

為了避免廣告的嫌疑,我們選擇國外的一個共享單車來舉例子,在共享單車數據分析的SQL設計中,我們將使用自行車共享服務Hubway的數據集,其中包括使用該服務進行的超過150萬次旅行的數據。

在開始用SQL編寫我們自己的一些查詢之前,我們將首先看一下資料庫,它們是什麼以及為什麼使用它們。

如果您想繼續,可以在這裡下載hubway.db文件(130 MB)。

SQL基礎:關係資料庫

關係資料庫是一種資料庫,該資料庫存儲跨多個表的相關信息,並允許您同時查詢多個表中的信息。

通過思考一個例子,更容易理解它是如何工作的。假設您是一家企業,並且想要跟蹤銷售信息。您可以在Excel中設置一個電子表格,在其中您要跟蹤的所有信息都以單獨的列顯示:訂單號,日期,到期金額,裝運跟蹤號,客戶名,客戶地址和客戶電話號碼。

此設置可以很好地跟蹤所需的信息,但是當您開始從同一位客戶那裡獲得重複訂單時,您會發現他們的姓名,地址和電話號碼存儲在電子表格的多行中。

隨著業務的增長和要跟蹤的訂單數量的增加,這些冗餘數據將佔用不必要的空間,並通常會降低銷售跟蹤系統的效率。您可能還會遇到數據完整性問題。例如,不能保證每個欄位都將填充正確的數據類型,或者每次都以完全相同的方式輸入名稱和地址。

與上圖中的關係資料庫一樣,使用關係資料庫可以避免所有這些問題。您可以設置兩個表,一個用於訂單,一個用於客戶。「客戶」表將包括每個客戶的唯一ID號,以及我們已經跟蹤的姓名,地址和電話號碼。「訂單」表將包括您的訂單號,日期,應付金額,跟蹤號,並且在每個客戶數據項中沒有一個單獨的欄位,而是一個客戶ID列。

這使我們能夠提取任何給定訂單的所有客戶信息,但是我們只需要在資料庫中存儲一次即可,而不必為每個訂單再次列出它。

我們的數據集

讓我們開始看看我們的資料庫。該資料庫有兩個表,trips和stations。首先,我們只看trips表。它包含以下列:

1)id —用作每次旅行的參考的唯一整數

2)duration —行程時間,以秒為單位

3)start_date —旅行開始的日期和時間

4)start_station—一個整數,與該行開始於的車站的表中的id列相對應stations

5)end_date —旅行結束的日期和時間

6)end_station —行程終點站的「 id」

7)bike_number —旅途中所用自行車的Hubway唯一標識符

8)sub_type—用戶的訂閱類型。"Registered"對於具有成員資格"Casual"的用戶,對於沒有成員資格的用戶

9)zip_code —用戶的郵政編碼(僅適用於註冊會員)

10)birth_date —用戶的出生年份(僅適用於註冊會員)

11)gender —用戶的性別(僅適用於註冊會員)

我們的分析

有了這些信息和我們將很快學習的SQL命令,以下是我們在共享單車數據分析的SQL設計中將嘗試回答的一些問題:

1)最長旅行的持續時間是多少?

2)「註冊」用戶進行了多少次旅行?

3)平均旅行時間是多少?

4)註冊用戶或臨時用戶旅行更長嗎?

5)大多數旅行中使用哪輛自行車?

6)30歲以上的用戶平均旅行時間是多少?

我們將用來回答這些問題的SQL命令是:

1)SELECT

2)WHERE

3)LIMIT

4)ORDER BY

5)GROUP BY

6)AND

7)OR

8)MIN

9)MAX

10)AVG

11)SUM

12)COUNT

安裝與設定

就共享單車數據分析的SQL設計而言,我們將使用一個名為SQLite3的資料庫系統。從2.5版開始,SQLite已經成為Python的一部分,因此,如果您安裝了Python,則幾乎肯定也會安裝SQLite。如果尚未安裝Python和SQLite3庫,則可以使用Anaconda輕鬆進行安裝和設置。

使用Python運行我們的SQL代碼可以使我們將結果導入到Pandas數據框中,從而更易於以易於閱讀的格式顯示結果。這也意味著我們可以對從資料庫中提取的數據進行進一步的分析和可視化,儘管這超出了共享單車數據分析的SQL設計的範圍。

另外,如果我們不想使用或安裝Python,則可以從命令行運行SQLite3。只需從SQLite3網頁下載「預編譯的二進位文件」,然後使用以下代碼打開資料庫:

在這裡,我們只需鍵入要運行的查詢,我們將在終端窗口中看到返回的數據。

使用終端的另一種方法是通過Python連接到SQLite資料庫。這將使我們能夠使用Jupyter筆記本,以便我們可以在格式整齊的表中查看查詢的結果。

為此,我們將定義一個函數,該函數將查詢(存儲為字符串)作為輸入並將結果顯示為格式化的數據框:

當然,我們不必在SQL中使用Python。如果您已經是R程式設計師,那麼我們的R用戶SQL基礎知識課程將是一個不錯的起點。

選擇

我們將使用的第一個命令是SELECT。SELECT將幾乎是我們編寫的每個查詢的基礎-它告訴資料庫我們要查看哪些列。我們既可以按名稱指定列(用逗號分隔),也可以使用通配符*返回表中的每一列。

除了要檢索的列之外,我們還必須告訴資料庫從哪個表獲取它們。為此,我們使用關鍵字,FROM後跟表名。例如,如果我們想看到的start_date,並bike_number在每行trips表中,我們可以使用下面的查詢:

在此示例中,我們從SELECT命令開始,以便資料庫知道我們希望它為我們找到一些數據。然後,我們告訴資料庫我們對start_date和bike_number列感興趣。最後,我們過去FROM使資料庫知道我們要查看的列是trips表的一部分。

編寫SQL查詢時要意識到的重要一件事是,我們希望每個查詢都以分號(;)結尾。並非每個SQL資料庫實際上都需要這樣做,但是有些確實需要,所以最好養成這種習慣。

限制

開始在Hubway資料庫上運行查詢之前,我們需要知道的下一個命令是LIMIT。LIMIT只是告訴資料庫您希望它返回多少行。

SELECT我們在上一節中查看的查詢將為表中的每一行返回所請求的信息trips,但是有時這可能意味著大量數據。我們可能不想要所有這些。相反,如果我們想看到的start_date,並bike_number在資料庫中的第一個五年的旅行,我們可以添加LIMIT到我們的查詢,如下所示:

我們僅添加了LIMIT命令,然後添加了一個數字,該數字表示我們要返回的行數。在本例中,我們使用5,但您可以將其替換為任何數字,以獲取正在處理的項目的適當數據量。

LIMIT在共享單車數據分析的SQL設計中,我們將在Hubway資料庫中的查詢中使用很多–該trips表包含超過150萬行數據,我們當然不需要顯示所有數據!

讓我們在Hubway資料庫上運行第一個查詢。首先,我們將查詢存儲為字符串,然後使用我們先前定義的函數在資料庫上運行它。看下面的例子:

該查詢*用作通配符,而不是指定要返回的列。這意味著該SELECT命令已為我們提供了trips表中的每一列。我們還使用該LIMIT函數將輸出限制為表的前五行。

您會經常看到人們在查詢中使用大寫的逗號(這是我們在共享單車數據分析的SQL設計中將遵循的約定),但這主要是優先考慮的問題。大寫字母使代碼更易於閱讀,但實際上絲毫不影響代碼的功能。如果您希望使用小寫命令編寫查詢,則查詢仍將正確執行。

我們前面的示例返回trips表中的每一列。如果只對duration和start_date列感興趣,則可以按如下所示用列名替換通配符:

訂購

在回答第一個問題之前,我們需要知道的最終命令是ORDER BY。此命令使我們可以對給定列上的資料庫進行排序。

要使用它,我們只需指定要排序的列的名稱。默認情況下,ORDER BY按升序排序。如果我們想指定資料庫應該排序的順序,我們可以添加關鍵字ASC以升序或DESC降序。

例如,如果我們想將trips表從最短duration到最長排序,我們可以在查詢中添加以下行:

有了SELECT,LIMIT和ORDER BY命令之後,我們現在可以嘗試回答第一個問題:最長旅行的持續時間是多少?

要回答這個問題,將其分為幾個部分並確定我們需要解決每個部分的命令會很有幫助。

首先,我們需要從表的duration列中提取信息trips。然後,要找出最長的行程,我們可以duration按降序對列進行排序。我們可能會通過以下方式提出一個查詢,該查詢將獲取我們正在尋找的信息:

1)使用SELECT檢索duration列FROM的trips表

2)使用ORDER BY排序的duration列,並使用DESC關鍵字來指定要在降序排序

3)用於LIMIT將輸出限制為1行

以這種方式使用這些命令將返回持續時間最長的單行,這將為我們提供問題的答案。

需要注意的另一件事-隨著查詢添加更多命令並變得更加複雜,如果將它們分成多行,您可能會更容易閱讀。就像大寫一樣,這是個人喜好問題。它不會影響代碼的運行方式(系統只是從頭開始讀取代碼,直到到達分號為止),但它可以使您的查詢更清晰,更易於理解。在Python中,我們可以使用三引號將字符串分隔為多行。

讓我們繼續運行此查詢,找出最長的旅程持續了多長時間。

現在我們知道最長的旅程持續了9999秒,或者說是166分鐘多一點。但是,最大值為9999時,我們不知道這是否真的是最長行程的長度,或者資料庫是否僅設置為允許四位數的數字。

如果確實由資料庫縮短了特別長的行程,那麼我們可能期望在9999秒處看到很多行程,它們達到了極限。讓我們嘗試運行與之前相同的查詢,但是將調整LIMIT為返回10個最長持續時間,以查看是否為這種情況:

我們在這裡看到的是,在9999年並沒有一整趟旅行,因此看起來我們並沒有切斷持續時間的高端,但是仍然很難判斷這是否是真正的行程跳閘或最大允許值。

Hubway會為30分鐘以上的騎行收取額外費用(某人保持9999秒的自行車將不得不支付25美元的額外費用),因此他們認為4位數字足以追蹤大多數騎行是合理的。

哪裡

前面的命令非常適合提取特定列的排序信息,但是如果我們要查看數據的特定子集,該怎麼辦?就是這樣WHERE。WHERE命令允許我們使用邏輯運算符指定應返回的行。例如,您可以使用以下命令返回bike的每次旅行B00400:

您還會注意到,我們在此查詢中使用引號。那是因為bike_number儲存為字串。如果該列包含數字數據類型,則不需要引號。

讓我們編寫一個查詢,該查詢WHERE用於返回trips表中每一行的每一列,這些查詢的duration時間超過9990秒:

如我們所見,此查詢返回了14個不同的行程,每個行程持續9990秒或更長。關於此查詢的突出之處是,除一個結果外,所有結果都具有sub_type的"Casual"。也許這表明"Registered"用戶更了解長途旅行的額外費用。也許Hubway可以更好地向休閒用戶傳達其價格結構,以幫助他們避免超額收費。

我們已經知道,即使是SQL的初學者級命令也可以如何幫助我們回答業務問題並在數據中尋找見解。

返回到WHERE,我們也可以WHERE使用AND或在子句中組合多個邏輯測試OR。例如,如果在我們之前的查詢中,共享單車數據分析的SQL資料庫設計https://www.aaa-cg.com.cn/data/2586.html我們只想返回duration超過9990秒的行程,並且還具有已sub_type註冊的行程,則可以AND用來指定這兩個條件。

這是另一個個人喜好建議:使用括號分隔每個邏輯測試,如下面的代碼塊所示。這不是代碼正常運行所必需的,但是括號會隨著您增加複雜性而使您的查詢更容易理解。

現在運行該查詢。我們已經知道它只能返回一個結果,因此應該容易檢查我們是否正確:

我們在帖子開頭提出的下一個問題是「'註冊'用戶進行了多少次旅行?」 為了回答這個問題,我們可以運行與上面相同的查詢,並修改WHERE表達式以返回sub_type等於的所有行,'Registered'然後對它們進行遞增計數。

但是,SQL實際上有一個內置命令來為我們進行計數COUNT。

COUNT使我們可以將計算轉移到資料庫,從而省去了編寫額外腳本來計算結果的麻煩。要使用它,我們只需要添加(COUNT(column_name)而不是添加)您想要的列即可SELECT,如下所示:

在這種情況下,我們選擇對哪一列進行計數都沒有關係,因為每一列都應該有查詢中每一行的數據。但是有時查詢可能缺少某些行的值(或「空」)。如果不確定一列是否包含空值,則可以COUNT在該id列上運行-該id列永遠不會為空,因此我們可以確保計數不會遺漏任何內容。

我們還可以使用COUNT(1)或COUNT(*)來計數查詢中的每一行。值得注意的是,有時我們實際上可能想COUNT在具有空值的列上運行。例如,我們可能想知道資料庫中有多少行缺少一列的值。

讓我們看一個查詢來回答我們的問題。我們可以SELECT COUNT(*)用來計算返回的總行數,並WHERE sub_type = "Registered"確保只計算註冊用戶的旅行次數。

該查詢有效,並且已返回我們問題的答案。但是列標題不是特別描述性的。如果其他人看這張桌子,他們將無法理解它的含義。如果我們想使結果更具可讀性,可以使用AS別名(或暱稱)作為輸出。讓我們重新運行上一個查詢,但給我們的列標題加上別名Total Trips by Registered Users:

匯總功能

COUNT這不是SQL掌握的唯一數學技巧。我們也可以使用SUM,AVG,MIN和MAX分別返回列的求和,平均值,最小值和最大值。這些與COUNT一起被稱為集合函數。

因此,要回答我們的第三個問題,「平均旅行持續時間是多少?」 ,我們可以使用列AVG上的函數duration(再次使用AS,為輸出列起一個更具描述性的名稱):

事實證明,平均旅行持續時間是912秒,大約是15分鐘。這是有道理的,因為我們知道Hubway會對30分鐘以上的行程收取額外費用。該服務是為騎手短途單程旅行而設計的。

接下來的問題是,註冊用戶或臨時用戶旅行更長的時間呢?我們已經知道一種解決此問題的方法-我們可以SELECT AVG(duration) FROM trips使用WHERE子句運行兩個查詢,這些子句將一個限制到"Registered"一個,一個限制到"Casual"用戶。

不過,讓我們以不同的方式來做。SQL還包括使用GROUP BY命令在單個查詢中回答此問題的方法。

通過...分組

GROUP BY 根據特定列的內容將行分為幾組,並允許我們在每個組上執行聚合函數。

為了更好地了解其工作原理,讓我們看一下該gender專欄。每行可以有三個可能的值一個gender列,"Male","Female"或Null(丟失;我們沒有gender對普通用戶的數據)。

當使用時GROUP BY,資料庫將根據gender列中的值將每一行分成不同的組,就像我們將一副紙牌分成不同的花色一樣。我們可以想像製造兩堆,所有雄性之一,所有雌性之一。

一旦我們擁有兩個獨立的堆,資料庫將依次對它們中的每一個執行查詢中的任何聚合函數。COUNT例如,如果使用,則查詢將計算每個堆中的行數,並分別返回每個堆的值。

讓我們詳細介紹如何編寫查詢來回答我們的問題,即註冊用戶或臨時用戶是否需要更長的行程。

1)與到目前為止的每個查詢一樣,我們將從SELECT告訴資料庫想要查看哪些信息開始。在這種情況下,我們需要sub_type和AVG(duration)。

2)我們還將包括GROUP BY sub_type按訂閱類型分離數據,並分別計算註冊用戶和臨時用戶的平均值。

當我們將它們放在一起時,代碼如下所示:

完全不同!平均而言,註冊用戶的出行時間約為11分鐘,而休閒用戶每次出行的時間則接近25分鐘。註冊用戶可能會進行更短,更頻繁的旅行,這可能是他們上下班的一部分。另一方面,休閒用戶每次旅行花費的時間大約是兩倍。

休閒用戶可能來自人口統計學(例如旅遊者),他們更傾向於長途旅行,以確保他們四處逛逛並看到所有景點。一旦我們發現了數據的差異,公司便可以通過多種方式對其進行調查,以更好地了解造成這種情況的原因。

但是,出於共享單車數據分析的SQL設計的目的,讓我們繼續。我們的下一個問題是旅行次數最多的是哪輛自行車?我們可以使用非常相似的查詢來回答這個問題。看下面的示例,看看是否可以弄清楚每行的內容-我們將逐步進行操作,以便檢查是否正確:

從輸出中可以看到,自行車B00490出行最多。讓我們來看看如何到達那裡:

1)第一行是一個SELECT子句,告訴資料庫我們要查看bike_number列和每行的計數。它還AS用於告訴資料庫以更有用的名稱顯示每一列。

2)第二行用於FROM指定我們要查找的數據在trips表中。

3)第三行是開始有些棘手的地方。我們GROUP BY用來告訴第COUNT1行的函數分別計算每個值bike_number。

4)在第四行,我們有一個ORDER BY子句對表格進行降序排序,並確保最常用的自行車在頂部。

5)最後,我們LIMIT將輸出限制為第一行,因為我們如何對第四行的數據進行排序,所以我們知道這將是旅行次數最多的自行車。

算術運算符

我們的最後一個問題比其他問題更加棘手。我們想知道30歲以上註冊會員的平均旅行時間。

我們可以算出30歲以下的人出生的那一年,然後再插入,但是一個更優雅的解決方案是直接在查詢中使用算術運算。SQL允許我們使用+,-,*和/在一次對整個列執行運算。

加入

到目前為止,我們一直在研究僅從trips表中提取數據的查詢。但是,SQL之所以如此強大是因為它使我們能夠從同一查詢中的多個表中提取數據。

我們的自行車共享資料庫包含第二個表stations。該stations表包含有關Hubway網絡中每個站點的信息,並包括id該trips表引用的列。

不過,在開始研究該資料庫中的一些實際示例之前,讓我們回顧一下較早的假設訂單跟蹤資料庫。在該資料庫中,我們有兩個表orders和customers,它們通過customer_id列連接。

假設我們要編寫一個查詢,該查詢返回資料庫中的每個訂單的order_number和name。如果它們都存儲在同一個表中,則可以使用以下查詢:

不幸的是,order_number列和name列存儲在兩個不同的表中,因此我們必須添加一些額外的步驟。讓我們花一點時間考慮一下資料庫在返回所需信息之前需要了解的其他事項:

1)該order_number列在哪個表中?

2)該name列在哪個表中?

3)orders表中的信息如何與表中的信息連接customers?

要回答這些問題中的前兩個,我們可以在SELECT命令中包括每列的表名。我們這樣做的方法就是簡單地寫一個表名和列名,用.。分隔。例如,代替SELECT order_number, name我們會寫SELECT orders.order_number, customers.name。在此處添加表名稱可以通過告訴資料庫要查找的表來幫助資料庫查找我們要查找的列。

為了告訴資料庫orders和customers表如何連接,我們使用JOIN和ON。JOIN指定應該連接的表,並ON指定每個表中的哪些列相關。

我們將使用內部聯接,這意味著將僅在中指定的列匹配的地方返回行ON。在此示例中,我們將要JOIN在FROM命令中未包含的任何表上使用。因此,我們可以使用FROM orders INNER JOIN customers或FROM customers INNER JOIN orders。

如前所述,這些表連接customer_id在每個表的列上。因此,我們將要用來ON告訴資料庫,這兩列引用的是這樣的東西:

我們再次使用.來確保資料庫知道這些列中的每一個都在哪個表中。因此,當我們將所有這些放在一起時,我們得到的查詢如下所示:

該查詢將返回資料庫中每個訂單的訂單號以及與每個訂單相關聯的客戶名稱。

回到我們的Hubway資料庫,我們現在可以編寫一些查詢以JOIN進行實際操作。

在開始之前,我們應該看一下表中的其餘列stations。這是一個查詢,向我們顯示了前5行,因此我們可以看到stations表的外觀:

1)id—每個工作站的唯一標識符(對應於表中的start_station和end_station列trips)

2)station —站名

3)municipality —車站所在的城市(波士頓,布魯克林,劍橋或薩默維爾)

4)lat —車站的緯度

5)lng —車站的經度

6)哪些車站最經常往返?

7)在不同的城市中有多少次旅行開始和結束?

與以前一樣,我們將嘗試回答數據中的一些問題,從哪個站是最頻繁的起點開始?讓我們逐步進行操作:

1)首先,我們要使用SELECT返回表中的station列stations和COUNT行數。

2)接下來,我們指定我們想要的表JOIN並告訴資料庫連接它們ON的start_station列trips表和id列stations的表。

3)然後我們進入查詢的內容-我們在表格中GROUP BY的station列,stations以便我們COUNT將分別計算每個車站的行程次數

4)最後,我們可以ORDER BY我們COUNT並LIMIT輸出到結果的管理的數量

如果您熟悉波士頓,您將了解為什麼這些是最受歡迎的電臺。南站是該市主要的通勤火車站之一,查爾斯街沿河延伸,靠近一些風景優美的路線,博伊爾斯頓和信標街就在市中心,靠近許多辦公大樓。

我們要看的下一個問題是往返最常用的車站是?我們可以使用與以前幾乎相同的查詢。我們將以相同的方式SELECT使用相同的輸出列和JOIN表,但是這次我們將添加一個WHERE子句以限制我們COUNT的行程start_station與相同end_station。

我們可以看到,這些站點的數量與上一個問題相同,但數量要低得多。最繁忙的站點仍然是最繁忙的站點,但是總體而言,較低的站點表明人們通常在使用Hubway自行車從A點到達B點,而不是在返回起點之前先騎自行車一會兒。

這裡有一個明顯的不同-Esplande並不是我們第一個查詢中總體上最繁忙的車站之一,它似乎是往返行程中最繁忙的車站。為什麼?好吧,一張圖片值一千個字。當然,這看起來像是騎自行車的好地方:

接下來的問題是:在不同的城市開始和結束多少次旅行?這個問題使事情更進一步。我們想知道在不同的地方開始和結束了多少次旅行municipality。為了實現這一目標,我們需要JOIN的trips表到stations表的兩倍。一旦ON該start_station列,然後ON在end_station列。

為此,我們必須為該stations表創建一個別名,以便能夠區分與關聯的start_station數據和與關聯的數據end_station。我們可以使用與為各個列創建別名以使其更直觀地顯示名稱的方式完全相同AS。

例如,我們可以使用下面的代碼JOIN的stations表到trips使用的「開始」別名表。然後,我們可以將「開始」與我們的列名稱結合使用,.以引用來自此特定對象的數據JOIN(而不是第二個,JOIN我們將處理ON該end_station列):

這是我們運行最終查詢時的樣子。請注意,我們曾經<>表示「不等於」,但!=也可以使用。

這表明,在150萬次旅行中,大約有300,000次(或20%)在與開始的城市不同的地方結束–進一步的證據表明,人們大多使用Hubway自行車進行相對較短的旅行,而不是在城鎮之間進行較長的旅行。

如果您已經做到了,那麼恭喜!您已經開始掌握SQL的基礎知識。我們已經討論了許多重要的命令,SELECT,LIMIT,WHERE,ORDER BY,GROUP BY和JOIN,以及骨料和算術功能。這些將為您繼續SQL之旅提供堅實的基礎。

下一步

在完成本入門SQL教程之後,您現在應該能夠找到自己感興趣的資料庫並編寫查詢以提取信息。好的第一步可能是繼續使用Hubway資料庫,以了解您還能找到什麼。以下是您可能想嘗試回答的其他一些問題:

1)有多少趟旅程產生了額外的費用(持續時間超過30分鐘)?

2)哪輛自行車使用的時間最長?

3)註冊用戶或臨時用戶是否往返更多?

4)哪個城市的平均停留時間最長?

如果您想更進一步,請查看我們的交互式SQL課程,該課程涵蓋了您從入門到高級SQL所需的一切知識,適用於數據分析師和數據科學家的工作。在數據科學課程頁面上的SQL菜單下查找所有交互式SQL課程產品的完整列表。

相關推薦

大數據分析R為什麼要學習SQL知識

大數據分析師的溝通技巧

大數據分析R語言7種數據可視化方式

人工智慧機器學習的慘痛教訓

大數據分析為什麼要學習R中的線性建模

相關焦點

  • 共享單車的心臟-詳解共享單車核心原理
    共享單車的風靡,相信大家都有體驗過了,其原理功能大概一名理科生或者有著電子科技愛好的人大概都能猜出來,但是作為一名嵌入式工程師或做電子行業的一定會對裡面核心模塊感興趣,那今天我從網上搜集的一些信息(畢竟不敢自己拆...),和大家一起解開共享單車的秘密。
  • R+SQL Server的大數據管理
    令人興奮的是,微軟在2016年6月正式發布的SQL Server 2016將支持R語言編程(包括大數據的算法)。據了解,這次更新是微軟對Revolution Analytics公司收購的結果,該公司此前的產品Revolution R就是一款強大的大數據分析工具。所以說SQL Server 2016代表了微軟向大數據及機器學習領域邁出的第一步。
  • 共享經濟案例—摩拜單車模式及SWOT分析
    此種共享更多的是通過網際網路作為媒介來實現的。  二、摩拜單車案例分析  A、摩拜單車是什麼?  摩拜單車,英文名mobike,2016年在上海上線,是一款網際網路短途出行解決方案,是無樁借還車模式的智能硬體,在APP上實名註冊,並繳納299元保障金,即可租用。人們通過智慧型手機就能快速租用和歸還一輛摩拜單車,用可負擔的價格來完成一次幾公裡的市內騎行。
  • 大數據分析工程師入門9-Spark SQL
    早期Spark的切入點是SparkContext,通過它來創建和操作數據集,對於不同的API需要不同的context。比如:使用sql-需要sqlContext,使用hive-需要hiveContext,使用streaming-需要StreamingContext。
  • 10年前就出現的共享單車,為啥在中國火了?共享單車的前世今生
    第二代共享單車於1995年在丹麥哥本哈根推出,為定製車輛,設有固定的樁式站點,使用時需投入一枚硬幣解鎖,免費使用,車輛可歸還到任意站點,歸還後退回硬幣。僅在3年以後,法國雷恩就出現了第三代共享單車。該類型的單車仍然採用定製化設計的車輛,設有固定的樁式站點,使用智慧卡(需提供個人信息註冊)取車,前30分鐘免費使用,超出時間收取少量費用。
  • 共享單車智慧調度 大數據運營破「潮汐」現象
    活動現場,通過實地演練,城管執法部門快速反應,針對共享單車早晚「潮汐」現象,聯合哈囉出行智慧運營管理,通過哈囉大腦大數據平臺科學調度、高效協同,有效解決重要堵點早晚高峰區域擁堵亂象,最大化滿足民眾高峰期交通出行需求。
  • 共享單車競爭發展對策及建議
    郭建明針對共享單車面臨的現狀、出現的意義、存在的問題進行經濟學分析,指出共享單車各品牌商應優化生產設計並創建自己的核心競爭力,合理布點以提高使用頻率,密切關注相關法律規定以制定出合適的運營方案,從而提高整個共享單車行業的資源利用效率、降低投資風險。
  • Python數據分析:pandas讀取和寫入數據
    我的公眾號是關於自己在數據分析/挖掘學習過程中的一些技術和總結分享,文章會持續更新......繼續深入學習pandas相關操作,數據讀取寫入、分組、合併,轉換等等。前面一篇文章裡已經寫了關於描述性統計以及常用的基本操作。接下來的一段時間裡,我將陸續地去掌握並輸出。這篇文章是關於數據讀取與寫入的知識點。
  • 共享單車的連接方式探討
    作者/ 何暉 (IHS Markit 高級分析師)本文引用地址:http://www.eepw.com.cn/article/201709/364866.htm摘要:在2017年8月「IHS Markit領先技術報告論壇——中國站」上,IHS Markit高級分析師何暉女士分析了共享單車的連接方式及相關
  • 遠程連接不上SQL資料庫6大可能的問題原因列舉
    打開APP 遠程連接不上SQL資料庫6大可能的問題原因列舉 發表於 2018-10-27 09:31:40 3打開允許遠程連接 1、打開SQL Server Management Studio 2、打開資料庫屬性
  • 共享單車給企業、打工者、城市帶來怎樣的改變?
    一位創業者感嘆:他們的單車每天都會消失幾千輛,手頭兒的錢有點兒燒不起。如前文所述,摩拜單車的設計更加穩固、智能鎖和定位系統更加完善,市民於是對摩拜更加愛護。所以,第一代單車給後來者帶來最重要的啟示就是:要花合理的成本把單車的品質做好,市民會更加愛護,也更有利於自己的資產管理。於是如你所見,如今單車新三巨頭:青桔、美團、哈羅所提供的單車,不僅美觀時尚,而且車身堅固、GPS定位系統穩定。
  • 共享單車使用原理的全面解讀—小強單車
    用戶通過手機APP可以查看附近的共享單車,並進行預約,然後通過地圖引導找到單車,並通過掃二維碼遠程開鎖進行騎車,其實很多用戶好奇為什麼共享單車只需要通過手機端掃一掃就可以開鎖騎走呢。  共享單車使用app開可以完成付費和行駛線路記錄,其實是通過車身鎖內集成了嵌入式晶片,GPS 模塊和 SIM 卡,隨時監控自行車在路上的具體位置,這裡就給大家解讀共享單車背後的使用原理。
  • 共享單車快慢分季節?紐約公交趕不上三輪?
    更多的數據顯示,計程車在一段路程中出行時間至少比平均耗時多5分鐘的概率比共享單車高2倍,耗時多10分鐘則比共享單車高3.5倍。所以共享單車出行在很多減少極端情況的案例中,也表現的更出色。   為什麼在2009年後,計程車越來越慢?
  • 共享單車併購背後有何玄機
    他說後來自己把股份賣給了戰略投資人,「財務投資人主要的目的是為了賺點錢,但戰略投資人更是為了看數據」。他的一番話不僅道出了共享單車兩大巨頭的發展現狀,更透露了美團等接盤者的目的。在朱嘯虎退出後,ofo和摩拜各自艱難發展,融資也從一個月兩次降到了8個月一次。如今,摩拜被美團收購,ofo將車輛抵押給阿里借款17億元,共享單車企業的日子似乎不再好過。
  • 共享單車困局:共享單車為何成了無人認領的「殭屍車」?
    在一些街道拐角處、地鐵附近或者公交車站周邊的空地上也時不時可以看到橫七豎八、堆放在一起的數量驚人的ofo或摩拜或其他品牌的共享單車,以致於被大家戲稱為共享單車「墳場」。實際上,這些單車並非都是損毀的。在大興舊宮一個停車場內,堆放著大量的、至少三個品牌的共享單車,記者從中挑選了幾輛摩拜和ofo單車,嘗試了一下,均能開鎖並正常行駛。
  • 大數據分析工程師面試集錦3-SQL/SparkSql/HiveQL
    大數據分析工程師80%的時間都在與SQL打交道,通過SQL完成業務方的各種臨時性需求分析和常規性報表統計。熟練的SQL技能能夠大大提高工作效率。本文將SQL/SparkSql/HiveQL放在一起來梳理一份常見題型的面試題庫。
  • 「共享單車」註定是智慧出行的一部分
    如果想知道單車應該在我們出行中佔有什麼地位,我們就需要先分析下我們的出行方式(這裡指交通需求,不包含徒步、騎行等)以及影響出行方式的因素。這裡主要分析騎車出行,故簡化以上因素,且在單車總是很容易獲取的情況下,大概歸納出如下表格(顏色越深,選擇騎車的可能性越大,白色是我認為此環境下選擇騎車的概率小於20%):
  • eclipse如何使用JDBC向資料庫插入數據!
    eclipse如何使用JDBC向資料庫插入數據!1.在工程中新建InsertTest.java類2.向資料庫中插入數據總共分為4步   1.獲取資料庫連接   2.準備sql語句   3.執行插入      3.1使用connection的createStatement()方法獲取Statement對象      3.2調用Statement對象的executeUpdate(sql)方法執行插入操作   4.關閉資料庫連接
  • 來看看共享單車中的神奇科技
    從2016年下半年開始,共享單車如雨後春筍一般遍布大街小巷,為坐地鐵上下班的同學解決了最後1公裡的難題。有的同學就會好奇,App是怎麼控制單車開鎖的呢?單車開鎖和關鎖的時候會有滴滴的提示聲音,那電量是怎麼供應的呢?今天我們一起來看一下。
  • 廣州市共享單車運營商招標結果出爐 青桔單車、摩拜等中標
    近日,廣州市2019年網際網路租賃自行車運營商招標評標結果公布,青桔單車成功中標,份額為10萬。同時中標的還有摩拜和哈囉。公示日期為2019年6月4日至2019年6月10日。據了解,本次招標公告4月29日正式發布,通過公開招標方式,確定3家網際網路租賃自行車運營商,未來3年內廣州市網際網路租賃自行車投放運營配額為40萬輛。