帶你讀《機器學習即服務 将Python機器學習創意快速轉變為 雲端Web應用程式》之二：在Azure上進行共享單車 回歸模型智能預測

點選檢視第一章 點選檢視第三章

第2章

在Azure上進行共享單車回歸模型智能預測

本章中，我們将介紹如何在微軟Azure公有雲上，利用雲端回歸系數功能建構一個實作自行車租賃需求的互動式Web應用。

作為本書介紹的第一個智能項目，我們将使用回歸模組化方式來模拟Capital Bikeshare系統中的自行車共享資料集，并了解溫度、風和時間等變量是如何影響美國中大西洋地區的自行車租賃需求的，如圖2-1所示。

加州大學爾灣分校的UCI機器學習庫慷慨貢獻了本章所需的資料集（

https://archive.ics.uci.edu/ml/datasets/bike+sharing+dataset

）。在進行本章實驗前，請通路UCI網站下載下傳相關資料集。

提示：　請通路www.apress.com/9781484238721 ，單擊“Download source code”按鈕，跳轉至GitHub網站，下載下傳第2章所需檔案。推薦使用Jupyter Notebook打開chapter2.ipynb檔案，以配合閱讀本章内容。

2.1　共享單車租賃需求回歸系數分析

本章中，我們将建構一個簡單直覺的模型，并使其與不同的環境因素進行互動，進而了解這些環境因素是如何影響自行車租賃需求的。對使用者來說，這會是一種很好的方式，因為這種方式可以讓他們确認關于什麼會讓他們的使用者租賃或不租賃自行車的直覺判斷。當然，在有些情況下，他們也會感到很驚訝（比如，冬天騎車的人居然會比夏天還多—本章中，我們将讓你親眼看到這個現象）。

這個Web應用背後的“大腦”是一個線性回歸模型（linear regression model）。它能夠發現曆史資料集與模型輸出結果之間的線性關系。利用這個原理，通過線性回歸模型，我們就可推斷随着時間推移和不同環境參數的變化，自行車租賃在需求上的變化。最終我們希望看到的是，這個模型能否幫助我們預測未來的自行車租賃需求。

記住一點，無論何時，隻要你打算将一個Python模型擴充到Web應用，那麼在添加任何建構Web應用程式所需的額外層之前，必須解決該模型中目前的所有問題和缺陷（bug）。在将任何應用或内容移至雲端前，請先把所有簡單問題解決掉！遵循這條建議，後續會減少你很多不必要的麻煩。

2.2　探索共享單車原始資料集

雖然是一種興起不久的服務，共享單車已經受到極大歡迎。騎手使用一部移動手機，下載下傳安裝APP，就可線上注冊登入，并查找定位到周邊自行車的位置，然後線上租賃并把車騎走！這種服務模式建立了一個全新的生态系統，不需要人與人之間面對面的互動，就可以享受到自行車租賃服務。根據人工智能與決策支援實驗室的Hadi Fanaee-T的說法（來自UCI機器學習資料集資訊庫講義筆記）：

“與公共汽車或地鐵等其他交通服務相反，共享單車模式中，騎行時長、出發和到達位置在系統中都被明确記錄。這一功能将自行車共享系統變成了虛拟傳感器網絡，利用這個網絡，可以感覺到一個城市的移動性。是以，通過監測這些資料，城市中發生的很多重要事件都有希望被監控到。”

下載下傳的資料集包括兩部分：hour.csv和day.csv，特征細節參見表2-1。

2.2.1　下載下傳UCI機器學習庫資料集

你可以使用Python指令行或者手工方式，從UCI的機器學習資料倉庫中直接下載下傳資料集。資料集下載下傳位址為

。下載下傳到的資料中包含三個檔案：

• day.csv
• hour.csv
• Readme.txt

在自行車租賃資料中，日資料集day.csv有731行，小時資料集hour.csv有17 379個記錄。

2.2.2　Jupyter Notebook配置使用

在本書中，每一章都對應着有一個Jupyter記事本檔案。在開始使用本章的記事本檔案前，我們首先來回顧一些基礎知識。從GitHub上下載下傳源代碼檔案後，打開終端視窗，然後進入chapter2目錄。在這個目錄中，你将看到兩個檔案和一個檔案夾，如圖2-2所示。

requirements_jupyter.txt檔案中包含了運作本章Jupyter記事本檔案所需的Python庫。通過運作“pip3”指令，你可以快速安裝依賴庫檔案（代碼清單2-1）。

圖2-2中，chapter2.ipynb檔案就是第2章的Jupyter Notebook檔案。Jupyter Notebook檔案的打開方式很多，最流行的是使用“jupyter notebook”指令（代碼清單2-2）。如果在打開過程中出現問題，請參考Jupyter的官方文檔。

此指令将會打開一個浏覽器視窗，浏覽器中會顯示預設路徑下的全部檔案清單，單擊chapter2.ipynb檔案超連結，如圖2-3所示。

然後，浏覽器将打開一個新的Tab視窗和相應的Notebook界面，其中包含了與本章内容相關的全部探索實驗代碼。本書全部代碼都基于Python 3.x編寫。如果你使用其他Python版本，則需要調整部分代碼片段。一旦你在浏覽器上打開了對應章節的Notebook，那麼準備工作就一切就緒了。在打開的Notebook界面上，單擊第一個代碼框使其高亮，然後單擊上方的運作按鈕，如圖2-4所示。如果在執行過程中出現錯誤，則在繼續之前請先解決目前錯誤，因為Jupyter Notebook中每個代碼片段的執行都要依賴之前的執行結果（錯誤可能與Python的版本相容性有關，或者缺失了必須安裝的依賴庫檔案）。

