第3章
在GCP上基于邏輯回歸實作實時智能
在本章中，我們會在谷歌雲上建構一個能互動式地建立乘客配置的Web應用程式，來預測誰會在泰坦尼克号沉船事件中幸存下來。
我們将重溫經典的受到全世界教科書和教育部落格青睐的泰坦尼克号資料集。我們将分析乘客們的特征，并嘗試了解在這場悲慘的事故中，為什麼有些人幸存下來了，而其他人卻沒有。我們将探索資料集，為模組化做好準備，并将其應用到一個互動式Web應用程式中。該應用會允許使用者建立虛構的乘客配置，設定參數，并可視化他或她在這次航行中的表現（圖3-1）。
我們将使用由範德比爾特大學（Vanderbilt University）生物統計學系托管的資料集，這裡還托管了許多其他有趣的資料集。通過調用Pandas Python庫，你可以友善地直接下載下傳這些資料集。
提示：請通路www.apress.com/9781484238721 ，單擊“Download source code”按鈕，跳轉至GitHub網站，下載下傳第3章所需檔案。推薦使用Jupyter Notebook打開chapter3.ipynb檔案，以配合閱讀本章内容。
3.1 規劃Web應用
作為第一步，我們将充分思考泰坦尼克項目的概念，并在本地機器上建立Web應用程式。
應用程式背後的大腦是來自“sklearn Python庫”的簡單邏輯回歸模型。在資料準備階段，我們會删除非預測特征、為分類資料建立虛拟列，以及在文本字段上應用基本的自然語言處理。然後，我們會訓練該模型，用于識别這趟旅行中幸存者和遇難者之間的共同模式。
為了驗證模型的準确性，我們采用标準的模組化過程，将資料集一分為二，一部分用于模型訓練，另一部分用于模型驗證。一旦我們對模型的能力感到滿意，就可以用它來預測虛構乘客的幸存機率。這個機率是0～1之間的某個數字，代表虛構乘客從沉船事件中幸存下來的機會—越接近1，幸存的機會越大。
最後，我們将抽象并概括整個過程，使得它能在我們的Web應用程式的構造函數中運作。這意味着，在模型部署期間（以及每次重新開機Web伺服器時），隻會進行一次提取、準備和模組化資料的整個過程。這確定了當使用者想要與Web應用程式互動時，它會快速從已訓練好的模型中産生預測，因為它已經被加載到記憶體中了。現在，我們先來完成項目的本地版本。
3.2 資料處理
由于這是一個經典的資料科學練習和一個著名的事件記錄，我們已經知道（或有直覺）哪些特征有助于了解誰會在事故中幸存下來（有關其他資訊，請參閱範德比爾特生物統計資料）。首先将本章的檔案下載下傳到chapter-3檔案夾中。打開Jupyter Notebook以便跟進。先來看一下本機上的資料圖例（表3-1）。
我們可使用Pandas的head()函數以程式設計方式完成探索資料的第一步，該函數将傳回前5行記錄（代碼清單3-1和圖3-2）。你還可以使用tail()函數檢視最後5行資料。
其中，比較引人注意的是，body列中缺少很多值，name和home.dest列中存在大量文本資料，而cabin列中有一些混合内容。
Pandas函數info()、describe()和isnull()也是進行快速資料探索的關鍵。強烈建議你在拿到新資料集時，或在做完任何資料轉換工作後運作這些函數。
info()函數告訴你資料集中包含的資料類型和非空值個數彙總（代碼清單3-2）。
Pandas的info()函數輸出中标記為“non-null object”的資料可被視為基于文本的資料，此時，我們還需要确定它的文本類型。這個過程會具有某種程度的主觀性，因為有很多方法可以解決這個問題（下面很快就會詳細介紹）。
Pandas的describe()函數為你提供所有定量字段的彙總摘要。我們可以看到survived字段的平均值為0.38，這意味着隻有38%的乘客幸存了下來。并且由于我們将使用該特征作為結果标簽來訓練模型，是以整個資料集更偏向于遇難者（也就是說，大多數乘客沒有在這次航行事故中幸存下來，見代碼清單3-3和圖3-3）。
可以将isnull()函數封裝到計數器中，以找出将要處理的缺失值的數量。已經有很多關于估算，以及如何更好地處理模組化方案中缺失資料的書籍出版了。在本例中，我們将丢棄幾個特征，并對其他幾個特征利用插補法（imputation）來補齊缺失的資料（代碼清單3-4和圖3-4）。
在分析該函數的輸出時，我們發現數字的、分類的和基于文本的特征都有缺失資料。資料集總共包含1309行。我們還看到body特征有90%的條目缺失，是以我們将直接丢棄它。我們還将忽略一些其他特征，它們要麼難以使用，要麼對幸存模型沒什麼幫助（例如，乘客的姓氏）。
3.2.1 處理分類型資料
使用分類型資料是一個重要的主題，有時候是主觀的，而有時候則不是。一個好的經驗法則是找出某個基于文本的特定列的所有值中，有多少是唯一的，有多少是重複的。檢查重複度是一個很好的開始。我們将基于cabin特征，調用Pandas的groupby()函數和count()函數。其結果将告訴我們，乘客是否具有共同的cabin特征。如果具有，那該特征應該被歸為分類型的；否則，則是自由格式文本類型的（代碼清單3-5和圖3-5）。
從輸出結果可以确認這些值是分類型的，因為它們是經常重複的（這和直覺一緻，即每個艙室可以有多于一個乘客）。讓我們在另一個基于文本的列上進行相同的實驗，即name特征（我們将會看到具體有多少次重複，見代碼清單3-6和圖3-6）。
就像由直覺所得結果一樣，大多數名字都是唯一的。是以，這個特征列不是分類型的，它一般不适用于模組化（你需要重複的資料來找到模式，是以原始的有唯一性的文本資料不能用于此目的）。
可以在數字和文本資料類型中找到分類型資料。是以，重要的是單獨考察每個特征，并确定最佳模組化方式。例如，sex這一特征是分類型的和二進制的，是以它的資料片段對我們來說價值有限。我們将它更名為isFemale列。如前所示，cabin特征确實有重複性，對此我們還可以做一些處理，使它的重複性更強（代碼清單3-7）。
通過提取該特征的部分樣本，我們注意到這種資料的共性：每個數字前面都有一個代表船甲闆級别的字母（圖3-7）。
是以，利用這些資料的方法之一是隻取其第一個字母并删除數字部分。這為我們提供了一個有趣的新特征：乘客在哪個甲闆層，從該甲闆到頂層甲闆上的救生艇之間的距離是否與幸存與否有某種關聯關系呢？也許有，你可以通過使用我們即将建構出的應用程式找到（代碼清單3-8）。
讓我們像以前計算重複度那樣來運作groupby()和count()函數（代碼清單3-9和圖3-8）。
結果是，重複次數比先前觀察到的要多得多。新的特征應該比以前的特征更具價值。我們将對乘客的name特征做相同的處理，并僅提取稱謂：“Mrs.”或“Mr.”等，同時删除其他部分（有關詳細資訊，請參閱Jupyter Notebook）。
這并不是說原始的自由格式文本（非重複類型的）對模組化沒有用處。相反，世界上大多數資料都是非結構化的，并且非常富有潛力—你可以想象一下醫生的處方單以及商店評價！這些資料可以被模組化，但需要更進階的方法，如自然語言處理、奇異向量分解、單詞向量等。我們将在本書後面的章節中了解這些技術中的一部分。
3.2.2 從分類型資料建立虛拟特征
一旦确定了分類型特征并轉換了需要轉換的特征，我們仍然需要将它們轉換為數字形式，以便我們的模型可以使用它們。Pandas庫中的一個很棒的函數是get_dummies()。它會将每個分類轉化為一個列。
下面是一個使用get_dummies()函數的例子，以及它的輸出（代碼清單3-10和圖3-9）。
該函數作用于一個特征之上，将該特征的每個唯一值轉化為一個單獨列并删除原始值。請記住，并非所有的非連續數字都應該轉化為虛拟字段。以美國郵政編碼為例。如果你對它們進行這種轉化，你将向你的資料集添加額外的43 000個具有極稀疏資料的特征。可見這并不總是一個好主意。對于郵政編碼這種情形，更好的方法可能是進行更大的分類分組，如在城鎮或州這種級别進行分組模組化。
3.3 模組化
這是我們的第二個項目，讓它盡量保持簡單将使我們能夠持續地專注于全局，并在建構Web應用程式所涉及的每個部分上花費差不多相同的時間。我們将使用sklearn庫中的邏輯回歸模型。上一章中，我們使用了線性回歸來嘗試預測連續型變量。邏輯回歸則試圖預測二進制結果，例如真或者假、開心或傷心等。這是兩種非常常見的模型，但你需要使用正确的那個，具體則取決于你嘗試模組化和預測的結果變量的類型。
3.3.1 訓練和測試資料集拆分
利用sklearn中的train_test_split()函數将資料集随機地拆分為兩個帶随機數種子的資料集。每當測試不同方法時，如果你想為了做公平比較而要確定你使用的是同樣的拆分方法時，可以設定random_state參數。test_size參數設定拆分出的測試資料集的大小。在這裡，我們将其設定為0.5或50%，是以它将随機地将資料集平均地拆分為訓練資料集和測試資料集。我們将使用訓練資料集對資料進行模組化，并使用測試資料集來評估模型的運作結果。該函數的使用很簡單（代碼清單3-11和圖3-10）。
拆分出的兩個資料集分别儲存到y_train變量和y_test變量。其中，訓練模型隻會使用y_train（代碼清單3-12）。
3.3.2 邏輯回歸
現在到了決定使用什麼模型并進行設定的時候了。由于我們要預測二進制結果，即乘客會在航行事故中幸存還是遇難，是以邏輯回歸是一個很好的輕量級選擇—它非常應用。我們需要時刻牢記最終目的（代碼清單3-13）。
資料直截了當，幸存模式也衆所周知，大多數模組化算法都适用。用sklearn邏輯回歸模型可以輕松地計算出模型的結果系數，以幫助我們解釋哪些特征對于乘客能在泰坦尼克号之旅中幸存下來至關重要（代碼清單3-14）。
圖3-11顯示了在幸存預測中最正面和最負面的影響因子。很明顯，在這次事故中，幸存率較高的是女性和富人而不是男性和窮人（請參閱Jyputer Notebook以獲得完整的系數清單）。
3.3.3 預測幸存率
一旦有了訓練好的模型，我們就可以使用測試資料集來驗證模型的準确率了（使用前面提到的train_test_split()函數）。永遠不要在訓練階段使用這些資料！隻有這樣，才能保證它對于模型是全新的，這樣才能獲得客觀的評估效果（代碼清單3-15）。
這個模型在測試資料集上的準确率幾乎達到了80%。考慮到我們使用的是一個簡單的模型和一個小型的資料集，這成績其實已經很不錯了。
我們差不多完成了Python腳本，是以隻需要確定可以使用虛構資料進行預測就行了。這是一個重要的步驟，因為我們希望我們的使用者能夠給出他們自己的資料，并通過訓練好了的模型去運作。下面來預測一個50歲三等艙男性乘客的幸存率（代碼清單3-16）。
如果你熟悉這個資料集和這個曆史事件，你就會知道這個虛構乘客的結果不會很好。在模型上運作該資料，然後使用一個簡單的比較圖表來顯示其結果，該圖表顯示了這位虛構乘客的幸存率以及所有乘客的平均存活率。男性和三等艙是一個糟糕的組合（圖3-12）。
3.4 準備上雲
既然已确認我們的模型是有效的了，則可以建立虛構乘客并預測他們的幸存機率了。将代碼打包成兩個函數并用于我們的Web應用程式。在從獨立腳本項目遷移到基于雲的環境這一過程中，保持一切幹淨整潔将減少複雜性和調試難度。
3.4.1 函數startup()
建立一個startup()函數，它負責将資料加載到記憶體中，運作所有的特征工程，建立虛拟列，并訓練模型。隻有當Web伺服器聯機或者重新開機時，該函數才會被調用一次。将盡可能多的東西預加載到記憶體中，将為使用者與Web應用程式互動提供更快的運作和響應體驗。
3.4.2 函數submit_new_profile()
第二個函數是submit_new_profile()。此函數負責處理新虛構乘客的配置，将資料格式化為與真實訓練資料相同的格式，建立所需的虛拟列，并調用模型進行預測及産生幸存機率值。
也就這些了，我們所需要的大部分“智能”工作将由這兩個函數來負責。所有其餘代碼都用于在Web伺服器和HTML頁面之間進行通信和顯示結果，并使整個項目看起來很專業。現在，我們要超越自己，來進一步學習Flask。
使用Flask的一個很好的原因是，它允許我們在Python語言環境中将獨立的Python腳本函數移植到伺服器端Web控件。這使得在模型和Web之間傳遞資料變得更加容易！
3.4.3 使用HTML表單實作互動
除了Flask之外，另一個關鍵前端Web技術是“HTML表單”。雖然這是個很基本的東西，但它是使用者和我們的應用程式之間的關鍵連接配接。HTML表單允許使用者與網頁上的資訊進行互動，然後單擊送出按鈕，将使用者的自定義資料發送回Flask Web伺服器（代碼清單3-17）。
3.4.4 建立動态圖像
在這裡，我們使用一種重要的技術将Python中即時建立的圖像轉換為字元串，這樣HTML解釋器就可以動态地解釋它們了。這是通過“base64”Python子產品提供的：
這個子產品實作了RFC 3548标準中規定的資料編碼和解碼。這個标準定義Base16、Base32和Base64算法，用于将任意二進制字元串編碼和解碼為文本字元串。該文本字元串可以通過電子郵件發送，可用作URL的一部分，以及作為HTTP POST請求中的一部分。編碼算法與uuencode程式不同。
在下面經過删減的代碼片段中，我們使用matplotlib.pyplot庫于Python中建立一個圖像（代碼清單3-18）。
然後就可以使用Flask Jinja2模闆将plot_url變量注入HTLM代碼中了（代碼清單3-19）。
若檢視HTML源代碼輸出，你将看到HTML圖像标簽由長字元串組成（在下面圖示中被大幅删減了）。解釋器會知道如何将其轉換為圖像（圖3-13）。
3.4.5 下載下傳Titanic代碼
如果你還沒有下載下傳第3章的檔案，那現在就請下載下傳它們，并将它們儲存在本地機器上。下載下傳完成後，打開指令行視窗，進入web-application檔案夾。檔案夾結構如代碼清單3-20所示。
然後運作“pip install -r”指令來安裝所需的Python庫（代碼清單3-21）。
運作“Python3 main.py”指令。結果将如圖3-14所示。
然後将URL“
http://127.0.0.1:5000/”（你的終端視窗中顯示的URL位址）複制到你的浏覽器中，你會看到Titanic Web應用程式界面。如果界面沒有出現，請在你喜歡的代碼編輯器中打開main.py檔案（Mac上的sublime和Windows上的notepad ++是我的最愛），并将最後一行的布爾标志修改為“True”。重新運作它，并解決顯示出來的所有問題。
圖3-15顯示了Web應用程式的本地版本。
3.5 部署到谷歌雲上
現在，即将進入另一個有趣的階段，将我們的應用程式部署到無伺服器雲（serverless cloud）上，讓全世界都能看到它！在前言中，我們介紹了Google Standard App Engine（标準應用引擎）。現在，我們将使用Flexible App Engine（靈活應用引擎）來運作更複雜的Python庫。
3.5.1 Google App Engine
Google App Engine是無伺服器的，是以你無須考慮Web應用程式背後的任何與硬體有關的東西。你不用關心應用程式運作在什麼作業系統之上，它将動态地擴充，Google将會負責安全更新檔，你隻需為你消耗的内容付費。
谷歌雲有兩種類型的App Engine供你選擇：一種非常簡單但定制性不強，而另一種則相反。我們在第1章中使用了Standard Environment（标準環境），現在将使用Flexible Environment（靈活環境），因為我們的Web應用程式需要某些Python庫（圖3-16）。
3.5.2 在Google App Engine上進行部署
在Google App Engine上部署Web應用程式有多種方法。在本章中，我們将使用儀表闆本身内置的Shell終端。這種終端可用于很快就能完成的簡單部署。對于複雜部署，你需要從本地計算機打開終端會話，并使用相應的身份驗證開啟與谷歌雲賬戶的連接配接。其他方式包括将GitHub（或BitBucket）直接連結到你的谷歌雲賬戶；直接使用本地計算機上的終端會話；儀表闆中還有一個實驗性的代碼編輯器（請參閱
https://cloudplatform.googleblog.com/2016/10/introducing-Google-Cloud-Shels-new-code-editor.html）。
如果還沒有谷歌雲賬戶，你可以通路谷歌雲入門教程（
https://console.cloud.google.com/getting-started）并設定一個賬戶。在撰寫本書時，Google提供12個月300美元的試用費，以幫助你入門（圖3-17）。
第1步：啟動谷歌雲Shell
登入谷歌雲，建立或選擇一個App Engine項目。單擊右上角的插入符号按鈕啟動谷歌雲Shell指令行工具。這将在GCP儀表闆的下半部分打開一個熟悉的指令行視窗（圖3-18）。
第2步：壓縮所有本地檔案并上傳到雲上
你有很多方法可以完成該步驟：可以逐個上傳檔案，克隆GitHub存儲庫，或者将它們壓縮到一個zip歸檔檔案中并上傳它。我們選擇後面一種方法，将11個檔案壓縮到web-application檔案夾中（圖3-19）。
使用“Upload file”功能将壓縮檔案上傳到雲上（“Upload file”功能在三個垂直點下的Shell視窗的右上側，如圖3-20所示）。
第3步：在谷歌雲上建立工作目錄并解壓縮檔案
成功上傳檔案後，建立一個名為“chapter-3”的新目錄，然後将壓縮檔案移入其中并解壓縮這個檔案（代碼清單3-22）。
第4步：建立lib檔案夾
到目前為止，我們的準備工作快做完了。若檢視requirements.txt檔案，你将看到運作該應用程式所需的一個或多個Python庫。當你建構自己的應用程式時，你可以在此檔案中列出所需的所有庫；然後運作腳本來将它們實際安裝到lib檔案夾。需要注意的是，Google App Engine的Standard Environment（标準環境）僅支援一組最小的庫；對于更複雜的需求，你将需要使用Flexible Environment（靈活環境），這是因為它更接近Python解釋器。運作以下指令将所有需要的附加庫安裝到lib檔案夾。部署Web應用程式時，lib檔案夾将始終包含這些庫檔案（代碼清單3-23）。
第5步：部署Web應用
最後，使用deploy指令将Web應用部署到雲上。會出現一個确認界面（代碼清單3-24）。
隻需要這一句指令就夠了！你可以稍事休息，無伺服器工具會負責部署你的網站。因為我們用的是Flexible App Engine，完成部署最多可能需要20分鐘。部署全部完成後，它将提供一個可點選的連結，點選它會直接跳轉到部署好了的Web應用程式，你也可以使用“browse”指令（代碼清單3-25）通路它。
現在，好好享受你的勞動成果吧！你可以設計各種虛構乘客來做實驗（圖3-21）。
3.5.3 問題排查
如果你遇到任何問題，谷歌雲logs功能會是你的得力幫手。你可以在谷歌雲使用者界面上直接打開它，或者使用logs URL位址（代碼清單3-26）。
你還可以在谷歌雲Shell中運作“app logs tail”指令，以打開日志流（代碼清單3-27）。
3.5.4 收尾工作
最後一件事：在我們完成Web應用程式之前，請不要忘記停止或删除App Engine Cloud執行個體。即使你使用的是免費信用，也不要浪費金錢或信用。
與标準版相比，Flexible App Engine的情況略有不同，因為Flexible會花費更多的錢。是以，如果你不使用它，請務必停止它。這可以通過谷歌雲儀表闆很友善地完成。
導航到App Engine，你會看到版本清單。單擊你的活動版本，停止它（圖3-22）。如果你有多個版本，則可以删除舊版本；你将無法删除預設版本，停止它就可以了（如果你真的不想留下任何痕迹，隻需删除整個項目）。
3.6 代碼回顧
我們來簡單回顧代碼中的關鍵部分。
3.6.1 main.py
main.py檔案與我們使用的Jupyter Notebook略有不同。在運作Web應用程式時，最好不要使用過多的依賴。這就是我們不使用任何Pandas代碼，而選擇使用NumPy數組（代碼清單3-28）的原因。
例如，當某使用者設計一個新的乘客配置時，這些配置值會被簡單地添加到清單中（以正确的順序）并直接輸入邏輯回歸模型。這些字段不會被虛拟，因為它是從一開始就以虛拟狀态建立了的（我們手動對它們進行了虛拟，見代碼清單3-29）。
在這段代碼中，cabin特征會被直接存儲為整數。這會節省一些處理步驟，例如避免調用Pandas的get_dummies()函數。
3.6.2 app.yaml
許多架構依賴YAML來配置和存儲程式設定。app.yaml檔案包含各種配置設定，例如将App Engine環境設定為“flex”，将Python啟動程式腳本的名稱設定為“main”，以及所需硬體的資訊（代碼清單3-30）。
Google App Engine的Flexible Environment需要至少10 GB磁盤空間。
要了解App Engine的app.yaml檔案的更多資訊，可以通路
https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml。
3.6.3 appengine_config.py檔案與lib檔案夾
appengine_config.py檔案和lib檔案夾配合使用，用于處理運作Web應用程式所需的其他Python庫（代碼清單3-31）。
運作“pip install”指令來建立包含所需Python庫的lib檔案夾（代碼清單3-32）。
如果在運作此指令後檢視lib檔案夾，你将看到已部署好了的各種Python庫。此檔案夾将與所有Web應用程式檔案一起部署，以使其正常運作。appengine_config.py的功能比我們所介紹的要多得多；有關它的更多詳細資訊，請參閱官方文檔。
提示 要了解有關appengine_config.py的更多資訊，請查閱Google文檔：
https://cloud.google.com/appengine/docs/standard/python/tools/appengineconfig。
3.6.4 requirements.txt
我們來看看啟動和運作泰坦尼克号Web應用程式所需的所有Python庫（你的版本号可能會有所不同；代碼清單3-33）。
3.7 步驟回顧
我們來回顧一下将泰坦尼克号Web應用部署到谷歌雲上的主要步驟。
1）檢查在本地運作的Web應用程式，壓縮所有Web應用程式檔案，在谷歌雲上建立目标檔案夾，然後解壓縮檔案。
2）建立lib檔案夾。
3）部署Web應用。
4）擷取Web應用的URL。
5）最後關閉環境，登入CGP面闆，進入App Engine，關閉運作着的版本。
3.8 本章小結
從泰坦尼克号資料集上，我們了解到，富人和女性的幸存率最高，而窮人和男性的幸存率則最低。
盡管這個項目很簡單，但本章介紹了許多新概念和新技術。第一個要點是，在開發本地Python概念和模型時，總要為将來移植到雲端做些考慮，這包括保持簡單、處理直覺概念，以及保持代碼整潔和高效。