每個章節對應的Jupyter Notebook代碼中都提供了使用Python指令行直接下載下傳資料集的方式（如果存在防火牆問題，則需要手動下載下傳）。

2.2.3　資料集探索

Python Pandas庫中的head()函數提供了檢視資料集中前面幾行的功能，如代碼清單2-3和圖2-5所示。

執行上述指令後，将看到圖2-5中所示的結果。

使用head()函數，我們會看到資料集中有日期格式、整數格式和浮點數格式的資料。另外，還能看到一些備援的特征，如date（dteday）已經通過season、yr、mnth、hr等進行了分類。是以，資料集的dteday特征是可以抛棄不用的（雖然我們會暫時保留它以滿足對資料集的探索需求）。其他一些特征似乎是多餘的，如temp和atemp，這可能需要進一步檢查核實。我們還删除了casual和registered特征，因為這些特征無法幫助我們從單個使用者的角度來模拟需求，而這正是我們要實作的Web應用程式重點。根據季節、天氣等因素預測使用者注冊數量，這可能會得到一個有趣的預測結果，但是這不符合我們目前的需求範圍，是以我們将放棄這些特征。

本章中，我們僅保留真正需要的資料特征，這可以為我們後續分析消除資料混亂，并讓我們的分析過程變得更清晰和易于了解，進而更好地實作我們資料科學和Web應用程式的目标。

Pandas Python庫中的info()函數也是檢視資料集所包含的資料類型、數量和空值的好方法（代碼清單2-5）。

可以看到，使用info()函數，目前儲存在記憶體中的所有資料都是浮點數或整數類型，并且它們都不是空值。如果我們碰巧有空值、日期資料類型或文本資料類型，則在繼續模組化之前，我們需要先解決這個問題。就目前而言，大多數模型都需要數值類型資料，就如我們這裡所擁有的一樣，到目前為止我們的資料準備一切還算順利！

2.2.4　預測結果變量分析

接下來，我們将研究用以訓練模型的結果變量cnt，即自行車租賃總數。Pandas庫中的describe()函數是了解量化資料的另一種必備工具。此處，我們将它用于結果變量（也稱為模型的标簽），如代碼清單2-6所示。

上述輸出結果中，我們可以看到，cnt的值在最小值1和最大值977之間，也就是說在每一個有記錄的小時内，自行車租賃數量最小是1輛，最多時是977輛，還可以看到，每小時平均自行車租賃數量是189.5輛。

另外，還可以确認我們所處理的是一個連續數值變量問題，是以，對于自行車租賃數量的訓練和預測，線性回歸（或者類似線性回歸的模型）将是最佳選擇。下面，我們将cnt資料繪制出來，以便更好地了解它，如代碼清單2-7和圖2-6所示。

繪制結果如圖2-6所示。

2.2.5　量化特征與租賃統計

接下來，我們将建立所有浮點類型資料的散點圖。我們将基于租賃計數來進行繪制，以顯示與租賃計數相關的潛在關系，如圖2-7和圖2-8所示。

可以看到，被租用的自行車數量和溫度之間存在某種程度的線性關系；天氣越溫暖，租來的自行車越多。還可以看到，temp和atemp這兩個特征具有相似的分布，并且可能出現備援甚至多重共線性。為了保持單一線性，我們将删除atemp特征（在圖2-9和圖2-10中，僅有temp，而沒有atemp特征）。

可以看到，特征hum或者濕度散點圖中，所有資料點幾乎都密集在一個範圍内，盡管邊緣處也出現了稀疏點。windspeed特征散點圖中，風速與自行車租賃數量之間确實顯示了非線性關系，風速越大，自行車租賃數量越少！

2.2.6　分類特征研究

在我們已下載下傳的資料集中，除了自行車租賃計數特征cnt外，其他的整數資料都具有分類特征。通過直方圖檢視時，分類資料會産生許多有趣的資訊，如圖2-11所示。

上圖中可以看到，weathersit直方圖表明好天氣的時候，人們更喜歡租賃自行車；season直方圖表明秋天是自行車租賃的高峰季節。

最後是特征hr或租賃時間直方圖，清楚顯示上班高峰時間和下午騎行時間段租賃自行車人數最多，而淩晨4點是最不受歡迎的騎行時間，如圖2-12所示。

盡管我們可以通過圖表繪制方式來了解到很多東西，但是仍然需要進行更徹底和系統的檢測，才能做出哪些特征需要保留，哪些特征需要抛棄的決策。

2.3　資料模組化準備工作

在大多數資料科學項目中，存在一個資料預處理階段，在這個階段會進行資料評估和清理，以實作資料的“模型就緒”。在清理階段，我們已經放棄了一些無用的資料特征，同時也清除了可能存在的空值，我們也不用擔心相關性或多重共線性，因為在最終模型中，我們僅會使用四個簡單的特征。

2.3.1　回歸模組化

在統計分析中，回歸模型試圖預測變量之間的關系。它主要用于分析獨立變量與依賴變量的關系，而拟合模型（fitted model）則可用于預測依賴變量的新變化。

2.3.2　簡單線性回歸

線性回歸可能是最簡單的模組化算法。它試圖解釋一個因變量和一個或多個自變量之間的關系。基本的線性回歸方程如圖2-13所示。

在上述方程中，y是因變量，0是常數，1是回歸系數，x是自變量。

2.3.3　簡單線性回歸模型

這裡，從一個簡單的多線性回歸模型開始，我們輸入所有變量并獲得均方根誤差（RMSE）。RMSE最終轉化到與結果變量（也稱為y軸标簽）相同的機關來表示誤差（即RMSE值與y值具有相同量綱），是以很容易看出模型在學習/預測自行車租賃方面表現如何，而誤差是置信區間的一種表現形式。你所關注的是盡可能希望獲得較低的RMSE值，是以我們的目标是不斷調整資料和模型，直到RMSE值停止繼續降低為止。本章中，我們所有模組化工作都基于Python scitkit-learn /sklearn庫。這是一個很了不起的Python庫，幾乎可以滿足大多數Python使用者的模組化需求。

盡管我們隻打算進行簡單的線性回歸，但我們還是用到了sklearn庫中的三個函數：train_test_split函數從原始資料中建立兩個随機資料集，并從結果中分離特征；linear_model函數運作我們的模型；mean_squared_error函數評估模型的學習效果（代碼清單2-8）。

train_test_split()函數基于使用者指定的種子參數将原始資料集拆分為兩個随機資料集。無論何時，如果想要測試不同的方法，并希望確定始終使用相同的拆分以進行不同方法的公平比較，則設定random_state種子參數是個不錯的選擇。test_size參數設定測試拆分的大小，在這裡我們将它設定為0.3或30%，是以最終結果将是資料集中70%的資料配置設定給了訓練集，而剩餘30%的資料配置設定給測試集（代碼清單2-9）。

我們事先聲明一個LinearRegression()模型，然後調用fit()函數，使用訓練資料和訓練标簽來訓練模型。執行上述代碼後，模型model_lr即經過訓練并準備好進行預測（代碼清單2-10）。

最後，我們調用函數predict()，并将配置設定為測試集的剩餘30%資料傳入函數，然後将預測标簽值輸入函數mean_squared_error()求取均方根誤內插補點。我們最終得到的RMSE值為143.08，同時我們将其作為後續預測的基準參考值。上述結果，也就是我們基于目前選擇的資料特征和拆分種子值（我們在train_test_split函數上應用的種子，這可以確定我們每次都得到相同的資料分割）所得到的結果。了解這個RMSE值的一種方式，就是我們的模型預測的偏差是143輛自行車（因為它與我們的結果變量處于相同的量綱）。考慮到每小時自行車平均租賃數量大約是190輛，是以，與簡單采用自行車租賃的全局平均值相比，我們的模型做得更好。但是，接下來我們将會看看能否再把這個均方根誤內插補點改進一點。

2.4　特征工程試驗

下面，我們将驗證能否通過幾種技術手段，擷取更好的預測模型。技術方式主要包括多項式、非線性模組化和利用時間序列。

2.4.1　多項式模組化

将多項式變換應用于一系列值中，可以線上性回歸期間實作更好的拟合。使用Python的sklearn庫，可以輕松實作多項式變換（代碼清單2-11）。

現在我們将所有特征轉換為二維（模型是多元二次函數），并計算RMSE（使用二維特征重新訓練後的模型，如代碼清單2-12所示）。

然後，進行三維多項式回歸模型預測，并計算RMSE（使用三維特征重新訓練後的模型，如代碼清單2-13所示）。

最後，進行四維多項式回歸模型預測，并計算RMSE（使用四維特征重新訓練後的模型，如代碼清單2-14所示）。

由上可以看出，使用sklearn庫的PolynomialFeatures()函數進行多項式回歸模組化是非常簡單的。當特征變量轉換為二維和三維時，RMSE值确實得到了優化，但是超過三維後，結果明顯退化。

2.4.2　建立分類資料虛拟特征

在優化預測模型方面，另一個值得嘗試的方法，就是虛拟化分類資料。這就意味着為每個特征類建立單獨列。這裡我們使用特征weathersit：它不是一個連續變量，相反，它屬于任意類别。如果将這類特征傳給預測模型，則模型會将其視為線性數值資料，而這種情況是不合理的，将mist & cloud加1并不等于snow。通過為特征weathersit建立4個新的特征列：clear、mist、snow和rain，同時給每一個新特征賦一個二進制值true/false，這樣會得到更好的預測模型。

使用Pandas函數get_dummies()很容易就實作上述功能，這裡我們将實作代碼抽象到函數裡面，以便後續Web應用更友善使用（代碼清單2-15）。

上述代碼會将每個類别分解為歸屬它自己的列。在下面的代碼片段中，我們将對season、weekday和weathersit進行dummify操作（代碼清單2-16）。

将函數應用于資料集後，每個天氣類别現在都在一個單獨的列中（忽略第一列，它是多餘的，如果第一列不是weathershit_2、weathershit_3或weathershit_4，那麼我們可以認為它是weathershit_1）。檢視dummify操作後的天氣字段（代碼清單2-17）。

輸出結果如圖2-14所示。

那麼，從分類資料中建立虛拟資料是否有助于預測模型呢（代碼清單2-18）？

可以看到，這個方法對模型預測結果改進不是很明顯，是以針對本章模型我們這裡所做的嘗試不是很合理。且不管它，我們繼續往下嘗試其他技術。

2.4.3　非線性模型試驗

作為最後一個模組化試驗，我們将上一節中的虛拟資料放到sklearn庫的“Gradient Boosting Regressor”（GBM）模型中運作。在sklearn包中從一個模型切換到另一個模型是非常簡單的，我們隻需要在記憶體中加載适當的模型并修改兩行代碼（代碼清單2-19）。

很不可思議！這是目前為止值最小的RMSE，我們将模型的預測錯誤率降低到了一半。

2.4.4　使用時間序列複雜特征

這是本章最後一個特征工程試驗了，我們的模組化靈感源自微軟的資料科學家。我們的原始資料是随着時間推移的自行車租賃總數，是以資料集是時序的。每當資料集随着時間推移記錄事件時，你都可以将其看成是一個額外的特征。例如，比起發生在一年前的事件，發生在一小時前的事件很可能更重要。時間也可以捕捉趨勢、改變需求和感覺等。我們希望建立捕捉所有這些時間變化元素的特征！

對于每一行資料，我們将添加兩項新特征：前一小時的自行車租賃總和，以及兩小時前的自行車租賃總和。這樣做的動機是，如果我們想要了解目前的自行車租賃情況，我們可以先看看一小時前發生的事情。如果一小時前的租賃情況良好，那麼目前的租賃情況也會傾向于良好，這個時間元素可以被視為鼎盛或蕭條時期、好天氣或惡劣天氣等的替身。

為了彙總每天和每小時的自行車租賃數，我們使用Pandas極其強大的groupby()函數。這裡我們提取三個字段dteday、hr和cnt，并按日期和小時對cnt進行分組（代碼清單2-20）。

輸出結果如圖2-15所示。

此函數按小時和日期來統計計數。接下來，我們建立兩個新特征，一個向前移動一行，另外一個向前移動兩行，進而為目前行提供過去一小時前和過去兩小時前的自行車租賃總量。最後，我們使用Pandas的merge()函數将這兩個特征添加到主資料幀中（代碼清單2-21）。

将這些新資料拆分，并将其運作到用GBM回歸模型（sklearn庫中的GradientBoosting-Regressor）之後，我們利用測試資料集來計算均方根誤差RMSE值（代碼清單2-22）。

哇！是不是很吃驚，RMSE值為44.43，比之前的值還要好！

2.5　簡約模型

很遺憾的是，最好的模型評估值并不意味着一切！本章中，我們需要使用一個簡單的回歸方程來進行預測。這不是通過複雜模型或過度特征資料設計可以輕松完成的事情，GBM并非線性模型，是以也沒有給我們帶來一個友善、輕量的回歸方程。此外，我們之前建立的時移模型要求我們擁有前兩個小時的預測總數，由于無法通路實時資料，是以這個模型并不适用于Web通路用戶端。

如果你的目标是建立Web應用，那麼有一點是你必須要記住的：如果最準确的預測來自極複雜的模組化技術，那你的模型将很難轉換到生産環境中。

2.5.1　簡單模型中的回歸系數提取

本節将介紹一種無須伺服器端計算即可預測需求的簡便方法。線性回歸模型并非最強大的模型，它從來也沒說過自己是最強大的。但是，線性回歸模型确實可以将相當複雜的資料提煉成極其簡單明了的線性表示。而正是這種簡單的線性表現形式，為我們的應用提供了強大動力。

學習模型系數是回歸模組化最強大的地方，這在Web應用程式設計環境中更加強大，我們完全可以依賴模型系數和簡單的回歸方程來估計自行車的租賃需求。這就使得應用程式完全可以根據客戶前端做出複雜的決策—輕量、快速并且有用！

為了得到一組回歸系數和一個簡單的回歸方程，首先我們需要訓練和測試回歸模型。當我們對預測結果、使用的特征和預測的品質感到滿意時，就可以提取此時的模型系數。另外，我們也會将模型輸入特征轉換為最基本和最具了解性的特征。下面是一個建構Web應用程式的經驗教訓：我們必須在最佳模型與生産現實之間取得平衡，如果你建立了一個了不起的模型，但沒有人可以操作它，或者沒法在生産中實時運作，那你的模型就是失敗的。

這裡我們将以Web應用程式設計為中心，盡量保持模型簡單。是以，我們僅使用4個特征：season、hr，holiday和temp。這些特征是使用者可以了解、易于擷取，同時隻使用4個特征，我們的模型會快很多。接下來，我們分别對這些特征進行模組化，并檢查對應模型的R-squared值。

2.5.2　R-Squared

R-squared是描述資料與拟合回歸線之間有多近的統計量度。它也被稱為确定系數，或多重回歸中的多重确定系數。R-squared的定義是非常直截了當的，它是線性模型預期的響應變量變化的百分比（代碼清單2-23）。

确定系數可以看成是個百分比。它可以讓你了解到，有多少資料點落在回歸方程形成的結果線上。系數越高，表明落線上内的點越多。如果系數為0.80，則表明80%的資料點落在回歸線内。

我們最希望看到的，當然是R-squared接近1（或100%）且不是負數。使用sklearn庫中的r2_score函數很簡單就可計算出R-squared值（代碼清單2-24）。

每個R-squared都是正數，我們看到hr和temp特征比season和holiday特征具有更多的變化。請記住，我們這裡是分别針對每個特征計算的R-squared。另外，還有一個接下來的好步驟在這裡沒有提及，就是把這些特征合在一起來計算R-squared值（或者為了處理多個特征而調整R-squared值）。

如前所示，我們也将對season變量進行dummify操作。如果在包括dummified後的所有特征上重新運作R-squared循環計算，那麼我們将得到以下R-squared值（代碼清單2-25）。

可以看到，上述所有R-squared值都是正數，是以在最終的Web應用程式中，我們将使用上述特征集。

2.5.3　基于回歸系數的新資料預測

前面一節中，我們已經計算出回歸模型系數，現在我們可以使用回歸方程來預測自行車租賃數量了。回歸方程是一個源自我們回歸模型的最佳線性拟合方程，該公式很常見，大多數資料統計類型的書中都會提及，如圖2-16所示。

上述公式中，y是因變量，也可以了解為我們要預測的值，在本章中，就是自行車租賃數量。0是截距，1是線的斜率，x是自變量。對于多元線性回歸情況，隻需添加更多自變量即可。

需要特别指出的是，這個公式及其系數代表了應用到模型中的資料可能産生的最小誤差。是以，當向模型中注入新資料時，我們不能立即真正意義上更改所有自變量。這點請務必記住，雖然我們在Web應用中将會允許使用者進行各種環境設定以影響自行車租賃的數量，但是這些環境參數設定可能不會立即生效。另外，我們也提供了“reset”按鈕來将所有變量重置為原始均值。

最終模型運作之後，我們需要提取截距和系數值。使用sklearn庫的linear_model函數即可輕松實作：隻需要調用intercept_和coef_參數即可擷取這兩個值（代碼清單2-26和代碼清單2-27）。

輸出結果如圖2-17所示。

然後，我們可以将這些常數配置設定給我們的Web應用程式，以便它可以反過來預測自行車租賃需求（代碼清單2-28）。

為了建構回歸方程，我們還需要擷取曆史均值。如果是歸類值，那麼我們選擇最高均值并将其設定為1，而将其他值設定為0（就如我們對season和holiday所做的一樣）（代碼清單2-29）。

現在，我們已準備好了預測自行車租賃數量所需的一切。接下來，讓我們一起來看看在上午9點時租賃數量是多少，而所有其他值保持在它們的平均值附近（代碼清單2-30）。

可以看到，得到的預測結果是，在上午9點自行車租賃數量是171輛（你的結果可能略有不同）。在實際應用中，我們将會允許使用者一次性更改多個特征值，但請記住，與原始方程值相差太多的更改可能會使模型品質下降。

2.6　共享單車租賃需求互動式Web應用設計

現在，我們來點有趣的内容，設計我們的Web應用程式。開始之前，我們需要始終牢記最終目标—我們希望與他人分享的内容以及其他人希望看到的内容是什麼？

我們将設計一個互動式Web應用程式，允許使用者自定義環境變量（時間、假日、溫度和季節），并通過互動式獲得自行車租賃數量的可視化回報。

應用程式在視覺上要做到引人注目，以便吸引使用者并讓他們在使用時保持興趣。這意味着需要将大量的精力投入消息、UI、視覺效果和互動式控件設計中，就如在收集資料和模組化時一樣。

2.6.1　代碼可讀性與擴充性摘要

在我的大多數Web應用程式中，我都會嘗試将代碼抽象為邏輯子產品。一個子產品用于處理使用者資料收集過程，另一個子產品是核心“大腦”部分，其主要負責建立回歸方程，運作模型，并傳回自行車租賃預測結果。在編譯和調試Web應用程式時，将代碼抽象到邏輯單元中将會極大地簡化你的工作。這種方式允許你對每個子產品進行單元測試，以確定所有子產品都能正常工作，或者無所事事時，作為一個消遣過程。

在本章介紹的Web應用程式中，大多數“大腦”将直接駐留在用戶端HTML首頁面中。Flask是一個Web服務架構，主要用于檢索、分析和回送自定義内容。在本章中，我們所需要做的隻是用于預測自行車租賃需求的回歸方程，是以在使用者用戶端和Web伺服器之間來回切換的情況并不多（僅有本章是此類情況，在所有其他章節中，“大腦”部分都在Web伺服器上實作，而不是用戶端的網頁上）。

2.6.2　建構本地Flask應用

在将代碼搬到雲端運作之前，先在本地試運作是很重要的。這将為你節省大量時間和免去很多頭疼的事情。首先，在我們的本地機器上做簡單的Flask練習。如果你從未在本地運作過Flask應用程式，則需要使用“pip3 install”或者OS和Python版本支援的其他工具來安裝以下Python庫：

• Flask

一旦Flask安裝完成後，打開文本編輯器，鍵入如下代碼，并将檔案儲存為hello.py（代碼清單2-31）。

在MAC/Windows上，打開一個終端/指令行（代碼清單2-32和代碼清單2-33）。

執行上述指令後，你應該看到圖2-18中所示的内容。

然後将URL“

http://127.0.0.1:5000/

”（或者終端視窗中出現的其他URL）複制到浏覽器中，你應該會看到Web應用程式已經啟動。更多的示例和提示可以參見Flask官方網站，Flask官方快速入門指南請參考

http://flask.pocoo.org/docs/0.12/quickstart

。

在上述過程中，發生了什麼事情呢？如果你對Web服務架構不熟悉，可能會覺得這有點神秘和深奧（需要指出的是，Flask是最簡單的Web架構之一），下面我們一步一步來分析整個過程。

在前面的“Hello world”示例中，所有過程都發生在“虛假”的Web伺服器端（實際上就是你的本地計算機）。Web伺服器端的工作，就是進行指令處理，并将可檢視的HTML内容傳回給發起請求的用戶端網頁。

首先，我們将Flask庫加載到記憶體中（代碼清單2-34）。

然後，我們執行個體化一個Flask會話（代碼清單2-35）。

最後，我們建立一個函數來執行某些操作，并使用路由參數對其進行裝飾，是以它知道從Web用戶端處理哪些指令。這裡，‘/’簡單地表示根頁面或者“index.html”根會話頁面（代碼清單2-36）。

很顯然，實際應用中函數功能不可能這麼簡單。它很可能會調用資料庫或者通過Representational State Transfer（REST）API調用來收集用戶端資訊并通過HTML模闆将最終内容傳回給用戶端。整個過程中，允許建立自定義資料并實作智能化，然後将其封裝起來并在複雜網頁中呈現。不論是出于何種目的，這類網頁看起來就像是純手工制作的一樣，而事實上它是由Flask動态建立的。在本書中，我們會一直使用Flask，如果你按照每章的講解進行操作，那麼你就能很好地掌握這個Web架構。

代碼段的最後部分僅用于在本地執行模式（即從本機上運作）下運作Web伺服器代碼，這裡，我們開啟Debug模式（代碼清單2-37）。

2.6.3　下載下傳運作GitHub共享單車代碼

如果還未下載下傳代碼檔案，請到GitHub下載下傳與本章相關的代碼，并找到web-application檔案夾，然後你在該檔案夾中應該看到如代碼清單2-38所示的内容。

下載下傳并解壓縮所有内容後，打開指令行視窗，進入web-application檔案夾，并通過運作“pip install -r”指令安裝所有必需的Python庫（代碼清單2-39）。

然後，運作你在“Hello World”實驗中執行的指令（運作“python3 main.py”也可以執行此操作，如圖2-19所示）。

執行後的結果應該如圖2-20所示。

2.6.4　Web應用程式調試最佳實踐

如果你沒有看到圖2-10中所示的螢幕截圖，那麼你的系統可能有問題，要麼缺少檔案或者某些庫。在Web應用程式設計領域，故障調試也是很重要的部分。這裡介紹兩個簡便方法來幫你解決問題。如果是Flask問題，并且浏覽器的顯示結果如圖2-21所示，那麼請執行以下步驟來排除故障。

要進行代碼調式，請在main.py腳本中将Flask的debug标志設定為True（通常位于檔案末尾）。這個方法僅适用于在本地執行的應用程式（代碼清單2-40）。

如果問題與Flask相關，則調試器将會捕捉它并顯示在浏覽器中，浏覽器中将會傳回更多有用的資訊，如圖2-22所示。

無論debug标志如何設定，你都會在終端或指令行視窗中看到Flask錯誤資訊，如圖2-23所示。

修複所有Flask問題後，你可能還有些前端錯誤需要處理。大多數浏覽器都會提供一些調試工具，圖2-24顯示了如何在Chrome中啟動并運作JavaScript調試器的示例（你應該也可以在你使用的浏覽器中找到相關功能）。

上述操作将在網頁右側打開一個漂亮的小調試中心，并會列出任何可能的錯誤或警告。檢查下調式中心的資訊總不會錯，以免存在警告資訊。如果使用的是其他浏覽器和裝置（如計算機、行動電話和平闆電腦），那麼測試Web應用程式的操作是類似的，如圖2-25所示。

2.7　在微軟Azure上運作Web應用程式

到目前為止，我們的模型已準備好可以到Azure上運作了。你需要一個Microsoft Azure賬戶，在撰寫本書時，Microsoft提供了200美元的信用額度，在30天内可以使用所有服務，并在12個月内可以通路試用。更多資訊請參考

https://azure.microsoft.com/en-us/free/

2.7.1　使用Git托管項目代碼

就本項目而言，你需要在本地計算機上安裝Git（

https://www.git-scm.com/downloads

上可以找到二進制安裝檔案）。如前所述，Git是一個源代碼版本控制工具，源代碼是個完全準備好的Git包，我們将會把這個源代碼Git包推送至Microsoft Azure（參見Git官網介紹部分對于Git的簡介）。

打開終端或指令行視窗，找到對應本章的web-application檔案夾，初始化Git倉庫（代碼清單2-41）。

在使用Git的過程中，随時想到運作一下“git status”是個好習慣，這可以確定你正在跟蹤的确實就是你想要的檔案（代碼清單2-42）。

将web-application檔案夾中的所有檔案添加到Git倉庫中，然後再次運作“git status”檢查是否正确（代碼清單2-43）。

然後，做一次本地Git送出，并添加一個有意義的注釋，以防止你将來想要重新通路以前的操作和檔案（代碼清單2-44）。

送出結果如圖2-26所示。

有關将Git部署到Azure App Service的更多資訊，請參考微軟官方文檔：

https://docs.microsoft.com/en-us/azure/app-service/app-service-deploy-local-git

2.7.2　微軟Azure指令行接口工具使用

本章中，我們将使用azure-cli工具來啟動和運作程式，因為這是一種啟動和控制Web執行個體的便捷方式（有關此部分設定的更多資訊，請參閱官方文檔

https://docs.microsoft.com/en-us/cli/azure/get-started-with-azure-cli

）。

對于Mac系統，進行如下設定：

對于其他作業系統，可以參考如下官方文檔：

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

第1步：登入

安裝azure-cli指令行工具後（如果本地指令行工具不友善使用，則直接使用Azure Cloud Shell即可），建立az會話。從azure-cli登入Azure。

按照提示操作，用浏覽器打開給定的URL位址，然後輸入對應的代碼，如圖2-27所示。

如果一切正常（即你有一個可用的Azure賬戶），上述操作會自動将azure-cli終端連接配接到雲伺服器。另外，一旦你獲得授權，就可以關閉浏覽器授權視窗了。記住，確定你在對應本章web-application檔案夾下使用指令行工具。

第2步：為部署使用者建立憑據

部署使用者需要适當權限來使用FTP和本地Git服務。在這裡，我們将使用者名設定為“flaskuser11”，密碼設定為“flask123”。使用者設定隻需執行一次，然後就可以重複使用同一個賬戶。如果使用同一個賬戶存在問題，隻需建立一個不同的使用者名即可（可以在使用者名末尾添加一個數字，把我這裡的使用者名末尾數字遞增一下就行）（代碼清單2-46）。

在執行每個azure-cli的步驟時，将會收到确認設定的JSON消息。在“az webapp deployment”的案例中，JSON資訊中大多數應該是空值并且沒有錯誤資訊。如果你看到有錯誤資訊，那麼你可能有權限問題需要解決（“conflict”表示使用者名已經被占用了，請使用其他名稱，“bad requests”表示密碼太弱）。

第3步：建立資源組

資源組将是你操作雲計算資源的邏輯空間。這裡，建議輸入離你所在地理位置最近的Region（Azure的Region資訊請參考：

https://azure.microsoft.com/en-us/regions/

）。在本章案例中，使用“West US”Region不會有多大影響，即使你在世界任何角落。但是在生産環境中，如果希望你的Web服務盡可能靠近你的使用者以便實作更好的服務性能，那麼使用“West US”Region可能會産生一定影響。

第4步：建立Azure應用服務計劃

這裡，我們将名稱設定為“myAppServicePlan”，并選擇一個空閑執行個體sku（代碼清單2-48）。

第5步：建立Web APP

你的“webapp”名稱必須是唯一的，并確定“resource-group”和“plan”名稱與之前設定的相同。這裡，我們将Web APP名稱設定為“amunateguibike”。

檢視支援的全部運作時清單（代碼清單2-50）。

“az webapp create”的輸出包含了後續步驟所需的重要資訊。這裡，主要檢視包含“deploymentLocalGitUrl”的行，如圖2-28所示。

為你的Azure項目執行個體提取本地Git URL配置（代碼清單2-51和代碼清單2-52）。

第6步：将Git代碼推送至Azure

将我們之前儲存的Git倉庫位址URL添加到“add azure”指令後面（代碼清單2-53）。

指令将會提示你輸入密碼，確定這裡輸入的密碼是之前在“az webapp deployment user”步驟中設定的密碼（這裡是flask123）（代碼清單2-54）。

一切就緒！現在你可以回到之前的浏覽器頁面單擊重新整理，或者打開一個新的頁面并輸入如下位址：

http://amunateguibike.

azurewebsites.net （或者在你的實際案例中，可以輸入你自定義的位址：

http://< WITH-YOUR-APP-NAME>>.azurewebsite.ne t，你應該會看到“Predict Bicycle Rental Demand”，如圖2-29所示）。

另外，如果azure-cli指令行工具傳回錯誤消息，則需要進行故障排查（請參閱“故障排查”部分）。當你更新了代碼并想要重新部署時，再次執行push指令即可（代碼清單2-55）。

你也可以直接在Azure的Web儀表闆上管理應用程式。登入Azure并轉到App Services菜單，如圖2-30所示。

2.7.3　資源清理

這一步很關鍵。你不應該在雲端上運作已經不需要的應用程式，因為這肯定會産生不必要的費用（如果是試用使用者，那你可以用完你的免費信用額）。如果你不再需要Azure上的資源，請将其删除！使用指令行删除Azure資源（代碼清單2-56）。

執行結果如圖2-31所示。

另外，也可以在Azure Web儀表闆上的“APP Services”菜單中進行删除操作。

2.7.4　故障排查

故障排查可以解決Web應用程式調試中發現的錯誤，你需要做的事情就是通過Azure的儀表闆打開日志記錄，如圖2-32所示。

然後，打開日志流菜單，開始捕捉程式活動，如圖2-33所示。

另外，你還可以使用Azure儀表闆中内置的便捷控制台工具檢查檔案結構，如圖2-34所示。

你甚至可以使用install指令檢查requirements.txt檔案是否有效，在Azure控制台中執行指令（代碼清單2-57）。

2.7.5　步驟回顧

1）在終端或指令行視窗找到存放本章源代碼的目錄，并進入包含Web應用程式的檔案夾目錄中，如下：

2）向Git倉庫送出所有檔案。

3）登入Azure指令行視窗并授權會話。

4）準備Azure Web應用。

5）推送Web應用程式到Azure公有雲上。

6）在浏覽器中打開URL。

7）終止執行個體。

2.8　Web應用程式腳本及技術分析

下面簡單介紹我們的Web應用程式代碼。其中有兩個重要的檔案：main.py和index.html。main.py是Web服務控制腳本，index.html是模闆檔案，是Web應用程式所要呈現的内容。由于大多數處理都直接在index.html中發生，是以我們主要檢視運作Web應用程式的HTML和JavaScript腳本。

2.8.1　main.py檔案分析

通常情況下，main.py是指揮操作背後的“大腦”。它可以做任何獨立Python腳本能做的事情，并且能夠為Web生成網頁内容。在本章中，除了将特征平均值和模型的截距及系數傳遞給模闆外，這裡确實沒有太多要做的内容了。在本書中，我們将同時使用main.py和application.py兩個檔案。事實上，對于Python Web服務控制檔案的命名并沒有正确或錯誤之分，唯一需要注意的就是不能使用保留字。如果你确實想要自定義檔案名稱，則需要更新YAML檔案和Web伺服器網關接口（WSGI）配置檔案。此外，一些雲服務提供商使用不同的應用程式預設名稱，例如谷歌雲預設為“main”，Azure預設為“application”。但是，不管使用哪種公有雲，名稱都是可以自定義和更改的。

這裡，main.py所做的一個有趣的事情，就是傳遞模型的截距、系數和特征平均值的初始值。

裝飾器“@app.route”将路由任何調用根URL或帶有index.html檔案名的用戶端請求。然後将所有預設值傳遞給index.html模闆（代碼清單2-58）。

Flask使用一種稱為“Jinja2”的技術，将上述這些變量全部注入HTML模闆表單中。如果檢視return語句，你會發現它調用了Flask的render_template函數，并将預期的變量傳遞給index.html。

對HTML模闆而言，要接收這些變量，所要做的事情就是在接收變量上使用“{{ }}”

符号。要檢視模闆腳本内容，請參閱Web應用程式中的index.htm腳本檔案（代碼清單2-59）。

2.8.2　/static/檔案夾分析

顧名思義，靜态檔案夾包含了靜态、不變的檔案。這是Web應用程式存儲圖像、檔案和其他共享資料的位置。

2.8.3　/templates/index.html檔案及腳本分析

templates檔案夾中包含了我們Web應用程式所需的所有模闆。在随後的章節中，我們通常會看到兩個html檔案，一個是index.html，另一個是html響應檔案。實際應用中，最好将這些檔案分開，不要試圖将所有内容全都塞入一個帶有“if then”的複雜分支html檔案中。

與本章相關的大多數Web應用程式操作都發生在index.html檔案中，是以我們有必要仔細分析這個檔案。在編輯器中，打開并檢視完整的index.html檔案。如前所述，本章的“大腦”不是Flask，而是index.html代表的前端頁面以及位于頁面末尾的JavaScript代碼段。JavaScript為網頁設計帶來了很高的互動性。

對于本章中的Web應用程式，它會偵聽按鈕單擊事件，并使用使用者所選特征來運作回歸方程，以重新計算自行車租賃需求。應用程式功能不局限于此，一旦它得到一個新的需求估計值，它将權衡需求值并決定顯示哪個自行車圖檔—如果估計值比較小，則顯示1輛自行車圖檔，如果值很大，則顯示16輛自行車。

使用者單擊Web界面上的特征按鈕，以使用該特定特征來重新計算自行車租賃需求值（代碼清單2-60）。

标簽内的onclick()函數将season_spring的ID發送到主JavaScript函數calculateBikeDemand()。這意味着使用者想要告訴函數，使用season特征變量集來重新計算回歸方程（代碼清單2-61）。

2.9　本章小結

本章介紹的自行車租賃需求預測Web應用是我們的第一個項目！雖然這個項目比較簡單，在Web用戶端和Web伺服器之間幾乎沒有太多的内容互動，但是項目真正實作了一個Web應用程式的定義。本章中，我們介紹了使用Flask和Web控件，将獨立腳本整合成互動式Web應用項目的概念。我們還看到，Python和Python庫可以與Flask Web架構實作便捷通信，進而可以實作快速無縫的Web計算。

在本章的Web應用程式設計過程中，我們首先從規劃Web應用程式應該是什麼，以及觀衆對什麼内容感興趣開始。這個過程需要反複強調：如果沒人感興趣，那就沒必要花心思去建構了。通常而言，我們總是從模組化開始，然後嘗試對其進行改造，以使其适用于Web應用程式。

然後，我們探索了Capital Bikeshare系統中的自行車共享資料集，嘗試了不同的模組化方法來預測環境因素影響下的租賃需求，并選擇我們的Web應用程式最終使用的特征和模型系數。

我們在本地運作了基于Flask的Web應用程式，最後将其部署到Microsoft Azure公有雲上。如果你按照本章介紹的順序執行步驟，那你應該也不會碰到什麼問題。始終要記住一點，首先設計Web應用程式，然後盡可能多地在本地編譯和運作，最後再部署到雲上。

2.10　附加資源

如果你想了解更多關于Flask的知識，去Google搜尋它，你就會得到非常多的材料。更多資訊請參考以下連結：

• Flask：參考官方門戶網站 http://flask.pocoo.org/
• CSS：檢視w3schools網站手冊（CSS及Web相關的很多東西）www.w3schools.com/css/ 。
• Bootstrap：參考網站 https://getbootstrap.com/
• jQuery：參考官方網站 https://jquery.com/
• YAML：參考官方網站 http://yaml.org/
• Jinja2：參考官方文檔 http://jinja.pocoo.org/docs/docs/